From kbarrett at openjdk.org Sun Jan 1 02:18:49 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 1 Jan 2023 02:18:49 GMT Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof [v4] In-Reply-To: References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com> Message-ID: On Sat, 31 Dec 2022 17:18:52 GMT, Julian Waters wrote: >> I'm not sure if it's a good idea to entirely forbid `std::alignment_of<>`? While `alignof` should be used over it most of the time, I'm somewhat certain it and it's other counterpart from C++17 (may) have certain differences from `alignof` in newer versions of the language (especially when used with templates and in metaprogramming contexts), which is why I chose to avoid having to take those issues into account for now by simply saying the latter should always be preferred over the former (Similar to how nullptr vs NULL is discussed in the Style Guide). Maybe I could word it better though > > Something like this perhaps? > > - Prefer `alignof` ([n2341](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2341.pdf)) to `std::alignment_of<>`. The template has been superseded by the newer operator. > I'm not sure if it's a good idea to entirely forbid `std::alignment_of<>`? I disagree. > While `alignof` should be used over it most of the time, I'm somewhat certain > it and it's other counterpart from C++17 (may) have certain differences from > `alignof` in newer versions of the language ... `std::alignment_of::value` is defined as `alignof(T)` in every version of the standard. The C++17 addition of `std::alignment_of_v` is just abbreviated syntactic sugar, and is still more verbose than using `alignof`. I see no other changes between versions of the standard, and would be surprised if any were to come in the future. > ... (especially when used with templates and in metaprogramming contexts) ... `std::alignment_of<>` could be used in advanced metaprogramming contexts involving higher order metafunctions. We don't do that sort of thing much at all in HotSpot. If someone finds a place where `std::alignment_of<>` might be better, we can revisit its status. > (Similar to how nullptr vs NULL is discussed in the Style Guide). nullptr vs NULL is a very different situation. New code and substantial changes should use nullptr. But there is a large body of existing code using NULL. When making a small modification to such code one might choose to continue using NULL to be consistent with surrounding code. And one might choose to keep such a change separate from a NULL => nullptr change in that surrounding code. There are no current uses of `std::alignment_of<>` to be consistent with. ------------- PR: https://git.openjdk.org/jdk/pull/11761 From kbarrett at openjdk.org Mon Jan 2 00:12:47 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 2 Jan 2023 00:12:47 GMT Subject: RFR: 8299378: sprintf is deprecated in Xcode 14 [v2] In-Reply-To: References: Message-ID: On Wed, 28 Dec 2022 07:01:19 GMT, Xue-Lei Andrew Fan wrote: >> The `sprintf` is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812), but the test was not covered. The failure was [reported later](https://github.com/openjdk/jdk/pull/11115#issuecomment-1344973773), while gtest is enabled for building. >> >> This patch is just to make sure the building could pass. Other than that, the use of `sprintf` in other places are not touched. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > include os Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/11793 From rehn at openjdk.org Mon Jan 2 08:01:52 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Mon, 2 Jan 2023 08:01:52 GMT Subject: RFR: 8295974: jni_FatalError and Xcheck:jni warnings should print the native stack when there are no Java frames [v4] In-Reply-To: <74PlFZv9YmJ8Of15S94tirJvrqyeI7uv4FNoqQL17Zw=.238d37c1-52cb-4f04-b262-db650b4aa0c4@github.com> References: <74PlFZv9YmJ8Of15S94tirJvrqyeI7uv4FNoqQL17Zw=.238d37c1-52cb-4f04-b262-db650b4aa0c4@github.com> Message-ID: On Fri, 23 Dec 2022 01:18:34 GMT, David Holmes wrote: >> If a JNI Fatal error, or a JNI warning (from Xcheck:jni) is triggered in "top-level" native code (such as the launcher itself, or a freshly attached native thread) then there is no stack printed as there are no Java frames. This enhancement changes that so that we print the native stack, similarly to how error reporting does. We reuse VMError::print_native _stack to do this, but it could be argued this should be moved to a more general purpose utility class - suggestions welcome. >> >> Testing: >> - manual fault injection (see bug report) >> - tiers 1-4 >> >> Thanks. > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Move assertion and make clear print_jni_stack is only for current thread. Marked as reviewed by rehn (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11703 From fweimer at openjdk.org Mon Jan 2 08:21:07 2023 From: fweimer at openjdk.org (Florian Weimer) Date: Mon, 2 Jan 2023 08:21:07 GMT Subject: RFR: 8295159: DSO created with -ffast-math breaks Java floating-point arithmetic [v7] In-Reply-To: References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com> Message-ID: <6Nqp89bLxFyanHeFOs2ihYr8fKLt7RtBXcSZKXQIJ8c=.24c8f48a-758f-4734-ad6d-6f0a196f8148@github.com> On Wed, 12 Oct 2022 17:00:15 GMT, Andrew Haley wrote: >> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics. >> >> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522 >> >> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. >> >> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions. > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > 8295159: DSO created with -ffast-math breaks Java floating-point arithmetic I found another example while reviewing the assembler sources in the Fedora `nacl` package: * [nacl: Corrupts FPU state on x86](https://bugzilla.redhat.com/show_bug.cgi?id=2144809) The assembler sources look as if they were generated with a high-level assembler. That tool apparently does not properly implement the callee-saved nature of the floating-point control word. ------------- PR: https://git.openjdk.org/jdk/pull/10661 From aboldtch at openjdk.org Mon Jan 2 08:38:12 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 2 Jan 2023 08:38:12 GMT Subject: RFR: 8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly [v2] In-Reply-To: References: Message-ID: > In a similar vain to [JDK-8299089](https://bugs.openjdk.org/browse/JDK-8299089) there are different semantics for OopStorage and thread local oops. UnifiedOopRef in the jfr leakprofiler must be able to distinguish these and treat them appropriately. > > Testing: Running test at the moment. Has been running on the generational branch of ZGC for over three months. Not many tests exercise the leakprofiler. x86_32 has mostly been tested with GHA. > > Note: The accessBackend changes are only there to facilitate comparing OopLoadProxy objects directly with nullptr instead of creating and comparing with an `oop()` / `oop(NULL)`. Can be backed out of this PR and put in a different RFE instead. Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Use more suitible nomenclature: raw ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11741/files - new: https://git.openjdk.org/jdk/pull/11741/files/6692c224..e0d2eea4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11741&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11741&range=00-01 Stats: 23 lines in 3 files changed: 0 ins; 0 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/11741.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11741/head:pull/11741 PR: https://git.openjdk.org/jdk/pull/11741 From aboldtch at openjdk.org Mon Jan 2 08:38:12 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 2 Jan 2023 08:38:12 GMT Subject: RFR: 8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly [v2] In-Reply-To: References: Message-ID: On Fri, 23 Dec 2022 09:45:15 GMT, Erik ?sterlund wrote: > Hmm. So we have IN_NATIVE accesses tagged as encode_in_native, and essentially AS_RAW accesses encoded as encode_non_barriered. I usually don't pick on naming, but the term "non-barriered" seems to stray away from already established terminology. I would prefer if the mentions of "non_barriered" changed to "as_raw" for consistency. I agree, changed the terms used. ------------- PR: https://git.openjdk.org/jdk/pull/11741 From iwalulya at openjdk.org Mon Jan 2 09:10:48 2023 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 2 Jan 2023 09:10:48 GMT Subject: RFR: JDK-8299402: Remove metaprogramming/isVolatile.hpp In-Reply-To: <583ZyfXsqKBjcSXWsfGhVpMJsyfEpiVZzXKu9_zxaWo=.06aeb6b5-142d-4c1c-b8fa-7400d08c4f54@github.com> References: <583ZyfXsqKBjcSXWsfGhVpMJsyfEpiVZzXKu9_zxaWo=.06aeb6b5-142d-4c1c-b8fa-7400d08c4f54@github.com> Message-ID: On Thu, 29 Dec 2022 02:49:43 GMT, Justin King wrote: > Code cleanup of pre-C++11 implementations. Marked as reviewed by iwalulya (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11801 From iwalulya at openjdk.org Mon Jan 2 09:11:48 2023 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 2 Jan 2023 09:11:48 GMT Subject: RFR: JDK-8299397: Remove metaprogramming/isFloatingPoint.hpp In-Reply-To: References: Message-ID: On Thu, 29 Dec 2022 02:58:18 GMT, Justin King wrote: > Code cleanup of pre-C++11 implementations. Marked as reviewed by iwalulya (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11802 From aboldtch at openjdk.org Mon Jan 2 09:17:48 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 2 Jan 2023 09:17:48 GMT Subject: RFR: JDK-8299386: Refactor metaprogramming to use In-Reply-To: <4IgAzvExdRfJLSpdv2zIG1hMdZHJLKOv62FMP6IyAPg=.bf4322b6-83ed-4cc7-a1e7-81333079afd8@github.com> References: <4IgAzvExdRfJLSpdv2zIG1hMdZHJLKOv62FMP6IyAPg=.bf4322b6-83ed-4cc7-a1e7-81333079afd8@github.com> Message-ID: On Wed, 28 Dec 2022 06:00:59 GMT, Justin King wrote: > Cleanup `metaprogramming/` to just use implementations from `` that are available in C++11 and onward. Just a general question with regards too our style guide. What is the goal/idea behind this line? https://github.com/openjdk/jdk/blame/2ee34f14880cccca02e2933f80b000979f33c6d1/doc/hotspot-style.md#L578 > TODO: Rather than directly #including (permitted) Standard Library headers, use a convention of #including wrapper headers (in some location like hotspot/shared/stdcpp). This provides a single place for dealing with issues we might have for any given header, esp. platform-specific issues. And is it relevant for any/all of these / metaprogramming changes? ------------- PR: https://git.openjdk.org/jdk/pull/11794 From eosterlund at openjdk.org Mon Jan 2 13:26:50 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 2 Jan 2023 13:26:50 GMT Subject: RFR: 8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly [v2] In-Reply-To: References: Message-ID: <4yw3hKol-8RA_e_x1DUVh-w6dKAdXYZ-CWbXjxEYoqo=.3bfe68cc-4b44-4a39-8f77-1d63915ce193@github.com> On Mon, 2 Jan 2023 08:38:12 GMT, Axel Boldt-Christmas wrote: >> In a similar vain to [JDK-8299089](https://bugs.openjdk.org/browse/JDK-8299089) there are different semantics for OopStorage and thread local oops. UnifiedOopRef in the jfr leakprofiler must be able to distinguish these and treat them appropriately. >> >> Testing: Running test at the moment. Has been running on the generational branch of ZGC for over three months. Not many tests exercise the leakprofiler. x86_32 has mostly been tested with GHA. >> >> Note: The accessBackend changes are only there to facilitate comparing OopLoadProxy objects directly with nullptr instead of creating and comparing with an `oop()` / `oop(NULL)`. Can be backed out of this PR and put in a different RFE instead. > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Use more suitible nomenclature: raw Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.org/jdk/pull/11741 From jcking at openjdk.org Mon Jan 2 14:19:55 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 2 Jan 2023 14:19:55 GMT Subject: Integrated: JDK-8299402: Remove metaprogramming/isVolatile.hpp In-Reply-To: <583ZyfXsqKBjcSXWsfGhVpMJsyfEpiVZzXKu9_zxaWo=.06aeb6b5-142d-4c1c-b8fa-7400d08c4f54@github.com> References: <583ZyfXsqKBjcSXWsfGhVpMJsyfEpiVZzXKu9_zxaWo=.06aeb6b5-142d-4c1c-b8fa-7400d08c4f54@github.com> Message-ID: On Thu, 29 Dec 2022 02:49:43 GMT, Justin King wrote: > Code cleanup of pre-C++11 implementations. This pull request has now been integrated. Changeset: 9d3d0399 Author: Justin King Committer: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/9d3d03997e9eb283bd58c8ea740e62689334966a Stats: 83 lines in 3 files changed: 1 ins; 80 del; 2 mod 8299402: Remove metaprogramming/isVolatile.hpp Reviewed-by: kbarrett, iwalulya, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/11801 From tschatzl at openjdk.org Mon Jan 2 14:21:58 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 2 Jan 2023 14:21:58 GMT Subject: [jdk20] RFR: 8293824: gc/whitebox/TestConcMarkCycleWB.java failed "RuntimeException: assertTrue: expected true, was false" In-Reply-To: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com> References: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com> Message-ID: On Thu, 22 Dec 2022 02:04:30 GMT, Kim Barrett wrote: > Please review this change to WhiteBox and some tests involving G1 concurrent GCs. > > Some tests currently use WhiteBox.g1StartConcMarkCycle() to trigger a > concurrent GC. Many of them follow it with a loop waiting for a concurrent > cycle to not be in progress. A few also preceed that call with a similar > loop, since that call does nothing and returns false if a concurrent cycle is > already in progress. Those tests typically want to ensure there was a > concurrent cycle that was started after some setup. > > The failing test calls that function, asserting that it returned true, e.g. a > new concurrent cycle was started. > > There are various problems with this, due to races with concurrent cycles > started automatically, and due to possibly aborted (by full GCs) concurrent cycles, > making some of these tests unreliable in some configurations. > > For example, the test failure associated with this bug intermittently arises > when running with `-Xcomp`, triggering a concurrent cycle before the explicit > request by the test, causing the explicit request to fail (because there is > already one in progress), failing the assert. Waiting for there not to be an > in-progress cycle before the explicit request just narrows the race window. > > We have a different mechanism in WhiteBox for controlling concurrent cycles, > the concurrent GC breakpoint mechanism. By adding a counter specifically for > such cycles, we can use GC breakpoints to ensure only the concurrent cycles > the test wants are occurring, and can verify they completed successfully. > > So we change tests using WhiteBox.g1StartConcMarkCycle() to instead use GC > breakpoints, along with the new WhiteBox.g1CompletedConcurrentMarkCycles() to > avoid racing request problems and to detect aborted cycles. Since it is no > longer used, WhiteBox.g1StartConcMarkCycle() is removed. The test that began > this adventure (TestConcMarkCycleWB.java) is also removed, since it no longer > serves any purpose, having been purely a test of that removed function. > > Testing: > mach5 tier1-7 - running the changed tests on a variety of platforms with a > variety of configurations. Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.org/jdk20/pull/71 From jcking at openjdk.org Mon Jan 2 14:38:53 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 2 Jan 2023 14:38:53 GMT Subject: Integrated: JDK-8299397: Remove metaprogramming/isFloatingPoint.hpp In-Reply-To: References: Message-ID: On Thu, 29 Dec 2022 02:58:18 GMT, Justin King wrote: > Code cleanup of pre-C++11 implementations. This pull request has now been integrated. Changeset: ce6395a1 Author: Justin King Committer: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/ce6395a1356a3d1334aeffc70ac8e4f86dd81a4c Stats: 98 lines in 3 files changed: 0 ins; 96 del; 2 mod 8299397: Remove metaprogramming/isFloatingPoint.hpp Reviewed-by: kbarrett, iwalulya, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/11802 From ayang at openjdk.org Mon Jan 2 14:59:51 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 2 Jan 2023 14:59:51 GMT Subject: RFR: 8298482: Implement ParallelGC NUMAStats for Linux In-Reply-To: References: Message-ID: On Mon, 12 Dec 2022 15:19:21 GMT, Nick Gasson wrote: > ParallelGC has a seemingly useful option -XX:+NUMAStats that prints detailed information in GC.heap_info about which NUMA node pages in the eden space are bound to. However as far as I can tell this only ever worked on Solaris and is not implemented on any of the systems we currently support. This patch implements it on Linux using the move_pages system call. > > The function os::get_page_info() and accompanying struct page_info was just a thin wrapper around the Solaris meminfo(2) syscall and was never ported to other systems so I've just removed it rather than try to emulate its interface. > > There's also a method MutableNUMASpace::LGRPSpace::scan_pages() which attempts to find pages on the wrong NUMA node and frees them so that they have another chance to be allocated on the correct node by the first-touching thread, but I think this has always been a no-op on non-Solaris so perhaps should also be removed. On Linux it shouldn't be necessary as you can bind pages to the desired node directly. > > I don't know what the performance of this option was like on Solaris but on Linux the move_pages call can be quite slow: I measured about 25ms/GB on my system. At the moment we call LGRPSpace::accumulate_statistics() twice per GC cycle: I removed the second call as it's likely to see a lot of uncommitted pages if the spaces were just resized. MutableNUMASpace::print_on() also calls accumulate_statistics() directly and since that's the only place this data is used, maybe we can drop the call from MutableNUMASpace::accumulate_statistics() as well? > > Example output: > > > PSYoungGen total 4290560K, used 835628K [0x00000006aac00000, 0x0000000800000000, 0x0000000800000000) > eden space 3096576K, 1% used [0x00000006aac00000,0x00000007176a9f48,0x0000000767c00000) > lgrp 0 space 1761280K, 2% used [0x00000006aac00000,0x00000006acfc4980,0x0000000716400000) > local/remote/unbiased/uncommitted: 1671168K/0K/0K/90112K, large/small pages: 0/440320 > lgrp 1 space 1335296K, 46% used [0x0000000716400000,0x000000073c2abb18,0x0000000767c00000) > local/remote/unbiased/uncommitted: 1335296K/0K/0K/0K, large/small pages: 0/333824 > from space 1193984K, 65% used [0x00000007b7200000,0x00000007e6b9c778,0x0000000800000000) > to space 1247232K, 0% used [0x0000000767c00000,0x0000000767c00000,0x00000007b3e00000) > > > After testing this with SPECjbb for a while I noticed some pages always end up bound to the wrong node. I think this is a regression caused by JDK-8283935 but I'll raise a separate ticket for that. src/hotspot/share/gc/parallel/mutableNUMASpace.cpp line 896: > 894: size_t npages = 0; > 895: for (; npages < PagesPerIteration && p < end; p += os::vm_page_size()) > 896: pages[npages++] = p; This means each page is `vm_page_size()` aligned. Would it be problematic if large-page is in use? ------------- PR: https://git.openjdk.org/jdk/pull/11635 From jcking at openjdk.org Mon Jan 2 21:11:23 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 2 Jan 2023 21:11:23 GMT Subject: RFR: JDK-8299479: Remove metaprogramming/decay.hpp Message-ID: Code cleanup of pre-C++11 implementations. ------------- Commit messages: - Remove header - Remove include - Remove metaprogramming/decay.hpp Changes: https://git.openjdk.org/jdk/pull/11816/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11816&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299479 Stats: 103 lines in 3 files changed: 0 ins; 89 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/11816.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11816/head:pull/11816 PR: https://git.openjdk.org/jdk/pull/11816 From jcking at openjdk.org Mon Jan 2 21:11:23 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 2 Jan 2023 21:11:23 GMT Subject: RFR: JDK-8299479: Remove metaprogramming/decay.hpp In-Reply-To: References: Message-ID: On Mon, 2 Jan 2023 21:03:51 GMT, Justin King wrote: > Code cleanup of pre-C++11 implementations. @kimbarrett Another one. ------------- PR: https://git.openjdk.org/jdk/pull/11816 From jcking at openjdk.org Mon Jan 2 22:43:31 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 2 Jan 2023 22:43:31 GMT Subject: RFR: JDK-8299481: Remove metaprogramming/removePointer.hpp Message-ID: Code cleanup of pre-C++11 implementations. ------------- Commit messages: - Remove include - Remove metaprogramming/removePointer.hpp Changes: https://git.openjdk.org/jdk/pull/11817/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11817&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299481 Stats: 87 lines in 3 files changed: 0 ins; 87 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11817.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11817/head:pull/11817 PR: https://git.openjdk.org/jdk/pull/11817 From jcking at openjdk.org Mon Jan 2 22:43:31 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 2 Jan 2023 22:43:31 GMT Subject: RFR: JDK-8299481: Remove metaprogramming/removePointer.hpp In-Reply-To: References: Message-ID: On Mon, 2 Jan 2023 22:30:21 GMT, Justin King wrote: > Code cleanup of pre-C++11 implementations. @kimbarrett Another one. ------------- PR: https://git.openjdk.org/jdk/pull/11817 From jcking at openjdk.org Mon Jan 2 22:44:34 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 2 Jan 2023 22:44:34 GMT Subject: RFR: JDK-8299482: Remove metaprogramming/isIntegral.hpp Message-ID: Code cleanup of pre-C++11 implementations. ------------- Commit messages: - Remove metaprogramming/isIntegral.hpp Changes: https://git.openjdk.org/jdk/pull/11818/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11818&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299482 Stats: 140 lines in 5 files changed: 3 ins; 123 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/11818.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11818/head:pull/11818 PR: https://git.openjdk.org/jdk/pull/11818 From jcking at openjdk.org Mon Jan 2 22:44:35 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 2 Jan 2023 22:44:35 GMT Subject: RFR: JDK-8299482: Remove metaprogramming/isIntegral.hpp In-Reply-To: References: Message-ID: On Mon, 2 Jan 2023 22:36:37 GMT, Justin King wrote: > Code cleanup of pre-C++11 implementations. @kimbarrett Another one. ------------- PR: https://git.openjdk.org/jdk/pull/11818 From jcking at openjdk.org Mon Jan 2 23:11:10 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 2 Jan 2023 23:11:10 GMT Subject: RFR: JDK-8299482: Remove metaprogramming/isIntegral.hpp [v2] In-Reply-To: References: Message-ID: > Code cleanup of pre-C++11 implementations. Justin King has updated the pull request incrementally with one additional commit since the last revision: Add missing include Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11818/files - new: https://git.openjdk.org/jdk/pull/11818/files/54ae69eb..a22853dc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11818&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11818&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11818.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11818/head:pull/11818 PR: https://git.openjdk.org/jdk/pull/11818 From kbarrett at openjdk.org Tue Jan 3 02:05:48 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 3 Jan 2023 02:05:48 GMT Subject: RFR: JDK-8299481: Remove metaprogramming/removePointer.hpp In-Reply-To: References: Message-ID: On Mon, 2 Jan 2023 22:30:21 GMT, Justin King wrote: > Code cleanup of pre-C++11 implementations. Looks good, and trivial. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/11817 From kbarrett at openjdk.org Tue Jan 3 02:09:48 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 3 Jan 2023 02:09:48 GMT Subject: RFR: JDK-8299482: Remove metaprogramming/isIntegral.hpp [v2] In-Reply-To: References: Message-ID: On Mon, 2 Jan 2023 23:11:10 GMT, Justin King wrote: >> Code cleanup of pre-C++11 implementations. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Add missing include > > Signed-off-by: Justin King Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/11818 From xuelei at openjdk.org Tue Jan 3 03:13:50 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Tue, 3 Jan 2023 03:13:50 GMT Subject: RFR: 8299254: Support dealing with standard assert macro In-Reply-To: <6VQwFg9prwXbOwp_asHA4-Wru6PdKvaRN8MGiU24_sw=.1cafd8ea-e7e4-4a9d-a8ba-4f0cf87621d2@github.com> References: <6VQwFg9prwXbOwp_asHA4-Wru6PdKvaRN8MGiU24_sw=.1cafd8ea-e7e4-4a9d-a8ba-4f0cf87621d2@github.com> Message-ID: On Thu, 22 Dec 2022 23:05:03 GMT, Kim Barrett wrote: > Please review this change to provide and use mechanisms for dealing with uses > of the standard assert macro (from or ) in 3rd party code > that we use in HotSpot. > > We provide a pair of utility header files, to be included before and after a > header that may use (and so include) the standard assert macro. These new > headers provide a scope in which the HotSpot assert macro is not defined, and > then reinstated after. > > We also define NDEBUG in release builds of HotSpot, so any uses of the > standard assert macro in such 3rd party code will be disabled. > > Finally, we use the new utility headers in some gtests and in our gtest > wrapper header (unittest.hpp), eliminating problems the gtest implementation > and with some versions of some standard libraries that the tests use. > > Testing: > mach5 tier1 The patch passed for my build on MacOSX13.1/M1 (See JDK-8299380). Thanks! ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.org/jdk/pull/11770 From fyang at openjdk.org Tue Jan 3 03:41:47 2023 From: fyang at openjdk.org (Fei Yang) Date: Tue, 3 Jan 2023 03:41:47 GMT Subject: RFR: 8299162: Refactor shared trampoline emission logic [v2] In-Reply-To: <2AQOqhItBwarWAAf3o64HQnJqGLN7hRd96krydvJxeM=.22d31e24-c43d-44fb-b54b-d1ea86893883@github.com> References: <2AQOqhItBwarWAAf3o64HQnJqGLN7hRd96krydvJxeM=.22d31e24-c43d-44fb-b54b-d1ea86893883@github.com> Message-ID: On Thu, 22 Dec 2022 03:44:11 GMT, Xiaolin Zheng wrote: >> After the quick fix [JDK-8297763](https://bugs.openjdk.org/browse/JDK-8297763), shared trampoline logic gets a bit verbose. If we can turn to batch emission of trampoline stubs, pre-calculating the total size, and pre-allocating them, then we can remove the CodeBuffer expansion checks each time and clean up the code around. >> >> >> [Stub Code] >> ... >> >> __ align() // emit nothing or a 4-byte padding >> <-- (B) emit multiple relocations at the pc: __ relocate(, trampoline_stub_Relocation::spec()) >> __ ldr() >> __ br() >> __ emit_int64() >> >> __ align() // emit nothing or a 4-byte padding >> <-- emit multiple relocations at the pc: __ relocate(, trampoline_stub_Relocation::spec()) >> __ ldr() >> __ br() >> __ emit_int64() >> >> __ align() // emit nothing or a 4-byte padding >> <-- emit multiple relocations at the pc: __ relocate(, trampoline_stub_Relocation::spec()) >> __ ldr() >> __ br() >> __ emit_int64() >> >> >> Here, the `pc_at_(C) - pc_at_(B)` is the fixed length `NativeCallTrampolineStub::instruction_size`; but the `pc_at_(B) - pc_at_(A)` may be a 0 or 4, which is not a fixed-length value. >> >> So originally: >> The logic of the lambda `emit()` inside the `emit_shared_trampolines()` when emitting a shared trampoline: >> >> We are at (A) -> >> do an align() -> >> We are at (B) -> >> emit lots of relocations bound to this shared trampoline at (B) -> >> do an emit_trampoline_stub() -> >> We are at (C) >> >> >> After this patch: >> >> We are at (A) -> >> do an emit_trampoline_stub(), which contains an align() already -> >> We are at (C) directly -> >> reversely calculate the (B) address, for `pc_at_(C) - pc_at_(B)` is a fixed-length value -> >> emit lots of relocations bound to this shared trampoline at (B) >> >> >> Theoretically the same. Just a code refactoring and we can remove some checks inside and make the code clean. >> >> Tested AArch64 hotspot tier1~4 with fastdebug build twice; Tested RISC-V hotspot tier1~4 with fastdebug build on hardware once. >> >> >> Thanks, >> Xiaolin > > Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision: > > __ Looks good to me. Better to have another reviewer. ------------- Marked as reviewed by fyang (Reviewer). PR: https://git.openjdk.org/jdk/pull/11749 From dholmes at openjdk.org Tue Jan 3 04:25:54 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 3 Jan 2023 04:25:54 GMT Subject: RFR: 8295974: jni_FatalError and Xcheck:jni warnings should print the native stack when there are no Java frames [v4] In-Reply-To: References: <74PlFZv9YmJ8Of15S94tirJvrqyeI7uv4FNoqQL17Zw=.238d37c1-52cb-4f04-b262-db650b4aa0c4@github.com> Message-ID: <2XHjWC6oDrUF9Lytyyuy1j50U1rorLTKUvl7RJH8OV8=.0333d8fa-12c1-4253-b88e-c4c1729a7380@github.com> On Mon, 2 Jan 2023 07:58:58 GMT, Robbin Ehn wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Move assertion and make clear print_jni_stack is only for current thread. > > Marked as reviewed by rehn (Reviewer). Thanks @robehn ! ------------- PR: https://git.openjdk.org/jdk/pull/11703 From dholmes at openjdk.org Tue Jan 3 04:25:56 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 3 Jan 2023 04:25:56 GMT Subject: Integrated: 8295974: jni_FatalError and Xcheck:jni warnings should print the native stack when there are no Java frames In-Reply-To: References: Message-ID: On Fri, 16 Dec 2022 07:07:06 GMT, David Holmes wrote: > If a JNI Fatal error, or a JNI warning (from Xcheck:jni) is triggered in "top-level" native code (such as the launcher itself, or a freshly attached native thread) then there is no stack printed as there are no Java frames. This enhancement changes that so that we print the native stack, similarly to how error reporting does. We reuse VMError::print_native _stack to do this, but it could be argued this should be moved to a more general purpose utility class - suggestions welcome. > > Testing: > - manual fault injection (see bug report) > - tiers 1-4 > > Thanks. This pull request has now been integrated. Changeset: 37574333 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/375743336dc15f9f945a03422eaa7ff773622cd8 Stats: 230 lines in 6 files changed: 213 ins; 9 del; 8 mod 8295974: jni_FatalError and Xcheck:jni warnings should print the native stack when there are no Java frames Reviewed-by: coleenp, rehn, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/11703 From dholmes at openjdk.org Tue Jan 3 05:22:51 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 3 Jan 2023 05:22:51 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v2] In-Reply-To: References: <1rK2mzryGeyI-Yak0rUIqYZBuK5zrxCYwPe9zJbjHpY=.5471f1af-f8b8-4219-ae93-8b5a5fecaad9@github.com> Message-ID: On Fri, 23 Dec 2022 14:53:38 GMT, Erik ?sterlund wrote: >> The JfrVFrameStream is used while generating stack traces for events. One of the events are the ZPage allocation event. This event is sometimes sent when ZGC is relocating. The current implementation of JfrVFrameStream uses WalkContinuation::include, which causes JFR to walk the continuation and perform GC barriers. This is problematic, since ZGC has a requirement that we never perform load barriers while running the relocation code. If we do, we might end up performing other reloctions from the the relocation code, and in some cases that causes dead locks. >> >> I propose that JFR doesn't walk the stack during stack watermark processing. This PR implements that change. This PR replaces https://github.com/openjdk/jdk/pull/11586 > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Fix release build src/hotspot/share/runtime/disableStackTracingMark.cpp line 34: > 32: : _jt(nullptr), > 33: _sp(nullptr) { > 34: if (jt == Thread::current()) { Just a drive-by comment, but what is the case for `jt` not being the current thread? ------------- PR: https://git.openjdk.org/jdk/pull/11778 From kbarrett at openjdk.org Tue Jan 3 05:41:49 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 3 Jan 2023 05:41:49 GMT Subject: RFR: JDK-8299386: Refactor metaprogramming to use In-Reply-To: References: <4IgAzvExdRfJLSpdv2zIG1hMdZHJLKOv62FMP6IyAPg=.bf4322b6-83ed-4cc7-a1e7-81333079afd8@github.com> Message-ID: On Mon, 2 Jan 2023 09:15:16 GMT, Axel Boldt-Christmas wrote: > Just a general question with regards too our style guide. What is the goal/idea behind this line? https://github.com/openjdk/jdk/blame/2ee34f14880cccca02e2933f80b000979f33c6d1/doc/hotspot-style.md#L578 > > > TODO: Rather than directly #including (permitted) Standard Library headers, use a convention of #including wrapper headers (in some location like hotspot/shared/stdcpp). This provides a single place for dealing with issues we might have for any given header, esp. platform-specific issues. > > And is it relevant for any/all of these / metaprogramming changes? This is kind of a hint / reminder / statement of intent for future direction, particularly if/when we start permitting the use of more of the Standard Library. There were questions about whether we were going to do that and how we might control it, back when I was doing the large revision of this document for C++14 support. It currently has no real force (it's a TODO item after all), and probably doesn't really belong in the current document. But there are continuing discussions about opening up some amount of StdLib usage. ------------- PR: https://git.openjdk.org/jdk/pull/11794 From dholmes at openjdk.org Tue Jan 3 06:39:48 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 3 Jan 2023 06:39:48 GMT Subject: RFR: 8299254: Support dealing with standard assert macro In-Reply-To: <6VQwFg9prwXbOwp_asHA4-Wru6PdKvaRN8MGiU24_sw=.1cafd8ea-e7e4-4a9d-a8ba-4f0cf87621d2@github.com> References: <6VQwFg9prwXbOwp_asHA4-Wru6PdKvaRN8MGiU24_sw=.1cafd8ea-e7e4-4a9d-a8ba-4f0cf87621d2@github.com> Message-ID: <0K8uV1bRbUyVzdzMaz7ikBg6JZH9LeZys9g56llUm74=.e8df7e1d-4541-4641-b680-783870165d80@github.com> On Thu, 22 Dec 2022 23:05:03 GMT, Kim Barrett wrote: > Please review this change to provide and use mechanisms for dealing with uses > of the standard assert macro (from or ) in 3rd party code > that we use in HotSpot. > > We provide a pair of utility header files, to be included before and after a > header that may use (and so include) the standard assert macro. These new > headers provide a scope in which the HotSpot assert macro is not defined, and > then reinstated after. > > We also define NDEBUG in release builds of HotSpot, so any uses of the > standard assert macro in such 3rd party code will be disabled. > > Finally, we use the new utility headers in some gtests and in our gtest > wrapper header (unittest.hpp), eliminating problems the gtest implementation > and with some versions of some standard libraries that the tests use. > > Testing: > mach5 tier1 Not pretty, but effective. Do we need some text added to the hotspot style guide to describe this usage? Should we bracket all includes of system headers with these, or only those known to cause a problem? Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/11770 From dholmes at openjdk.org Tue Jan 3 07:00:50 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 3 Jan 2023 07:00:50 GMT Subject: RFR: 8299378: sprintf is deprecated in Xcode 14 [v2] In-Reply-To: References: Message-ID: On Wed, 28 Dec 2022 07:01:19 GMT, Xue-Lei Andrew Fan wrote: >> The `sprintf` is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812), but the test was not covered. The failure was [reported later](https://github.com/openjdk/jdk/pull/11115#issuecomment-1344973773), while gtest is enabled for building. >> >> This patch is just to make sure the building could pass. Other than that, the use of `sprintf` in other places are not touched. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > include os Seems fine. Thanks. One nit below. test/hotspot/gtest/utilities/test_unsigned5.cpp line 25: > 23: > 24: #include "precompiled.hpp" > 25: #include "runtime/os.hpp" Nit: please sort includes alphabetically ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/11793 From eosterlund at openjdk.org Tue Jan 3 08:51:49 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 3 Jan 2023 08:51:49 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v2] In-Reply-To: References: <1rK2mzryGeyI-Yak0rUIqYZBuK5zrxCYwPe9zJbjHpY=.5471f1af-f8b8-4219-ae93-8b5a5fecaad9@github.com> Message-ID: On Tue, 3 Jan 2023 05:20:06 GMT, David Holmes wrote: >> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix release build > > src/hotspot/share/runtime/disableStackTracingMark.cpp line 34: > >> 32: : _jt(nullptr), >> 33: _sp(nullptr) { >> 34: if (jt == Thread::current()) { > > Just a drive-by comment, but what is the case for `jt` not being the current thread? If one thread is processing oops of a different thread, for example when you perform a handshake with a target thread and its oops need to be sane, then the jt is the target thread, which is not the current one. But the stack sampling is based on the current thread always, so if the passed in thread isn't the current thread, there is nothing to do. Hmm - I should add a comment shouldn't I? :-) ------------- PR: https://git.openjdk.org/jdk/pull/11778 From tschatzl at openjdk.org Tue Jan 3 09:14:52 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 3 Jan 2023 09:14:52 GMT Subject: RFR: JDK-8299481: Remove metaprogramming/removePointer.hpp In-Reply-To: References: Message-ID: On Mon, 2 Jan 2023 22:30:21 GMT, Justin King wrote: > Code cleanup of pre-C++11 implementations. Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11817 From tschatzl at openjdk.org Tue Jan 3 09:15:49 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 3 Jan 2023 09:15:49 GMT Subject: RFR: JDK-8299482: Remove metaprogramming/isIntegral.hpp [v2] In-Reply-To: References: Message-ID: <5Xh8qDjDTLIVPTgK5pnNb_cE6Tum-FgixJbAj6mqGuw=.40139009-8a1c-46db-84e6-8be362d0aa37@github.com> On Mon, 2 Jan 2023 23:11:10 GMT, Justin King wrote: >> Code cleanup of pre-C++11 implementations. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Add missing include > > Signed-off-by: Justin King Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11818 From tschatzl at openjdk.org Tue Jan 3 09:16:55 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 3 Jan 2023 09:16:55 GMT Subject: RFR: JDK-8299479: Remove metaprogramming/decay.hpp In-Reply-To: References: Message-ID: On Mon, 2 Jan 2023 21:03:51 GMT, Justin King wrote: > Code cleanup of pre-C++11 implementations. Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11816 From shade at openjdk.org Tue Jan 3 10:13:49 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 3 Jan 2023 10:13:49 GMT Subject: RFR: 8299072: java_lang_ref_Reference::clear_referent should be GC agnostic In-Reply-To: References: Message-ID: <6S2QZ9-NMeIQe0FUCdZlCKuWG8h_dwdFs9_sqMbJ6Ng=.4fe5ec3c-d4fc-4efe-ae19-5b9caf64a316@github.com> On Tue, 20 Dec 2022 07:05:34 GMT, Erik ?sterlund wrote: > The current java_lang_ref_Reference::clear_referent implementation performs a raw reference clear. That doesn't work well with upcoming GC algorithms. It should be made GC agnostic by going through the normal access API. Looks fine. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/11736 From mdoerr at openjdk.org Tue Jan 3 10:39:53 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 3 Jan 2023 10:39:53 GMT Subject: RFR: 8291302: ARM32: nmethod entry barriers support [v5] In-Reply-To: References: Message-ID: On Mon, 26 Dec 2022 10:31:12 GMT, Aleksei Voitylov wrote: >> This PR implements nmethod entry barriers for ARM32. It has already been implemented for other ports and is related with JDK-8290025 "Remove the Sweeper". > > Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: > > address review comments Thanks for the cleanup! Still looks good. I think the PR is ready for integration. You have 3 reviews and the concerns were addressed. ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.org/jdk/pull/11442 From ngasson at openjdk.org Tue Jan 3 10:41:49 2023 From: ngasson at openjdk.org (Nick Gasson) Date: Tue, 3 Jan 2023 10:41:49 GMT Subject: RFR: 8298482: Implement ParallelGC NUMAStats for Linux In-Reply-To: References: Message-ID: On Mon, 2 Jan 2023 14:44:01 GMT, Albert Mingkun Yang wrote: >> ParallelGC has a seemingly useful option -XX:+NUMAStats that prints detailed information in GC.heap_info about which NUMA node pages in the eden space are bound to. However as far as I can tell this only ever worked on Solaris and is not implemented on any of the systems we currently support. This patch implements it on Linux using the move_pages system call. >> >> The function os::get_page_info() and accompanying struct page_info was just a thin wrapper around the Solaris meminfo(2) syscall and was never ported to other systems so I've just removed it rather than try to emulate its interface. >> >> There's also a method MutableNUMASpace::LGRPSpace::scan_pages() which attempts to find pages on the wrong NUMA node and frees them so that they have another chance to be allocated on the correct node by the first-touching thread, but I think this has always been a no-op on non-Solaris so perhaps should also be removed. On Linux it shouldn't be necessary as you can bind pages to the desired node directly. >> >> I don't know what the performance of this option was like on Solaris but on Linux the move_pages call can be quite slow: I measured about 25ms/GB on my system. At the moment we call LGRPSpace::accumulate_statistics() twice per GC cycle: I removed the second call as it's likely to see a lot of uncommitted pages if the spaces were just resized. MutableNUMASpace::print_on() also calls accumulate_statistics() directly and since that's the only place this data is used, maybe we can drop the call from MutableNUMASpace::accumulate_statistics() as well? >> >> Example output: >> >> >> PSYoungGen total 4290560K, used 835628K [0x00000006aac00000, 0x0000000800000000, 0x0000000800000000) >> eden space 3096576K, 1% used [0x00000006aac00000,0x00000007176a9f48,0x0000000767c00000) >> lgrp 0 space 1761280K, 2% used [0x00000006aac00000,0x00000006acfc4980,0x0000000716400000) >> local/remote/unbiased/uncommitted: 1671168K/0K/0K/90112K, large/small pages: 0/440320 >> lgrp 1 space 1335296K, 46% used [0x0000000716400000,0x000000073c2abb18,0x0000000767c00000) >> local/remote/unbiased/uncommitted: 1335296K/0K/0K/0K, large/small pages: 0/333824 >> from space 1193984K, 65% used [0x00000007b7200000,0x00000007e6b9c778,0x0000000800000000) >> to space 1247232K, 0% used [0x0000000767c00000,0x0000000767c00000,0x00000007b3e00000) >> >> >> After testing this with SPECjbb for a while I noticed some pages always end up bound to the wrong node. I think this is a regression caused by JDK-8283935 but I'll raise a separate ticket for that. > > src/hotspot/share/gc/parallel/mutableNUMASpace.cpp line 896: > >> 894: size_t npages = 0; >> 895: for (; npages < PagesPerIteration && p < end; p += os::vm_page_size()) >> 896: pages[npages++] = p; > > This means each page is `vm_page_size()` aligned. Would it be problematic if large-page is in use? I don't think so: for HugeTLBFS it makes some redundant calls but in my testing always returns the node ID for the containing huge page even if the address given is not huge page aligned, and for THP you don't know whether a particular address is backed by a huge page so you have to step with the smallest granularity anyway. With large pages enabled the "small/large pages" count is misleading but I don't know any way to get this information on Linux except by parsing `/proc/self/smaps` which we probably don't want to do. ------------- PR: https://git.openjdk.org/jdk/pull/11635 From eosterlund at openjdk.org Tue Jan 3 10:59:49 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 3 Jan 2023 10:59:49 GMT Subject: RFR: 8291302: ARM32: nmethod entry barriers support [v5] In-Reply-To: References: Message-ID: On Mon, 26 Dec 2022 10:31:12 GMT, Aleksei Voitylov wrote: >> This PR implements nmethod entry barriers for ARM32. It has already been implemented for other ports and is related with JDK-8290025 "Remove the Sweeper". > > Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: > > address review comments Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.org/jdk/pull/11442 From avoitylov at openjdk.org Tue Jan 3 12:05:55 2023 From: avoitylov at openjdk.org (Aleksei Voitylov) Date: Tue, 3 Jan 2023 12:05:55 GMT Subject: Integrated: 8291302: ARM32: nmethod entry barriers support In-Reply-To: References: Message-ID: On Wed, 30 Nov 2022 20:26:23 GMT, Aleksei Voitylov wrote: > This PR implements nmethod entry barriers for ARM32. It has already been implemented for other ports and is related with JDK-8290025 "Remove the Sweeper". This pull request has now been integrated. Changeset: 245f0cf4 Author: Aleksei Voitylov Committer: Martin Doerr URL: https://git.openjdk.org/jdk/commit/245f0cf4ac9dc655bfe2abb1c88c6ed1ddffd291 Stats: 268 lines in 12 files changed: 263 ins; 0 del; 5 mod 8291302: ARM32: nmethod entry barriers support Reviewed-by: eosterlund, rrich, mdoerr, aph ------------- PR: https://git.openjdk.org/jdk/pull/11442 From ayang at openjdk.org Tue Jan 3 12:08:55 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 3 Jan 2023 12:08:55 GMT Subject: RFR: 8298482: Implement ParallelGC NUMAStats for Linux In-Reply-To: References: Message-ID: On Tue, 3 Jan 2023 10:39:22 GMT, Nick Gasson wrote: >> src/hotspot/share/gc/parallel/mutableNUMASpace.cpp line 896: >> >>> 894: size_t npages = 0; >>> 895: for (; npages < PagesPerIteration && p < end; p += os::vm_page_size()) >>> 896: pages[npages++] = p; >> >> This means each page is `vm_page_size()` aligned. Would it be problematic if large-page is in use? > > I don't think so: for HugeTLBFS it makes some redundant calls but in my testing always returns the node ID for the containing huge page even if the address given is not huge page aligned, and for THP you don't know whether a particular address is backed by a huge page so you have to step with the smallest granularity anyway. With large pages enabled the "small/large pages" count is misleading but I don't know any way to get this information on Linux except by parsing `/proc/self/smaps` which we probably don't want to do. I see; thanks for the clarification. Re the misleading "small/large pages" count, can it be dropped? Or, what useful info does this count convey towards identifying wrongly placed OS pages? ------------- PR: https://git.openjdk.org/jdk/pull/11635 From mgronlun at openjdk.org Tue Jan 3 13:34:49 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 3 Jan 2023 13:34:49 GMT Subject: RFR: 8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly [v2] In-Reply-To: References: Message-ID: On Mon, 2 Jan 2023 08:38:12 GMT, Axel Boldt-Christmas wrote: >> In a similar vain to [JDK-8299089](https://bugs.openjdk.org/browse/JDK-8299089) there are different semantics for OopStorage and thread local oops. UnifiedOopRef in the jfr leakprofiler must be able to distinguish these and treat them appropriately. >> >> Testing: Running test at the moment. Has been running on the generational branch of ZGC for over three months. Not many tests exercise the leakprofiler. x86_32 has mostly been tested with GHA. >> >> Note: The accessBackend changes are only there to facilitate comparing OopLoadProxy objects directly with nullptr instead of creating and comparing with an `oop()` / `oop(NULL)`. Can be backed out of this PR and put in a different RFE instead. > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Use more suitible nomenclature: raw This is introducing some new, very complicated tagging scheme. I don't understand it. What is 0b011 ? ------------- PR: https://git.openjdk.org/jdk/pull/11741 From mgronlun at openjdk.org Tue Jan 3 13:37:55 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 3 Jan 2023 13:37:55 GMT Subject: RFR: 8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly [v2] In-Reply-To: References: Message-ID: On Mon, 2 Jan 2023 08:38:12 GMT, Axel Boldt-Christmas wrote: >> In a similar vain to [JDK-8299089](https://bugs.openjdk.org/browse/JDK-8299089) there are different semantics for OopStorage and thread local oops. UnifiedOopRef in the jfr leakprofiler must be able to distinguish these and treat them appropriately. >> >> Testing: Running test at the moment. Has been running on the generational branch of ZGC for over three months. Not many tests exercise the leakprofiler. x86_32 has mostly been tested with GHA. >> >> Note: The accessBackend changes are only there to facilitate comparing OopLoadProxy objects directly with nullptr instead of creating and comparing with an `oop()` / `oop(NULL)`. Can be backed out of this PR and put in a different RFE instead. > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Use more suitible nomenclature: raw Changes requested by mgronlun (Reviewer). src/hotspot/share/jfr/leakprofiler/chains/rootSetClosure.cpp line 51: > 49: assert(ref != NULL, "invariant"); > 50: assert(is_aligned(ref, HeapWordSize), "invariant"); > 51: if (NativeAccess<>::oop_load(ref) != nullptr) { Why is this needed now? src/hotspot/share/jfr/leakprofiler/utilities/unifiedOopRef.hpp line 34: > 32: static const uintptr_t tag_mask = LP64_ONLY(0b111) NOT_LP64(0b011); > 33: static const uintptr_t native_tag = 0b001; > 34: static const uintptr_t raw_tag = 0b010; What is "raw", compared to "native"? src/hotspot/share/jfr/leakprofiler/utilities/unifiedOopRef.inline.hpp line 45: > 43: template<> > 44: inline uintptr_t UnifiedOopRef::addr() const { > 45: return (_value & ~tag_mask) LP64_ONLY(>> 1); Why a shift now as well? src/hotspot/share/jfr/leakprofiler/utilities/unifiedOopRef.inline.hpp line 70: > 68: LP64_ONLY(assert(((reinterpret_cast(ref)) & (1ull << 63)) == 0, "Unexpected high-order bit")); > 69: UnifiedOopRef result = { (reinterpret_cast(ref) LP64_ONLY(<< 1)) | tag }; > 70: assert(result.addr() == ref, "sanity"); This is crazy hard to read. src/hotspot/share/oops/accessBackend.hpp line 1260: > 1258: } > 1259: > 1260: inline bool operator ==(std::nullptr_t) const { why std::nullptr_t? ------------- PR: https://git.openjdk.org/jdk/pull/11741 From mgronlun at openjdk.org Tue Jan 3 13:56:51 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 3 Jan 2023 13:56:51 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v2] In-Reply-To: References: <1rK2mzryGeyI-Yak0rUIqYZBuK5zrxCYwPe9zJbjHpY=.5471f1af-f8b8-4219-ae93-8b5a5fecaad9@github.com> Message-ID: On Fri, 23 Dec 2022 14:53:38 GMT, Erik ?sterlund wrote: >> The JfrVFrameStream is used while generating stack traces for events. One of the events are the ZPage allocation event. This event is sometimes sent when ZGC is relocating. The current implementation of JfrVFrameStream uses WalkContinuation::include, which causes JFR to walk the continuation and perform GC barriers. This is problematic, since ZGC has a requirement that we never perform load barriers while running the relocation code. If we do, we might end up performing other reloctions from the the relocation code, and in some cases that causes dead locks. >> >> I propose that JFR doesn't walk the stack during stack watermark processing. This PR implements that change. This PR replaces https://github.com/openjdk/jdk/pull/11586 > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Fix release build The upshot with this solution compared to not having stacktraces for the ZPage Allocation Event is that only the relocation parts are sensitive? Other allocation sites can still have stacktraces? ------------- PR: https://git.openjdk.org/jdk/pull/11778 From mgronlun at openjdk.org Tue Jan 3 13:59:53 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 3 Jan 2023 13:59:53 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v2] In-Reply-To: References: <1rK2mzryGeyI-Yak0rUIqYZBuK5zrxCYwPe9zJbjHpY=.5471f1af-f8b8-4219-ae93-8b5a5fecaad9@github.com> Message-ID: On Fri, 23 Dec 2022 14:53:38 GMT, Erik ?sterlund wrote: >> The JfrVFrameStream is used while generating stack traces for events. One of the events are the ZPage allocation event. This event is sometimes sent when ZGC is relocating. The current implementation of JfrVFrameStream uses WalkContinuation::include, which causes JFR to walk the continuation and perform GC barriers. This is problematic, since ZGC has a requirement that we never perform load barriers while running the relocation code. If we do, we might end up performing other reloctions from the the relocation code, and in some cases that causes dead locks. >> >> I propose that JFR doesn't walk the stack during stack watermark processing. This PR implements that change. This PR replaces https://github.com/openjdk/jdk/pull/11586 > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Fix release build src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp line 391: > 389: > 390: bool ret = false; > 391: StackWatermarkSet::start_processing(thread, StackWatermarkKind::gc); Is this now needed unconditionally, for all threads sampled? What is the overhead of introducing it? src/hotspot/share/runtime/deoptimization.cpp line 759: > 757: // clear it to make sure JFR understands not to try and walk stacks from events > 758: // in here. > 759: DisableStackTracingMark dstm(thread); You replace the old system in Deopt, with the new formalized method? Ok. ------------- PR: https://git.openjdk.org/jdk/pull/11778 From aboldtch at openjdk.org Tue Jan 3 14:30:57 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 3 Jan 2023 14:30:57 GMT Subject: RFR: 8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly [v2] In-Reply-To: References: Message-ID: <-Vajigb2X8yHp76kYNFVh58pp8XgB0A04odj5KEIFFw=.d7b72d1c-024f-4747-9a45-f4e9656b2f6a@github.com> On Tue, 3 Jan 2023 13:32:12 GMT, Markus Gr?nlund wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: >> >> Use more suitible nomenclature: raw > > src/hotspot/share/jfr/leakprofiler/chains/rootSetClosure.cpp line 51: > >> 49: assert(ref != NULL, "invariant"); >> 50: assert(is_aligned(ref, HeapWordSize), "invariant"); >> 51: if (NativeAccess<>::oop_load(ref) != nullptr) { > > Why is this needed now? The GC requires that load barriers to access oops in native storage. Currently the raw load works on all GCs as it only checks for null and all GCs encode null as NULL. But it is semantically wrong, and will not work with generational ZGC where there exist colored null which is not encoded as NULL. > src/hotspot/share/jfr/leakprofiler/utilities/unifiedOopRef.hpp line 34: > >> 32: static const uintptr_t tag_mask = LP64_ONLY(0b111) NOT_LP64(0b011); >> 33: static const uintptr_t native_tag = 0b001; >> 34: static const uintptr_t raw_tag = 0b010; > > What is "raw", compared to "native"? Native is native storage (not in java heap) which requires GC barriers. Raw is raw storage which does not require GC barriers. This is thread local storage, such as the handle area, stack, etc. > src/hotspot/share/jfr/leakprofiler/utilities/unifiedOopRef.inline.hpp line 45: > >> 43: template<> >> 44: inline uintptr_t UnifiedOopRef::addr() const { >> 45: return (_value & ~tag_mask) LP64_ONLY(>> 1); > > Why a shift now as well? I do not remember exactly. But I think there was some ref which on 64 bit which had the third bit set. That is this assert failed: `assert((reinterpret_cast(ref) & UnifiedOopRef::tag_mask) == 0, "Unexpected low-order bits");` I have to remove the shift and test again. I think it is strange given that `ObjectAlignmentInBytes >= 8` but we added the shift for some reason. Or maybe I am just missing something obvious. > src/hotspot/share/jfr/leakprofiler/utilities/unifiedOopRef.inline.hpp line 70: > >> 68: LP64_ONLY(assert(((reinterpret_cast(ref)) & (1ull << 63)) == 0, "Unexpected high-order bit")); >> 69: UnifiedOopRef result = { (reinterpret_cast(ref) LP64_ONLY(<< 1)) | tag }; >> 70: assert(result.addr() == ref, "sanity"); > > This is crazy hard to read. Yeah. Refactoring out `reinterpret_cast(ref)` into a variable might help a bit at least. The assert just want to check that the lowest two bits are not set (the tagging does not destroy information) and that on 64 bit platforms the highest bit is not set (the shift does not destroy information). Not sure if there is a better way to express those two invariants. > src/hotspot/share/oops/accessBackend.hpp line 1260: > >> 1258: } >> 1259: >> 1260: inline bool operator ==(std::nullptr_t) const { > > why std::nullptr_t? This change is only here to facilitate being able to compare the OopLoadProxy object directly to nullptr instead of having to create and use an `oop()` / `oop(NULL)`. ------------- PR: https://git.openjdk.org/jdk/pull/11741 From jcking at openjdk.org Tue Jan 3 14:33:36 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 3 Jan 2023 14:33:36 GMT Subject: RFR: JDK-8299481: Remove metaprogramming/removePointer.hpp [v2] In-Reply-To: References: Message-ID: > Code cleanup of pre-C++11 implementations. Justin King has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge remote-tracking branch 'upstream/master' into remove-remove-pointer - Remove include Signed-off-by: Justin King - Remove metaprogramming/removePointer.hpp Signed-off-by: Justin King ------------- Changes: https://git.openjdk.org/jdk/pull/11817/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11817&range=01 Stats: 87 lines in 3 files changed: 0 ins; 87 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11817.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11817/head:pull/11817 PR: https://git.openjdk.org/jdk/pull/11817 From aboldtch at openjdk.org Tue Jan 3 14:33:52 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 3 Jan 2023 14:33:52 GMT Subject: RFR: 8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly [v2] In-Reply-To: References: Message-ID: <6XjZ4ySS1LtyfAdGRtv8rtDGFdPVEKy-npdPntq7WG4=.0b3fe15a-148f-421a-aa21-5e2ec1d0fbfa@github.com> On Tue, 3 Jan 2023 13:31:39 GMT, Markus Gr?nlund wrote: > This is introducing some new, very complicated tagging scheme. I don't understand it. What is 0b011 ? We have three storage/access types in the vm, Native, Raw, Heap. The two lower bits encode this. The only valid low bits are Heap: 0b00, Native: 0b01 and Raw: 0b10. Then each storage area can be use compressed oops or not. Which is the third bit. `0b011` would be an invalid tag. ------------- PR: https://git.openjdk.org/jdk/pull/11741 From jcking at openjdk.org Tue Jan 3 14:34:43 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 3 Jan 2023 14:34:43 GMT Subject: RFR: JDK-8299479: Remove metaprogramming/decay.hpp [v2] In-Reply-To: References: Message-ID: > Code cleanup of pre-C++11 implementations. Justin King 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 remote-tracking branch 'upstream/master' into remove-decay - Remove header Signed-off-by: Justin King - Remove include Signed-off-by: Justin King - Remove metaprogramming/decay.hpp Signed-off-by: Justin King ------------- Changes: https://git.openjdk.org/jdk/pull/11816/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11816&range=01 Stats: 62 lines in 2 files changed: 0 ins; 48 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/11816.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11816/head:pull/11816 PR: https://git.openjdk.org/jdk/pull/11816 From jcking at openjdk.org Tue Jan 3 14:36:38 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 3 Jan 2023 14:36:38 GMT Subject: RFR: JDK-8299482: Remove metaprogramming/isIntegral.hpp [v3] In-Reply-To: References: Message-ID: > Code cleanup of pre-C++11 implementations. Justin King has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge remote-tracking branch 'upstream/master' into remove-is-integral - Add missing include Signed-off-by: Justin King - Remove metaprogramming/isIntegral.hpp Signed-off-by: Justin King ------------- Changes: https://git.openjdk.org/jdk/pull/11818/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11818&range=02 Stats: 82 lines in 4 files changed: 3 ins; 65 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/11818.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11818/head:pull/11818 PR: https://git.openjdk.org/jdk/pull/11818 From mgronlun at openjdk.org Tue Jan 3 14:46:50 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 3 Jan 2023 14:46:50 GMT Subject: RFR: 8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly [v2] In-Reply-To: <-Vajigb2X8yHp76kYNFVh58pp8XgB0A04odj5KEIFFw=.d7b72d1c-024f-4747-9a45-f4e9656b2f6a@github.com> References: <-Vajigb2X8yHp76kYNFVh58pp8XgB0A04odj5KEIFFw=.d7b72d1c-024f-4747-9a45-f4e9656b2f6a@github.com> Message-ID: On Tue, 3 Jan 2023 14:27:48 GMT, Axel Boldt-Christmas wrote: >> src/hotspot/share/jfr/leakprofiler/chains/rootSetClosure.cpp line 51: >> >>> 49: assert(ref != NULL, "invariant"); >>> 50: assert(is_aligned(ref, HeapWordSize), "invariant"); >>> 51: if (NativeAccess<>::oop_load(ref) != nullptr) { >> >> Why is this needed now? > > The GC requires that load barriers to access oops in native storage. Currently the raw load works on all GCs as it only checks for null and all GCs encode null as NULL. But it is semantically wrong, and will not work with generational ZGC where there exist colored null which is not encoded as NULL. Thanks. Should not the same construct be used in RawRootClosure? Or is it not needed there because the raw references to oops are not loaded through the Access Api? ------------- PR: https://git.openjdk.org/jdk/pull/11741 From aboldtch at openjdk.org Tue Jan 3 15:01:51 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 3 Jan 2023 15:01:51 GMT Subject: RFR: 8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly [v2] In-Reply-To: References: <-Vajigb2X8yHp76kYNFVh58pp8XgB0A04odj5KEIFFw=.d7b72d1c-024f-4747-9a45-f4e9656b2f6a@github.com> Message-ID: <95corZvJwy_eGmWbfN4gf8UQl9fCQl5FqVhX_-NwEHo=.59d4aa5f-6cd7-4a82-a12a-9c48aade9690@github.com> On Tue, 3 Jan 2023 14:43:45 GMT, Markus Gr?nlund wrote: >> The GC requires that load barriers to access oops in native storage. Currently the raw load works on all GCs as it only checks for null and all GCs encode null as NULL. But it is semantically wrong, and will not work with generational ZGC where there exist colored null which is not encoded as NULL. > > Thanks. Should not the same construct be used in RawRootClosure? Or is it not needed there because the raw references to oops are not loaded through the Access Api? Raw storage has no GC barriers so a null oop there must be NULL. The RawAccess API is really only used when dealing with narrowOop or templated generic code which can be either. `RawAccess<>::oop_load(oop* ref)` will just become a `*ref`. I think I used RawAccess everywhere initially ,but @fisk thought that it should not be used for raw oop*, not sure if there were some other reason behind it than it being unnecessary / obfuscating. ------------- PR: https://git.openjdk.org/jdk/pull/11741 From eosterlund at openjdk.org Tue Jan 3 15:29:51 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 3 Jan 2023 15:29:51 GMT Subject: RFR: 8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly [v2] In-Reply-To: <-Vajigb2X8yHp76kYNFVh58pp8XgB0A04odj5KEIFFw=.d7b72d1c-024f-4747-9a45-f4e9656b2f6a@github.com> References: <-Vajigb2X8yHp76kYNFVh58pp8XgB0A04odj5KEIFFw=.d7b72d1c-024f-4747-9a45-f4e9656b2f6a@github.com> Message-ID: On Tue, 3 Jan 2023 14:28:00 GMT, Axel Boldt-Christmas wrote: >> src/hotspot/share/jfr/leakprofiler/utilities/unifiedOopRef.inline.hpp line 45: >> >>> 43: template<> >>> 44: inline uintptr_t UnifiedOopRef::addr() const { >>> 45: return (_value & ~tag_mask) LP64_ONLY(>> 1); >> >> Why a shift now as well? > > I do not remember exactly. But I think there was some ref which on 64 bit which had the third bit set. That is this assert failed: > `assert((reinterpret_cast(ref) & UnifiedOopRef::tag_mask) == 0, "Unexpected low-order bits");` > I have to remove the shift and test again. I think it is strange given that `ObjectAlignmentInBytes >= 8` but we added the shift for some reason. Or maybe I am just missing something obvious. ObjectAlignmentInBytes is 4 by default on 32 bit VMs. ------------- PR: https://git.openjdk.org/jdk/pull/11741 From eosterlund at openjdk.org Tue Jan 3 15:35:49 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 3 Jan 2023 15:35:49 GMT Subject: RFR: 8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly [v2] In-Reply-To: <95corZvJwy_eGmWbfN4gf8UQl9fCQl5FqVhX_-NwEHo=.59d4aa5f-6cd7-4a82-a12a-9c48aade9690@github.com> References: <-Vajigb2X8yHp76kYNFVh58pp8XgB0A04odj5KEIFFw=.d7b72d1c-024f-4747-9a45-f4e9656b2f6a@github.com> <95corZvJwy_eGmWbfN4gf8UQl9fCQl5FqVhX_-NwEHo=.59d4aa5f-6cd7-4a82-a12a-9c48aade9690@github.com> Message-ID: On Tue, 3 Jan 2023 14:58:46 GMT, Axel Boldt-Christmas wrote: >> Thanks. Should not the same construct be used in RawRootClosure? Or is it not needed there because the raw references to oops are not loaded through the Access Api? > > Raw storage has no GC barriers so a null oop there must be NULL. The RawAccess API is really only used when dealing with narrowOop or templated generic code which can be either. `RawAccess<>::oop_load(oop* ref)` will just become a `*ref`. I think I used RawAccess everywhere initially ,but @fisk thought that it should not be used for raw oop*, not sure if there were some other reason behind it than it being unnecessary / obfuscating. I think what I might have said is that RawAccess helps with compressed oop conversion and memory ordering sprinklings. If you don't need to do anything special with either of those and you just want a plain dereference of an oop*, then just doing a plain dereference achieves the same thing with a lot less templates. Using RawAccess can make it look like there is more to it than there really is. It's perfectly correct, but maybe just not needed and makes you scratch your head a bit when really there is nothing special to see at all. ------------- PR: https://git.openjdk.org/jdk/pull/11741 From eosterlund at openjdk.org Tue Jan 3 15:40:48 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 3 Jan 2023 15:40:48 GMT Subject: RFR: 8299072: java_lang_ref_Reference::clear_referent should be GC agnostic In-Reply-To: <6S2QZ9-NMeIQe0FUCdZlCKuWG8h_dwdFs9_sqMbJ6Ng=.4fe5ec3c-d4fc-4efe-ae19-5b9caf64a316@github.com> References: <6S2QZ9-NMeIQe0FUCdZlCKuWG8h_dwdFs9_sqMbJ6Ng=.4fe5ec3c-d4fc-4efe-ae19-5b9caf64a316@github.com> Message-ID: On Tue, 3 Jan 2023 10:11:15 GMT, Aleksey Shipilev wrote: >> The current java_lang_ref_Reference::clear_referent implementation performs a raw reference clear. That doesn't work well with upcoming GC algorithms. It should be made GC agnostic by going through the normal access API. > > Looks fine. Thanks for the review @shipilev! ------------- PR: https://git.openjdk.org/jdk/pull/11736 From mdoerr at openjdk.org Tue Jan 3 15:58:49 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 3 Jan 2023 15:58:49 GMT Subject: RFR: 8299312: Clean up BarrierSetNMethod In-Reply-To: References: Message-ID: <1km8O--i4urmIjKeFK2AT3mO0d4DoTX5RcPYC1XdD-k=.d82590fe-35d2-406f-a502-fd5bb2c145f5@github.com> On Fri, 23 Dec 2022 12:00:46 GMT, Erik ?sterlund wrote: > The terminology in BarrierSetNMethod is not crisp. In platform code we talk about a per-nmethod "guard value", but on shared level we call the same value arm value or disarm value in different contexts. But it really depends on the value whether the nmethod is disarmed or armed. We should embrace the "guard value" terminology and lift it in to the shared code level. > We also have more functionality than we need on platform level. The platform level only needs to know how to deoptimize, and how to set/get the guard value of an nmethod. The more specific functionality should be moved to the shared code and be expressed in terms of said setter/getter. With https://github.com/openjdk/jdk/commit/245f0cf4ac9dc655bfe2abb1c88c6ed1ddffd291, nmethod entry barriers are implemented on all platforms, now. The ARM32 parts should be added. (Also see failing pre-submit test.) ------------- PR: https://git.openjdk.org/jdk/pull/11774 From coleen.phillimore at oracle.com Tue Jan 3 16:06:16 2023 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 3 Jan 2023 11:06:16 -0500 Subject: CFV: New hotspot Group Member: Ron Pressler Message-ID: I hereby nominate Ron Pressler [rpressler] to Membership in the hotspot Group. Ron Pressler is the lead for the Loom project [1] and is a committer on the JDK project, including the major contribution of? JEP 425: Virtual Threads. Votes are due by January 17, 2023. Only current Members of the hotspot Group [2] are eligible to vote on this nomination.? Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Coleen Phillimore [1] https://openjdk.org/census#loom [2] https://openjdk.org/census#hotspot [3] https://openjdk.org/groups/#member-vote From coleen.phillimore at oracle.com Tue Jan 3 16:11:00 2023 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 3 Jan 2023 11:11:00 -0500 Subject: CFV: New hotspot Group Member: Ron Pressler In-Reply-To: References: Message-ID: Correcting email address. -------- Forwarded Message -------- Subject: CFV: New hotspot Group Member: Ron Pressler Date: Tue, 3 Jan 2023 11:06:16 -0500 From: coleen.phillimore at oracle.com To: hotspot-dev at openjdk.java.net I hereby nominate Ron Pressler [rpressler] to Membership in the hotspot Group. Ron Pressler is the lead for the Loom project [1] and is a committer on the JDK project, including the major contribution of JEP 425: Virtual Threads. Votes are due by January 17, 2023. Only current Members of the hotspot Group [2] are eligible to vote on this nomination.? Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Coleen Phillimore [1] https://openjdk.org/census#loom [2] https://openjdk.org/census#hotspot [3] https://openjdk.org/groups/#member-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Tue Jan 3 16:13:29 2023 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 3 Jan 2023 11:13:29 -0500 Subject: CFV: New hotspot Group Member: Ron Pressler In-Reply-To: References: Message-ID: <75aadc54-91ff-b11b-faf6-236c79d7df7d@oracle.com> Vote: yes On 1/3/23 11:11 AM, coleen.phillimore at oracle.com wrote: > Correcting email address. > > > -------- Forwarded Message -------- > Subject: CFV: New hotspot Group Member: Ron Pressler > Date: Tue, 3 Jan 2023 11:06:16 -0500 > From: coleen.phillimore at oracle.com > To: hotspot-dev at openjdk.java.net > > > > I hereby nominate Ron Pressler [rpressler] to Membership in the > hotspot Group. > > Ron Pressler is the lead for the Loom project [1] and is a committer > on the JDK project, including the major contribution of? JEP 425: > Virtual Threads. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#loom > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Tue Jan 3 16:18:44 2023 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 3 Jan 2023 11:18:44 -0500 Subject: CFV: New OpenJDK hotspot Group Member: Robbin Ehn Message-ID: <7652c110-0767-bf12-dd32-8cde03ba6fc7@oracle.com> I hereby nominate Robbin Ehn [rehn] to Membership in the hotspot Group. Robbin Ehn is an OpenJDK Reviewer and a member of the HotSpot runtime team at Oracle.? He has contributed a concurrent hash table, synchronization performance improvements and bug fixes to the HotSpot code base. Votes are due by January 17, 2023. Only current Members of the hotspot Group [1] are eligible to vote on this nomination.? Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Coleen Phillimore [1] https://openjdk.org/census#hotspot [2] https://openjdk.org/groups/#member-vote From coleen.phillimore at oracle.com Tue Jan 3 16:20:07 2023 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 3 Jan 2023 11:20:07 -0500 Subject: CFV: New OpenJDK hotspot Group Member: Patricio Chilano Mateo Message-ID: I hereby nominate Patricio Chilano Mateo [pchilomate] to Membership in the hotspot Group. Patricio is an OpenJDK Reviewer and a member of the HotSpot runtime team at Oracle. Since 2018 he has worked on improvements and bug fixes mainly in the areas of locking, safepoint synchronization, thread state transitions, and handshakes. He is currently working on Loom changes for virtual thread preemption. Votes are due by January 17, 2023. Only current Members of the hotspot Group [1] are eligible to vote on this nomination.? Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Coleen Phillimore [1] https://openjdk.org/census#hotspot [2] https://openjdk.org/groups/#member-vote From mgronlun at openjdk.org Tue Jan 3 16:21:48 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 3 Jan 2023 16:21:48 GMT Subject: RFR: 8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly [v2] In-Reply-To: <6XjZ4ySS1LtyfAdGRtv8rtDGFdPVEKy-npdPntq7WG4=.0b3fe15a-148f-421a-aa21-5e2ec1d0fbfa@github.com> References: <6XjZ4ySS1LtyfAdGRtv8rtDGFdPVEKy-npdPntq7WG4=.0b3fe15a-148f-421a-aa21-5e2ec1d0fbfa@github.com> Message-ID: On Tue, 3 Jan 2023 14:31:24 GMT, Axel Boldt-Christmas wrote: > > This is introducing some new, very complicated tagging scheme. I don't understand it. What is 0b011 ? > > We have three storage/access types in the vm, Native, Raw, Heap. The two lower bits encode this. The only valid low bits are Heap: 0b00, Native: 0b01 and Raw: 0b10. Then each storage area can be use compressed oops or not. Which is the third bit. > > `0b011` would be an invalid tag. I see now it is the mask on 32-bit. ------------- PR: https://git.openjdk.org/jdk/pull/11741 From mgronlun at openjdk.org Tue Jan 3 16:21:50 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 3 Jan 2023 16:21:50 GMT Subject: RFR: 8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly [v2] In-Reply-To: References: <-Vajigb2X8yHp76kYNFVh58pp8XgB0A04odj5KEIFFw=.d7b72d1c-024f-4747-9a45-f4e9656b2f6a@github.com> Message-ID: <-Bw1QEa8ENJ4arP1p27jW5J3scq3G6LhTOrqdr3pww4=.1e170716-a01b-4e64-952a-b9e05aefbbfb@github.com> On Tue, 3 Jan 2023 15:26:34 GMT, Erik ?sterlund wrote: >> I do not remember exactly. But I think there was some ref which on 64 bit which had the third bit set. That is this assert failed: >> `assert((reinterpret_cast(ref) & UnifiedOopRef::tag_mask) == 0, "Unexpected low-order bits");` >> I have to remove the shift and test again. I think it is strange given that `ObjectAlignmentInBytes >= 8` but we added the shift for some reason. Or maybe I am just missing something obvious. > > ObjectAlignmentInBytes is 4 by default on 32 bit VMs. @fisk Why are the shifts needed on 64-bits? ------------- PR: https://git.openjdk.org/jdk/pull/11741 From coleen.phillimore at oracle.com Tue Jan 3 16:22:11 2023 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 3 Jan 2023 11:22:11 -0500 Subject: CFV: New OpenJDK hotspot Group Member: Lois Foltan Message-ID: I hereby nominate Lois Foltan [lfoltan] to Membership in the hotspot Group. Lois is an OpenJDK Reviewer and a member of the HotSpot runtime team at Oracle. She contributed the VM support for the Module subsystem JSR 294, semantic changes in HotSpot for default methods, cleanups for signature processing, Condy support, and many bug fixes. Lois is now an engineering manager for the runtime team. Votes are due by January 17, 2023. Only current Members of the hotspot Group [1] are eligible to vote on this nomination.? Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Coleen Phillimore [1] https://openjdk.org/census#hotspot [2] https://openjdk.org/groups/#member-vot From coleen.phillimore at oracle.com Tue Jan 3 16:26:27 2023 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 3 Jan 2023 11:26:27 -0500 Subject: CFV: New OpenJDK hotspot Group Member: Frederic Parain Message-ID: <175ece63-eb89-ba46-52aa-270762e122c2@oracle.com> I hereby nominate Frederic Parain [fparain] to Membership in the hotspot Group. Frederic is an OpenJDK Committer and a member of the HotSpot runtime team at Oracle. He is an active contributor to the valhalla project [1], implementing programming models in the HotSpot code. He is also a contributor to OpenJDK since 2010, working on serviceability code, implementing the diagnostic commands framework, and rewriting Java field layout code. He is currently working on compressing c2 frames in the Loom project, and making the VM internal representation of fields extensible for valhalla support. Votes are due by January 17, 2023. Only current Members of the hotspot Group [2] are eligible to vote on this nomination.? Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Coleen Phillimore [1] https://openjdk.org/census#valhalla [2] https://openjdk.org/census#hotspot [3] https://openjdk.org/groups/#member-vote From coleen.phillimore at oracle.com Tue Jan 3 16:27:18 2023 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 3 Jan 2023 11:27:18 -0500 Subject: CFV: New OpenJDK hotspot Group Member: Serguei Spitsyn Message-ID: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> I hereby nominate Serguei Spitsyn [sspitsyn] to Membership in the hotspot Group. Serguei is an OpenJDK reviewer and a member of the HotSpot serviceability team at Oracle.? He is lead for the serviceability project [1] and a technical lead in HotSpot. He has recently implemented JVMTI support for the Loom project.? He is already member of the OpenJDK members group. Votes are due by January 17, 2023. Only current Members of the hotspot Group [2] are eligible to vote on this nomination.? Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Coleen Phillimore [1] https://openjdk.org/census#serviceability [2] https://openjdk.org/census#hotspot [3] https://openjdk.org/groups/#member-vote From xuelei at openjdk.org Tue Jan 3 16:28:54 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Tue, 3 Jan 2023 16:28:54 GMT Subject: RFR: 8299378: sprintf is deprecated in Xcode 14 [v3] In-Reply-To: References: Message-ID: > The `sprintf` is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812), but the test was not covered. The failure was [reported later](https://github.com/openjdk/jdk/pull/11115#issuecomment-1344973773), while gtest is enabled for building. > > This patch is just to make sure the building could pass. Other than that, the use of `sprintf` in other places are not touched. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: sort includes alphabetically ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11793/files - new: https://git.openjdk.org/jdk/pull/11793/files/3d5f9d43..59d43781 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11793&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11793&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11793.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11793/head:pull/11793 PR: https://git.openjdk.org/jdk/pull/11793 From xuelei at openjdk.org Tue Jan 3 16:28:56 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Tue, 3 Jan 2023 16:28:56 GMT Subject: RFR: 8299378: sprintf is deprecated in Xcode 14 [v2] In-Reply-To: References: Message-ID: On Tue, 3 Jan 2023 06:55:23 GMT, David Holmes wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> include os > > test/hotspot/gtest/utilities/test_unsigned5.cpp line 25: > >> 23: >> 24: #include "precompiled.hpp" >> 25: #include "runtime/os.hpp" > > Nit: please sort includes alphabetically Updated. Thanks for the suggestion. ------------- PR: https://git.openjdk.org/jdk/pull/11793 From coleen.phillimore at oracle.com Tue Jan 3 16:29:30 2023 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 3 Jan 2023 11:29:30 -0500 Subject: CFV: New OpenJDK hotspot Group Member: Robbin Ehn In-Reply-To: <7652c110-0767-bf12-dd32-8cde03ba6fc7@oracle.com> References: <7652c110-0767-bf12-dd32-8cde03ba6fc7@oracle.com> Message-ID: <279ac3f6-d7be-ca06-4333-64514dc6c410@oracle.com> Vote: yes On 1/3/23 11:18 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate Robbin Ehn [rehn] to Membership in the hotspot Group. > > Robbin Ehn is an OpenJDK Reviewer and a member of the HotSpot runtime > team at Oracle.? He has contributed a concurrent hash table, > synchronization performance improvements and bug fixes to the HotSpot > code base. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vote > > From coleen.phillimore at oracle.com Tue Jan 3 16:29:53 2023 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 3 Jan 2023 11:29:53 -0500 Subject: CFV: New OpenJDK hotspot Group Member: Patricio Chilano Mateo In-Reply-To: References: Message-ID: Vote: yes On 1/3/23 11:20 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo [pchilomate] to Membership in > the hotspot Group. > > Patricio is an OpenJDK Reviewer and a member of the HotSpot runtime > team at Oracle. Since 2018 he has worked on improvements and bug fixes > mainly in the areas of locking, safepoint synchronization, thread > state transitions, and handshakes. He is currently working on Loom > changes for virtual thread preemption. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vote > > From coleen.phillimore at oracle.com Tue Jan 3 16:30:17 2023 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 3 Jan 2023 11:30:17 -0500 Subject: CFV: New OpenJDK hotspot Group Member: Lois Foltan In-Reply-To: References: Message-ID: Vote: yes On 1/3/23 11:22 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate Lois Foltan [lfoltan] to Membership in the hotspot > Group. > > Lois is an OpenJDK Reviewer and a member of the HotSpot runtime team > at Oracle. She contributed the VM support for the Module subsystem JSR > 294, semantic changes in HotSpot for default methods, cleanups for > signature processing, Condy support, and many bug fixes. Lois is now > an engineering manager for the runtime team. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vot From coleen.phillimore at oracle.com Tue Jan 3 16:30:56 2023 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 3 Jan 2023 11:30:56 -0500 Subject: CFV: New OpenJDK hotspot Group Member: Frederic Parain In-Reply-To: <175ece63-eb89-ba46-52aa-270762e122c2@oracle.com> References: <175ece63-eb89-ba46-52aa-270762e122c2@oracle.com> Message-ID: Vote: yes On 1/3/23 11:26 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate Frederic Parain [fparain] to Membership in the > hotspot Group. > > Frederic is an OpenJDK Committer and a member of the HotSpot runtime > team at Oracle. He is an active contributor to the valhalla project > [1], implementing programming models in the HotSpot code. He is also a > contributor to OpenJDK since 2010, working on serviceability code, > implementing the diagnostic commands framework, and rewriting Java > field layout code. He is currently working on compressing c2 frames in > the Loom project, and making the VM internal representation of fields > extensible for valhalla support. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#valhalla > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > From coleen.phillimore at oracle.com Tue Jan 3 16:31:15 2023 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 3 Jan 2023 11:31:15 -0500 Subject: CFV: New OpenJDK hotspot Group Member: Serguei Spitsyn In-Reply-To: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> References: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> Message-ID: <633b01f5-59eb-b314-5140-7c03a28209a3@oracle.com> Vote: yes On 1/3/23 11:27 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate Serguei Spitsyn [sspitsyn] to Membership in the > hotspot Group. > > Serguei is an OpenJDK reviewer and a member of the HotSpot > serviceability team at Oracle.? He is lead for the serviceability > project [1] and a technical lead in HotSpot. He has recently > implemented JVMTI support for the Loom project.? He is already member > of the OpenJDK members group. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#serviceability > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > From vladimir.kozlov at oracle.com Tue Jan 3 16:47:52 2023 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 3 Jan 2023 16:47:52 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Serguei Spitsyn In-Reply-To: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> References: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> Message-ID: <9DF034D2-33CD-4086-B392-E1BE0B3C6972@oracle.com> Vote: yes Thanks Vladimir > On Jan 3, 2023, at 8:27 AM, coleen.phillimore at oracle.com wrote: > > ?I hereby nominate Serguei Spitsyn [sspitsyn] to Membership in the hotspot Group. > > Serguei is an OpenJDK reviewer and a member of the HotSpot serviceability team at Oracle. He is lead for the serviceability project [1] and a technical lead in HotSpot. He has recently implemented JVMTI support for the Loom project. He is already member of the OpenJDK members group. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#serviceability > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > From vladimir.kozlov at oracle.com Tue Jan 3 16:48:20 2023 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 3 Jan 2023 16:48:20 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Frederic Parain In-Reply-To: <175ece63-eb89-ba46-52aa-270762e122c2@oracle.com> References: <175ece63-eb89-ba46-52aa-270762e122c2@oracle.com> Message-ID: Vote: yes Thanks Vladimir > On Jan 3, 2023, at 8:26 AM, coleen.phillimore at oracle.com wrote: > > ?I hereby nominate Frederic Parain [fparain] to Membership in the hotspot Group. > > Frederic is an OpenJDK Committer and a member of the HotSpot runtime team at Oracle. He is an active contributor to the valhalla project [1], implementing programming models in the HotSpot code. He is also a contributor to OpenJDK since 2010, working on serviceability code, implementing the diagnostic commands framework, and rewriting Java field layout code. He is currently working on compressing c2 frames in the Loom project, and making the VM internal representation of fields extensible for valhalla support. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#valhalla > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > From vladimir.kozlov at oracle.com Tue Jan 3 16:48:37 2023 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 3 Jan 2023 16:48:37 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Lois Foltan In-Reply-To: References: Message-ID: <9F917968-ABB2-4C43-9609-3E81E831486A@oracle.com> Vote: yes Thanks Vladimir > On Jan 3, 2023, at 8:23 AM, coleen.phillimore at oracle.com wrote: > > ?I hereby nominate Lois Foltan [lfoltan] to Membership in the hotspot Group. > > Lois is an OpenJDK Reviewer and a member of the HotSpot runtime team at Oracle. She contributed the VM support for the Module subsystem JSR 294, semantic changes in HotSpot for default methods, cleanups for signature processing, Condy support, and many bug fixes. Lois is now an engineering manager for the runtime team. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vot From vladimir.kozlov at oracle.com Tue Jan 3 16:48:57 2023 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 3 Jan 2023 16:48:57 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Patricio Chilano Mateo In-Reply-To: References: Message-ID: Vote: yes Thanks Vladimir > On Jan 3, 2023, at 8:20 AM, coleen.phillimore at oracle.com wrote: > > ?I hereby nominate Patricio Chilano Mateo [pchilomate] to Membership in the hotspot Group. > > Patricio is an OpenJDK Reviewer and a member of the HotSpot runtime team at Oracle. Since 2018 he has worked on improvements and bug fixes mainly in the areas of locking, safepoint synchronization, thread state transitions, and handshakes. He is currently working on Loom changes for virtual thread preemption. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vote > > From vladimir.kozlov at oracle.com Tue Jan 3 16:49:20 2023 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 3 Jan 2023 16:49:20 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Robbin Ehn In-Reply-To: <7652c110-0767-bf12-dd32-8cde03ba6fc7@oracle.com> References: <7652c110-0767-bf12-dd32-8cde03ba6fc7@oracle.com> Message-ID: <328CA5AD-911D-42FA-8CEA-499C77FFD779@oracle.com> Vote: yes Thanks Vladimir > On Jan 3, 2023, at 8:19 AM, coleen.phillimore at oracle.com wrote: > > ?I hereby nominate Robbin Ehn [rehn] to Membership in the hotspot Group. > > Robbin Ehn is an OpenJDK Reviewer and a member of the HotSpot runtime team at Oracle. He has contributed a concurrent hash table, synchronization performance improvements and bug fixes to the HotSpot code base. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vote > > From vladimir.kozlov at oracle.com Tue Jan 3 16:50:36 2023 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 3 Jan 2023 16:50:36 +0000 Subject: CFV: New hotspot Group Member: Ron Pressler In-Reply-To: References: Message-ID: <1A907120-6C71-4C4E-B9BA-166E7F1C353F@oracle.com> Vote: yes Thanks Vladimir On Jan 3, 2023, at 8:11 AM, coleen.phillimore at oracle.com wrote: ? Correcting email address. -------- Forwarded Message -------- Subject: CFV: New hotspot Group Member: Ron Pressler Date: Tue, 3 Jan 2023 11:06:16 -0500 From: coleen.phillimore at oracle.com To: hotspot-dev at openjdk.java.net I hereby nominate Ron Pressler [rpressler] to Membership in the hotspot Group. Ron Pressler is the lead for the Loom project [1] and is a committer on the JDK project, including the major contribution of JEP 425: Virtual Threads. Votes are due by January 17, 2023. Only current Members of the hotspot Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Coleen Phillimore [1] https://openjdk.org/census#loom [2] https://openjdk.org/census#hotspot [3] https://openjdk.org/groups/#member-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus.gronlund at oracle.com Tue Jan 3 17:13:39 2023 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 3 Jan 2023 17:13:39 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Lois Foltan In-Reply-To: References: Message-ID: Vote: yes Thanks Markus -----Original Message----- From: hotspot-dev On Behalf Of coleen.phillimore at oracle.com Sent: den 3 januari 2023 17:22 To: hotspot-dev at openjdk.org Subject: CFV: New OpenJDK hotspot Group Member: Lois Foltan I hereby nominate Lois Foltan [lfoltan] to Membership in the hotspot Group. Lois is an OpenJDK Reviewer and a member of the HotSpot runtime team at Oracle. She contributed the VM support for the Module subsystem JSR 294, semantic changes in HotSpot for default methods, cleanups for signature processing, Condy support, and many bug fixes. Lois is now an engineering manager for the runtime team. Votes are due by January 17, 2023. Only current Members of the hotspot Group [1] are eligible to vote on this nomination.? Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Coleen Phillimore [1] https://openjdk.org/census#hotspot [2] https://openjdk.org/groups/#member-vot From markus.gronlund at oracle.com Tue Jan 3 17:14:10 2023 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 3 Jan 2023 17:14:10 +0000 Subject: CFV: New hotspot Group Member: Ron Pressler In-Reply-To: References: Message-ID: Vote: yes Thanks Markus -----Original Message----- From: hotspot-dev On Behalf Of coleen.phillimore at oracle.com Sent: den 3 januari 2023 17:06 To: hotspot-dev at openjdk.java.net Subject: CFV: New hotspot Group Member: Ron Pressler I hereby nominate Ron Pressler [rpressler] to Membership in the hotspot Group. Ron Pressler is the lead for the Loom project [1] and is a committer on the JDK project, including the major contribution of? JEP 425: Virtual Threads. Votes are due by January 17, 2023. Only current Members of the hotspot Group [2] are eligible to vote on this nomination.? Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Coleen Phillimore [1] https://openjdk.org/census#loom [2] https://openjdk.org/census#hotspot [3] https://openjdk.org/groups/#member-vote From markus.gronlund at oracle.com Tue Jan 3 17:14:38 2023 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 3 Jan 2023 17:14:38 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Robbin Ehn In-Reply-To: <7652c110-0767-bf12-dd32-8cde03ba6fc7@oracle.com> References: <7652c110-0767-bf12-dd32-8cde03ba6fc7@oracle.com> Message-ID: Vote: yes Thanks Markus -----Original Message----- From: hotspot-dev On Behalf Of coleen.phillimore at oracle.com Sent: den 3 januari 2023 17:19 To: hotspot-dev at openjdk.org Subject: CFV: New OpenJDK hotspot Group Member: Robbin Ehn I hereby nominate Robbin Ehn [rehn] to Membership in the hotspot Group. Robbin Ehn is an OpenJDK Reviewer and a member of the HotSpot runtime team at Oracle.? He has contributed a concurrent hash table, synchronization performance improvements and bug fixes to the HotSpot code base. Votes are due by January 17, 2023. Only current Members of the hotspot Group [1] are eligible to vote on this nomination.? Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Coleen Phillimore [1] https://openjdk.org/census#hotspot [2] https://openjdk.org/groups/#member-vote From markus.gronlund at oracle.com Tue Jan 3 17:15:10 2023 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 3 Jan 2023 17:15:10 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Patricio Chilano Mateo In-Reply-To: References: Message-ID: Vote: yes Thanks Markus -----Original Message----- From: hotspot-dev On Behalf Of coleen.phillimore at oracle.com Sent: den 3 januari 2023 17:20 To: hotspot-dev at openjdk.org Subject: CFV: New OpenJDK hotspot Group Member: Patricio Chilano Mateo I hereby nominate Patricio Chilano Mateo [pchilomate] to Membership in the hotspot Group. Patricio is an OpenJDK Reviewer and a member of the HotSpot runtime team at Oracle. Since 2018 he has worked on improvements and bug fixes mainly in the areas of locking, safepoint synchronization, thread state transitions, and handshakes. He is currently working on Loom changes for virtual thread preemption. Votes are due by January 17, 2023. Only current Members of the hotspot Group [1] are eligible to vote on this nomination.? Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Coleen Phillimore [1] https://openjdk.org/census#hotspot [2] https://openjdk.org/groups/#member-vote From markus.gronlund at oracle.com Tue Jan 3 17:15:37 2023 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 3 Jan 2023 17:15:37 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Serguei Spitsyn In-Reply-To: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> References: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> Message-ID: Vote: yes Thanks Markus -----Original Message----- From: hotspot-dev On Behalf Of coleen.phillimore at oracle.com Sent: den 3 januari 2023 17:27 To: hotspot-dev at openjdk.org Subject: CFV: New OpenJDK hotspot Group Member: Serguei Spitsyn I hereby nominate Serguei Spitsyn [sspitsyn] to Membership in the hotspot Group. Serguei is an OpenJDK reviewer and a member of the HotSpot serviceability team at Oracle.? He is lead for the serviceability project [1] and a technical lead in HotSpot. He has recently implemented JVMTI support for the Loom project.? He is already member of the OpenJDK members group. Votes are due by January 17, 2023. Only current Members of the hotspot Group [2] are eligible to vote on this nomination.? Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Coleen Phillimore [1] https://openjdk.org/census#serviceability [2] https://openjdk.org/census#hotspot [3] https://openjdk.org/groups/#member-vote From markus.gronlund at oracle.com Tue Jan 3 17:16:11 2023 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 3 Jan 2023 17:16:11 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Frederic Parain In-Reply-To: <175ece63-eb89-ba46-52aa-270762e122c2@oracle.com> References: <175ece63-eb89-ba46-52aa-270762e122c2@oracle.com> Message-ID: Vote: yes Thanks Markus -----Original Message----- From: hotspot-dev On Behalf Of coleen.phillimore at oracle.com Sent: den 3 januari 2023 17:26 To: hotspot-dev at openjdk.org Subject: CFV: New OpenJDK hotspot Group Member: Frederic Parain I hereby nominate Frederic Parain [fparain] to Membership in the hotspot Group. Frederic is an OpenJDK Committer and a member of the HotSpot runtime team at Oracle. He is an active contributor to the valhalla project [1], implementing programming models in the HotSpot code. He is also a contributor to OpenJDK since 2010, working on serviceability code, implementing the diagnostic commands framework, and rewriting Java field layout code. He is currently working on compressing c2 frames in the Loom project, and making the VM internal representation of fields extensible for valhalla support. Votes are due by January 17, 2023. Only current Members of the hotspot Group [2] are eligible to vote on this nomination.? Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Coleen Phillimore [1] https://openjdk.org/census#valhalla [2] https://openjdk.org/census#hotspot [3] https://openjdk.org/groups/#member-vote From shade at openjdk.org Tue Jan 3 17:30:49 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 3 Jan 2023 17:30:49 GMT Subject: RFR: 8294403: [REDO] make test should report only on executed tests In-Reply-To: References: Message-ID: On Tue, 3 Jan 2023 09:39:59 GMT, Aleksey Shipilev wrote: > This should help to speed up tests significantly. Currently, if we run "make test" with a subset of tests, JTReg would still read the entirety of test root to report on tests that were not run. Even with current suite of tests it gets expensive. If you add more tests to suite -- for example, mounting a large test archive like pre-generated fuzzer tests -- it starts to take a lot of time. > > The reasonable default for older jtreg is `-report:executed`. My own CI -- that has millions of tests mounted in `test/` -- was running with `JTREG="OPTIONS=-report:executed"` for years now. I think that should be the default way to run the tests in JDK tree. > > [CODETOOLS-7903323](https://bugs.openjdk.org/browse/CODETOOLS-7903323) provides a new reporting option, `-report:files`, which makes this whole business easier. This requires new jtreg. > > Motivational improvements: > > > $ time CONF=linux-x86_64-server-release make run-test TEST=gc/epsilon/TestHelloWorld.java > > # Default JDK tree > > # Baseline > real 0m9.086s > user 0m22.857s > sys 0m4.202s > > # Patched > real 0m6.406s ; +40% faster > user 0m17.156s > sys 0m3.193s > > # +100K fuzzer tests in tree > > # Baseline > real 3m1.997s > user 3m16.643s > sys 0m10.490s > > # Patched > real 0m8.919s ; 20x faster > user 0m17.904s > sys 0m4.860s > > > Additional testing: > - [x] Ad-hoc timing tests (see above) > - [x] Reproducer from [CODETOOLS-7903331](https://bugs.openjdk.org/browse/CODETOOLS-7903331) > - [x] Eyeballing the test results on passing tests with REPEAT_COUNT > 1 > - [x] Eyeballing the test results on intermittently failing tests with RETRY_COUNT > 1 This might need more exposure. ------------- PR: https://git.openjdk.org/jdk/pull/11824 From ChrisPhi at LGonQn.Org Tue Jan 3 17:31:15 2023 From: ChrisPhi at LGonQn.Org (Chris Phillips) Date: Tue, 3 Jan 2023 12:31:15 -0500 Subject: CFV: New hotspot Group Member: Ron Pressler In-Reply-To: References: Message-ID: Hi Vote: yes Cheers! Chris On 2023-01-03 11:06, coleen.phillimore at oracle.com wrote: > I hereby nominate Ron Pressler [rpressler] to Membership in the hotspot > Group. > > Ron Pressler is the lead for the Loom project [1] and is a committer on > the JDK project, including the major contribution of? JEP 425: Virtual > Threads. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#loom > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > > > From hohensee at amazon.com Tue Jan 3 17:36:36 2023 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 3 Jan 2023 17:36:36 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Serguei Spitsyn Message-ID: <620CA565-8D7B-4288-8C3E-3581E8D46AF7@amazon.com> Vote: yes ?On 1/3/23, 8:28 AM, "hotspot-dev on behalf of coleen.phillimore at oracle.com" wrote: I hereby nominate Serguei Spitsyn [sspitsyn] to Membership in the hotspot Group. Serguei is an OpenJDK reviewer and a member of the HotSpot serviceability team at Oracle. He is lead for the serviceability project [1] and a technical lead in HotSpot. He has recently implemented JVMTI support for the Loom project. He is already member of the OpenJDK members group. Votes are due by January 17, 2023. Only current Members of the hotspot Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Coleen Phillimore [1] https://openjdk.org/census#serviceability [2] https://openjdk.org/census#hotspot [3] https://openjdk.org/groups/#member-vote From hohensee at amazon.com Tue Jan 3 17:37:18 2023 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 3 Jan 2023 17:37:18 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Frederic Parain Message-ID: <13261288-1E66-454B-9722-A416DFA03FCE@amazon.com> Vote: yes ?On 1/3/23, 8:27 AM, "hotspot-dev on behalf of coleen.phillimore at oracle.com" wrote: I hereby nominate Frederic Parain [fparain] to Membership in the hotspot Group. Frederic is an OpenJDK Committer and a member of the HotSpot runtime team at Oracle. He is an active contributor to the valhalla project [1], implementing programming models in the HotSpot code. He is also a contributor to OpenJDK since 2010, working on serviceability code, implementing the diagnostic commands framework, and rewriting Java field layout code. He is currently working on compressing c2 frames in the Loom project, and making the VM internal representation of fields extensible for valhalla support. Votes are due by January 17, 2023. Only current Members of the hotspot Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Coleen Phillimore [1] https://openjdk.org/census#valhalla [2] https://openjdk.org/census#hotspot [3] https://openjdk.org/groups/#member-vote From hohensee at amazon.com Tue Jan 3 17:37:37 2023 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 3 Jan 2023 17:37:37 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Lois Foltan Message-ID: <6286D16E-7890-4363-A0B2-10FACA2EABF2@amazon.com> Vote: yes ?On 1/3/23, 8:23 AM, "hotspot-dev on behalf of coleen.phillimore at oracle.com" wrote: I hereby nominate Lois Foltan [lfoltan] to Membership in the hotspot Group. Lois is an OpenJDK Reviewer and a member of the HotSpot runtime team at Oracle. She contributed the VM support for the Module subsystem JSR 294, semantic changes in HotSpot for default methods, cleanups for signature processing, Condy support, and many bug fixes. Lois is now an engineering manager for the runtime team. Votes are due by January 17, 2023. Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Coleen Phillimore [1] https://openjdk.org/census#hotspot [2] https://openjdk.org/groups/#member-vot From hohensee at amazon.com Tue Jan 3 17:38:09 2023 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 3 Jan 2023 17:38:09 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Patricio Chilano Mateo Message-ID: <5E499386-FA51-4621-A4B3-A9C00806DF94@amazon.com> Vote: yes ?On 1/3/23, 8:21 AM, "hotspot-dev on behalf of coleen.phillimore at oracle.com" wrote: I hereby nominate Patricio Chilano Mateo [pchilomate] to Membership in the hotspot Group. Patricio is an OpenJDK Reviewer and a member of the HotSpot runtime team at Oracle. Since 2018 he has worked on improvements and bug fixes mainly in the areas of locking, safepoint synchronization, thread state transitions, and handshakes. He is currently working on Loom changes for virtual thread preemption. Votes are due by January 17, 2023. Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Coleen Phillimore [1] https://openjdk.org/census#hotspot [2] https://openjdk.org/groups/#member-vote From hohensee at amazon.com Tue Jan 3 17:38:26 2023 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 3 Jan 2023 17:38:26 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Robbin Ehn Message-ID: Vote: yes ?On 1/3/23, 8:19 AM, "hotspot-dev on behalf of coleen.phillimore at oracle.com" wrote: I hereby nominate Robbin Ehn [rehn] to Membership in the hotspot Group. Robbin Ehn is an OpenJDK Reviewer and a member of the HotSpot runtime team at Oracle. He has contributed a concurrent hash table, synchronization performance improvements and bug fixes to the HotSpot code base. Votes are due by January 17, 2023. Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Coleen Phillimore [1] https://openjdk.org/census#hotspot [2] https://openjdk.org/groups/#member-vote From james.laskey at oracle.com Tue Jan 3 17:45:38 2023 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 3 Jan 2023 17:45:38 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Lois Foltan In-Reply-To: <9F917968-ABB2-4C43-9609-3E81E831486A@oracle.com> References: <9F917968-ABB2-4C43-9609-3E81E831486A@oracle.com> Message-ID: <9409B53E-88FE-4948-862D-8E7D58CEB3A1@oracle.com> Vote: yes ? > On Jan 3, 2023, at 12:48 PM, Vladimir Kozlov wrote: > > ?Vote: yes > > Thanks > Vladimir > >> On Jan 3, 2023, at 8:23 AM, coleen.phillimore at oracle.com wrote: >> >> ?I hereby nominate Lois Foltan [lfoltan] to Membership in the hotspot Group. >> >> Lois is an OpenJDK Reviewer and a member of the HotSpot runtime team at Oracle. She contributed the VM support for the Module subsystem JSR 294, semantic changes in HotSpot for default methods, cleanups for signature processing, Condy support, and many bug fixes. Lois is now an engineering manager for the runtime team. >> >> Votes are due by January 17, 2023. >> >> Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. >> >> For Lazy Consensus voting instructions, see [2]. >> >> Coleen Phillimore >> >> [1] https://openjdk.org/census#hotspot >> [2] https://openjdk.org/groups/#member-vot From ChrisPhi at LGonQn.Org Tue Jan 3 17:45:47 2023 From: ChrisPhi at LGonQn.Org (Chris Phillips) Date: Tue, 3 Jan 2023 12:45:47 -0500 Subject: CFV: New OpenJDK hotspot Group Member: Robbin Ehn In-Reply-To: <7652c110-0767-bf12-dd32-8cde03ba6fc7@oracle.com> References: <7652c110-0767-bf12-dd32-8cde03ba6fc7@oracle.com> Message-ID: Hi Vote: yes Cheers! Chris On 2023-01-03 11:18, coleen.phillimore at oracle.com wrote: > I hereby nominate Robbin Ehn [rehn] to Membership in the hotspot Group. > > Robbin Ehn is an OpenJDK Reviewer and a member of the HotSpot runtime > team at Oracle.? He has contributed a concurrent hash table, > synchronization performance improvements and bug fixes to the HotSpot > code base. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vote > > > > From ChrisPhi at LGonQn.Org Tue Jan 3 17:54:22 2023 From: ChrisPhi at LGonQn.Org (Chris Phillips) Date: Tue, 3 Jan 2023 12:54:22 -0500 Subject: CFV: New OpenJDK hotspot Group Member: Patricio Chilano Mateo In-Reply-To: References: Message-ID: Hi Vote: yes Cheers! Chris On 2023-01-03 11:20, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo [pchilomate] to Membership in > the hotspot Group. > > Patricio is an OpenJDK Reviewer and a member of the HotSpot runtime team > at Oracle. Since 2018 he has worked on improvements and bug fixes mainly > in the areas of locking, safepoint synchronization, thread state > transitions, and handshakes. He is currently working on Loom changes for > virtual thread preemption. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vote > > > > From ChrisPhi at LGonQn.Org Tue Jan 3 17:54:54 2023 From: ChrisPhi at LGonQn.Org (Chris Phillips) Date: Tue, 3 Jan 2023 12:54:54 -0500 Subject: CFV: New OpenJDK hotspot Group Member: Lois Foltan In-Reply-To: References: Message-ID: <74a6461b-dde6-dc53-dd4b-76f10c900c2f@LGonQn.Org> Hi Vote: yes Cheers! Chris On 2023-01-03 11:22, coleen.phillimore at oracle.com wrote: > I hereby nominate Lois Foltan [lfoltan] to Membership in the hotspot Group. > > Lois is an OpenJDK Reviewer and a member of the HotSpot runtime team at > Oracle. She contributed the VM support for the Module subsystem JSR 294, > semantic changes in HotSpot for default methods, cleanups for signature > processing, Condy support, and many bug fixes. Lois is now an > engineering manager for the runtime team. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vot > > From ChrisPhi at LGonQn.Org Tue Jan 3 17:57:07 2023 From: ChrisPhi at LGonQn.Org ("Chris Phillips"@T O) Date: Tue, 3 Jan 2023 12:57:07 -0500 Subject: CFV: New OpenJDK hotspot Group Member: Serguei Spitsyn In-Reply-To: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> References: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> Message-ID: <9345f6ea-0ffc-56ff-f604-27f605900fb2@LGonQn.Org> Hi Vote: yes Cheers! Chris On 03/01/23 11:27 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate Serguei Spitsyn [sspitsyn] to Membership in the > hotspot Group. > > Serguei is an OpenJDK reviewer and a member of the HotSpot > serviceability team at Oracle. He is lead for the serviceability > project [1] and a technical lead in HotSpot. He has recently > implemented JVMTI support for the Loom project. He is already member > of the OpenJDK members group. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#serviceability > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > > > > From ChrisPhi at LGonQn.Org Tue Jan 3 17:57:33 2023 From: ChrisPhi at LGonQn.Org (Chris Phillips) Date: Tue, 3 Jan 2023 12:57:33 -0500 Subject: CFV: New OpenJDK hotspot Group Member: Frederic Parain In-Reply-To: <175ece63-eb89-ba46-52aa-270762e122c2@oracle.com> References: <175ece63-eb89-ba46-52aa-270762e122c2@oracle.com> Message-ID: <2f1d162a-5f60-2aac-b539-d6a0d41b7fb1@LGonQn.Org> Hi Vote: yes Cheers! Chris On 2023-01-03 11:26, coleen.phillimore at oracle.com wrote: > I hereby nominate Frederic Parain [fparain] to Membership in the hotspot > Group. > > Frederic is an OpenJDK Committer and a member of the HotSpot runtime > team at Oracle. He is an active contributor to the valhalla project [1], > implementing programming models in the HotSpot code. He is also a > contributor to OpenJDK since 2010, working on serviceability code, > implementing the diagnostic commands framework, and rewriting Java field > layout code. He is currently working on compressing c2 frames in the > Loom project, and making the VM internal representation of fields > extensible for valhalla support. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#valhalla > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > > > From kim.barrett at oracle.com Tue Jan 3 18:13:03 2023 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 3 Jan 2023 18:13:03 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Robbin Ehn In-Reply-To: <7652c110-0767-bf12-dd32-8cde03ba6fc7@oracle.com> References: <7652c110-0767-bf12-dd32-8cde03ba6fc7@oracle.com> Message-ID: <1EC408F6-298A-4435-A104-04BB2D00B45F@oracle.com> vote: yes > On Jan 3, 2023, at 11:18 AM, coleen.phillimore at oracle.com wrote: > > I hereby nominate Robbin Ehn [rehn] to Membership in the hotspot Group. > > Robbin Ehn is an OpenJDK Reviewer and a member of the HotSpot runtime team at Oracle. He has contributed a concurrent hash table, synchronization performance improvements and bug fixes to the HotSpot code base. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vote > > -------------- 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 kim.barrett at oracle.com Tue Jan 3 18:15:08 2023 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 3 Jan 2023 18:15:08 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Patricio Chilano Mateo In-Reply-To: References: Message-ID: <1233832F-4876-4A20-B990-FF39319DFCE6@oracle.com> vote: yes > On Jan 3, 2023, at 11:20 AM, coleen.phillimore at oracle.com wrote: > > I hereby nominate Patricio Chilano Mateo [pchilomate] to Membership in the hotspot Group. > > Patricio is an OpenJDK Reviewer and a member of the HotSpot runtime team at Oracle. Since 2018 he has worked on improvements and bug fixes mainly in the areas of locking, safepoint synchronization, thread state transitions, and handshakes. He is currently working on Loom changes for virtual thread preemption. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vote > > -------------- 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 kim.barrett at oracle.com Tue Jan 3 18:15:33 2023 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 3 Jan 2023 18:15:33 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Lois Foltan In-Reply-To: References: Message-ID: vote: yes > On Jan 3, 2023, at 11:22 AM, coleen.phillimore at oracle.com wrote: > > I hereby nominate Lois Foltan [lfoltan] to Membership in the hotspot Group. > > Lois is an OpenJDK Reviewer and a member of the HotSpot runtime team at Oracle. She contributed the VM support for the Module subsystem JSR 294, semantic changes in HotSpot for default methods, cleanups for signature processing, Condy support, and many bug fixes. Lois is now an engineering manager for the runtime team. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vot -------------- 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 kim.barrett at oracle.com Tue Jan 3 18:15:59 2023 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 3 Jan 2023 18:15:59 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Serguei Spitsyn In-Reply-To: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> References: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> Message-ID: vote: yes > On Jan 3, 2023, at 11:27 AM, coleen.phillimore at oracle.com wrote: > > I hereby nominate Serguei Spitsyn [sspitsyn] to Membership in the hotspot Group. > > Serguei is an OpenJDK reviewer and a member of the HotSpot serviceability team at Oracle. He is lead for the serviceability project [1] and a technical lead in HotSpot. He has recently implemented JVMTI support for the Loom project. He is already member of the OpenJDK members group. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#serviceability > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > -------------- 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 kim.barrett at oracle.com Tue Jan 3 18:16:19 2023 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 3 Jan 2023 18:16:19 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Frederic Parain In-Reply-To: <175ece63-eb89-ba46-52aa-270762e122c2@oracle.com> References: <175ece63-eb89-ba46-52aa-270762e122c2@oracle.com> Message-ID: <42FF0291-904F-4F64-82B3-E8BEE40BCC4B@oracle.com> vote: yes > On Jan 3, 2023, at 11:26 AM, coleen.phillimore at oracle.com wrote: > > I hereby nominate Frederic Parain [fparain] to Membership in the hotspot Group. > > Frederic is an OpenJDK Committer and a member of the HotSpot runtime team at Oracle. He is an active contributor to the valhalla project [1], implementing programming models in the HotSpot code. He is also a contributor to OpenJDK since 2010, working on serviceability code, implementing the diagnostic commands framework, and rewriting Java field layout code. He is currently working on compressing c2 frames in the Loom project, and making the VM internal representation of fields extensible for valhalla support. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#valhalla > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > -------------- 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 kim.barrett at oracle.com Tue Jan 3 18:17:53 2023 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 3 Jan 2023 18:17:53 +0000 Subject: CFV: New hotspot Group Member: Ron Pressler In-Reply-To: References: Message-ID: <54CA2529-A5C7-49EE-A509-A31ADF544E17@oracle.com> vote: yes (And please ignore the earlier vote sent from the wrong email address that is going to bounce from the list.) > On Jan 3, 2023, at 11:11 AM, coleen.phillimore at oracle.com wrote: > > Correcting email address. > > > -------- Forwarded Message -------- Subject: CFV: New hotspot Group Member: Ron Pressler Date: Tue, 3 Jan 2023 11:06:16 -0500 From: coleen.phillimore at oracle.com To: hotspot-dev at openjdk.java.net > > I hereby nominate Ron Pressler [rpressler] to Membership in the hotspot Group. > > Ron Pressler is the lead for the Loom project [1] and is a committer on the JDK project, including the major contribution of JEP 425: Virtual Threads. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#loom > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > -------------- 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 erikj at openjdk.org Tue Jan 3 18:21:48 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 3 Jan 2023 18:21:48 GMT Subject: RFR: 8294403: [REDO] make test should report only on executed tests In-Reply-To: References: Message-ID: On Tue, 3 Jan 2023 09:39:59 GMT, Aleksey Shipilev wrote: > This should help to speed up tests significantly. Currently, if we run "make test" with a subset of tests, JTReg would still read the entirety of test root to report on tests that were not run. Even with current suite of tests it gets expensive. If you add more tests to suite -- for example, mounting a large test archive like pre-generated fuzzer tests -- it starts to take a lot of time. > > The reasonable default for older jtreg is `-report:executed`. My own CI -- that has millions of tests mounted in `test/` -- was running with `JTREG="OPTIONS=-report:executed"` for years now. [CODETOOLS-7903323](https://bugs.openjdk.org/browse/CODETOOLS-7903323) provides a new reporting option, `-report:files`, which makes this whole business easier. This requires new jtreg. > > Motivational improvements: > > > $ time CONF=linux-x86_64-server-release make run-test TEST=gc/epsilon/TestHelloWorld.java > > # Default JDK tree > > # Baseline > real 0m9.086s > user 0m22.857s > sys 0m4.202s > > # Patched > real 0m6.406s ; +40% faster > user 0m17.156s > sys 0m3.193s > > # +100K fuzzer tests in tree > > # Baseline > real 3m1.997s > user 3m16.643s > sys 0m10.490s > > # Patched > real 0m8.919s ; 20x faster > user 0m17.904s > sys 0m4.860s > > > Additional testing: > - [x] Ad-hoc timing tests (see above) > - [x] Reproducer from [CODETOOLS-7903331](https://bugs.openjdk.org/browse/CODETOOLS-7903331) > - [x] Eyeballing the test results on passing tests with REPEAT_COUNT > 1 > - [x] Eyeballing the test results on intermittently failing tests with RETRY_COUNT > 1 Looks good from a build point of view. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.org/jdk/pull/11824 From coleenp at openjdk.org Tue Jan 3 18:42:44 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 3 Jan 2023 18:42:44 GMT Subject: RFR: 8299274: Add elements to resolved_references consistently Message-ID: I added a resolved_references_at and set_resolved_references_at() functions to use for accesses to the resolved_references array, except for the CDS usages. This has an assert that the element is an oop and oob checks and setting elements use a CAS consistently. These asserts seem useful for finding the bug causing https://bugs.openjdk.org/browse/JDK-8296915. Tested with tiers1-4. ------------- Commit messages: - Fix copyrights - 8299274: Add elements to resolved_references consistently Changes: https://git.openjdk.org/jdk/pull/11834/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11834&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299274 Stats: 49 lines in 8 files changed: 20 ins; 4 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/11834.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11834/head:pull/11834 PR: https://git.openjdk.org/jdk/pull/11834 From jcking at openjdk.org Tue Jan 3 19:11:11 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 3 Jan 2023 19:11:11 GMT Subject: RFR: JDK-8299479: Remove metaprogramming/decay.hpp [v3] In-Reply-To: References: Message-ID: > Code cleanup of pre-C++11 implementations. Justin King has updated the pull request incrementally with one additional commit since the last revision: Remove header Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11816/files - new: https://git.openjdk.org/jdk/pull/11816/files/131c7fdc..bfae998e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11816&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11816&range=01-02 Stats: 42 lines in 1 file changed: 0 ins; 42 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11816.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11816/head:pull/11816 PR: https://git.openjdk.org/jdk/pull/11816 From ioi.lam at oracle.com Tue Jan 3 19:11:20 2023 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 3 Jan 2023 11:11:20 -0800 Subject: CFV: New OpenJDK hotspot Group Member: Robbin Ehn In-Reply-To: <7652c110-0767-bf12-dd32-8cde03ba6fc7@oracle.com> References: <7652c110-0767-bf12-dd32-8cde03ba6fc7@oracle.com> Message-ID: <41693a46-6d49-9388-7138-b13ba9aec22b@oracle.com> vote: yes On 1/3/2023 8:18 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate Robbin Ehn [rehn] to Membership in the hotspot Group. > > Robbin Ehn is an OpenJDK Reviewer and a member of the HotSpot runtime > team at Oracle.? He has contributed a concurrent hash table, > synchronization performance improvements and bug fixes to the HotSpot > code base. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vote > > From ioi.lam at oracle.com Tue Jan 3 19:11:27 2023 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 3 Jan 2023 11:11:27 -0800 Subject: CFV: New OpenJDK hotspot Group Member: Patricio Chilano Mateo In-Reply-To: References: Message-ID: <4d664e2d-5aa7-a0a6-555e-4c3cd62de171@oracle.com> vote: yes On 1/3/2023 8:20 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo [pchilomate] to Membership in > the hotspot Group. > > Patricio is an OpenJDK Reviewer and a member of the HotSpot runtime > team at Oracle. Since 2018 he has worked on improvements and bug fixes > mainly in the areas of locking, safepoint synchronization, thread > state transitions, and handshakes. He is currently working on Loom > changes for virtual thread preemption. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vote > > From ioi.lam at oracle.com Tue Jan 3 19:11:35 2023 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 3 Jan 2023 11:11:35 -0800 Subject: CFV: New OpenJDK hotspot Group Member: Lois Foltan In-Reply-To: References: Message-ID: vote: yes On 1/3/2023 8:22 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate Lois Foltan [lfoltan] to Membership in the hotspot > Group. > > Lois is an OpenJDK Reviewer and a member of the HotSpot runtime team > at Oracle. She contributed the VM support for the Module subsystem JSR > 294, semantic changes in HotSpot for default methods, cleanups for > signature processing, Condy support, and many bug fixes. Lois is now > an engineering manager for the runtime team. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vot From ioi.lam at oracle.com Tue Jan 3 19:11:43 2023 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 3 Jan 2023 11:11:43 -0800 Subject: CFV: New OpenJDK hotspot Group Member: Serguei Spitsyn In-Reply-To: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> References: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> Message-ID: <665a0291-795c-f70c-6e04-acd3d0ab050b@oracle.com> vote: yes On 1/3/2023 8:27 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate Serguei Spitsyn [sspitsyn] to Membership in the > hotspot Group. > > Serguei is an OpenJDK reviewer and a member of the HotSpot > serviceability team at Oracle.? He is lead for the serviceability > project [1] and a technical lead in HotSpot. He has recently > implemented JVMTI support for the Loom project.? He is already member > of the OpenJDK members group. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#serviceability > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > From ioi.lam at oracle.com Tue Jan 3 19:11:50 2023 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 3 Jan 2023 11:11:50 -0800 Subject: CFV: New OpenJDK hotspot Group Member: Frederic Parain In-Reply-To: <175ece63-eb89-ba46-52aa-270762e122c2@oracle.com> References: <175ece63-eb89-ba46-52aa-270762e122c2@oracle.com> Message-ID: <6075ff82-ee58-0ac6-90e4-a4b334e15cd1@oracle.com> vote: yes On 1/3/2023 8:26 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate Frederic Parain [fparain] to Membership in the > hotspot Group. > > Frederic is an OpenJDK Committer and a member of the HotSpot runtime > team at Oracle. He is an active contributor to the valhalla project > [1], implementing programming models in the HotSpot code. He is also a > contributor to OpenJDK since 2010, working on serviceability code, > implementing the diagnostic commands framework, and rewriting Java > field layout code. He is currently working on compressing c2 frames in > the Loom project, and making the VM internal representation of fields > extensible for valhalla support. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#valhalla > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > From jcking at openjdk.org Tue Jan 3 19:12:23 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 3 Jan 2023 19:12:23 GMT Subject: RFR: JDK-8299482: Remove metaprogramming/isIntegral.hpp [v4] In-Reply-To: References: Message-ID: > Code cleanup of pre-C++11 implementations. Justin King has updated the pull request incrementally with one additional commit since the last revision: Remove header Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11818/files - new: https://git.openjdk.org/jdk/pull/11818/files/49fe7030..87b41e14 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11818&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11818&range=02-03 Stats: 59 lines in 1 file changed: 0 ins; 59 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11818.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11818/head:pull/11818 PR: https://git.openjdk.org/jdk/pull/11818 From jcking at openjdk.org Tue Jan 3 19:14:55 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 3 Jan 2023 19:14:55 GMT Subject: RFR: JDK-8299479: Remove metaprogramming/decay.hpp [v3] In-Reply-To: References: Message-ID: On Tue, 3 Jan 2023 19:11:11 GMT, Justin King wrote: >> Code cleanup of pre-C++11 implementations. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Remove header > > Signed-off-by: Justin King Forgot to remove the actual header apparently, updated. ------------- PR: https://git.openjdk.org/jdk/pull/11816 From jcking at openjdk.org Tue Jan 3 19:14:53 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 3 Jan 2023 19:14:53 GMT Subject: RFR: JDK-8299482: Remove metaprogramming/isIntegral.hpp [v3] In-Reply-To: References: Message-ID: On Tue, 3 Jan 2023 14:36:38 GMT, Justin King wrote: >> Code cleanup of pre-C++11 implementations. > > Justin King has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge remote-tracking branch 'upstream/master' into remove-is-integral > - Add missing include > > Signed-off-by: Justin King > - Remove metaprogramming/isIntegral.hpp > > Signed-off-by: Justin King Forgot to remove the actual header apparently, updated. ------------- PR: https://git.openjdk.org/jdk/pull/11818 From duke at openjdk.org Tue Jan 3 19:41:01 2023 From: duke at openjdk.org (duke) Date: Tue, 3 Jan 2023 19:41:01 GMT Subject: Withdrawn: 8295060: Port PrintDeoptimizationDetails to UL In-Reply-To: References: Message-ID: On Tue, 11 Oct 2022 09:21:46 GMT, Johan Sj?len wrote: > Hi! > > This PR ports PrintDeoptimizationDetails to UL by mapping its output to debug level with tag deoptimization. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/10645 From jcking at openjdk.org Tue Jan 3 19:42:27 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 3 Jan 2023 19:42:27 GMT Subject: RFR: JDK-8299554: Remove EnableIf from metaprogramming/enableIf.hpp Message-ID: <4VZUOmguEjK6C8NEMI3KrS_E5HNU-G1H-h8MJty2mlY=.2aa0c645-1695-45ee-b53d-f701772884d8@github.com> As the title says, remove `EnableIf` type alias from `metaprogramming/enableIf.hpp` leaving only `ENABLE_IF` and `ENABLE_IF_SDEFN`. ------------- Commit messages: - Remove EnableIf from metaprogramming/enableIf.hpp Changes: https://git.openjdk.org/jdk/pull/11835/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11835&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299554 Stats: 168 lines in 7 files changed: 6 ins; 5 del; 157 mod Patch: https://git.openjdk.org/jdk/pull/11835.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11835/head:pull/11835 PR: https://git.openjdk.org/jdk/pull/11835 From jcking at openjdk.org Tue Jan 3 19:44:49 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 3 Jan 2023 19:44:49 GMT Subject: RFR: JDK-8299554: Remove EnableIf from metaprogramming/enableIf.hpp In-Reply-To: <4VZUOmguEjK6C8NEMI3KrS_E5HNU-G1H-h8MJty2mlY=.2aa0c645-1695-45ee-b53d-f701772884d8@github.com> References: <4VZUOmguEjK6C8NEMI3KrS_E5HNU-G1H-h8MJty2mlY=.2aa0c645-1695-45ee-b53d-f701772884d8@github.com> Message-ID: On Tue, 3 Jan 2023 19:34:26 GMT, Justin King wrote: > As the title says, remove `EnableIf` type alias from `metaprogramming/enableIf.hpp` leaving only `ENABLE_IF` and `ENABLE_IF_SDEFN`. @kimbarrett Cleanup EnableIf, but leave ENABLE_IF and ENABLE_IF_SDEFN as discussed. Also switched to `std::enable_if_t`. ------------- PR: https://git.openjdk.org/jdk/pull/11835 From kbarrett at openjdk.org Tue Jan 3 19:44:50 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 3 Jan 2023 19:44:50 GMT Subject: RFR: JDK-8299479: Remove metaprogramming/decay.hpp [v3] In-Reply-To: References: Message-ID: On Tue, 3 Jan 2023 19:11:11 GMT, Justin King wrote: >> Code cleanup of pre-C++11 implementations. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Remove header > > Signed-off-by: Justin King Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/11816 From iklam at openjdk.org Tue Jan 3 20:10:49 2023 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 3 Jan 2023 20:10:49 GMT Subject: RFR: 8299274: Add elements to resolved_references consistently In-Reply-To: References: Message-ID: On Tue, 3 Jan 2023 18:35:20 GMT, Coleen Phillimore wrote: > I added a resolved_references_at and set_resolved_references_at() functions to use for accesses to the resolved_references array, except for the CDS usages. This has an assert that the element is an oop and oob checks and setting elements use a CAS consistently. > These asserts seem useful for finding the bug causing https://bugs.openjdk.org/browse/JDK-8296915. > Tested with tiers1-4. Looks good to me. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.org/jdk/pull/11834 From coleenp at openjdk.org Tue Jan 3 20:54:48 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 3 Jan 2023 20:54:48 GMT Subject: RFR: 8299274: Add elements to resolved_references consistently In-Reply-To: References: Message-ID: On Tue, 3 Jan 2023 18:35:20 GMT, Coleen Phillimore wrote: > I added a resolved_references_at and set_resolved_references_at() functions to use for accesses to the resolved_references array, except for the CDS usages. This has an assert that the element is an oop and oob checks and setting elements use a CAS consistently. > These asserts seem useful for finding the bug causing https://bugs.openjdk.org/browse/JDK-8296915. > Tested with tiers1-4. Thanks, Ioi. ------------- PR: https://git.openjdk.org/jdk/pull/11834 From kbarrett at openjdk.org Tue Jan 3 21:40:50 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 3 Jan 2023 21:40:50 GMT Subject: RFR: JDK-8299554: Remove EnableIf from metaprogramming/enableIf.hpp In-Reply-To: References: <4VZUOmguEjK6C8NEMI3KrS_E5HNU-G1H-h8MJty2mlY=.2aa0c645-1695-45ee-b53d-f701772884d8@github.com> Message-ID: On Tue, 3 Jan 2023 19:42:07 GMT, Justin King wrote: > @kimbarrett Cleanup EnableIf, but leave ENABLE_IF and ENABLE_IF_SDEFN as discussed. Also switched to `std::enable_if_t`. My suggestion here: https://github.com/openjdk/jdk/pull/11794#pullrequestreview-1231289245 was to leave this one alone. I think (pretty nearly) all current uses of EnableIf would be better handled by refactoring to take advantage of C++17 if-constexpr. I think there's little point to this intermediate change if C++17 support is coming (which I'm hopeful that it is). ------------- PR: https://git.openjdk.org/jdk/pull/11835 From jcking at openjdk.org Tue Jan 3 21:55:48 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 3 Jan 2023 21:55:48 GMT Subject: RFR: JDK-8299554: Remove EnableIf from metaprogramming/enableIf.hpp In-Reply-To: References: <4VZUOmguEjK6C8NEMI3KrS_E5HNU-G1H-h8MJty2mlY=.2aa0c645-1695-45ee-b53d-f701772884d8@github.com> Message-ID: On Tue, 3 Jan 2023 21:38:27 GMT, Kim Barrett wrote: >> @kimbarrett Cleanup EnableIf, but leave ENABLE_IF and ENABLE_IF_SDEFN as discussed. Also switched to `std::enable_if_t`. > >> @kimbarrett Cleanup EnableIf, but leave ENABLE_IF and ENABLE_IF_SDEFN as discussed. Also switched to `std::enable_if_t`. > > My suggestion here: https://github.com/openjdk/jdk/pull/11794#pullrequestreview-1231289245 > was to leave this one alone. I think (pretty nearly) all current uses of EnableIf would be better handled by refactoring > to take advantage of C++17 if-constexpr. I think there's little point to this intermediate change if C++17 support is > coming (which I'm hopeful that it is). > > @kimbarrett Cleanup EnableIf, but leave ENABLE_IF and ENABLE_IF_SDEFN as discussed. Also switched to `std::enable_if_t`. > > My suggestion here: [#11794 (review)](https://github.com/openjdk/jdk/pull/11794#pullrequestreview-1231289245) was to leave this one alone. I think (pretty nearly) all current uses of EnableIf would be better handled by refactoring to take advantage of C++17 if-constexpr. I think there's little point to this intermediate change if C++17 support is coming (which I'm hopeful that it is). Rewriting to use `if constexpr` is more involved than a simple replace. This is meant to just stop the bleeding and remove the alias. ------------- PR: https://git.openjdk.org/jdk/pull/11835 From vladimir.x.ivanov at oracle.com Tue Jan 3 22:16:39 2023 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 3 Jan 2023 14:16:39 -0800 Subject: CFV: New OpenJDK hotspot Group Member: Lois Foltan In-Reply-To: References: Message-ID: Vote: yes Best regards, Vladimir Ivanov On 1/3/23 08:22, coleen.phillimore at oracle.com wrote: > I hereby nominate Lois Foltan [lfoltan] to Membership in the hotspot Group. From vladimir.x.ivanov at oracle.com Tue Jan 3 22:17:11 2023 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 3 Jan 2023 14:17:11 -0800 Subject: CFV: New OpenJDK hotspot Group Member: Serguei Spitsyn In-Reply-To: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> References: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> Message-ID: Vote: yes Best regards, Vladimir Ivanov On 1/3/23 08:27, coleen.phillimore at oracle.com wrote: > I hereby nominate Serguei Spitsyn [sspitsyn] to Membership in the > hotspot Group. From vladimir.x.ivanov at oracle.com Tue Jan 3 22:17:23 2023 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 3 Jan 2023 14:17:23 -0800 Subject: CFV: New OpenJDK hotspot Group Member: Frederic Parain In-Reply-To: <175ece63-eb89-ba46-52aa-270762e122c2@oracle.com> References: <175ece63-eb89-ba46-52aa-270762e122c2@oracle.com> Message-ID: <5021b263-fc59-249d-b9d7-943d2c5ebd2c@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 1/3/23 08:26, coleen.phillimore at oracle.com wrote: > I hereby nominate Frederic Parain [fparain] to Membership in the hotspot > Group. From vladimir.x.ivanov at oracle.com Tue Jan 3 22:17:45 2023 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 3 Jan 2023 14:17:45 -0800 Subject: CFV: New OpenJDK hotspot Group Member: Patricio Chilano Mateo In-Reply-To: References: Message-ID: <07a2a015-735c-6ba9-08b9-ef646ea571dd@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 1/3/23 08:20, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo [pchilomate] to Membership in > the hotspot Group. From kevin.walls at oracle.com Tue Jan 3 22:18:13 2023 From: kevin.walls at oracle.com (Kevin Walls) Date: Tue, 3 Jan 2023 22:18:13 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Serguei Spitsyn In-Reply-To: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> References: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> Message-ID: Vote: yes -----Original Message----- From: hotspot-dev On Behalf Of coleen.phillimore at oracle.com Sent: 03 January 2023 16:27 To: hotspot-dev at openjdk.org Subject: CFV: New OpenJDK hotspot Group Member: Serguei Spitsyn From kevin.walls at oracle.com Tue Jan 3 22:18:27 2023 From: kevin.walls at oracle.com (Kevin Walls) Date: Tue, 3 Jan 2023 22:18:27 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Frederic Parain In-Reply-To: <175ece63-eb89-ba46-52aa-270762e122c2@oracle.com> References: <175ece63-eb89-ba46-52aa-270762e122c2@oracle.com> Message-ID: Vote: yes -----Original Message----- From: hotspot-dev On Behalf Of coleen.phillimore at oracle.com Sent: 03 January 2023 16:26 To: hotspot-dev at openjdk.org Subject: CFV: New OpenJDK hotspot Group Member: Frederic Parain From kevin.walls at oracle.com Tue Jan 3 22:18:40 2023 From: kevin.walls at oracle.com (Kevin Walls) Date: Tue, 3 Jan 2023 22:18:40 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Lois Foltan In-Reply-To: References: Message-ID: Vote: yes -----Original Message----- From: hotspot-dev On Behalf Of coleen.phillimore at oracle.com Sent: 03 January 2023 16:22 To: hotspot-dev at openjdk.org Subject: CFV: New OpenJDK hotspot Group Member: Lois Foltan From kevin.walls at oracle.com Tue Jan 3 22:19:11 2023 From: kevin.walls at oracle.com (Kevin Walls) Date: Tue, 3 Jan 2023 22:19:11 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Patricio Chilano Mateo In-Reply-To: References: Message-ID: Vote: yes -----Original Message----- From: hotspot-dev On Behalf Of coleen.phillimore at oracle.com Sent: 03 January 2023 16:20 To: hotspot-dev at openjdk.org Subject: CFV: New OpenJDK hotspot Group Member: Patricio Chilano Mateo From kevin.walls at oracle.com Tue Jan 3 22:19:44 2023 From: kevin.walls at oracle.com (Kevin Walls) Date: Tue, 3 Jan 2023 22:19:44 +0000 Subject: CFV: New hotspot Group Member: Ron Pressler In-Reply-To: References: Message-ID: Vote: yes From: hotspot-dev On Behalf Of coleen.phillimore at oracle.com Sent: 03 January 2023 16:11 To: hotspot-dev at openjdk.org Subject: CFV: New hotspot Group Member: Ron Pressler -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.x.ivanov at oracle.com Tue Jan 3 22:19:20 2023 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 3 Jan 2023 14:19:20 -0800 Subject: CFV: New OpenJDK hotspot Group Member: Robbin Ehn In-Reply-To: <7652c110-0767-bf12-dd32-8cde03ba6fc7@oracle.com> References: <7652c110-0767-bf12-dd32-8cde03ba6fc7@oracle.com> Message-ID: <5dce4bb9-eb14-73f1-aaf1-d2860a0a81b0@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 1/3/23 08:18, coleen.phillimore at oracle.com wrote: > I hereby nominate Robbin Ehn [rehn] to Membership in the hotspot Group. From vladimir.x.ivanov at oracle.com Tue Jan 3 22:18:25 2023 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 3 Jan 2023 14:18:25 -0800 Subject: CFV: New hotspot Group Member: Ron Pressler In-Reply-To: References: Message-ID: <6580c278-0e73-037f-6afb-f77be5bc917a@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 1/3/23 08:06, coleen.phillimore at oracle.com wrote: > I hereby nominate Ron Pressler [rpressler] to Membership in the hotspot > Group. From calvin.cheung at oracle.com Tue Jan 3 22:29:34 2023 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Tue, 3 Jan 2023 14:29:34 -0800 Subject: CFV: New OpenJDK hotspot Group Member: Serguei Spitsyn In-Reply-To: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> References: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> Message-ID: <1076defe-5e80-3ddc-1e34-b959be21a7c7@oracle.com> vote: yes On 1/3/23 8:27 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate Serguei Spitsyn [sspitsyn] to Membership in the > hotspot Group. > > Serguei is an OpenJDK reviewer and a member of the HotSpot > serviceability team at Oracle.? He is lead for the serviceability > project [1] and a technical lead in HotSpot. He has recently > implemented JVMTI support for the Loom project.? He is already member > of the OpenJDK members group. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#serviceability > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > From calvin.cheung at oracle.com Tue Jan 3 22:29:51 2023 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Tue, 3 Jan 2023 14:29:51 -0800 Subject: CFV: New OpenJDK hotspot Group Member: Frederic Parain In-Reply-To: <175ece63-eb89-ba46-52aa-270762e122c2@oracle.com> References: <175ece63-eb89-ba46-52aa-270762e122c2@oracle.com> Message-ID: <0b34c6db-a35f-57e7-238a-34933f3f314d@oracle.com> vote: yes On 1/3/23 8:26 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate Frederic Parain [fparain] to Membership in the > hotspot Group. > > Frederic is an OpenJDK Committer and a member of the HotSpot runtime > team at Oracle. He is an active contributor to the valhalla project > [1], implementing programming models in the HotSpot code. He is also a > contributor to OpenJDK since 2010, working on serviceability code, > implementing the diagnostic commands framework, and rewriting Java > field layout code. He is currently working on compressing c2 frames in > the Loom project, and making the VM internal representation of fields > extensible for valhalla support. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#valhalla > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > From calvin.cheung at oracle.com Tue Jan 3 22:30:36 2023 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Tue, 3 Jan 2023 14:30:36 -0800 Subject: CFV: New OpenJDK hotspot Group Member: Lois Foltan In-Reply-To: References: Message-ID: vote: yes On 1/3/23 8:22 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate Lois Foltan [lfoltan] to Membership in the hotspot > Group. > > Lois is an OpenJDK Reviewer and a member of the HotSpot runtime team > at Oracle. She contributed the VM support for the Module subsystem JSR > 294, semantic changes in HotSpot for default methods, cleanups for > signature processing, Condy support, and many bug fixes. Lois is now > an engineering manager for the runtime team. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vot From calvin.cheung at oracle.com Tue Jan 3 22:31:07 2023 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Tue, 3 Jan 2023 14:31:07 -0800 Subject: CFV: New OpenJDK hotspot Group Member: Patricio Chilano Mateo In-Reply-To: References: Message-ID: vote: yes On 1/3/23 8:20 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo [pchilomate] to Membership in > the hotspot Group. > > Patricio is an OpenJDK Reviewer and a member of the HotSpot runtime > team at Oracle. Since 2018 he has worked on improvements and bug fixes > mainly in the areas of locking, safepoint synchronization, thread > state transitions, and handshakes. He is currently working on Loom > changes for virtual thread preemption. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vote > > From calvin.cheung at oracle.com Tue Jan 3 22:31:45 2023 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Tue, 3 Jan 2023 14:31:45 -0800 Subject: CFV: New OpenJDK hotspot Group Member: Robbin Ehn In-Reply-To: <7652c110-0767-bf12-dd32-8cde03ba6fc7@oracle.com> References: <7652c110-0767-bf12-dd32-8cde03ba6fc7@oracle.com> Message-ID: <29b05e3a-c9f6-086c-aa8e-13a382d6e3e9@oracle.com> vote: yes On 1/3/23 8:18 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate Robbin Ehn [rehn] to Membership in the hotspot Group. > > Robbin Ehn is an OpenJDK Reviewer and a member of the HotSpot runtime > team at Oracle.? He has contributed a concurrent hash table, > synchronization performance improvements and bug fixes to the HotSpot > code base. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vote > > From calvin.cheung at oracle.com Tue Jan 3 22:33:49 2023 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Tue, 3 Jan 2023 14:33:49 -0800 Subject: CFV: New hotspot Group Member: Ron Pressler In-Reply-To: References: Message-ID: <7ff36516-74ee-b8f5-b8ae-dc78ff69136a@oracle.com> vote: yes On 1/3/23 8:06 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate Ron Pressler [rpressler] to Membership in the > hotspot Group. > > Ron Pressler is the lead for the Loom project [1] and is a committer > on the JDK project, including the major contribution of JEP 425: > Virtual Threads. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#loom > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > From xuelei at openjdk.org Tue Jan 3 22:47:53 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Tue, 3 Jan 2023 22:47:53 GMT Subject: Integrated: 8299378: sprintf is deprecated in Xcode 14 In-Reply-To: References: Message-ID: On Wed, 28 Dec 2022 05:52:27 GMT, Xue-Lei Andrew Fan wrote: > The `sprintf` is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812), but the test was not covered. The failure was [reported later](https://github.com/openjdk/jdk/pull/11115#issuecomment-1344973773), while gtest is enabled for building. > > This patch is just to make sure the building could pass. Other than that, the use of `sprintf` in other places are not touched. This pull request has now been integrated. Changeset: 38cfc591 Author: Xue-Lei Andrew Fan URL: https://git.openjdk.org/jdk/commit/38cfc591725de478879266584280562f0ba4b42f Stats: 6 lines in 3 files changed: 2 ins; 0 del; 4 mod 8299378: sprintf is deprecated in Xcode 14 Reviewed-by: kbarrett, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/11793 From jcking at openjdk.org Tue Jan 3 23:42:25 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 3 Jan 2023 23:42:25 GMT Subject: RFR: JDK-8299554: Remove EnableIf from metaprogramming/enableIf.hpp [v2] In-Reply-To: <4VZUOmguEjK6C8NEMI3KrS_E5HNU-G1H-h8MJty2mlY=.2aa0c645-1695-45ee-b53d-f701772884d8@github.com> References: <4VZUOmguEjK6C8NEMI3KrS_E5HNU-G1H-h8MJty2mlY=.2aa0c645-1695-45ee-b53d-f701772884d8@github.com> Message-ID: > As the title says, remove `EnableIf` type alias from `metaprogramming/enableIf.hpp` leaving only `ENABLE_IF` and `ENABLE_IF_SDEFN`. Justin King has updated the pull request incrementally with one additional commit since the last revision: s/td/std Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11835/files - new: https://git.openjdk.org/jdk/pull/11835/files/04d84346..a86a30c4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11835&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11835&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11835.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11835/head:pull/11835 PR: https://git.openjdk.org/jdk/pull/11835 From jcking at openjdk.org Wed Jan 4 00:33:01 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 4 Jan 2023 00:33:01 GMT Subject: RFR: JDK-8299554: Remove EnableIf from metaprogramming/enableIf.hpp [v3] In-Reply-To: <4VZUOmguEjK6C8NEMI3KrS_E5HNU-G1H-h8MJty2mlY=.2aa0c645-1695-45ee-b53d-f701772884d8@github.com> References: <4VZUOmguEjK6C8NEMI3KrS_E5HNU-G1H-h8MJty2mlY=.2aa0c645-1695-45ee-b53d-f701772884d8@github.com> Message-ID: > As the title says, remove `EnableIf` type alias from `metaprogramming/enableIf.hpp` leaving only `ENABLE_IF` and `ENABLE_IF_SDEFN`. Justin King has updated the pull request incrementally with one additional commit since the last revision: s/::type/ Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11835/files - new: https://git.openjdk.org/jdk/pull/11835/files/a86a30c4..46d03252 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11835&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11835&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11835.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11835/head:pull/11835 PR: https://git.openjdk.org/jdk/pull/11835 From david.holmes at oracle.com Wed Jan 4 01:05:36 2023 From: david.holmes at oracle.com (David Holmes) Date: Wed, 4 Jan 2023 11:05:36 +1000 Subject: CFV: New hotspot Group Member: Ron Pressler In-Reply-To: References: Message-ID: <95164a20-1017-e337-5e24-c393a1f61bd5@oracle.com> Vote: yes David On 4/01/2023 2:06 am, coleen.phillimore at oracle.com wrote: > I hereby nominate Ron Pressler [rpressler] to Membership in the hotspot > Group. > > Ron Pressler is the lead for the Loom project [1] and is a committer on > the JDK project, including the major contribution of? JEP 425: Virtual > Threads. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#loom > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > From david.holmes at oracle.com Wed Jan 4 01:08:31 2023 From: david.holmes at oracle.com (David Holmes) Date: Wed, 4 Jan 2023 11:08:31 +1000 Subject: CFV: New OpenJDK hotspot Group Member: Frederic Parain In-Reply-To: <175ece63-eb89-ba46-52aa-270762e122c2@oracle.com> References: <175ece63-eb89-ba46-52aa-270762e122c2@oracle.com> Message-ID: <94525576-df3f-284a-b334-050b90a7b9f4@oracle.com> Vote: yes David On 4/01/2023 2:26 am, coleen.phillimore at oracle.com wrote: > I hereby nominate Frederic Parain [fparain] to Membership in the hotspot > Group. > > Frederic is an OpenJDK Committer and a member of the HotSpot runtime > team at Oracle. He is an active contributor to the valhalla project [1], > implementing programming models in the HotSpot code. He is also a > contributor to OpenJDK since 2010, working on serviceability code, > implementing the diagnostic commands framework, and rewriting Java field > layout code. He is currently working on compressing c2 frames in the > Loom project, and making the VM internal representation of fields > extensible for valhalla support. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#valhalla > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > From david.holmes at oracle.com Wed Jan 4 01:12:08 2023 From: david.holmes at oracle.com (David Holmes) Date: Wed, 4 Jan 2023 11:12:08 +1000 Subject: CFV: New OpenJDK hotspot Group Member: Lois Foltan In-Reply-To: References: Message-ID: <2b068664-0ec2-317a-7489-07849db5b5ac@oracle.com> Vote: yes David On 4/01/2023 2:22 am, coleen.phillimore at oracle.com wrote: > I hereby nominate Lois Foltan [lfoltan] to Membership in the hotspot Group. > > Lois is an OpenJDK Reviewer and a member of the HotSpot runtime team at > Oracle. She contributed the VM support for the Module subsystem JSR 294, > semantic changes in HotSpot for default methods, cleanups for signature > processing, Condy support, and many bug fixes. Lois is now an > engineering manager for the runtime team. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vot From david.holmes at oracle.com Wed Jan 4 01:12:21 2023 From: david.holmes at oracle.com (David Holmes) Date: Wed, 4 Jan 2023 11:12:21 +1000 Subject: CFV: New OpenJDK hotspot Group Member: Patricio Chilano Mateo In-Reply-To: References: Message-ID: <671ec4f1-089e-2914-e208-0a8e64f39380@oracle.com> Vote: yes David On 4/01/2023 2:20 am, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo [pchilomate] to Membership in > the hotspot Group. > > Patricio is an OpenJDK Reviewer and a member of the HotSpot runtime team > at Oracle. Since 2018 he has worked on improvements and bug fixes mainly > in the areas of locking, safepoint synchronization, thread state > transitions, and handshakes. He is currently working on Loom changes for > virtual thread preemption. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vote > > From david.holmes at oracle.com Wed Jan 4 01:12:38 2023 From: david.holmes at oracle.com (David Holmes) Date: Wed, 4 Jan 2023 11:12:38 +1000 Subject: CFV: New OpenJDK hotspot Group Member: Robbin Ehn In-Reply-To: <7652c110-0767-bf12-dd32-8cde03ba6fc7@oracle.com> References: <7652c110-0767-bf12-dd32-8cde03ba6fc7@oracle.com> Message-ID: Vote: yes David On 4/01/2023 2:18 am, coleen.phillimore at oracle.com wrote: > I hereby nominate Robbin Ehn [rehn] to Membership in the hotspot Group. > > Robbin Ehn is an OpenJDK Reviewer and a member of the HotSpot runtime > team at Oracle.? He has contributed a concurrent hash table, > synchronization performance improvements and bug fixes to the HotSpot > code base. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vote > > From david.holmes at oracle.com Wed Jan 4 01:12:53 2023 From: david.holmes at oracle.com (David Holmes) Date: Wed, 4 Jan 2023 11:12:53 +1000 Subject: CFV: New OpenJDK hotspot Group Member: Serguei Spitsyn In-Reply-To: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> References: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> Message-ID: <26ded54a-2ff9-1c55-55a5-76696830d9ce@oracle.com> Vote: yes David On 4/01/2023 2:27 am, coleen.phillimore at oracle.com wrote: > I hereby nominate Serguei Spitsyn [sspitsyn] to Membership in the > hotspot Group. > > Serguei is an OpenJDK reviewer and a member of the HotSpot > serviceability team at Oracle.? He is lead for the serviceability > project [1] and a technical lead in HotSpot. He has recently implemented > JVMTI support for the Loom project.? He is already member of the OpenJDK > members group. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#serviceability > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > From dholmes at openjdk.org Wed Jan 4 01:27:49 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 4 Jan 2023 01:27:49 GMT Subject: RFR: 8294403: [REDO] make test should report only on executed tests In-Reply-To: References: Message-ID: On Tue, 3 Jan 2023 09:39:59 GMT, Aleksey Shipilev wrote: > This should help to speed up tests significantly. Currently, if we run "make test" with a subset of tests, JTReg would still read the entirety of test root to report on tests that were not run. Even with current suite of tests it gets expensive. If you add more tests to suite -- for example, mounting a large test archive like pre-generated fuzzer tests -- it starts to take a lot of time. > > The reasonable default for older jtreg is `-report:executed`. My own CI -- that has millions of tests mounted in `test/` -- was running with `JTREG="OPTIONS=-report:executed"` for years now. [CODETOOLS-7903323](https://bugs.openjdk.org/browse/CODETOOLS-7903323) provides a new reporting option, `-report:files`, which makes this whole business easier. This requires new jtreg. > > Motivational improvements: > > > $ time CONF=linux-x86_64-server-release make run-test TEST=gc/epsilon/TestHelloWorld.java > > # Default JDK tree > > # Baseline > real 0m9.086s > user 0m22.857s > sys 0m4.202s > > # Patched > real 0m6.406s ; +40% faster > user 0m17.156s > sys 0m3.193s > > # +100K fuzzer tests in tree > > # Baseline > real 3m1.997s > user 3m16.643s > sys 0m10.490s > > # Patched > real 0m8.919s ; 20x faster > user 0m17.904s > sys 0m4.860s > > > Additional testing: > - [x] Ad-hoc timing tests (see above) > - [x] Reproducer from [CODETOOLS-7903331](https://bugs.openjdk.org/browse/CODETOOLS-7903331) > - [x] Eyeballing the test results on passing tests with REPEAT_COUNT > 1 > - [x] Eyeballing the test results on intermittently failing tests with RETRY_COUNT > 1 This seems fine to me. Thanks. I personally always run with `-noreport`. :) ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/11824 From jpai at openjdk.org Wed Jan 4 01:43:48 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 4 Jan 2023 01:43:48 GMT Subject: RFR: 8294403: [REDO] make test should report only on executed tests In-Reply-To: References: Message-ID: On Tue, 3 Jan 2023 09:39:59 GMT, Aleksey Shipilev wrote: > This should help to speed up tests significantly. Currently, if we run "make test" with a subset of tests, JTReg would still read the entirety of test root to report on tests that were not run. Even with current suite of tests it gets expensive. If you add more tests to suite -- for example, mounting a large test archive like pre-generated fuzzer tests -- it starts to take a lot of time. > > The reasonable default for older jtreg is `-report:executed`. My own CI -- that has millions of tests mounted in `test/` -- was running with `JTREG="OPTIONS=-report:executed"` for years now. [CODETOOLS-7903323](https://bugs.openjdk.org/browse/CODETOOLS-7903323) provides a new reporting option, `-report:files`, which makes this whole business easier. This requires new jtreg. > > Motivational improvements: > > > $ time CONF=linux-x86_64-server-release make run-test TEST=gc/epsilon/TestHelloWorld.java > > # Default JDK tree > > # Baseline > real 0m9.086s > user 0m22.857s > sys 0m4.202s > > # Patched > real 0m6.406s ; +40% faster > user 0m17.156s > sys 0m3.193s > > # +100K fuzzer tests in tree > > # Baseline > real 3m1.997s > user 3m16.643s > sys 0m10.490s > > # Patched > real 0m8.919s ; 20x faster > user 0m17.904s > sys 0m4.860s > > > Additional testing: > - [x] Ad-hoc timing tests (see above) > - [x] Reproducer from [CODETOOLS-7903331](https://bugs.openjdk.org/browse/CODETOOLS-7903331) > - [x] Eyeballing the test results on passing tests with REPEAT_COUNT > 1 > - [x] Eyeballing the test results on intermittently failing tests with RETRY_COUNT > 1 Hello Aleksey, this looks good to me. Good to see the timing improvements on `make test`. Please update the copyright years on the files before integrating. I see that in the additional testing section you note, running tests with RETRY_COUNT. Is that intentional? Does retry count play a role in the report generation? ------------- Marked as reviewed by jpai (Reviewer). PR: https://git.openjdk.org/jdk/pull/11824 From dholmes at openjdk.org Wed Jan 4 01:57:49 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 4 Jan 2023 01:57:49 GMT Subject: RFR: 8299274: Add elements to resolved_references consistently In-Reply-To: References: Message-ID: On Tue, 3 Jan 2023 18:35:20 GMT, Coleen Phillimore wrote: > I added a resolved_references_at and set_resolved_references_at() functions to use for accesses to the resolved_references array, except for the CDS usages. This has an assert that the element is an oop and oob checks and setting elements use a CAS consistently. > These asserts seem useful for finding the bug causing https://bugs.openjdk.org/browse/JDK-8296915. > Tested with tiers1-4. Looks good - nice simplification. Just one issue with naming. Thanks src/hotspot/share/oops/constantPool.cpp line 174: > 172: } > 173: > 174: oop ConstantPool::resolved_references_at(int index) const { This function should be called `resolved_reference_at` - singular - as it returns one reference. Thanks. src/hotspot/share/oops/constantPool.cpp line 181: > 179: > 180: // Use a CAS for multithreaded access > 181: oop ConstantPool::set_resolved_references_at(int index, oop new_result, oop old_result) { This function should be called `set_resolved_reference_at` - singular - as it sets one reference. Thanks. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/11834 From jcking at openjdk.org Wed Jan 4 02:02:11 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 4 Jan 2023 02:02:11 GMT Subject: RFR: JDK-8299554: Remove EnableIf from metaprogramming/enableIf.hpp [v4] In-Reply-To: <4VZUOmguEjK6C8NEMI3KrS_E5HNU-G1H-h8MJty2mlY=.2aa0c645-1695-45ee-b53d-f701772884d8@github.com> References: <4VZUOmguEjK6C8NEMI3KrS_E5HNU-G1H-h8MJty2mlY=.2aa0c645-1695-45ee-b53d-f701772884d8@github.com> Message-ID: > As the title says, remove `EnableIf` type alias from `metaprogramming/enableIf.hpp` leaving only `ENABLE_IF` and `ENABLE_IF_SDEFN`. Justin King has updated the pull request incrementally with one additional commit since the last revision: s//::value Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11835/files - new: https://git.openjdk.org/jdk/pull/11835/files/46d03252..810d8f61 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11835&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11835&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11835.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11835/head:pull/11835 PR: https://git.openjdk.org/jdk/pull/11835 From apangin at openjdk.org Wed Jan 4 02:44:23 2023 From: apangin at openjdk.org (Andrei Pangin) Date: Wed, 4 Jan 2023 02:44:23 GMT Subject: RFR: 8299544: Improve performance of CRC32C intrinsics (non-AVX-512) for small inputs Message-ID: 8299544: Improve performance of CRC32C intrinsics (non-AVX-512) for small inputs ------------- Commit messages: - Merge branch 'openjdk:master' into JDK-8299544 - 8299544: Improve performance of CRC32C intrinsics (non-AVX-512) for small inputs Changes: https://git.openjdk.org/jdk/pull/11838/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11838&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299544 Stats: 16 lines in 2 files changed: 5 ins; 2 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/11838.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11838/head:pull/11838 PR: https://git.openjdk.org/jdk/pull/11838 From kbarrett at openjdk.org Wed Jan 4 03:27:19 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 4 Jan 2023 03:27:19 GMT Subject: [jdk20] RFR: 8293824: gc/whitebox/TestConcMarkCycleWB.java failed "RuntimeException: assertTrue: expected true, was false" [v2] In-Reply-To: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com> References: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com> Message-ID: <2wRK9LZ0L4QdgzNhCM2bya3emb4zU9OTwvt5VnyzO0E=.0b22adcb-c49b-4a46-bf8a-82975ea1d514@github.com> > Please review this change to WhiteBox and some tests involving G1 concurrent GCs. > > Some tests currently use WhiteBox.g1StartConcMarkCycle() to trigger a > concurrent GC. Many of them follow it with a loop waiting for a concurrent > cycle to not be in progress. A few also preceed that call with a similar > loop, since that call does nothing and returns false if a concurrent cycle is > already in progress. Those tests typically want to ensure there was a > concurrent cycle that was started after some setup. > > The failing test calls that function, asserting that it returned true, e.g. a > new concurrent cycle was started. > > There are various problems with this, due to races with concurrent cycles > started automatically, and due to possibly aborted (by full GCs) concurrent cycles, > making some of these tests unreliable in some configurations. > > For example, the test failure associated with this bug intermittently arises > when running with `-Xcomp`, triggering a concurrent cycle before the explicit > request by the test, causing the explicit request to fail (because there is > already one in progress), failing the assert. Waiting for there not to be an > in-progress cycle before the explicit request just narrows the race window. > > We have a different mechanism in WhiteBox for controlling concurrent cycles, > the concurrent GC breakpoint mechanism. By adding a counter specifically for > such cycles, we can use GC breakpoints to ensure only the concurrent cycles > the test wants are occurring, and can verify they completed successfully. > > So we change tests using WhiteBox.g1StartConcMarkCycle() to instead use GC > breakpoints, along with the new WhiteBox.g1CompletedConcurrentMarkCycles() to > avoid racing request problems and to detect aborted cycles. Since it is no > longer used, WhiteBox.g1StartConcMarkCycle() is removed. The test that began > this adventure (TestConcMarkCycleWB.java) is also removed, since it no longer > serves any purpose, having been purely a test of that removed function. > > Testing: > mach5 tier1-7 - running the changed tests on a variety of platforms with a > variety of configurations. Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into test-concmark20 - use gc breakpoints to perform conc gc ------------- Changes: - all: https://git.openjdk.org/jdk20/pull/71/files - new: https://git.openjdk.org/jdk20/pull/71/files/39abc3dc..3b837273 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk20&pr=71&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=71&range=00-01 Stats: 786 lines in 35 files changed: 563 ins; 95 del; 128 mod Patch: https://git.openjdk.org/jdk20/pull/71.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/71/head:pull/71 PR: https://git.openjdk.org/jdk20/pull/71 From kbarrett at openjdk.org Wed Jan 4 03:27:20 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 4 Jan 2023 03:27:20 GMT Subject: [jdk20] RFR: 8293824: gc/whitebox/TestConcMarkCycleWB.java failed "RuntimeException: assertTrue: expected true, was false" [v2] In-Reply-To: References: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com> Message-ID: On Thu, 22 Dec 2022 16:11:46 GMT, Ivan Walulya wrote: >> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'master' into test-concmark20 >> - use gc breakpoints to perform conc gc > > Lgtm! Thanks for reviews @walulyai and @tschatzl . ------------- PR: https://git.openjdk.org/jdk20/pull/71 From kbarrett at openjdk.org Wed Jan 4 03:31:57 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 4 Jan 2023 03:31:57 GMT Subject: [jdk20] Integrated: 8293824: gc/whitebox/TestConcMarkCycleWB.java failed "RuntimeException: assertTrue: expected true, was false" In-Reply-To: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com> References: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com> Message-ID: On Thu, 22 Dec 2022 02:04:30 GMT, Kim Barrett wrote: > Please review this change to WhiteBox and some tests involving G1 concurrent GCs. > > Some tests currently use WhiteBox.g1StartConcMarkCycle() to trigger a > concurrent GC. Many of them follow it with a loop waiting for a concurrent > cycle to not be in progress. A few also preceed that call with a similar > loop, since that call does nothing and returns false if a concurrent cycle is > already in progress. Those tests typically want to ensure there was a > concurrent cycle that was started after some setup. > > The failing test calls that function, asserting that it returned true, e.g. a > new concurrent cycle was started. > > There are various problems with this, due to races with concurrent cycles > started automatically, and due to possibly aborted (by full GCs) concurrent cycles, > making some of these tests unreliable in some configurations. > > For example, the test failure associated with this bug intermittently arises > when running with `-Xcomp`, triggering a concurrent cycle before the explicit > request by the test, causing the explicit request to fail (because there is > already one in progress), failing the assert. Waiting for there not to be an > in-progress cycle before the explicit request just narrows the race window. > > We have a different mechanism in WhiteBox for controlling concurrent cycles, > the concurrent GC breakpoint mechanism. By adding a counter specifically for > such cycles, we can use GC breakpoints to ensure only the concurrent cycles > the test wants are occurring, and can verify they completed successfully. > > So we change tests using WhiteBox.g1StartConcMarkCycle() to instead use GC > breakpoints, along with the new WhiteBox.g1CompletedConcurrentMarkCycles() to > avoid racing request problems and to detect aborted cycles. Since it is no > longer used, WhiteBox.g1StartConcMarkCycle() is removed. The test that began > this adventure (TestConcMarkCycleWB.java) is also removed, since it no longer > serves any purpose, having been purely a test of that removed function. > > Testing: > mach5 tier1-7 - running the changed tests on a variety of platforms with a > variety of configurations. This pull request has now been integrated. Changeset: b743519b Author: Kim Barrett URL: https://git.openjdk.org/jdk20/commit/b743519ba911a254669fa8a96e6006c14e3f5ad1 Stats: 288 lines in 24 files changed: 98 ins; 131 del; 59 mod 8293824: gc/whitebox/TestConcMarkCycleWB.java failed "RuntimeException: assertTrue: expected true, was false" Reviewed-by: iwalulya, tschatzl ------------- PR: https://git.openjdk.org/jdk20/pull/71 From dean.long at oracle.com Wed Jan 4 03:49:02 2023 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 3 Jan 2023 19:49:02 -0800 Subject: CFV: New OpenJDK hotspot Group Member: Lois Foltan In-Reply-To: References: Message-ID: <34b7a286-b001-8bac-53da-b28f7cf70bec@oracle.com> Vote: yes On 1/3/23 8:22 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate Lois Foltan [lfoltan] to Membership in the hotspot > Group. > > Lois is an OpenJDK Reviewer and a member of the HotSpot runtime team > at Oracle. She contributed the VM support for the Module subsystem JSR > 294, semantic changes in HotSpot for default methods, cleanups for > signature processing, Condy support, and many bug fixes. Lois is now > an engineering manager for the runtime team. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vot From dean.long at oracle.com Wed Jan 4 03:50:27 2023 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 3 Jan 2023 19:50:27 -0800 Subject: CFV: New OpenJDK hotspot Group Member: Frederic Parain In-Reply-To: <175ece63-eb89-ba46-52aa-270762e122c2@oracle.com> References: <175ece63-eb89-ba46-52aa-270762e122c2@oracle.com> Message-ID: <1241f41b-3190-be59-e66d-3f0427fb4c9d@oracle.com> Vote: yes On 1/3/23 8:26 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate Frederic Parain [fparain] to Membership in the > hotspot Group. > > Frederic is an OpenJDK Committer and a member of the HotSpot runtime > team at Oracle. He is an active contributor to the valhalla project > [1], implementing programming models in the HotSpot code. He is also a > contributor to OpenJDK since 2010, working on serviceability code, > implementing the diagnostic commands framework, and rewriting Java > field layout code. He is currently working on compressing c2 frames in > the Loom project, and making the VM internal representation of fields > extensible for valhalla support. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#valhalla > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > From dean.long at oracle.com Wed Jan 4 03:50:46 2023 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 3 Jan 2023 19:50:46 -0800 Subject: CFV: New OpenJDK hotspot Group Member: Patricio Chilano Mateo In-Reply-To: References: Message-ID: Vote: yes On 1/3/23 8:20 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo [pchilomate] to Membership in > the hotspot Group. > > Patricio is an OpenJDK Reviewer and a member of the HotSpot runtime > team at Oracle. Since 2018 he has worked on improvements and bug fixes > mainly in the areas of locking, safepoint synchronization, thread > state transitions, and handshakes. He is currently working on Loom > changes for virtual thread preemption. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vote > > From dean.long at oracle.com Wed Jan 4 03:51:06 2023 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 3 Jan 2023 19:51:06 -0800 Subject: CFV: New OpenJDK hotspot Group Member: Robbin Ehn In-Reply-To: <7652c110-0767-bf12-dd32-8cde03ba6fc7@oracle.com> References: <7652c110-0767-bf12-dd32-8cde03ba6fc7@oracle.com> Message-ID: <3e56c2de-b7e4-43bf-61aa-3d63a43c9a23@oracle.com> Vote: yes On 1/3/23 8:18 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate Robbin Ehn [rehn] to Membership in the hotspot Group. > > Robbin Ehn is an OpenJDK Reviewer and a member of the HotSpot runtime > team at Oracle.? He has contributed a concurrent hash table, > synchronization performance improvements and bug fixes to the HotSpot > code base. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vote > > From dean.long at oracle.com Wed Jan 4 03:51:22 2023 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 3 Jan 2023 19:51:22 -0800 Subject: CFV: New OpenJDK hotspot Group Member: Serguei Spitsyn In-Reply-To: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> References: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> Message-ID: Vote: yes On 1/3/23 8:27 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate Serguei Spitsyn [sspitsyn] to Membership in the > hotspot Group. > > Serguei is an OpenJDK reviewer and a member of the HotSpot > serviceability team at Oracle.? He is lead for the serviceability > project [1] and a technical lead in HotSpot. He has recently > implemented JVMTI support for the Loom project.? He is already member > of the OpenJDK members group. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#serviceability > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > From dean.long at oracle.com Wed Jan 4 04:29:34 2023 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 3 Jan 2023 20:29:34 -0800 Subject: CFV: New hotspot Group Member: Ron Pressler In-Reply-To: References: Message-ID: <5480d757-e507-db9d-e068-7648d9924b72@oracle.com> Vote: yes From dholmes at openjdk.org Wed Jan 4 05:00:57 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 4 Jan 2023 05:00:57 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions [v5] In-Reply-To: References: Message-ID: <-u9V0TIbZ41IPEmql4jeLKzAmT9OPIZAurEoN-K2BXc=.0b8e5b84-47be-4d49-b99c-9317b25258e4@github.com> On Sat, 24 Dec 2022 04:14:07 GMT, Serguei Spitsyn wrote: >> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different. >> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread. >> >> Testing: >> mach5 jobs are TBD (preliminary testing was completed): >> - all JVMTI, JDWP, JDI and JDB tests have to be run >> - Kitchensink >> - tier5 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > fix race between VTMS_transition_disable_for_one and start_VTMS_transition Still muddling through this ... src/hotspot/share/classfile/javaClasses.cpp line 1740: > 1738: void java_lang_Thread::inc_VTMS_transition_disable_count(oop java_thread) { > 1739: int val = VTMS_transition_disable_count(java_thread); > 1740: assert(JvmtiVTMSTransition_lock->owned_by_self(), "Must be locked"); Nit: normally a lock-checking assertion would come first in the function, so that it stands out more. src/hotspot/share/classfile/javaClasses.cpp line 1746: > 1744: void java_lang_Thread::dec_VTMS_transition_disable_count(oop java_thread) { > 1745: int val = VTMS_transition_disable_count(java_thread); > 1746: assert(JvmtiVTMSTransition_lock->owned_by_self(), "Must be locked"); Nit: normally a lock-checking assertion would come first in the function, so that it stands out more. src/hotspot/share/prims/jvmtiThreadState.cpp line 384: > 382: JvmtiThreadState* vstate = java_lang_Thread::jvmti_thread_state(vth()); > 383: if (vstate != NULL) { > 384: vstate->set_is_in_VTMS_transition(true); Is the VTMS transition flag in the `JvmtiThreadState` dead code now? src/hotspot/share/prims/jvmtiThreadState.cpp line 482: > 480: _VTMS_transition_disable_for_all_count > 0) { > 481: MonitorLocker ml(JvmtiVTMSTransition_lock, Mutex::_no_safepoint_check_flag); > 482: ml.notify_all(); Checking the counts outside the lock seems really racy. Maybe it is safe in the original code but now we have two counters it is very hard to ascertain this is correct. Overall I find it very hard to see exactly how these counters get used. ------------- PR: https://git.openjdk.org/jdk/pull/11690 From tobias.hartmann at oracle.com Wed Jan 4 06:00:00 2023 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 4 Jan 2023 07:00:00 +0100 Subject: CFV: New hotspot Group Member: Ron Pressler In-Reply-To: References: Message-ID: Vote: yes Best regards, Tobias On 03.01.23 17:11, coleen.phillimore at oracle.com wrote: > Correcting email address. > > > -------- Forwarded Message -------- > Subject: CFV: New hotspot Group Member: Ron Pressler > Date: Tue, 3 Jan 2023 11:06:16 -0500 > From: coleen.phillimore at oracle.com > To: hotspot-dev at openjdk.java.net > > > > I hereby nominate Ron Pressler [rpressler] to Membership in the hotspot Group. > > Ron Pressler is the lead for the Loom project [1] and is a committer on the JDK project, including > the major contribution of? JEP 425: Virtual Threads. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on this nomination.? Votes must > be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#loom > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > From tobias.hartmann at oracle.com Wed Jan 4 06:00:18 2023 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 4 Jan 2023 07:00:18 +0100 Subject: CFV: New OpenJDK hotspot Group Member: Serguei Spitsyn In-Reply-To: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> References: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> Message-ID: <12a99244-0f18-bff6-8197-19908d9e25ef@oracle.com> Vote: yes Best regards, Tobias On 03.01.23 17:27, coleen.phillimore at oracle.com wrote: > I hereby nominate Serguei Spitsyn [sspitsyn] to Membership in the hotspot Group. > > Serguei is an OpenJDK reviewer and a member of the HotSpot serviceability team at Oracle.? He is > lead for the serviceability project [1] and a technical lead in HotSpot. He has recently implemented > JVMTI support for the Loom project.? He is already member of the OpenJDK members group. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on this nomination.? Votes must > be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#serviceability > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > From tobias.hartmann at oracle.com Wed Jan 4 06:00:42 2023 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 4 Jan 2023 07:00:42 +0100 Subject: CFV: New OpenJDK hotspot Group Member: Robbin Ehn In-Reply-To: <7652c110-0767-bf12-dd32-8cde03ba6fc7@oracle.com> References: <7652c110-0767-bf12-dd32-8cde03ba6fc7@oracle.com> Message-ID: <7652bd9b-7ec4-5e0c-7cf2-a64dfeebc5d1@oracle.com> Vote: yes Best regards, Tobias On 03.01.23 17:18, coleen.phillimore at oracle.com wrote: > I hereby nominate Robbin Ehn [rehn] to Membership in the hotspot Group. > > Robbin Ehn is an OpenJDK Reviewer and a member of the HotSpot runtime team at Oracle.? He has > contributed a concurrent hash table, synchronization performance improvements and bug fixes to the > HotSpot code base. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on this nomination.? Votes must > be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vote > > From tobias.hartmann at oracle.com Wed Jan 4 06:00:58 2023 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 4 Jan 2023 07:00:58 +0100 Subject: CFV: New OpenJDK hotspot Group Member: Patricio Chilano Mateo In-Reply-To: References: Message-ID: <66251480-9b61-06fa-4e9b-cf23e1e30294@oracle.com> Vote: yes Best regards, Tobias On 03.01.23 17:20, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo [pchilomate] to Membership in the hotspot Group. > > Patricio is an OpenJDK Reviewer and a member of the HotSpot runtime team at Oracle. Since 2018 he > has worked on improvements and bug fixes mainly in the areas of locking, safepoint synchronization, > thread state transitions, and handshakes. He is currently working on Loom changes for virtual thread > preemption. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on this nomination.? Votes must > be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vote > > From tobias.hartmann at oracle.com Wed Jan 4 06:01:20 2023 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 4 Jan 2023 07:01:20 +0100 Subject: CFV: New OpenJDK hotspot Group Member: Frederic Parain In-Reply-To: <175ece63-eb89-ba46-52aa-270762e122c2@oracle.com> References: <175ece63-eb89-ba46-52aa-270762e122c2@oracle.com> Message-ID: <4da9552b-2cec-c9e8-1364-3313c6336496@oracle.com> Vote: yes Best regards, Tobias On 03.01.23 17:26, coleen.phillimore at oracle.com wrote: > I hereby nominate Frederic Parain [fparain] to Membership in the hotspot Group. > > Frederic is an OpenJDK Committer and a member of the HotSpot runtime team at Oracle. He is an active > contributor to the valhalla project [1], implementing programming models in the HotSpot code. He is > also a contributor to OpenJDK since 2010, working on serviceability code, implementing the > diagnostic commands framework, and rewriting Java field layout code. He is currently working on > compressing c2 frames in the Loom project, and making the VM internal representation of fields > extensible for valhalla support. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on this nomination.? Votes must > be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#valhalla > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > From tobias.hartmann at oracle.com Wed Jan 4 06:01:43 2023 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 4 Jan 2023 07:01:43 +0100 Subject: CFV: New OpenJDK hotspot Group Member: Lois Foltan In-Reply-To: References: Message-ID: <1f1e3816-907c-208b-8257-913b4daaa168@oracle.com> Vote: yes Best regards, Tobias On 03.01.23 17:22, coleen.phillimore at oracle.com wrote: > I hereby nominate Lois Foltan [lfoltan] to Membership in the hotspot Group. > > Lois is an OpenJDK Reviewer and a member of the HotSpot runtime team at Oracle. She contributed the > VM support for the Module subsystem JSR 294, semantic changes in HotSpot for default methods, > cleanups for signature processing, Condy support, and many bug fixes. Lois is now an engineering > manager for the runtime team. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on this nomination.? Votes must > be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vot From thartmann at openjdk.org Wed Jan 4 07:01:35 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 4 Jan 2023 07:01:35 GMT Subject: RFR: 8298720: Insufficient error handling when CodeBuffer is exhausted Message-ID: This patch fixes various places in C1 and C2 on Aarch64 and RISC-V that miss proper error handling when the code buffer is exhausted, leading to crashes. Similar but incomplete patches went in with [JDK-8130309](https://bugs.openjdk.org/browse/JDK-8130309), [JDK-8248411](https://bugs.openjdk.org/browse/JDK-8248411) and [JDK-8272094](https://bugs.openjdk.org/browse/JDK-8272094) in the past. These issues are extremely hard to reproduce, even with the `-XX:+StressCodeBuffers` option, because code buffer expansion needs to fail at the exact moment when a specific (unhandled) instruction is emitted. Even with the stress option, we expand the code buffer such that multiple instructions will fit and in addition, chances are high that we simply bail out from compilation before emitting the problematic instruction. I attached a patch to [JDK-8298720](https://bugs.openjdk.org/browse/JDK-8298720), that makes `-XX:+StressCodeBuffers` randomized and more aggressive. With that, I can reproduce the issue reliably but it's extremely slow and therefore not well suited for integration. I now went over all usages of `CodeBuffer::expand` to make sure that we have proper error handling in place and found some remaining issues in JVMCI code. I filed [JDK-8299570](https://bugs.openjdk.org/browse/JDK-8299570) to address them. I would need help to test the RISC-V specific changes. Thanks, Tobias ------------- Commit messages: - Re-added newline - Proper error handling in C1 - Make reset_labels accessible - 8298720: Insufficient error handling when CodeBuffer is exhausted Changes: https://git.openjdk.org/jdk/pull/11839/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11839&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298720 Stats: 114 lines in 10 files changed: 71 ins; 6 del; 37 mod Patch: https://git.openjdk.org/jdk/pull/11839.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11839/head:pull/11839 PR: https://git.openjdk.org/jdk/pull/11839 From sspitsyn at openjdk.org Wed Jan 4 07:43:55 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 4 Jan 2023 07:43:55 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions [v5] In-Reply-To: <-u9V0TIbZ41IPEmql4jeLKzAmT9OPIZAurEoN-K2BXc=.0b8e5b84-47be-4d49-b99c-9317b25258e4@github.com> References: <-u9V0TIbZ41IPEmql4jeLKzAmT9OPIZAurEoN-K2BXc=.0b8e5b84-47be-4d49-b99c-9317b25258e4@github.com> Message-ID: On Wed, 4 Jan 2023 04:33:53 GMT, David Holmes wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> fix race between VTMS_transition_disable_for_one and start_VTMS_transition > > src/hotspot/share/classfile/javaClasses.cpp line 1746: > >> 1744: void java_lang_Thread::dec_VTMS_transition_disable_count(oop java_thread) { >> 1745: int val = VTMS_transition_disable_count(java_thread); >> 1746: assert(JvmtiVTMSTransition_lock->owned_by_self(), "Must be locked"); > > Nit: normally a lock-checking assertion would come first in the function, so that it stands out more. Okay, thanks. Fixed locally. > src/hotspot/share/prims/jvmtiThreadState.cpp line 384: > >> 382: JvmtiThreadState* vstate = java_lang_Thread::jvmti_thread_state(vth()); >> 383: if (vstate != NULL) { >> 384: vstate->set_is_in_VTMS_transition(true); > > Is the VTMS transition flag in the `JvmtiThreadState` dead code now? Yes. All this dead code has been removed now. ------------- PR: https://git.openjdk.org/jdk/pull/11690 From sspitsyn at openjdk.org Wed Jan 4 07:48:58 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 4 Jan 2023 07:48:58 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions [v5] In-Reply-To: <-u9V0TIbZ41IPEmql4jeLKzAmT9OPIZAurEoN-K2BXc=.0b8e5b84-47be-4d49-b99c-9317b25258e4@github.com> References: <-u9V0TIbZ41IPEmql4jeLKzAmT9OPIZAurEoN-K2BXc=.0b8e5b84-47be-4d49-b99c-9317b25258e4@github.com> Message-ID: On Wed, 4 Jan 2023 04:54:27 GMT, David Holmes wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> fix race between VTMS_transition_disable_for_one and start_VTMS_transition > > src/hotspot/share/prims/jvmtiThreadState.cpp line 482: > >> 480: _VTMS_transition_disable_for_all_count > 0) { >> 481: MonitorLocker ml(JvmtiVTMSTransition_lock, Mutex::_no_safepoint_check_flag); >> 482: ml.notify_all(); > > Checking the counts outside the lock seems really racy. Maybe it is safe in the original code but now we have two counters it is very hard to ascertain this is correct. Overall I find it very hard to see exactly how these counters get used. This notification code is just an optimization. All related waiting fragments are with timeouts. I agree this sync protocol is kind of complicated and also does not scale well. I'm still thinking on how to improve it. ------------- PR: https://git.openjdk.org/jdk/pull/11690 From fyang at openjdk.org Wed Jan 4 09:11:49 2023 From: fyang at openjdk.org (Fei Yang) Date: Wed, 4 Jan 2023 09:11:49 GMT Subject: RFR: 8298720: Insufficient error handling when CodeBuffer is exhausted In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 06:31:16 GMT, Tobias Hartmann wrote: > This patch fixes various places in C1 and C2 on Aarch64 and RISC-V that miss proper error handling when the code buffer is exhausted, leading to crashes. Similar but incomplete patches went in with [JDK-8130309](https://bugs.openjdk.org/browse/JDK-8130309), [JDK-8248411](https://bugs.openjdk.org/browse/JDK-8248411) and [JDK-8272094](https://bugs.openjdk.org/browse/JDK-8272094) in the past. > > These issues are extremely hard to reproduce, even with the `-XX:+StressCodeBuffers` option, because code buffer expansion needs to fail at the exact moment when a specific (unhandled) instruction is emitted. Even with the stress option, we expand the code buffer such that multiple instructions will fit and in addition, chances are high that we simply bail out from compilation before emitting the problematic instruction. I attached a patch to [JDK-8298720](https://bugs.openjdk.org/browse/JDK-8298720), that makes `-XX:+StressCodeBuffers` randomized and more aggressive. With that, I can reproduce the issue reliably but it's extremely slow and therefore not well suited for integration. > > I now went over all usages of `CodeBuffer::expand` to make sure that we have proper error handling in place and found some remaining issues in JVMCI code. I filed [JDK-8299570](https://bugs.openjdk.org/browse/JDK-8299570) to address them. > > I would need help to test the RISC-V specific changes. > > Thanks, > Tobias Hi! Thanks for handling RISC-V at the same time. I can help arrange some necessary tests on linux-riscv64 for those changes. ------------- PR: https://git.openjdk.org/jdk/pull/11839 From shade at openjdk.org Wed Jan 4 09:15:18 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 4 Jan 2023 09:15:18 GMT Subject: RFR: 8294403: [REDO] make test should report only on executed tests [v2] In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 01:40:36 GMT, Jaikiran Pai wrote: > Please update the copyright years on the files before integrating. Updated. > I see that in the additional testing section you note, running tests with RETRY_COUNT. Is that intentional? Does retry count play a role in the report generation? The logic for REPEAT/RETRY_COUNT merges the jtreg reports from "different" repeated runs. We have to check new reporting mode still produces sane results in that mode. ------------- PR: https://git.openjdk.org/jdk/pull/11824 From kbarrett at openjdk.org Wed Jan 4 09:17:53 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 4 Jan 2023 09:17:53 GMT Subject: RFR: 8299254: Support dealing with standard assert macro In-Reply-To: <0K8uV1bRbUyVzdzMaz7ikBg6JZH9LeZys9g56llUm74=.e8df7e1d-4541-4641-b680-783870165d80@github.com> References: <6VQwFg9prwXbOwp_asHA4-Wru6PdKvaRN8MGiU24_sw=.1cafd8ea-e7e4-4a9d-a8ba-4f0cf87621d2@github.com> <0K8uV1bRbUyVzdzMaz7ikBg6JZH9LeZys9g56llUm74=.e8df7e1d-4541-4641-b680-783870165d80@github.com> Message-ID: On Tue, 3 Jan 2023 06:36:38 GMT, David Holmes wrote: > Not pretty, but effective. > > Do we need some text added to the hotspot style guide to describe this usage? Should we bracket all includes of system headers with these, or only those known to cause a problem? Most of the uses are currently violations of the style guide (e.g. using the Standard Library (other than the C++ wrappers for standard C headers)). The only exception to that is the wrapper around the gtest header inclusions. So no, I don't think we need to do anything about this in the style guide. (My prototype / proposal for permitting more use of the Standard Library makes use of this same mechanism. The new helper files originated there, and this change lets me eliminate one of the commits in that work.) ------------- PR: https://git.openjdk.org/jdk/pull/11770 From shade at openjdk.org Wed Jan 4 09:15:18 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 4 Jan 2023 09:15:18 GMT Subject: RFR: 8294403: [REDO] make test should report only on executed tests [v2] In-Reply-To: References: Message-ID: > This should help to speed up tests significantly. Currently, if we run "make test" with a subset of tests, JTReg would still read the entirety of test root to report on tests that were not run. Even with current suite of tests it gets expensive. If you add more tests to suite -- for example, mounting a large test archive like pre-generated fuzzer tests -- it starts to take a lot of time. > > The reasonable default for older jtreg is `-report:executed`. My own CI -- that has millions of tests mounted in `test/` -- was running with `JTREG="OPTIONS=-report:executed"` for years now. [CODETOOLS-7903323](https://bugs.openjdk.org/browse/CODETOOLS-7903323) provides a new reporting option, `-report:files`, which makes this whole business easier. This requires new jtreg. > > Motivational improvements: > > > $ time CONF=linux-x86_64-server-release make run-test TEST=gc/epsilon/TestHelloWorld.java > > # Default JDK tree > > # Baseline > real 0m9.086s > user 0m22.857s > sys 0m4.202s > > # Patched > real 0m6.406s ; +40% faster > user 0m17.156s > sys 0m3.193s > > # +100K fuzzer tests in tree > > # Baseline > real 3m1.997s > user 3m16.643s > sys 0m10.490s > > # Patched > real 0m8.919s ; 20x faster > user 0m17.904s > sys 0m4.860s > > > Additional testing: > - [x] Ad-hoc timing tests (see above) > - [x] Reproducer from [CODETOOLS-7903331](https://bugs.openjdk.org/browse/CODETOOLS-7903331) > - [x] Eyeballing the test results on passing tests with REPEAT_COUNT > 1 > - [x] Eyeballing the test results on intermittently failing tests with RETRY_COUNT > 1 Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Copyright years ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11824/files - new: https://git.openjdk.org/jdk/pull/11824/files/a803958f..a82ac6cc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11824&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11824&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11824.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11824/head:pull/11824 PR: https://git.openjdk.org/jdk/pull/11824 From jpai at openjdk.org Wed Jan 4 09:25:56 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 4 Jan 2023 09:25:56 GMT Subject: RFR: 8294403: [REDO] make test should report only on executed tests [v2] In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 09:10:01 GMT, Aleksey Shipilev wrote: > > I see that in the additional testing section you note, running tests with RETRY_COUNT. Is that intentional? Does retry count play a role in the report generation? > > The logic for REPEAT/RETRY_COUNT merges the jtreg reports from "different" repeated runs. We have to check new reporting mode still produces sane results in that mode. Thank you for that detail, I wasn't aware of that. ------------- PR: https://git.openjdk.org/jdk/pull/11824 From jpai at openjdk.org Wed Jan 4 09:25:55 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 4 Jan 2023 09:25:55 GMT Subject: RFR: 8294403: [REDO] make test should report only on executed tests [v2] In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 09:15:18 GMT, Aleksey Shipilev wrote: >> This should help to speed up tests significantly. Currently, if we run "make test" with a subset of tests, JTReg would still read the entirety of test root to report on tests that were not run. Even with current suite of tests it gets expensive. If you add more tests to suite -- for example, mounting a large test archive like pre-generated fuzzer tests -- it starts to take a lot of time. >> >> The reasonable default for older jtreg is `-report:executed`. My own CI -- that has millions of tests mounted in `test/` -- was running with `JTREG="OPTIONS=-report:executed"` for years now. [CODETOOLS-7903323](https://bugs.openjdk.org/browse/CODETOOLS-7903323) provides a new reporting option, `-report:files`, which makes this whole business easier. This requires new jtreg. >> >> Motivational improvements: >> >> >> $ time CONF=linux-x86_64-server-release make run-test TEST=gc/epsilon/TestHelloWorld.java >> >> # Default JDK tree >> >> # Baseline >> real 0m9.086s >> user 0m22.857s >> sys 0m4.202s >> >> # Patched >> real 0m6.406s ; +40% faster >> user 0m17.156s >> sys 0m3.193s >> >> # +100K fuzzer tests in tree >> >> # Baseline >> real 3m1.997s >> user 3m16.643s >> sys 0m10.490s >> >> # Patched >> real 0m8.919s ; 20x faster >> user 0m17.904s >> sys 0m4.860s >> >> >> Additional testing: >> - [x] Ad-hoc timing tests (see above) >> - [x] Reproducer from [CODETOOLS-7903331](https://bugs.openjdk.org/browse/CODETOOLS-7903331) >> - [x] Eyeballing the test results on passing tests with REPEAT_COUNT > 1 >> - [x] Eyeballing the test results on intermittently failing tests with RETRY_COUNT > 1 > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Copyright years Marked as reviewed by jpai (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11824 From thartmann at openjdk.org Wed Jan 4 10:03:50 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 4 Jan 2023 10:03:50 GMT Subject: RFR: 8298720: Insufficient error handling when CodeBuffer is exhausted In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 09:06:44 GMT, Fei Yang wrote: >> This patch fixes various places in C1 and C2 on Aarch64 and RISC-V that miss proper error handling when the code buffer is exhausted, leading to crashes. Similar but incomplete patches went in with [JDK-8130309](https://bugs.openjdk.org/browse/JDK-8130309), [JDK-8248411](https://bugs.openjdk.org/browse/JDK-8248411) and [JDK-8272094](https://bugs.openjdk.org/browse/JDK-8272094) in the past. >> >> These issues are extremely hard to reproduce, even with the `-XX:+StressCodeBuffers` option, because code buffer expansion needs to fail at the exact moment when a specific (unhandled) instruction is emitted. Even with the stress option, we expand the code buffer such that multiple instructions will fit and in addition, chances are high that we simply bail out from compilation before emitting the problematic instruction. I attached a patch to [JDK-8298720](https://bugs.openjdk.org/browse/JDK-8298720), that makes `-XX:+StressCodeBuffers` randomized and more aggressive. With that, I can reproduce the issue reliably but it's extremely slow and therefore not well suited for integration. >> >> I now went over all usages of `CodeBuffer::expand` to make sure that we have proper error handling in place and found some remaining issues in JVMCI code. I filed [JDK-8299570](https://bugs.openjdk.org/browse/JDK-8299570) to address them. >> >> I would need help to test the RISC-V specific changes. >> >> Thanks, >> Tobias > > Hi! Thanks for handling RISC-V at the same time. I can help arrange some necessary tests on linux-riscv64 for those changes. Thanks @RealFYang! It's mostly about verifying that I did not miss any label in the `reset_labels` calls. You should be able to hardcode the bailout to always true and check if we don't hit any assert. ------------- PR: https://git.openjdk.org/jdk/pull/11839 From fjiang at openjdk.org Wed Jan 4 11:17:51 2023 From: fjiang at openjdk.org (Feilong Jiang) Date: Wed, 4 Jan 2023 11:17:51 GMT Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory API (Preview) Message-ID: Add experimental Foreign Function & Memory API support for RISC-V. Details of FFM API RISC-V port please refer to [JBS issue](https://bugs.openjdk.org/browse/JDK-8293841) ------------- Commit messages: - sync with JDK-8296477 - sync with JDK-8295044 - JDK-8293841: RISC-V: Implementation of Foreign Function & Memory API (Preview) Changes: https://git.openjdk.org/jdk/pull/11004/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11004&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293841 Stats: 2861 lines in 64 files changed: 2736 ins; 2 del; 123 mod Patch: https://git.openjdk.org/jdk/pull/11004.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11004/head:pull/11004 PR: https://git.openjdk.org/jdk/pull/11004 From duke at openjdk.org Wed Jan 4 11:42:55 2023 From: duke at openjdk.org (Christoph) Date: Wed, 4 Jan 2023 11:42:55 GMT Subject: RFR: 8299378: sprintf is deprecated in Xcode 14 [v3] In-Reply-To: References: Message-ID: <-hkjhJ8w2GhJaQNTUWPNV4KJAFt2RcTKS4ywxBj2xXI=.62cfe4d7-c523-45f4-80bd-21e6c407dbce@github.com> On Tue, 3 Jan 2023 16:28:54 GMT, Xue-Lei Andrew Fan wrote: >> The `sprintf` is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812), but the test was not covered. The failure was [reported later](https://github.com/openjdk/jdk/pull/11115#issuecomment-1344973773), while gtest is enabled for building. >> >> This patch is just to make sure the building could pass. Other than that, the use of `sprintf` in other places are not touched. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > sort includes alphabetically @XueleiFan Unfortunately I still get the same error even after this PR was merged. ------------- PR: https://git.openjdk.org/jdk/pull/11793 From rehn at openjdk.org Wed Jan 4 12:27:58 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 4 Jan 2023 12:27:58 GMT Subject: RFR: 8299274: Add elements to resolved_references consistently In-Reply-To: References: Message-ID: On Tue, 3 Jan 2023 18:35:20 GMT, Coleen Phillimore wrote: > I added a resolved_references_at and set_resolved_references_at() functions to use for accesses to the resolved_references array, except for the CDS usages. This has an assert that the element is an oop and oob checks and setting elements use a CAS consistently. > These asserts seem useful for finding the bug causing https://bugs.openjdk.org/browse/JDK-8296915. > Tested with tiers1-4. Otherwise looks good, thanks! ------------- PR: https://git.openjdk.org/jdk/pull/11834 From rehn at openjdk.org Wed Jan 4 12:28:00 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 4 Jan 2023 12:28:00 GMT Subject: RFR: 8299274: Add elements to resolved_references consistently In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 01:39:19 GMT, David Holmes wrote: >> I added a resolved_references_at and set_resolved_references_at() functions to use for accesses to the resolved_references array, except for the CDS usages. This has an assert that the element is an oop and oob checks and setting elements use a CAS consistently. >> These asserts seem useful for finding the bug causing https://bugs.openjdk.org/browse/JDK-8296915. >> Tested with tiers1-4. > > src/hotspot/share/oops/constantPool.cpp line 181: > >> 179: >> 180: // Use a CAS for multithreaded access >> 181: oop ConstantPool::set_resolved_references_at(int index, oop new_result, oop old_result) { > > This function should be called `set_resolved_reference_at` - singular - as it sets one reference. Thanks. We never overwrite anything. I.e. we only store if the index is null. >From what I have seen in the code, anything else would be a bug? So I think this method is a bit to generic: bool set_resolved_reference_at(int index, oop value) Where we return false is that index already contains an oop? ------------- PR: https://git.openjdk.org/jdk/pull/11834 From ngasson at openjdk.org Wed Jan 4 12:29:14 2023 From: ngasson at openjdk.org (Nick Gasson) Date: Wed, 4 Jan 2023 12:29:14 GMT Subject: RFR: 8298482: Implement ParallelGC NUMAStats for Linux [v2] In-Reply-To: References: Message-ID: <2K2OnpQX5vxdcw0sX-uZ9hjYlRZyQrwPWIPnkwEXWe8=.17d5874b-937e-46e3-8fd7-56ecc4934a84@github.com> > ParallelGC has a seemingly useful option -XX:+NUMAStats that prints detailed information in GC.heap_info about which NUMA node pages in the eden space are bound to. However as far as I can tell this only ever worked on Solaris and is not implemented on any of the systems we currently support. This patch implements it on Linux using the move_pages system call. > > The function os::get_page_info() and accompanying struct page_info was just a thin wrapper around the Solaris meminfo(2) syscall and was never ported to other systems so I've just removed it rather than try to emulate its interface. > > There's also a method MutableNUMASpace::LGRPSpace::scan_pages() which attempts to find pages on the wrong NUMA node and frees them so that they have another chance to be allocated on the correct node by the first-touching thread, but I think this has always been a no-op on non-Solaris so perhaps should also be removed. On Linux it shouldn't be necessary as you can bind pages to the desired node directly. > > I don't know what the performance of this option was like on Solaris but on Linux the move_pages call can be quite slow: I measured about 25ms/GB on my system. At the moment we call LGRPSpace::accumulate_statistics() twice per GC cycle: I removed the second call as it's likely to see a lot of uncommitted pages if the spaces were just resized. MutableNUMASpace::print_on() also calls accumulate_statistics() directly and since that's the only place this data is used, maybe we can drop the call from MutableNUMASpace::accumulate_statistics() as well? > > Example output: > > > PSYoungGen total 4290560K, used 835628K [0x00000006aac00000, 0x0000000800000000, 0x0000000800000000) > eden space 3096576K, 1% used [0x00000006aac00000,0x00000007176a9f48,0x0000000767c00000) > lgrp 0 space 1761280K, 2% used [0x00000006aac00000,0x00000006acfc4980,0x0000000716400000) > local/remote/unbiased/uncommitted: 1671168K/0K/0K/90112K, large/small pages: 0/440320 > lgrp 1 space 1335296K, 46% used [0x0000000716400000,0x000000073c2abb18,0x0000000767c00000) > local/remote/unbiased/uncommitted: 1335296K/0K/0K/0K, large/small pages: 0/333824 > from space 1193984K, 65% used [0x00000007b7200000,0x00000007e6b9c778,0x0000000800000000) > to space 1247232K, 0% used [0x0000000767c00000,0x0000000767c00000,0x00000007b3e00000) > > > After testing this with SPECjbb for a while I noticed some pages always end up bound to the wrong node. I think this is a regression caused by JDK-8283935 but I'll raise a separate ticket for that. Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: No small/large page count, update copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11635/files - new: https://git.openjdk.org/jdk/pull/11635/files/f9c78f6e..c8333026 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11635&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11635&range=00-01 Stats: 18 lines in 7 files changed: 0 ins; 9 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/11635.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11635/head:pull/11635 PR: https://git.openjdk.org/jdk/pull/11635 From ngasson at openjdk.org Wed Jan 4 12:29:14 2023 From: ngasson at openjdk.org (Nick Gasson) Date: Wed, 4 Jan 2023 12:29:14 GMT Subject: RFR: 8298482: Implement ParallelGC NUMAStats for Linux [v2] In-Reply-To: References: Message-ID: <-DhAailkKqvr7bOATkjo5z5nz73JOE7YeKhXmZ1Vb_Y=.62355934-ed5d-4f2e-b2d6-91b5b8aa4966@github.com> On Tue, 3 Jan 2023 12:05:35 GMT, Albert Mingkun Yang wrote: >> I don't think so: for HugeTLBFS it makes some redundant calls but in my testing always returns the node ID for the containing huge page even if the address given is not huge page aligned, and for THP you don't know whether a particular address is backed by a huge page so you have to step with the smallest granularity anyway. With large pages enabled the "small/large pages" count is misleading but I don't know any way to get this information on Linux except by parsing `/proc/self/smaps` which we probably don't want to do. > > I see; thanks for the clarification. Re the misleading "small/large pages" count, can it be dropped? Or, what useful info does this count convey towards identifying wrongly placed OS pages? I don't think it adds any useful information now that the large page count is always zero: it's really just repeating the space size from the line above. I've removed it in the latest commit. ------------- PR: https://git.openjdk.org/jdk/pull/11635 From jwaters at openjdk.org Wed Jan 4 13:01:52 2023 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 4 Jan 2023 13:01:52 GMT Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof [v4] In-Reply-To: References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com> Message-ID: On Sun, 1 Jan 2023 02:15:56 GMT, Kim Barrett wrote: >> Something like this perhaps? >> >> - Prefer `alignof` ([n2341](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2341.pdf)) to `std::alignment_of<>`. The template has been superseded by the newer operator. > >> I'm not sure if it's a good idea to entirely forbid `std::alignment_of<>`? > > I disagree. > >> While `alignof` should be used over it most of the time, I'm somewhat certain >> it and it's other counterpart from C++17 (may) have certain differences from >> `alignof` in newer versions of the language ... > > `std::alignment_of::value` is defined as `alignof(T)` in every version of > the standard. The C++17 addition of `std::alignment_of_v` is just > abbreviated syntactic sugar, and is still more verbose than using `alignof`. I > see no other changes between versions of the standard, and would be surprised > if any were to come in the future. > >> ... (especially when used with templates and in metaprogramming contexts) ... > > `std::alignment_of<>` could be used in advanced metaprogramming contexts > involving higher order metafunctions. We don't do that sort of thing much at > all in HotSpot. If someone finds a place where `std::alignment_of<>` might be > better, we can revisit its status. > >> (Similar to how nullptr vs NULL is discussed in the Style Guide). > > nullptr vs NULL is a very different situation. New code and substantial > changes should use nullptr. But there is a large body of existing code using > NULL. When making a small modification to such code one might choose to > continue using NULL to be consistent with surrounding code. And one might > choose to keep such a change separate from a NULL => nullptr change in that > surrounding code. There are no current uses of `std::alignment_of<>` to be > consistent with. Alright, I'm convinced ------------- PR: https://git.openjdk.org/jdk/pull/11761 From jwaters at openjdk.org Wed Jan 4 13:02:20 2023 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 4 Jan 2023 13:02:20 GMT Subject: RFR: 8250269: Replace ATTRIBUTE_ALIGNED with alignas [v11] In-Reply-To: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com> References: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com> Message-ID: > 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 10 additional commits since the last revision: - 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 - ATTRIBUTE_ALIGNED(16) - Merge branch 'openjdk:master' into alignas - Merge branch 'openjdk:master' into alignas - Merge branch 'openjdk:master' into alignas - alignas ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11431/files - new: https://git.openjdk.org/jdk/pull/11431/files/d32d7b67..bbdb8ea3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11431&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11431&range=09-10 Stats: 2746 lines in 86 files changed: 1084 ins; 1532 del; 130 mod Patch: https://git.openjdk.org/jdk/pull/11431.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11431/head:pull/11431 PR: https://git.openjdk.org/jdk/pull/11431 From jwaters at openjdk.org Wed Jan 4 13:15:50 2023 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 4 Jan 2023 13:15:50 GMT Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof [v4] In-Reply-To: References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com> Message-ID: On Sat, 31 Dec 2022 04:12:29 GMT, Kim Barrett wrote: >> 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 seven additional commits since the last revision: >> >> - >> - Merge remote-tracking branch 'upstream/master' into alignof >> - Make section more brief >> - Merge remote-tracking branch 'upstream/master' into alignof >> - More Descriptive Version >> - Merge remote-tracking branch 'upstream/master' into alignof >> - HotSpot Style Guide should permit use of alignof > > doc/hotspot-style.md line 575: > >> 573: * `#include ` to use placement `new`, `std::nothrow`, and `std::nothrow_t`. >> 574: * `#include ` to use `std::numeric_limits`. >> 575: * `#include ` with some considerations, listed below. > > s/considerations/restrictions/ Changed, thanks > doc/hotspot-style.md line 578: > >> 576: * `#include ` to use `std::nullptr_t` and `std::max_align_t`. >> 577: >> 578: Certain declarations from `` should be avoided. > > s/should be avoided/are forbidden/ I'll just rewrite this one to say it has restrictions that apply to it, to match the line about it from above ------------- PR: https://git.openjdk.org/jdk/pull/11761 From jwaters at openjdk.org Wed Jan 4 13:23:08 2023 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 4 Jan 2023 13:23:08 GMT Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof [v5] In-Reply-To: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com> References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com> Message-ID: > The alignof operator was added by C++11. It returns the alignment for the given type. Various metaprogramming usages exist, in particular when using std::aligned_storage. Use of this operator should be permitted in HotSpot code. 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 ten additional commits since the last revision: - Hopefully final change - Merge remote-tracking branch 'upstream/master' into alignof - - Merge remote-tracking branch 'upstream/master' into alignof - Make section more brief - Merge remote-tracking branch 'upstream/master' into alignof - More Descriptive Version - Merge remote-tracking branch 'upstream/master' into alignof - HotSpot Style Guide should permit use of alignof ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11761/files - new: https://git.openjdk.org/jdk/pull/11761/files/cc5c61a4..f3fa278c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11761&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11761&range=03-04 Stats: 2756 lines in 88 files changed: 1084 ins; 1534 del; 138 mod Patch: https://git.openjdk.org/jdk/pull/11761.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11761/head:pull/11761 PR: https://git.openjdk.org/jdk/pull/11761 From mgronlun at openjdk.org Wed Jan 4 13:29:52 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 4 Jan 2023 13:29:52 GMT Subject: RFR: 8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly [v2] In-Reply-To: <-Bw1QEa8ENJ4arP1p27jW5J3scq3G6LhTOrqdr3pww4=.1e170716-a01b-4e64-952a-b9e05aefbbfb@github.com> References: <-Vajigb2X8yHp76kYNFVh58pp8XgB0A04odj5KEIFFw=.d7b72d1c-024f-4747-9a45-f4e9656b2f6a@github.com> <-Bw1QEa8ENJ4arP1p27jW5J3scq3G6LhTOrqdr3pww4=.1e170716-a01b-4e64-952a-b9e05aefbbfb@github.com> Message-ID: On Tue, 3 Jan 2023 16:19:01 GMT, Markus Gr?nlund wrote: >> ObjectAlignmentInBytes is 4 by default on 32 bit VMs. > > @fisk Why are the shifts needed on 64-bits? Maybe the shift is needed in order to handle unaligned oops, as for code blob oops? The existing root processing logic has up to now skipped code blob oops, mainly because they were hard to encode. The rationale was that they are not roots in and of themselves. Now, we have seen several instances where chains are not found on iterations, so maybe the assumption on skipping code blob oops is wrong. With this encoding scheme in place, it would be possible to pass a closure for processing the code blob oops as well. ------------- PR: https://git.openjdk.org/jdk/pull/11741 From eosterlund at openjdk.org Wed Jan 4 14:26:50 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 4 Jan 2023 14:26:50 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v2] In-Reply-To: References: <1rK2mzryGeyI-Yak0rUIqYZBuK5zrxCYwPe9zJbjHpY=.5471f1af-f8b8-4219-ae93-8b5a5fecaad9@github.com> Message-ID: On Tue, 3 Jan 2023 13:53:43 GMT, Markus Gr?nlund wrote: > The upshot with this solution compared to not having stacktraces for the ZPage Allocation Event is that only the relocation parts are sensitive? Other allocation sites can still have stacktraces? It's even more precise than that. Only relocation events... specifically when processing the stack watermark of the current thread, needs to emit stack traces. Any other relocation event can still print stack traces, and other allocation events as well. > src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp line 391: > >> 389: >> 390: bool ret = false; >> 391: StackWatermarkSet::start_processing(thread, StackWatermarkKind::gc); > > Is this now needed unconditionally, for all threads sampled? What is the overhead of introducing it? Compared to everything else that thread sampling does, I really wouldn't worry about it. In the common case it will just check if processing already started, and then continue. ------------- PR: https://git.openjdk.org/jdk/pull/11778 From mgronlun at openjdk.org Wed Jan 4 14:31:51 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 4 Jan 2023 14:31:51 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v2] In-Reply-To: References: <1rK2mzryGeyI-Yak0rUIqYZBuK5zrxCYwPe9zJbjHpY=.5471f1af-f8b8-4219-ae93-8b5a5fecaad9@github.com> Message-ID: On Wed, 4 Jan 2023 14:24:31 GMT, Erik ?sterlund wrote: >> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp line 391: >> >>> 389: >>> 390: bool ret = false; >>> 391: StackWatermarkSet::start_processing(thread, StackWatermarkKind::gc); >> >> Is this now needed unconditionally, for all threads sampled? What is the overhead of introducing it? > > Compared to everything else that thread sampling does, I really wouldn't worry about it. In the common case it will just check if processing already started, and then continue. The reason for asking is for upcoming changes that try to minimize everything involved in sampling. Is this only needed for virtual threads? ------------- PR: https://git.openjdk.org/jdk/pull/11778 From eosterlund at openjdk.org Wed Jan 4 14:33:55 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 4 Jan 2023 14:33:55 GMT Subject: Integrated: 8299079: Better interface nmethod oop accesses In-Reply-To: References: Message-ID: On Tue, 20 Dec 2022 08:29:09 GMT, Erik ?sterlund wrote: > Today when oops are read from nmethods, we use the same interfacing that we would use to read any other IN_NATIVE oops. That isn't enough for generational ZGC. The nmethod oops are rather different from other IN_NATIVE oops in that they are encoded in the machine code as direct pointers. Normally, IN_NATIVE oops with generational ZGC are not direct pointers, but are colored pointered that can be converted to direct pointers by going through a load barrier. For nmethod oops, that conversion requires external knowledge from the surrounding nmethod. I propose a new NMethodAccess to interface better with the GC. This pull request has now been integrated. Changeset: e3035bad Author: Erik ?sterlund URL: https://git.openjdk.org/jdk/commit/e3035bad60dfa71e9c24fcc509cd7f07eb2bf62e Stats: 25 lines in 3 files changed: 8 ins; 0 del; 17 mod 8299079: Better interface nmethod oop accesses Co-authored-by: Axel Boldt-Christmas Reviewed-by: kvn, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/11738 From jwilhelm at openjdk.org Wed Jan 4 14:34:19 2023 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Wed, 4 Jan 2023 14:34:19 GMT Subject: RFR: Merge jdk20 Message-ID: Forwardport JDK 20 -> JDK 21 ------------- Commit messages: - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20 - 8299476: PPC64 Zero build fails after JDK-8286302 - 8293824: gc/whitebox/TestConcMarkCycleWB.java failed "RuntimeException: assertTrue: expected true, was false" - 8299483: ProblemList java/text/Format/NumberFormat/CurrencyFormat.java - 8298324: Unable to run shell test with make - 8299235: broken link referencing missing id The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk&pr=11845&range=00.0 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=11845&range=00.1 Changes: https://git.openjdk.org/jdk/pull/11845/files Stats: 299 lines in 28 files changed: 101 ins; 131 del; 67 mod Patch: https://git.openjdk.org/jdk/pull/11845.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11845/head:pull/11845 PR: https://git.openjdk.org/jdk/pull/11845 From coleenp at openjdk.org Wed Jan 4 14:41:53 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 4 Jan 2023 14:41:53 GMT Subject: RFR: 8299274: Add elements to resolved_references consistently In-Reply-To: References: Message-ID: <18n8HYwpEyNUEhK9E2RrBGUlY0ziThN-DLXsjAvJNQI=.3bb346a4-e79e-4c09-b005-fc82080121c4@github.com> On Wed, 4 Jan 2023 01:38:08 GMT, David Holmes wrote: >> I added a resolved_references_at and set_resolved_references_at() functions to use for accesses to the resolved_references array, except for the CDS usages. This has an assert that the element is an oop and oob checks and setting elements use a CAS consistently. >> These asserts seem useful for finding the bug causing https://bugs.openjdk.org/browse/JDK-8296915. >> Tested with tiers1-4. > > src/hotspot/share/oops/constantPool.cpp line 174: > >> 172: } >> 173: >> 174: oop ConstantPool::resolved_references_at(int index) const { > > This function should be called `resolved_reference_at` - singular - as it returns one reference. Thanks. I have it resolved_references because that's the name of the array and I want to keep that as a string to search on. ------------- PR: https://git.openjdk.org/jdk/pull/11834 From coleenp at openjdk.org Wed Jan 4 14:41:56 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 4 Jan 2023 14:41:56 GMT Subject: RFR: 8299274: Add elements to resolved_references consistently In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 12:24:49 GMT, Robbin Ehn wrote: >> src/hotspot/share/oops/constantPool.cpp line 181: >> >>> 179: >>> 180: // Use a CAS for multithreaded access >>> 181: oop ConstantPool::set_resolved_references_at(int index, oop new_result, oop old_result) { >> >> This function should be called `set_resolved_reference_at` - singular - as it sets one reference. Thanks. > > We never overwrite anything. I.e. we only store if the index is null. > From what I have seen in the code, anything else would be a bug? (as in we never change an object in the array) > > So I think this method is a bit to generic: > bool set_resolved_reference_at(int index, oop value) > Where we return false if that index already contains an oop? The reason I made it resolved_references plural is so you can grep on resolved_references and see all operations on this array. We do not overwrite anything. We may have multiple threads writing the same string to it. There's an assert in string_at_put: assert(result == nullptr || result == str, "Only set once or to the same string."); I need it to return the existing value for the code in resolve_constant_at_impl(). ------------- PR: https://git.openjdk.org/jdk/pull/11834 From fparain at openjdk.org Wed Jan 4 14:47:55 2023 From: fparain at openjdk.org (Frederic Parain) Date: Wed, 4 Jan 2023 14:47:55 GMT Subject: RFR: 8299274: Add elements to resolved_references consistently In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 14:38:05 GMT, Coleen Phillimore wrote: >> We never overwrite anything. I.e. we only store if the index is null. >> From what I have seen in the code, anything else would be a bug? (as in we never change an object in the array) >> >> So I think this method is a bit to generic: >> bool set_resolved_reference_at(int index, oop value) >> Where we return false if that index already contains an oop? > > The reason I made it resolved_references plural is so you can grep on resolved_references and see all operations on this array. > > We do not overwrite anything. We may have multiple threads writing the same string to it. There's an assert in string_at_put: > assert(result == nullptr || result == str, "Only set once or to the same string."); > > I need it to return the existing value for the code in resolve_constant_at_impl(). Shouldn't this method check the validity of the index argument? ------------- PR: https://git.openjdk.org/jdk/pull/11834 From eosterlund at openjdk.org Wed Jan 4 14:50:20 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 4 Jan 2023 14:50:20 GMT Subject: RFR: 8299312: Clean up BarrierSetNMethod [v2] In-Reply-To: References: Message-ID: > The terminology in BarrierSetNMethod is not crisp. In platform code we talk about a per-nmethod "guard value", but on shared level we call the same value arm value or disarm value in different contexts. But it really depends on the value whether the nmethod is disarmed or armed. We should embrace the "guard value" terminology and lift it in to the shared code level. > We also have more functionality than we need on platform level. The platform level only needs to know how to deoptimize, and how to set/get the guard value of an nmethod. The more specific functionality should be moved to the shared code and be expressed in terms of said setter/getter. Erik ?sterlund 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: - ARM support - Merge branch 'master' into 8299312_barrier_set_nmethod_cleanup - Fix Shenandoah build - 8299312: Clean up BarrierSetNMethod ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11774/files - new: https://git.openjdk.org/jdk/pull/11774/files/78afd161..e0b32db3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11774&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11774&range=00-01 Stats: 9893 lines in 672 files changed: 5058 ins; 2615 del; 2220 mod Patch: https://git.openjdk.org/jdk/pull/11774.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11774/head:pull/11774 PR: https://git.openjdk.org/jdk/pull/11774 From rehn at openjdk.org Wed Jan 4 14:52:54 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 4 Jan 2023 14:52:54 GMT Subject: RFR: 8299274: Add elements to resolved_references consistently In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 14:44:07 GMT, Frederic Parain wrote: >> The reason I made it resolved_references plural is so you can grep on resolved_references and see all operations on this array. >> >> We do not overwrite anything. We may have multiple threads writing the same string to it. There's an assert in string_at_put: >> assert(result == nullptr || result == str, "Only set once or to the same string."); >> >> I need it to return the existing value for the code in resolve_constant_at_impl(). > > Shouldn't this method check the validity of the index argument? > I need it to return the existing value for the code in resolve_constant_at_impl(). So it's a getter/setter, but if the argument must be nullptr, I think we should skip it. ------------- PR: https://git.openjdk.org/jdk/pull/11834 From fparain at openjdk.org Wed Jan 4 14:47:54 2023 From: fparain at openjdk.org (Frederic Parain) Date: Wed, 4 Jan 2023 14:47:54 GMT Subject: RFR: 8299274: Add elements to resolved_references consistently In-Reply-To: References: Message-ID: <0vFePPy47bCBwVpd2iK4lgYhDnkYtQ-xL5_gMu5CzcQ=.bd5d6d04-716f-4f91-8b86-2b42bcbffaa7@github.com> On Tue, 3 Jan 2023 18:35:20 GMT, Coleen Phillimore wrote: > I added a resolved_references_at and set_resolved_references_at() functions to use for accesses to the resolved_references array, except for the CDS usages. This has an assert that the element is an oop and oob checks and setting elements use a CAS consistently. > These asserts seem useful for finding the bug causing https://bugs.openjdk.org/browse/JDK-8296915. > Tested with tiers1-4. Changes requested by fparain (Committer). ------------- PR: https://git.openjdk.org/jdk/pull/11834 From eosterlund at openjdk.org Wed Jan 4 14:53:02 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 4 Jan 2023 14:53:02 GMT Subject: Integrated: 8299072: java_lang_ref_Reference::clear_referent should be GC agnostic In-Reply-To: References: Message-ID: On Tue, 20 Dec 2022 07:05:34 GMT, Erik ?sterlund wrote: > The current java_lang_ref_Reference::clear_referent implementation performs a raw reference clear. That doesn't work well with upcoming GC algorithms. It should be made GC agnostic by going through the normal access API. This pull request has now been integrated. Changeset: c32a34c2 Author: Erik ?sterlund URL: https://git.openjdk.org/jdk/commit/c32a34c2e534147bccf8320b095edda9e1088f5a Stats: 8 lines in 5 files changed: 5 ins; 0 del; 3 mod 8299072: java_lang_ref_Reference::clear_referent should be GC agnostic Co-authored-by: Axel Boldt-Christmas Reviewed-by: dholmes, shade, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/11736 From coleenp at openjdk.org Wed Jan 4 15:13:50 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 4 Jan 2023 15:13:50 GMT Subject: RFR: 8299274: Add elements to resolved_references consistently In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 14:49:47 GMT, Robbin Ehn wrote: >> Shouldn't this method check the validity of the index argument? > >> I need it to return the existing value for the code in resolve_constant_at_impl(). > > So it's a getter/setter, but if the argument must be nullptr, I think we should skip it. obj_at_put already checks the index. ------------- PR: https://git.openjdk.org/jdk/pull/11834 From eosterlund at openjdk.org Wed Jan 4 15:36:51 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 4 Jan 2023 15:36:51 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v2] In-Reply-To: References: <1rK2mzryGeyI-Yak0rUIqYZBuK5zrxCYwPe9zJbjHpY=.5471f1af-f8b8-4219-ae93-8b5a5fecaad9@github.com> Message-ID: On Wed, 4 Jan 2023 14:28:44 GMT, Markus Gr?nlund wrote: >> Compared to everything else that thread sampling does, I really wouldn't worry about it. In the common case it will just check if processing already started, and then continue. > > The reason for asking is for upcoming changes that try to minimize everything involved in sampling. Is this only needed for virtual threads? I see. It is indeed only needed for virtual threads. If you are going to perform very frequent sampling, then it's worth mentioning that the check if the processing already started requires load_acquire on non-TSO platforms. I suppose that would be the dominating cost. But for this load_acquire to start showing up as a significant overhead, I think you would have to do sampling in the order of magnitude of hundreds of nanosecond interval levels. So unless you are getting to such intense frequencies, I think I would still not worry about it. What do you think? ------------- PR: https://git.openjdk.org/jdk/pull/11778 From mgronlun at openjdk.org Wed Jan 4 15:41:55 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 4 Jan 2023 15:41:55 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v2] In-Reply-To: References: <1rK2mzryGeyI-Yak0rUIqYZBuK5zrxCYwPe9zJbjHpY=.5471f1af-f8b8-4219-ae93-8b5a5fecaad9@github.com> Message-ID: On Wed, 4 Jan 2023 15:33:46 GMT, Erik ?sterlund wrote: >> The reason for asking is for upcoming changes that try to minimize everything involved in sampling. Is this only needed for virtual threads? > > I see. It is indeed only needed for virtual threads. If you are going to perform very frequent sampling, then it's worth mentioning that the check if the processing already started requires load_acquire on non-TSO platforms. I suppose that would be the dominating cost. But for this load_acquire to start showing up as a significant overhead, I think you would have to do sampling in the order of magnitude of hundreds of nanosecond interval levels. So unless you are getting to such intense frequencies, I think I would still not worry about it. What do you think? Thanks for the information, Erik. I think we can go with your solution, I will take the information about virtual threads into account for later, there is still a lot of magic left that needs to be done in the new sampling system in order to incorporate them. ------------- PR: https://git.openjdk.org/jdk/pull/11778 From duke at openjdk.org Wed Jan 4 15:41:58 2023 From: duke at openjdk.org (Johannes Bechberger) Date: Wed, 4 Jan 2023 15:41:58 GMT Subject: RFR: 8297967: Make frame::safe_for_sender safer [v5] In-Reply-To: References: Message-ID: On Wed, 7 Dec 2022 12:09:24 GMT, Johannes Bechberger wrote: >> Makes frame::safe_for_sender safer by using os::is_readable_pointer to check the location of the return address. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Remove check for value that might be null This is ongoing work. ------------- PR: https://git.openjdk.org/jdk/pull/11461 From mdoerr at openjdk.org Wed Jan 4 15:43:57 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 4 Jan 2023 15:43:57 GMT Subject: RFR: 8299312: Clean up BarrierSetNMethod [v2] In-Reply-To: References: Message-ID: <6kIYLSUVYIVvoKhLGGhYowSFyY09rWE07Tw4le5q2Bw=.90fed758-0136-4b5c-bd9f-73821c010930@github.com> On Wed, 4 Jan 2023 14:50:20 GMT, Erik ?sterlund wrote: >> The terminology in BarrierSetNMethod is not crisp. In platform code we talk about a per-nmethod "guard value", but on shared level we call the same value arm value or disarm value in different contexts. But it really depends on the value whether the nmethod is disarmed or armed. We should embrace the "guard value" terminology and lift it in to the shared code level. >> We also have more functionality than we need on platform level. The platform level only needs to know how to deoptimize, and how to set/get the guard value of an nmethod. The more specific functionality should be moved to the shared code and be expressed in terms of said setter/getter. > > Erik ?sterlund 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: > > - ARM support > - Merge branch 'master' into 8299312_barrier_set_nmethod_cleanup > - Fix Shenandoah build > - 8299312: Clean up BarrierSetNMethod LGTM. ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.org/jdk/pull/11774 From fparain at openjdk.org Wed Jan 4 15:45:10 2023 From: fparain at openjdk.org (Frederic Parain) Date: Wed, 4 Jan 2023 15:45:10 GMT Subject: RFR: 8299274: Add elements to resolved_references consistently [v2] In-Reply-To: <7yGH808nkOftbFghjt7qlv1lVr3N8oAUvaZ40ut6ixo=.89474824-7dff-46cd-b163-11669642bd69@github.com> References: <7yGH808nkOftbFghjt7qlv1lVr3N8oAUvaZ40ut6ixo=.89474824-7dff-46cd-b163-11669642bd69@github.com> Message-ID: On Wed, 4 Jan 2023 15:41:22 GMT, Coleen Phillimore wrote: >> I added a resolved_references_at and set_resolved_references_at() functions to use for accesses to the resolved_references array, except for the CDS usages. This has an assert that the element is an oop and oob checks and setting elements use a CAS consistently. >> These asserts seem useful for finding the bug causing https://bugs.openjdk.org/browse/JDK-8296915. >> Tested with tiers1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Change to objArrayOop to replace_if_null since that is what it's doing. Marked as reviewed by fparain (Committer). ------------- PR: https://git.openjdk.org/jdk/pull/11834 From rehn at openjdk.org Wed Jan 4 15:45:11 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 4 Jan 2023 15:45:11 GMT Subject: RFR: 8299274: Add elements to resolved_references consistently [v2] In-Reply-To: <7yGH808nkOftbFghjt7qlv1lVr3N8oAUvaZ40ut6ixo=.89474824-7dff-46cd-b163-11669642bd69@github.com> References: <7yGH808nkOftbFghjt7qlv1lVr3N8oAUvaZ40ut6ixo=.89474824-7dff-46cd-b163-11669642bd69@github.com> Message-ID: On Wed, 4 Jan 2023 15:41:22 GMT, Coleen Phillimore wrote: >> I added a resolved_references_at and set_resolved_references_at() functions to use for accesses to the resolved_references array, except for the CDS usages. This has an assert that the element is an oop and oob checks and setting elements use a CAS consistently. >> These asserts seem useful for finding the bug causing https://bugs.openjdk.org/browse/JDK-8296915. >> Tested with tiers1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Change to objArrayOop to replace_if_null since that is what it's doing. Thanks! ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11834 From coleenp at openjdk.org Wed Jan 4 15:45:10 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 4 Jan 2023 15:45:10 GMT Subject: RFR: 8299274: Add elements to resolved_references consistently [v2] In-Reply-To: References: Message-ID: <7yGH808nkOftbFghjt7qlv1lVr3N8oAUvaZ40ut6ixo=.89474824-7dff-46cd-b163-11669642bd69@github.com> > I added a resolved_references_at and set_resolved_references_at() functions to use for accesses to the resolved_references array, except for the CDS usages. This has an assert that the element is an oop and oob checks and setting elements use a CAS consistently. > These asserts seem useful for finding the bug causing https://bugs.openjdk.org/browse/JDK-8296915. > Tested with tiers1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Change to objArrayOop to replace_if_null since that is what it's doing. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11834/files - new: https://git.openjdk.org/jdk/pull/11834/files/d10796da..50ff492c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11834&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11834&range=00-01 Stats: 14 lines in 6 files changed: 0 ins; 1 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/11834.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11834/head:pull/11834 PR: https://git.openjdk.org/jdk/pull/11834 From xuelei at openjdk.org Wed Jan 4 15:47:56 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 4 Jan 2023 15:47:56 GMT Subject: RFR: 8299378: sprintf is deprecated in Xcode 14 [v3] In-Reply-To: <-hkjhJ8w2GhJaQNTUWPNV4KJAFt2RcTKS4ywxBj2xXI=.62cfe4d7-c523-45f4-80bd-21e6c407dbce@github.com> References: <-hkjhJ8w2GhJaQNTUWPNV4KJAFt2RcTKS4ywxBj2xXI=.62cfe4d7-c523-45f4-80bd-21e6c407dbce@github.com> Message-ID: On Wed, 4 Jan 2023 11:40:23 GMT, Christoph wrote: > @XueleiFan Unfortunately I still get the same error even after this PR was merged. @Siedlerchr Would you please share the platform information? Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/11793 From mgronlun at openjdk.org Wed Jan 4 15:48:53 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 4 Jan 2023 15:48:53 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v2] In-Reply-To: References: <1rK2mzryGeyI-Yak0rUIqYZBuK5zrxCYwPe9zJbjHpY=.5471f1af-f8b8-4219-ae93-8b5a5fecaad9@github.com> Message-ID: <0A2u_ZuEnM9aOilTWrinh9Csvi3zOT9__aSw6vc8L1Y=.dcdf6f0c-5e9d-4744-bb87-8a3c0b2af8f4@github.com> On Fri, 23 Dec 2022 14:53:38 GMT, Erik ?sterlund wrote: >> The JfrVFrameStream is used while generating stack traces for events. One of the events are the ZPage allocation event. This event is sometimes sent when ZGC is relocating. The current implementation of JfrVFrameStream uses WalkContinuation::include, which causes JFR to walk the continuation and perform GC barriers. This is problematic, since ZGC has a requirement that we never perform load barriers while running the relocation code. If we do, we might end up performing other reloctions from the the relocation code, and in some cases that causes dead locks. >> >> I propose that JFR doesn't walk the stack during stack watermark processing. This PR implements that change. This PR replaces https://github.com/openjdk/jdk/pull/11586 > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Fix release build src/hotspot/share/runtime/disableStackTracingMark.hpp line 36: > 34: // Use this class to mark a section of code where stack tracing is not safe > 35: // and should be avoided. > 36: class DisableStackTracingMark : public StackObj { One thing that could perhaps be a bit of a gotcha with this is the name selection, "DisableStackTracingMark". One could get the impression that this disables stack traces entirely. But this is not the case for asynchronous operations, like AsyncGetCallTrace and JFR - they fetch the information from the CPU context to produce a stacktrace, if there is no ljf. Not a biggie, but might be confusing. Perhaps "NoLastJavaFrame" or something? ------------- PR: https://git.openjdk.org/jdk/pull/11778 From ayang at openjdk.org Wed Jan 4 15:55:50 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 4 Jan 2023 15:55:50 GMT Subject: RFR: 8298482: Implement ParallelGC NUMAStats for Linux [v2] In-Reply-To: <2K2OnpQX5vxdcw0sX-uZ9hjYlRZyQrwPWIPnkwEXWe8=.17d5874b-937e-46e3-8fd7-56ecc4934a84@github.com> References: <2K2OnpQX5vxdcw0sX-uZ9hjYlRZyQrwPWIPnkwEXWe8=.17d5874b-937e-46e3-8fd7-56ecc4934a84@github.com> Message-ID: On Wed, 4 Jan 2023 12:29:14 GMT, Nick Gasson wrote: >> ParallelGC has a seemingly useful option -XX:+NUMAStats that prints detailed information in GC.heap_info about which NUMA node pages in the eden space are bound to. However as far as I can tell this only ever worked on Solaris and is not implemented on any of the systems we currently support. This patch implements it on Linux using the move_pages system call. >> >> The function os::get_page_info() and accompanying struct page_info was just a thin wrapper around the Solaris meminfo(2) syscall and was never ported to other systems so I've just removed it rather than try to emulate its interface. >> >> There's also a method MutableNUMASpace::LGRPSpace::scan_pages() which attempts to find pages on the wrong NUMA node and frees them so that they have another chance to be allocated on the correct node by the first-touching thread, but I think this has always been a no-op on non-Solaris so perhaps should also be removed. On Linux it shouldn't be necessary as you can bind pages to the desired node directly. >> >> I don't know what the performance of this option was like on Solaris but on Linux the move_pages call can be quite slow: I measured about 25ms/GB on my system. At the moment we call LGRPSpace::accumulate_statistics() twice per GC cycle: I removed the second call as it's likely to see a lot of uncommitted pages if the spaces were just resized. MutableNUMASpace::print_on() also calls accumulate_statistics() directly and since that's the only place this data is used, maybe we can drop the call from MutableNUMASpace::accumulate_statistics() as well? >> >> Example output: >> >> >> PSYoungGen total 4290560K, used 835628K [0x00000006aac00000, 0x0000000800000000, 0x0000000800000000) >> eden space 3096576K, 1% used [0x00000006aac00000,0x00000007176a9f48,0x0000000767c00000) >> lgrp 0 space 1761280K, 2% used [0x00000006aac00000,0x00000006acfc4980,0x0000000716400000) >> local/remote/unbiased/uncommitted: 1671168K/0K/0K/90112K, large/small pages: 0/440320 >> lgrp 1 space 1335296K, 46% used [0x0000000716400000,0x000000073c2abb18,0x0000000767c00000) >> local/remote/unbiased/uncommitted: 1335296K/0K/0K/0K, large/small pages: 0/333824 >> from space 1193984K, 65% used [0x00000007b7200000,0x00000007e6b9c778,0x0000000800000000) >> to space 1247232K, 0% used [0x0000000767c00000,0x0000000767c00000,0x00000007b3e00000) >> >> >> After testing this with SPECjbb for a while I noticed some pages always end up bound to the wrong node. I think this is a regression caused by JDK-8283935 but I'll raise a separate ticket for that. > > Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: > > No small/large page count, update copyright year > maybe we can drop the call from MutableNUMASpace::accumulate_statistics() as well? Agree. The rest look good. ------------- Marked as reviewed by ayang (Reviewer). PR: https://git.openjdk.org/jdk/pull/11635 From jwilhelm at openjdk.org Wed Jan 4 16:06:57 2023 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Wed, 4 Jan 2023 16:06:57 GMT Subject: Integrated: Merge jdk20 In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 14:25:12 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 20 -> JDK 21 This pull request has now been integrated. Changeset: df1caf90 Author: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/df1caf90818558b897a6b8ab80757f2a03398c55 Stats: 299 lines in 28 files changed: 101 ins; 131 del; 67 mod Merge ------------- PR: https://git.openjdk.org/jdk/pull/11845 From mbaesken at openjdk.org Wed Jan 4 16:10:50 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 4 Jan 2023 16:10:50 GMT Subject: RFR: JDK-8296995: ostream should handle snprintf(3) errors in release builds [v4] In-Reply-To: References: Message-ID: <5skwoE6TrkvdGwZAI1WDrWez3QPfU4xqF6FFBrGfL7c=.2b3a3657-e527-4521-a321-a3a479dd072b@github.com> On Wed, 7 Dec 2022 14:15:59 GMT, Thomas Stuefe wrote: >> Small fix for a very unlikely problem. >> >> All streams in ostream.hpp end up using `os::snprintf()`, which uses `::vsnprintf()`. `vsnprintf(3)`can fail and return -1. >> >> The chance for this to happen is small. snprintf errors are usually encoding errors though not always (see third example at https://stackoverflow.com/questions/65334245/what-is-an-encoding-error-for-sprintf-that-should-return-1). I found "%ls" in one place in windows coding, so I am not sure we can always exclude the possibility of wide strings being used in our code base, or that of printing with outside-provided format strings. >> >> In case of an error, we assert in debug builds but don't handle it in release. There, this situation gets misdiagnosed later as a buffer overflow because we cast the signedness of the result away (see `outputStream::do_vsnprintf()`). >> >> --- >> >> The patch is trivial. The most exciting thing is the gtest, I guess. >> >> In release builds, we now treat this condition as an empty string write. I considered printing a clear marker into the stream instead, e.g. "ENCODING ERROR", but ultimately did not do it. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > fix copyright Can't this be integrated ? What's missing? ------------- PR: https://git.openjdk.org/jdk/pull/11160 From djelinski at openjdk.org Wed Jan 4 16:13:53 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 4 Jan 2023 16:13:53 GMT Subject: RFR: 8294403: [REDO] make test should report only on executed tests [v2] In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 09:15:18 GMT, Aleksey Shipilev wrote: >> This should help to speed up tests significantly. Currently, if we run "make test" with a subset of tests, JTReg would still read the entirety of test root to report on tests that were not run. Even with current suite of tests it gets expensive. If you add more tests to suite -- for example, mounting a large test archive like pre-generated fuzzer tests -- it starts to take a lot of time. >> >> The reasonable default for older jtreg is `-report:executed`. My own CI -- that has millions of tests mounted in `test/` -- was running with `JTREG="OPTIONS=-report:executed"` for years now. [CODETOOLS-7903323](https://bugs.openjdk.org/browse/CODETOOLS-7903323) provides a new reporting option, `-report:files`, which makes this whole business easier. This requires new jtreg. >> >> Motivational improvements: >> >> >> $ time CONF=linux-x86_64-server-release make run-test TEST=gc/epsilon/TestHelloWorld.java >> >> # Default JDK tree >> >> # Baseline >> real 0m9.086s >> user 0m22.857s >> sys 0m4.202s >> >> # Patched >> real 0m6.406s ; +40% faster >> user 0m17.156s >> sys 0m3.193s >> >> # +100K fuzzer tests in tree >> >> # Baseline >> real 3m1.997s >> user 3m16.643s >> sys 0m10.490s >> >> # Patched >> real 0m8.919s ; 20x faster >> user 0m17.904s >> sys 0m4.860s >> >> >> Additional testing: >> - [x] Ad-hoc timing tests (see above) >> - [x] Reproducer from [CODETOOLS-7903331](https://bugs.openjdk.org/browse/CODETOOLS-7903331) >> - [x] Eyeballing the test results on passing tests with REPEAT_COUNT > 1 >> - [x] Eyeballing the test results on intermittently failing tests with RETRY_COUNT > 1 > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Copyright years I like this! $ time make run-test TEST=jdk/java/net/BindException/Test.java: # baseline: real 0m43.176s user 0m12.453s sys 1m13.797s # patched: real 0m22.558s user 0m10.797s sys 1m1.734s ------------- Marked as reviewed by djelinski (Committer). PR: https://git.openjdk.org/jdk/pull/11824 From eosterlund at openjdk.org Wed Jan 4 16:13:55 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 4 Jan 2023 16:13:55 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v2] In-Reply-To: <0A2u_ZuEnM9aOilTWrinh9Csvi3zOT9__aSw6vc8L1Y=.dcdf6f0c-5e9d-4744-bb87-8a3c0b2af8f4@github.com> References: <1rK2mzryGeyI-Yak0rUIqYZBuK5zrxCYwPe9zJbjHpY=.5471f1af-f8b8-4219-ae93-8b5a5fecaad9@github.com> <0A2u_ZuEnM9aOilTWrinh9Csvi3zOT9__aSw6vc8L1Y=.dcdf6f0c-5e9d-4744-bb87-8a3c0b2af8f4@github.com> Message-ID: On Wed, 4 Jan 2023 15:45:33 GMT, Markus Gr?nlund wrote: >> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix release build > > src/hotspot/share/runtime/disableStackTracingMark.hpp line 36: > >> 34: // Use this class to mark a section of code where stack tracing is not safe >> 35: // and should be avoided. >> 36: class DisableStackTracingMark : public StackObj { > > One thing that could perhaps be a bit of a gotcha with this is the name selection, "DisableStackTracingMark". One could get the impression that this disables stack traces entirely. But this is not the case for asynchronous operations, like AsyncGetCallTrace and JFR - they fetch the information from the CPU context to produce a stacktrace, if there is no ljf. Not a biggie, but might be confusing. Perhaps "NoLastJavaFrame" or something? Good point. I'll try to think of a better name. ------------- PR: https://git.openjdk.org/jdk/pull/11778 From duke at openjdk.org Wed Jan 4 16:35:00 2023 From: duke at openjdk.org (Christoph) Date: Wed, 4 Jan 2023 16:35:00 GMT Subject: RFR: 8299378: sprintf is deprecated in Xcode 14 [v3] In-Reply-To: References: Message-ID: On Tue, 3 Jan 2023 16:28:54 GMT, Xue-Lei Andrew Fan wrote: >> The `sprintf` is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812), but the test was not covered. The failure was [reported later](https://github.com/openjdk/jdk/pull/11115#issuecomment-1344973773), while gtest is enabled for building. >> >> This patch is just to make sure the building could pass. Other than that, the use of `sprintf` in other places are not touched. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > sort includes alphabetically Ventura 13.1 (22C65) SDK: MacOSX13.1.sdk (XCode 14.2) macosx-aarch64-server-release Full log (I commented out that line in libAsyncExceptionOnMonitorEnter, therefore the following came up) I am happy to test any further fixes. === Output from failing command(s) repeated here === * For target support_test_hotspot_jtreg_native_support_libthreadend01_libthreadend01.o: ------------- PR: https://git.openjdk.org/jdk/pull/11793 From mikael at openjdk.org Wed Jan 4 19:49:50 2023 From: mikael at openjdk.org (Mikael Vidstedt) Date: Wed, 4 Jan 2023 19:49:50 GMT Subject: RFR: 8299254: Support dealing with standard assert macro In-Reply-To: <6VQwFg9prwXbOwp_asHA4-Wru6PdKvaRN8MGiU24_sw=.1cafd8ea-e7e4-4a9d-a8ba-4f0cf87621d2@github.com> References: <6VQwFg9prwXbOwp_asHA4-Wru6PdKvaRN8MGiU24_sw=.1cafd8ea-e7e4-4a9d-a8ba-4f0cf87621d2@github.com> Message-ID: On Thu, 22 Dec 2022 23:05:03 GMT, Kim Barrett wrote: > Please review this change to provide and use mechanisms for dealing with uses > of the standard assert macro (from or ) in 3rd party code > that we use in HotSpot. > > We provide a pair of utility header files, to be included before and after a > header that may use (and so include) the standard assert macro. These new > headers provide a scope in which the HotSpot assert macro is not defined, and > then reinstated after. > > We also define NDEBUG in release builds of HotSpot, so any uses of the > standard assert macro in such 3rd party code will be disabled. > > Finally, we use the new utility headers in some gtests and in our gtest > wrapper header (unittest.hpp), eliminating problems the gtest implementation > and with some versions of some standard libraries that the tests use. > > Testing: > mach5 tier1 Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11770 From kvn at openjdk.org Wed Jan 4 20:25:50 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 4 Jan 2023 20:25:50 GMT Subject: RFR: 8298720: Insufficient error handling when CodeBuffer is exhausted In-Reply-To: References: Message-ID: <0ltwqSDWed6m8E2IIH_MIUMvIiA6rI43OcKVFXH2Ux8=.a1356f15-3d49-491e-9afc-ebde241c5a5c@github.com> On Wed, 4 Jan 2023 06:31:16 GMT, Tobias Hartmann wrote: > This patch fixes various places in C1 and C2 on Aarch64 and RISC-V that miss proper error handling when the code buffer is exhausted, leading to crashes. Similar but incomplete patches went in with [JDK-8130309](https://bugs.openjdk.org/browse/JDK-8130309), [JDK-8248411](https://bugs.openjdk.org/browse/JDK-8248411) and [JDK-8272094](https://bugs.openjdk.org/browse/JDK-8272094) in the past. > > These issues are extremely hard to reproduce, even with the `-XX:+StressCodeBuffers` option, because code buffer expansion needs to fail at the exact moment when a specific (unhandled) instruction is emitted. Even with the stress option, we expand the code buffer such that multiple instructions will fit and in addition, chances are high that we simply bail out from compilation before emitting the problematic instruction. I attached a patch to [JDK-8298720](https://bugs.openjdk.org/browse/JDK-8298720), that makes `-XX:+StressCodeBuffers` randomized and more aggressive. With that, I can reproduce the issue reliably but it's extremely slow and therefore not well suited for integration. > > I now went over all usages of `CodeBuffer::expand` to make sure that we have proper error handling in place and found some remaining issues in JVMCI code. I filed [JDK-8299570](https://bugs.openjdk.org/browse/JDK-8299570) to address them. > > I would need help to test the RISC-V specific changes. > > Thanks, > Tobias My main question is: can we do bailout in `MacroAssembler::trampoline_call()` instead of later in all over places? In `c1_LIRAssembler_ppc.cpp` it bailout in emit_trampoline_stub_for_call(). src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp line 1205: > 1203: *op->stub()->entry()); > 1204: if (tpc == nullptr) { > 1205: bailout("trampoline stub overflow"); The message is confusing. How about `"no space for trampoline stub"` used in `c1_LIRAssembler_ppc.cpp`. ------------- PR: https://git.openjdk.org/jdk/pull/11839 From mikael.vidstedt at oracle.com Wed Jan 4 21:07:13 2023 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 4 Jan 2023 21:07:13 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Patricio Chilano Mateo In-Reply-To: References: Message-ID: <9ACB13F6-C903-4D79-BB59-39C0457C2E5C@oracle.com> Vote: yes Cheers, Mikael > On Jan 3, 2023, at 8:20 AM, coleen.phillimore at oracle.com wrote: > > I hereby nominate Patricio Chilano Mateo [pchilomate] to Membership in the hotspot Group. > > Patricio is an OpenJDK Reviewer and a member of the HotSpot runtime team at Oracle. Since 2018 he has worked on improvements and bug fixes mainly in the areas of locking, safepoint synchronization, thread state transitions, and handshakes. He is currently working on Loom changes for virtual thread preemption. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vote > > From mikael.vidstedt at oracle.com Wed Jan 4 21:07:28 2023 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 4 Jan 2023 21:07:28 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Robbin Ehn In-Reply-To: <7652c110-0767-bf12-dd32-8cde03ba6fc7@oracle.com> References: <7652c110-0767-bf12-dd32-8cde03ba6fc7@oracle.com> Message-ID: Vote: yes Cheers, Mikael > On Jan 3, 2023, at 8:18 AM, coleen.phillimore at oracle.com wrote: > > I hereby nominate Robbin Ehn [rehn] to Membership in the hotspot Group. > > Robbin Ehn is an OpenJDK Reviewer and a member of the HotSpot runtime team at Oracle. He has contributed a concurrent hash table, synchronization performance improvements and bug fixes to the HotSpot code base. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vote > > From mikael.vidstedt at oracle.com Wed Jan 4 21:07:43 2023 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 4 Jan 2023 21:07:43 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Serguei Spitsyn In-Reply-To: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> References: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> Message-ID: <6515E910-6891-439D-8EE0-7FC57A24E98F@oracle.com> Vote: yes Cheers, Mikael > On Jan 3, 2023, at 8:27 AM, coleen.phillimore at oracle.com wrote: > > I hereby nominate Serguei Spitsyn [sspitsyn] to Membership in the hotspot Group. > > Serguei is an OpenJDK reviewer and a member of the HotSpot serviceability team at Oracle. He is lead for the serviceability project [1] and a technical lead in HotSpot. He has recently implemented JVMTI support for the Loom project. He is already member of the OpenJDK members group. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#serviceability > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > From mikael.vidstedt at oracle.com Wed Jan 4 21:08:06 2023 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 4 Jan 2023 21:08:06 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Frederic Parain In-Reply-To: <175ece63-eb89-ba46-52aa-270762e122c2@oracle.com> References: <175ece63-eb89-ba46-52aa-270762e122c2@oracle.com> Message-ID: Vote: yes Cheers, Mikael > On Jan 3, 2023, at 8:26 AM, coleen.phillimore at oracle.com wrote: > > I hereby nominate Frederic Parain [fparain] to Membership in the hotspot Group. > > Frederic is an OpenJDK Committer and a member of the HotSpot runtime team at Oracle. He is an active contributor to the valhalla project [1], implementing programming models in the HotSpot code. He is also a contributor to OpenJDK since 2010, working on serviceability code, implementing the diagnostic commands framework, and rewriting Java field layout code. He is currently working on compressing c2 frames in the Loom project, and making the VM internal representation of fields extensible for valhalla support. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#valhalla > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > From mikael.vidstedt at oracle.com Wed Jan 4 21:08:20 2023 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 4 Jan 2023 21:08:20 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Lois Foltan In-Reply-To: References: Message-ID: <9361A9C6-D1FD-4E81-ACB7-21E872FC149E@oracle.com> Vote: yes Cheers, Mikael > On Jan 3, 2023, at 8:22 AM, coleen.phillimore at oracle.com wrote: > > I hereby nominate Lois Foltan [lfoltan] to Membership in the hotspot Group. > > Lois is an OpenJDK Reviewer and a member of the HotSpot runtime team at Oracle. She contributed the VM support for the Module subsystem JSR 294, semantic changes in HotSpot for default methods, cleanups for signature processing, Condy support, and many bug fixes. Lois is now an engineering manager for the runtime team. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vot From iklam at openjdk.org Wed Jan 4 21:08:44 2023 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 4 Jan 2023 21:08:44 GMT Subject: RFR: 8297914: Remove java_lang_Class::process_archived_mirror() Message-ID: This is another prerequisite for [JDK-8296344](https://bugs.openjdk.org/browse/JDK-8296344). Before this PR, when archiving mirror objects (i.e., instances of `java.lang.Class`): - We first allocate a copy of the mirror inside a safepoint. - We then reinitialize the contents of the copy to the desired state (so that it can be used by `Klass::restore_unshareable_info()` This copy-and-modify operation inside the safepoint makes it difficult to implement [JDK-8296344](https://bugs.openjdk.org/browse/JDK-8296344). It violates the requirements [1] and [2] as stated in [JDK-8298600](https://bugs.openjdk.org/browse/JDK-8298600). Also, the reinitialization code is complicated. After this PR: - During the creation of each regular mirror object, we allocate a "scratch mirror" object, which has the states as expected by `Klass::restore_unshareable_info()`. See `java_lang_Class::create_scratch_mirror()`. - When the archive heap is dumped inside a safepoint, we use the scratch mirror, so we can avoid the copy-and-modify operation. See `HeapShared::archive_java_mirrors()`. Testing: tiers 1-4 ------------- Commit messages: - refactored KlassToOopHandleTable - refactor java_lang_Class::allocate_mirror (step2) - refactor java_lang_Class::allocate_mirror (step1) - 8297914: Remove java_lang_Class::process_archived_mirror() Changes: https://git.openjdk.org/jdk/pull/11853/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11853&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297914 Stats: 511 lines in 12 files changed: 227 ins; 226 del; 58 mod Patch: https://git.openjdk.org/jdk/pull/11853.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11853/head:pull/11853 PR: https://git.openjdk.org/jdk/pull/11853 From mikael.vidstedt at oracle.com Wed Jan 4 21:09:10 2023 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 4 Jan 2023 21:09:10 +0000 Subject: CFV: New hotspot Group Member: Ron Pressler In-Reply-To: References: Message-ID: <67DFBBE2-EFE3-4D90-8979-8763A99485C6@oracle.com> Vote: yes Cheers, Mikael > On Jan 3, 2023, at 8:06 AM, coleen.phillimore at oracle.com wrote: > > I hereby nominate Ron Pressler [rpressler] to Membership in the hotspot Group. > > Ron Pressler is the lead for the Loom project [1] and is a committer on the JDK project, including the major contribution of JEP 425: Virtual Threads. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#loom > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > From kvn at openjdk.org Wed Jan 4 21:21:49 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 4 Jan 2023 21:21:49 GMT Subject: RFR: 8299544: Improve performance of CRC32C intrinsics (non-AVX-512) for small inputs In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 02:36:25 GMT, Andrei Pangin wrote: > When comparing performance of JDK built-in CRC32C intrinsics with the native implementation, we noticed that JDK performs notably worse on smaller array sizes (up to 1024 bytes). > > The main reason is that the algorithm based on the ["Fast CRC Computation for iSCSI Polynomial Using CRC32 Instruction"](https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/crc-iscsi-polynomial-crc32-instruction-paper.pdf) paper, processes input buffer in [chunks](https://github.com/openjdk/jdk/blob/92dfc735f2297441a99b3e39464fb8f77a354d55/src/hotspot/cpu/x86/crc32c.h#L29-L50) of 6144, 2064, and 648 bytes, and the rest of the buffer is processed sequentially with [4-byte variant](https://github.com/openjdk/jdk/blob/92dfc735f2297441a99b3e39464fb8f77a354d55/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L8231-L8236) of CRC32 instruction. > > Experiments show that CRC32C computation performance can be improved for smaller inputs without performance impact for larger inputs, if the smallest chunk size is reduced from 648 to 216 bytes. Actually, the original paper suggests the algorithms CRC_216 / CRC_240 for processing blocks of 216 and 240 bytes respectively. The value 648 might have resulted from an "x3" mistake (the algorithm accumulates 3 checksums per iteration). > > Additionally, when processing the tail (less than 216 bytes), we can use 8-byte variant of CRC32 instruction instead of 4-byte variant to speed up the algorithm even further. > > The proposed PR includes the following changes: > > 1. CRC32C_LOW is decreased from 8 * 27 to 8 * 9 (which corresponds to 216 bytes). > 2. CRC32C_MIDDLE is decreased from 8 * 86 to 8 * 74 to compensate for performance drop for mid-size arrays. The value 74 has been chosen empirically. According to experiments, values from 70 to 75 yield the best results, while with higher or lower values, there is a degradation for certain array sizes. > 3. On x86_64, `CRC32 r32, [m32]` instruction is replaced with `CRC32 r64, [m64]` in the tail loop. > 4. Unconditional JMP is replaced with a conditional jump at the end of the loop. > 5. The hot tail loop is aligned. > > Notes: > > - The changes are only for x86 architecture. > - If the hardware supports AVX-512 extensions + VPCLMULQDQ instruction (introduced with Ice Lake), another version of CRC32C intrinsics is generated, and the changes do not have effect. Please, show performance curve graph before and after your changes. `Disclaimer:` in `x86/crc32c.h` says that if you change constants you may need to adjust other places in VM. Do you need for this changes? ------------- PR: https://git.openjdk.org/jdk/pull/11838 From dholmes at openjdk.org Wed Jan 4 21:59:59 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 4 Jan 2023 21:59:59 GMT Subject: RFR: 8299378: sprintf is deprecated in Xcode 14 [v3] In-Reply-To: References: Message-ID: On Tue, 3 Jan 2023 16:28:54 GMT, Xue-Lei Andrew Fan wrote: >> The `sprintf` is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812), but the test was not covered. The failure was [reported later](https://github.com/openjdk/jdk/pull/11115#issuecomment-1344973773), while gtest is enabled for building. >> >> This patch is just to make sure the building could pass. Other than that, the use of `sprintf` in other places are not touched. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > sort includes alphabetically We have developers reporting the same, and other issues. I don't know what builds you used to test this but there are issues with at least `opto` code in hotspot and JVMTI tests (as above). ------------- PR: https://git.openjdk.org/jdk/pull/11793 From duke at openjdk.org Wed Jan 4 22:09:02 2023 From: duke at openjdk.org (Christoph) Date: Wed, 4 Jan 2023 22:09:02 GMT Subject: RFR: 8299378: sprintf is deprecated in Xcode 14 [v3] In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 21:57:22 GMT, David Holmes wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> sort includes alphabetically > > We have developers reporting the same, and other issues. I don't know what builds you used to test this but there are issues with at least `opto` code in hotspot and JVMTI tests (as above). @dholmes-ora I am using the latest master branch from earlier today 82deb5ca615 ------------- PR: https://git.openjdk.org/jdk/pull/11793 From coleenp at openjdk.org Wed Jan 4 23:13:18 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 4 Jan 2023 23:13:18 GMT Subject: RFR: 8299275: Add resolved_references verification code Message-ID: <1Adx9iDHr_fSF8l2AXfNF9Rzq5NpPwhqiJ2AxnorYRQ=.88805086-76f3-4839-80de-ad059f7304f7@github.com> I added some verification code to try to help track down JDK-8296915 (https://bugs.openjdk.org/browse/JDK-8296915). Ran Test: runtime/SelectionResolution/InvokeInterfaceSuccessTest.java 100x with -XX:+VerifyBefore/AfterGC. Tested with tier1-4. ------------- Commit messages: - 8299275: Add resolved_references verification code Changes: https://git.openjdk.org/jdk/pull/11856/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11856&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299275 Stats: 38 lines in 3 files changed: 32 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/11856.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11856/head:pull/11856 PR: https://git.openjdk.org/jdk/pull/11856 From iklam at openjdk.org Thu Jan 5 00:28:50 2023 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 5 Jan 2023 00:28:50 GMT Subject: RFR: 8299275: Add resolved_references verification code In-Reply-To: <1Adx9iDHr_fSF8l2AXfNF9Rzq5NpPwhqiJ2AxnorYRQ=.88805086-76f3-4839-80de-ad059f7304f7@github.com> References: <1Adx9iDHr_fSF8l2AXfNF9Rzq5NpPwhqiJ2AxnorYRQ=.88805086-76f3-4839-80de-ad059f7304f7@github.com> Message-ID: On Wed, 4 Jan 2023 23:05:36 GMT, Coleen Phillimore wrote: > I added some verification code to try to help track down JDK-8296915 (https://bugs.openjdk.org/browse/JDK-8296915). > Ran Test: runtime/SelectionResolution/InvokeInterfaceSuccessTest.java 100x with -XX:+VerifyBefore/AfterGC. > Tested with tier1-4. Although the title of this PR is "Add resolved_references verification code", it's not obvious to me how resolved_references are touched by the changes. src/hotspot/share/classfile/classLoaderData.cpp line 1059: > 1057: Metadata* m = _deallocate_list->at(i); > 1058: if (m->is_klass()) { > 1059: ((InstanceKlass*)m)->verify(); There's no `InstanceKlass::verify()` method. Do you mean `((Klass*)m)->verify()` ? ------------- PR: https://git.openjdk.org/jdk/pull/11856 From dholmes at openjdk.org Thu Jan 5 01:40:51 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 5 Jan 2023 01:40:51 GMT Subject: RFR: 8297914: Remove java_lang_Class::process_archived_mirror() In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 21:01:28 GMT, Ioi Lam wrote: > This is another prerequisite for [JDK-8296344](https://bugs.openjdk.org/browse/JDK-8296344). > > Before this PR, when archiving mirror objects (i.e., instances of `java.lang.Class`): > - We first allocate a copy of the mirror inside a safepoint. > - We then reinitialize the contents of the copy to the desired state (so that it can be used by `Klass::restore_unshareable_info()` > > This copy-and-modify operation inside the safepoint makes it difficult to implement [JDK-8296344](https://bugs.openjdk.org/browse/JDK-8296344). It violates the requirements [1] and [2] as stated in [JDK-8298600](https://bugs.openjdk.org/browse/JDK-8298600). Also, the reinitialization code is complicated. > > After this PR: > - During the creation of each regular mirror object, we allocate a "scratch mirror" object, which has the states as expected by `Klass::restore_unshareable_info()`. See `java_lang_Class::create_scratch_mirror()`. > - When the archive heap is dumped inside a safepoint, we use the scratch mirror, so we can avoid the copy-and-modify operation. See `HeapShared::archive_java_mirrors()`. > > Testing: tiers 1-4 src/hotspot/share/classfile/javaClasses.cpp line 1062: > 1060: // > 1061: // Note: we archive the "scratch mirror" instead of k->java_mirror(), because the > 1062: // later may contain dumptime-specific information that cannot be archived s/later/latter/ ------------- PR: https://git.openjdk.org/jdk/pull/11853 From xuelei at openjdk.org Thu Jan 5 01:57:55 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Thu, 5 Jan 2023 01:57:55 GMT Subject: RFR: 8299378: sprintf is deprecated in Xcode 14 [v3] In-Reply-To: References: Message-ID: <-GA_oq_0YnuokfcwNyHEWvJ1Ed-rp65HMpf90bGBXAs=.9f0da003-817d-46ee-ac34-2a26bef71635@github.com> On Wed, 4 Jan 2023 16:31:37 GMT, Christoph wrote: > Ventura 13.1 (22C65) SDK: MacOSX13.1.sdk (XCode 14.2) macosx-aarch64-server-release > > Full log (I commented out that line in libAsyncExceptionOnMonitorEnter, therefore the following came up) I am happy to test any further fixes. > > I run `make run-test tier1` and did a clean before I could reproduce the issue. A new bug was filed: https://bugs.openjdk.org/browse/JDK-8299635. Thank you! ------------- PR: https://git.openjdk.org/jdk/pull/11793 From thartmann at openjdk.org Thu Jan 5 06:14:28 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 5 Jan 2023 06:14:28 GMT Subject: RFR: 8298720: Insufficient error handling when CodeBuffer is exhausted [v2] In-Reply-To: References: Message-ID: > This patch fixes various places in C1 and C2 on Aarch64 and RISC-V that miss proper error handling when the code buffer is exhausted, leading to crashes. Similar but incomplete patches went in with [JDK-8130309](https://bugs.openjdk.org/browse/JDK-8130309), [JDK-8248411](https://bugs.openjdk.org/browse/JDK-8248411) and [JDK-8272094](https://bugs.openjdk.org/browse/JDK-8272094) in the past. > > These issues are extremely hard to reproduce, even with the `-XX:+StressCodeBuffers` option, because code buffer expansion needs to fail at the exact moment when a specific (unhandled) instruction is emitted. Even with the stress option, we expand the code buffer such that multiple instructions will fit and in addition, chances are high that we simply bail out from compilation before emitting the problematic instruction. I attached a patch to [JDK-8298720](https://bugs.openjdk.org/browse/JDK-8298720), that makes `-XX:+StressCodeBuffers` randomized and more aggressive. With that, I can reproduce the issue reliably but it's extremely slow and therefore not well suited for integration. > > I now went over all usages of `CodeBuffer::expand` to make sure that we have proper error handling in place and found some remaining issues in JVMCI code. I filed [JDK-8299570](https://bugs.openjdk.org/browse/JDK-8299570) to address them. > > I would need help to test the RISC-V specific changes. > > Thanks, > Tobias Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision: Adjusted bailout message ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11839/files - new: https://git.openjdk.org/jdk/pull/11839/files/32e5f483..25a4cf22 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11839&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11839&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11839.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11839/head:pull/11839 PR: https://git.openjdk.org/jdk/pull/11839 From thartmann at openjdk.org Thu Jan 5 06:14:28 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 5 Jan 2023 06:14:28 GMT Subject: RFR: 8298720: Insufficient error handling when CodeBuffer is exhausted [v2] In-Reply-To: <0ltwqSDWed6m8E2IIH_MIUMvIiA6rI43OcKVFXH2Ux8=.a1356f15-3d49-491e-9afc-ebde241c5a5c@github.com> References: <0ltwqSDWed6m8E2IIH_MIUMvIiA6rI43OcKVFXH2Ux8=.a1356f15-3d49-491e-9afc-ebde241c5a5c@github.com> Message-ID: On Wed, 4 Jan 2023 20:18:48 GMT, Vladimir Kozlov wrote: >> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision: >> >> Adjusted bailout message > > src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp line 1205: > >> 1203: *op->stub()->entry()); >> 1204: if (tpc == nullptr) { >> 1205: bailout("trampoline stub overflow"); > > The message is confusing. How about `"no space for trampoline stub"` used in `c1_LIRAssembler_ppc.cpp`. Makes sense. Fixed. ------------- PR: https://git.openjdk.org/jdk/pull/11839 From thartmann at openjdk.org Thu Jan 5 06:52:55 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 5 Jan 2023 06:52:55 GMT Subject: RFR: 8298720: Insufficient error handling when CodeBuffer is exhausted [v3] In-Reply-To: References: Message-ID: > This patch fixes various places in C1 and C2 on Aarch64 and RISC-V that miss proper error handling when the code buffer is exhausted, leading to crashes. Similar but incomplete patches went in with [JDK-8130309](https://bugs.openjdk.org/browse/JDK-8130309), [JDK-8248411](https://bugs.openjdk.org/browse/JDK-8248411) and [JDK-8272094](https://bugs.openjdk.org/browse/JDK-8272094) in the past. > > These issues are extremely hard to reproduce, even with the `-XX:+StressCodeBuffers` option, because code buffer expansion needs to fail at the exact moment when a specific (unhandled) instruction is emitted. Even with the stress option, we expand the code buffer such that multiple instructions will fit and in addition, chances are high that we simply bail out from compilation before emitting the problematic instruction. I attached a patch to [JDK-8298720](https://bugs.openjdk.org/browse/JDK-8298720), that makes `-XX:+StressCodeBuffers` randomized and more aggressive. With that, I can reproduce the issue reliably but it's extremely slow and therefore not well suited for integration. > > I now went over all usages of `CodeBuffer::expand` to make sure that we have proper error handling in place and found some remaining issues in JVMCI code. I filed [JDK-8299570](https://bugs.openjdk.org/browse/JDK-8299570) to address them. > > I would need help to test the RISC-V specific changes. > > Thanks, > Tobias Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision: Bail out from C1 MacroAssembler ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11839/files - new: https://git.openjdk.org/jdk/pull/11839/files/25a4cf22..60921e18 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11839&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11839&range=01-02 Stats: 48 lines in 3 files changed: 7 ins; 11 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/11839.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11839/head:pull/11839 PR: https://git.openjdk.org/jdk/pull/11839 From thartmann at openjdk.org Thu Jan 5 06:52:57 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 5 Jan 2023 06:52:57 GMT Subject: RFR: 8298720: Insufficient error handling when CodeBuffer is exhausted [v2] In-Reply-To: References: Message-ID: On Thu, 5 Jan 2023 06:14:28 GMT, Tobias Hartmann wrote: >> This patch fixes various places in C1 and C2 on Aarch64 and RISC-V that miss proper error handling when the code buffer is exhausted, leading to crashes. Similar but incomplete patches went in with [JDK-8130309](https://bugs.openjdk.org/browse/JDK-8130309), [JDK-8248411](https://bugs.openjdk.org/browse/JDK-8248411) and [JDK-8272094](https://bugs.openjdk.org/browse/JDK-8272094) in the past. >> >> These issues are extremely hard to reproduce, even with the `-XX:+StressCodeBuffers` option, because code buffer expansion needs to fail at the exact moment when a specific (unhandled) instruction is emitted. Even with the stress option, we expand the code buffer such that multiple instructions will fit and in addition, chances are high that we simply bail out from compilation before emitting the problematic instruction. I attached a patch to [JDK-8298720](https://bugs.openjdk.org/browse/JDK-8298720), that makes `-XX:+StressCodeBuffers` randomized and more aggressive. With that, I can reproduce the issue reliably but it's extremely slow and therefore not well suited for integration. >> >> I now went over all usages of `CodeBuffer::expand` to make sure that we have proper error handling in place and found some remaining issues in JVMCI code. I filed [JDK-8299570](https://bugs.openjdk.org/browse/JDK-8299570) to address them. >> >> I would need help to test the RISC-V specific changes. >> >> Thanks, >> Tobias > > Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision: > > Adjusted bailout message Thanks for the review, Vladimir. > can we do bailout in MacroAssembler::trampoline_call() instead of later in all over places? We could access the current C1 `Compilation` via `Compilation::current()` and trigger the bailout from the C1 MacroAssembler. We can't push it further down into the MacroAssembler methods because they are shared and also used by the stubGenerator. I updated the patch accordingly. Do you prefer that solution? ------------- PR: https://git.openjdk.org/jdk/pull/11839 From thartmann at openjdk.org Thu Jan 5 07:06:13 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 5 Jan 2023 07:06:13 GMT Subject: RFR: 8298720: Insufficient error handling when CodeBuffer is exhausted [v4] In-Reply-To: References: Message-ID: > This patch fixes various places in C1 and C2 on Aarch64 and RISC-V that miss proper error handling when the code buffer is exhausted, leading to crashes. Similar but incomplete patches went in with [JDK-8130309](https://bugs.openjdk.org/browse/JDK-8130309), [JDK-8248411](https://bugs.openjdk.org/browse/JDK-8248411) and [JDK-8272094](https://bugs.openjdk.org/browse/JDK-8272094) in the past. > > These issues are extremely hard to reproduce, even with the `-XX:+StressCodeBuffers` option, because code buffer expansion needs to fail at the exact moment when a specific (unhandled) instruction is emitted. Even with the stress option, we expand the code buffer such that multiple instructions will fit and in addition, chances are high that we simply bail out from compilation before emitting the problematic instruction. I attached a patch to [JDK-8298720](https://bugs.openjdk.org/browse/JDK-8298720), that makes `-XX:+StressCodeBuffers` randomized and more aggressive. With that, I can reproduce the issue reliably but it's extremely slow and therefore not well suited for integration. > > I now went over all usages of `CodeBuffer::expand` to make sure that we have proper error handling in place and found some remaining issues in JVMCI code. I filed [JDK-8299570](https://bugs.openjdk.org/browse/JDK-8299570) to address them. > > I would need help to test the RISC-V specific changes. > > Thanks, > Tobias Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision: Updated copyrights ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11839/files - new: https://git.openjdk.org/jdk/pull/11839/files/60921e18..2ac31ce7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11839&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11839&range=02-03 Stats: 8 lines in 8 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/11839.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11839/head:pull/11839 PR: https://git.openjdk.org/jdk/pull/11839 From fyang at openjdk.org Thu Jan 5 08:06:51 2023 From: fyang at openjdk.org (Fei Yang) Date: Thu, 5 Jan 2023 08:06:51 GMT Subject: RFR: 8298720: Insufficient error handling when CodeBuffer is exhausted In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 09:06:44 GMT, Fei Yang wrote: >> This patch fixes various places in C1 and C2 on Aarch64 and RISC-V that miss proper error handling when the code buffer is exhausted, leading to crashes. Similar but incomplete patches went in with [JDK-8130309](https://bugs.openjdk.org/browse/JDK-8130309), [JDK-8248411](https://bugs.openjdk.org/browse/JDK-8248411) and [JDK-8272094](https://bugs.openjdk.org/browse/JDK-8272094) in the past. >> >> These issues are extremely hard to reproduce, even with the `-XX:+StressCodeBuffers` option, because code buffer expansion needs to fail at the exact moment when a specific (unhandled) instruction is emitted. Even with the stress option, we expand the code buffer such that multiple instructions will fit and in addition, chances are high that we simply bail out from compilation before emitting the problematic instruction. I attached a patch to [JDK-8298720](https://bugs.openjdk.org/browse/JDK-8298720), that makes `-XX:+StressCodeBuffers` randomized and more aggressive. With that, I can reproduce the issue reliably but it's extremely slow and therefore not well suited for integration. >> >> I now went over all usages of `CodeBuffer::expand` to make sure that we have proper error handling in place and found some remaining issues in JVMCI code. I filed [JDK-8299570](https://bugs.openjdk.org/browse/JDK-8299570) to address them. >> >> I would need help to test the RISC-V specific changes. >> >> Thanks, >> Tobias > > Hi! Thanks for handling RISC-V at the same time. I can help arrange some necessary tests on linux-riscv64 for those changes. > Thanks @RealFYang! It's mostly about verifying that I did not miss any label in the `reset_labels` calls. You should be able to hardcode the bailout to always true and check if we don't hit any assert. Hi, fastdebug bootcycle is fine on linux-riscv64 platform. And If I hardcoded the bailout to always true, I got following assertion error when I do native fastdebug build on both aarch64 and riscv64 platforms: # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/realfyang/openjdk-jdk/src/hotspot/share/opto/output.cpp:3241), pid=2565744, tid=2566009 # assert(!C->failing()) failed: Must not have pending failure. Reason is: CodeCache is full # # JRE version: OpenJDK Runtime Environment (21.0) (fastdebug build 21-internal-adhoc.realfyang.openjdk-jdk) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 21-internal-adhoc.realfyang.openjdk-jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64) # Problematic frame: # V [libjvm.so+0x14fa71c] PhaseOutput::scratch_emit_size(Node const*)+0x314 ------------- PR: https://git.openjdk.org/jdk/pull/11839 From ngasson at openjdk.org Thu Jan 5 09:53:06 2023 From: ngasson at openjdk.org (Nick Gasson) Date: Thu, 5 Jan 2023 09:53:06 GMT Subject: RFR: 8298482: Implement ParallelGC NUMAStats for Linux [v3] In-Reply-To: References: Message-ID: <0kLOC8uhdDwwtu901coLNm8UT_7k3pzLn1MjWeXqU-0=.d4d9c100-12bb-4dc1-81d7-a3752e1fd930@github.com> > ParallelGC has a seemingly useful option -XX:+NUMAStats that prints detailed information in GC.heap_info about which NUMA node pages in the eden space are bound to. However as far as I can tell this only ever worked on Solaris and is not implemented on any of the systems we currently support. This patch implements it on Linux using the move_pages system call. > > The function os::get_page_info() and accompanying struct page_info was just a thin wrapper around the Solaris meminfo(2) syscall and was never ported to other systems so I've just removed it rather than try to emulate its interface. > > There's also a method MutableNUMASpace::LGRPSpace::scan_pages() which attempts to find pages on the wrong NUMA node and frees them so that they have another chance to be allocated on the correct node by the first-touching thread, but I think this has always been a no-op on non-Solaris so perhaps should also be removed. On Linux it shouldn't be necessary as you can bind pages to the desired node directly. > > I don't know what the performance of this option was like on Solaris but on Linux the move_pages call can be quite slow: I measured about 25ms/GB on my system. At the moment we call LGRPSpace::accumulate_statistics() twice per GC cycle: I removed the second call as it's likely to see a lot of uncommitted pages if the spaces were just resized. MutableNUMASpace::print_on() also calls accumulate_statistics() directly and since that's the only place this data is used, maybe we can drop the call from MutableNUMASpace::accumulate_statistics() as well? > > Example output: > > > PSYoungGen total 4290560K, used 835628K [0x00000006aac00000, 0x0000000800000000, 0x0000000800000000) > eden space 3096576K, 1% used [0x00000006aac00000,0x00000007176a9f48,0x0000000767c00000) > lgrp 0 space 1761280K, 2% used [0x00000006aac00000,0x00000006acfc4980,0x0000000716400000) > local/remote/unbiased/uncommitted: 1671168K/0K/0K/90112K, large/small pages: 0/440320 > lgrp 1 space 1335296K, 46% used [0x0000000716400000,0x000000073c2abb18,0x0000000767c00000) > local/remote/unbiased/uncommitted: 1335296K/0K/0K/0K, large/small pages: 0/333824 > from space 1193984K, 65% used [0x00000007b7200000,0x00000007e6b9c778,0x0000000800000000) > to space 1247232K, 0% used [0x0000000767c00000,0x0000000767c00000,0x00000007b3e00000) > > > After testing this with SPECjbb for a while I noticed some pages always end up bound to the wrong node. I think this is a regression caused by JDK-8283935 but I'll raise a separate ticket for that. Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: Do not update NUMAStats in MutableNUMASpace::accumulate_statistics() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11635/files - new: https://git.openjdk.org/jdk/pull/11635/files/c8333026..80bd78cd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11635&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11635&range=01-02 Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11635.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11635/head:pull/11635 PR: https://git.openjdk.org/jdk/pull/11635 From thartmann at openjdk.org Thu Jan 5 10:09:49 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 5 Jan 2023 10:09:49 GMT Subject: RFR: 8298720: Insufficient error handling when CodeBuffer is exhausted In-Reply-To: References: Message-ID: On Thu, 5 Jan 2023 08:01:42 GMT, Fei Yang wrote: >> Hi! Thanks for handling RISC-V at the same time. I can help arrange some necessary tests on linux-riscv64 for those changes. > >> Thanks @RealFYang! It's mostly about verifying that I did not miss any label in the `reset_labels` calls. You should be able to hardcode the bailout to always true and check if we don't hit any assert. > > Hi, fastdebug bootcycle is fine on linux-riscv64 platform. > And If I hardcoded the bailout to always true, I got following assertion error when I do native fastdebug build on both aarch64 and riscv64 platforms: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/home/realfyang/openjdk-jdk/src/hotspot/share/opto/output.cpp:3241), pid=2565744, tid=2566009 > # assert(!C->failing()) failed: Must not have pending failure. Reason is: CodeCache is full > # > # JRE version: OpenJDK Runtime Environment (21.0) (fastdebug build 21-internal-adhoc.realfyang.openjdk-jdk) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 21-internal-adhoc.realfyang.openjdk-jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64) > # Problematic frame: > # V [libjvm.so+0x14fa71c] PhaseOutput::scratch_emit_size(Node const*)+0x314 Thanks for testing, @RealFYang. That assert is expected as the code assumes that the scratch buffer is always large enough in size and code emission should never fail. Of course, that's not true when hardcoding the bailout. Missing to reset a label before the bailout would lead to a `"Label was never bound to a location, but it was used as a jmp target"` assert. Thanks for verifying that this is not the case. ------------- PR: https://git.openjdk.org/jdk/pull/11839 From eosterlund at openjdk.org Thu Jan 5 10:54:27 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 5 Jan 2023 10:54:27 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v3] In-Reply-To: <1rK2mzryGeyI-Yak0rUIqYZBuK5zrxCYwPe9zJbjHpY=.5471f1af-f8b8-4219-ae93-8b5a5fecaad9@github.com> References: <1rK2mzryGeyI-Yak0rUIqYZBuK5zrxCYwPe9zJbjHpY=.5471f1af-f8b8-4219-ae93-8b5a5fecaad9@github.com> Message-ID: > The JfrVFrameStream is used while generating stack traces for events. One of the events are the ZPage allocation event. This event is sometimes sent when ZGC is relocating. The current implementation of JfrVFrameStream uses WalkContinuation::include, which causes JFR to walk the continuation and perform GC barriers. This is problematic, since ZGC has a requirement that we never perform load barriers while running the relocation code. If we do, we might end up performing other reloctions from the the relocation code, and in some cases that causes dead locks. > > I propose that JFR doesn't walk the stack during stack watermark processing. This PR implements that change. This PR replaces https://github.com/openjdk/jdk/pull/11586 Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: Renaming and comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11778/files - new: https://git.openjdk.org/jdk/pull/11778/files/5bd03153..674f0d74 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11778&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11778&range=01-02 Stats: 131 lines in 5 files changed: 63 ins; 59 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/11778.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11778/head:pull/11778 PR: https://git.openjdk.org/jdk/pull/11778 From eosterlund at openjdk.org Thu Jan 5 10:54:27 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 5 Jan 2023 10:54:27 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v2] In-Reply-To: References: <1rK2mzryGeyI-Yak0rUIqYZBuK5zrxCYwPe9zJbjHpY=.5471f1af-f8b8-4219-ae93-8b5a5fecaad9@github.com> <0A2u_ZuEnM9aOilTWrinh9Csvi3zOT9__aSw6vc8L1Y=.dcdf6f0c-5e9d-4744-bb87-8a3c0b2af8f4@github.com> Message-ID: On Wed, 4 Jan 2023 16:10:39 GMT, Erik ?sterlund wrote: >> src/hotspot/share/runtime/disableStackTracingMark.hpp line 36: >> >>> 34: // Use this class to mark a section of code where stack tracing is not safe >>> 35: // and should be avoided. >>> 36: class DisableStackTracingMark : public StackObj { >> >> One thing that could perhaps be a bit of a gotcha with this is the name selection, "DisableStackTracingMark". One could get the impression that this disables stack traces entirely. But this is not the case for asynchronous operations, like AsyncGetCallTrace and JFR - they fetch the information from the CPU context to produce a stacktrace, if there is no ljf. Not a biggie, but might be confusing. Perhaps "NoLastJavaFrame" or something? > > Good point. I'll try to think of a better name. Trying out ClearFrameAnchorMark in the latest commit - what do you think? ------------- PR: https://git.openjdk.org/jdk/pull/11778 From fyang at openjdk.org Thu Jan 5 11:10:52 2023 From: fyang at openjdk.org (Fei Yang) Date: Thu, 5 Jan 2023 11:10:52 GMT Subject: RFR: 8298720: Insufficient error handling when CodeBuffer is exhausted [v4] In-Reply-To: References: Message-ID: On Thu, 5 Jan 2023 07:06:13 GMT, Tobias Hartmann wrote: >> This patch fixes various places in C1 and C2 on Aarch64 and RISC-V that miss proper error handling when the code buffer is exhausted, leading to crashes. Similar but incomplete patches went in with [JDK-8130309](https://bugs.openjdk.org/browse/JDK-8130309), [JDK-8248411](https://bugs.openjdk.org/browse/JDK-8248411) and [JDK-8272094](https://bugs.openjdk.org/browse/JDK-8272094) in the past. >> >> These issues are extremely hard to reproduce, even with the `-XX:+StressCodeBuffers` option, because code buffer expansion needs to fail at the exact moment when a specific (unhandled) instruction is emitted. Even with the stress option, we expand the code buffer such that multiple instructions will fit and in addition, chances are high that we simply bail out from compilation before emitting the problematic instruction. I attached a patch to [JDK-8298720](https://bugs.openjdk.org/browse/JDK-8298720), that makes `-XX:+StressCodeBuffers` randomized and more aggressive. With that, I can reproduce the issue reliably but it's extremely slow and therefore not well suited for integration. >> >> I now went over all usages of `CodeBuffer::expand` to make sure that we have proper error handling in place and found some remaining issues in JVMCI code. I filed [JDK-8299570](https://bugs.openjdk.org/browse/JDK-8299570) to address them. >> >> I would need help to test the RISC-V specific changes. >> >> Thanks, >> Tobias > > Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision: > > Updated copyrights Looks good to me. ------------- Marked as reviewed by fyang (Reviewer). PR: https://git.openjdk.org/jdk/pull/11839 From shade at openjdk.org Thu Jan 5 12:12:51 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 5 Jan 2023 12:12:51 GMT Subject: RFR: 8294403: [REDO] make test should report only on executed tests [v2] In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 09:15:18 GMT, Aleksey Shipilev wrote: >> This should help to speed up tests significantly. Currently, if we run "make test" with a subset of tests, JTReg would still read the entirety of test root to report on tests that were not run. Even with current suite of tests it gets expensive. If you add more tests to suite -- for example, mounting a large test archive like pre-generated fuzzer tests -- it starts to take a lot of time. >> >> The reasonable default for older jtreg is `-report:executed`. My own CI -- that has millions of tests mounted in `test/` -- was running with `JTREG="OPTIONS=-report:executed"` for years now. [CODETOOLS-7903323](https://bugs.openjdk.org/browse/CODETOOLS-7903323) provides a new reporting option, `-report:files`, which makes this whole business easier. This requires new jtreg. >> >> Motivational improvements: >> >> >> $ time CONF=linux-x86_64-server-release make run-test TEST=gc/epsilon/TestHelloWorld.java >> >> # Default JDK tree >> >> # Baseline >> real 0m9.086s >> user 0m22.857s >> sys 0m4.202s >> >> # Patched >> real 0m6.406s ; +40% faster >> user 0m17.156s >> sys 0m3.193s >> >> # +100K fuzzer tests in tree >> >> # Baseline >> real 3m1.997s >> user 3m16.643s >> sys 0m10.490s >> >> # Patched >> real 0m8.919s ; 20x faster >> user 0m17.904s >> sys 0m4.860s >> >> >> Additional testing: >> - [x] Ad-hoc timing tests (see above) >> - [x] Reproducer from [CODETOOLS-7903331](https://bugs.openjdk.org/browse/CODETOOLS-7903331) >> - [x] Eyeballing the test results on passing tests with REPEAT_COUNT > 1 >> - [x] Eyeballing the test results on intermittently failing tests with RETRY_COUNT > 1 > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Copyright years My longer testing passes well. I would like to integrate it soon, if there are no objections. ------------- PR: https://git.openjdk.org/jdk/pull/11824 From mgronlun at openjdk.org Thu Jan 5 12:27:50 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 5 Jan 2023 12:27:50 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v2] In-Reply-To: References: <1rK2mzryGeyI-Yak0rUIqYZBuK5zrxCYwPe9zJbjHpY=.5471f1af-f8b8-4219-ae93-8b5a5fecaad9@github.com> <0A2u_ZuEnM9aOilTWrinh9Csvi3zOT9__aSw6vc8L1Y=.dcdf6f0c-5e9d-4744-bb87-8a3c0b2af8f4@github.com> Message-ID: On Thu, 5 Jan 2023 10:50:32 GMT, Erik ?sterlund wrote: >> Good point. I'll try to think of a better name. > > Trying out ClearFrameAnchorMark in the latest commit - what do you think? I am always slightly jarred about the discrepancy between the API, set_last_java_frame() and reset_last_java_frame() and the fact that the struct field is called _frame_anchor. Conceptually, "last java frame" is better. Therefore, I would suggest ClearLastJavaFrameMark. Sorry. ------------- PR: https://git.openjdk.org/jdk/pull/11778 From eosterlund at openjdk.org Thu Jan 5 12:49:50 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 5 Jan 2023 12:49:50 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v2] In-Reply-To: References: <1rK2mzryGeyI-Yak0rUIqYZBuK5zrxCYwPe9zJbjHpY=.5471f1af-f8b8-4219-ae93-8b5a5fecaad9@github.com> <0A2u_ZuEnM9aOilTWrinh9Csvi3zOT9__aSw6vc8L1Y=.dcdf6f0c-5e9d-4744-bb87-8a3c0b2af8f4@github.com> Message-ID: On Thu, 5 Jan 2023 12:24:09 GMT, Markus Gr?nlund wrote: >> Trying out ClearFrameAnchorMark in the latest commit - what do you think? > > I am always slightly jarred about the discrepancy between the API, set_last_java_frame() and reset_last_java_frame() and the fact that the struct field is called _frame_anchor. Conceptually, "last java frame" is better. Therefore, I would suggest ClearLastJavaFrameMark. Sorry. Okay, let's take that for a spin. ------------- PR: https://git.openjdk.org/jdk/pull/11778 From eosterlund at openjdk.org Thu Jan 5 13:04:45 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 5 Jan 2023 13:04:45 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v4] In-Reply-To: <1rK2mzryGeyI-Yak0rUIqYZBuK5zrxCYwPe9zJbjHpY=.5471f1af-f8b8-4219-ae93-8b5a5fecaad9@github.com> References: <1rK2mzryGeyI-Yak0rUIqYZBuK5zrxCYwPe9zJbjHpY=.5471f1af-f8b8-4219-ae93-8b5a5fecaad9@github.com> Message-ID: > The JfrVFrameStream is used while generating stack traces for events. One of the events are the ZPage allocation event. This event is sometimes sent when ZGC is relocating. The current implementation of JfrVFrameStream uses WalkContinuation::include, which causes JFR to walk the continuation and perform GC barriers. This is problematic, since ZGC has a requirement that we never perform load barriers while running the relocation code. If we do, we might end up performing other reloctions from the the relocation code, and in some cases that causes dead locks. > > I propose that JFR doesn't walk the stack during stack watermark processing. This PR implements that change. This PR replaces https://github.com/openjdk/jdk/pull/11586 Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: More renaming ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11778/files - new: https://git.openjdk.org/jdk/pull/11778/files/674f0d74..901c4277 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11778&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11778&range=02-03 Stats: 235 lines in 6 files changed: 114 ins; 114 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/11778.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11778/head:pull/11778 PR: https://git.openjdk.org/jdk/pull/11778 From eosterlund at openjdk.org Thu Jan 5 13:08:48 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 5 Jan 2023 13:08:48 GMT Subject: RFR: 8299312: Clean up BarrierSetNMethod In-Reply-To: <1km8O--i4urmIjKeFK2AT3mO0d4DoTX5RcPYC1XdD-k=.d82590fe-35d2-406f-a502-fd5bb2c145f5@github.com> References: <1km8O--i4urmIjKeFK2AT3mO0d4DoTX5RcPYC1XdD-k=.d82590fe-35d2-406f-a502-fd5bb2c145f5@github.com> Message-ID: <_ONOHzwnJtl_l9se_WVzP2nP6dE0EXl61lTOCOt9qFA=.88dcba7c-2ca2-4746-9d55-863cf0635717@github.com> On Tue, 3 Jan 2023 15:55:43 GMT, Martin Doerr wrote: >> The terminology in BarrierSetNMethod is not crisp. In platform code we talk about a per-nmethod "guard value", but on shared level we call the same value arm value or disarm value in different contexts. But it really depends on the value whether the nmethod is disarmed or armed. We should embrace the "guard value" terminology and lift it in to the shared code level. >> We also have more functionality than we need on platform level. The platform level only needs to know how to deoptimize, and how to set/get the guard value of an nmethod. The more specific functionality should be moved to the shared code and be expressed in terms of said setter/getter. > > With https://github.com/openjdk/jdk/commit/245f0cf4ac9dc655bfe2abb1c88c6ed1ddffd291, nmethod entry barriers are implemented on all platforms, now. The ARM32 parts should be added. (Also see failing pre-submit test.) Thanks for the review @TheRealMDoerr! ------------- PR: https://git.openjdk.org/jdk/pull/11774 From mgronlun at openjdk.org Thu Jan 5 13:20:51 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 5 Jan 2023 13:20:51 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v4] In-Reply-To: References: <1rK2mzryGeyI-Yak0rUIqYZBuK5zrxCYwPe9zJbjHpY=.5471f1af-f8b8-4219-ae93-8b5a5fecaad9@github.com> Message-ID: <9ChDJXJKuuqbZDXbRj1dRzdThoC0D5go7Rp8QMKau-U=.441e2bb3-f54b-4402-8438-3c1f054ea1b6@github.com> On Thu, 5 Jan 2023 13:04:45 GMT, Erik ?sterlund wrote: >> The JfrVFrameStream is used while generating stack traces for events. One of the events are the ZPage allocation event. This event is sometimes sent when ZGC is relocating. The current implementation of JfrVFrameStream uses WalkContinuation::include, which causes JFR to walk the continuation and perform GC barriers. This is problematic, since ZGC has a requirement that we never perform load barriers while running the relocation code. If we do, we might end up performing other reloctions from the the relocation code, and in some cases that causes dead locks. >> >> I propose that JFR doesn't walk the stack during stack watermark processing. This PR implements that change. This PR replaces https://github.com/openjdk/jdk/pull/11586 > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > More renaming Looks good. ------------- Marked as reviewed by mgronlun (Reviewer). PR: https://git.openjdk.org/jdk/pull/11778 From coleenp at openjdk.org Thu Jan 5 14:40:50 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 5 Jan 2023 14:40:50 GMT Subject: RFR: 8299275: Add some ClassLoaderData verification code In-Reply-To: References: <1Adx9iDHr_fSF8l2AXfNF9Rzq5NpPwhqiJ2AxnorYRQ=.88805086-76f3-4839-80de-ad059f7304f7@github.com> Message-ID: On Thu, 5 Jan 2023 00:16:44 GMT, Ioi Lam wrote: >> I added some verification code to try to help track down JDK-8296915 (https://bugs.openjdk.org/browse/JDK-8296915). >> Ran Test: runtime/SelectionResolution/InvokeInterfaceSuccessTest.java 100x with -XX:+VerifyBefore/AfterGC. >> Tested with tier1-4. > > src/hotspot/share/classfile/classLoaderData.cpp line 1059: > >> 1057: Metadata* m = _deallocate_list->at(i); >> 1058: if (m->is_klass()) { >> 1059: ((InstanceKlass*)m)->verify(); > > There's no `InstanceKlass::verify()` method. Do you mean `((Klass*)m)->verify()` ? // Verification virtual void verify_on(outputStream* st); void verify() { verify_on(tty); } It calls the virtual function InstanceKlass::verify_on() ------------- PR: https://git.openjdk.org/jdk/pull/11856 From coleenp at openjdk.org Thu Jan 5 14:40:51 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 5 Jan 2023 14:40:51 GMT Subject: RFR: 8299275: Add some ClassLoaderData verification code In-Reply-To: References: <1Adx9iDHr_fSF8l2AXfNF9Rzq5NpPwhqiJ2AxnorYRQ=.88805086-76f3-4839-80de-ad059f7304f7@github.com> Message-ID: On Thu, 5 Jan 2023 14:36:49 GMT, Coleen Phillimore wrote: >> src/hotspot/share/classfile/classLoaderData.cpp line 1059: >> >>> 1057: Metadata* m = _deallocate_list->at(i); >>> 1058: if (m->is_klass()) { >>> 1059: ((InstanceKlass*)m)->verify(); >> >> There's no `InstanceKlass::verify()` method. Do you mean `((Klass*)m)->verify()` ? > > // Verification > virtual void verify_on(outputStream* st); > void verify() { verify_on(tty); } > > It calls the virtual function InstanceKlass::verify_on() Yes, I did add the deallocate_list verification too. I can change the title of the bug. ------------- PR: https://git.openjdk.org/jdk/pull/11856 From coleenp at openjdk.org Thu Jan 5 14:43:50 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 5 Jan 2023 14:43:50 GMT Subject: RFR: 8299274: Add elements to resolved_references consistently [v2] In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 01:54:45 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Change to objArrayOop to replace_if_null since that is what it's doing. > > Looks good - nice simplification. Just one issue with naming. > > Thanks @dholmes-ora are you holding out until I change the name to something I don't agree with ? ------------- PR: https://git.openjdk.org/jdk/pull/11834 From eosterlund at openjdk.org Thu Jan 5 14:49:51 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 5 Jan 2023 14:49:51 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v2] In-Reply-To: References: <1rK2mzryGeyI-Yak0rUIqYZBuK5zrxCYwPe9zJbjHpY=.5471f1af-f8b8-4219-ae93-8b5a5fecaad9@github.com> Message-ID: On Tue, 3 Jan 2023 13:53:43 GMT, Markus Gr?nlund wrote: >> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix release build > > The upshot with this solution compared to not having stacktraces for the ZPage Allocation Event is that only the relocation parts are sensitive? Other allocation sites can still have stacktraces? Thanks for the review, @mgronlun! ------------- PR: https://git.openjdk.org/jdk/pull/11778 From coleenp at openjdk.org Thu Jan 5 14:58:20 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 5 Jan 2023 14:58:20 GMT Subject: RFR: 8299274: Add elements to resolved_references consistently [v3] In-Reply-To: References: Message-ID: > I added a resolved_references_at and set_resolved_references_at() functions to use for accesses to the resolved_references array, except for the CDS usages. This has an assert that the element is an oop and oob checks and setting elements use a CAS consistently. > These asserts seem useful for finding the bug causing https://bugs.openjdk.org/browse/JDK-8296915. > Tested with tiers1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Change the name to resolved_reference_at because there's a resolved_klass_at but I don't like this name as much as having resolved_references (plural) in the name. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11834/files - new: https://git.openjdk.org/jdk/pull/11834/files/50ff492c..015e590a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11834&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11834&range=01-02 Stats: 15 lines in 6 files changed: 0 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/11834.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11834/head:pull/11834 PR: https://git.openjdk.org/jdk/pull/11834 From mbaesken at openjdk.org Thu Jan 5 15:02:39 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 5 Jan 2023 15:02:39 GMT Subject: RFR: JDK-8299672: Enhance HeapDump JFR event Message-ID: Enhance the JFR Event HeapDump with the additional interesting fields, compression and overwrite. Add some UL logging in case the heap dump writing failed . ------------- Commit messages: - JDK-8299672 - Enhance HeapDump event, UL log in case heap dump writing failed Changes: https://git.openjdk.org/jdk/pull/11864/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11864&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299672 Stats: 14 lines in 3 files changed: 9 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/11864.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11864/head:pull/11864 PR: https://git.openjdk.org/jdk/pull/11864 From apangin at openjdk.org Thu Jan 5 15:07:51 2023 From: apangin at openjdk.org (Andrei Pangin) Date: Thu, 5 Jan 2023 15:07:51 GMT Subject: RFR: 8299544: Improve performance of CRC32C intrinsics (non-AVX-512) for small inputs In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 21:19:32 GMT, Vladimir Kozlov wrote: >> When comparing performance of JDK built-in CRC32C intrinsics with the native implementation, we noticed that JDK performs notably worse on smaller array sizes (up to 1024 bytes). >> >> The main reason is that the algorithm based on the ["Fast CRC Computation for iSCSI Polynomial Using CRC32 Instruction"](https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/crc-iscsi-polynomial-crc32-instruction-paper.pdf) paper, processes input buffer in [chunks](https://github.com/openjdk/jdk/blob/92dfc735f2297441a99b3e39464fb8f77a354d55/src/hotspot/cpu/x86/crc32c.h#L29-L50) of 6144, 2064, and 648 bytes, and the rest of the buffer is processed sequentially with [4-byte variant](https://github.com/openjdk/jdk/blob/92dfc735f2297441a99b3e39464fb8f77a354d55/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L8231-L8236) of CRC32 instruction. >> >> Experiments show that CRC32C computation performance can be improved for smaller inputs without performance impact for larger inputs, if the smallest chunk size is reduced from 648 to 216 bytes. Actually, the original paper suggests the algorithms CRC_216 / CRC_240 for processing blocks of 216 and 240 bytes respectively. The value 648 might have resulted from an "x3" mistake (the algorithm accumulates 3 checksums per iteration). >> >> Additionally, when processing the tail (less than 216 bytes), we can use 8-byte variant of CRC32 instruction instead of 4-byte variant to speed up the algorithm even further. >> >> ### Changes in this PR >> >> 1. CRC32C_LOW is decreased from 8 * 27 to 8 * 9 (which corresponds to 216 bytes). >> 2. CRC32C_MIDDLE is decreased from 8 * 86 to 8 * 74 to compensate for performance drop for mid-size arrays. The value 74 has been chosen empirically. According to experiments, values from 70 to 75 yield the best results, while with higher or lower values, there is a degradation for certain array sizes. >> 3. On x86_64, `CRC32 r32, [m32]` instruction is replaced with `CRC32 r64, [m64]` in the tail loop. >> 4. Unconditional JMP is replaced with a conditional jump at the end of the loop. >> 5. The hot tail loop is aligned. >> >> ### Notes >> >> - The changes are only for x86 architecture. >> - If the hardware supports AVX-512 extensions + VPCLMULQDQ instruction (introduced with Ice Lake), another version of CRC32C intrinsics is generated, and the changes do not have effect. >> >> ### Performance >> >> JMH benchmark used to assess performance: https://cr.openjdk.java.net/~apangin/8299544/CrcBench.java >> >> Tested hardware: >> - Intel Xeon Platinum 8259CL >> - Intel Xeon Platinum 8124M >> - Intel Core i7-1280P >> - AMD EPYC 7251 >> >> Raw JMH results: >> https://cr.openjdk.java.net/~apangin/8299544/jmh/ >> >> Performance curve: >> crc32c-perf-curve >> >> Improvement summary as a table: >> crc32c-perf-table >> >> and as a graph: >> crc32c-perf-graph >> >> I also checked [TestCRC32C.java](https://github.com/openjdk/jdk/blob/872384707e89d03ede655aad16f360dc94f10152/test/micro/org/openjdk/bench/java/util/TestCRC32C.java) microbenchmark included in the JDK source code. It also shows similar improvement: >> >> **Intel Xeon Platinum 8259CL** >> >> ORIGINAL PATCHED >> Benchmark (count) Mode Cnt Score Error Units Score Error Diff >> TestCRC32C.testCRC32CUpdate 64 thrpt 12 61526.044 ? 14.426 ops/ms 116187.797 ? 37.719 88.8% >> TestCRC32C.testCRC32CUpdate 128 thrpt 12 30043.410 ? 275.597 ops/ms 61527.139 ? 11.407 104.8% >> TestCRC32C.testCRC32CUpdate 256 thrpt 12 16086.548 ? 1.386 ops/ms 49801.463 ? 4.034 209.6% >> TestCRC32C.testCRC32CUpdate 512 thrpt 12 8107.780 ? 0.837 ops/ms 25506.806 ? 5.119 214.6% >> TestCRC32C.testCRC32CUpdate 1024 thrpt 12 8171.332 ? 0.684 ops/ms 12913.665 ? 1.425 58.0% >> TestCRC32C.testCRC32CUpdate 2048 thrpt 12 8300.331 ? 1.848 ops/ms 10155.094 ? 1.551 22.3% >> TestCRC32C.testCRC32CUpdate 4096 thrpt 12 4886.483 ? 2.027 ops/ms 5101.460 ? 1.001 4.4% >> TestCRC32C.testCRC32CUpdate 8192 thrpt 12 2690.988 ? 0.315 ops/ms 2859.960 ? 0.807 6.3% >> TestCRC32C.testCRC32CUpdate 16384 thrpt 12 1414.695 ? 0.477 ops/ms 1432.189 ? 0.162 1.2% >> TestCRC32C.testCRC32CUpdate 32768 thrpt 12 671.593 ? 103.208 ops/ms 682.077 ? 106.374 1.6% >> TestCRC32C.testCRC32CUpdate 65536 thrpt 12 340.002 ? 53.363 ops/ms 341.034 ? 53.581 0.3% >> >> >> **AMD EPYC 7251** >> >> ORIGINAL PATCHED >> Benchmark (count) Mode Cnt Score Error Units Score Error Diff >> TestCRC32C.testCRC32CUpdate 64 thrpt 12 32061.964 ? 26.971 ops/ms 53863.073 ? 133.610 68.0% >> TestCRC32C.testCRC32CUpdate 128 thrpt 12 17706.981 ? 19.582 ops/ms 32515.029 ? 14.303 83.6% >> TestCRC32C.testCRC32CUpdate 256 thrpt 12 8455.888 ? 5.070 ops/ms 19181.871 ? 35.279 126.8% >> TestCRC32C.testCRC32CUpdate 512 thrpt 12 4550.874 ? 1.293 ops/ms 10008.634 ? 17.191 119.9% >> TestCRC32C.testCRC32CUpdate 1024 thrpt 12 3636.205 ? 7.306 ops/ms 5122.156 ? 3.912 40.9% >> TestCRC32C.testCRC32CUpdate 2048 thrpt 12 2549.876 ? 90.854 ops/ms 2811.828 ? 5.924 10.3% >> TestCRC32C.testCRC32CUpdate 4096 thrpt 12 1335.905 ? 1.813 ops/ms 1389.812 ? 2.177 4.0% >> TestCRC32C.testCRC32CUpdate 8192 thrpt 12 717.871 ? 7.692 ops/ms 737.720 ? 0.357 2.8% >> TestCRC32C.testCRC32CUpdate 16384 thrpt 12 361.759 ? 1.755 ops/ms 364.348 ? 0.487 0.7% >> TestCRC32C.testCRC32CUpdate 32768 thrpt 12 183.699 ? 0.586 ops/ms 184.822 ? 0.178 0.6% >> TestCRC32C.testCRC32CUpdate 65536 thrpt 12 92.636 ? 0.133 ops/ms 92.850 ? 0.145 0.2% > > Please, show performance curve graph before and after your changes. > > `Disclaimer:` in `x86/crc32c.h` says that if you change constants you may need to adjust other places in VM. Do you need for this changes? @vnkozlov Thank you for your comments. I amended PR description with benchmark results and performance graphs. As to the disclaimer in `crc32c.h`, it is about changing the number of chunks: `CRC32C_NUM_ChunkSizeInBytes = 3`. I experimented with 4 chunks as well, but the performance gains were not large enough to justify more code changes, so I just left 3 chunks for simplicity. ------------- PR: https://git.openjdk.org/jdk/pull/11838 From eastigeevich at openjdk.org Thu Jan 5 15:14:49 2023 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Thu, 5 Jan 2023 15:14:49 GMT Subject: RFR: 8299544: Improve performance of CRC32C intrinsics (non-AVX-512) for small inputs In-Reply-To: References: Message-ID: <86S2TwvkPRzhEuz22_gLNcOvlMi9HZZeUnBvumKbWPA=.f5efb22c-f872-4e9a-baa2-8a29665b3238@github.com> On Wed, 4 Jan 2023 02:36:25 GMT, Andrei Pangin wrote: > When comparing performance of JDK built-in CRC32C intrinsics with the native implementation, we noticed that JDK performs notably worse on smaller array sizes (up to 1024 bytes). > > The main reason is that the algorithm based on the ["Fast CRC Computation for iSCSI Polynomial Using CRC32 Instruction"](https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/crc-iscsi-polynomial-crc32-instruction-paper.pdf) paper, processes input buffer in [chunks](https://github.com/openjdk/jdk/blob/92dfc735f2297441a99b3e39464fb8f77a354d55/src/hotspot/cpu/x86/crc32c.h#L29-L50) of 6144, 2064, and 648 bytes, and the rest of the buffer is processed sequentially with [4-byte variant](https://github.com/openjdk/jdk/blob/92dfc735f2297441a99b3e39464fb8f77a354d55/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L8231-L8236) of CRC32 instruction. > > Experiments show that CRC32C computation performance can be improved for smaller inputs without performance impact for larger inputs, if the smallest chunk size is reduced from 648 to 216 bytes. Actually, the original paper suggests the algorithms CRC_216 / CRC_240 for processing blocks of 216 and 240 bytes respectively. The value 648 might have resulted from an "x3" mistake (the algorithm accumulates 3 checksums per iteration). > > Additionally, when processing the tail (less than 216 bytes), we can use 8-byte variant of CRC32 instruction instead of 4-byte variant to speed up the algorithm even further. > > ### Changes in this PR > > 1. CRC32C_LOW is decreased from 8 * 27 to 8 * 9 (which corresponds to 216 bytes). > 2. CRC32C_MIDDLE is decreased from 8 * 86 to 8 * 74 to compensate for performance drop for mid-size arrays. The value 74 has been chosen empirically. According to experiments, values from 70 to 75 yield the best results, while with higher or lower values, there is a degradation for certain array sizes. > 3. On x86_64, `CRC32 r32, [m32]` instruction is replaced with `CRC32 r64, [m64]` in the tail loop. > 4. Unconditional JMP is replaced with a conditional jump at the end of the loop. > 5. The hot tail loop is aligned. > > ### Notes > > - The changes are only for x86 architecture. > - If the hardware supports AVX-512 extensions + VPCLMULQDQ instruction (introduced with Ice Lake), another version of CRC32C intrinsics is generated, and the changes do not have effect. > > ### Performance > > JMH benchmark used to assess performance: https://cr.openjdk.java.net/~apangin/8299544/CrcBench.java > > Tested hardware: > - Intel Xeon Platinum 8259CL > - Intel Xeon Platinum 8124M > - Intel Core i7-1280P > - AMD EPYC 7251 > > Raw JMH results: > https://cr.openjdk.java.net/~apangin/8299544/jmh/ > > Performance curve: > crc32c-perf-curve > > Improvement summary as a table: > crc32c-perf-table > > and as a graph: > crc32c-perf-graph > > I also checked [TestCRC32C.java](https://github.com/openjdk/jdk/blob/872384707e89d03ede655aad16f360dc94f10152/test/micro/org/openjdk/bench/java/util/TestCRC32C.java) microbenchmark included in the JDK source code. It also shows similar improvement: > > **Intel Xeon Platinum 8259CL** > > ORIGINAL PATCHED > Benchmark (count) Mode Cnt Score Error Units Score Error Diff > TestCRC32C.testCRC32CUpdate 64 thrpt 12 61526.044 ? 14.426 ops/ms 116187.797 ? 37.719 88.8% > TestCRC32C.testCRC32CUpdate 128 thrpt 12 30043.410 ? 275.597 ops/ms 61527.139 ? 11.407 104.8% > TestCRC32C.testCRC32CUpdate 256 thrpt 12 16086.548 ? 1.386 ops/ms 49801.463 ? 4.034 209.6% > TestCRC32C.testCRC32CUpdate 512 thrpt 12 8107.780 ? 0.837 ops/ms 25506.806 ? 5.119 214.6% > TestCRC32C.testCRC32CUpdate 1024 thrpt 12 8171.332 ? 0.684 ops/ms 12913.665 ? 1.425 58.0% > TestCRC32C.testCRC32CUpdate 2048 thrpt 12 8300.331 ? 1.848 ops/ms 10155.094 ? 1.551 22.3% > TestCRC32C.testCRC32CUpdate 4096 thrpt 12 4886.483 ? 2.027 ops/ms 5101.460 ? 1.001 4.4% > TestCRC32C.testCRC32CUpdate 8192 thrpt 12 2690.988 ? 0.315 ops/ms 2859.960 ? 0.807 6.3% > TestCRC32C.testCRC32CUpdate 16384 thrpt 12 1414.695 ? 0.477 ops/ms 1432.189 ? 0.162 1.2% > TestCRC32C.testCRC32CUpdate 32768 thrpt 12 671.593 ? 103.208 ops/ms 682.077 ? 106.374 1.6% > TestCRC32C.testCRC32CUpdate 65536 thrpt 12 340.002 ? 53.363 ops/ms 341.034 ? 53.581 0.3% > > > **AMD EPYC 7251** > > ORIGINAL PATCHED > Benchmark (count) Mode Cnt Score Error Units Score Error Diff > TestCRC32C.testCRC32CUpdate 64 thrpt 12 32061.964 ? 26.971 ops/ms 53863.073 ? 133.610 68.0% > TestCRC32C.testCRC32CUpdate 128 thrpt 12 17706.981 ? 19.582 ops/ms 32515.029 ? 14.303 83.6% > TestCRC32C.testCRC32CUpdate 256 thrpt 12 8455.888 ? 5.070 ops/ms 19181.871 ? 35.279 126.8% > TestCRC32C.testCRC32CUpdate 512 thrpt 12 4550.874 ? 1.293 ops/ms 10008.634 ? 17.191 119.9% > TestCRC32C.testCRC32CUpdate 1024 thrpt 12 3636.205 ? 7.306 ops/ms 5122.156 ? 3.912 40.9% > TestCRC32C.testCRC32CUpdate 2048 thrpt 12 2549.876 ? 90.854 ops/ms 2811.828 ? 5.924 10.3% > TestCRC32C.testCRC32CUpdate 4096 thrpt 12 1335.905 ? 1.813 ops/ms 1389.812 ? 2.177 4.0% > TestCRC32C.testCRC32CUpdate 8192 thrpt 12 717.871 ? 7.692 ops/ms 737.720 ? 0.357 2.8% > TestCRC32C.testCRC32CUpdate 16384 thrpt 12 361.759 ? 1.755 ops/ms 364.348 ? 0.487 0.7% > TestCRC32C.testCRC32CUpdate 32768 thrpt 12 183.699 ? 0.586 ops/ms 184.822 ? 0.178 0.6% > TestCRC32C.testCRC32CUpdate 65536 thrpt 12 92.636 ? 0.133 ops/ms 92.850 ? 0.145 0.2% LGTM ------------- Marked as reviewed by eastigeevich (Committer). PR: https://git.openjdk.org/jdk/pull/11838 From iklam at openjdk.org Thu Jan 5 17:12:48 2023 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 5 Jan 2023 17:12:48 GMT Subject: RFR: 8299275: Add some ClassLoaderData verification code In-Reply-To: References: <1Adx9iDHr_fSF8l2AXfNF9Rzq5NpPwhqiJ2AxnorYRQ=.88805086-76f3-4839-80de-ad059f7304f7@github.com> Message-ID: On Thu, 5 Jan 2023 14:38:07 GMT, Coleen Phillimore wrote: >> // Verification >> virtual void verify_on(outputStream* st); >> void verify() { verify_on(tty); } >> >> It calls the virtual function InstanceKlass::verify_on() > > Yes, I did add the deallocate_list verification too. I can change the title of the bug. This code seem unsafe since you are checking for `is_klass()` but cast to `InstanceKlass*`. Since `verify()` is in `Klass` anyway, it's better to say if (m->is_klass()) { ((Klass*)m)->verify(); ------------- PR: https://git.openjdk.org/jdk/pull/11856 From kvn at openjdk.org Thu Jan 5 17:16:51 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 5 Jan 2023 17:16:51 GMT Subject: RFR: 8298720: Insufficient error handling when CodeBuffer is exhausted [v4] In-Reply-To: References: Message-ID: On Thu, 5 Jan 2023 07:06:13 GMT, Tobias Hartmann wrote: >> This patch fixes various places in C1 and C2 on Aarch64 and RISC-V that miss proper error handling when the code buffer is exhausted, leading to crashes. Similar but incomplete patches went in with [JDK-8130309](https://bugs.openjdk.org/browse/JDK-8130309), [JDK-8248411](https://bugs.openjdk.org/browse/JDK-8248411) and [JDK-8272094](https://bugs.openjdk.org/browse/JDK-8272094) in the past. >> >> These issues are extremely hard to reproduce, even with the `-XX:+StressCodeBuffers` option, because code buffer expansion needs to fail at the exact moment when a specific (unhandled) instruction is emitted. Even with the stress option, we expand the code buffer such that multiple instructions will fit and in addition, chances are high that we simply bail out from compilation before emitting the problematic instruction. I attached a patch to [JDK-8298720](https://bugs.openjdk.org/browse/JDK-8298720), that makes `-XX:+StressCodeBuffers` randomized and more aggressive. With that, I can reproduce the issue reliably but it's extremely slow and therefore not well suited for integration. >> >> I now went over all usages of `CodeBuffer::expand` to make sure that we have proper error handling in place and found some remaining issues in JVMCI code. I filed [JDK-8299570](https://bugs.openjdk.org/browse/JDK-8299570) to address them. >> >> I would need help to test the RISC-V specific changes. >> >> Thanks, >> Tobias > > Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision: > > Updated copyrights Looks good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11839 From iklam at openjdk.org Thu Jan 5 17:28:50 2023 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 5 Jan 2023 17:28:50 GMT Subject: RFR: 8299274: Add elements to resolved_references consistently [v3] In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 15:11:30 GMT, Coleen Phillimore wrote: >>> I need it to return the existing value for the code in resolve_constant_at_impl(). >> >> So it's a getter/setter, but if the argument must be nullptr, I think we should skip it. > > obj_at_put already checks the index. I agree with David's naming. For grepping, it's better to grep for the singular form as there are already functions that use the singular form. $ find src/hotspot -type f | xargs grep resolved_reference | grep -v references | wc 41 223 4559 Here are some examples. If you grep for the plural form, you will miss them. ./share/oops/constantPool.cpp: set_resolved_reference_length( ./share/oops/constantPool.hpp: int _resolved_reference_length; ./share/oops/cpCache.hpp: void initialize_resolved_reference_index(int ref_index) { ------------- PR: https://git.openjdk.org/jdk/pull/11834 From rehn at openjdk.org Thu Jan 5 18:28:55 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 5 Jan 2023 18:28:55 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7] In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 16:56:40 GMT, Afshin Zafari wrote: >> test of tier1-5 passed. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8292741: Convert JvmtiTagMapTable to ResourceHashtable Looks fine, thanks. (+- DavidH comment) ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11288 From jcking at openjdk.org Thu Jan 5 18:40:42 2023 From: jcking at openjdk.org (Justin King) Date: Thu, 5 Jan 2023 18:40:42 GMT Subject: RFR: JDK-8299688: Adopt C++14 compatible std::bit_cast introduced in C++20 Message-ID: Adopts a C++14 compatible implementation of [std::bit_cast](https://en.cppreference.com/w/cpp/numeric/bit_cast). `PrimitiveConversions::cast` is refactored into `bit_cast` and extended to support all compatible types. Additionally it makes use of `__builtin_bit_cast` when available, which is strictly well defined compared to fallback approaches which are sometimes lurking in undefined behavior territory. Lastly some legacy casting is updated to use `bit_cast` in `utilities/globalDefinitions.hpp`. ------------- Commit messages: - Correctly handle const/volatile pointers - Use __builtin_bit_cast when available for every specialization of bit_cast - Minor cleanup - Ensure operator& overloading is ignored - Fix interdependency - Fix interdependency - Do not use bit_cast for function pointer conversion - Use bit_cast in utilities/globalDefinitions.hpp - Add additional test cases - Remove include and fix another include - ... and 2 more: https://git.openjdk.org/jdk/compare/41900b57...4cff62ba Changes: https://git.openjdk.org/jdk/pull/11865/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11865&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299688 Stats: 687 lines in 18 files changed: 400 ins; 236 del; 51 mod Patch: https://git.openjdk.org/jdk/pull/11865.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11865/head:pull/11865 PR: https://git.openjdk.org/jdk/pull/11865 From iklam at openjdk.org Thu Jan 5 19:14:56 2023 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 5 Jan 2023 19:14:56 GMT Subject: RFR: 8299274: Add elements to resolved_references consistently [v3] In-Reply-To: References: Message-ID: <5vwkKU-JOds1_6M2NAIj-CWtglSsP_c-GTDrX_vePMw=.5b201b5e-2acd-4fc8-8a3b-9b14e83b770b@github.com> On Thu, 5 Jan 2023 14:58:20 GMT, Coleen Phillimore wrote: >> I added a resolved_references_at and set_resolved_references_at() functions to use for accesses to the resolved_references array, except for the CDS usages. This has an assert that the element is an oop and oob checks and setting elements use a CAS consistently. >> These asserts seem useful for finding the bug causing https://bugs.openjdk.org/browse/JDK-8296915. >> Tested with tiers1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Change the name to resolved_reference_at because there's a resolved_klass_at but I don't like this name as much as having resolved_references (plural) in the name. Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11834 From coleenp at openjdk.org Thu Jan 5 19:16:09 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 5 Jan 2023 19:16:09 GMT Subject: RFR: 8299275: Add some ClassLoaderData verification code [v2] In-Reply-To: <1Adx9iDHr_fSF8l2AXfNF9Rzq5NpPwhqiJ2AxnorYRQ=.88805086-76f3-4839-80de-ad059f7304f7@github.com> References: <1Adx9iDHr_fSF8l2AXfNF9Rzq5NpPwhqiJ2AxnorYRQ=.88805086-76f3-4839-80de-ad059f7304f7@github.com> Message-ID: > I added some verification code to try to help track down JDK-8296915 (https://bugs.openjdk.org/browse/JDK-8296915). > Ran Test: runtime/SelectionResolution/InvokeInterfaceSuccessTest.java 100x with -XX:+VerifyBefore/AfterGC. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Cast to Klass ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11856/files - new: https://git.openjdk.org/jdk/pull/11856/files/4701cf48..4775cbc9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11856&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11856&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11856.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11856/head:pull/11856 PR: https://git.openjdk.org/jdk/pull/11856 From coleenp at openjdk.org Thu Jan 5 19:17:50 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 5 Jan 2023 19:17:50 GMT Subject: RFR: 8299274: Add elements to resolved_references consistently [v3] In-Reply-To: References: Message-ID: On Thu, 5 Jan 2023 14:58:20 GMT, Coleen Phillimore wrote: >> I added a resolved_references_at and set_resolved_references_at() functions to use for accesses to the resolved_references array, except for the CDS usages. This has an assert that the element is an oop and oob checks and setting elements use a CAS consistently. >> These asserts seem useful for finding the bug causing https://bugs.openjdk.org/browse/JDK-8296915. >> Tested with tiers1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Change the name to resolved_reference_at because there's a resolved_klass_at but I don't like this name as much as having resolved_references (plural) in the name. Thanks for reviewing, Ioi. singular resolved_reference looks better to me today than it did yesterday. ------------- PR: https://git.openjdk.org/jdk/pull/11834 From kbarrett at openjdk.org Thu Jan 5 19:33:48 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 5 Jan 2023 19:33:48 GMT Subject: RFR: 8299254: Support dealing with standard assert macro In-Reply-To: References: <6VQwFg9prwXbOwp_asHA4-Wru6PdKvaRN8MGiU24_sw=.1cafd8ea-e7e4-4a9d-a8ba-4f0cf87621d2@github.com> Message-ID: On Tue, 3 Jan 2023 03:11:32 GMT, Xue-Lei Andrew Fan wrote: >> Please review this change to provide and use mechanisms for dealing with uses >> of the standard assert macro (from or ) in 3rd party code >> that we use in HotSpot. >> >> We provide a pair of utility header files, to be included before and after a >> header that may use (and so include) the standard assert macro. These new >> headers provide a scope in which the HotSpot assert macro is not defined, and >> then reinstated after. >> >> We also define NDEBUG in release builds of HotSpot, so any uses of the >> standard assert macro in such 3rd party code will be disabled. >> >> Finally, we use the new utility headers in some gtests and in our gtest >> wrapper header (unittest.hpp), eliminating problems the gtest implementation >> and with some versions of some standard libraries that the tests use. >> >> Testing: >> mach5 tier1 > > The patch passed for my build on MacOSX13.1/M1 (See JDK-8299380). Thanks! Thanks for reviews @XueleiFan , @dholmes-ora , @erikj79 , and @vidmik . ------------- PR: https://git.openjdk.org/jdk/pull/11770 From kbarrett at openjdk.org Thu Jan 5 19:54:48 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 5 Jan 2023 19:54:48 GMT Subject: RFR: 8299254: Support dealing with standard assert macro [v2] In-Reply-To: <6VQwFg9prwXbOwp_asHA4-Wru6PdKvaRN8MGiU24_sw=.1cafd8ea-e7e4-4a9d-a8ba-4f0cf87621d2@github.com> References: <6VQwFg9prwXbOwp_asHA4-Wru6PdKvaRN8MGiU24_sw=.1cafd8ea-e7e4-4a9d-a8ba-4f0cf87621d2@github.com> Message-ID: > Please review this change to provide and use mechanisms for dealing with uses > of the standard assert macro (from or ) in 3rd party code > that we use in HotSpot. > > We provide a pair of utility header files, to be included before and after a > header that may use (and so include) the standard assert macro. These new > headers provide a scope in which the HotSpot assert macro is not defined, and > then reinstated after. > > We also define NDEBUG in release builds of HotSpot, so any uses of the > standard assert macro in such 3rd party code will be disabled. > > Finally, we use the new utility headers in some gtests and in our gtest > wrapper header (unittest.hpp), eliminating problems the gtest implementation > and with some versions of some standard libraries that the tests use. > > Testing: > mach5 tier1 Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' into std-assert - define NDEBUG in HotSpot release builds - use vmassert_uninstall/reinstall in gtests - utility for manipulating HotSpot assert macro ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11770/files - new: https://git.openjdk.org/jdk/pull/11770/files/8b9a2d60..c122a265 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11770&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11770&range=00-01 Stats: 5917 lines in 567 files changed: 2798 ins; 1954 del; 1165 mod Patch: https://git.openjdk.org/jdk/pull/11770.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11770/head:pull/11770 PR: https://git.openjdk.org/jdk/pull/11770 From kbarrett at openjdk.org Thu Jan 5 19:54:50 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 5 Jan 2023 19:54:50 GMT Subject: Integrated: 8299254: Support dealing with standard assert macro In-Reply-To: <6VQwFg9prwXbOwp_asHA4-Wru6PdKvaRN8MGiU24_sw=.1cafd8ea-e7e4-4a9d-a8ba-4f0cf87621d2@github.com> References: <6VQwFg9prwXbOwp_asHA4-Wru6PdKvaRN8MGiU24_sw=.1cafd8ea-e7e4-4a9d-a8ba-4f0cf87621d2@github.com> Message-ID: <__ih9V-t81EJYoFI61agHjoCNdAvRaHW4K4N6BlGWww=.4a0c45a1-ab1a-4add-b5d8-73ef15e3187a@github.com> On Thu, 22 Dec 2022 23:05:03 GMT, Kim Barrett wrote: > Please review this change to provide and use mechanisms for dealing with uses > of the standard assert macro (from or ) in 3rd party code > that we use in HotSpot. > > We provide a pair of utility header files, to be included before and after a > header that may use (and so include) the standard assert macro. These new > headers provide a scope in which the HotSpot assert macro is not defined, and > then reinstated after. > > We also define NDEBUG in release builds of HotSpot, so any uses of the > standard assert macro in such 3rd party code will be disabled. > > Finally, we use the new utility headers in some gtests and in our gtest > wrapper header (unittest.hpp), eliminating problems the gtest implementation > and with some versions of some standard libraries that the tests use. > > Testing: > mach5 tier1 This pull request has now been integrated. Changeset: 3e2314d0 Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/3e2314d08218dc8a4f4fc61bd4e1d5e58a0129c7 Stats: 122 lines in 8 files changed: 102 ins; 16 del; 4 mod 8299254: Support dealing with standard assert macro Reviewed-by: erikj, xuelei, dholmes, mikael ------------- PR: https://git.openjdk.org/jdk/pull/11770 From iklam at openjdk.org Thu Jan 5 19:58:59 2023 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 5 Jan 2023 19:58:59 GMT Subject: RFR: 8299275: Add some ClassLoaderData verification code [v2] In-Reply-To: References: <1Adx9iDHr_fSF8l2AXfNF9Rzq5NpPwhqiJ2AxnorYRQ=.88805086-76f3-4839-80de-ad059f7304f7@github.com> Message-ID: On Thu, 5 Jan 2023 19:16:09 GMT, Coleen Phillimore wrote: >> I added some verification code to try to help track down JDK-8296915 (https://bugs.openjdk.org/browse/JDK-8296915). >> Ran Test: runtime/SelectionResolution/InvokeInterfaceSuccessTest.java 100x with -XX:+VerifyBefore/AfterGC. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Cast to Klass Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11856 From jcking at openjdk.org Thu Jan 5 19:59:40 2023 From: jcking at openjdk.org (Justin King) Date: Thu, 5 Jan 2023 19:59:40 GMT Subject: RFR: JDK-8299688: Adopt C++14 compatible std::bit_cast introduced in C++20 [v2] In-Reply-To: References: Message-ID: > Adopts a C++14 compatible implementation of [std::bit_cast](https://en.cppreference.com/w/cpp/numeric/bit_cast). > > `PrimitiveConversions::cast` is refactored into `bit_cast` and extended to support all compatible types. Additionally it makes use of `__builtin_bit_cast` when available, which is strictly well defined compared to fallback approaches which are sometimes lurking in undefined behavior territory. > > Lastly some legacy casting is updated to use `bit_cast` in `utilities/globalDefinitions.hpp`. Justin King has updated the pull request incrementally with one additional commit since the last revision: Apple Clang thinks __builtin_bit_cast is present when its not Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11865/files - new: https://git.openjdk.org/jdk/pull/11865/files/4cff62ba..281a915e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11865&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11865&range=00-01 Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/11865.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11865/head:pull/11865 PR: https://git.openjdk.org/jdk/pull/11865 From pchilanomate at openjdk.org Thu Jan 5 20:56:37 2023 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 5 Jan 2023 20:56:37 GMT Subject: [jdk20] RFR: 8294744: applications/kitchensink/Kitchensink.java crashed: assert(oopDesc::is_oop(obj)) failed: not an oop Message-ID: Please review the following patch. The value we set initially for extended_sp on natives frames doesn't account for the oop that could be pushed to the stack in case the method throws an exception. This can create a situation in Interpreter::_throw_exception_entry where we push an exception oop to the Java expression stack below the actual physical stack pointer. When JFR is present though a JavaThread could receive a suspend signal right after that push. On Linux aarch64, because there is no red zone defined (nor implemented it seems), the pushed oop gets overwritten during the setup and execution of the signal handler. This later leads to a crash when popping the oop back and rethrowing in the caller of the native method. There are more details in the bug comments. To fix it I used the same technique we use for normal Java frames, i.e. add extra space to extended_sp when creating the frame to account for the max space needed. I tested the patch by running Kitchensink.java around 150 times on mach5 with no failures (without the patch 50 runs would already show ~10 failures on average). I also run tiers1-6 for sanity check. Thanks, Patricio ------------- Commit messages: - v1 Changes: https://git.openjdk.org/jdk20/pull/85/files Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=85&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294744 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk20/pull/85.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/85/head:pull/85 PR: https://git.openjdk.org/jdk20/pull/85 From kbarrett at openjdk.org Thu Jan 5 21:36:51 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 5 Jan 2023 21:36:51 GMT Subject: RFR: JDK-8299481: Remove metaprogramming/removePointer.hpp [v2] In-Reply-To: References: Message-ID: On Tue, 3 Jan 2023 14:33:36 GMT, Justin King wrote: >> Code cleanup of pre-C++11 implementations. > > Justin King has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge remote-tracking branch 'upstream/master' into remove-remove-pointer > - Remove include > > Signed-off-by: Justin King > - Remove metaprogramming/removePointer.hpp > > Signed-off-by: Justin King Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11817 From bpb at openjdk.org Thu Jan 5 22:33:48 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 5 Jan 2023 22:33:48 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly Message-ID: Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. ------------- Commit messages: - 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly Changes: https://git.openjdk.org/jdk/pull/11873/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299684 Stats: 21 lines in 2 files changed: 12 ins; 3 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From duke at openjdk.org Thu Jan 5 23:10:53 2023 From: duke at openjdk.org (SWinxy) Date: Thu, 5 Jan 2023 23:10:53 GMT Subject: RFR: 8299378: sprintf is deprecated in Xcode 14 [v3] In-Reply-To: References: Message-ID: On Tue, 3 Jan 2023 16:28:54 GMT, Xue-Lei Andrew Fan wrote: >> The `sprintf` is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812), but the test was not covered. The failure was [reported later](https://github.com/openjdk/jdk/pull/11115#issuecomment-1344973773), while gtest is enabled for building. >> >> This patch is just to make sure the building could pass. Other than that, the use of `sprintf` in other places are not touched. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > sort includes alphabetically Oddly, this PR didn't solve it for me either. [8299635](https://bugs.openjdk.org/browse/JDK-8299635) should include the failure of `libAsyncExceptionOnMonitorEnter`. ------------- PR: https://git.openjdk.org/jdk/pull/11793 From psandoz at openjdk.org Thu Jan 5 23:25:50 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 5 Jan 2023 23:25:50 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly In-Reply-To: References: Message-ID: <4y4hWpgTAz89OygAA5LAjIfEeAP7OEyDbQHWO9DceA0=.5a6e4061-4d08-40cf-a90c-12d1af36bd7d@github.com> On Thu, 5 Jan 2023 22:25:19 GMT, Brian Burkhalter wrote: > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Requires an update to the JNI spec and therefore a CSR? src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 249: > 247: return Math.toIntExact(capacity); > 248: } catch (ArithmeticException ignore) { > 249: throw new IllegalArgumentException("capacity " + capacity I think we should mention the source, that the capacity value originates from a native call to NewDirectByteBuffer, since that will not appear in any frames of the reported stack trace. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Thu Jan 5 23:25:50 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 5 Jan 2023 23:25:50 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly In-Reply-To: <4y4hWpgTAz89OygAA5LAjIfEeAP7OEyDbQHWO9DceA0=.5a6e4061-4d08-40cf-a90c-12d1af36bd7d@github.com> References: <4y4hWpgTAz89OygAA5LAjIfEeAP7OEyDbQHWO9DceA0=.5a6e4061-4d08-40cf-a90c-12d1af36bd7d@github.com> Message-ID: <6XtN6Ds03G9CeeL2_eUjbtlAi3NSq-pL6-o9zXRJSzI=.fca79da0-0e2f-44ae-8900-3639ab9a0f5c@github.com> On Thu, 5 Jan 2023 23:19:53 GMT, Paul Sandoz wrote: > I think we should mention the source, that the capacity value originates from a native call to NewDirectByteBuffer [...] So you mean in the IAE message itself? ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Thu Jan 5 23:31:47 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 5 Jan 2023 23:31:47 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly In-Reply-To: <4y4hWpgTAz89OygAA5LAjIfEeAP7OEyDbQHWO9DceA0=.5a6e4061-4d08-40cf-a90c-12d1af36bd7d@github.com> References: <4y4hWpgTAz89OygAA5LAjIfEeAP7OEyDbQHWO9DceA0=.5a6e4061-4d08-40cf-a90c-12d1af36bd7d@github.com> Message-ID: <-VLIE3QIHpofdg5puizvukVzpmvlniQ8ehZS5WJMdNI=.b24bc2b2-5316-472f-9ddf-76d6bdf1d05b@github.com> On Thu, 5 Jan 2023 23:20:40 GMT, Paul Sandoz wrote: > Requires an update to the JNI spec and therefore a CSR? Yes, I think both. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From psandoz at openjdk.org Thu Jan 5 23:31:50 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 5 Jan 2023 23:31:50 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly In-Reply-To: <6XtN6Ds03G9CeeL2_eUjbtlAi3NSq-pL6-o9zXRJSzI=.fca79da0-0e2f-44ae-8900-3639ab9a0f5c@github.com> References: <4y4hWpgTAz89OygAA5LAjIfEeAP7OEyDbQHWO9DceA0=.5a6e4061-4d08-40cf-a90c-12d1af36bd7d@github.com> <6XtN6Ds03G9CeeL2_eUjbtlAi3NSq-pL6-o9zXRJSzI=.fca79da0-0e2f-44ae-8900-3639ab9a0f5c@github.com> Message-ID: On Thu, 5 Jan 2023 23:22:34 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 249: >> >>> 247: return Math.toIntExact(capacity); >>> 248: } catch (ArithmeticException ignore) { >>> 249: throw new IllegalArgumentException("capacity " + capacity >> >> I think we should mention the source, that the capacity value originates from a native call to NewDirectByteBuffer, since that will not appear in any frames of the reported stack trace. > >> I think we should mention the source, that the capacity value originates from a native call to NewDirectByteBuffer [...] > > So you mean in the IAE message itself? Yes, enhance the message with more detail ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Thu Jan 5 23:42:11 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 5 Jan 2023 23:42:11 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v2] In-Reply-To: References: Message-ID: > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299684: Enhance message in IAE caused by NewDirectByteBuffer passing up a capacity which overflows int range ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11873/files - new: https://git.openjdk.org/jdk/pull/11873/files/8baa0fbb..db924a34 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From sviswanathan at openjdk.org Fri Jan 6 02:25:48 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Fri, 6 Jan 2023 02:25:48 GMT Subject: RFR: 8299544: Improve performance of CRC32C intrinsics (non-AVX-512) for small inputs In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 02:36:25 GMT, Andrei Pangin wrote: > When comparing performance of JDK built-in CRC32C intrinsics with the native implementation, we noticed that JDK performs notably worse on smaller array sizes (up to 1024 bytes). > > The main reason is that the algorithm based on the ["Fast CRC Computation for iSCSI Polynomial Using CRC32 Instruction"](https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/crc-iscsi-polynomial-crc32-instruction-paper.pdf) paper, processes input buffer in [chunks](https://github.com/openjdk/jdk/blob/92dfc735f2297441a99b3e39464fb8f77a354d55/src/hotspot/cpu/x86/crc32c.h#L29-L50) of 6144, 2064, and 648 bytes, and the rest of the buffer is processed sequentially with [4-byte variant](https://github.com/openjdk/jdk/blob/92dfc735f2297441a99b3e39464fb8f77a354d55/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L8231-L8236) of CRC32 instruction. > > Experiments show that CRC32C computation performance can be improved for smaller inputs without performance impact for larger inputs, if the smallest chunk size is reduced from 648 to 216 bytes. Actually, the original paper suggests the algorithms CRC_216 / CRC_240 for processing blocks of 216 and 240 bytes respectively. The value 648 might have resulted from an "x3" mistake (the algorithm accumulates 3 checksums per iteration). > > Additionally, when processing the tail (less than 216 bytes), we can use 8-byte variant of CRC32 instruction instead of 4-byte variant to speed up the algorithm even further. > > ### Changes in this PR > > 1. CRC32C_LOW is decreased from 8 * 27 to 8 * 9 (which corresponds to 216 bytes). > 2. CRC32C_MIDDLE is decreased from 8 * 86 to 8 * 74 to compensate for performance drop for mid-size arrays. The value 74 has been chosen empirically. According to experiments, values from 70 to 75 yield the best results, while with higher or lower values, there is a degradation for certain array sizes. > 3. On x86_64, `CRC32 r32, [m32]` instruction is replaced with `CRC32 r64, [m64]` in the tail loop. > 4. Unconditional JMP is replaced with a conditional jump at the end of the loop. > 5. The hot tail loop is aligned. > > ### Notes > > - The changes are only for x86 architecture. > - If the hardware supports AVX-512 extensions + VPCLMULQDQ instruction (introduced with Ice Lake), another version of CRC32C intrinsics is generated, and the changes do not have effect. > > ### Performance > > JMH benchmark used to assess performance: https://cr.openjdk.java.net/~apangin/8299544/CrcBench.java > > Tested hardware: > - Intel Xeon Platinum 8259CL > - Intel Xeon Platinum 8124M > - Intel Core i7-1280P > - AMD EPYC 7251 > > Raw JMH results: > https://cr.openjdk.java.net/~apangin/8299544/jmh/ > > Performance curve: > crc32c-perf-curve > > Improvement summary as a table: > crc32c-perf-table > > and as a graph: > crc32c-perf-graph > > I also checked [TestCRC32C.java](https://github.com/openjdk/jdk/blob/872384707e89d03ede655aad16f360dc94f10152/test/micro/org/openjdk/bench/java/util/TestCRC32C.java) microbenchmark included in the JDK source code. It also shows similar improvement: > > **Intel Xeon Platinum 8259CL** > > ORIGINAL PATCHED > Benchmark (count) Mode Cnt Score Error Units Score Error Diff > TestCRC32C.testCRC32CUpdate 64 thrpt 12 61526.044 ? 14.426 ops/ms 116187.797 ? 37.719 88.8% > TestCRC32C.testCRC32CUpdate 128 thrpt 12 30043.410 ? 275.597 ops/ms 61527.139 ? 11.407 104.8% > TestCRC32C.testCRC32CUpdate 256 thrpt 12 16086.548 ? 1.386 ops/ms 49801.463 ? 4.034 209.6% > TestCRC32C.testCRC32CUpdate 512 thrpt 12 8107.780 ? 0.837 ops/ms 25506.806 ? 5.119 214.6% > TestCRC32C.testCRC32CUpdate 1024 thrpt 12 8171.332 ? 0.684 ops/ms 12913.665 ? 1.425 58.0% > TestCRC32C.testCRC32CUpdate 2048 thrpt 12 8300.331 ? 1.848 ops/ms 10155.094 ? 1.551 22.3% > TestCRC32C.testCRC32CUpdate 4096 thrpt 12 4886.483 ? 2.027 ops/ms 5101.460 ? 1.001 4.4% > TestCRC32C.testCRC32CUpdate 8192 thrpt 12 2690.988 ? 0.315 ops/ms 2859.960 ? 0.807 6.3% > TestCRC32C.testCRC32CUpdate 16384 thrpt 12 1414.695 ? 0.477 ops/ms 1432.189 ? 0.162 1.2% > TestCRC32C.testCRC32CUpdate 32768 thrpt 12 671.593 ? 103.208 ops/ms 682.077 ? 106.374 1.6% > TestCRC32C.testCRC32CUpdate 65536 thrpt 12 340.002 ? 53.363 ops/ms 341.034 ? 53.581 0.3% > > > **AMD EPYC 7251** > > ORIGINAL PATCHED > Benchmark (count) Mode Cnt Score Error Units Score Error Diff > TestCRC32C.testCRC32CUpdate 64 thrpt 12 32061.964 ? 26.971 ops/ms 53863.073 ? 133.610 68.0% > TestCRC32C.testCRC32CUpdate 128 thrpt 12 17706.981 ? 19.582 ops/ms 32515.029 ? 14.303 83.6% > TestCRC32C.testCRC32CUpdate 256 thrpt 12 8455.888 ? 5.070 ops/ms 19181.871 ? 35.279 126.8% > TestCRC32C.testCRC32CUpdate 512 thrpt 12 4550.874 ? 1.293 ops/ms 10008.634 ? 17.191 119.9% > TestCRC32C.testCRC32CUpdate 1024 thrpt 12 3636.205 ? 7.306 ops/ms 5122.156 ? 3.912 40.9% > TestCRC32C.testCRC32CUpdate 2048 thrpt 12 2549.876 ? 90.854 ops/ms 2811.828 ? 5.924 10.3% > TestCRC32C.testCRC32CUpdate 4096 thrpt 12 1335.905 ? 1.813 ops/ms 1389.812 ? 2.177 4.0% > TestCRC32C.testCRC32CUpdate 8192 thrpt 12 717.871 ? 7.692 ops/ms 737.720 ? 0.357 2.8% > TestCRC32C.testCRC32CUpdate 16384 thrpt 12 361.759 ? 1.755 ops/ms 364.348 ? 0.487 0.7% > TestCRC32C.testCRC32CUpdate 32768 thrpt 12 183.699 ? 0.586 ops/ms 184.822 ? 0.178 0.6% > TestCRC32C.testCRC32CUpdate 65536 thrpt 12 92.636 ? 0.133 ops/ms 92.850 ? 0.145 0.2% Very nice work. The changes looks good to me. ------------- Marked as reviewed by sviswanathan (Reviewer). PR: https://git.openjdk.org/jdk/pull/11838 From kvn at openjdk.org Fri Jan 6 02:33:48 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 6 Jan 2023 02:33:48 GMT Subject: RFR: 8299544: Improve performance of CRC32C intrinsics (non-AVX-512) for small inputs In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 02:36:25 GMT, Andrei Pangin wrote: > When comparing performance of JDK built-in CRC32C intrinsics with the native implementation, we noticed that JDK performs notably worse on smaller array sizes (up to 1024 bytes). > > The main reason is that the algorithm based on the ["Fast CRC Computation for iSCSI Polynomial Using CRC32 Instruction"](https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/crc-iscsi-polynomial-crc32-instruction-paper.pdf) paper, processes input buffer in [chunks](https://github.com/openjdk/jdk/blob/92dfc735f2297441a99b3e39464fb8f77a354d55/src/hotspot/cpu/x86/crc32c.h#L29-L50) of 6144, 2064, and 648 bytes, and the rest of the buffer is processed sequentially with [4-byte variant](https://github.com/openjdk/jdk/blob/92dfc735f2297441a99b3e39464fb8f77a354d55/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L8231-L8236) of CRC32 instruction. > > Experiments show that CRC32C computation performance can be improved for smaller inputs without performance impact for larger inputs, if the smallest chunk size is reduced from 648 to 216 bytes. Actually, the original paper suggests the algorithms CRC_216 / CRC_240 for processing blocks of 216 and 240 bytes respectively. The value 648 might have resulted from an "x3" mistake (the algorithm accumulates 3 checksums per iteration). > > Additionally, when processing the tail (less than 216 bytes), we can use 8-byte variant of CRC32 instruction instead of 4-byte variant to speed up the algorithm even further. > > ### Changes in this PR > > 1. CRC32C_LOW is decreased from 8 * 27 to 8 * 9 (which corresponds to 216 bytes). > 2. CRC32C_MIDDLE is decreased from 8 * 86 to 8 * 74 to compensate for performance drop for mid-size arrays. The value 74 has been chosen empirically. According to experiments, values from 70 to 75 yield the best results, while with higher or lower values, there is a degradation for certain array sizes. > 3. On x86_64, `CRC32 r32, [m32]` instruction is replaced with `CRC32 r64, [m64]` in the tail loop. > 4. Unconditional JMP is replaced with a conditional jump at the end of the loop. > 5. The hot tail loop is aligned. > > ### Notes > > - The changes are only for x86 architecture. > - If the hardware supports AVX-512 extensions + VPCLMULQDQ instruction (introduced with Ice Lake), another version of CRC32C intrinsics is generated, and the changes do not have effect. > > ### Performance > > JMH benchmark used to assess performance: https://cr.openjdk.java.net/~apangin/8299544/CrcBench.java > > Tested hardware: > - Intel Xeon Platinum 8259CL > - Intel Xeon Platinum 8124M > - Intel Core i7-1280P > - AMD EPYC 7251 > > Raw JMH results: > https://cr.openjdk.java.net/~apangin/8299544/jmh/ > > Performance curve: > crc32c-perf-curve > > Improvement summary as a table: > crc32c-perf-table > > and as a graph: > crc32c-perf-graph > > I also checked [TestCRC32C.java](https://github.com/openjdk/jdk/blob/872384707e89d03ede655aad16f360dc94f10152/test/micro/org/openjdk/bench/java/util/TestCRC32C.java) microbenchmark included in the JDK source code. It also shows similar improvement: > > **Intel Xeon Platinum 8259CL** > > ORIGINAL PATCHED > Benchmark (count) Mode Cnt Score Error Units Score Error Diff > TestCRC32C.testCRC32CUpdate 64 thrpt 12 61526.044 ? 14.426 ops/ms 116187.797 ? 37.719 88.8% > TestCRC32C.testCRC32CUpdate 128 thrpt 12 30043.410 ? 275.597 ops/ms 61527.139 ? 11.407 104.8% > TestCRC32C.testCRC32CUpdate 256 thrpt 12 16086.548 ? 1.386 ops/ms 49801.463 ? 4.034 209.6% > TestCRC32C.testCRC32CUpdate 512 thrpt 12 8107.780 ? 0.837 ops/ms 25506.806 ? 5.119 214.6% > TestCRC32C.testCRC32CUpdate 1024 thrpt 12 8171.332 ? 0.684 ops/ms 12913.665 ? 1.425 58.0% > TestCRC32C.testCRC32CUpdate 2048 thrpt 12 8300.331 ? 1.848 ops/ms 10155.094 ? 1.551 22.3% > TestCRC32C.testCRC32CUpdate 4096 thrpt 12 4886.483 ? 2.027 ops/ms 5101.460 ? 1.001 4.4% > TestCRC32C.testCRC32CUpdate 8192 thrpt 12 2690.988 ? 0.315 ops/ms 2859.960 ? 0.807 6.3% > TestCRC32C.testCRC32CUpdate 16384 thrpt 12 1414.695 ? 0.477 ops/ms 1432.189 ? 0.162 1.2% > TestCRC32C.testCRC32CUpdate 32768 thrpt 12 671.593 ? 103.208 ops/ms 682.077 ? 106.374 1.6% > TestCRC32C.testCRC32CUpdate 65536 thrpt 12 340.002 ? 53.363 ops/ms 341.034 ? 53.581 0.3% > > > **AMD EPYC 7251** > > ORIGINAL PATCHED > Benchmark (count) Mode Cnt Score Error Units Score Error Diff > TestCRC32C.testCRC32CUpdate 64 thrpt 12 32061.964 ? 26.971 ops/ms 53863.073 ? 133.610 68.0% > TestCRC32C.testCRC32CUpdate 128 thrpt 12 17706.981 ? 19.582 ops/ms 32515.029 ? 14.303 83.6% > TestCRC32C.testCRC32CUpdate 256 thrpt 12 8455.888 ? 5.070 ops/ms 19181.871 ? 35.279 126.8% > TestCRC32C.testCRC32CUpdate 512 thrpt 12 4550.874 ? 1.293 ops/ms 10008.634 ? 17.191 119.9% > TestCRC32C.testCRC32CUpdate 1024 thrpt 12 3636.205 ? 7.306 ops/ms 5122.156 ? 3.912 40.9% > TestCRC32C.testCRC32CUpdate 2048 thrpt 12 2549.876 ? 90.854 ops/ms 2811.828 ? 5.924 10.3% > TestCRC32C.testCRC32CUpdate 4096 thrpt 12 1335.905 ? 1.813 ops/ms 1389.812 ? 2.177 4.0% > TestCRC32C.testCRC32CUpdate 8192 thrpt 12 717.871 ? 7.692 ops/ms 737.720 ? 0.357 2.8% > TestCRC32C.testCRC32CUpdate 16384 thrpt 12 361.759 ? 1.755 ops/ms 364.348 ? 0.487 0.7% > TestCRC32C.testCRC32CUpdate 32768 thrpt 12 183.699 ? 0.586 ops/ms 184.822 ? 0.178 0.6% > TestCRC32C.testCRC32CUpdate 65536 thrpt 12 92.636 ? 0.133 ops/ms 92.850 ? 0.145 0.2% Nice. Thank you for providing performance data. Please, update Copyright year in modified files. I will run testing before approval. ------------- PR: https://git.openjdk.org/jdk/pull/11838 From duke at openjdk.org Fri Jan 6 02:45:18 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 6 Jan 2023 02:45:18 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor Message-ID: This PR adds a new lint warning category `this-escape`. It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) * Some constructor `B()` of `B` invokes `A()` as its superclass constructor * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. >From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. **Patch Navigation Guide** * Non-trivial compiler changes: * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` * Javadoc additions of `@implNote`: * `src/java.base/share/classes/java/io/PipedReader.java` * `src/java.base/share/classes/java/io/PipedWriter.java` * `src/java.base/share/classes/java/lang/Throwable.java` * `src/java.base/share/classes/java/util/ArrayDeque.java` * `src/java.base/share/classes/java/util/EnumMap.java` * `src/java.base/share/classes/java/util/HashSet.java` * `src/java.base/share/classes/java/util/Hashtable.java` * `src/java.base/share/classes/java/util/LinkedList.java` * `src/java.base/share/classes/java/util/TreeMap.java` * `src/java.base/share/classes/java/util/TreeSet.java` * New unit tests * `test/langtools/tools/javac/warnings/ThisEscape/*.java` * **Everything else** is just adding `@SuppressWarnings("this-escape")` ------------- Commit messages: - Remove trailing whitespace. - Some documentation tweaks. - Treat method references like the equivalent lambda. - Fix bug where initializers could generate duplicate warnings. - Javadoc fix. - Add ThisEscape.html doc note and link the new @implNote's to it. - Add more @SuppressWarnings("this-escape") annotations. - Add more @SuppressWarnings("this-escape") annotations. - Add more @SuppressWarnings("this-escape") annotations. - Add more @SuppressWarnings("this-escape") annotations. - ... and 38 more: https://git.openjdk.org/jdk/compare/c6588d5b...9c162283 Changes: https://git.openjdk.org/jdk/pull/11874/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8015831 Stats: 4326 lines in 1285 files changed: 4259 ins; 3 del; 64 mod Patch: https://git.openjdk.org/jdk/pull/11874.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874 PR: https://git.openjdk.org/jdk/pull/11874 From dholmes at openjdk.org Fri Jan 6 04:51:00 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 6 Jan 2023 04:51:00 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 02:20:53 GMT, Archie L. Cobbs wrote: > This PR adds a new lint warning category `this-escape`. > > It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. > > A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ > * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) > * Some constructor `B()` of `B` invokes `A()` as its superclass constructor > * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly > > In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. > > Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. > > From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. > > For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. > > More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. > > Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. > > Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. > > **Patch Navigation Guide** > > * Non-trivial compiler changes: > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` > > * Javadoc additions of `@implNote`: > > * `src/java.base/share/classes/java/io/PipedReader.java` > * `src/java.base/share/classes/java/io/PipedWriter.java` > * `src/java.base/share/classes/java/lang/Throwable.java` > * `src/java.base/share/classes/java/util/ArrayDeque.java` > * `src/java.base/share/classes/java/util/EnumMap.java` > * `src/java.base/share/classes/java/util/HashSet.java` > * `src/java.base/share/classes/java/util/Hashtable.java` > * `src/java.base/share/classes/java/util/LinkedList.java` > * `src/java.base/share/classes/java/util/TreeMap.java` > * `src/java.base/share/classes/java/util/TreeSet.java` > > * New unit tests > * `test/langtools/tools/javac/warnings/ThisEscape/*.java` > > * **Everything else** is just adding `@SuppressWarnings("this-escape")` Hi Archie, The associated JBS issue has been dormant for 6+ years and this is a very intrusive change affecting many, many files. Has the resurrection of this project previously been discussed somewhere? ------------- PR: https://git.openjdk.org/jdk/pull/11874 From dholmes at openjdk.org Fri Jan 6 05:14:49 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 6 Jan 2023 05:14:49 GMT Subject: RFR: 8299274: Add elements to resolved_references consistently [v3] In-Reply-To: References: Message-ID: On Thu, 5 Jan 2023 14:58:20 GMT, Coleen Phillimore wrote: >> I added a resolved_references_at and set_resolved_references_at() functions to use for accesses to the resolved_references array, except for the CDS usages. This has an assert that the element is an oop and oob checks and setting elements use a CAS consistently. >> These asserts seem useful for finding the bug causing https://bugs.openjdk.org/browse/JDK-8296915. >> Tested with tiers1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Change the name to resolved_reference_at because there's a resolved_klass_at but I don't like this name as much as having resolved_references (plural) in the name. > @dholmes-ora are you holding out until I change the name to something I don't agree with ? No I was waiting to see if anyone else had an opinion on it. :) Thanks for making the change. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/11834 From thartmann at openjdk.org Fri Jan 6 06:48:49 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 6 Jan 2023 06:48:49 GMT Subject: RFR: 8298720: Insufficient error handling when CodeBuffer is exhausted [v4] In-Reply-To: References: Message-ID: On Thu, 5 Jan 2023 07:06:13 GMT, Tobias Hartmann wrote: >> This patch fixes various places in C1 and C2 on Aarch64 and RISC-V that miss proper error handling when the code buffer is exhausted, leading to crashes. Similar but incomplete patches went in with [JDK-8130309](https://bugs.openjdk.org/browse/JDK-8130309), [JDK-8248411](https://bugs.openjdk.org/browse/JDK-8248411) and [JDK-8272094](https://bugs.openjdk.org/browse/JDK-8272094) in the past. >> >> These issues are extremely hard to reproduce, even with the `-XX:+StressCodeBuffers` option, because code buffer expansion needs to fail at the exact moment when a specific (unhandled) instruction is emitted. Even with the stress option, we expand the code buffer such that multiple instructions will fit and in addition, chances are high that we simply bail out from compilation before emitting the problematic instruction. I attached a patch to [JDK-8298720](https://bugs.openjdk.org/browse/JDK-8298720), that makes `-XX:+StressCodeBuffers` randomized and more aggressive. With that, I can reproduce the issue reliably but it's extremely slow and therefore not well suited for integration. >> >> I now went over all usages of `CodeBuffer::expand` to make sure that we have proper error handling in place and found some remaining issues in JVMCI code. I filed [JDK-8299570](https://bugs.openjdk.org/browse/JDK-8299570) to address them. >> >> I would need help to test the RISC-V specific changes. >> >> Thanks, >> Tobias > > Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision: > > Updated copyrights Thanks, Vladimir! ------------- PR: https://git.openjdk.org/jdk/pull/11839 From dholmes at openjdk.org Fri Jan 6 06:54:49 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 6 Jan 2023 06:54:49 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v2] In-Reply-To: References: Message-ID: On Thu, 5 Jan 2023 23:42:11 GMT, Brian Burkhalter wrote: >> Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299684: Enhance message in IAE caused by NewDirectByteBuffer passing up a capacity which overflows int range I think it will look strange to update the JNI spec to say that although the function takes a jlong as the requested capacity, it will throw IAE if the capacity is larger than a jint! The mismatch between the JNI and Java code made me dig into the history here to see what JSR-51 had to say about this, but unfortunately it didn't say much. What I did find in https://bugs.openjdk.org/browse/JDK-4496703 was a very definitive comment about only supporting 32-bit (ie int) based direct buffers, but with a glimmer of hope > "A future revision of the specification is likely to address this problem". So perhaps the JNI side was prepared for this unrealized future? But even so it should have specified what happens if the jlong capacity exceeds the value of a jint I thought perhaps a special OutOfMemoryError (akin to the "Requested array size exceeds VM limit" OOME) could be thrown - and that would not require a JNI spec change - but it is a stretch. Though also note that if this requires a JNI spec change then it cannot be backported without jumping through some serious JCP Maintenance Release hoops. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From duke at openjdk.org Fri Jan 6 07:26:58 2023 From: duke at openjdk.org (Damon Fenacci) Date: Fri, 6 Jan 2023 07:26:58 GMT Subject: RFR: JDK-8295406: C1 crash with -XX:TypeProfileArgsLimit=0 -XX:TypeProfileLevel=222 Message-ID: `-XX:TypeProfileArgsLimit=0 -XX:TypeProfileLevel=222` cause an assert to fail in `LIRGenerator::profile_arguments`. `LIRGenerator::profile_arguments` actually checks if arguments need to be profiled but the `MethodData::profile_arguments` method doesn't take `TypeProfileArgsLimit=0` into account. Adding a check for _TypeProfileArgsLimit>0_ to determine if arguments have to be profiled. ------------- Commit messages: - JDK-8295406: copyright year update - JDK-8295406: added regression test - JDK-8295406: C1 crash with -XX:TypeProfileArgsLimit=0 -XX:TypeProfileLevel=222 Changes: https://git.openjdk.org/jdk/pull/11843/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11843&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8295406 Stats: 46 lines in 2 files changed: 44 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11843.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11843/head:pull/11843 PR: https://git.openjdk.org/jdk/pull/11843 From thartmann at openjdk.org Fri Jan 6 07:26:58 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 6 Jan 2023 07:26:58 GMT Subject: RFR: JDK-8295406: C1 crash with -XX:TypeProfileArgsLimit=0 -XX:TypeProfileLevel=222 In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 13:41:36 GMT, Damon Fenacci wrote: > `-XX:TypeProfileArgsLimit=0 -XX:TypeProfileLevel=222` cause an assert to fail in `LIRGenerator::profile_arguments`. > > `LIRGenerator::profile_arguments` actually checks if arguments need to be profiled but the `MethodData::profile_arguments` method doesn't take `TypeProfileArgsLimit=0` into account. > > Adding a check for _TypeProfileArgsLimit>0_ to determine if arguments have to be profiled. Looks good to me! ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.org/jdk/pull/11843 From duke at openjdk.org Fri Jan 6 07:26:58 2023 From: duke at openjdk.org (Damon Fenacci) Date: Fri, 6 Jan 2023 07:26:58 GMT Subject: RFR: JDK-8295406: C1 crash with -XX:TypeProfileArgsLimit=0 -XX:TypeProfileLevel=222 In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 13:41:36 GMT, Damon Fenacci wrote: > `-XX:TypeProfileArgsLimit=0 -XX:TypeProfileLevel=222` cause an assert to fail in `LIRGenerator::profile_arguments`. > > `LIRGenerator::profile_arguments` actually checks if arguments need to be profiled but the `MethodData::profile_arguments` method doesn't take `TypeProfileArgsLimit=0` into account. > > Adding a check for _TypeProfileArgsLimit>0_ to determine if arguments have to be profiled. @rwestrel thanks a lot for your hint! Added `TestTypeProfileArgsLimit` regression test that checks for `TypeProfileArgsLimit=0` and `TypeProfileLevel=222` plus a few other combinations of `TypeProfileArgsLimit`, `TypeProfileLevel` and `TypeProfileParmsLimit`. ------------- PR: https://git.openjdk.org/jdk/pull/11843 From duke at openjdk.org Fri Jan 6 07:26:59 2023 From: duke at openjdk.org (Damon Fenacci) Date: Fri, 6 Jan 2023 07:26:59 GMT Subject: RFR: JDK-8295406: C1 crash with -XX:TypeProfileArgsLimit=0 -XX:TypeProfileLevel=222 In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 06:33:05 GMT, Tobias Hartmann wrote: >> `-XX:TypeProfileArgsLimit=0 -XX:TypeProfileLevel=222` cause an assert to fail in `LIRGenerator::profile_arguments`. >> >> `LIRGenerator::profile_arguments` actually checks if arguments need to be profiled but the `MethodData::profile_arguments` method doesn't take `TypeProfileArgsLimit=0` into account. >> >> Adding a check for _TypeProfileArgsLimit>0_ to determine if arguments have to be profiled. > > Looks good to me! @TobiHartmann thanks a lot for reviewing it. ------------- PR: https://git.openjdk.org/jdk/pull/11843 From alanb at openjdk.org Fri Jan 6 07:53:54 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 6 Jan 2023 07:53:54 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 02:20:53 GMT, Archie L. Cobbs wrote: > This PR adds a new lint warning category `this-escape`. > > It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. > > A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ > * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) > * Some constructor `B()` of `B` invokes `A()` as its superclass constructor > * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly > > In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. > > Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. > > From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. > > For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. > > More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. > > Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. > > Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. > > **Patch Navigation Guide** > > * Non-trivial compiler changes: > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` > > * Javadoc additions of `@implNote`: > > * `src/java.base/share/classes/java/io/PipedReader.java` > * `src/java.base/share/classes/java/io/PipedWriter.java` > * `src/java.base/share/classes/java/lang/Throwable.java` > * `src/java.base/share/classes/java/util/ArrayDeque.java` > * `src/java.base/share/classes/java/util/EnumMap.java` > * `src/java.base/share/classes/java/util/HashSet.java` > * `src/java.base/share/classes/java/util/Hashtable.java` > * `src/java.base/share/classes/java/util/LinkedList.java` > * `src/java.base/share/classes/java/util/TreeMap.java` > * `src/java.base/share/classes/java/util/TreeSet.java` > > * New unit tests > * `test/langtools/tools/javac/warnings/ThisEscape/*.java` > > * **Everything else** is just adding `@SuppressWarnings("this-escape")` This looks like a very useful lint warning to have but this PR is unwieldy. If you haven't done so already then you probably should socialize on compiler-dev and get agreement on the semantics and other details. I think you will also need to separate the addition of the lint warning from the changes to the wider JDK. It might be okay to add the feature but have it disabled for the JDK build initially. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From thartmann at openjdk.org Fri Jan 6 08:30:58 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 6 Jan 2023 08:30:58 GMT Subject: Integrated: 8298720: Insufficient error handling when CodeBuffer is exhausted In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 06:31:16 GMT, Tobias Hartmann wrote: > This patch fixes various places in C1 and C2 on Aarch64 and RISC-V that miss proper error handling when the code buffer is exhausted, leading to crashes. Similar but incomplete patches went in with [JDK-8130309](https://bugs.openjdk.org/browse/JDK-8130309), [JDK-8248411](https://bugs.openjdk.org/browse/JDK-8248411) and [JDK-8272094](https://bugs.openjdk.org/browse/JDK-8272094) in the past. > > These issues are extremely hard to reproduce, even with the `-XX:+StressCodeBuffers` option, because code buffer expansion needs to fail at the exact moment when a specific (unhandled) instruction is emitted. Even with the stress option, we expand the code buffer such that multiple instructions will fit and in addition, chances are high that we simply bail out from compilation before emitting the problematic instruction. I attached a patch to [JDK-8298720](https://bugs.openjdk.org/browse/JDK-8298720), that makes `-XX:+StressCodeBuffers` randomized and more aggressive. With that, I can reproduce the issue reliably but it's extremely slow and therefore not well suited for integration. > > I now went over all usages of `CodeBuffer::expand` to make sure that we have proper error handling in place and found some remaining issues in JVMCI code. I filed [JDK-8299570](https://bugs.openjdk.org/browse/JDK-8299570) to address them. > > I would need help to test the RISC-V specific changes. > > Thanks, > Tobias This pull request has now been integrated. Changeset: cc4936a7 Author: Tobias Hartmann URL: https://git.openjdk.org/jdk/commit/cc4936a79e1c1723542d575a2596edd29248817e Stats: 90 lines in 8 files changed: 66 ins; 5 del; 19 mod 8298720: Insufficient error handling when CodeBuffer is exhausted Reviewed-by: kvn, fyang ------------- PR: https://git.openjdk.org/jdk/pull/11839 From qpzhang at openjdk.org Fri Jan 6 08:39:27 2023 From: qpzhang at openjdk.org (Patrick Zhang) Date: Fri, 6 Jan 2023 08:39:27 GMT Subject: RFR: 8298427: Detect Ampere-1 and Ampere-1A CPUs and set default options Message-ID: This patch is to add CPU detection for Ampere-1 and Ampere-1A and set -XX:+UseSIMDForMemoryOps by default. In addition, an `enum Ampere_CPU_Model ` got introduced in order to clearly describe all Ampere CPUs in `src/hotspot/cpu/aarch64/vm_version_aarch64.hpp`. Tests done: 1. Jtreg tier1 sanity check on Ampere Altra AArch64 platforms, and Ampere-1 systems as well. No new issue found. 4. GitHub Actions (GHA) sanity tests: https://github.com/cnqpzhang/jdk/actions/runs/3845722221 3. OpenJDK bundled JMH, `make run-test TEST="micro:java.lang.ArrayCopy*" `, SIMD vs NoSIMD ratios are mostly positive. For example, `java.lang.ArrayCopyAligned.testChar` with `-p length=600` showed +42% improvement on Ampere-1. 2. Ran [JMH JDK Microbenchmarks](https://github.com/openjdk/jmh-jdk-microbenchmarks), ~1500 cases. No obvious perf regression found. Signed-off-by: Patrick Zhang ------------- Commit messages: - 8298427: Detect Ampere-1 and Ampere-1A CPUs and set default options Changes: https://git.openjdk.org/jdk/pull/11878/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11878&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298427 Stats: 18 lines in 2 files changed: 15 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11878.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11878/head:pull/11878 PR: https://git.openjdk.org/jdk/pull/11878 From alanb at openjdk.org Fri Jan 6 09:06:49 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 6 Jan 2023 09:06:49 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v2] In-Reply-To: References: Message-ID: On Thu, 5 Jan 2023 23:42:11 GMT, Brian Burkhalter wrote: >> Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299684: Enhance message in IAE caused by NewDirectByteBuffer passing up a capacity which overflows int range I checked ancient history and the issue goes back to JDK 1.4 (when JSR-51 defined this API). It's surprising that it hasn't been reported/noticed before now. Yes, this will need an update to the JNI spec to say that it throws if capacity is negative or greater than Integer.MAX_VALUE. It will look a bit strange in the spec when the parameter is jlong but we can't change it. As regards what to throw then the current proposal to throw IAE seems okay as the function already throws it for negative values that are >= Integer.MIN_VALUE, e.g. Exception in thread "main" java.lang.IllegalArgumentException: capacity < 0: (-1 < 0) at java.base/java.nio.Buffer.createCapacityException(Buffer.java:282) at java.base/java.nio.Buffer.(Buffer.java:245) at java.base/java.nio.ByteBuffer.(ByteBuffer.java:298) at java.base/java.nio.ByteBuffer.(ByteBuffer.java:306) at java.base/java.nio.MappedByteBuffer.(MappedByteBuffer.java:113) at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:177) at Test.newDirectByteBuffer(Native Method) at Test.main(Test.java:7) The compatibility impact of the change should be minimal, at least I can't imagine anyone depending on the current broken behavior. For the change, clampCapacity only needs to be called once, not twice. The exception message is a bit strange. If cap is < Integer.MIN_VALUE then it would be better to have it consistent with the existing message above. Also "in upcall from JNI NewDirectByteBuffer" should be better if it didn't include "in upcall". We will need to add a test for this and decide whether to place it. It seems there aren't any tests for these JNI functions in hotspot//jtreg/runtime/jni, maybe we start a new locations for tests in test/jdk/java/nio/jni. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From aph at openjdk.org Fri Jan 6 09:27:49 2023 From: aph at openjdk.org (Andrew Haley) Date: Fri, 6 Jan 2023 09:27:49 GMT Subject: RFR: 8298427: Detect Ampere-1 and Ampere-1A CPUs and set default options In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 08:27:28 GMT, Patrick Zhang wrote: > This patch is to add CPU detection for Ampere-1 and Ampere-1A and set -XX:+UseSIMDForMemoryOps by default. In addition, an `enum Ampere_CPU_Model ` got introduced in order to clearly describe all Ampere CPUs in `src/hotspot/cpu/aarch64/vm_version_aarch64.hpp`. > > Tests done: > 1. Jtreg tier1 sanity check on Ampere Altra AArch64 platforms, and Ampere-1 systems as well. No new issue found. > 4. GitHub Actions (GHA) sanity tests: https://github.com/cnqpzhang/jdk/actions/runs/3845722221 > 3. OpenJDK bundled JMH, `make run-test TEST="micro:java.lang.ArrayCopy*" `, SIMD vs NoSIMD ratios are mostly positive. For example, `java.lang.ArrayCopyAligned.testChar` with `-p length=600` showed +42% improvement on Ampere-1. > 2. Ran [JMH JDK Microbenchmarks](https://github.com/openjdk/jmh-jdk-microbenchmarks), ~1500 cases. No obvious perf regression found. > > Signed-off-by: Patrick Zhang Please update the title to 8298427: AArch64: Detect Ampere-1 and Ampere-1A CPUs and set default options Reason: AArch64 reviewers look for AArch64-related bugs. They'll see your PR sooner. ------------- Marked as reviewed by aph (Reviewer). PR: https://git.openjdk.org/jdk/pull/11878 From qpzhang at openjdk.org Fri Jan 6 09:39:19 2023 From: qpzhang at openjdk.org (Patrick Zhang) Date: Fri, 6 Jan 2023 09:39:19 GMT Subject: RFR: 8298472: AArch64: Detect Ampere-1 and Ampere-1A CPUs and set default options [v2] In-Reply-To: References: Message-ID: > This patch is to add CPU detection for Ampere-1 and Ampere-1A and set -XX:+UseSIMDForMemoryOps by default. In addition, an `enum Ampere_CPU_Model ` got introduced in order to clearly describe all Ampere CPUs in `src/hotspot/cpu/aarch64/vm_version_aarch64.hpp`. > > Tests done: > 1. Jtreg tier1 sanity check on Ampere Altra AArch64 platforms, and Ampere-1 systems as well. No new issue found. > 4. GitHub Actions (GHA) sanity tests: https://github.com/cnqpzhang/jdk/actions/runs/3845722221 > 3. OpenJDK bundled JMH, `make run-test TEST="micro:java.lang.ArrayCopy*" `, SIMD vs NoSIMD ratios are mostly positive. For example, `java.lang.ArrayCopyAligned.testChar` with `-p length=600` showed +42% improvement on Ampere-1. > 2. Ran [JMH JDK Microbenchmarks](https://github.com/openjdk/jmh-jdk-microbenchmarks), ~1500 cases. No obvious perf regression found. > > Signed-off-by: Patrick Zhang Patrick Zhang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8298472: Detect Ampere-1 and Ampere-1A CPUs and set default options Signed-off-by: Patrick Zhang ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11878/files - new: https://git.openjdk.org/jdk/pull/11878/files/eb584df1..829f4979 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11878&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11878&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11878.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11878/head:pull/11878 PR: https://git.openjdk.org/jdk/pull/11878 From qpzhang at openjdk.org Fri Jan 6 09:42:48 2023 From: qpzhang at openjdk.org (Patrick Zhang) Date: Fri, 6 Jan 2023 09:42:48 GMT Subject: RFR: 8298472: AArch64: Detect Ampere-1 and Ampere-1A CPUs and set default options [v2] In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 09:24:55 GMT, Andrew Haley wrote: > Please update the title to > > 8298427: AArch64: Detect Ampere-1 and Ampere-1A CPUs and set default options > > Reason: AArch64 reviewers look for AArch64-related bugs. They'll see your PR sooner. Thank you @theRealAph, I updated the title to `8298472: AArch64: Detect Ampere-1 and Ampere-1A CPUs and set default` Previous 8298427 was a wrong link (my fault), [JDK-8298472](https://bugs.openjdk.org/browse/JDK-8298472) is the right one. ------------- PR: https://git.openjdk.org/jdk/pull/11878 From ngasson at openjdk.org Fri Jan 6 10:11:51 2023 From: ngasson at openjdk.org (Nick Gasson) Date: Fri, 6 Jan 2023 10:11:51 GMT Subject: RFR: 8298472: AArch64: Detect Ampere-1 and Ampere-1A CPUs and set default options [v2] In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 09:39:19 GMT, Patrick Zhang wrote: >> This patch is to add CPU detection for Ampere-1 and Ampere-1A and set -XX:+UseSIMDForMemoryOps by default. In addition, an `enum Ampere_CPU_Model ` got introduced in order to clearly describe all Ampere CPUs in `src/hotspot/cpu/aarch64/vm_version_aarch64.hpp`. >> >> Tests done: >> 1. Jtreg tier1 sanity check on Ampere Altra AArch64 platforms, and Ampere-1 systems as well. No new issue found. >> 4. GitHub Actions (GHA) sanity tests: https://github.com/cnqpzhang/jdk/actions/runs/3845722221 >> 3. OpenJDK bundled JMH, `make run-test TEST="micro:java.lang.ArrayCopy*" `, SIMD vs NoSIMD ratios are mostly positive. For example, `java.lang.ArrayCopyAligned.testChar` with `-p length=600` showed +42% improvement on Ampere-1. >> 2. Ran [JMH JDK Microbenchmarks](https://github.com/openjdk/jmh-jdk-microbenchmarks), ~1500 cases. No obvious perf regression found. >> >> Signed-off-by: Patrick Zhang > > Patrick Zhang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 8298472: Detect Ampere-1 and Ampere-1A CPUs and set default options > > Signed-off-by: Patrick Zhang Marked as reviewed by ngasson (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11878 From shade at openjdk.org Fri Jan 6 11:31:57 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 6 Jan 2023 11:31:57 GMT Subject: Integrated: 8294403: [REDO] make test should report only on executed tests In-Reply-To: References: Message-ID: <6JKgG4vzz9qYTvO9IuyiD3Zav0nQxyGZTq1hua9NYLg=.86c99571-21b4-4e32-bacf-0c83cee96495@github.com> On Tue, 3 Jan 2023 09:39:59 GMT, Aleksey Shipilev wrote: > This should help to speed up tests significantly. Currently, if we run "make test" with a subset of tests, JTReg would still read the entirety of test root to report on tests that were not run. Even with current suite of tests it gets expensive. If you add more tests to suite -- for example, mounting a large test archive like pre-generated fuzzer tests -- it starts to take a lot of time. > > The reasonable default for older jtreg is `-report:executed`. My own CI -- that has millions of tests mounted in `test/` -- was running with `JTREG="OPTIONS=-report:executed"` for years now. [CODETOOLS-7903323](https://bugs.openjdk.org/browse/CODETOOLS-7903323) provides a new reporting option, `-report:files`, which makes this whole business easier. This requires new jtreg. > > Motivational improvements: > > > $ time CONF=linux-x86_64-server-release make run-test TEST=gc/epsilon/TestHelloWorld.java > > # Default JDK tree > > # Baseline > real 0m9.086s > user 0m22.857s > sys 0m4.202s > > # Patched > real 0m6.406s ; +40% faster > user 0m17.156s > sys 0m3.193s > > # +100K fuzzer tests in tree > > # Baseline > real 3m1.997s > user 3m16.643s > sys 0m10.490s > > # Patched > real 0m8.919s ; 20x faster > user 0m17.904s > sys 0m4.860s > > > Additional testing: > - [x] Ad-hoc timing tests (see above) > - [x] Reproducer from [CODETOOLS-7903331](https://bugs.openjdk.org/browse/CODETOOLS-7903331) > - [x] Eyeballing the test results on passing tests with REPEAT_COUNT > 1 > - [x] Eyeballing the test results on intermittently failing tests with RETRY_COUNT > 1 This pull request has now been integrated. Changeset: 5598acc3 Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/5598acc345dbd6f806145157ae6f7c591340a1d1 Stats: 13 lines in 3 files changed: 11 ins; 0 del; 2 mod 8294403: [REDO] make test should report only on executed tests Reviewed-by: erikj, dholmes, jpai, djelinski ------------- PR: https://git.openjdk.org/jdk/pull/11824 From apangin at openjdk.org Fri Jan 6 12:07:25 2023 From: apangin at openjdk.org (Andrei Pangin) Date: Fri, 6 Jan 2023 12:07:25 GMT Subject: RFR: 8299544: Improve performance of CRC32C intrinsics (non-AVX-512) for small inputs [v2] In-Reply-To: References: Message-ID: > When comparing performance of JDK built-in CRC32C intrinsics with the native implementation, we noticed that JDK performs notably worse on smaller array sizes (up to 1024 bytes). > > The main reason is that the algorithm based on the ["Fast CRC Computation for iSCSI Polynomial Using CRC32 Instruction"](https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/crc-iscsi-polynomial-crc32-instruction-paper.pdf) paper, processes input buffer in [chunks](https://github.com/openjdk/jdk/blob/92dfc735f2297441a99b3e39464fb8f77a354d55/src/hotspot/cpu/x86/crc32c.h#L29-L50) of 6144, 2064, and 648 bytes, and the rest of the buffer is processed sequentially with [4-byte variant](https://github.com/openjdk/jdk/blob/92dfc735f2297441a99b3e39464fb8f77a354d55/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L8231-L8236) of CRC32 instruction. > > Experiments show that CRC32C computation performance can be improved for smaller inputs without performance impact for larger inputs, if the smallest chunk size is reduced from 648 to 216 bytes. Actually, the original paper suggests the algorithms CRC_216 / CRC_240 for processing blocks of 216 and 240 bytes respectively. The value 648 might have resulted from an "x3" mistake (the algorithm accumulates 3 checksums per iteration). > > Additionally, when processing the tail (less than 216 bytes), we can use 8-byte variant of CRC32 instruction instead of 4-byte variant to speed up the algorithm even further. > > ### Changes in this PR > > 1. CRC32C_LOW is decreased from 8 * 27 to 8 * 9 (which corresponds to 216 bytes). > 2. CRC32C_MIDDLE is decreased from 8 * 86 to 8 * 74 to compensate for performance drop for mid-size arrays. The value 74 has been chosen empirically. According to experiments, values from 70 to 75 yield the best results, while with higher or lower values, there is a degradation for certain array sizes. > 3. On x86_64, `CRC32 r32, [m32]` instruction is replaced with `CRC32 r64, [m64]` in the tail loop. > 4. Unconditional JMP is replaced with a conditional jump at the end of the loop. > 5. The hot tail loop is aligned. > > ### Notes > > - The changes are only for x86 architecture. > - If the hardware supports AVX-512 extensions + VPCLMULQDQ instruction (introduced with Ice Lake), another version of CRC32C intrinsics is generated, and the changes do not have effect. > > ### Performance > > JMH benchmark used to assess performance: https://cr.openjdk.java.net/~apangin/8299544/CrcBench.java > > Tested hardware: > - Intel Xeon Platinum 8259CL > - Intel Xeon Platinum 8124M > - Intel Core i7-1280P > - AMD EPYC 7251 > > Raw JMH results: > https://cr.openjdk.java.net/~apangin/8299544/jmh/ > > Performance curve: > crc32c-perf-curve > > Improvement summary as a table: > crc32c-perf-table > > and as a graph: > crc32c-perf-graph > > I also checked [TestCRC32C.java](https://github.com/openjdk/jdk/blob/872384707e89d03ede655aad16f360dc94f10152/test/micro/org/openjdk/bench/java/util/TestCRC32C.java) microbenchmark included in the JDK source code. It also shows similar improvement: > > **Intel Xeon Platinum 8259CL** > > ORIGINAL PATCHED > Benchmark (count) Mode Cnt Score Error Units Score Error Diff > TestCRC32C.testCRC32CUpdate 64 thrpt 12 61526.044 ? 14.426 ops/ms 116187.797 ? 37.719 88.8% > TestCRC32C.testCRC32CUpdate 128 thrpt 12 30043.410 ? 275.597 ops/ms 61527.139 ? 11.407 104.8% > TestCRC32C.testCRC32CUpdate 256 thrpt 12 16086.548 ? 1.386 ops/ms 49801.463 ? 4.034 209.6% > TestCRC32C.testCRC32CUpdate 512 thrpt 12 8107.780 ? 0.837 ops/ms 25506.806 ? 5.119 214.6% > TestCRC32C.testCRC32CUpdate 1024 thrpt 12 8171.332 ? 0.684 ops/ms 12913.665 ? 1.425 58.0% > TestCRC32C.testCRC32CUpdate 2048 thrpt 12 8300.331 ? 1.848 ops/ms 10155.094 ? 1.551 22.3% > TestCRC32C.testCRC32CUpdate 4096 thrpt 12 4886.483 ? 2.027 ops/ms 5101.460 ? 1.001 4.4% > TestCRC32C.testCRC32CUpdate 8192 thrpt 12 2690.988 ? 0.315 ops/ms 2859.960 ? 0.807 6.3% > TestCRC32C.testCRC32CUpdate 16384 thrpt 12 1414.695 ? 0.477 ops/ms 1432.189 ? 0.162 1.2% > TestCRC32C.testCRC32CUpdate 32768 thrpt 12 671.593 ? 103.208 ops/ms 682.077 ? 106.374 1.6% > TestCRC32C.testCRC32CUpdate 65536 thrpt 12 340.002 ? 53.363 ops/ms 341.034 ? 53.581 0.3% > > > **AMD EPYC 7251** > > ORIGINAL PATCHED > Benchmark (count) Mode Cnt Score Error Units Score Error Diff > TestCRC32C.testCRC32CUpdate 64 thrpt 12 32061.964 ? 26.971 ops/ms 53863.073 ? 133.610 68.0% > TestCRC32C.testCRC32CUpdate 128 thrpt 12 17706.981 ? 19.582 ops/ms 32515.029 ? 14.303 83.6% > TestCRC32C.testCRC32CUpdate 256 thrpt 12 8455.888 ? 5.070 ops/ms 19181.871 ? 35.279 126.8% > TestCRC32C.testCRC32CUpdate 512 thrpt 12 4550.874 ? 1.293 ops/ms 10008.634 ? 17.191 119.9% > TestCRC32C.testCRC32CUpdate 1024 thrpt 12 3636.205 ? 7.306 ops/ms 5122.156 ? 3.912 40.9% > TestCRC32C.testCRC32CUpdate 2048 thrpt 12 2549.876 ? 90.854 ops/ms 2811.828 ? 5.924 10.3% > TestCRC32C.testCRC32CUpdate 4096 thrpt 12 1335.905 ? 1.813 ops/ms 1389.812 ? 2.177 4.0% > TestCRC32C.testCRC32CUpdate 8192 thrpt 12 717.871 ? 7.692 ops/ms 737.720 ? 0.357 2.8% > TestCRC32C.testCRC32CUpdate 16384 thrpt 12 361.759 ? 1.755 ops/ms 364.348 ? 0.487 0.7% > TestCRC32C.testCRC32CUpdate 32768 thrpt 12 183.699 ? 0.586 ops/ms 184.822 ? 0.178 0.6% > TestCRC32C.testCRC32CUpdate 65536 thrpt 12 92.636 ? 0.133 ops/ms 92.850 ? 0.145 0.2% Andrei Pangin has updated the pull request incrementally with one additional commit since the last revision: Updated copyright years ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11838/files - new: https://git.openjdk.org/jdk/pull/11838/files/9cdca84f..632db572 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11838&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11838&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11838.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11838/head:pull/11838 PR: https://git.openjdk.org/jdk/pull/11838 From apangin at openjdk.org Fri Jan 6 12:07:25 2023 From: apangin at openjdk.org (Andrei Pangin) Date: Fri, 6 Jan 2023 12:07:25 GMT Subject: RFR: 8299544: Improve performance of CRC32C intrinsics (non-AVX-512) for small inputs In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 02:36:25 GMT, Andrei Pangin wrote: > When comparing performance of JDK built-in CRC32C intrinsics with the native implementation, we noticed that JDK performs notably worse on smaller array sizes (up to 1024 bytes). > > The main reason is that the algorithm based on the ["Fast CRC Computation for iSCSI Polynomial Using CRC32 Instruction"](https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/crc-iscsi-polynomial-crc32-instruction-paper.pdf) paper, processes input buffer in [chunks](https://github.com/openjdk/jdk/blob/92dfc735f2297441a99b3e39464fb8f77a354d55/src/hotspot/cpu/x86/crc32c.h#L29-L50) of 6144, 2064, and 648 bytes, and the rest of the buffer is processed sequentially with [4-byte variant](https://github.com/openjdk/jdk/blob/92dfc735f2297441a99b3e39464fb8f77a354d55/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L8231-L8236) of CRC32 instruction. > > Experiments show that CRC32C computation performance can be improved for smaller inputs without performance impact for larger inputs, if the smallest chunk size is reduced from 648 to 216 bytes. Actually, the original paper suggests the algorithms CRC_216 / CRC_240 for processing blocks of 216 and 240 bytes respectively. The value 648 might have resulted from an "x3" mistake (the algorithm accumulates 3 checksums per iteration). > > Additionally, when processing the tail (less than 216 bytes), we can use 8-byte variant of CRC32 instruction instead of 4-byte variant to speed up the algorithm even further. > > ### Changes in this PR > > 1. CRC32C_LOW is decreased from 8 * 27 to 8 * 9 (which corresponds to 216 bytes). > 2. CRC32C_MIDDLE is decreased from 8 * 86 to 8 * 74 to compensate for performance drop for mid-size arrays. The value 74 has been chosen empirically. According to experiments, values from 70 to 75 yield the best results, while with higher or lower values, there is a degradation for certain array sizes. > 3. On x86_64, `CRC32 r32, [m32]` instruction is replaced with `CRC32 r64, [m64]` in the tail loop. > 4. Unconditional JMP is replaced with a conditional jump at the end of the loop. > 5. The hot tail loop is aligned. > > ### Notes > > - The changes are only for x86 architecture. > - If the hardware supports AVX-512 extensions + VPCLMULQDQ instruction (introduced with Ice Lake), another version of CRC32C intrinsics is generated, and the changes do not have effect. > > ### Performance > > JMH benchmark used to assess performance: https://cr.openjdk.java.net/~apangin/8299544/CrcBench.java > > Tested hardware: > - Intel Xeon Platinum 8259CL > - Intel Xeon Platinum 8124M > - Intel Core i7-1280P > - AMD EPYC 7251 > > Raw JMH results: > https://cr.openjdk.java.net/~apangin/8299544/jmh/ > > Performance curve: > crc32c-perf-curve > > Improvement summary as a table: > crc32c-perf-table > > and as a graph: > crc32c-perf-graph > > I also checked [TestCRC32C.java](https://github.com/openjdk/jdk/blob/872384707e89d03ede655aad16f360dc94f10152/test/micro/org/openjdk/bench/java/util/TestCRC32C.java) microbenchmark included in the JDK source code. It also shows similar improvement: > > **Intel Xeon Platinum 8259CL** > > ORIGINAL PATCHED > Benchmark (count) Mode Cnt Score Error Units Score Error Diff > TestCRC32C.testCRC32CUpdate 64 thrpt 12 61526.044 ? 14.426 ops/ms 116187.797 ? 37.719 88.8% > TestCRC32C.testCRC32CUpdate 128 thrpt 12 30043.410 ? 275.597 ops/ms 61527.139 ? 11.407 104.8% > TestCRC32C.testCRC32CUpdate 256 thrpt 12 16086.548 ? 1.386 ops/ms 49801.463 ? 4.034 209.6% > TestCRC32C.testCRC32CUpdate 512 thrpt 12 8107.780 ? 0.837 ops/ms 25506.806 ? 5.119 214.6% > TestCRC32C.testCRC32CUpdate 1024 thrpt 12 8171.332 ? 0.684 ops/ms 12913.665 ? 1.425 58.0% > TestCRC32C.testCRC32CUpdate 2048 thrpt 12 8300.331 ? 1.848 ops/ms 10155.094 ? 1.551 22.3% > TestCRC32C.testCRC32CUpdate 4096 thrpt 12 4886.483 ? 2.027 ops/ms 5101.460 ? 1.001 4.4% > TestCRC32C.testCRC32CUpdate 8192 thrpt 12 2690.988 ? 0.315 ops/ms 2859.960 ? 0.807 6.3% > TestCRC32C.testCRC32CUpdate 16384 thrpt 12 1414.695 ? 0.477 ops/ms 1432.189 ? 0.162 1.2% > TestCRC32C.testCRC32CUpdate 32768 thrpt 12 671.593 ? 103.208 ops/ms 682.077 ? 106.374 1.6% > TestCRC32C.testCRC32CUpdate 65536 thrpt 12 340.002 ? 53.363 ops/ms 341.034 ? 53.581 0.3% > > > **AMD EPYC 7251** > > ORIGINAL PATCHED > Benchmark (count) Mode Cnt Score Error Units Score Error Diff > TestCRC32C.testCRC32CUpdate 64 thrpt 12 32061.964 ? 26.971 ops/ms 53863.073 ? 133.610 68.0% > TestCRC32C.testCRC32CUpdate 128 thrpt 12 17706.981 ? 19.582 ops/ms 32515.029 ? 14.303 83.6% > TestCRC32C.testCRC32CUpdate 256 thrpt 12 8455.888 ? 5.070 ops/ms 19181.871 ? 35.279 126.8% > TestCRC32C.testCRC32CUpdate 512 thrpt 12 4550.874 ? 1.293 ops/ms 10008.634 ? 17.191 119.9% > TestCRC32C.testCRC32CUpdate 1024 thrpt 12 3636.205 ? 7.306 ops/ms 5122.156 ? 3.912 40.9% > TestCRC32C.testCRC32CUpdate 2048 thrpt 12 2549.876 ? 90.854 ops/ms 2811.828 ? 5.924 10.3% > TestCRC32C.testCRC32CUpdate 4096 thrpt 12 1335.905 ? 1.813 ops/ms 1389.812 ? 2.177 4.0% > TestCRC32C.testCRC32CUpdate 8192 thrpt 12 717.871 ? 7.692 ops/ms 737.720 ? 0.357 2.8% > TestCRC32C.testCRC32CUpdate 16384 thrpt 12 361.759 ? 1.755 ops/ms 364.348 ? 0.487 0.7% > TestCRC32C.testCRC32CUpdate 32768 thrpt 12 183.699 ? 0.586 ops/ms 184.822 ? 0.178 0.6% > TestCRC32C.testCRC32CUpdate 65536 thrpt 12 92.636 ? 0.133 ops/ms 92.850 ? 0.145 0.2% Thanks. I updated copyright years. ------------- PR: https://git.openjdk.org/jdk/pull/11838 From coleenp at openjdk.org Fri Jan 6 13:57:49 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 6 Jan 2023 13:57:49 GMT Subject: RFR: 8299274: Add elements to resolved_references consistently [v3] In-Reply-To: References: Message-ID: On Thu, 5 Jan 2023 14:58:20 GMT, Coleen Phillimore wrote: >> I added a resolved_references_at and set_resolved_references_at() functions to use for accesses to the resolved_references array, except for the CDS usages. This has an assert that the element is an oop and oob checks and setting elements use a CAS consistently. >> These asserts seem useful for finding the bug causing https://bugs.openjdk.org/browse/JDK-8296915. >> Tested with tiers1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Change the name to resolved_reference_at because there's a resolved_klass_at but I don't like this name as much as having resolved_references (plural) in the name. Thanks for reviewing, Ioi, Fred, Robbin and David. ------------- PR: https://git.openjdk.org/jdk/pull/11834 From coleenp at openjdk.org Fri Jan 6 13:58:51 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 6 Jan 2023 13:58:51 GMT Subject: RFR: 8299275: Add some ClassLoaderData verification code [v2] In-Reply-To: References: <1Adx9iDHr_fSF8l2AXfNF9Rzq5NpPwhqiJ2AxnorYRQ=.88805086-76f3-4839-80de-ad059f7304f7@github.com> Message-ID: On Thu, 5 Jan 2023 17:09:56 GMT, Ioi Lam wrote: >> Yes, I did add the deallocate_list verification too. I can change the title of the bug. > > This code seem unsafe since you are checking for `is_klass()` but cast to `InstanceKlass*`. Since `verify()` is in `Klass` anyway, it's better to say > > > if (m->is_klass()) { > ((Klass*)m)->verify(); fixed. ------------- PR: https://git.openjdk.org/jdk/pull/11856 From coleenp at openjdk.org Fri Jan 6 14:00:57 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 6 Jan 2023 14:00:57 GMT Subject: Integrated: 8299274: Add elements to resolved_references consistently In-Reply-To: References: Message-ID: On Tue, 3 Jan 2023 18:35:20 GMT, Coleen Phillimore wrote: > I added a resolved_references_at and set_resolved_references_at() functions to use for accesses to the resolved_references array, except for the CDS usages. This has an assert that the element is an oop and oob checks and setting elements use a CAS consistently. > These asserts seem useful for finding the bug causing https://bugs.openjdk.org/browse/JDK-8296915. > Tested with tiers1-4. This pull request has now been integrated. Changeset: 1e997292 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/1e9972922a3d8232cf111a391584638b272a3a17 Stats: 57 lines in 11 files changed: 20 ins; 5 del; 32 mod 8299274: Add elements to resolved_references consistently Reviewed-by: iklam, dholmes, rehn, fparain ------------- PR: https://git.openjdk.org/jdk/pull/11834 From coleenp at openjdk.org Fri Jan 6 14:15:56 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 6 Jan 2023 14:15:56 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7] In-Reply-To: References: Message-ID: On Thu, 15 Dec 2022 01:57:27 GMT, David Holmes wrote: >> I agree that this is ambigious. The `jvmtiTagMap` calls `add/update` methods of `jvmtiTagMapTable` which in turn calls `resourceHashTable` methods `put` and `put_if_absent`. >> `put` and `put_if_absent` can be used for both adding and updating and reporting it in returned values. >> `jvmtiTagMap` calls to `jvmtiTagMapTable` add/update DO NOT CARE about the returned values. For these calls, it doesn't mater if an add (update) method resulted in an update (add). >> So which one of the following cases would be correct? >> - Based on the `jvmtiTagMap` calls, let the add/update be void and ignore the differences of what really happens in the table. Or >> - Based on the `resourceHashTable` bool-valued `put` and `put_if_absent` methods, let the add/update be bool-values and leave the decision on "what really happened in the table" to the callers in `jvmtiTagMap`. (current implementation) > > The issue is not the underlying RHT methods but the semantics of the `jvmtiTagMap` methods. If a call to add always expects to add then it should be a fatal error if it actually did an update as that indicates something is broken. Similarly if an update actually does an add. The JvmtiTagMap code adds/updates and removes the entries like below in two places which could probably be simplified, but I think that's outside the scope of this RFE. I suggest removing the bool return from add, remove and update, and add the assert(true) in the remove case. There's already an assert that add/update happened in the other cases. ``` // if the object is not already tagged then we tag it if (found_tag == 0) { if (tag != 0) { hashmap->add(o, tag); } else { // no-op } } else { // if the object is already tagged then we either update // the tag (if a new tag value has been provided) // or remove the object if the new tag value is 0. if (tag == 0) { hashmap->remove(o); } else { hashmap->update(o, tag); } } ------------- PR: https://git.openjdk.org/jdk/pull/11288 From duke at openjdk.org Fri Jan 6 14:51:54 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 6 Jan 2023 14:51:54 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 04:48:27 GMT, David Holmes wrote: > The associated JBS issue has been dormant for 6+ years and this is a very intrusive change affecting many, many files. Has the resurrection of this project previously been discussed somewhere? Hi @dholmes-ora, The work to add this warning has been guided by @briangoetz in discussions on the amber-dev mailing list. See that thread for how we came up with the current design, underlying motivation, etc. Regarding intrusiveness (assuming you're referring simply to the number of files touched), as mentioned this was one of two options. The other option would be to patch to about ~30 `Java.gmk` files in `make/modules` to exclude `this-escape` from `-Xlint` during the various module builds. Going this route is fine with me, but it has the downside that any new code being developed would not benefit from the new warning. This was in fact my original approach (and it was a lot easier :) but Brian rightly pointed out that adding `@SuppressWarnings` annotations was the the safer (i.e, more conservative) approach. > If you haven't done so already then you probably should socialize on compiler-dev and get agreement on the semantics and other details. Hi @AlanBateman, As mentioned this has been under discussion on amber-dev for a while. Happy to continue that discussion here as well. > I think you will also need to separate the addition of the lint warning from the changes to the wider JDK. It might be okay to add the feature but have it disabled for the JDK build initially. Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct? If this is generally agreed as a better route then let me know and I'll update the patch. Thanks for both of your comments. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From apangin at openjdk.org Fri Jan 6 15:15:51 2023 From: apangin at openjdk.org (Andrei Pangin) Date: Fri, 6 Jan 2023 15:15:51 GMT Subject: RFR: 8299544: Improve performance of CRC32C intrinsics (non-AVX-512) for small inputs [v3] In-Reply-To: References: Message-ID: > When comparing performance of JDK built-in CRC32C intrinsics with the native implementation, we noticed that JDK performs notably worse on smaller array sizes (up to 1024 bytes). > > The main reason is that the algorithm based on the ["Fast CRC Computation for iSCSI Polynomial Using CRC32 Instruction"](https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/crc-iscsi-polynomial-crc32-instruction-paper.pdf) paper, processes input buffer in [chunks](https://github.com/openjdk/jdk/blob/92dfc735f2297441a99b3e39464fb8f77a354d55/src/hotspot/cpu/x86/crc32c.h#L29-L50) of 6144, 2064, and 648 bytes, and the rest of the buffer is processed sequentially with [4-byte variant](https://github.com/openjdk/jdk/blob/92dfc735f2297441a99b3e39464fb8f77a354d55/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L8231-L8236) of CRC32 instruction. > > Experiments show that CRC32C computation performance can be improved for smaller inputs without performance impact for larger inputs, if the smallest chunk size is reduced from 648 to 216 bytes. Actually, the original paper suggests the algorithms CRC_216 / CRC_240 for processing blocks of 216 and 240 bytes respectively. The value 648 might have resulted from an "x3" mistake (the algorithm accumulates 3 checksums per iteration). > > Additionally, when processing the tail (less than 216 bytes), we can use 8-byte variant of CRC32 instruction instead of 4-byte variant to speed up the algorithm even further. > > ### Changes in this PR > > 1. CRC32C_LOW is decreased from 8 * 27 to 8 * 9 (which corresponds to 216 bytes). > 2. CRC32C_MIDDLE is decreased from 8 * 86 to 8 * 74 to compensate for performance drop for mid-size arrays. The value 74 has been chosen empirically. According to experiments, values from 70 to 75 yield the best results, while with higher or lower values, there is a degradation for certain array sizes. > 3. On x86_64, `CRC32 r32, [m32]` instruction is replaced with `CRC32 r64, [m64]` in the tail loop. > 4. Unconditional JMP is replaced with a conditional jump at the end of the loop. > 5. The hot tail loop is aligned. > > ### Notes > > - The changes are only for x86 architecture. > - If the hardware supports AVX-512 extensions + VPCLMULQDQ instruction (introduced with Ice Lake), another version of CRC32C intrinsics is generated, and the changes do not have effect. > > ### Performance > > JMH benchmark used to assess performance: https://cr.openjdk.java.net/~apangin/8299544/CrcBench.java > > Tested hardware: > - Intel Xeon Platinum 8259CL > - Intel Xeon Platinum 8124M > - Intel Core i7-1280P > - AMD EPYC 7251 > > Raw JMH results: > https://cr.openjdk.java.net/~apangin/8299544/jmh/ > > Performance curve: > crc32c-perf-curve > > Improvement summary as a table: > crc32c-perf-table > > and as a graph: > crc32c-perf-graph > > I also checked [TestCRC32C.java](https://github.com/openjdk/jdk/blob/872384707e89d03ede655aad16f360dc94f10152/test/micro/org/openjdk/bench/java/util/TestCRC32C.java) microbenchmark included in the JDK source code. It also shows similar improvement: > > **Intel Xeon Platinum 8259CL** > > ORIGINAL PATCHED > Benchmark (count) Mode Cnt Score Error Units Score Error Diff > TestCRC32C.testCRC32CUpdate 64 thrpt 12 61526.044 ? 14.426 ops/ms 116187.797 ? 37.719 88.8% > TestCRC32C.testCRC32CUpdate 128 thrpt 12 30043.410 ? 275.597 ops/ms 61527.139 ? 11.407 104.8% > TestCRC32C.testCRC32CUpdate 256 thrpt 12 16086.548 ? 1.386 ops/ms 49801.463 ? 4.034 209.6% > TestCRC32C.testCRC32CUpdate 512 thrpt 12 8107.780 ? 0.837 ops/ms 25506.806 ? 5.119 214.6% > TestCRC32C.testCRC32CUpdate 1024 thrpt 12 8171.332 ? 0.684 ops/ms 12913.665 ? 1.425 58.0% > TestCRC32C.testCRC32CUpdate 2048 thrpt 12 8300.331 ? 1.848 ops/ms 10155.094 ? 1.551 22.3% > TestCRC32C.testCRC32CUpdate 4096 thrpt 12 4886.483 ? 2.027 ops/ms 5101.460 ? 1.001 4.4% > TestCRC32C.testCRC32CUpdate 8192 thrpt 12 2690.988 ? 0.315 ops/ms 2859.960 ? 0.807 6.3% > TestCRC32C.testCRC32CUpdate 16384 thrpt 12 1414.695 ? 0.477 ops/ms 1432.189 ? 0.162 1.2% > TestCRC32C.testCRC32CUpdate 32768 thrpt 12 671.593 ? 103.208 ops/ms 682.077 ? 106.374 1.6% > TestCRC32C.testCRC32CUpdate 65536 thrpt 12 340.002 ? 53.363 ops/ms 341.034 ? 53.581 0.3% > > > **AMD EPYC 7251** > > ORIGINAL PATCHED > Benchmark (count) Mode Cnt Score Error Units Score Error Diff > TestCRC32C.testCRC32CUpdate 64 thrpt 12 32061.964 ? 26.971 ops/ms 53863.073 ? 133.610 68.0% > TestCRC32C.testCRC32CUpdate 128 thrpt 12 17706.981 ? 19.582 ops/ms 32515.029 ? 14.303 83.6% > TestCRC32C.testCRC32CUpdate 256 thrpt 12 8455.888 ? 5.070 ops/ms 19181.871 ? 35.279 126.8% > TestCRC32C.testCRC32CUpdate 512 thrpt 12 4550.874 ? 1.293 ops/ms 10008.634 ? 17.191 119.9% > TestCRC32C.testCRC32CUpdate 1024 thrpt 12 3636.205 ? 7.306 ops/ms 5122.156 ? 3.912 40.9% > TestCRC32C.testCRC32CUpdate 2048 thrpt 12 2549.876 ? 90.854 ops/ms 2811.828 ? 5.924 10.3% > TestCRC32C.testCRC32CUpdate 4096 thrpt 12 1335.905 ? 1.813 ops/ms 1389.812 ? 2.177 4.0% > TestCRC32C.testCRC32CUpdate 8192 thrpt 12 717.871 ? 7.692 ops/ms 737.720 ? 0.357 2.8% > TestCRC32C.testCRC32CUpdate 16384 thrpt 12 361.759 ? 1.755 ops/ms 364.348 ? 0.487 0.7% > TestCRC32C.testCRC32CUpdate 32768 thrpt 12 183.699 ? 0.586 ops/ms 184.822 ? 0.178 0.6% > TestCRC32C.testCRC32CUpdate 65536 thrpt 12 92.636 ? 0.133 ops/ms 92.850 ? 0.145 0.2% Andrei Pangin 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 'openjdk:master' into JDK-8299544 - Updated copyright years - Merge branch 'openjdk:master' into JDK-8299544 - 8299544: Improve performance of CRC32C intrinsics (non-AVX-512) for small inputs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11838/files - new: https://git.openjdk.org/jdk/pull/11838/files/632db572..c197bd81 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11838&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11838&range=01-02 Stats: 2555 lines in 225 files changed: 1640 ins; 432 del; 483 mod Patch: https://git.openjdk.org/jdk/pull/11838.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11838/head:pull/11838 PR: https://git.openjdk.org/jdk/pull/11838 From pchilanomate at openjdk.org Fri Jan 6 15:25:30 2023 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 6 Jan 2023 15:25:30 GMT Subject: [jdk20] RFR: 8294744: AArch64: applications/kitchensink/Kitchensink.java crashed: assert(oopDesc::is_oop(obj)) failed: not an oop [v2] In-Reply-To: References: Message-ID: > Please review the following patch. The value we set initially for extended_sp on natives frames doesn't account for the oop that could be pushed to the stack in case the method throws an exception. This can create a situation in Interpreter::_throw_exception_entry where we push an exception oop to the Java expression stack below the actual physical stack pointer. When JFR is present though a JavaThread could receive a suspend signal right after that push. On Linux aarch64, because there is no red zone defined (nor implemented it seems), the pushed oop gets overwritten during the setup and execution of the signal handler. This later leads to a crash when popping the oop back and rethrowing in the caller of the native method. There are more details in the bug comments. > > To fix it I used the same technique we use for normal Java frames, i.e. add extra space to extended_sp when creating the frame to account for the max space needed. > > > > I tested the patch by running Kitchensink.java around 150 times on mach5 with no failures (without the patch 50 runs would already show ~10 failures on average). I also run tiers1-6 for sanity check. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into JDK-8294744 - v1 ------------- Changes: - all: https://git.openjdk.org/jdk20/pull/85/files - new: https://git.openjdk.org/jdk20/pull/85/files/bd0b3e84..2aeadb14 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk20&pr=85&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=85&range=00-01 Stats: 50 lines in 9 files changed: 36 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk20/pull/85.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/85/head:pull/85 PR: https://git.openjdk.org/jdk20/pull/85 From alanb at openjdk.org Fri Jan 6 15:41:16 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 6 Jan 2023 15:41:16 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 14:49:16 GMT, Archie L. Cobbs wrote: > Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct? > > If this is generally agreed as a better route then let me know and I'll update the patch. Yes, I think that would be better. It would remove most of the noise, 1200+ files, and 10+ mailing lists from this PR. I assume there will be at least some iteration on compiler-dev about the details and changes to javac. Once you get to the JDK changes then I suspect that some areas may want to fix issues rather than adding SW. Sadly, I see a few examples in your list where there have been attempts to avoid leaking "this" but where we backed away out of concern that 3rd party code was extending some class and overriding a method known to be invoked by the constructor. Also we have places that register themselves to cleaners. I suspect some of the suggestions to document leaking this in implNotes will need discussion too because they amount to documenting "hooks" that people will rely on, e.g. documenting in ArrayDeque that its constructor invokes addList could be read as an invite to override it. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From mcimadamore at openjdk.org Fri Jan 6 15:57:50 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 6 Jan 2023 15:57:50 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 15:38:31 GMT, Alan Bateman wrote: >>> The associated JBS issue has been dormant for 6+ years and this is a very intrusive change affecting many, many files. Has the resurrection of this project previously been discussed somewhere? >> >> Hi @dholmes-ora, >> >> The work to add this warning has been guided by @briangoetz in discussions on the amber-dev mailing list. See that thread for how we came up with the current design, underlying motivation, etc. >> >> Regarding intrusiveness (assuming you're referring simply to the number of files touched), as mentioned this was one of two options. The other option would be to patch to about ~30 `Java.gmk` files in `make/modules` to exclude `this-escape` from `-Xlint` during the various module builds. >> >> Going this route is fine with me, but it has the downside that any new code being developed would not benefit from the new warning. This was in fact my original approach (and it was a lot easier :) but Brian rightly pointed out that adding `@SuppressWarnings` annotations was the the safer (i.e, more conservative) approach. >> >>> If you haven't done so already then you probably should socialize on compiler-dev and get agreement on the semantics and other details. >> >> Hi @AlanBateman, >> >> As mentioned this has been under discussion on amber-dev for a while. Happy to continue that discussion here as well. >> >>> I think you will also need to separate the addition of the lint warning from the changes to the wider JDK. It might be okay to add the feature but have it disabled for the JDK build initially. >> >> Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct? >> >> If this is generally agreed as a better route then let me know and I'll update the patch. >> >> Thanks for both of your comments. > >> Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct? >> >> If this is generally agreed as a better route then let me know and I'll update the patch. > > Yes, I think that would be better. It would remove most of the noise, 1200+ files, and 10+ mailing lists from this PR. I assume there will be at least some iteration on compiler-dev about the details and changes to javac. Once you get to the JDK changes then I suspect that some areas may want to fix issues rather than adding SW. Sadly, I see a few examples in your list where there have been attempts to avoid leaking "this" but where we backed away out of concern that 3rd party code was extending some class and overriding a method known to be invoked by the constructor. Also we have places that register themselves to cleaners. I suspect some of the suggestions to document leaking this in implNotes will need discussion too because they amount to documenting "hooks" that people will rely on, e.g. documenting in ArrayDeque that its constructor invokes addList could be read as an invite to override it. I agree with @AlanBateman. When we introduced similar warnings in the past, we have enabled support in javac (with some test) in a separate PR, and then followed up with small dedicated PR for each of the various areas (enabling new warnings one by one). See this great umbrella JBS issue (created by @asotona) which has details on all the issues that were filed when we added an extra Lint warning for lossy conversions: https://bugs.openjdk.org/browse/JDK-8286374 They all refer to this: https://bugs.openjdk.org/browse/JDK-8244681 Which was submitted as a separate javac-only PR: https://github.com/openjdk/jdk/pull/8599 ------------- PR: https://git.openjdk.org/jdk/pull/11874 From kvn at openjdk.org Fri Jan 6 18:09:05 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 6 Jan 2023 18:09:05 GMT Subject: RFR: JDK-8295406: C1 crash with -XX:TypeProfileArgsLimit=0 -XX:TypeProfileLevel=222 In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 13:41:36 GMT, Damon Fenacci wrote: > `-XX:TypeProfileArgsLimit=0 -XX:TypeProfileLevel=222` cause an assert to fail in `LIRGenerator::profile_arguments`. > > `LIRGenerator::profile_arguments` actually checks if arguments need to be profiled but the `MethodData::profile_arguments` method doesn't take `TypeProfileArgsLimit=0` into account. > > Adding a check for _TypeProfileArgsLimit>0_ to determine if arguments have to be profiled. Looks good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11843 From kvn at openjdk.org Fri Jan 6 18:09:13 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 6 Jan 2023 18:09:13 GMT Subject: RFR: 8299544: Improve performance of CRC32C intrinsics (non-AVX-512) for small inputs [v3] In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 15:15:51 GMT, Andrei Pangin wrote: >> When comparing performance of JDK built-in CRC32C intrinsics with the native implementation, we noticed that JDK performs notably worse on smaller array sizes (up to 1024 bytes). >> >> The main reason is that the algorithm based on the ["Fast CRC Computation for iSCSI Polynomial Using CRC32 Instruction"](https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/crc-iscsi-polynomial-crc32-instruction-paper.pdf) paper, processes input buffer in [chunks](https://github.com/openjdk/jdk/blob/92dfc735f2297441a99b3e39464fb8f77a354d55/src/hotspot/cpu/x86/crc32c.h#L29-L50) of 6144, 2064, and 648 bytes, and the rest of the buffer is processed sequentially with [4-byte variant](https://github.com/openjdk/jdk/blob/92dfc735f2297441a99b3e39464fb8f77a354d55/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L8231-L8236) of CRC32 instruction. >> >> Experiments show that CRC32C computation performance can be improved for smaller inputs without performance impact for larger inputs, if the smallest chunk size is reduced from 648 to 216 bytes. Actually, the original paper suggests the algorithms CRC_216 / CRC_240 for processing blocks of 216 and 240 bytes respectively. The value 648 might have resulted from an "x3" mistake (the algorithm accumulates 3 checksums per iteration). >> >> Additionally, when processing the tail (less than 216 bytes), we can use 8-byte variant of CRC32 instruction instead of 4-byte variant to speed up the algorithm even further. >> >> ### Changes in this PR >> >> 1. CRC32C_LOW is decreased from 8 * 27 to 8 * 9 (which corresponds to 216 bytes). >> 2. CRC32C_MIDDLE is decreased from 8 * 86 to 8 * 74 to compensate for performance drop for mid-size arrays. The value 74 has been chosen empirically. According to experiments, values from 70 to 75 yield the best results, while with higher or lower values, there is a degradation for certain array sizes. >> 3. On x86_64, `CRC32 r32, [m32]` instruction is replaced with `CRC32 r64, [m64]` in the tail loop. >> 4. Unconditional JMP is replaced with a conditional jump at the end of the loop. >> 5. The hot tail loop is aligned. >> >> ### Notes >> >> - The changes are only for x86 architecture. >> - If the hardware supports AVX-512 extensions + VPCLMULQDQ instruction (introduced with Ice Lake), another version of CRC32C intrinsics is generated, and the changes do not have effect. >> >> ### Performance >> >> JMH benchmark used to assess performance: https://cr.openjdk.java.net/~apangin/8299544/CrcBench.java >> >> Tested hardware: >> - Intel Xeon Platinum 8259CL >> - Intel Xeon Platinum 8124M >> - Intel Core i7-1280P >> - AMD EPYC 7251 >> >> Raw JMH results: >> https://cr.openjdk.java.net/~apangin/8299544/jmh/ >> >> Performance curve: >> crc32c-perf-curve >> >> Improvement summary as a table: >> crc32c-perf-table >> >> and as a graph: >> crc32c-perf-graph >> >> I also checked [TestCRC32C.java](https://github.com/openjdk/jdk/blob/872384707e89d03ede655aad16f360dc94f10152/test/micro/org/openjdk/bench/java/util/TestCRC32C.java) microbenchmark included in the JDK source code. It also shows similar improvement: >> >> **Intel Xeon Platinum 8259CL** >> >> ORIGINAL PATCHED >> Benchmark (count) Mode Cnt Score Error Units Score Error Diff >> TestCRC32C.testCRC32CUpdate 64 thrpt 12 61526.044 ? 14.426 ops/ms 116187.797 ? 37.719 88.8% >> TestCRC32C.testCRC32CUpdate 128 thrpt 12 30043.410 ? 275.597 ops/ms 61527.139 ? 11.407 104.8% >> TestCRC32C.testCRC32CUpdate 256 thrpt 12 16086.548 ? 1.386 ops/ms 49801.463 ? 4.034 209.6% >> TestCRC32C.testCRC32CUpdate 512 thrpt 12 8107.780 ? 0.837 ops/ms 25506.806 ? 5.119 214.6% >> TestCRC32C.testCRC32CUpdate 1024 thrpt 12 8171.332 ? 0.684 ops/ms 12913.665 ? 1.425 58.0% >> TestCRC32C.testCRC32CUpdate 2048 thrpt 12 8300.331 ? 1.848 ops/ms 10155.094 ? 1.551 22.3% >> TestCRC32C.testCRC32CUpdate 4096 thrpt 12 4886.483 ? 2.027 ops/ms 5101.460 ? 1.001 4.4% >> TestCRC32C.testCRC32CUpdate 8192 thrpt 12 2690.988 ? 0.315 ops/ms 2859.960 ? 0.807 6.3% >> TestCRC32C.testCRC32CUpdate 16384 thrpt 12 1414.695 ? 0.477 ops/ms 1432.189 ? 0.162 1.2% >> TestCRC32C.testCRC32CUpdate 32768 thrpt 12 671.593 ? 103.208 ops/ms 682.077 ? 106.374 1.6% >> TestCRC32C.testCRC32CUpdate 65536 thrpt 12 340.002 ? 53.363 ops/ms 341.034 ? 53.581 0.3% >> >> >> **AMD EPYC 7251** >> >> ORIGINAL PATCHED >> Benchmark (count) Mode Cnt Score Error Units Score Error Diff >> TestCRC32C.testCRC32CUpdate 64 thrpt 12 32061.964 ? 26.971 ops/ms 53863.073 ? 133.610 68.0% >> TestCRC32C.testCRC32CUpdate 128 thrpt 12 17706.981 ? 19.582 ops/ms 32515.029 ? 14.303 83.6% >> TestCRC32C.testCRC32CUpdate 256 thrpt 12 8455.888 ? 5.070 ops/ms 19181.871 ? 35.279 126.8% >> TestCRC32C.testCRC32CUpdate 512 thrpt 12 4550.874 ? 1.293 ops/ms 10008.634 ? 17.191 119.9% >> TestCRC32C.testCRC32CUpdate 1024 thrpt 12 3636.205 ? 7.306 ops/ms 5122.156 ? 3.912 40.9% >> TestCRC32C.testCRC32CUpdate 2048 thrpt 12 2549.876 ? 90.854 ops/ms 2811.828 ? 5.924 10.3% >> TestCRC32C.testCRC32CUpdate 4096 thrpt 12 1335.905 ? 1.813 ops/ms 1389.812 ? 2.177 4.0% >> TestCRC32C.testCRC32CUpdate 8192 thrpt 12 717.871 ? 7.692 ops/ms 737.720 ? 0.357 2.8% >> TestCRC32C.testCRC32CUpdate 16384 thrpt 12 361.759 ? 1.755 ops/ms 364.348 ? 0.487 0.7% >> TestCRC32C.testCRC32CUpdate 32768 thrpt 12 183.699 ? 0.586 ops/ms 184.822 ? 0.178 0.6% >> TestCRC32C.testCRC32CUpdate 65536 thrpt 12 92.636 ? 0.133 ops/ms 92.850 ? 0.145 0.2% > > Andrei Pangin 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 'openjdk:master' into JDK-8299544 > - Updated copyright years > - Merge branch 'openjdk:master' into JDK-8299544 > - 8299544: Improve performance of CRC32C intrinsics (non-AVX-512) for small inputs My testing passed. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11838 From bpb at openjdk.org Fri Jan 6 18:10:28 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 6 Jan 2023 18:10:28 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v3] In-Reply-To: References: Message-ID: > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299684: Call clampCapacity() only once; change IAE message ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11873/files - new: https://git.openjdk.org/jdk/pull/11873/files/db924a34..a9e44d62 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=01-02 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From apangin at openjdk.org Fri Jan 6 19:03:58 2023 From: apangin at openjdk.org (Andrei Pangin) Date: Fri, 6 Jan 2023 19:03:58 GMT Subject: Integrated: 8299544: Improve performance of CRC32C intrinsics (non-AVX-512) for small inputs In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 02:36:25 GMT, Andrei Pangin wrote: > When comparing performance of JDK built-in CRC32C intrinsics with the native implementation, we noticed that JDK performs notably worse on smaller array sizes (up to 1024 bytes). > > The main reason is that the algorithm based on the ["Fast CRC Computation for iSCSI Polynomial Using CRC32 Instruction"](https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/crc-iscsi-polynomial-crc32-instruction-paper.pdf) paper, processes input buffer in [chunks](https://github.com/openjdk/jdk/blob/92dfc735f2297441a99b3e39464fb8f77a354d55/src/hotspot/cpu/x86/crc32c.h#L29-L50) of 6144, 2064, and 648 bytes, and the rest of the buffer is processed sequentially with [4-byte variant](https://github.com/openjdk/jdk/blob/92dfc735f2297441a99b3e39464fb8f77a354d55/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L8231-L8236) of CRC32 instruction. > > Experiments show that CRC32C computation performance can be improved for smaller inputs without performance impact for larger inputs, if the smallest chunk size is reduced from 648 to 216 bytes. Actually, the original paper suggests the algorithms CRC_216 / CRC_240 for processing blocks of 216 and 240 bytes respectively. The value 648 might have resulted from an "x3" mistake (the algorithm accumulates 3 checksums per iteration). > > Additionally, when processing the tail (less than 216 bytes), we can use 8-byte variant of CRC32 instruction instead of 4-byte variant to speed up the algorithm even further. > > ### Changes in this PR > > 1. CRC32C_LOW is decreased from 8 * 27 to 8 * 9 (which corresponds to 216 bytes). > 2. CRC32C_MIDDLE is decreased from 8 * 86 to 8 * 74 to compensate for performance drop for mid-size arrays. The value 74 has been chosen empirically. According to experiments, values from 70 to 75 yield the best results, while with higher or lower values, there is a degradation for certain array sizes. > 3. On x86_64, `CRC32 r32, [m32]` instruction is replaced with `CRC32 r64, [m64]` in the tail loop. > 4. Unconditional JMP is replaced with a conditional jump at the end of the loop. > 5. The hot tail loop is aligned. > > ### Notes > > - The changes are only for x86 architecture. > - If the hardware supports AVX-512 extensions + VPCLMULQDQ instruction (introduced with Ice Lake), another version of CRC32C intrinsics is generated, and the changes do not have effect. > > ### Performance > > JMH benchmark used to assess performance: https://cr.openjdk.java.net/~apangin/8299544/CrcBench.java > > Tested hardware: > - Intel Xeon Platinum 8259CL > - Intel Xeon Platinum 8124M > - Intel Core i7-1280P > - AMD EPYC 7251 > > Raw JMH results: > https://cr.openjdk.java.net/~apangin/8299544/jmh/ > > Performance curve: > crc32c-perf-curve > > Improvement summary as a table: > crc32c-perf-table > > and as a graph: > crc32c-perf-graph > > I also checked [TestCRC32C.java](https://github.com/openjdk/jdk/blob/872384707e89d03ede655aad16f360dc94f10152/test/micro/org/openjdk/bench/java/util/TestCRC32C.java) microbenchmark included in the JDK source code. It also shows similar improvement: > > **Intel Xeon Platinum 8259CL** > > ORIGINAL PATCHED > Benchmark (count) Mode Cnt Score Error Units Score Error Diff > TestCRC32C.testCRC32CUpdate 64 thrpt 12 61526.044 ? 14.426 ops/ms 116187.797 ? 37.719 88.8% > TestCRC32C.testCRC32CUpdate 128 thrpt 12 30043.410 ? 275.597 ops/ms 61527.139 ? 11.407 104.8% > TestCRC32C.testCRC32CUpdate 256 thrpt 12 16086.548 ? 1.386 ops/ms 49801.463 ? 4.034 209.6% > TestCRC32C.testCRC32CUpdate 512 thrpt 12 8107.780 ? 0.837 ops/ms 25506.806 ? 5.119 214.6% > TestCRC32C.testCRC32CUpdate 1024 thrpt 12 8171.332 ? 0.684 ops/ms 12913.665 ? 1.425 58.0% > TestCRC32C.testCRC32CUpdate 2048 thrpt 12 8300.331 ? 1.848 ops/ms 10155.094 ? 1.551 22.3% > TestCRC32C.testCRC32CUpdate 4096 thrpt 12 4886.483 ? 2.027 ops/ms 5101.460 ? 1.001 4.4% > TestCRC32C.testCRC32CUpdate 8192 thrpt 12 2690.988 ? 0.315 ops/ms 2859.960 ? 0.807 6.3% > TestCRC32C.testCRC32CUpdate 16384 thrpt 12 1414.695 ? 0.477 ops/ms 1432.189 ? 0.162 1.2% > TestCRC32C.testCRC32CUpdate 32768 thrpt 12 671.593 ? 103.208 ops/ms 682.077 ? 106.374 1.6% > TestCRC32C.testCRC32CUpdate 65536 thrpt 12 340.002 ? 53.363 ops/ms 341.034 ? 53.581 0.3% > > > **AMD EPYC 7251** > > ORIGINAL PATCHED > Benchmark (count) Mode Cnt Score Error Units Score Error Diff > TestCRC32C.testCRC32CUpdate 64 thrpt 12 32061.964 ? 26.971 ops/ms 53863.073 ? 133.610 68.0% > TestCRC32C.testCRC32CUpdate 128 thrpt 12 17706.981 ? 19.582 ops/ms 32515.029 ? 14.303 83.6% > TestCRC32C.testCRC32CUpdate 256 thrpt 12 8455.888 ? 5.070 ops/ms 19181.871 ? 35.279 126.8% > TestCRC32C.testCRC32CUpdate 512 thrpt 12 4550.874 ? 1.293 ops/ms 10008.634 ? 17.191 119.9% > TestCRC32C.testCRC32CUpdate 1024 thrpt 12 3636.205 ? 7.306 ops/ms 5122.156 ? 3.912 40.9% > TestCRC32C.testCRC32CUpdate 2048 thrpt 12 2549.876 ? 90.854 ops/ms 2811.828 ? 5.924 10.3% > TestCRC32C.testCRC32CUpdate 4096 thrpt 12 1335.905 ? 1.813 ops/ms 1389.812 ? 2.177 4.0% > TestCRC32C.testCRC32CUpdate 8192 thrpt 12 717.871 ? 7.692 ops/ms 737.720 ? 0.357 2.8% > TestCRC32C.testCRC32CUpdate 16384 thrpt 12 361.759 ? 1.755 ops/ms 364.348 ? 0.487 0.7% > TestCRC32C.testCRC32CUpdate 32768 thrpt 12 183.699 ? 0.586 ops/ms 184.822 ? 0.178 0.6% > TestCRC32C.testCRC32CUpdate 65536 thrpt 12 92.636 ? 0.133 ops/ms 92.850 ? 0.145 0.2% This pull request has now been integrated. Changeset: 8c70bf3f Author: Andrei Pangin Committer: Sandhya Viswanathan URL: https://git.openjdk.org/jdk/commit/8c70bf3fff6f01b637f9e72a0b4c617051dbfafd Stats: 18 lines in 2 files changed: 5 ins; 2 del; 11 mod 8299544: Improve performance of CRC32C intrinsics (non-AVX-512) for small inputs Reviewed-by: kvn, eastigeevich, sviswanathan ------------- PR: https://git.openjdk.org/jdk/pull/11838 From sviswanathan at openjdk.org Fri Jan 6 19:48:56 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Fri, 6 Jan 2023 19:48:56 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v13] In-Reply-To: References: <6lAQI6kDDTGbskylHcWReX8ExaB6qkwgqoai7E6ikZY=.8a69a63c-453d-4bbd-8c76-4d477bfb77fe@github.com> Message-ID: On Thu, 22 Dec 2022 13:10:02 GMT, Claes Redestad wrote: >> @cl4es Thanks for passing the constant node through, the code looks much cleaner now. The attached patch should handle the signed bytes/shorts as well. Please take a look. >> [signed.patch](https://github.com/openjdk/jdk/files/10273480/signed.patch) > > I ran tests and some quick microbenchmarking to validate @sviswa7's patch to activate vectorization for `short` and `byte` arrays and it looks good: > > Before: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 10000 avgt 5 7845.586 ? 23.440 ns/op > ArraysHashCode.chars 10000 avgt 5 1203.163 ? 11.995 ns/op > ArraysHashCode.ints 10000 avgt 5 1131.915 ? 7.843 ns/op > ArraysHashCode.multibytes 10000 avgt 5 4136.487 ? 5.790 ns/op > ArraysHashCode.multichars 10000 avgt 5 671.328 ? 17.629 ns/op > ArraysHashCode.multiints 10000 avgt 5 699.051 ? 8.135 ns/op > ArraysHashCode.multishorts 10000 avgt 5 4139.300 ? 10.633 ns/op > ArraysHashCode.shorts 10000 avgt 5 7844.019 ? 26.071 ns/op > > > After: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 10000 avgt 5 1193.208 ? 1.965 ns/op > ArraysHashCode.chars 10000 avgt 5 1193.311 ? 5.941 ns/op > ArraysHashCode.ints 10000 avgt 5 1132.592 ? 10.410 ns/op > ArraysHashCode.multibytes 10000 avgt 5 657.343 ? 25.343 ns/op > ArraysHashCode.multichars 10000 avgt 5 672.668 ? 5.229 ns/op > ArraysHashCode.multiints 10000 avgt 5 697.143 ? 3.929 ns/op > ArraysHashCode.multishorts 10000 avgt 5 666.738 ? 12.236 ns/op > ArraysHashCode.shorts 10000 avgt 5 1193.563 ? 5.449 ns/op @cl4es There seem to be failure on windows-x64 platform pre submit tests. Could you please take a look? ------------- PR: https://git.openjdk.org/jdk/pull/10847 From coleenp at openjdk.org Fri Jan 6 20:03:34 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 6 Jan 2023 20:03:34 GMT Subject: RFR: 8299275: Add some ClassLoaderData verification code [v3] In-Reply-To: <1Adx9iDHr_fSF8l2AXfNF9Rzq5NpPwhqiJ2AxnorYRQ=.88805086-76f3-4839-80de-ad059f7304f7@github.com> References: <1Adx9iDHr_fSF8l2AXfNF9Rzq5NpPwhqiJ2AxnorYRQ=.88805086-76f3-4839-80de-ad059f7304f7@github.com> Message-ID: > I added some verification code to try to help track down JDK-8296915 (https://bugs.openjdk.org/browse/JDK-8296915). > Ran Test: runtime/SelectionResolution/InvokeInterfaceSuccessTest.java 100x with -XX:+VerifyBefore/AfterGC. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision: - Fix some english. - Walk other non-mirror oops in CLD::_handles area and add a comment why not mirrors. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11856/files - new: https://git.openjdk.org/jdk/pull/11856/files/4775cbc9..5b425763 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11856&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11856&range=01-02 Stats: 5 lines in 1 file changed: 1 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11856.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11856/head:pull/11856 PR: https://git.openjdk.org/jdk/pull/11856 From fparain at openjdk.org Fri Jan 6 20:48:51 2023 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 6 Jan 2023 20:48:51 GMT Subject: RFR: 8299275: Add some ClassLoaderData verification code [v3] In-Reply-To: References: <1Adx9iDHr_fSF8l2AXfNF9Rzq5NpPwhqiJ2AxnorYRQ=.88805086-76f3-4839-80de-ad059f7304f7@github.com> Message-ID: On Fri, 6 Jan 2023 20:03:34 GMT, Coleen Phillimore wrote: >> I added some verification code to try to help track down JDK-8296915 (https://bugs.openjdk.org/browse/JDK-8296915). >> Ran Test: runtime/SelectionResolution/InvokeInterfaceSuccessTest.java 100x with -XX:+VerifyBefore/AfterGC. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision: > > - Fix some english. > - Walk other non-mirror oops in CLD::_handles area and add a comment why not mirrors. Looks good to me. Thank you for the comment about mirrors. ------------- Marked as reviewed by fparain (Committer). PR: https://git.openjdk.org/jdk/pull/11856 From duke at openjdk.org Fri Jan 6 23:13:09 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 6 Jan 2023 23:13:09 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v2] In-Reply-To: References: Message-ID: > This PR adds a new lint warning category `this-escape`. > > It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. > > A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ > * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) > * Some constructor `B()` of `B` invokes `A()` as its superclass constructor > * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly > > In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. > > Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. > > From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. > > For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. > > More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. > > Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. > > Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. > > **Patch Navigation Guide** > > * Non-trivial compiler changes: > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` > > * Javadoc additions of `@implNote`: > > * `src/java.base/share/classes/java/io/PipedReader.java` > * `src/java.base/share/classes/java/io/PipedWriter.java` > * `src/java.base/share/classes/java/lang/Throwable.java` > * `src/java.base/share/classes/java/util/ArrayDeque.java` > * `src/java.base/share/classes/java/util/EnumMap.java` > * `src/java.base/share/classes/java/util/HashSet.java` > * `src/java.base/share/classes/java/util/Hashtable.java` > * `src/java.base/share/classes/java/util/LinkedList.java` > * `src/java.base/share/classes/java/util/TreeMap.java` > * `src/java.base/share/classes/java/util/TreeSet.java` > > * New unit tests > * `test/langtools/tools/javac/warnings/ThisEscape/*.java` > > * **Everything else** is just adding `@SuppressWarnings("this-escape")` Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision: - Update copyright year for newly added files to 2023. - Suppress "this-escape" warnings using build flags instead of @SuppressAnnotations annotations. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11874/files - new: https://git.openjdk.org/jdk/pull/11874/files/9c162283..f667cd56 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=00-01 Stats: 1935 lines in 1303 files changed: 60 ins; 1770 del; 105 mod Patch: https://git.openjdk.org/jdk/pull/11874.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874 PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Fri Jan 6 23:13:09 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 6 Jan 2023 23:13:09 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 15:38:31 GMT, Alan Bateman wrote: >>> The associated JBS issue has been dormant for 6+ years and this is a very intrusive change affecting many, many files. Has the resurrection of this project previously been discussed somewhere? >> >> Hi @dholmes-ora, >> >> The work to add this warning has been guided by @briangoetz in discussions on the amber-dev mailing list. See that thread for how we came up with the current design, underlying motivation, etc. >> >> Regarding intrusiveness (assuming you're referring simply to the number of files touched), as mentioned this was one of two options. The other option would be to patch to about ~30 `Java.gmk` files in `make/modules` to exclude `this-escape` from `-Xlint` during the various module builds. >> >> Going this route is fine with me, but it has the downside that any new code being developed would not benefit from the new warning. This was in fact my original approach (and it was a lot easier :) but Brian rightly pointed out that adding `@SuppressWarnings` annotations was the the safer (i.e, more conservative) approach. >> >>> If you haven't done so already then you probably should socialize on compiler-dev and get agreement on the semantics and other details. >> >> Hi @AlanBateman, >> >> As mentioned this has been under discussion on amber-dev for a while. Happy to continue that discussion here as well. >> >>> I think you will also need to separate the addition of the lint warning from the changes to the wider JDK. It might be okay to add the feature but have it disabled for the JDK build initially. >> >> Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct? >> >> If this is generally agreed as a better route then let me know and I'll update the patch. >> >> Thanks for both of your comments. > >> Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct? >> >> If this is generally agreed as a better route then let me know and I'll update the patch. > > Yes, I think that would be better. It would remove most of the noise, 1200+ files, and 10+ mailing lists from this PR. I assume there will be at least some iteration on compiler-dev about the details and changes to javac. Once you get to the JDK changes then I suspect that some areas may want to fix issues rather than adding SW. Sadly, I see a few examples in your list where there have been attempts to avoid leaking "this" but where we backed away out of concern that 3rd party code was extending some class and overriding a method known to be invoked by the constructor. Also we have places that register themselves to cleaners. I suspect some of the suggestions to document leaking this in implNotes will need discussion too because they amount to documenting "hooks" that people will rely on, e.g. documenting in ArrayDeque that its constructor invokes addList could be read as an invite to override it. Hi @AlanBateman, OK that sounds like a plan. I've pushed a new commit to the `ThisEscape` branch that removes all the`@SuppressWarnings` annotations and replaces them with adjustments to build flags. I've moved the `@SuppressWarnings` annotations onto a new branch `ThisEscapeAnnotations`. This is just for future reference in case somebody wants to add them back someday and doesn't want to start from scratch. > I suspect some of the suggestions to document leaking this in implNotes will need discussion too because they amount to documenting "hooks" that people will rely on, e.g. documenting in ArrayDeque that its constructor invokes addList could be read as an invite to override it. Hmm. Hasn't that horse already left the barn? You kind of implied that when you said: > I see a few examples in your list where there have been attempts to avoid leaking "this" but where we backed away out of concern that 3rd party code was extending some class and overriding a method known to be invoked by the constructor. In other words, it doesn't sound like changing the behavior of these constructors is viable option at this point. And if that's the case, we might as well document and warn about the current behavior. Of course I'd love to be wrong... in which case, we can fix these constructors. Or, the third option - just do nothing yet. That would mean removing the warnings, which is fine. But then the `ThisEscape.html` document is orphaned. What should we do with it? I can remove it, just leave it there, or put it somewhere else (where?). It seems like having some documentation of the meaning of "this escape" would be helpful, because it's a subtle concept and there are multiple ways to define "escape". Thanks. @mcimadamore thanks for the bugs suggestion, I'll put that on the to-do list. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From bpb at openjdk.org Fri Jan 6 23:56:39 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 6 Jan 2023 23:56:39 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v4] In-Reply-To: References: Message-ID: > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299684: Add test for out of range capacity passed to NewDirectBuffer ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11873/files - new: https://git.openjdk.org/jdk/pull/11873/files/a9e44d62..d8e6c180 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=02-03 Stats: 121 lines in 3 files changed: 120 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From fyang at openjdk.org Sat Jan 7 10:11:53 2023 From: fyang at openjdk.org (Fei Yang) Date: Sat, 7 Jan 2023 10:11:53 GMT Subject: RFR: 8299312: Clean up BarrierSetNMethod [v2] In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 14:50:20 GMT, Erik ?sterlund wrote: >> The terminology in BarrierSetNMethod is not crisp. In platform code we talk about a per-nmethod "guard value", but on shared level we call the same value arm value or disarm value in different contexts. But it really depends on the value whether the nmethod is disarmed or armed. We should embrace the "guard value" terminology and lift it in to the shared code level. >> We also have more functionality than we need on platform level. The platform level only needs to know how to deoptimize, and how to set/get the guard value of an nmethod. The more specific functionality should be moved to the shared code and be expressed in terms of said setter/getter. > > Erik ?sterlund 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: > > - ARM support > - Merge branch 'master' into 8299312_barrier_set_nmethod_cleanup > - Fix Shenandoah build > - 8299312: Clean up BarrierSetNMethod Looks good to me. src/hotspot/share/runtime/thread.hpp line 118: > 116: // On AArch64, the high order 32 bits are used by a "patching epoch" number > 117: // which reflects if this thread has executed the required fences, after > 118: // an nmethod gets disarmed. The low order 32 bit denote the disarmed value. Nit: I think this should be: "The low order 32 bits denote the disarmed value." instead of: "The low order 32 bit denote the disarmed value." ------------- Marked as reviewed by fyang (Reviewer). PR: https://git.openjdk.org/jdk/pull/11774 From duke at openjdk.org Sat Jan 7 16:24:56 2023 From: duke at openjdk.org (ExE Boss) Date: Sat, 7 Jan 2023 16:24:56 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v2] In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 23:13:09 GMT, Archie L. Cobbs wrote: >> This PR adds a new lint warning category `this-escape`. >> >> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. >> >> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ >> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) >> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor >> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly >> >> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. >> >> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. >> >> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. >> >> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. >> >> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. >> >> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. >> >> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. >> >> **Patch Navigation Guide** >> >> * Non-trivial compiler changes: >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` >> >> * Javadoc additions of `@implNote`: >> >> * `src/java.base/share/classes/java/io/PipedReader.java` >> * `src/java.base/share/classes/java/io/PipedWriter.java` >> * `src/java.base/share/classes/java/lang/Throwable.java` >> * `src/java.base/share/classes/java/util/ArrayDeque.java` >> * `src/java.base/share/classes/java/util/EnumMap.java` >> * `src/java.base/share/classes/java/util/HashSet.java` >> * `src/java.base/share/classes/java/util/Hashtable.java` >> * `src/java.base/share/classes/java/util/LinkedList.java` >> * `src/java.base/share/classes/java/util/TreeMap.java` >> * `src/java.base/share/classes/java/util/TreeSet.java` >> >> * New unit tests >> * `test/langtools/tools/javac/warnings/ThisEscape/*.java` >> >> * **Everything else** is just adding `@SuppressWarnings("this-escape")` > > Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright year for newly added files to 2023. > - Suppress "this-escape" warnings using build flags instead of @SuppressAnnotations annotations. src/java.base/share/classes/java/lang/AssertionError.java line 75: > 73: */ > 74: @SuppressWarnings("this-escape") > 75: public AssertionError(Object detailMessage) { The?Javadoc of?this?constructor should?probably?mention that?it?calls `initCause(?)` when?`detailMessage` is?a?`Throwable`. src/java.base/share/classes/java/lang/BootstrapMethodError.java line 77: > 75: * Constructs a {@code BootstrapMethodError} with the specified > 76: * cause. > 77: * Suggestion: * * @implNote This constructor invokes {@link #initCause initCause()}; see * This Escape. * src/java.base/share/classes/java/lang/ExceptionInInitializerError.java line 54: > 52: * throwable object. > 53: * A detail message is a String that describes this particular exception. > 54: */ Suggestion: * * @implNote This constructor invokes {@link #initCause initCause()}; see * This Escape. */ ------------- PR: https://git.openjdk.org/jdk/pull/11874 From aph at openjdk.org Sat Jan 7 18:19:51 2023 From: aph at openjdk.org (Andrew Haley) Date: Sat, 7 Jan 2023 18:19:51 GMT Subject: [jdk20] RFR: 8294744: AArch64: applications/kitchensink/Kitchensink.java crashed: assert(oopDesc::is_oop(obj)) failed: not an oop [v2] In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 15:25:30 GMT, Patricio Chilano Mateo wrote: >> Please review the following patch. The value we set initially for extended_sp on natives frames doesn't account for the oop that could be pushed to the stack in case the method throws an exception. This can create a situation in Interpreter::_throw_exception_entry where we push an exception oop to the Java expression stack below the actual physical stack pointer. When JFR is present though a JavaThread could receive a suspend signal right after that push. On Linux aarch64, because there is no red zone defined (nor implemented it seems), the pushed oop gets overwritten during the setup and execution of the signal handler. This later leads to a crash when popping the oop back and rethrowing in the caller of the native method. There are more details in the bug comments. >> >> To fix it I used the same technique we use for normal Java frames, i.e. add extra space to extended_sp when creating the frame to account for the max space needed. >> >> >> >> I tested the patch by running Kitchensink.java around 150 times on mach5 with no failures (without the patch 50 runs would already show ~10 failures on average). I also run tiers1-6 for sanity check. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into JDK-8294744 > - v1 Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.org/jdk20/pull/85 From jcking at openjdk.org Sun Jan 8 10:50:54 2023 From: jcking at openjdk.org (Justin King) Date: Sun, 8 Jan 2023 10:50:54 GMT Subject: Integrated: JDK-8299481: Remove metaprogramming/removePointer.hpp In-Reply-To: References: Message-ID: On Mon, 2 Jan 2023 22:30:21 GMT, Justin King wrote: > Code cleanup of pre-C++11 implementations. This pull request has now been integrated. Changeset: d53cac37 Author: Justin King Committer: Kim Barrett URL: https://git.openjdk.org/jdk/commit/d53cac379419b7b74df045bb119df6d5f9e91878 Stats: 87 lines in 3 files changed: 0 ins; 87 del; 0 mod 8299481: Remove metaprogramming/removePointer.hpp Reviewed-by: kbarrett, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/11817 From fyang at openjdk.org Mon Jan 9 02:08:01 2023 From: fyang at openjdk.org (Fei Yang) Date: Mon, 9 Jan 2023 02:08:01 GMT Subject: [jdk20] RFR: 8294744: AArch64: applications/kitchensink/Kitchensink.java crashed: assert(oopDesc::is_oop(obj)) failed: not an oop [v2] In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 15:25:30 GMT, Patricio Chilano Mateo wrote: >> Please review the following patch. The value we set initially for extended_sp on natives frames doesn't account for the oop that could be pushed to the stack in case the method throws an exception. This can create a situation in Interpreter::_throw_exception_entry where we push an exception oop to the Java expression stack below the actual physical stack pointer. When JFR is present though a JavaThread could receive a suspend signal right after that push. On Linux aarch64, because there is no red zone defined (nor implemented it seems), the pushed oop gets overwritten during the setup and execution of the signal handler. This later leads to a crash when popping the oop back and rethrowing in the caller of the native method. There are more details in the bug comments. >> >> To fix it I used the same technique we use for normal Java frames, i.e. add extra space to extended_sp when creating the frame to account for the max space needed. >> >> >> >> I tested the patch by running Kitchensink.java around 150 times on mach5 with no failures (without the patch 50 runs would already show ~10 failures on average). I also run tiers1-6 for sanity check. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into JDK-8294744 > - v1 Looks good to me. JVM on linux-riscv64 bears the same problem as it has the same code flow as aarch64 on this part. And linux-riscv64 doesn't have a redzone defined/implemented either, which I have verified with a small C program with inline assembly like you do for x86 and aarch64. So I have prepared a fix for linux-riscv64. This has passed sanity tests on HiFive Unmatched. Could you please add this change while you are on it? diff --git a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp index 49a2b87c232..213e360c20e 100644 --- a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp +++ b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp @@ -776,8 +776,12 @@ void TemplateInterpreterGenerator::generate_fixed_frame(bool native_call) { // Move SP out of the way __ mv(sp, t0); } else { - __ sd(sp, Address(sp, 5 * wordSize)); + // Make sure there is room for the exception oop pushed in case method throws + // an exception (see TemplateInterpreterGenerator::generate_throw_exception()) + __ sub(t0, sp, 2 * wordSize); + __ sd(t0, Address(sp, 5 * wordSize)); __ sd(zr, Address(sp, 4 * wordSize)); + __ mv(sp, t0); } } ------------- PR: https://git.openjdk.org/jdk20/pull/85 From dholmes at openjdk.org Mon Jan 9 05:54:55 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 9 Jan 2023 05:54:55 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v4] In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 23:56:39 GMT, Brian Burkhalter wrote: >> Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299684: Add test for out of range capacity passed to NewDirectBuffer Changes requested by dholmes (Reviewer). make/test/JtregNativeJdk.gmk line 81: > 79: > 80: BUILD_JDK_JTREG_LIBRARIES_LIBS_libTracePinnedThreads := jvm.lib > 81: BUILD_JDK_JTREG_LIBRARIES_LIBS_libNewDirectByteBuffer := -ljava -lc This is not correct for Windows make/test/JtregNativeJdk.gmk line 85: > 83: BUILD_JDK_JTREG_LIBRARIES_LIBS_libstringPlatformChars := -ljava > 84: BUILD_JDK_JTREG_LIBRARIES_LIBS_libDirectIO := -ljava > 85: BUILD_JDK_JTREG_LIBRARIES_LIBS_libNewDirectByteBuffer := -ljava -lc Why do we need `-lc`? src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 245: > 243: // Constrain the capacity to int range throwing IAE if not possible > 244: // > 245: private static int clampCapacity(long capacity) { I think `checkCapacity` would be better - clamp suggests the value gets clamped rather than throwing an exception. src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 247: > 245: private static int clampCapacity(long capacity) { > 246: try { > 247: return Math.toIntExact(capacity); Why not the more direct and obvious: if (capacity < 0) { throw ... } else if (capacity > Integer.MAX_VALUE) { throw ... } src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 251: > 249: String msg = "JNI NewDirectByteBuffer passed illegal capacity: " > 250: + capacity + (capacity < Integer.MIN_VALUE > 251: ? " < Integer.MIN_VALUE" : " > Integer.MAX_VALUE"); Why the check against `MIN_VALUE`? test/jdk/java/nio/jni/NewDirectByteBuffer.java line 49: > 47: 1L, > 48: (long)Integer.MAX_VALUE - 1, > 49: (long)Integer.MAX_VALUE Won't such large capacities trigger OOME? ------------- PR: https://git.openjdk.org/jdk/pull/11873 From duke at openjdk.org Mon Jan 9 07:13:49 2023 From: duke at openjdk.org (Damon Fenacci) Date: Mon, 9 Jan 2023 07:13:49 GMT Subject: RFR: JDK-8295406: C1 crash with -XX:TypeProfileArgsLimit=0 -XX:TypeProfileLevel=222 In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 06:33:05 GMT, Tobias Hartmann wrote: >> `-XX:TypeProfileArgsLimit=0 -XX:TypeProfileLevel=222` cause an assert to fail in `LIRGenerator::profile_arguments`. >> >> `LIRGenerator::profile_arguments` actually checks if arguments need to be profiled but the `MethodData::profile_arguments` method doesn't take `TypeProfileArgsLimit=0` into account. >> >> Adding a check for _TypeProfileArgsLimit>0_ to determine if arguments have to be profiled. > > Looks good to me! @TobiHartmann @vnkozlov thanks a lot for your reviews! ------------- PR: https://git.openjdk.org/jdk/pull/11843 From aboldtch at openjdk.org Mon Jan 9 07:25:06 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 9 Jan 2023 07:25:06 GMT Subject: RFR: 8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly [v3] In-Reply-To: References: Message-ID: > In a similar vain to [JDK-8299089](https://bugs.openjdk.org/browse/JDK-8299089) there are different semantics for OopStorage and thread local oops. UnifiedOopRef in the jfr leakprofiler must be able to distinguish these and treat them appropriately. > > Testing: Running test at the moment. Has been running on the generational branch of ZGC for over three months. Not many tests exercise the leakprofiler. x86_32 has mostly been tested with GHA. > > Note: The accessBackend changes are only there to facilitate comparing OopLoadProxy objects directly with nullptr instead of creating and comparing with an `oop()` / `oop(NULL)`. Can be backed out of this PR and put in a different RFE instead. Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Add comment and cleanup assert ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11741/files - new: https://git.openjdk.org/jdk/pull/11741/files/e0d2eea4..b82e8997 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11741&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11741&range=01-02 Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11741.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11741/head:pull/11741 PR: https://git.openjdk.org/jdk/pull/11741 From aboldtch at openjdk.org Mon Jan 9 07:25:07 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 9 Jan 2023 07:25:07 GMT Subject: RFR: 8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly [v2] In-Reply-To: References: <-Vajigb2X8yHp76kYNFVh58pp8XgB0A04odj5KEIFFw=.d7b72d1c-024f-4747-9a45-f4e9656b2f6a@github.com> <-Bw1QEa8ENJ4arP1p27jW5J3scq3G6LhTOrqdr3pww4=.1e170716-a01b-4e64-952a-b9e05aefbbfb@github.com> Message-ID: On Wed, 4 Jan 2023 13:25:57 GMT, Markus Gr?nlund wrote: >> @fisk Why are the shifts needed on 64-bits? > > Maybe the shift is needed in order to handle unaligned oops, as for code blob oops? The existing root processing logic has up to now skipped code blob oops, mainly because they were hard to encode. The rationale was that they are not roots in and of themselves. Now, we have seen several instances where chains are not found on iterations, so maybe the assumption on skipping code blob oops is wrong. With this encoding scheme in place, it would be possible to pass a closure for processing the code blob oops as well. Sorry for the tardy response. I think I forgot what the code was actually doing at the time of writing my previous answer. We are encoding ` narrowOop*` and `oop*` here not `narrowOop`/`oop`. And `narrowOop*` are 4 byte aligned. ------------- PR: https://git.openjdk.org/jdk/pull/11741 From duke at openjdk.org Mon Jan 9 08:02:03 2023 From: duke at openjdk.org (Damon Fenacci) Date: Mon, 9 Jan 2023 08:02:03 GMT Subject: Integrated: JDK-8295406: C1 crash with -XX:TypeProfileArgsLimit=0 -XX:TypeProfileLevel=222 In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 13:41:36 GMT, Damon Fenacci wrote: > `-XX:TypeProfileArgsLimit=0 -XX:TypeProfileLevel=222` cause an assert to fail in `LIRGenerator::profile_arguments`. > > `LIRGenerator::profile_arguments` actually checks if arguments need to be profiled but the `MethodData::profile_arguments` method doesn't take `TypeProfileArgsLimit=0` into account. > > Adding a check for _TypeProfileArgsLimit>0_ to determine if arguments have to be profiled. This pull request has now been integrated. Changeset: 9b1ade8e Author: Damon Fenacci Committer: Tobias Hartmann URL: https://git.openjdk.org/jdk/commit/9b1ade8e2b324b3875bf97c70d8591c577568c32 Stats: 46 lines in 2 files changed: 44 ins; 0 del; 2 mod 8295406: C1 crash with -XX:TypeProfileArgsLimit=0 -XX:TypeProfileLevel=222 Reviewed-by: thartmann, kvn ------------- PR: https://git.openjdk.org/jdk/pull/11843 From alanb at openjdk.org Mon Jan 9 08:42:52 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 9 Jan 2023 08:42:52 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v4] In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 23:56:39 GMT, Brian Burkhalter wrote: >> Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299684: Add test for out of range capacity passed to NewDirectBuffer I agree with David that it would be clearer and simpler to check if capacity is negative or greater than Integer.MAX_VALUE. There other helper methods called from this code and they are named checkXXX so it would be good to keep that consistent if you can. We don't have other tests for this JNI function in the test tree so having the new tests be a complete unit test would be good. This means checking the position, limit, and capacity of the ByteBuffer and testing that it's a direct buffer. If you make it a JUnit test then you'll be able to paramatrized test with value sources, and use the assertions API when checking each of the buffer properties. For the native code used by the test then it would be clearer if allocBigBuffer were renamed to newDirectByteBuffer. Also I think you'll need to check the value from malloc in case it fails. You'll need another native function to free the memory and have the tests invoke the free in a finally block so that memory doesn't accumulate as the test cycles through the different buffer sizes. Right now, I assume the tests don't run on 32-bit as it mallocs two 2Gb areas. Once the test is re-worded then you can get a sense as to how much memory it needs and whether you need a @requires in the test description to ensue that the test system has sufficient memory. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From alanb at openjdk.org Mon Jan 9 08:45:52 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 9 Jan 2023 08:45:52 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v4] In-Reply-To: References: Message-ID: <1deRMd9Z4swBHRwfUtX5_-XNYuHpYv7PKi4Gf3gjJXA=.e23bf8cf-041f-48e2-916d-33273161a8b9@github.com> On Mon, 9 Jan 2023 05:51:15 GMT, David Holmes wrote: > Won't such large capacities trigger OOME? The malloc might fail, in which case the value of NULL will be passed to NewDirectByteBuffer. It needs to check the return from malloc. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From eosterlund at openjdk.org Mon Jan 9 09:49:55 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 9 Jan 2023 09:49:55 GMT Subject: RFR: 8299312: Clean up BarrierSetNMethod [v2] In-Reply-To: References: Message-ID: On Sat, 7 Jan 2023 10:08:36 GMT, Fei Yang wrote: >> Erik ?sterlund 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: >> >> - ARM support >> - Merge branch 'master' into 8299312_barrier_set_nmethod_cleanup >> - Fix Shenandoah build >> - 8299312: Clean up BarrierSetNMethod > > Looks good to me. Thanks for the review @RealFYang! > src/hotspot/share/runtime/thread.hpp line 118: > >> 116: // On AArch64, the high order 32 bits are used by a "patching epoch" number >> 117: // which reflects if this thread has executed the required fences, after >> 118: // an nmethod gets disarmed. The low order 32 bit denote the disarmed value. > > Nit: > I think this should be: > "The low order 32 bits denote the disarmed value." > instead of: > "The low order 32 bit denote the disarmed value." Yes, you are right, thanks. ------------- PR: https://git.openjdk.org/jdk/pull/11774 From aturbanov at openjdk.org Mon Jan 9 09:44:51 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 9 Jan 2023 09:44:51 GMT Subject: RFR: 8299089: Instrument global jni handles with tag to make them distinguishable In-Reply-To: References: Message-ID: On Tue, 20 Dec 2022 11:44:33 GMT, Axel Boldt-Christmas wrote: > Weak global jni handles are tagged so the GC can distinguish them when resolving the object. Today there is no cheap way of distinguishing global jni handles from local jni handles. For generational ZGC the OopStorage handles and the thread local handles semantical difference requires the handles to be distinguishable. > > This enhancements instruments the jni handles with a global tag similarly to the jweak tag. > > Note: > * the s390 implementation has minimal changes and requires improvement. > * There is room for enchantment here to create the same abstraction that ppc uses for all platforms, i.e. move the resolve_jobject from the MacroAssembler to the BarrierSetAssembler which allows for more optimised code for GCs that can treat local and global handles the same. > > Testing: GHA. Oracle supported platforms tier1-3. Will run higher tiers. Has also been tested on the generational branch of ZGC for over three months. Requires testing on non Oracle platforms. test/hotspot/jtreg/runtime/jni/FastGetField/FastGetField.java line 134: > 132: long duration = System.nanoTime(); > 133: for (int c = 0; c < loop_cnt; ++c) { > 134: if (accessFields() != 0l) throw new RuntimeException("Wrong initial result!"); nit: Suggestion: if (accessFields() != 0L) throw new RuntimeException("Wrong initial result!"); ------------- PR: https://git.openjdk.org/jdk/pull/11740 From eosterlund at openjdk.org Mon Jan 9 09:54:12 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 9 Jan 2023 09:54:12 GMT Subject: RFR: 8299312: Clean up BarrierSetNMethod [v3] In-Reply-To: References: Message-ID: > The terminology in BarrierSetNMethod is not crisp. In platform code we talk about a per-nmethod "guard value", but on shared level we call the same value arm value or disarm value in different contexts. But it really depends on the value whether the nmethod is disarmed or armed. We should embrace the "guard value" terminology and lift it in to the shared code level. > We also have more functionality than we need on platform level. The platform level only needs to know how to deoptimize, and how to set/get the guard value of an nmethod. The more specific functionality should be moved to the shared code and be expressed in terms of said setter/getter. Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: Nit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11774/files - new: https://git.openjdk.org/jdk/pull/11774/files/e0b32db3..08a1fb25 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11774&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11774&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11774.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11774/head:pull/11774 PR: https://git.openjdk.org/jdk/pull/11774 From rschmelter at openjdk.org Mon Jan 9 10:04:53 2023 From: rschmelter at openjdk.org (Ralf Schmelter) Date: Mon, 9 Jan 2023 10:04:53 GMT Subject: RFR: JDK-8299672: Enhance HeapDump JFR event In-Reply-To: References: Message-ID: On Thu, 5 Jan 2023 14:54:31 GMT, Matthias Baesken wrote: > Enhance the JFR Event HeapDump with the additional interesting fields, compression and overwrite. > Add some UL logging in case the heap dump writing failed . Looks good. test/jdk/jdk/jfr/event/diagnostics/TestHeapDump.java line 68: > 66: Events.assertField(e, "onOutOfMemoryError").equal(false); > 67: Events.assertField(e, "size").equal(Files.size(path)); > 68: Events.assertField(e, "compression").equal(-1); I would use below(1) instead of equals(-1), since it is not specified which value < 1 is used when gzip compression is not enabled. Or you could do the sanitizing when storing the value in the event itself. But in that case I would probably use 0 instead of -1. ------------- Marked as reviewed by rschmelter (Reviewer). PR: https://git.openjdk.org/jdk/pull/11864 From stefank at openjdk.org Mon Jan 9 10:38:51 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 9 Jan 2023 10:38:51 GMT Subject: RFR: 8299032: Interface IN_NATIVE oop stores for C2 In-Reply-To: <61HZ-hCw_ZoDZCtsDLsz-tfPE6S7Ox_1nXApLQnZ1SU=.60c813cf-a5d8-4a3c-a2a1-86d7af05d042@github.com> References: <61HZ-hCw_ZoDZCtsDLsz-tfPE6S7Ox_1nXApLQnZ1SU=.60c813cf-a5d8-4a3c-a2a1-86d7af05d042@github.com> Message-ID: On Fri, 23 Dec 2022 13:54:44 GMT, Erik ?sterlund wrote: > Loom added the first IN_NATIVE oop store to C2 code, when switching the current virtual thread of a platform thread. Instead of interfacing this properly, a raw store was used. But a future GC algorithm, such as generational ZGC, might not work well with raw stores. We should add support to the access API for this. Looks like Shenandoah was already missing something here as they do concurrent root processing requiring SATB barriers on IN_NATIVE oop stores. It is not in the scope of this PR to fix the Shenandoah bug - someone working on Shenandoah should do this. This PR merely adds an interface such that GCs that need to do something different here, can do that. Serial, Parallel and G1 don't need to do anything for IN_NATIVE stores as they do STW root processing. ZGC doesn't (yet) have store barriers at all, and hence doesn't need to do anything special either. Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11777 From eosterlund at openjdk.org Mon Jan 9 10:47:51 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 9 Jan 2023 10:47:51 GMT Subject: RFR: 8299032: Interface IN_NATIVE oop stores for C2 In-Reply-To: References: <61HZ-hCw_ZoDZCtsDLsz-tfPE6S7Ox_1nXApLQnZ1SU=.60c813cf-a5d8-4a3c-a2a1-86d7af05d042@github.com> Message-ID: On Mon, 9 Jan 2023 10:36:15 GMT, Stefan Karlsson wrote: >> Loom added the first IN_NATIVE oop store to C2 code, when switching the current virtual thread of a platform thread. Instead of interfacing this properly, a raw store was used. But a future GC algorithm, such as generational ZGC, might not work well with raw stores. We should add support to the access API for this. Looks like Shenandoah was already missing something here as they do concurrent root processing requiring SATB barriers on IN_NATIVE oop stores. It is not in the scope of this PR to fix the Shenandoah bug - someone working on Shenandoah should do this. This PR merely adds an interface such that GCs that need to do something different here, can do that. Serial, Parallel and G1 don't need to do anything for IN_NATIVE stores as they do STW root processing. ZGC doesn't (yet) have store barriers at all, and hence doesn't need to do anything special either. > > Marked as reviewed by stefank (Reviewer). Thanks for the review, @stefank! ------------- PR: https://git.openjdk.org/jdk/pull/11777 From qpzhang at openjdk.org Mon Jan 9 11:11:56 2023 From: qpzhang at openjdk.org (Patrick Zhang) Date: Mon, 9 Jan 2023 11:11:56 GMT Subject: Integrated: 8298472: AArch64: Detect Ampere-1 and Ampere-1A CPUs and set default options In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 08:27:28 GMT, Patrick Zhang wrote: > This patch is to add CPU detection for Ampere-1 and Ampere-1A and set -XX:+UseSIMDForMemoryOps by default. In addition, an `enum Ampere_CPU_Model ` got introduced in order to clearly describe all Ampere CPUs in `src/hotspot/cpu/aarch64/vm_version_aarch64.hpp`. > > Tests done: > 1. Jtreg tier1 sanity check on Ampere Altra AArch64 platforms, and Ampere-1 systems as well. No new issue found. > 4. GitHub Actions (GHA) sanity tests: https://github.com/cnqpzhang/jdk/actions/runs/3845722221 > 3. OpenJDK bundled JMH, `make run-test TEST="micro:java.lang.ArrayCopy*" `, SIMD vs NoSIMD ratios are mostly positive. For example, `java.lang.ArrayCopyAligned.testChar` with `-p length=600` showed +42% improvement on Ampere-1. > 2. Ran [JMH JDK Microbenchmarks](https://github.com/openjdk/jmh-jdk-microbenchmarks), ~1500 cases. No obvious perf regression found. > > Signed-off-by: Patrick Zhang This pull request has now been integrated. Changeset: 70684574 Author: Patrick Zhang Committer: Nick Gasson URL: https://git.openjdk.org/jdk/commit/706845743699efb01994e2d12c65023a3e972b77 Stats: 18 lines in 2 files changed: 15 ins; 0 del; 3 mod 8298472: AArch64: Detect Ampere-1 and Ampere-1A CPUs and set default options Reviewed-by: aph, ngasson ------------- PR: https://git.openjdk.org/jdk/pull/11878 From stefank at openjdk.org Mon Jan 9 13:24:52 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 9 Jan 2023 13:24:52 GMT Subject: RFR: 8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly [v3] In-Reply-To: References: Message-ID: On Mon, 2 Jan 2023 08:34:05 GMT, Axel Boldt-Christmas wrote: > Hmm. So we have IN_NATIVE accesses tagged as encode_in_native, and essentially AS_RAW accesses encoded as encode_non_barriered. I usually don't pick on naming, but the term "non-barriered" seems to stray away from already established terminology. I would prefer if the mentions of "non_barriered" changed to "as_raw" for consistency. The following is not blocking this review, but could maybe be a starting point for a future discussion: FWIW, I think that as_raw is doesn't explain "why" we are not using a normal IN_NATIVE access. Maybe that's also why Markus said: > What is "raw", compared to "native"? It's also an "AS" property and not an "IN" property, so it talks about "how" to perform the access and not what kind of root it is. I wanted to hint about what kind of root it was when I chose the name non-barriered. Taking a step back, ZGC deals with two categories of roots: 1) Roots that requires the normal GC barriers (OopStorage, Global JNI Handle) 2) Roots that requires an "externalized" GC barrier to be applied before the root is accessed (Threads, frames, nmethods) We use different terminology for these, like: a) colored vs uncolored roots b) barriered vs non-barriered (Maybe I'm the only one who is using these terms) (a) is ZGC centric, and (b) tries to be more generic. Neither of these are good names, but I think it would be beneficial to have good names for these. It would help explain why we can use "raw" access for the latter, and hopefully help the readability of the code. Maybe this is taking it too far, but if we have good names we could split IN_NATIVE into two, and tag each call site appropriately depending on root type. ------------- PR: https://git.openjdk.org/jdk/pull/11741 From stefank at openjdk.org Mon Jan 9 13:37:55 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 9 Jan 2023 13:37:55 GMT Subject: RFR: 8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly [v2] In-Reply-To: <-Vajigb2X8yHp76kYNFVh58pp8XgB0A04odj5KEIFFw=.d7b72d1c-024f-4747-9a45-f4e9656b2f6a@github.com> References: <-Vajigb2X8yHp76kYNFVh58pp8XgB0A04odj5KEIFFw=.d7b72d1c-024f-4747-9a45-f4e9656b2f6a@github.com> Message-ID: On Tue, 3 Jan 2023 14:28:07 GMT, Axel Boldt-Christmas wrote: >> src/hotspot/share/jfr/leakprofiler/utilities/unifiedOopRef.inline.hpp line 70: >> >>> 68: LP64_ONLY(assert(((reinterpret_cast(ref)) & (1ull << 63)) == 0, "Unexpected high-order bit")); >>> 69: UnifiedOopRef result = { (reinterpret_cast(ref) LP64_ONLY(<< 1)) | tag }; >>> 70: assert(result.addr() == ref, "sanity"); >> >> This is crazy hard to read. > > Yeah. Refactoring out `reinterpret_cast(ref)` into a variable might help a bit at least. The assert just want to check that the lowest two bits are not set (the tagging does not destroy information) and that on 64 bit platforms the highest bit is not set (the shift does not destroy information). > > Not sure if there is a better way to express those two invariants. Maybe it would be easier to read the code if it was rewritten as (uncompiled): uintptr_t value = reinterpret_cast(ref); #ifdef _LP64 // tag_mask is 3 bits. When ref is a narrowOop* we only have 2 alignment // bits, because of the 4 byte alignment of compressed oops addresses. // Shift up to make way for one more bit. assert((value & (1ull << 63)) == 0, "Unexpected high-order bit"); value <<= 1; #endif UnifiedOopRef result = { value | tag }; assert(result.addr() == ref, "sanity"); ------------- PR: https://git.openjdk.org/jdk/pull/11741 From eosterlund at openjdk.org Mon Jan 9 13:38:00 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 9 Jan 2023 13:38:00 GMT Subject: Integrated: 8299312: Clean up BarrierSetNMethod In-Reply-To: References: Message-ID: On Fri, 23 Dec 2022 12:00:46 GMT, Erik ?sterlund wrote: > The terminology in BarrierSetNMethod is not crisp. In platform code we talk about a per-nmethod "guard value", but on shared level we call the same value arm value or disarm value in different contexts. But it really depends on the value whether the nmethod is disarmed or armed. We should embrace the "guard value" terminology and lift it in to the shared code level. > We also have more functionality than we need on platform level. The platform level only needs to know how to deoptimize, and how to set/get the guard value of an nmethod. The more specific functionality should be moved to the shared code and be expressed in terms of said setter/getter. This pull request has now been integrated. Changeset: 4ba81221 Author: Erik ?sterlund URL: https://git.openjdk.org/jdk/commit/4ba8122197e912db4894ed7fe395a8842268fbef Stats: 175 lines in 29 files changed: 10 ins; 82 del; 83 mod 8299312: Clean up BarrierSetNMethod Reviewed-by: mdoerr, fyang ------------- PR: https://git.openjdk.org/jdk/pull/11774 From egahlin at openjdk.org Mon Jan 9 13:39:51 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Mon, 9 Jan 2023 13:39:51 GMT Subject: RFR: JDK-8299672: Enhance HeapDump JFR event In-Reply-To: References: Message-ID: On Thu, 5 Jan 2023 14:54:31 GMT, Matthias Baesken wrote: > Enhance the JFR Event HeapDump with the additional interesting fields, compression and overwrite. > Add some UL logging in case the heap dump writing failed . What's the rationale for adding compression level and overwrite? ------------- PR: https://git.openjdk.org/jdk/pull/11864 From stefank at openjdk.org Mon Jan 9 14:02:53 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 9 Jan 2023 14:02:53 GMT Subject: RFR: 8299089: Instrument global jni handles with tag to make them distinguishable In-Reply-To: References: Message-ID: <08il6G-2yWpaQNKy4IrH9V6Umo3BdTp9imPO7D7o4tU=.7fff3832-cf3a-4721-90c8-f3c83bf579ff@github.com> On Tue, 20 Dec 2022 11:44:33 GMT, Axel Boldt-Christmas wrote: > Weak global jni handles are tagged so the GC can distinguish them when resolving the object. Today there is no cheap way of distinguishing global jni handles from local jni handles. For generational ZGC the OopStorage handles and the thread local handles semantical difference requires the handles to be distinguishable. > > This enhancements instruments the jni handles with a global tag similarly to the jweak tag. > > Note: > * the s390 implementation has minimal changes and requires improvement. > * There is room for enchantment here to create the same abstraction that ppc uses for all platforms, i.e. move the resolve_jobject from the MacroAssembler to the BarrierSetAssembler which allows for more optimised code for GCs that can treat local and global handles the same. > > Testing: GHA. Oracle supported platforms tier1-3. Will run higher tiers. Has also been tested on the generational branch of ZGC for over three months. Requires testing on non Oracle platforms. Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11740 From stefank at openjdk.org Mon Jan 9 14:02:53 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 9 Jan 2023 14:02:53 GMT Subject: RFR: 8299089: Instrument global jni handles with tag to make them distinguishable In-Reply-To: References: Message-ID: <08il6G-2yWpaQNKy4IrH9V6Umo3BdTp9imPO7D7o4tU=.7fff3832-cf3a-4721-90c8-f3c83bf579ff@github.com> On Tue, 20 Dec 2022 11:44:33 GMT, Axel Boldt-Christmas wrote: > Weak global jni handles are tagged so the GC can distinguish them when resolving the object. Today there is no cheap way of distinguishing global jni handles from local jni handles. For generational ZGC the OopStorage handles and the thread local handles semantical difference requires the handles to be distinguishable. > > This enhancements instruments the jni handles with a global tag similarly to the jweak tag. > > Note: > * the s390 implementation has minimal changes and requires improvement. > * There is room for enchantment here to create the same abstraction that ppc uses for all platforms, i.e. move the resolve_jobject from the MacroAssembler to the BarrierSetAssembler which allows for more optimised code for GCs that can treat local and global handles the same. > > Testing: GHA. Oracle supported platforms tier1-3. Will run higher tiers. Has also been tested on the generational branch of ZGC for over three months. Requires testing on non Oracle platforms. Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11740 From aboldtch at openjdk.org Mon Jan 9 14:19:32 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 9 Jan 2023 14:19:32 GMT Subject: RFR: 8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly [v4] In-Reply-To: References: Message-ID: > In a similar vain to [JDK-8299089](https://bugs.openjdk.org/browse/JDK-8299089) there are different semantics for OopStorage and thread local oops. UnifiedOopRef in the jfr leakprofiler must be able to distinguish these and treat them appropriately. > > Testing: Running test at the moment. Has been running on the generational branch of ZGC for over three months. Not many tests exercise the leakprofiler. x86_32 has mostly been tested with GHA. > > Note: The accessBackend changes are only there to facilitate comparing OopLoadProxy objects directly with nullptr instead of creating and comparing with an `oop()` / `oop(NULL)`. Can be backed out of this PR and put in a different RFE instead. Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: stefank suggestion ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11741/files - new: https://git.openjdk.org/jdk/pull/11741/files/b82e8997..9d9637a2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11741&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11741&range=02-03 Stats: 12 lines in 1 file changed: 5 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/11741.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11741/head:pull/11741 PR: https://git.openjdk.org/jdk/pull/11741 From duke at openjdk.org Mon Jan 9 14:46:43 2023 From: duke at openjdk.org (Fredrik Bredberg) Date: Mon, 9 Jan 2023 14:46:43 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames Message-ID: Implementation of relativized locals in interpreter frames for x86. x64, aarch64, ppc64le, riscv. Not relativized zero and s390 but done some changes to cope with the changed generic code. Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu. ------------- Commit messages: - Changed copyright date to 2023 - 8299795: Relativize locals in interpreter frames Changes: https://git.openjdk.org/jdk/pull/11902/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11902&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299795 Stats: 227 lines in 40 files changed: 107 ins; 17 del; 103 mod Patch: https://git.openjdk.org/jdk/pull/11902.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11902/head:pull/11902 PR: https://git.openjdk.org/jdk/pull/11902 From redestad at openjdk.org Mon Jan 9 15:00:48 2023 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 9 Jan 2023 15:00:48 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v17] In-Reply-To: References: Message-ID: > Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. > > I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. > > Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. > > The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. > > With the most recent fixes the x64 intrinsic results on my workstation look like this: > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op > StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op > StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op > StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op > > Baseline: > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op > StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op > StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op > StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op > > I.e. no measurable overhead compared to baseline even for `size == 1`. > > The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. > > Benchmark for `Arrays.hashCode`: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op > ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op > ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op > ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op > ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op > ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op > ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op > ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op > ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op > ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op > ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op > ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op > ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op > ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op > ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op > ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op > > Baseline: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op > ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op > ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op > ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op > ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op > ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op > ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op > ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op > ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op > ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op > ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op > ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op > ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op > ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op > ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op > ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op > > > As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 68 commits: - Merge branch 'master' into 8282664-polyhash - Treat Op_VectorizedHashCode as other similar Ops in split_unique_types - Handle signed subword arrays, contributed by @sviswa7 - @sviswa7 comments - Pass the constant mode node through, removing need for all but one instruct declarations - FLAG_SET_DEFAULT - Merge branch 'master' into 8282664-polyhash - Merge branch 'master' into 8282664-polyhash - Missing & 0xff in StringLatin1::hashCode - Qualified guess on shenandoahSupport fix-up - ... and 58 more: https://git.openjdk.org/jdk/compare/66db0bb6...71297615 ------------- Changes: https://git.openjdk.org/jdk/pull/10847/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=16 Stats: 1052 lines in 33 files changed: 992 ins; 8 del; 52 mod Patch: https://git.openjdk.org/jdk/pull/10847.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10847/head:pull/10847 PR: https://git.openjdk.org/jdk/pull/10847 From coleenp at openjdk.org Mon Jan 9 15:02:01 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 9 Jan 2023 15:02:01 GMT Subject: RFR: 8299275: Add some ClassLoaderData verification code [v3] In-Reply-To: References: <1Adx9iDHr_fSF8l2AXfNF9Rzq5NpPwhqiJ2AxnorYRQ=.88805086-76f3-4839-80de-ad059f7304f7@github.com> Message-ID: <25QH8P1nIEmumNPwJ-jxlcrshdn3IrtVyzkCsbNHccg=.36d9112c-097f-401a-bfb6-a0bbae3598a3@github.com> On Fri, 6 Jan 2023 20:03:34 GMT, Coleen Phillimore wrote: >> I added some verification code to try to help track down JDK-8296915 (https://bugs.openjdk.org/browse/JDK-8296915). >> Ran Test: runtime/SelectionResolution/InvokeInterfaceSuccessTest.java 100x with -XX:+VerifyBefore/AfterGC. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision: > > - Fix some english. > - Walk other non-mirror oops in CLD::_handles area and add a comment why not mirrors. Thanks for the code reviews. ------------- PR: https://git.openjdk.org/jdk/pull/11856 From coleenp at openjdk.org Mon Jan 9 15:04:59 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 9 Jan 2023 15:04:59 GMT Subject: Integrated: 8299275: Add some ClassLoaderData verification code In-Reply-To: <1Adx9iDHr_fSF8l2AXfNF9Rzq5NpPwhqiJ2AxnorYRQ=.88805086-76f3-4839-80de-ad059f7304f7@github.com> References: <1Adx9iDHr_fSF8l2AXfNF9Rzq5NpPwhqiJ2AxnorYRQ=.88805086-76f3-4839-80de-ad059f7304f7@github.com> Message-ID: On Wed, 4 Jan 2023 23:05:36 GMT, Coleen Phillimore wrote: > I added some verification code to try to help track down JDK-8296915 (https://bugs.openjdk.org/browse/JDK-8296915). > Ran Test: runtime/SelectionResolution/InvokeInterfaceSuccessTest.java 100x with -XX:+VerifyBefore/AfterGC. > Tested with tier1-4. This pull request has now been integrated. Changeset: 17a3f0e2 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/17a3f0e2577f2f9eb3fe62a4b8261e3dbe4c3b28 Stats: 38 lines in 3 files changed: 32 ins; 1 del; 5 mod 8299275: Add some ClassLoaderData verification code Reviewed-by: iklam, fparain ------------- PR: https://git.openjdk.org/jdk/pull/11856 From stefank at openjdk.org Mon Jan 9 15:17:54 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 9 Jan 2023 15:17:54 GMT Subject: RFR: JDK-8299688: Adopt C++14 compatible std::bit_cast introduced in C++20 [v2] In-Reply-To: References: Message-ID: On Thu, 5 Jan 2023 19:59:40 GMT, Justin King wrote: >> Adopts a C++14 compatible implementation of [std::bit_cast](https://en.cppreference.com/w/cpp/numeric/bit_cast). >> >> `PrimitiveConversions::cast` is refactored into `bit_cast` and extended to support all compatible types. Additionally it makes use of `__builtin_bit_cast` when available, which is strictly well defined compared to fallback approaches which are sometimes lurking in undefined behavior territory. >> >> Lastly some legacy casting is updated to use `bit_cast` in `utilities/globalDefinitions.hpp`. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Apple Clang thinks __builtin_bit_cast is present when its not > > Signed-off-by: Justin King Leaving this review for Kim ... but saw a few nits that could be fixed in the meantime. src/hotspot/os_cpu/linux_ppc/atomic_linux_ppc.hpp line 35: > 33: #include "orderAccess_linux_ppc.hpp" > 34: #include "utilities/debug.hpp" > 35: #include "utilities/bitCast.hpp" Sort includes src/hotspot/os_cpu/windows_aarch64/atomic_windows_aarch64.hpp line 63: > 61: return bit_cast( \ > 62: IntrinsicName(reinterpret_cast(dest), \ > 63: bit_cast(add_value))); \ Could you realign the `` characters? The same comment applies to other places in this patch. ------------- PR: https://git.openjdk.org/jdk/pull/11865 From fjiang at openjdk.org Mon Jan 9 14:20:29 2023 From: fjiang at openjdk.org (Feilong Jiang) Date: Mon, 9 Jan 2023 14:20:29 GMT Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory API (Preview) [v2] In-Reply-To: References: Message-ID: > Add experimental Foreign Function & Memory API support for RISC-V. > > For details of the FFM API RISC-V port please refer to [JBS issue](https://bugs.openjdk.org/browse/JDK-8293841) > > Testing: > > - [x] jdk_foreign with release/fastdebug build > - [x] run TestMatrix.java manually with release/fastdebug build Feilong Jiang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8293841-foreign-api-riscv - code adjustment and remove unnecessary static - sync with JDK-8296477 - sync with JDK-8295044 - JDK-8293841: RISC-V: Implementation of Foreign Function & Memory API (Preview) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11004/files - new: https://git.openjdk.org/jdk/pull/11004/files/c155840c..efe8238e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11004&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11004&range=00-01 Stats: 6771 lines in 356 files changed: 3498 ins; 2172 del; 1101 mod Patch: https://git.openjdk.org/jdk/pull/11004.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11004/head:pull/11004 PR: https://git.openjdk.org/jdk/pull/11004 From jcking at openjdk.org Mon Jan 9 15:45:20 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 9 Jan 2023 15:45:20 GMT Subject: RFR: JDK-8299688: Adopt C++14 compatible std::bit_cast introduced in C++20 [v2] In-Reply-To: References: Message-ID: On Mon, 9 Jan 2023 15:09:59 GMT, Stefan Karlsson wrote: >> Justin King has updated the pull request incrementally with one additional commit since the last revision: >> >> Apple Clang thinks __builtin_bit_cast is present when its not >> >> Signed-off-by: Justin King > > src/hotspot/os_cpu/linux_ppc/atomic_linux_ppc.hpp line 35: > >> 33: #include "orderAccess_linux_ppc.hpp" >> 34: #include "utilities/debug.hpp" >> 35: #include "utilities/bitCast.hpp" > > Sort includes Done. > src/hotspot/os_cpu/windows_aarch64/atomic_windows_aarch64.hpp line 63: > >> 61: return bit_cast( \ >> 62: IntrinsicName(reinterpret_cast(dest), \ >> 63: bit_cast(add_value))); \ > > Could you realign the `` characters? The same comment applies to other places in this patch. Believe I got them all now. ------------- PR: https://git.openjdk.org/jdk/pull/11865 From jcking at openjdk.org Mon Jan 9 15:45:19 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 9 Jan 2023 15:45:19 GMT Subject: RFR: JDK-8299688: Adopt C++14 compatible std::bit_cast introduced in C++20 [v3] In-Reply-To: References: Message-ID: > Adopts a C++14 compatible implementation of [std::bit_cast](https://en.cppreference.com/w/cpp/numeric/bit_cast). > > `PrimitiveConversions::cast` is refactored into `bit_cast` and extended to support all compatible types. Additionally it makes use of `__builtin_bit_cast` when available, which is strictly well defined compared to fallback approaches which are sometimes lurking in undefined behavior territory. > > Lastly some legacy casting is updated to use `bit_cast` in `utilities/globalDefinitions.hpp`. Justin King has updated the pull request incrementally with one additional commit since the last revision: Sort includes and fix macro indentation Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11865/files - new: https://git.openjdk.org/jdk/pull/11865/files/281a915e..e5921255 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11865&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11865&range=01-02 Stats: 16 lines in 3 files changed: 1 ins; 1 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/11865.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11865/head:pull/11865 PR: https://git.openjdk.org/jdk/pull/11865 From fjiang at openjdk.org Mon Jan 9 15:09:12 2023 From: fjiang at openjdk.org (Feilong Jiang) Date: Mon, 9 Jan 2023 15:09:12 GMT Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory API (Preview) [v3] In-Reply-To: References: Message-ID: > Add experimental Foreign Function & Memory API support for RISC-V. > > For details of the FFM API RISC-V port please refer to [JBS issue](https://bugs.openjdk.org/browse/JDK-8293841) > > Testing: > > - [x] jdk_foreign with release/fastdebug build > - [x] run TestMatrix.java manually with release/fastdebug build Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision: fix build ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11004/files - new: https://git.openjdk.org/jdk/pull/11004/files/efe8238e..289b8697 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11004&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11004&range=01-02 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11004.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11004/head:pull/11004 PR: https://git.openjdk.org/jdk/pull/11004 From pchilanomate at openjdk.org Mon Jan 9 16:02:49 2023 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 9 Jan 2023 16:02:49 GMT Subject: [jdk20] RFR: 8294744: AArch64: applications/kitchensink/Kitchensink.java crashed: assert(oopDesc::is_oop(obj)) failed: not an oop [v3] In-Reply-To: References: Message-ID: <77y-PdPY4NpS3fbdtF4mkeqZzzBFMu0GCU9wO-atEnw=.eddf48e9-3557-438f-9e6c-0cca495ec354@github.com> > Please review the following patch. The value we set initially for extended_sp on natives frames doesn't account for the oop that could be pushed to the stack in case the method throws an exception. This can create a situation in Interpreter::_throw_exception_entry where we push an exception oop to the Java expression stack below the actual physical stack pointer. When JFR is present though a JavaThread could receive a suspend signal right after that push. On Linux aarch64, because there is no red zone defined (nor implemented it seems), the pushed oop gets overwritten during the setup and execution of the signal handler. This later leads to a crash when popping the oop back and rethrowing in the caller of the native method. There are more details in the bug comments. > > To fix it I used the same technique we use for normal Java frames, i.e. add extra space to extended_sp when creating the frame to account for the max space needed. > > > > I tested the patch by running Kitchensink.java around 150 times on mach5 with no failures (without the patch 50 runs would already show ~10 failures on average). I also run tiers1-6 for sanity check. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: add fix for riscv ------------- Changes: - all: https://git.openjdk.org/jdk20/pull/85/files - new: https://git.openjdk.org/jdk20/pull/85/files/2aeadb14..2e2f1070 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk20&pr=85&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=85&range=01-02 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk20/pull/85.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/85/head:pull/85 PR: https://git.openjdk.org/jdk20/pull/85 From pchilanomate at openjdk.org Mon Jan 9 16:02:53 2023 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 9 Jan 2023 16:02:53 GMT Subject: [jdk20] RFR: 8294744: AArch64: applications/kitchensink/Kitchensink.java crashed: assert(oopDesc::is_oop(obj)) failed: not an oop [v2] In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 15:25:30 GMT, Patricio Chilano Mateo wrote: >> Please review the following patch. The value we set initially for extended_sp on natives frames doesn't account for the oop that could be pushed to the stack in case the method throws an exception. This can create a situation in Interpreter::_throw_exception_entry where we push an exception oop to the Java expression stack below the actual physical stack pointer. When JFR is present though a JavaThread could receive a suspend signal right after that push. On Linux aarch64, because there is no red zone defined (nor implemented it seems), the pushed oop gets overwritten during the setup and execution of the signal handler. This later leads to a crash when popping the oop back and rethrowing in the caller of the native method. There are more details in the bug comments. >> >> To fix it I used the same technique we use for normal Java frames, i.e. add extra space to extended_sp when creating the frame to account for the max space needed. >> >> >> >> I tested the patch by running Kitchensink.java around 150 times on mach5 with no failures (without the patch 50 runs would already show ~10 failures on average). I also run tiers1-6 for sanity check. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into JDK-8294744 > - v1 > Looks good to me. JVM on linux-riscv64 bears the same problem as it has the same code flow as aarch64 on this part [1][2]. And linux-riscv64 doesn't have a redzone defined/implemented either, which I have verified with a small C program with inline assembly like you do for x86 and aarch64. So I have prepared a fix for linux-riscv64. This has passed sanity tests on HiFive Unmatched. Could you please add this change while you are on it? > > ``` > diff --git a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp > index 49a2b87c232..213e360c20e 100644 > --- a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp > +++ b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp > @@ -776,8 +776,12 @@ void TemplateInterpreterGenerator::generate_fixed_frame(bool native_call) { > // Move SP out of the way > __ mv(sp, t0); > } else { > - __ sd(sp, Address(sp, 5 * wordSize)); > + // Make sure there is room for the exception oop pushed in case method throws > + // an exception (see TemplateInterpreterGenerator::generate_throw_exception()) > + __ sub(t0, sp, 2 * wordSize); > + __ sd(t0, Address(sp, 5 * wordSize)); > __ sd(zr, Address(sp, 4 * wordSize)); > + __ mv(sp, t0); > } > } > ``` > > [1] https://bugs.openjdk.org/browse/JDK-8290280 [2] [openjdk/jdk at 4dd236b](https://github.com/openjdk/jdk/commit/4dd236b40abfeb1200e884021b90226046bc4b85) > Sure, added. ------------- PR: https://git.openjdk.org/jdk20/pull/85 From redestad at openjdk.org Mon Jan 9 15:23:58 2023 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 9 Jan 2023 15:23:58 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v13] In-Reply-To: References: <6lAQI6kDDTGbskylHcWReX8ExaB6qkwgqoai7E6ikZY=.8a69a63c-453d-4bbd-8c76-4d477bfb77fe@github.com> Message-ID: On Thu, 22 Dec 2022 13:10:02 GMT, Claes Redestad wrote: >> @cl4es Thanks for passing the constant node through, the code looks much cleaner now. The attached patch should handle the signed bytes/shorts as well. Please take a look. >> [signed.patch](https://github.com/openjdk/jdk/files/10273480/signed.patch) > > I ran tests and some quick microbenchmarking to validate @sviswa7's patch to activate vectorization for `short` and `byte` arrays and it looks good: > > Before: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 10000 avgt 5 7845.586 ? 23.440 ns/op > ArraysHashCode.chars 10000 avgt 5 1203.163 ? 11.995 ns/op > ArraysHashCode.ints 10000 avgt 5 1131.915 ? 7.843 ns/op > ArraysHashCode.multibytes 10000 avgt 5 4136.487 ? 5.790 ns/op > ArraysHashCode.multichars 10000 avgt 5 671.328 ? 17.629 ns/op > ArraysHashCode.multiints 10000 avgt 5 699.051 ? 8.135 ns/op > ArraysHashCode.multishorts 10000 avgt 5 4139.300 ? 10.633 ns/op > ArraysHashCode.shorts 10000 avgt 5 7844.019 ? 26.071 ns/op > > > After: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 10000 avgt 5 1193.208 ? 1.965 ns/op > ArraysHashCode.chars 10000 avgt 5 1193.311 ? 5.941 ns/op > ArraysHashCode.ints 10000 avgt 5 1132.592 ? 10.410 ns/op > ArraysHashCode.multibytes 10000 avgt 5 657.343 ? 25.343 ns/op > ArraysHashCode.multichars 10000 avgt 5 672.668 ? 5.229 ns/op > ArraysHashCode.multiints 10000 avgt 5 697.143 ? 3.929 ns/op > ArraysHashCode.multishorts 10000 avgt 5 666.738 ? 12.236 ns/op > ArraysHashCode.shorts 10000 avgt 5 1193.563 ? 5.449 ns/op > @cl4es There seem to be failure on windows-x64 platform pre submit tests. Could you please take a look? It looks like the `as_Address(ExternalAddress(StubRoutines::x86::arrays_hashcode_powers_of_31() + ...)` trick is running into some reachability issue on Windows, hitting the `assert(reachable(adr), "must be");` in `macroAssembler_x86.cpp`. Might be related to ASLR or some quirk of the VS compiler. I'll investigate. ------------- PR: https://git.openjdk.org/jdk/pull/10847 From fyang at openjdk.org Mon Jan 9 16:43:02 2023 From: fyang at openjdk.org (Fei Yang) Date: Mon, 9 Jan 2023 16:43:02 GMT Subject: [jdk20] RFR: 8294744: AArch64: applications/kitchensink/Kitchensink.java crashed: assert(oopDesc::is_oop(obj)) failed: not an oop [v3] In-Reply-To: <77y-PdPY4NpS3fbdtF4mkeqZzzBFMu0GCU9wO-atEnw=.eddf48e9-3557-438f-9e6c-0cca495ec354@github.com> References: <77y-PdPY4NpS3fbdtF4mkeqZzzBFMu0GCU9wO-atEnw=.eddf48e9-3557-438f-9e6c-0cca495ec354@github.com> Message-ID: On Mon, 9 Jan 2023 16:02:49 GMT, Patricio Chilano Mateo wrote: >> Please review the following patch. The value we set initially for extended_sp on natives frames doesn't account for the oop that could be pushed to the stack in case the method throws an exception. This can create a situation in Interpreter::_throw_exception_entry where we push an exception oop to the Java expression stack below the actual physical stack pointer. When JFR is present though a JavaThread could receive a suspend signal right after that push. On Linux aarch64, because there is no red zone defined (nor implemented it seems), the pushed oop gets overwritten during the setup and execution of the signal handler. This later leads to a crash when popping the oop back and rethrowing in the caller of the native method. There are more details in the bug comments. >> >> To fix it I used the same technique we use for normal Java frames, i.e. add extra space to extended_sp when creating the frame to account for the max space needed. >> >> >> >> I tested the patch by running Kitchensink.java around 150 times on mach5 with no failures (without the patch 50 runs would already show ~10 failures on average). I also run tiers1-6 for sanity check. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > add fix for riscv Marked as reviewed by fyang (Reviewer). ------------- PR: https://git.openjdk.org/jdk20/pull/85 From redestad at openjdk.org Mon Jan 9 16:49:25 2023 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 9 Jan 2023 16:49:25 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v18] In-Reply-To: References: Message-ID: > Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. > > I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. > > Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. > > The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. > > With the most recent fixes the x64 intrinsic results on my workstation look like this: > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op > StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op > StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op > StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op > > Baseline: > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op > StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op > StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op > StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op > > I.e. no measurable overhead compared to baseline even for `size == 1`. > > The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. > > Benchmark for `Arrays.hashCode`: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op > ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op > ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op > ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op > ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op > ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op > ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op > ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op > ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op > ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op > ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op > ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op > ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op > ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op > ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op > ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op > > Baseline: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op > ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op > ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op > ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op > ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op > ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op > ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op > ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op > ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op > ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op > ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op > ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op > ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op > ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op > ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op > ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op > > > As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Explicitly lea external address ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10847/files - new: https://git.openjdk.org/jdk/pull/10847/files/71297615..c8c58f4a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=16-17 Stats: 11 lines in 1 file changed: 6 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10847.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10847/head:pull/10847 PR: https://git.openjdk.org/jdk/pull/10847 From daniel.daugherty at oracle.com Mon Jan 9 18:30:36 2023 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Mon, 9 Jan 2023 13:30:36 -0500 Subject: CFV: New hotspot Group Member: Ron Pressler In-Reply-To: References: Message-ID: <96499a01-e68b-bf5f-2a15-31adca686c6e@oracle.com> Vote: yes Dan On 1/3/23 11:11 AM, coleen.phillimore at oracle.com wrote: > Correcting email address. > > > -------- Forwarded Message -------- > Subject: CFV: New hotspot Group Member: Ron Pressler > Date: Tue, 3 Jan 2023 11:06:16 -0500 > From: coleen.phillimore at oracle.com > To: hotspot-dev at openjdk.java.net > > > > I hereby nominate Ron Pressler [rpressler] to Membership in the > hotspot Group. > > Ron Pressler is the lead for the Loom project [1] and is a committer > on the JDK project, including the major contribution of? JEP 425: > Virtual Threads. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#loom > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpb at openjdk.org Mon Jan 9 19:29:58 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 9 Jan 2023 19:29:58 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v4] In-Reply-To: References: <4y4hWpgTAz89OygAA5LAjIfEeAP7OEyDbQHWO9DceA0=.5a6e4061-4d08-40cf-a90c-12d1af36bd7d@github.com> <6XtN6Ds03G9CeeL2_eUjbtlAi3NSq-pL6-o9zXRJSzI=.fca79da0-0e2f-44ae-8900-3639ab9a0f5c@github.com> Message-ID: On Thu, 5 Jan 2023 23:27:34 GMT, Paul Sandoz wrote: >>> I think we should mention the source, that the capacity value originates from a native call to NewDirectByteBuffer [...] >> >> So you mean in the IAE message itself? > > Yes, enhance the message with more detail Fixed in a9e44d62414d6d241b523edd3350103bcafac5cc. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From ayang at openjdk.org Mon Jan 9 19:31:51 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 9 Jan 2023 19:31:51 GMT Subject: RFR: 8299089: Instrument global jni handles with tag to make them distinguishable In-Reply-To: References: Message-ID: On Tue, 20 Dec 2022 11:44:33 GMT, Axel Boldt-Christmas wrote: > Weak global jni handles are tagged so the GC can distinguish them when resolving the object. Today there is no cheap way of distinguishing global jni handles from local jni handles. For generational ZGC the OopStorage handles and the thread local handles semantical difference requires the handles to be distinguishable. > > This enhancements instruments the jni handles with a global tag similarly to the jweak tag. > > Note: > * the s390 implementation has minimal changes and requires improvement. > * There is room for enchantment here to create the same abstraction that ppc uses for all platforms, i.e. move the resolve_jobject from the MacroAssembler to the BarrierSetAssembler which allows for more optimised code for GCs that can treat local and global handles the same. > > Testing: GHA. Oracle supported platforms tier1-3. Will run higher tiers. Has also been tested on the generational branch of ZGC for over three months. Requires testing on non Oracle platforms. src/hotspot/share/runtime/jniHandles.cpp line 250: > 248: bool JNIHandles::is_global_handle(jobject handle) { > 249: assert(handle != NULL, "precondition"); > 250: return is_global_tagged(handle) && !is_jweak_tagged(handle) && is_storage_handle(global_handles(), global_ptr(handle)); Can a handle be both global and jweak tagged? Can a non-global ref be global-tagged? Seems to me the `is_global_tagged` check alone is enough here. ------------- PR: https://git.openjdk.org/jdk/pull/11740 From daniel.daugherty at oracle.com Mon Jan 9 19:57:00 2023 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Mon, 9 Jan 2023 14:57:00 -0500 Subject: CFV: New OpenJDK hotspot Group Member: Robbin Ehn In-Reply-To: <7652c110-0767-bf12-dd32-8cde03ba6fc7@oracle.com> References: <7652c110-0767-bf12-dd32-8cde03ba6fc7@oracle.com> Message-ID: <1ab76d95-4f75-c05d-0715-460a7ce2beba@oracle.com> Vote: yes Dan On 1/3/23 11:18 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate Robbin Ehn [rehn] to Membership in the hotspot Group. > > Robbin Ehn is an OpenJDK Reviewer and a member of the HotSpot runtime > team at Oracle.? He has contributed a concurrent hash table, > synchronization performance improvements and bug fixes to the HotSpot > code base. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vote > > From daniel.daugherty at oracle.com Mon Jan 9 19:59:32 2023 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Mon, 9 Jan 2023 14:59:32 -0500 Subject: CFV: New OpenJDK hotspot Group Member: Patricio Chilano Mateo In-Reply-To: References: Message-ID: <2ebf17d2-6ef6-1e6a-8c8b-218cbb0d593d@oracle.com> Vote: yes Dan On 1/3/23 11:20 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo [pchilomate] to Membership in > the hotspot Group. > > Patricio is an OpenJDK Reviewer and a member of the HotSpot runtime > team at Oracle. Since 2018 he has worked on improvements and bug fixes > mainly in the areas of locking, safepoint synchronization, thread > state transitions, and handshakes. He is currently working on Loom > changes for virtual thread preemption. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vote > > From ccheung at openjdk.org Mon Jan 9 19:59:44 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Mon, 9 Jan 2023 19:59:44 GMT Subject: RFR: 8298321: 2 File Leak defect groups in 2 files Message-ID: Please review this simple change for fixing two file leak warnings: 1) DirectivesParser::parse_from_file_inner() in open/src/hotspot/share/compiler/directivesParser.cpp 2) mmap_attach_shared() in open/src/hotspot/os/posix/perfMemory_posix.cpp Please refer to the [comment](https://bugs.openjdk.org/browse/JDK-8298321?focusedCommentId=14549361&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14549361) in the bug report for details. Passed tiers 1 and 2 testing. ------------- Commit messages: - 8298321: 2 File Leak defect groups in 2 files Changes: https://git.openjdk.org/jdk/pull/11909/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11909&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298321 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11909.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11909/head:pull/11909 PR: https://git.openjdk.org/jdk/pull/11909 From daniel.daugherty at oracle.com Mon Jan 9 20:01:38 2023 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Mon, 9 Jan 2023 15:01:38 -0500 Subject: CFV: New OpenJDK hotspot Group Member: Lois Foltan In-Reply-To: References: Message-ID: Vote: yes Dan On 1/3/23 11:22 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate Lois Foltan [lfoltan] to Membership in the hotspot > Group. > > Lois is an OpenJDK Reviewer and a member of the HotSpot runtime team > at Oracle. She contributed the VM support for the Module subsystem JSR > 294, semantic changes in HotSpot for default methods, cleanups for > signature processing, Condy support, and many bug fixes. Lois is now > an engineering manager for the runtime team. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vot From daniel.daugherty at oracle.com Mon Jan 9 20:03:23 2023 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Mon, 9 Jan 2023 15:03:23 -0500 Subject: CFV: New OpenJDK hotspot Group Member: Frederic Parain In-Reply-To: <175ece63-eb89-ba46-52aa-270762e122c2@oracle.com> References: <175ece63-eb89-ba46-52aa-270762e122c2@oracle.com> Message-ID: <1bba8ea6-61f3-6c11-c533-6d86cbdddf51@oracle.com> Vote: yes Dan On 1/3/23 11:26 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate Frederic Parain [fparain] to Membership in the > hotspot Group. > > Frederic is an OpenJDK Committer and a member of the HotSpot runtime > team at Oracle. He is an active contributor to the valhalla project > [1], implementing programming models in the HotSpot code. He is also a > contributor to OpenJDK since 2010, working on serviceability code, > implementing the diagnostic commands framework, and rewriting Java > field layout code. He is currently working on compressing c2 frames in > the Loom project, and making the VM internal representation of fields > extensible for valhalla support. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#valhalla > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > From daniel.daugherty at oracle.com Mon Jan 9 20:04:00 2023 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Mon, 9 Jan 2023 15:04:00 -0500 Subject: CFV: New OpenJDK hotspot Group Member: Serguei Spitsyn In-Reply-To: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> References: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> Message-ID: <922316d0-faa1-271c-0e40-d177596d633b@oracle.com> Vote: yes Dan On 1/3/23 11:27 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate Serguei Spitsyn [sspitsyn] to Membership in the > hotspot Group. > > Serguei is an OpenJDK reviewer and a member of the HotSpot > serviceability team at Oracle.? He is lead for the serviceability > project [1] and a technical lead in HotSpot. He has recently > implemented JVMTI support for the Loom project.? He is already member > of the OpenJDK members group. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#serviceability > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > From martin.doerr at sap.com Mon Jan 9 20:13:14 2023 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 9 Jan 2023 20:13:14 +0000 Subject: AW: CFV: New OpenJDK hotspot Group Member: Serguei Spitsyn In-Reply-To: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> References: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> Message-ID: Vote: yes Best regards, Martin Von: hotspot-dev im Auftrag von coleen.phillimore at oracle.com Datum: Dienstag, 3. Januar 2023 um 17:27 An: hotspot-dev at openjdk.org Betreff: CFV: New OpenJDK hotspot Group Member: Serguei Spitsyn I hereby nominate Serguei Spitsyn [sspitsyn] to Membership in the hotspot Group. Serguei is an OpenJDK reviewer and a member of the HotSpot serviceability team at Oracle. He is lead for the serviceability project [1] and a technical lead in HotSpot. He has recently implemented JVMTI support for the Loom project. He is already member of the OpenJDK members group. Votes are due by January 17, 2023. Only current Members of the hotspot Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Coleen Phillimore [1] https://openjdk.org/census#serviceability [2] https://openjdk.org/census#hotspot [3] https://openjdk.org/groups/#member-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From vlivanov at openjdk.org Mon Jan 9 20:38:54 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 9 Jan 2023 20:38:54 GMT Subject: RFR: 8298321: 2 File Leak defect groups in 2 files In-Reply-To: References: Message-ID: <0SHxfzBPDAO5XortLBnbAWBKzL7wPAj5bY2xMyG9cdU=.ec5e8469-d421-4a3f-adb4-bf5c454dc687@github.com> On Mon, 9 Jan 2023 19:34:55 GMT, Calvin Cheung wrote: > Please review this simple change for fixing two file leak warnings: > 1) DirectivesParser::parse_from_file_inner() in open/src/hotspot/share/compiler/directivesParser.cpp > 2) mmap_attach_shared() in open/src/hotspot/os/posix/perfMemory_posix.cpp > > Please refer to the [comment](https://bugs.openjdk.org/browse/JDK-8298321?focusedCommentId=14549361&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14549361) in the bug report for details. > > Passed tiers 1 and 2 testing. Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.org/jdk/pull/11909 From jesper.wilhelmsson at oracle.com Mon Jan 9 22:29:59 2023 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 9 Jan 2023 22:29:59 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Patricio Chilano Mateo In-Reply-To: References: Message-ID: Vote: Yes /Jesper > On 3 Jan 2023, at 17:20, coleen.phillimore at oracle.com wrote: > > I hereby nominate Patricio Chilano Mateo [pchilomate] to Membership in the hotspot Group. > > Patricio is an OpenJDK Reviewer and a member of the HotSpot runtime team at Oracle. Since 2018 he has worked on improvements and bug fixes mainly in the areas of locking, safepoint synchronization, thread state transitions, and handshakes. He is currently working on Loom changes for virtual thread preemption. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vote > > -------------- 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 jesper.wilhelmsson at oracle.com Mon Jan 9 22:30:18 2023 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 9 Jan 2023 22:30:18 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Lois Foltan In-Reply-To: References: Message-ID: <3E540915-3396-4CDA-90F4-CD61E7E7CDF3@oracle.com> Vote: Yes /Jesper > On 3 Jan 2023, at 17:22, coleen.phillimore at oracle.com wrote: > > I hereby nominate Lois Foltan [lfoltan] to Membership in the hotspot Group. > > Lois is an OpenJDK Reviewer and a member of the HotSpot runtime team at Oracle. She contributed the VM support for the Module subsystem JSR 294, semantic changes in HotSpot for default methods, cleanups for signature processing, Condy support, and many bug fixes. Lois is now an engineering manager for the runtime team. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vot -------------- 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 jesper.wilhelmsson at oracle.com Mon Jan 9 22:31:28 2023 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 9 Jan 2023 22:31:28 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Frederic Parain In-Reply-To: <175ece63-eb89-ba46-52aa-270762e122c2@oracle.com> References: <175ece63-eb89-ba46-52aa-270762e122c2@oracle.com> Message-ID: <5C13A2B9-61C6-478F-914A-4888942203BA@oracle.com> Vote: Yes /Jesper > On 3 Jan 2023, at 17:26, coleen.phillimore at oracle.com wrote: > > I hereby nominate Frederic Parain [fparain] to Membership in the hotspot Group. > > Frederic is an OpenJDK Committer and a member of the HotSpot runtime team at Oracle. He is an active contributor to the valhalla project [1], implementing programming models in the HotSpot code. He is also a contributor to OpenJDK since 2010, working on serviceability code, implementing the diagnostic commands framework, and rewriting Java field layout code. He is currently working on compressing c2 frames in the Loom project, and making the VM internal representation of fields extensible for valhalla support. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#valhalla > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > -------------- 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 jesper.wilhelmsson at oracle.com Mon Jan 9 22:32:11 2023 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 9 Jan 2023 22:32:11 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Serguei Spitsyn In-Reply-To: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> References: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> Message-ID: Vote: Yes /Jesper > On 3 Jan 2023, at 17:27, coleen.phillimore at oracle.com wrote: > > I hereby nominate Serguei Spitsyn [sspitsyn] to Membership in the hotspot Group. > > Serguei is an OpenJDK reviewer and a member of the HotSpot serviceability team at Oracle. He is lead for the serviceability project [1] and a technical lead in HotSpot. He has recently implemented JVMTI support for the Loom project. He is already member of the OpenJDK members group. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#serviceability > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > -------------- 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 jesper.wilhelmsson at oracle.com Mon Jan 9 22:35:04 2023 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 9 Jan 2023 22:35:04 +0000 Subject: CFV: New hotspot Group Member: Ron Pressler In-Reply-To: References: Message-ID: <8BD7441E-9DCC-4207-A26D-E410D400205E@oracle.com> Vote: Yes /Jesper > On 3 Jan 2023, at 17:11, coleen.phillimore at oracle.com wrote: > > Correcting email address. > > > -------- Forwarded Message -------- > Subject: CFV: New hotspot Group Member: Ron Pressler > Date: Tue, 3 Jan 2023 11:06:16 -0500 > From: coleen.phillimore at oracle.com > To: hotspot-dev at openjdk.java.net > > I hereby nominate Ron Pressler [rpressler] to Membership in the hotspot Group. > > Ron Pressler is the lead for the Loom project [1] and is a committer on the JDK project, including the major contribution of JEP 425: Virtual Threads. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#loom > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- 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 jesper.wilhelmsson at oracle.com Mon Jan 9 22:28:43 2023 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 9 Jan 2023 22:28:43 +0000 Subject: CFV: New OpenJDK hotspot Group Member: Robbin Ehn In-Reply-To: <7652c110-0767-bf12-dd32-8cde03ba6fc7@oracle.com> References: <7652c110-0767-bf12-dd32-8cde03ba6fc7@oracle.com> Message-ID: Vote: Yes /Jesper > On 3 Jan 2023, at 17:18, coleen.phillimore at oracle.com wrote: > > I hereby nominate Robbin Ehn [rehn] to Membership in the hotspot Group. > > Robbin Ehn is an OpenJDK Reviewer and a member of the HotSpot runtime team at Oracle. He has contributed a concurrent hash table, synchronization performance improvements and bug fixes to the HotSpot code base. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vote > > -------------- 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 ccheung at openjdk.org Mon Jan 9 23:08:39 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Mon, 9 Jan 2023 23:08:39 GMT Subject: RFR: 8298321: 2 File Leak defect groups in 2 files [v2] In-Reply-To: References: Message-ID: > Please review this simple change for fixing two file leak warnings: > 1) DirectivesParser::parse_from_file_inner() in open/src/hotspot/share/compiler/directivesParser.cpp > 2) mmap_attach_shared() in open/src/hotspot/os/posix/perfMemory_posix.cpp > > Please refer to the [comment](https://bugs.openjdk.org/browse/JDK-8298321?focusedCommentId=14549361&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14549361) in the bug report for details. > > Passed tiers 1 and 2 testing. Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: add an assert in perfMemory_posix.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11909/files - new: https://git.openjdk.org/jdk/pull/11909/files/754a8870..6faa5e98 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11909&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11909&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11909.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11909/head:pull/11909 PR: https://git.openjdk.org/jdk/pull/11909 From bpb at openjdk.org Mon Jan 9 23:14:56 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 9 Jan 2023 23:14:56 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v4] In-Reply-To: References: Message-ID: On Mon, 9 Jan 2023 05:40:57 GMT, David Holmes wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8299684: Add test for out of range capacity passed to NewDirectBuffer > > make/test/JtregNativeJdk.gmk line 81: > >> 79: >> 80: BUILD_JDK_JTREG_LIBRARIES_LIBS_libTracePinnedThreads := jvm.lib >> 81: BUILD_JDK_JTREG_LIBRARIES_LIBS_libNewDirectByteBuffer := -ljava -lc > > This is not correct for Windows Do you have a suggestion? ------------- PR: https://git.openjdk.org/jdk/pull/11873 From iklam at openjdk.org Mon Jan 9 23:16:54 2023 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 9 Jan 2023 23:16:54 GMT Subject: RFR: 8298321: 2 File Leak defect groups in 2 files [v2] In-Reply-To: References: Message-ID: On Mon, 9 Jan 2023 23:08:39 GMT, Calvin Cheung wrote: >> Please review this simple change for fixing two file leak warnings: >> 1) DirectivesParser::parse_from_file_inner() in open/src/hotspot/share/compiler/directivesParser.cpp >> 2) mmap_attach_shared() in open/src/hotspot/os/posix/perfMemory_posix.cpp >> >> Please refer to the [comment](https://bugs.openjdk.org/browse/JDK-8298321?focusedCommentId=14549361&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14549361) in the bug report for details. >> >> Passed tiers 1 and 2 testing. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > add an assert in perfMemory_posix.cpp src/hotspot/os/posix/perfMemory_posix.cpp line 1211: > 1209: return; > 1210: } > 1211: assert(!HAS_PENDING_EXCEPTION, "must be"); I think this is better, so you don't need to read the rather convoluted code in open_sharedmem_file() to understand what the API contract is. if (HAS_PENDING_EXCEPTION) { assert(fd == OS_ERR, "open_sharedmem_file always returns OS_ERR on exceptions"); } if (fd == OS_ERR) { return; } ------------- PR: https://git.openjdk.org/jdk/pull/11909 From redestad at openjdk.org Mon Jan 9 23:17:00 2023 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 9 Jan 2023 23:17:00 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v18] In-Reply-To: References: Message-ID: On Mon, 9 Jan 2023 16:49:25 GMT, Claes Redestad wrote: >> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. >> >> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. >> >> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. >> >> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. >> >> With the most recent fixes the x64 intrinsic results on my workstation look like this: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op >> >> I.e. no measurable overhead compared to baseline even for `size == 1`. >> >> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. >> >> Benchmark for `Arrays.hashCode`: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op >> ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op >> ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op >> ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op >> ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op >> ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op >> ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op >> ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op >> ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op >> ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op >> ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op >> ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op >> ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op >> ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op >> ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op >> ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op >> ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op >> ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op >> ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op >> ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op >> ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op >> ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op >> ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op >> ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op >> ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op >> >> >> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Explicitly lea external address Explicitly loading the address to a register seems to do the trick, avoiding the pitfalls of `as_Address(AddressLiteral)` - which apparently only works (portably) when we know for certain the address is in some allowed range. There's no measurable difference on microbenchmarks (there might be a couple of extra lea instructions on the vectorized paths, but that disappears in the noise). Thanks @fisk for the suggestion! ------------- PR: https://git.openjdk.org/jdk/pull/10847 From sspitsyn at openjdk.org Mon Jan 9 23:17:55 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 9 Jan 2023 23:17:55 GMT Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324 [v2] In-Reply-To: References: Message-ID: <55O_xJx412kcO8MhN5FF7iKHxHsh-aDVyNicIi7oeHM=.9d261cd0-7d22-4931-8c7f-e1fee9d4a4a4@github.com> On Wed, 23 Nov 2022 10:14:23 GMT, Serguei Spitsyn wrote: >> This problem has two sides. >> One is that the `VirtualThread::run() `cashes the field `notifyJvmtiEvents` value. >> It caused the native method `notifyJvmtiUnmountBegin()` not called after the field `notifyJvmtiEvents` >> value has been set to `true` when an agent library is loaded into running VM. >> The fix is to get rid of this cashing. >> Another is that enabling `notifyJvmtiEvents` notifications needs a synchronization. >> Otherwise, a VTMS transition start can be missed which will cause some asserts to fire. >> The fix is to use a JvmtiVTMSTransitionDisabler helper for sync. >> >> Testing: >> The originally failed tests are passed now: >> >> runtime/vthread/RedefineClass.java >> runtime/vthread/TestObjectAllocationSampleEvent.java >> >> In progress: >> Run the tiers 1-6 to make sure there are no regression. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > remove caching if notifyJvmtiEvents in yieldContinuation One more artificial comment to keep the PR alive. ------------- PR: https://git.openjdk.org/jdk/pull/11304 From sviswanathan at openjdk.org Tue Jan 10 00:28:58 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 10 Jan 2023 00:28:58 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v18] In-Reply-To: References: Message-ID: On Mon, 9 Jan 2023 23:13:29 GMT, Claes Redestad wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Explicitly lea external address > > Explicitly loading the address to a register seems to do the trick, avoiding the pitfalls of `as_Address(AddressLiteral)` - which apparently only works (portably) when we know for certain the address is in some allowed range. There's no measurable difference on microbenchmarks (there might be a couple of extra lea instructions on the vectorized paths, but that disappears in the noise). Thanks @fisk for the suggestion! Thanks @cl4es for fixing this issue. Changes look good to me. ------------- PR: https://git.openjdk.org/jdk/pull/10847 From ccheung at openjdk.org Tue Jan 10 00:49:59 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Tue, 10 Jan 2023 00:49:59 GMT Subject: RFR: 8298321: 2 File Leak defect groups in 2 files [v3] In-Reply-To: References: Message-ID: > Please review this simple change for fixing two file leak warnings: > 1) DirectivesParser::parse_from_file_inner() in open/src/hotspot/share/compiler/directivesParser.cpp > 2) mmap_attach_shared() in open/src/hotspot/os/posix/perfMemory_posix.cpp > > Please refer to the [comment](https://bugs.openjdk.org/browse/JDK-8298321?focusedCommentId=14549361&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14549361) in the bug report for details. > > Passed tiers 1 and 2 testing. Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: @iklam comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11909/files - new: https://git.openjdk.org/jdk/pull/11909/files/6faa5e98..56980b79 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11909&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11909&range=01-02 Stats: 4 lines in 1 file changed: 3 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11909.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11909/head:pull/11909 PR: https://git.openjdk.org/jdk/pull/11909 From kbarrett at openjdk.org Tue Jan 10 02:02:55 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 10 Jan 2023 02:02:55 GMT Subject: RFR: 8299032: Interface IN_NATIVE oop stores for C2 In-Reply-To: <61HZ-hCw_ZoDZCtsDLsz-tfPE6S7Ox_1nXApLQnZ1SU=.60c813cf-a5d8-4a3c-a2a1-86d7af05d042@github.com> References: <61HZ-hCw_ZoDZCtsDLsz-tfPE6S7Ox_1nXApLQnZ1SU=.60c813cf-a5d8-4a3c-a2a1-86d7af05d042@github.com> Message-ID: On Fri, 23 Dec 2022 13:54:44 GMT, Erik ?sterlund wrote: > Loom added the first IN_NATIVE oop store to C2 code, when switching the current virtual thread of a platform thread. Instead of interfacing this properly, a raw store was used. But a future GC algorithm, such as generational ZGC, might not work well with raw stores. We should add support to the access API for this. Looks like Shenandoah was already missing something here as they do concurrent root processing requiring SATB barriers on IN_NATIVE oop stores. It is not in the scope of this PR to fix the Shenandoah bug - someone working on Shenandoah should do this. This PR merely adds an interface such that GCs that need to do something different here, can do that. Serial, Parallel and G1 don't need to do anything for IN_NATIVE stores as they do STW root processing. ZGC doesn't (yet) have store barriers at all, and hence doesn't need to do anything special either. Not a review, since I'm not sufficiently knowledgeable about C2 to really do justice to it. Rather, a couple questions/comments. We made a concerted effort to reduce/eliminate oops in native storage, instead using OopStorage entries. This kind of feels like backsliding on that effort. Why? src/hotspot/share/opto/library_call.cpp line 3353: > 3351: thread_obj_handle = _gvn.transform(thread_obj_handle); > 3352: const TypePtr *adr_type = _gvn.type(thread_obj_handle)->isa_ptr(); > 3353: access_store_at(NULL, thread_obj_handle, adr_type, arr, _gvn.type(arr), T_OBJECT, IN_NATIVE | MO_UNORDERED); Old code has a `control()` constraint on the store. Is it okay to drop that? ------------- PR: https://git.openjdk.org/jdk/pull/11777 From bpb at openjdk.org Tue Jan 10 02:20:34 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 10 Jan 2023 02:20:34 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v5] In-Reply-To: References: Message-ID: > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299684: Changes addressing reviewer comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11873/files - new: https://git.openjdk.org/jdk/pull/11873/files/d8e6c180..d2386a4b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=03-04 Stats: 107 lines in 4 files changed: 70 ins; 13 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Tue Jan 10 02:20:37 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 10 Jan 2023 02:20:37 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v4] In-Reply-To: References: Message-ID: On Mon, 9 Jan 2023 08:40:02 GMT, Alan Bateman wrote: > If you make it a JUnit test then you'll be able to paramatrized test with value sources, and use the assertions API when checking each of the buffer properties. All points addressed in d2386a4b73f0fa4eb9cc278b3cbb1578e6cb4b55 except converting to a JUnit test. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Tue Jan 10 02:20:41 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 10 Jan 2023 02:20:41 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v4] In-Reply-To: References: Message-ID: On Mon, 9 Jan 2023 05:41:44 GMT, David Holmes wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8299684: Add test for out of range capacity passed to NewDirectBuffer > > make/test/JtregNativeJdk.gmk line 85: > >> 83: BUILD_JDK_JTREG_LIBRARIES_LIBS_libstringPlatformChars := -ljava >> 84: BUILD_JDK_JTREG_LIBRARIES_LIBS_libDirectIO := -ljava >> 85: BUILD_JDK_JTREG_LIBRARIES_LIBS_libNewDirectByteBuffer := -ljava -lc > > Why do we need `-lc`? No. Removed in d2386a4b73f0fa4eb9cc278b3cbb1578e6cb4b55. > src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 245: > >> 243: // Constrain the capacity to int range throwing IAE if not possible >> 244: // >> 245: private static int clampCapacity(long capacity) { > > I think `checkCapacity` would be better - clamp suggests the value gets clamped rather than throwing an exception. So changed in d2386a4b73f0fa4eb9cc278b3cbb1578e6cb4b55. > src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 247: > >> 245: private static int clampCapacity(long capacity) { >> 246: try { >> 247: return Math.toIntExact(capacity); > > Why not the more direct and obvious: > > if (capacity < 0) { > throw ... > } else if (capacity > Integer.MAX_VALUE) { > throw ... > } So changed in d2386a4b73f0fa4eb9cc278b3cbb1578e6cb4b55. > src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 251: > >> 249: String msg = "JNI NewDirectByteBuffer passed illegal capacity: " >> 250: + capacity + (capacity < Integer.MIN_VALUE >> 251: ? " < Integer.MIN_VALUE" : " > Integer.MAX_VALUE"); > > Why the check against `MIN_VALUE`? It was the lower bound for `toIntExact()` but not relevant any more. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Tue Jan 10 02:20:43 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 10 Jan 2023 02:20:43 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v4] In-Reply-To: <1deRMd9Z4swBHRwfUtX5_-XNYuHpYv7PKi4Gf3gjJXA=.e23bf8cf-041f-48e2-916d-33273161a8b9@github.com> References: <1deRMd9Z4swBHRwfUtX5_-XNYuHpYv7PKi4Gf3gjJXA=.e23bf8cf-041f-48e2-916d-33273161a8b9@github.com> Message-ID: On Mon, 9 Jan 2023 08:42:58 GMT, Alan Bateman wrote: >> test/jdk/java/nio/jni/NewDirectByteBuffer.java line 49: >> >>> 47: 1L, >>> 48: (long)Integer.MAX_VALUE - 1, >>> 49: (long)Integer.MAX_VALUE >> >> Won't such large capacities trigger OOME? > >> Won't such large capacities trigger OOME? > > The malloc might fail, in which case the value of NULL will be passed to NewDirectByteBuffer. It needs to check the return from malloc. Fixed in d2386a4b73f0fa4eb9cc278b3cbb1578e6cb4b55. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From iklam at openjdk.org Tue Jan 10 03:27:52 2023 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 10 Jan 2023 03:27:52 GMT Subject: RFR: 8298321: 2 File Leak defect groups in 2 files [v3] In-Reply-To: References: Message-ID: <3R6aDBf-JZ8ZTSX59MJ-NtNNZvBK9LRnv8IgqlEEjZ0=.97bcc76d-1e27-444e-9a2e-1ded4f81e606@github.com> On Tue, 10 Jan 2023 00:49:59 GMT, Calvin Cheung wrote: >> Please review this simple change for fixing two file leak warnings: >> 1) DirectivesParser::parse_from_file_inner() in open/src/hotspot/share/compiler/directivesParser.cpp >> 2) mmap_attach_shared() in open/src/hotspot/os/posix/perfMemory_posix.cpp >> >> Please refer to the [comment](https://bugs.openjdk.org/browse/JDK-8298321?focusedCommentId=14549361&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14549361) in the bug report for details. >> >> Passed tiers 1 and 2 testing. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > @iklam comment Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11909 From dholmes at openjdk.org Tue Jan 10 05:06:53 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 10 Jan 2023 05:06:53 GMT Subject: RFR: 8298321: 2 File Leak defect groups in 2 files [v3] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 00:49:59 GMT, Calvin Cheung wrote: >> Please review this simple change for fixing two file leak warnings: >> 1) DirectivesParser::parse_from_file_inner() in open/src/hotspot/share/compiler/directivesParser.cpp >> 2) mmap_attach_shared() in open/src/hotspot/os/posix/perfMemory_posix.cpp >> >> Please refer to the [comment](https://bugs.openjdk.org/browse/JDK-8298321?focusedCommentId=14549361&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14549361) in the bug report for details. >> >> Passed tiers 1 and 2 testing. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > @iklam comment src/hotspot/os/posix/perfMemory_posix.cpp line 1209: > 1207: > 1208: if (HAS_PENDING_EXCEPTION) { > 1209: assert(fd == OS_ERR, "open_sharedmem_file always return OS_ERR on exceptions"); Does this really appease the static analysis tool? src/hotspot/share/compiler/directivesParser.cpp line 105: > 103: return parse_string(buffer, stream) > 0; > 104: } > 105: ::close(file_handle); You could just move the existing `::close` to before the `if` statement ie close it immediately after the read. ------------- PR: https://git.openjdk.org/jdk/pull/11909 From dholmes at openjdk.org Tue Jan 10 05:57:53 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 10 Jan 2023 05:57:53 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v4] In-Reply-To: References: Message-ID: On Mon, 9 Jan 2023 23:12:00 GMT, Brian Burkhalter wrote: >> make/test/JtregNativeJdk.gmk line 81: >> >>> 79: >>> 80: BUILD_JDK_JTREG_LIBRARIES_LIBS_libTracePinnedThreads := jvm.lib >>> 81: BUILD_JDK_JTREG_LIBRARIES_LIBS_libNewDirectByteBuffer := -ljava -lc >> >> This is not correct for Windows > > Do you have a suggestion? BUILD_JDK_JTREG_LIBRARIES_LIBS_libNewDirectByteBuffer := jvm.lib as per the preceding line. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From dholmes at openjdk.org Tue Jan 10 06:06:55 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 10 Jan 2023 06:06:55 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v5] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 02:20:34 GMT, Brian Burkhalter wrote: >> Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299684: Changes addressing reviewer comments Updates look good - thanks. A few minor nits. src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 197: > 195: throw new IllegalArgumentException > 196: ("JNI NewDirectByteBuffer passed capacity < 0: (" > 197: + capacity + " < 0)"); You don't need to repeat the `< 0` part. src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 201: > 199: throw new IllegalArgumentException > 200: ("JNI NewDirectByteBuffer passed capacity > Integer.MAX_VALUE: (" > 201: + capacity + " > Integer.MAX_VALUE)"); You don't need to repeat the `> Integer.MAX_VALUE` part. test/jdk/java/nio/jni/NewDirectByteBuffer.java line 73: > 71: public static void main(String[] args) { > 72: System.out.println("--- Legal Capacities ---"); > 73: for (long cap : LEGAL_CAPACITIES) { I would still expect this to throw OOME for the very large values, so the OOME needs to be caught so that the test continues. test/jdk/java/nio/jni/NewDirectByteBuffer.java line 106: > 104: private static native ByteBuffer newDirectByteBuffer(long size); > 105: private static native long getDirectBufferCapacity(ByteBuffer buf); > 106: private static native void freeDirectBufferMemory(ByteBuffer buf); Naming nit: ByteBuffer versus Buffer ------------- PR: https://git.openjdk.org/jdk/pull/11873 From dholmes at openjdk.org Tue Jan 10 06:11:53 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 10 Jan 2023 06:11:53 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v4] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 05:54:53 GMT, David Holmes wrote: >> Do you have a suggestion? > > BUILD_JDK_JTREG_LIBRARIES_LIBS_libNewDirectByteBuffer := jvm.lib > > as per the preceding line. Sorry, my bad, that should be: BUILD_JDK_JTREG_LIBRARIES_LIBS_libNewDirectByteBuffer := $(WIN_LIB_JAVA) the Windows equivalent of `-ljava`. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From stefan.karlsson at oracle.com Tue Jan 10 07:43:35 2023 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 10 Jan 2023 08:43:35 +0100 Subject: CFV: New hotspot Group Member: Ron Pressler In-Reply-To: References: Message-ID: Vote: yes StefanK On 2023-01-03 17:11, coleen.phillimore at oracle.com wrote: > Correcting email address. > > > -------- Forwarded Message -------- > Subject: CFV: New hotspot Group Member: Ron Pressler > Date: Tue, 3 Jan 2023 11:06:16 -0500 > From: coleen.phillimore at oracle.com > To: hotspot-dev at openjdk.java.net > > > > I hereby nominate Ron Pressler [rpressler] to Membership in the > hotspot Group. > > Ron Pressler is the lead for the Loom project [1] and is a committer > on the JDK project, including the major contribution of? JEP 425: > Virtual Threads. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#loom > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.karlsson at oracle.com Tue Jan 10 07:43:52 2023 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 10 Jan 2023 08:43:52 +0100 Subject: CFV: New OpenJDK hotspot Group Member: Serguei Spitsyn In-Reply-To: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> References: <138b8d47-354a-3071-af05-2995b5ee9163@oracle.com> Message-ID: <1581fa22-38b0-fb8d-bcc3-caccbb0db7f2@oracle.com> Vote: yes StefanK On 2023-01-03 17:27, coleen.phillimore at oracle.com wrote: > I hereby nominate Serguei Spitsyn [sspitsyn] to Membership in the > hotspot Group. > > Serguei is an OpenJDK reviewer and a member of the HotSpot > serviceability team at Oracle.? He is lead for the serviceability > project [1] and a technical lead in HotSpot. He has recently > implemented JVMTI support for the Loom project.? He is already member > of the OpenJDK members group. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#serviceability > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > From stefan.karlsson at oracle.com Tue Jan 10 07:44:15 2023 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 10 Jan 2023 08:44:15 +0100 Subject: CFV: New OpenJDK hotspot Group Member: Frederic Parain In-Reply-To: <175ece63-eb89-ba46-52aa-270762e122c2@oracle.com> References: <175ece63-eb89-ba46-52aa-270762e122c2@oracle.com> Message-ID: <05a244e5-26ee-bea4-7083-a46e366d14b7@oracle.com> Vote: yes StefanK On 2023-01-03 17:26, coleen.phillimore at oracle.com wrote: > I hereby nominate Frederic Parain [fparain] to Membership in the > hotspot Group. > > Frederic is an OpenJDK Committer and a member of the HotSpot runtime > team at Oracle. He is an active contributor to the valhalla project > [1], implementing programming models in the HotSpot code. He is also a > contributor to OpenJDK since 2010, working on serviceability code, > implementing the diagnostic commands framework, and rewriting Java > field layout code. He is currently working on compressing c2 frames in > the Loom project, and making the VM internal representation of fields > extensible for valhalla support. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Coleen Phillimore > > [1] https://openjdk.org/census#valhalla > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > From stefan.karlsson at oracle.com Tue Jan 10 07:44:31 2023 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 10 Jan 2023 08:44:31 +0100 Subject: CFV: New OpenJDK hotspot Group Member: Lois Foltan In-Reply-To: References: Message-ID: <0c18a023-4bf7-b286-fbe3-cecb30abd015@oracle.com> Vote: yes StefanK On 2023-01-03 17:22, coleen.phillimore at oracle.com wrote: > I hereby nominate Lois Foltan [lfoltan] to Membership in the hotspot > Group. > > Lois is an OpenJDK Reviewer and a member of the HotSpot runtime team > at Oracle. She contributed the VM support for the Module subsystem JSR > 294, semantic changes in HotSpot for default methods, cleanups for > signature processing, Condy support, and many bug fixes. Lois is now > an engineering manager for the runtime team. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vot From stefan.karlsson at oracle.com Tue Jan 10 07:44:46 2023 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 10 Jan 2023 08:44:46 +0100 Subject: CFV: New OpenJDK hotspot Group Member: Patricio Chilano Mateo In-Reply-To: References: Message-ID: <80d84b44-4249-3baf-4035-5f9819f107b8@oracle.com> Vote: yes StefanK On 2023-01-03 17:20, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo [pchilomate] to Membership in > the hotspot Group. > > Patricio is an OpenJDK Reviewer and a member of the HotSpot runtime > team at Oracle. Since 2018 he has worked on improvements and bug fixes > mainly in the areas of locking, safepoint synchronization, thread > state transitions, and handshakes. He is currently working on Loom > changes for virtual thread preemption. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vote > > From stefan.karlsson at oracle.com Tue Jan 10 07:45:00 2023 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 10 Jan 2023 08:45:00 +0100 Subject: CFV: New OpenJDK hotspot Group Member: Robbin Ehn In-Reply-To: <7652c110-0767-bf12-dd32-8cde03ba6fc7@oracle.com> References: <7652c110-0767-bf12-dd32-8cde03ba6fc7@oracle.com> Message-ID: Vote: yes StefanK On 2023-01-03 17:18, coleen.phillimore at oracle.com wrote: > I hereby nominate Robbin Ehn [rehn] to Membership in the hotspot Group. > > Robbin Ehn is an OpenJDK Reviewer and a member of the HotSpot runtime > team at Oracle.? He has contributed a concurrent hash table, > synchronization performance improvements and bug fixes to the HotSpot > code base. > > Votes are due by January 17, 2023. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen Phillimore > > [1] https://openjdk.org/census#hotspot > [2] https://openjdk.org/groups/#member-vote > > From aboldtch at openjdk.org Tue Jan 10 07:57:52 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 10 Jan 2023 07:57:52 GMT Subject: RFR: 8299089: Instrument global jni handles with tag to make them distinguishable In-Reply-To: References: Message-ID: <9llKhi6qRqgCPE09peCUDFJz3HKfiiMx-5wOSXPs_gU=.9df28102-3f27-44e2-9598-07f749019a87@github.com> On Mon, 9 Jan 2023 19:28:50 GMT, Albert Mingkun Yang wrote: >> Weak global jni handles are tagged so the GC can distinguish them when resolving the object. Today there is no cheap way of distinguishing global jni handles from local jni handles. For generational ZGC the OopStorage handles and the thread local handles semantical difference requires the handles to be distinguishable. >> >> This enhancements instruments the jni handles with a global tag similarly to the jweak tag. >> >> Note: >> * the s390 implementation has minimal changes and requires improvement. >> * There is room for enchantment here to create the same abstraction that ppc uses for all platforms, i.e. move the resolve_jobject from the MacroAssembler to the BarrierSetAssembler which allows for more optimised code for GCs that can treat local and global handles the same. >> >> Testing: GHA. Oracle supported platforms tier1-3. Will run higher tiers. Has also been tested on the generational branch of ZGC for over three months. Requires testing on non Oracle platforms. > > src/hotspot/share/runtime/jniHandles.cpp line 250: > >> 248: bool JNIHandles::is_global_handle(jobject handle) { >> 249: assert(handle != NULL, "precondition"); >> 250: return is_global_tagged(handle) && !is_jweak_tagged(handle) && is_storage_handle(global_handles(), global_ptr(handle)); > > Can a handle be both global and jweak tagged? Can a non-global ref be global-tagged? > > Seems to me the `is_global_tagged` check alone is enough here. All the tags are mutually exclusive. _Note there is a minor difference in naming here. We just call them local, global or [j]weak. But in the jni.h and the API documentation jweak is also known as a Weak Global Ref or JNIWeakGlobalRefType, and global is a Global ref or JNIGlobalRefType. But they are still mutually exclusive and it is just the naming that both use the word global._ An alternative implementation would be to have the two bits mean global/local and strong/weak with the local weak combination being disallowed. I think the only benefit would be that it would fit more with the API naming that a global weak is global and weak tagged, a global is global tagged and local has no tags. But it would confuse the internal meaning of `global_handle`, does it include global weak or not? I think there is probably a better way of naming all these, but I also think the proposed change is the least disruptive to established nomenclature. `is_global_tagged` is enough if you only look at the hotspot code. But we will get handles from the JNI external interface, and we want to check that the storage is correct in conjunction with checking that the tags are correct. (I think this is the idea at least. Similarly how before this change `is_weak_global_handle` both checked the tag and the storage, while just checking the tag would have been enough). Looking at the code there is probably room for improvement here, as the `checked_jni_Delete*` which uses the `is_*_handle` functions also uses `jniCheck::validate_object` which only checks the tags (not the storage) before trying to look at the contents. So I am unsure what happens if the input handle has a bad tag/storage. ------------- PR: https://git.openjdk.org/jdk/pull/11740 From mbaesken at openjdk.org Tue Jan 10 08:21:54 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 10 Jan 2023 08:21:54 GMT Subject: RFR: JDK-8299672: Enhance HeapDump JFR event In-Reply-To: References: Message-ID: On Thu, 5 Jan 2023 14:54:31 GMT, Matthias Baesken wrote: > Enhance the JFR Event HeapDump with the additional interesting fields, compression and overwrite. > Add some UL logging in case the heap dump writing failed . The support for gzipped heap dumps was added recently with "8237354: Add option to jcmd to write a gzipped heap dump" but not reflected in JFR so I wanted to add it here too to get a full picture of the heap dump creation. The overwrite field was just added for completion, no specific reason. ------------- PR: https://git.openjdk.org/jdk/pull/11864 From ayang at openjdk.org Tue Jan 10 08:29:51 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 10 Jan 2023 08:29:51 GMT Subject: RFR: 8299089: Instrument global jni handles with tag to make them distinguishable In-Reply-To: <9llKhi6qRqgCPE09peCUDFJz3HKfiiMx-5wOSXPs_gU=.9df28102-3f27-44e2-9598-07f749019a87@github.com> References: <9llKhi6qRqgCPE09peCUDFJz3HKfiiMx-5wOSXPs_gU=.9df28102-3f27-44e2-9598-07f749019a87@github.com> Message-ID: On Tue, 10 Jan 2023 07:54:42 GMT, Axel Boldt-Christmas wrote: > All the tags are mutually exclusive. I see; could those tags be implemented using enum then? Sth like: enum Tag { local = 0b00, jweak = 0b01, global = 0b10, mask = 0b11, } bool is_tagged_with(Handle h, Tag t) { return (h & mask) == t. } This makes the "mutual exclusiveness" more explicit and can probaly remove some redundancy in `assert(is_jweak); assert(!is_global);`. > But we will get handles from the JNI external interface, and we want to check that the storage is correct in conjunction with checking that the tags are correct. I don't know much about JNI; I thought all handles must be constructed using JNI APIs -- so, they must be correctly tagged. ------------- PR: https://git.openjdk.org/jdk/pull/11740 From eosterlund at openjdk.org Tue Jan 10 09:34:52 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 10 Jan 2023 09:34:52 GMT Subject: RFR: 8299032: Interface IN_NATIVE oop stores for C2 In-Reply-To: References: <61HZ-hCw_ZoDZCtsDLsz-tfPE6S7Ox_1nXApLQnZ1SU=.60c813cf-a5d8-4a3c-a2a1-86d7af05d042@github.com> Message-ID: On Tue, 10 Jan 2023 01:56:11 GMT, Kim Barrett wrote: >> Loom added the first IN_NATIVE oop store to C2 code, when switching the current virtual thread of a platform thread. Instead of interfacing this properly, a raw store was used. But a future GC algorithm, such as generational ZGC, might not work well with raw stores. We should add support to the access API for this. Looks like Shenandoah was already missing something here as they do concurrent root processing requiring SATB barriers on IN_NATIVE oop stores. It is not in the scope of this PR to fix the Shenandoah bug - someone working on Shenandoah should do this. This PR merely adds an interface such that GCs that need to do something different here, can do that. Serial, Parallel and G1 don't need to do anything for IN_NATIVE stores as they do STW root processing. ZGC doesn't (yet) have store barriers at all, and hence doesn't need to do anything special either. > > src/hotspot/share/opto/library_call.cpp line 3353: > >> 3351: thread_obj_handle = _gvn.transform(thread_obj_handle); >> 3352: const TypePtr *adr_type = _gvn.type(thread_obj_handle)->isa_ptr(); >> 3353: access_store_at(NULL, thread_obj_handle, adr_type, arr, _gvn.type(arr), T_OBJECT, IN_NATIVE | MO_UNORDERED); > > Old code has a `control()` constraint on the store. Is it okay to drop that? The first parameter to access_store_at, is the containing object, not the control (which might be different to the address). As for IN_NATIVE stores, there is no containing object, which is what the NULL denotes. In the backend, it does indeed attach the current control inside of BarrierSetC2::store_at_resolved. ------------- PR: https://git.openjdk.org/jdk/pull/11777 From eosterlund at openjdk.org Tue Jan 10 09:39:51 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 10 Jan 2023 09:39:51 GMT Subject: RFR: 8299032: Interface IN_NATIVE oop stores for C2 In-Reply-To: References: <61HZ-hCw_ZoDZCtsDLsz-tfPE6S7Ox_1nXApLQnZ1SU=.60c813cf-a5d8-4a3c-a2a1-86d7af05d042@github.com> Message-ID: On Tue, 10 Jan 2023 02:00:28 GMT, Kim Barrett wrote: > Not a review, since I'm not sufficiently knowledgeable about C2 to really do justice to it. Rather, a couple questions/comments. > > We made a concerted effort to reduce/eliminate oops in native storage, instead using OopStorage entries. This kind of feels like backsliding on that effort. Why? It isn't a backsliding on that effort. This code is indeed using OopStorage. An OopHandle::replace uses IN_NATIVE stores. This is essentially an intrinsic that replaces the contents of an OopHandle, so similarly it should use an IN_NATIVE store for that. Having said that, perhaps it would have been more clear if there was a high level function of some sort with a name like oop_handle_replace containing the IN_NATIVE store? ------------- PR: https://git.openjdk.org/jdk/pull/11777 From aboldtch at openjdk.org Tue Jan 10 09:48:53 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 10 Jan 2023 09:48:53 GMT Subject: RFR: 8299089: Instrument global jni handles with tag to make them distinguishable In-Reply-To: References: <9llKhi6qRqgCPE09peCUDFJz3HKfiiMx-5wOSXPs_gU=.9df28102-3f27-44e2-9598-07f749019a87@github.com> Message-ID: On Tue, 10 Jan 2023 08:26:50 GMT, Albert Mingkun Yang wrote: >> All the tags are mutually exclusive. >> _Note there is a minor difference in naming here. We just call them local, global or [j]weak. But in the jni.h and the API documentation jweak is also known as a Weak Global Ref or JNIWeakGlobalRefType, and global is a Global ref or JNIGlobalRefType. But they are still mutually exclusive and it is just the naming that both use the word global._ >> >> An alternative implementation would be to have the two bits mean global/local and strong/weak with the local weak combination being disallowed. I think the only benefit would be that it would fit more with the API naming that a global weak is global and weak tagged, a global is global tagged and local has no tags. >> But it would confuse the internal meaning of `global_handle`, does it include global weak or not? I think there is probably a better way of naming all these, but I also think the proposed change is the least disruptive to established nomenclature. >> >> `is_global_tagged` is enough if you only look at the hotspot code. But we will get handles from the JNI external interface, and we want to check that the storage is correct in conjunction with checking that the tags are correct. (I think this is the idea at least. Similarly how before this change `is_weak_global_handle` both checked the tag and the storage, while just checking the tag would have been enough). >> >> Looking at the code there is probably room for improvement here, as the `checked_jni_Delete*` which uses the `is_*_handle` functions also uses `jniCheck::validate_object` which only checks the tags (not the storage) before trying to look at the contents. So I am unsure what happens if the input handle has a bad tag/storage. > >> All the tags are mutually exclusive. > > I see; could those tags be implemented using enum then? Sth like: > > > enum Tag { > local = 0b00, > jweak = 0b01, > global = 0b10, > mask = 0b11, > } > > bool is_tagged_with(Handle h, Tag t) { > return (h & mask) == t. > } > > > This makes the "mutual exclusiveness" more explicit and can probaly remove some redundancy in `assert(is_jweak); assert(!is_global);`. > > >> But we will get handles from the JNI external interface, and we want to check that the storage is correct in conjunction with checking that the tags are correct. > > I don't know much about JNI; I thought all handles must be constructed using JNI APIs -- so, they must be correctly tagged. That is probably clearer. Will take a look at it. That is how it should be used and I think the effort is that if you do something bad you get a ReportJNIFatalError with some message instead of maybe crashing in the VM. But probably cleaner and more accurate if the code which checks the storage is move to `jniCheck::validate_handle` and have the handle checks just use the tag. ------------- PR: https://git.openjdk.org/jdk/pull/11740 From eosterlund at openjdk.org Tue Jan 10 10:12:51 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 10 Jan 2023 10:12:51 GMT Subject: RFR: 8299673: Simplify object pinning interactions with string deduplication Message-ID: When raw char* String contents are exposed to JNI code, we 1. Load the string.value and pin it 2. Run native code 3. Load the string.value and unpin it Given this sequence we would be in trouble if between 1 and 3, string deduplication changed the value object. Then the pinning and unpinning wouldn't be balanced. The current approach for dealing with this is to have a bunch of code to guard against deduplication. An alternative simpler solution is to just change step 3 to pass in the same value. We already have enough information available to do that. Then the pinning and unpinning is also balanced, and we don't need to have any special interactions with string deduplication and can decouple these orthogonal concerns. It's worth noting though that the contract of pin_object now makes it explicit that pinned objects must not be recycled, even if not otherwise reachable. That seems to come naturally for region based pinning, but is worth keeping in mind. The exposed char* might be the only thing referencing the string value when string dedup happens concurrently. ------------- Commit messages: - More Kim feedback - Feedback from Kim - 8299673: Simplify object pinning interactions with string deduplication Changes: https://git.openjdk.org/jdk/pull/11923/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11923&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299673 Stats: 162 lines in 14 files changed: 66 ins; 68 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/11923.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11923/head:pull/11923 PR: https://git.openjdk.org/jdk/pull/11923 From aboldtch at openjdk.org Tue Jan 10 10:08:52 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 10 Jan 2023 10:08:52 GMT Subject: RFR: 8299089: Instrument global jni handles with tag to make them distinguishable In-Reply-To: References: <9llKhi6qRqgCPE09peCUDFJz3HKfiiMx-5wOSXPs_gU=.9df28102-3f27-44e2-9598-07f749019a87@github.com> Message-ID: <52iBfvaveG8GsTeQ9SZKrDNztxwadwdISaToIggbW6I=.88b620e9-e4e6-42ae-8312-da798114dac6@github.com> On Tue, 10 Jan 2023 09:46:18 GMT, Axel Boldt-Christmas wrote: >>> All the tags are mutually exclusive. >> >> I see; could those tags be implemented using enum then? Sth like: >> >> >> enum Tag { >> local = 0b00, >> jweak = 0b01, >> global = 0b10, >> mask = 0b11, >> } >> >> bool is_tagged_with(Handle h, Tag t) { >> return (h & mask) == t. >> } >> >> >> This makes the "mutual exclusiveness" more explicit and can probaly remove some redundancy in `assert(is_jweak); assert(!is_global);`. >> >> >>> But we will get handles from the JNI external interface, and we want to check that the storage is correct in conjunction with checking that the tags are correct. >> >> I don't know much about JNI; I thought all handles must be constructed using JNI APIs -- so, they must be correctly tagged. > > That is probably clearer. Will take a look at it. > > That is how it should be used and I think the effort is that if you do something bad you get a ReportJNIFatalError with some message instead of maybe crashing in the VM. But probably cleaner and more accurate if the code which checks the storage is move to `jniCheck::validate_handle` and have the handle checks just use the tag. Looking at `validate_handle` it does check the storage and it would reach `ShouldNotReachHere();` if the handle has bad storage. So just checking the tag should be fine. (And assert the storage) ------------- PR: https://git.openjdk.org/jdk/pull/11740 From sjohanss at openjdk.org Tue Jan 10 11:46:56 2023 From: sjohanss at openjdk.org (Stefan Johansson) Date: Tue, 10 Jan 2023 11:46:56 GMT Subject: RFR: 8298482: Implement ParallelGC NUMAStats for Linux [v3] In-Reply-To: <0kLOC8uhdDwwtu901coLNm8UT_7k3pzLn1MjWeXqU-0=.d4d9c100-12bb-4dc1-81d7-a3752e1fd930@github.com> References: <0kLOC8uhdDwwtu901coLNm8UT_7k3pzLn1MjWeXqU-0=.d4d9c100-12bb-4dc1-81d7-a3752e1fd930@github.com> Message-ID: On Thu, 5 Jan 2023 09:53:06 GMT, Nick Gasson wrote: >> ParallelGC has a seemingly useful option -XX:+NUMAStats that prints detailed information in GC.heap_info about which NUMA node pages in the eden space are bound to. However as far as I can tell this only ever worked on Solaris and is not implemented on any of the systems we currently support. This patch implements it on Linux using the move_pages system call. >> >> The function os::get_page_info() and accompanying struct page_info was just a thin wrapper around the Solaris meminfo(2) syscall and was never ported to other systems so I've just removed it rather than try to emulate its interface. >> >> There's also a method MutableNUMASpace::LGRPSpace::scan_pages() which attempts to find pages on the wrong NUMA node and frees them so that they have another chance to be allocated on the correct node by the first-touching thread, but I think this has always been a no-op on non-Solaris so perhaps should also be removed. On Linux it shouldn't be necessary as you can bind pages to the desired node directly. >> >> I don't know what the performance of this option was like on Solaris but on Linux the move_pages call can be quite slow: I measured about 25ms/GB on my system. At the moment we call LGRPSpace::accumulate_statistics() twice per GC cycle: I removed the second call as it's likely to see a lot of uncommitted pages if the spaces were just resized. MutableNUMASpace::print_on() also calls accumulate_statistics() directly and since that's the only place this data is used, maybe we can drop the call from MutableNUMASpace::accumulate_statistics() as well? >> >> Example output: >> >> >> PSYoungGen total 4290560K, used 835628K [0x00000006aac00000, 0x0000000800000000, 0x0000000800000000) >> eden space 3096576K, 1% used [0x00000006aac00000,0x00000007176a9f48,0x0000000767c00000) >> lgrp 0 space 1761280K, 2% used [0x00000006aac00000,0x00000006acfc4980,0x0000000716400000) >> local/remote/unbiased/uncommitted: 1671168K/0K/0K/90112K, large/small pages: 0/440320 >> lgrp 1 space 1335296K, 46% used [0x0000000716400000,0x000000073c2abb18,0x0000000767c00000) >> local/remote/unbiased/uncommitted: 1335296K/0K/0K/0K, large/small pages: 0/333824 >> from space 1193984K, 65% used [0x00000007b7200000,0x00000007e6b9c778,0x0000000800000000) >> to space 1247232K, 0% used [0x0000000767c00000,0x0000000767c00000,0x00000007b3e00000) >> >> >> After testing this with SPECjbb for a while I noticed some pages always end up bound to the wrong node. I think this is a regression caused by JDK-8283935 but I'll raise a separate ticket for that. > > Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: > > Do not update NUMAStats in MutableNUMASpace::accumulate_statistics() Looks good, just a style comment below. Regarding the need of calls to `accumulate_statistics()` I also agree that the call in `print_on` should be enough. src/hotspot/share/gc/parallel/mutableNUMASpace.cpp line 896: > 894: space_stats()->_local_space += os::vm_page_size(); > 895: else > 896: space_stats()->_remote_space += os::vm_page_size(); Please add braces for the `for`-loop and the `if-else`-statements. ------------- Marked as reviewed by sjohanss (Reviewer). PR: https://git.openjdk.org/jdk/pull/11635 From duke at openjdk.org Tue Jan 10 11:49:19 2023 From: duke at openjdk.org (Afshin Zafari) Date: Tue, 10 Jan 2023 11:49:19 GMT Subject: RFR: 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug [v3] In-Reply-To: References: Message-ID: > ### Description > The following problems found and solved: > > 1) Reporting which regex pattern did not match with error messages was incorrect. To report the mismatched pattern, the head of the pattern list was peeked, while it was the already peeked item from that did not match. So the next pattern to the mismatched one was reported. > > 2) The pattern for finding a crash was incorrectly set to "# .*VMError::controlled_crash.*", while it has to be "# .*crash_with_segfault.*". > > 3) `crash_with_segfault` function is too small and was `inline`d in compiler optimisations. So it was not in the stack trace when the error message is created. > > ### Patch > 1 and 2 corrected and added the `NOINLINE` to the `crash_with_segfault` signature. The same applied for `crash_with_sigfpe` function. > > ### Test > runtime/ErrorHandling/* and tier1-5 Afshin Zafari has updated the pull request incrementally with two additional commits since the last revision: - 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug - 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11704/files - new: https://git.openjdk.org/jdk/pull/11704/files/04a11f6b..35e46757 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11704&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11704&range=01-02 Stats: 8 lines in 3 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/11704.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11704/head:pull/11704 PR: https://git.openjdk.org/jdk/pull/11704 From duke at openjdk.org Tue Jan 10 11:57:22 2023 From: duke at openjdk.org (Afshin Zafari) Date: Tue, 10 Jan 2023 11:57:22 GMT Subject: RFR: 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug [v4] In-Reply-To: References: Message-ID: > ### Description > The following problems found and solved: > > 1) Reporting which regex pattern did not match with error messages was incorrect. To report the mismatched pattern, the head of the pattern list was peeked, while it was the already peeked item from that did not match. So the next pattern to the mismatched one was reported. > > 2) The pattern for finding a crash was incorrectly set to "# .*VMError::controlled_crash.*", while it has to be "# .*crash_with_segfault.*". > > 3) `crash_with_segfault` function is too small and was `inline`d in compiler optimisations. So it was not in the stack trace when the error message is created. > > ### Patch > 1 and 2 corrected and added the `NOINLINE` to the `crash_with_segfault` signature. The same applied for `crash_with_sigfpe` function. > > ### Test > runtime/ErrorHandling/* and tier1-5 Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11704/files - new: https://git.openjdk.org/jdk/pull/11704/files/35e46757..430f0210 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11704&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11704&range=02-03 Stats: 8 lines in 1 file changed: 0 ins; 7 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11704.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11704/head:pull/11704 PR: https://git.openjdk.org/jdk/pull/11704 From duke at openjdk.org Tue Jan 10 11:57:23 2023 From: duke at openjdk.org (Afshin Zafari) Date: Tue, 10 Jan 2023 11:57:23 GMT Subject: RFR: 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug [v2] In-Reply-To: References: Message-ID: <35RKBpK6Gf9pjG5bxVDNG9mgZ2o3qg1l8OhJnriy2Vs=.ce0a7b0a-d634-4a44-b85a-29d59af88229@github.com> On Sun, 18 Dec 2022 21:44:27 GMT, David Holmes wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug > > src/hotspot/share/utilities/vmError.cpp line 1806: > >> 1804: // Crash with an authentic sigfpe >> 1805: volatile int sigfpe_int = 0; >> 1806: static void NOINLINE crash_with_sigfpe() { > > Did you consider ALWAYSINLINE instead so the tests could be left unchanged? Used the ALWAYINLINE and tested for tier1-5. ------------- PR: https://git.openjdk.org/jdk/pull/11704 From alanb at openjdk.org Tue Jan 10 12:04:56 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 10 Jan 2023 12:04:56 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v5] In-Reply-To: References: Message-ID: <72tDSvqfz8V4UlUsCSLtIlplkn32UTucoTq62yRZhdo=.fab73681-bf7b-4ce7-b20b-8f2bca8f9373@github.com> On Tue, 10 Jan 2023 02:20:34 GMT, Brian Burkhalter wrote: >> Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299684: Changes addressing reviewer comments The update looks quite good and maybe some day this can be converted from a psvm test to a junit test. test/jdk/java/nio/jni/NewDirectByteBuffer.java line 30: > 28: * @summary Verify that JNI NewDirectByteBuffer throws IllegalArgumentException > 29: * if the capacity is negative or greater than Integer::MAX_VALUE > 30: * @run main/native NewDirectByteBuffer You may have missed the comments about @requires and wondering if this test will run on 32-bit, as it will attempt to malloc 2GB. test/jdk/java/nio/jni/NewDirectByteBuffer.java line 50: > 48: (long)Integer.MAX_VALUE + 1L, > 49: 3_000_000_000L, > 50: 5_000_000_000L Long.MIN_VALUE and Long.MAX_VALUE would be good to include. test/jdk/java/nio/jni/libNewDirectByteBuffer.c line 35: > 33: void* addr = malloc(size); > 34: if (addr == NULL) { > 35: jclass rtExCls = (*env)->FindClass(env, "java/lang/OutOfMemoryError"); rtExCls? Does this stand for "runtime exception class", just asking because this is an Error class. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From tschatzl at openjdk.org Tue Jan 10 12:09:53 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 10 Jan 2023 12:09:53 GMT Subject: RFR: 8298482: Implement ParallelGC NUMAStats for Linux [v3] In-Reply-To: <0kLOC8uhdDwwtu901coLNm8UT_7k3pzLn1MjWeXqU-0=.d4d9c100-12bb-4dc1-81d7-a3752e1fd930@github.com> References: <0kLOC8uhdDwwtu901coLNm8UT_7k3pzLn1MjWeXqU-0=.d4d9c100-12bb-4dc1-81d7-a3752e1fd930@github.com> Message-ID: On Thu, 5 Jan 2023 09:53:06 GMT, Nick Gasson wrote: >> ParallelGC has a seemingly useful option -XX:+NUMAStats that prints detailed information in GC.heap_info about which NUMA node pages in the eden space are bound to. However as far as I can tell this only ever worked on Solaris and is not implemented on any of the systems we currently support. This patch implements it on Linux using the move_pages system call. >> >> The function os::get_page_info() and accompanying struct page_info was just a thin wrapper around the Solaris meminfo(2) syscall and was never ported to other systems so I've just removed it rather than try to emulate its interface. >> >> There's also a method MutableNUMASpace::LGRPSpace::scan_pages() which attempts to find pages on the wrong NUMA node and frees them so that they have another chance to be allocated on the correct node by the first-touching thread, but I think this has always been a no-op on non-Solaris so perhaps should also be removed. On Linux it shouldn't be necessary as you can bind pages to the desired node directly. >> >> I don't know what the performance of this option was like on Solaris but on Linux the move_pages call can be quite slow: I measured about 25ms/GB on my system. At the moment we call LGRPSpace::accumulate_statistics() twice per GC cycle: I removed the second call as it's likely to see a lot of uncommitted pages if the spaces were just resized. MutableNUMASpace::print_on() also calls accumulate_statistics() directly and since that's the only place this data is used, maybe we can drop the call from MutableNUMASpace::accumulate_statistics() as well? >> >> Example output: >> >> >> PSYoungGen total 4290560K, used 835628K [0x00000006aac00000, 0x0000000800000000, 0x0000000800000000) >> eden space 3096576K, 1% used [0x00000006aac00000,0x00000007176a9f48,0x0000000767c00000) >> lgrp 0 space 1761280K, 2% used [0x00000006aac00000,0x00000006acfc4980,0x0000000716400000) >> local/remote/unbiased/uncommitted: 1671168K/0K/0K/90112K, large/small pages: 0/440320 >> lgrp 1 space 1335296K, 46% used [0x0000000716400000,0x000000073c2abb18,0x0000000767c00000) >> local/remote/unbiased/uncommitted: 1335296K/0K/0K/0K, large/small pages: 0/333824 >> from space 1193984K, 65% used [0x00000007b7200000,0x00000007e6b9c778,0x0000000800000000) >> to space 1247232K, 0% used [0x0000000767c00000,0x0000000767c00000,0x00000007b3e00000) >> >> >> After testing this with SPECjbb for a while I noticed some pages always end up bound to the wrong node. I think this is a regression caused by JDK-8283935 but I'll raise a separate ticket for that. > > Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: > > Do not update NUMAStats in MutableNUMASpace::accumulate_statistics() Apart from the braces issue raised by Stefan, looks good. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.org/jdk/pull/11635 From stuefe at openjdk.org Tue Jan 10 12:16:52 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 10 Jan 2023 12:16:52 GMT Subject: RFR: 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug [v4] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 11:57:22 GMT, Afshin Zafari wrote: >> ### Description >> The following problems found and solved: >> >> 1) Reporting which regex pattern did not match with error messages was incorrect. To report the mismatched pattern, the head of the pattern list was peeked, while it was the already peeked item from that did not match. So the next pattern to the mismatched one was reported. >> >> 2) The pattern for finding a crash was incorrectly set to "# .*VMError::controlled_crash.*", while it has to be "# .*crash_with_segfault.*". >> >> 3) `crash_with_segfault` function is too small and was `inline`d in compiler optimisations. So it was not in the stack trace when the error message is created. >> >> ### Patch >> 1 and 2 corrected and added the `NOINLINE` to the `crash_with_segfault` signature. The same applied for `crash_with_sigfpe` function. >> >> ### Test >> runtime/ErrorHandling/* and tier1-5 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug @afshin-zafari, thank you for finding and fixing this. I worry that this may be too fragile, since it depends on linker hints that AFAIK the linker could ignore. Could we instead match with something like `"# .*(VMError::controlled_crash|crash_with).*"`? ------------- PR: https://git.openjdk.org/jdk/pull/11704 From duke at openjdk.org Tue Jan 10 12:40:52 2023 From: duke at openjdk.org (Afshin Zafari) Date: Tue, 10 Jan 2023 12:40:52 GMT Subject: RFR: 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug [v4] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 12:14:16 GMT, Thomas Stuefe wrote: > @afshin-zafari, thank you for finding and fixing this. > > I worry that this may be too fragile, since it depends on linker hints that AFAIK the linker could ignore. Could we instead match with something like `"# .*(VMError::controlled_crash|crash_with).*"`? `ALWAYSINLINE` or its expanded form `__attribute__ (always_inline)` will prevail all other compile options for inlining (particularly compiler optimisation options) , e.g. limit number and/or do or don't inlining. So it would not be ignored as was not in tier 1-5 tests. ------------- PR: https://git.openjdk.org/jdk/pull/11704 From stuefe at openjdk.org Tue Jan 10 13:04:54 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 10 Jan 2023 13:04:54 GMT Subject: RFR: 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug [v4] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 11:57:22 GMT, Afshin Zafari wrote: >> ### Description >> The following problems found and solved: >> >> 1) Reporting which regex pattern did not match with error messages was incorrect. To report the mismatched pattern, the head of the pattern list was peeked, while it was the already peeked item from that did not match. So the next pattern to the mismatched one was reported. >> >> 2) The pattern for finding a crash was incorrectly set to "# .*VMError::controlled_crash.*", while it has to be "# .*crash_with_segfault.*". >> >> 3) `crash_with_segfault` function is too small and was `inline`d in compiler optimisations. So it was not in the stack trace when the error message is created. >> >> ### Patch >> 1 and 2 corrected and added the `NOINLINE` to the `crash_with_segfault` signature. The same applied for `crash_with_sigfpe` function. >> >> ### Test >> runtime/ErrorHandling/* and tier1-5 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug Marked as reviewed by stuefe (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11704 From stuefe at openjdk.org Tue Jan 10 13:04:56 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 10 Jan 2023 13:04:56 GMT Subject: RFR: 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug [v4] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 12:38:03 GMT, Afshin Zafari wrote: > > @afshin-zafari, thank you for finding and fixing this. > > I worry that this may be too fragile, since it depends on linker hints that AFAIK the linker could ignore. Could we instead match with something like `"# .*(VMError::controlled_crash|crash_with).*"`? > > `ALWAYSINLINE` or its expanded form `__attribute__ (always_inline)` will prevail all other compile options for inlining (particularly compiler optimisation options) , e.g. limit number and/or do or don't inlining. So it would not be ignored as was not in tier 1-5 tests. Okay, good enough then. Just wanted to prevent false positives (we had a lot of work when writing tests for NMT call stack matching). +1 ------------- PR: https://git.openjdk.org/jdk/pull/11704 From fjiang at openjdk.org Tue Jan 10 13:46:34 2023 From: fjiang at openjdk.org (Feilong Jiang) Date: Tue, 10 Jan 2023 13:46:34 GMT Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory API (Preview) [v4] In-Reply-To: References: Message-ID: > Add experimental Foreign Function & Memory API support for RISC-V. > > For details of the FFM API RISC-V port please refer to [JBS issue](https://bugs.openjdk.org/browse/JDK-8293841) > > Testing: > > - [x] jdk_foreign with release/fastdebug build > - [x] run TestMatrix.java manually with release/fastdebug build Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision: fix callArranger ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11004/files - new: https://git.openjdk.org/jdk/pull/11004/files/289b8697..fd312661 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11004&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11004&range=02-03 Stats: 6 lines in 2 files changed: 0 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11004.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11004/head:pull/11004 PR: https://git.openjdk.org/jdk/pull/11004 From aboldtch at openjdk.org Tue Jan 10 14:40:56 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 10 Jan 2023 14:40:56 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames In-Reply-To: References: Message-ID: On Mon, 9 Jan 2023 10:30:06 GMT, Fredrik Bredberg wrote: > Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. > Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. > Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. src/hotspot/cpu/aarch64/continuationHelper_aarch64.inline.hpp line 2: > 1: /* > 2: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. Note, you changed the initial year. Should be: - * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2022, 2023, Oracle and/or its affiliates. All rights reserved. ------------- PR: https://git.openjdk.org/jdk/pull/11902 From duke at openjdk.org Tue Jan 10 14:51:02 2023 From: duke at openjdk.org (Fredrik Bredberg) Date: Tue, 10 Jan 2023 14:51:02 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 14:38:32 GMT, Axel Boldt-Christmas wrote: >> Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. >> Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. >> Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. > > src/hotspot/cpu/aarch64/continuationHelper_aarch64.inline.hpp line 2: > >> 1: /* >> 2: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. > > Note, you changed the initial year. Should be: > > - * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2022, 2023, Oracle and/or its affiliates. All rights reserved. My sed script which updated all copyright headers to 2023 didn't take into account files with only one year in the copyright line. My bad. ------------- PR: https://git.openjdk.org/jdk/pull/11902 From fjiang at openjdk.org Tue Jan 10 15:15:23 2023 From: fjiang at openjdk.org (Feilong Jiang) Date: Tue, 10 Jan 2023 15:15:23 GMT Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory API (Preview) [v5] In-Reply-To: References: Message-ID: > Add experimental Foreign Function & Memory API support for RISC-V. > > For details of the FFM API RISC-V port please refer to [JBS issue](https://bugs.openjdk.org/browse/JDK-8293841) > > Testing: > > - [x] jdk_foreign with release/fastdebug build > - [x] run TestMatrix.java manually with release/fastdebug build Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision: fix callArranger ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11004/files - new: https://git.openjdk.org/jdk/pull/11004/files/fd312661..fee96ae8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11004&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11004&range=03-04 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/11004.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11004/head:pull/11004 PR: https://git.openjdk.org/jdk/pull/11004 From mdoerr at openjdk.org Tue Jan 10 15:16:56 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 10 Jan 2023 15:16:56 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames In-Reply-To: References: Message-ID: On Mon, 9 Jan 2023 10:30:06 GMT, Fredrik Bredberg wrote: > Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. > Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. > Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. Works on PPC64. Thanks! Tests have passed on other platforms as well. ------------- PR: https://git.openjdk.org/jdk/pull/11902 From aboldtch at openjdk.org Tue Jan 10 15:21:29 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 10 Jan 2023 15:21:29 GMT Subject: RFR: 8299089: Instrument global jni handles with tag to make them distinguishable [v2] In-Reply-To: References: Message-ID: > Weak global jni handles are tagged so the GC can distinguish them when resolving the object. Today there is no cheap way of distinguishing global jni handles from local jni handles. For generational ZGC the OopStorage handles and the thread local handles semantical difference requires the handles to be distinguishable. > > This enhancements instruments the jni handles with a global tag similarly to the jweak tag. > > Note: > * the s390 implementation has minimal changes and requires improvement. > * There is room for enchantment here to create the same abstraction that ppc uses for all platforms, i.e. move the resolve_jobject from the MacroAssembler to the BarrierSetAssembler which allows for more optimised code for GCs that can treat local and global handles the same. > > Testing: GHA. Oracle supported platforms tier1-3. Will run higher tiers. Has also been tested on the generational branch of ZGC for over three months. Requires testing on non Oracle platforms. Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision: - update copyright - albertnetymk feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11740/files - new: https://git.openjdk.org/jdk/pull/11740/files/3629e2e4..f4b8fde1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11740&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11740&range=00-01 Stats: 105 lines in 35 files changed: 14 ins; 8 del; 83 mod Patch: https://git.openjdk.org/jdk/pull/11740.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11740/head:pull/11740 PR: https://git.openjdk.org/jdk/pull/11740 From dcubed at openjdk.org Tue Jan 10 15:34:57 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 10 Jan 2023 15:34:57 GMT Subject: [jdk20] RFR: 8294744: AArch64: applications/kitchensink/Kitchensink.java crashed: assert(oopDesc::is_oop(obj)) failed: not an oop [v3] In-Reply-To: <77y-PdPY4NpS3fbdtF4mkeqZzzBFMu0GCU9wO-atEnw=.eddf48e9-3557-438f-9e6c-0cca495ec354@github.com> References: <77y-PdPY4NpS3fbdtF4mkeqZzzBFMu0GCU9wO-atEnw=.eddf48e9-3557-438f-9e6c-0cca495ec354@github.com> Message-ID: <0DWdojPWwuz1GmsVgq6VaiHWU-53kpBVsFpkRrgMZGk=.d43d08ce-b3cd-4228-a9e0-ef6c45bcbd10@github.com> On Mon, 9 Jan 2023 16:02:49 GMT, Patricio Chilano Mateo wrote: >> Please review the following patch. The value we set initially for extended_sp on natives frames doesn't account for the oop that could be pushed to the stack in case the method throws an exception. This can create a situation in Interpreter::_throw_exception_entry where we push an exception oop to the Java expression stack below the actual physical stack pointer. When JFR is present though a JavaThread could receive a suspend signal right after that push. On Linux aarch64, because there is no red zone defined (nor implemented it seems), the pushed oop gets overwritten during the setup and execution of the signal handler. This later leads to a crash when popping the oop back and rethrowing in the caller of the native method. There are more details in the bug comments. >> >> To fix it I used the same technique we use for normal Java frames, i.e. add extra space to extended_sp when creating the frame to account for the max space needed. >> >> >> >> I tested the patch by running Kitchensink.java around 150 times on mach5 with no failures (without the patch 50 runs would already show ~10 failures on average). I also run tiers1-6 for sanity check. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > add fix for riscv Thumbs up. Wonderful analysis in the bug report. You may want to attach your standalone reproducers to the bug report for future spelunkers. Thanks for including the testing information. src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 841: > 839: } else { > 840: // Make sure there is room for the exception oop pushed in case method throws > 841: // an exception (see TemplateInterpreterGenerator::generate_throw_exception()) I was going to request that you add a '.' to the end of this sentence, but it seems that lack of punctuation is the prevalent style in this file. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.org/jdk20/pull/85 From ayang at openjdk.org Tue Jan 10 16:14:55 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 10 Jan 2023 16:14:55 GMT Subject: RFR: 8299089: Instrument global jni handles with tag to make them distinguishable [v2] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 15:21:29 GMT, Axel Boldt-Christmas wrote: >> Weak global jni handles are tagged so the GC can distinguish them when resolving the object. Today there is no cheap way of distinguishing global jni handles from local jni handles. For generational ZGC the OopStorage handles and the thread local handles semantical difference requires the handles to be distinguishable. >> >> This enhancements instruments the jni handles with a global tag similarly to the jweak tag. >> >> Note: >> * the s390 implementation has minimal changes and requires improvement. >> * There is room for enchantment here to create the same abstraction that ppc uses for all platforms, i.e. move the resolve_jobject from the MacroAssembler to the BarrierSetAssembler which allows for more optimised code for GCs that can treat local and global handles the same. >> >> Testing: GHA. Oracle supported platforms tier1-3. Will run higher tiers. Has also been tested on the generational branch of ZGC for over three months. Requires testing on non Oracle platforms. > > Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision: > > - update copyright > - albertnetymk feedback I think `is_local/jweak/global` is clear enough; the `_tagged` suffix is impl-detail. src/hotspot/share/runtime/jniHandles.hpp line 69: > 67: enum TypeTag { > 68: local = 0b00, > 69: weak = 0b01, Maybe `jweak`? Just to be less ambiguous. src/hotspot/share/runtime/jniHandles.inline.hpp line 122: > 120: if (handle != NULL) { > 121: assert(!is_jweak_tagged(handle), "Invalid JNI local handle"); > 122: assert(!is_global_tagged(handle), "Invalid JNI local handle"); Why isn't `is_local_tagged` used here? ------------- Marked as reviewed by ayang (Reviewer). PR: https://git.openjdk.org/jdk/pull/11740 From mgronlun at openjdk.org Tue Jan 10 16:45:53 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 10 Jan 2023 16:45:53 GMT Subject: RFR: 8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly [v4] In-Reply-To: References: Message-ID: On Mon, 9 Jan 2023 14:19:32 GMT, Axel Boldt-Christmas wrote: >> In a similar vain to [JDK-8299089](https://bugs.openjdk.org/browse/JDK-8299089) there are different semantics for OopStorage and thread local oops. UnifiedOopRef in the jfr leakprofiler must be able to distinguish these and treat them appropriately. >> >> Testing: Running test at the moment. Has been running on the generational branch of ZGC for over three months. Not many tests exercise the leakprofiler. x86_32 has mostly been tested with GHA. >> >> Note: The accessBackend changes are only there to facilitate comparing OopLoadProxy objects directly with nullptr instead of creating and comparing with an `oop()` / `oop(NULL)`. Can be backed out of this PR and put in a different RFE instead. > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > stefank suggestion Marked as reviewed by mgronlun (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11741 From mgronlun at openjdk.org Tue Jan 10 16:45:53 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 10 Jan 2023 16:45:53 GMT Subject: RFR: 8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly [v2] In-Reply-To: References: <-Vajigb2X8yHp76kYNFVh58pp8XgB0A04odj5KEIFFw=.d7b72d1c-024f-4747-9a45-f4e9656b2f6a@github.com> <-Bw1QEa8ENJ4arP1p27jW5J3scq3G6LhTOrqdr3pww4=.1e170716-a01b-4e64-952a-b9e05aefbbfb@github.com> Message-ID: On Mon, 9 Jan 2023 07:21:12 GMT, Axel Boldt-Christmas wrote: >> Maybe the shift is needed in order to handle unaligned oops, as for code blob oops? The existing root processing logic has up to now skipped code blob oops, mainly because they were hard to encode. The rationale was that they are not roots in and of themselves. Now, we have seen several instances where chains are not found on iterations, so maybe the assumption on skipping code blob oops is wrong. With this encoding scheme in place, it would be possible to pass a closure for processing the code blob oops as well. > > Sorry for the tardy response. > > I think I forgot what the code was actually doing at the time of writing my previous answer. We are encoding ` narrowOop*` and `oop*` here not `narrowOop`/`oop`. And `narrowOop*` are 4 byte aligned. Thanks for the explanation, makes sense now. ------------- PR: https://git.openjdk.org/jdk/pull/11741 From duke at openjdk.org Tue Jan 10 16:56:31 2023 From: duke at openjdk.org (Afshin Zafari) Date: Tue, 10 Jan 2023 16:56:31 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v8] In-Reply-To: References: Message-ID: > test of tier1-5 passed. Afshin Zafari has updated the pull request incrementally with three additional commits since the last revision: - 8292741: Convert JvmtiTagMapTable to ResourceHashtable - 8292741: Convert JvmtiTagMapTable to ResourceHashtable - 8292741: Convert JvmtiTagMapTable to ResourceHashtable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11288/files - new: https://git.openjdk.org/jdk/pull/11288/files/d55d7612..9576b50a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=06-07 Stats: 14 lines in 3 files changed: 1 ins; 2 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/11288.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11288/head:pull/11288 PR: https://git.openjdk.org/jdk/pull/11288 From pchilanomate at openjdk.org Tue Jan 10 17:17:05 2023 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 10 Jan 2023 17:17:05 GMT Subject: [jdk20] RFR: 8294744: AArch64: applications/kitchensink/Kitchensink.java crashed: assert(oopDesc::is_oop(obj)) failed: not an oop [v3] In-Reply-To: <0DWdojPWwuz1GmsVgq6VaiHWU-53kpBVsFpkRrgMZGk=.d43d08ce-b3cd-4228-a9e0-ef6c45bcbd10@github.com> References: <77y-PdPY4NpS3fbdtF4mkeqZzzBFMu0GCU9wO-atEnw=.eddf48e9-3557-438f-9e6c-0cca495ec354@github.com> <0DWdojPWwuz1GmsVgq6VaiHWU-53kpBVsFpkRrgMZGk=.d43d08ce-b3cd-4228-a9e0-ef6c45bcbd10@github.com> Message-ID: On Tue, 10 Jan 2023 15:30:16 GMT, Daniel D. Daugherty wrote: > Thumbs up. Wonderful analysis in the bug report. You may want to attach your standalone reproducers to the bug report for future spelunkers. > > Thanks for including the testing information. > Thanks Dan! ------------- PR: https://git.openjdk.org/jdk20/pull/85 From pchilanomate at openjdk.org Tue Jan 10 17:17:07 2023 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 10 Jan 2023 17:17:07 GMT Subject: [jdk20] RFR: 8294744: AArch64: applications/kitchensink/Kitchensink.java crashed: assert(oopDesc::is_oop(obj)) failed: not an oop [v2] In-Reply-To: References: Message-ID: <0bA0KmzurxLLNhGKY8T9VlOhdAUKhrJ7io_IgP9Xt8k=.ee60e428-741e-4242-9973-1f3f56dcc342@github.com> On Sat, 7 Jan 2023 18:16:56 GMT, Andrew Haley wrote: >> Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8294744 >> - v1 > > Marked as reviewed by aph (Reviewer). Thanks for the reviews @theRealAph, @RealFYang and @dcubed-ojdk! ------------- PR: https://git.openjdk.org/jdk20/pull/85 From pchilanomate at openjdk.org Tue Jan 10 17:20:00 2023 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 10 Jan 2023 17:20:00 GMT Subject: [jdk20] Integrated: 8294744: AArch64: applications/kitchensink/Kitchensink.java crashed: assert(oopDesc::is_oop(obj)) failed: not an oop In-Reply-To: References: Message-ID: On Thu, 5 Jan 2023 20:24:25 GMT, Patricio Chilano Mateo wrote: > Please review the following patch. The value we set initially for extended_sp on natives frames doesn't account for the oop that could be pushed to the stack in case the method throws an exception. This can create a situation in Interpreter::_throw_exception_entry where we push an exception oop to the Java expression stack below the actual physical stack pointer. When JFR is present though a JavaThread could receive a suspend signal right after that push. On Linux aarch64, because there is no red zone defined (nor implemented it seems), the pushed oop gets overwritten during the setup and execution of the signal handler. This later leads to a crash when popping the oop back and rethrowing in the caller of the native method. There are more details in the bug comments. > > To fix it I used the same technique we use for normal Java frames, i.e. add extra space to extended_sp when creating the frame to account for the max space needed. > > > > I tested the patch by running Kitchensink.java around 150 times on mach5 with no failures (without the patch 50 runs would already show ~10 failures on average). I also run tiers1-6 for sanity check. > > Thanks, > Patricio This pull request has now been integrated. Changeset: 151450ea Author: Patricio Chilano Mateo URL: https://git.openjdk.org/jdk20/commit/151450ea9b78243130eb89a1c8ea9ad7ac13fb4a Stats: 10 lines in 2 files changed: 7 ins; 0 del; 3 mod 8294744: AArch64: applications/kitchensink/Kitchensink.java crashed: assert(oopDesc::is_oop(obj)) failed: not an oop Co-authored-by: Fei Yang Reviewed-by: aph, fyang, dcubed ------------- PR: https://git.openjdk.org/jdk20/pull/85 From duke at openjdk.org Tue Jan 10 19:17:56 2023 From: duke at openjdk.org (Ashutosh Mehra) Date: Tue, 10 Jan 2023 19:17:56 GMT Subject: RFR: 8297914: Remove java_lang_Class::process_archived_mirror() In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 21:01:28 GMT, Ioi Lam wrote: > This is another prerequisite for [JDK-8296344](https://bugs.openjdk.org/browse/JDK-8296344). > > Before this PR, when archiving mirror objects (i.e., instances of `java.lang.Class`): > - We first allocate a copy of the mirror inside a safepoint. > - We then reinitialize the contents of the copy to the desired state (so that it can be used by `Klass::restore_unshareable_info()` > > This copy-and-modify operation inside the safepoint makes it difficult to implement [JDK-8296344](https://bugs.openjdk.org/browse/JDK-8296344). It violates the requirements [1] and [2] as stated in [JDK-8298600](https://bugs.openjdk.org/browse/JDK-8298600). Also, the reinitialization code is complicated. > > After this PR: > - During the creation of each regular mirror object, we allocate a "scratch mirror" object, which has the states as expected by `Klass::restore_unshareable_info()`. See `java_lang_Class::create_scratch_mirror()`. > - When the archive heap is dumped inside a safepoint, we use the scratch mirror, so we can avoid the copy-and-modify operation. See `HeapShared::archive_java_mirrors()`. > > Testing: tiers 1-4 src/hotspot/share/cds/heapShared.cpp line 379: > 377: }; > 378: > 379: static KlassToOopHandleTable* _scratch_java_mirror_table = NULL; Any reason why `_scratch_basic_type_mirrors` is a static member of `HeapShared` but `_scratch_java_mirror_table` is not? src/hotspot/share/classfile/javaClasses.cpp line 1347: > 1345: assert(java_class == Universe::void_mirror(), "only valid non-array primitive"); > 1346: } > 1347: assert(Universe::java_mirror(type) == java_class || If we need the condition `HeapShared::scratch_java_mirror(type) == java_class` here, shouldn't the previous assert be also updated to check for scratch java mirror for void type? `assert(java_class == Universe::void_mirror() |, "only valid non-array primitive");` ------------- PR: https://git.openjdk.org/jdk/pull/11853 From dcubed at openjdk.org Tue Jan 10 20:14:57 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 10 Jan 2023 20:14:57 GMT Subject: RFR: 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug [v4] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 11:57:22 GMT, Afshin Zafari wrote: >> ### Description >> The following problems found and solved: >> >> 1) Reporting which regex pattern did not match with error messages was incorrect. To report the mismatched pattern, the head of the pattern list was peeked, while it was the already peeked item from that did not match. So the next pattern to the mismatched one was reported. >> >> 2) The pattern for finding a crash was incorrectly set to "# .*VMError::controlled_crash.*", while it has to be "# .*crash_with_segfault.*". >> >> 3) `crash_with_segfault` function is too small and was `inline`d in compiler optimisations. So it was not in the stack trace when the error message is created. >> >> ### Patch >> 1 and 2 corrected and added the `NOINLINE` to the `crash_with_segfault` signature. The same applied for `crash_with_sigfpe` function. >> >> ### Test >> runtime/ErrorHandling/* and tier1-5 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug You need to backout the copyright year changes to the two test files that are no longer modified by this patch. test/hotspot/jtreg/runtime/ErrorHandling/SecondaryErrorTest.java line 3: > 1: /* > 2: * Copyright (c) 2014, 2022 SAP SE. All rights reserved. > 3: * Copyright (c) 2014, 2023, Oracle and/or its affiliates. All rights reserved. There are no longer any changes to this file in this patch so the copyright year update should be backed out. test/hotspot/jtreg/runtime/ErrorHandling/TestSigInfoInHsErrFile.java line 2: > 1: /* > 2: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. There are no longer any changes to this file in this patch so the copyright year update should be backed out. ------------- Changes requested by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/11704 From ccheung at openjdk.org Tue Jan 10 20:21:25 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Tue, 10 Jan 2023 20:21:25 GMT Subject: RFR: 8298321: 2 File Leak defect groups in 2 files [v4] In-Reply-To: References: Message-ID: <1J9SHwg1ycL8uYN5ITZXeOEmzTNqZxVYEQ_cNhTQxeg=.817d96eb-8746-4af0-9b88-09a52956942d@github.com> > Please review this simple change for fixing two file leak warnings: > 1) DirectivesParser::parse_from_file_inner() in open/src/hotspot/share/compiler/directivesParser.cpp > 2) mmap_attach_shared() in open/src/hotspot/os/posix/perfMemory_posix.cpp > > Please refer to the [comment](https://bugs.openjdk.org/browse/JDK-8298321?focusedCommentId=14549361&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14549361) in the bug report for details. > > Passed tiers 1 and 2 testing. Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: move the ::close call to immediately after ::read ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11909/files - new: https://git.openjdk.org/jdk/pull/11909/files/56980b79..6439276c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11909&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11909&range=02-03 Stats: 4 lines in 1 file changed: 1 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11909.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11909/head:pull/11909 PR: https://git.openjdk.org/jdk/pull/11909 From ccheung at openjdk.org Tue Jan 10 20:21:26 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Tue, 10 Jan 2023 20:21:26 GMT Subject: RFR: 8298321: 2 File Leak defect groups in 2 files [v3] In-Reply-To: References: Message-ID: <80ytz5zwYXLeAAQE9ChmGPl9D0iDY-Gbvrr2CRuNMxY=.39d7fb30-17ee-4e80-bd13-29d179fcca77@github.com> On Tue, 10 Jan 2023 05:01:42 GMT, David Holmes wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> @iklam comment > > src/hotspot/os/posix/perfMemory_posix.cpp line 1209: > >> 1207: >> 1208: if (HAS_PENDING_EXCEPTION) { >> 1209: assert(fd == OS_ERR, "open_sharedmem_file always return OS_ERR on exceptions"); > > Does this really appease the static analysis tool? The static analysis tool should be fine about the above change. As I mentioned in the bug report, the warning is regarding the fd is not closed under the conditions HAS_PENDING_EXCEPTION and fd != OS_ERR. I will run rerun the test to be sure. > src/hotspot/share/compiler/directivesParser.cpp line 105: > >> 103: return parse_string(buffer, stream) > 0; >> 104: } >> 105: ::close(file_handle); > > You could just move the existing `::close` to before the `if` statement ie close it immediately after the read. I agree and have pushed another commit with your suggestion. ------------- PR: https://git.openjdk.org/jdk/pull/11909 From jcking at openjdk.org Tue Jan 10 21:10:38 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 10 Jan 2023 21:10:38 GMT Subject: RFR: JDK-8299386: Refactor metaprogramming to use In-Reply-To: <4IgAzvExdRfJLSpdv2zIG1hMdZHJLKOv62FMP6IyAPg=.bf4322b6-83ed-4cc7-a1e7-81333079afd8@github.com> References: <4IgAzvExdRfJLSpdv2zIG1hMdZHJLKOv62FMP6IyAPg=.bf4322b6-83ed-4cc7-a1e7-81333079afd8@github.com> Message-ID: <8aO32Ok7zfODDuqZt7DZWf2G3phjIEnhiL1j16JBSQI=.74a4b71f-bac8-4922-83c9-af050386f8e6@github.com> On Wed, 28 Dec 2022 06:00:59 GMT, Justin King wrote: > Cleanup `metaprogramming/` to just use implementations from `` that are available in C++11 and onward. Backing out since this is being addressed in multiple separate PRs. ------------- PR: https://git.openjdk.org/jdk/pull/11794 From jcking at openjdk.org Tue Jan 10 21:10:39 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 10 Jan 2023 21:10:39 GMT Subject: Withdrawn: JDK-8299386: Refactor metaprogramming to use In-Reply-To: <4IgAzvExdRfJLSpdv2zIG1hMdZHJLKOv62FMP6IyAPg=.bf4322b6-83ed-4cc7-a1e7-81333079afd8@github.com> References: <4IgAzvExdRfJLSpdv2zIG1hMdZHJLKOv62FMP6IyAPg=.bf4322b6-83ed-4cc7-a1e7-81333079afd8@github.com> Message-ID: <4ZLxx11t9qljJh_ki1PWPRkgLok5J4nmMcYjU4p_drc=.96289226-6a3b-4acd-942d-10f42c00227e@github.com> On Wed, 28 Dec 2022 06:00:59 GMT, Justin King wrote: > Cleanup `metaprogramming/` to just use implementations from `` that are available in C++11 and onward. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/11794 From jcking at openjdk.org Tue Jan 10 21:33:49 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 10 Jan 2023 21:33:49 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code Message-ID: Remove abstraction that is a holdover from Solaris. Direct usages of `MmapArrayAllocator` have been switched to normal `malloc`. The justification is that none of the code paths are called from signal handlers, so using `mmap` directly does not make sense and is potentially slower than going through `malloc` which can potentially re-use memory without making any system calls. The remaining usages of `ArrayAllocator` and `MallocArrayAllocator` are equivalent. ------------- Commit messages: - Use REALLOC_C_HEAP_ARRAY instead of NEW_C_HEAP_ARRAY/FREE_C_HEAP_ARRAY - Remove ArrayAllocatorMallocLimit Changes: https://git.openjdk.org/jdk/pull/11931/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299915 Stats: 336 lines in 13 files changed: 13 ins; 308 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/11931.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11931/head:pull/11931 PR: https://git.openjdk.org/jdk/pull/11931 From jcking at openjdk.org Tue Jan 10 21:41:21 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 10 Jan 2023 21:41:21 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v2] In-Reply-To: References: Message-ID: <0HxKoxC-2_7geQqXlYUZGcq-X6Q1ijKrIY42Sof8OcQ=.b3b8790f-74d6-40bd-b029-6c14dd1fd67c@github.com> > Remove abstraction that is a holdover from Solaris. Direct usages of `MmapArrayAllocator` have been switched to normal `malloc`. The justification is that none of the code paths are called from signal handlers, so using `mmap` directly does not make sense and is potentially slower than going through `malloc` which can potentially re-use memory without making any system calls. The remaining usages of `ArrayAllocator` and `MallocArrayAllocator` are equivalent. Justin King has updated the pull request incrementally with one additional commit since the last revision: Use unconstrained flag for SizeTTest.java Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11931/files - new: https://git.openjdk.org/jdk/pull/11931/files/efb1a8b3..9e96ddb9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11931.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11931/head:pull/11931 PR: https://git.openjdk.org/jdk/pull/11931 From dholmes at openjdk.org Tue Jan 10 22:15:16 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 10 Jan 2023 22:15:16 GMT Subject: RFR: 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug [v4] In-Reply-To: References: Message-ID: <9TTBu0KxvQlopA9GaF4geaOKaRgsGSi3hD14IR4et6U=.11dd3334-eee1-4ca4-a432-0e3f669d4ba7@github.com> On Tue, 10 Jan 2023 11:57:22 GMT, Afshin Zafari wrote: >> ### Description >> The following problems found and solved: >> >> 1) Reporting which regex pattern did not match with error messages was incorrect. To report the mismatched pattern, the head of the pattern list was peeked, while it was the already peeked item from that did not match. So the next pattern to the mismatched one was reported. >> >> 2) The pattern for finding a crash was incorrectly set to "# .*VMError::controlled_crash.*", while it has to be "# .*crash_with_segfault.*". >> >> 3) `crash_with_segfault` function is too small and was `inline`d in compiler optimisations. So it was not in the stack trace when the error message is created. >> >> ### Patch >> 1 and 2 corrected and added the `NOINLINE` to the `crash_with_segfault` signature. The same applied for `crash_with_sigfpe` function. >> >> ### Test >> runtime/ErrorHandling/* and tier1-5 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug Looks good modulo the copyright changes that need undoing. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/11704 From dholmes at openjdk.org Tue Jan 10 22:17:15 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 10 Jan 2023 22:17:15 GMT Subject: RFR: 8298321: 2 File Leak defect groups in 2 files [v4] In-Reply-To: <1J9SHwg1ycL8uYN5ITZXeOEmzTNqZxVYEQ_cNhTQxeg=.817d96eb-8746-4af0-9b88-09a52956942d@github.com> References: <1J9SHwg1ycL8uYN5ITZXeOEmzTNqZxVYEQ_cNhTQxeg=.817d96eb-8746-4af0-9b88-09a52956942d@github.com> Message-ID: On Tue, 10 Jan 2023 20:21:25 GMT, Calvin Cheung wrote: >> Please review this simple change for fixing two file leak warnings: >> 1) DirectivesParser::parse_from_file_inner() in open/src/hotspot/share/compiler/directivesParser.cpp >> 2) mmap_attach_shared() in open/src/hotspot/os/posix/perfMemory_posix.cpp >> >> Please refer to the [comment](https://bugs.openjdk.org/browse/JDK-8298321?focusedCommentId=14549361&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14549361) in the bug report for details. >> >> Passed tiers 1 and 2 testing. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > move the ::close call to immediately after ::read Thanks for the update. Pre-approval pending that final check as I'm away for a few days. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/11909 From dholmes at openjdk.org Tue Jan 10 22:17:18 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 10 Jan 2023 22:17:18 GMT Subject: RFR: 8298321: 2 File Leak defect groups in 2 files [v3] In-Reply-To: <80ytz5zwYXLeAAQE9ChmGPl9D0iDY-Gbvrr2CRuNMxY=.39d7fb30-17ee-4e80-bd13-29d179fcca77@github.com> References: <80ytz5zwYXLeAAQE9ChmGPl9D0iDY-Gbvrr2CRuNMxY=.39d7fb30-17ee-4e80-bd13-29d179fcca77@github.com> Message-ID: On Tue, 10 Jan 2023 20:16:37 GMT, Calvin Cheung wrote: >> src/hotspot/os/posix/perfMemory_posix.cpp line 1209: >> >>> 1207: >>> 1208: if (HAS_PENDING_EXCEPTION) { >>> 1209: assert(fd == OS_ERR, "open_sharedmem_file always return OS_ERR on exceptions"); >> >> Does this really appease the static analysis tool? > > The static analysis tool should be fine about the above change. As I mentioned in the bug report, the warning is regarding the fd is not closed under the conditions HAS_PENDING_EXCEPTION and fd != OS_ERR. > I will run rerun the test to be sure. Do we need to test both debug and release builds? The debug build should be fine due to the assert, but in release build ... ------------- PR: https://git.openjdk.org/jdk/pull/11909 From jcking at openjdk.org Tue Jan 10 22:24:26 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 10 Jan 2023 22:24:26 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v3] In-Reply-To: References: Message-ID: > Remove abstraction that is a holdover from Solaris. Direct usages of `MmapArrayAllocator` have been switched to normal `malloc`. The justification is that none of the code paths are called from signal handlers, so using `mmap` directly does not make sense and is potentially slower than going through `malloc` which can potentially re-use memory without making any system calls. The remaining usages of `ArrayAllocator` and `MallocArrayAllocator` are equivalent. Justin King has updated the pull request incrementally with one additional commit since the last revision: Remove ArrayAllocatorMallocLimit test Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11931/files - new: https://git.openjdk.org/jdk/pull/11931/files/9e96ddb9..235abed3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=01-02 Stats: 100 lines in 1 file changed: 0 ins; 100 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11931.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11931/head:pull/11931 PR: https://git.openjdk.org/jdk/pull/11931 From jcking at openjdk.org Tue Jan 10 22:50:11 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 10 Jan 2023 22:50:11 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v4] In-Reply-To: References: Message-ID: > Remove abstraction that is a holdover from Solaris. Direct usages of `MmapArrayAllocator` have been switched to normal `malloc`. The justification is that none of the code paths are called from signal handlers, so using `mmap` directly does not make sense and is potentially slower than going through `malloc` which can potentially re-use memory without making any system calls. The remaining usages of `ArrayAllocator` and `MallocArrayAllocator` are equivalent. Justin King has updated the pull request incrementally with one additional commit since the last revision: Initialize memory to zero in zGranuleMap Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11931/files - new: https://git.openjdk.org/jdk/pull/11931/files/235abed3..3216fb19 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=02-03 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11931.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11931/head:pull/11931 PR: https://git.openjdk.org/jdk/pull/11931 From coleenp at openjdk.org Tue Jan 10 23:43:18 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 10 Jan 2023 23:43:18 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v8] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 16:56:31 GMT, Afshin Zafari wrote: >> test of tier1-5 passed. > > Afshin Zafari has updated the pull request incrementally with three additional commits since the last revision: > > - 8292741: Convert JvmtiTagMapTable to ResourceHashtable > - 8292741: Convert JvmtiTagMapTable to ResourceHashtable > - 8292741: Convert JvmtiTagMapTable to ResourceHashtable Changes requested by coleenp (Reviewer). src/hotspot/share/prims/jvmtiTagMap.cpp line 195: > 193: JvmtiTagMap* _tag_map; > 194: JvmtiTagMapTable* _hashmap; > 195: bool _entry_found; is this used? src/hotspot/share/prims/jvmtiTagMapTable.hpp line 44: > 42: // Its get_hash() and equals() methods are also used for getting the hash > 43: // value of a Key and comparing two Keys, respectively. > 44: class JvmtiTagMapKey : public CHeapObj { Can you change mtInternal to mtServiceability here? ------------- PR: https://git.openjdk.org/jdk/pull/11288 From coleenp at openjdk.org Tue Jan 10 23:48:21 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 10 Jan 2023 23:48:21 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v8] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 16:56:31 GMT, Afshin Zafari wrote: >> test of tier1-5 passed. > > Afshin Zafari has updated the pull request incrementally with three additional commits since the last revision: > > - 8292741: Convert JvmtiTagMapTable to ResourceHashtable > - 8292741: Convert JvmtiTagMapTable to ResourceHashtable > - 8292741: Convert JvmtiTagMapTable to ResourceHashtable src/hotspot/share/prims/jvmtiTagMap.cpp line 442: > 440: delete _fields->at(i); > 441: } > 442: delete _fields; The changes here to ClassFieldMap are not part of the change, can you revert them (also leave mtInternal even though that's wrong). src/hotspot/share/prims/jvmtiTagMap.hpp line 37: > 35: class JvmtiTagMapKeyClosure; > 36: > 37: class JvmtiTagMap : public CHeapObj { Change to mtServiceability src/hotspot/share/prims/jvmtiTagMapTable.hpp line 76: > 74: JvmtiTagMapKey::equals> ResizableResourceHT; > 75: > 76: class JvmtiTagMapTable : public CHeapObj { Change this to mtServiceability ------------- PR: https://git.openjdk.org/jdk/pull/11288 From kbarrett at openjdk.org Wed Jan 11 04:46:10 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 11 Jan 2023 04:46:10 GMT Subject: RFR: 8299673: Simplify object pinning interactions with string deduplication In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 10:04:48 GMT, Erik ?sterlund wrote: > When raw char* String contents are exposed to JNI code, we > > 1. Load the string.value and pin it > 2. Run native code > 3. Load the string.value and unpin it > > Given this sequence we would be in trouble if between 1 and 3, string deduplication changed the value object. Then the pinning and unpinning wouldn't be balanced. > > The current approach for dealing with this is to have a bunch of code to guard against deduplication. An alternative simpler solution is to just change step 3 to pass in the same value. We already have enough information available to do that. Then the pinning and unpinning is also balanced, and we don't need to have any special interactions with string deduplication and can decouple these orthogonal concerns. > > It's worth noting though that the contract of pin_object now makes it explicit that pinned objects must not be recycled, even if not otherwise reachable. That seems to come naturally for region based pinning, but is worth keeping in mind. The exposed char* might be the only thing referencing the string value when string dedup happens concurrently. Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/11923 From jcking at openjdk.org Wed Jan 11 05:35:22 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 11 Jan 2023 05:35:22 GMT Subject: Integrated: JDK-8299479: Remove metaprogramming/decay.hpp In-Reply-To: References: Message-ID: On Mon, 2 Jan 2023 21:03:51 GMT, Justin King wrote: > Code cleanup of pre-C++11 implementations. This pull request has now been integrated. Changeset: 10a747c7 Author: Justin King Committer: Kim Barrett URL: https://git.openjdk.org/jdk/commit/10a747c70bb957b7dd268009e6062771085b97eb Stats: 104 lines in 3 files changed: 0 ins; 90 del; 14 mod 8299479: Remove metaprogramming/decay.hpp Reviewed-by: tschatzl, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/11816 From jcking at openjdk.org Wed Jan 11 05:37:17 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 11 Jan 2023 05:37:17 GMT Subject: Integrated: JDK-8299482: Remove metaprogramming/isIntegral.hpp In-Reply-To: References: Message-ID: On Mon, 2 Jan 2023 22:36:37 GMT, Justin King wrote: > Code cleanup of pre-C++11 implementations. This pull request has now been integrated. Changeset: f312c999 Author: Justin King Committer: Kim Barrett URL: https://git.openjdk.org/jdk/commit/f312c99977635a0c54600016c0814a64f8aff2ef Stats: 141 lines in 5 files changed: 3 ins; 124 del; 14 mod 8299482: Remove metaprogramming/isIntegral.hpp Reviewed-by: kbarrett, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/11818 From aboldtch at openjdk.org Wed Jan 11 06:47:14 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 11 Jan 2023 06:47:14 GMT Subject: RFR: 8299089: Instrument global jni handles with tag to make them distinguishable [v2] In-Reply-To: References: Message-ID: <0UGFgiO6PZ9KhIaamGW8t1GpRgj1lGD1CBnMQ2iO5ww=.6bb06697-517a-4241-a328-cb1f619a225e@github.com> On Tue, 10 Jan 2023 16:11:37 GMT, Albert Mingkun Yang wrote: > I think `is_local/jweak/global` is clear enough; the `_tagged` suffix is impl-detail. I think the tag suffix is fine, it is a private shorthand function to check the tag value. The public methods never mention tags. So the implementation detail is not leaked. > src/hotspot/share/runtime/jniHandles.hpp line 69: > >> 67: enum TypeTag { >> 68: local = 0b00, >> 69: weak = 0b01, > > Maybe `jweak`? Just to be less ambiguous. I think I should fix all the references, currently we use `global weak`, `weak global`, `weak` and `jweak`. jweak belongs to C, it is just a typedef to make the API signatures more clear (it is the same type as jobject). And use `weak global` everywhere which is how the C API actually names the types: typedef enum _jobjectType { JNIInvalidRefType = 0, JNILocalRefType = 1, JNIGlobalRefType = 2, JNIWeakGlobalRefType = 3 } jobjectRefType; > src/hotspot/share/runtime/jniHandles.inline.hpp line 122: > >> 120: if (handle != NULL) { >> 121: assert(!is_jweak_tagged(handle), "Invalid JNI local handle"); >> 122: assert(!is_global_tagged(handle), "Invalid JNI local handle"); > > Why isn't `is_local_tagged` used here? Yeah I just missed it. I see there are more asserts which should just be one tag check. Will fix. ------------- PR: https://git.openjdk.org/jdk/pull/11740 From aboldtch at openjdk.org Wed Jan 11 07:32:25 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 11 Jan 2023 07:32:25 GMT Subject: RFR: 8299089: Instrument global jni handles with tag to make them distinguishable [v3] In-Reply-To: References: Message-ID: > Weak global jni handles are tagged so the GC can distinguish them when resolving the object. Today there is no cheap way of distinguishing global jni handles from local jni handles. For generational ZGC the OopStorage handles and the thread local handles semantical difference requires the handles to be distinguishable. > > This enhancements instruments the jni handles with a global tag similarly to the jweak tag. > > Note: > * the s390 implementation has minimal changes and requires improvement. > * There is room for enchantment here to create the same abstraction that ppc uses for all platforms, i.e. move the resolve_jobject from the MacroAssembler to the BarrierSetAssembler which allows for more optimised code for GCs that can treat local and global handles the same. > > Testing: GHA. Oracle supported platforms tier1-3. Will run higher tiers. Has also been tested on the generational branch of ZGC for over three months. Requires testing on non Oracle platforms. Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision: - change names - cleanup asserts ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11740/files - new: https://git.openjdk.org/jdk/pull/11740/files/f4b8fde1..4e061678 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11740&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11740&range=01-02 Stats: 53 lines in 11 files changed: 2 ins; 8 del; 43 mod Patch: https://git.openjdk.org/jdk/pull/11740.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11740/head:pull/11740 PR: https://git.openjdk.org/jdk/pull/11740 From yadongwang at openjdk.org Wed Jan 11 08:20:18 2023 From: yadongwang at openjdk.org (Yadong Wang) Date: Wed, 11 Jan 2023 08:20:18 GMT Subject: RFR: 8299844: RISC-V: Implement _onSpinWait intrinsic Message-ID: Implement _onSpinWait() intrinsic for RISC-V, and it can be implemented by using PAUSE instruction from Zihintpause Extension, which is ratified and a mandatory extension of RVA22U64 (https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#rva22u64-mandatory-extensions). Software can use the PAUSE instruction to reduce energy consumption while executing spinwait code sequences (https://github.com/riscv/riscv-isa-manual/blob/master/src/zihintpause.tex). Add a test case of test/hotspot/jtreg/compiler/onSpinWait/TestOnSpinWaitRISCV64.java, passed on QEMU. ------------- Commit messages: - fix whitespace - 8299844: RISC-V: Implement _onSpinWait intrinsic Changes: https://git.openjdk.org/jdk/pull/11921/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11921&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299844 Stats: 126 lines in 7 files changed: 119 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/11921.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11921/head:pull/11921 PR: https://git.openjdk.org/jdk/pull/11921 From duke at openjdk.org Wed Jan 11 09:22:03 2023 From: duke at openjdk.org (Fredrik Bredberg) Date: Wed, 11 Jan 2023 09:22:03 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v2] In-Reply-To: References: Message-ID: > Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. > Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. > Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: Updated some copyright dates. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11902/files - new: https://git.openjdk.org/jdk/pull/11902/files/342d1465..54a0931d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11902&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11902&range=00-01 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11902.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11902/head:pull/11902 PR: https://git.openjdk.org/jdk/pull/11902 From stefank at openjdk.org Wed Jan 11 09:25:15 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 11 Jan 2023 09:25:15 GMT Subject: RFR: 8299673: Simplify object pinning interactions with string deduplication In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 10:04:48 GMT, Erik ?sterlund wrote: > When raw char* String contents are exposed to JNI code, we > > 1. Load the string.value and pin it > 2. Run native code > 3. Load the string.value and unpin it > > Given this sequence we would be in trouble if between 1 and 3, string deduplication changed the value object. Then the pinning and unpinning wouldn't be balanced. > > The current approach for dealing with this is to have a bunch of code to guard against deduplication. An alternative simpler solution is to just change step 3 to pass in the same value. We already have enough information available to do that. Then the pinning and unpinning is also balanced, and we don't need to have any special interactions with string deduplication and can decouple these orthogonal concerns. > > It's worth noting though that the contract of pin_object now makes it explicit that pinned objects must not be recycled, even if not otherwise reachable. That seems to come naturally for region based pinning, but is worth keeping in mind. The exposed char* might be the only thing referencing the string value when string dedup happens concurrently. Marked as reviewed by stefank (Reviewer). src/hotspot/share/gc/z/zCollectedHeap.cpp line 27: > 25: #include "classfile/classLoaderData.hpp" > 26: #include "gc/shared/gcLocker.inline.hpp" > 27: #include "gc/shared/gcHeapSummary.hpp" Sort order ------------- PR: https://git.openjdk.org/jdk/pull/11923 From duke at openjdk.org Wed Jan 11 09:40:23 2023 From: duke at openjdk.org (Afshin Zafari) Date: Wed, 11 Jan 2023 09:40:23 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v8] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 23:36:37 GMT, Coleen Phillimore wrote: >> Afshin Zafari has updated the pull request incrementally with three additional commits since the last revision: >> >> - 8292741: Convert JvmtiTagMapTable to ResourceHashtable >> - 8292741: Convert JvmtiTagMapTable to ResourceHashtable >> - 8292741: Convert JvmtiTagMapTable to ResourceHashtable > > src/hotspot/share/prims/jvmtiTagMap.cpp line 195: > >> 193: JvmtiTagMap* _tag_map; >> 194: JvmtiTagMapTable* _hashmap; >> 195: bool _entry_found; > > is this used? It isn't used. Removed. ------------- PR: https://git.openjdk.org/jdk/pull/11288 From duke at openjdk.org Wed Jan 11 09:42:19 2023 From: duke at openjdk.org (Afshin Zafari) Date: Wed, 11 Jan 2023 09:42:19 GMT Subject: RFR: 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug [v5] In-Reply-To: References: Message-ID: > ### Description > The following problems found and solved: > > 1) Reporting which regex pattern did not match with error messages was incorrect. To report the mismatched pattern, the head of the pattern list was peeked, while it was the already peeked item from that did not match. So the next pattern to the mismatched one was reported. > > 2) The pattern for finding a crash was incorrectly set to "# .*VMError::controlled_crash.*", while it has to be "# .*crash_with_segfault.*". > > 3) `crash_with_segfault` function is too small and was `inline`d in compiler optimisations. So it was not in the stack trace when the error message is created. > > ### Patch > 1 and 2 corrected and added the `NOINLINE` to the `crash_with_segfault` signature. The same applied for `crash_with_sigfpe` function. > > ### Test > runtime/ErrorHandling/* and tier1-5 Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11704/files - new: https://git.openjdk.org/jdk/pull/11704/files/430f0210..653b3739 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11704&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11704&range=03-04 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11704.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11704/head:pull/11704 PR: https://git.openjdk.org/jdk/pull/11704 From stefank at openjdk.org Wed Jan 11 10:08:17 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 11 Jan 2023 10:08:17 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v4] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 22:50:11 GMT, Justin King wrote: >> Remove abstraction that is a holdover from Solaris. Direct usages of `MmapArrayAllocator` have been switched to normal `malloc`. The justification is that none of the code paths are called from signal handlers, so using `mmap` directly does not make sense and is potentially slower than going through `malloc` which can potentially re-use memory without making any system calls. The remaining usages of `ArrayAllocator` and `MallocArrayAllocator` are equivalent. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Initialize memory to zero in zGranuleMap > > Signed-off-by: Justin King I'm happy to see this flag getting removed. I'm less happy about seeing usages of the array allocators being replaced by macros. I'd rather see an effort towards getting rid of these macros. Could we limit this patch to only remove the ArrayAllocatorMallocLimit flag and ArrayAllocator class, and defer the discussion around what API to use for array allocations? ------------- PR: https://git.openjdk.org/jdk/pull/11931 From duke at openjdk.org Wed Jan 11 10:10:45 2023 From: duke at openjdk.org (Afshin Zafari) Date: Wed, 11 Jan 2023 10:10:45 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v9] In-Reply-To: References: Message-ID: > test of tier1-5 passed. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: 8292741: Convert JvmtiTagMapTable to ResourceHashtable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11288/files - new: https://git.openjdk.org/jdk/pull/11288/files/9576b50a..b90aad6e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=07-08 Stats: 8 lines in 4 files changed: 1 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/11288.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11288/head:pull/11288 PR: https://git.openjdk.org/jdk/pull/11288 From duke at openjdk.org Wed Jan 11 10:10:45 2023 From: duke at openjdk.org (Afshin Zafari) Date: Wed, 11 Jan 2023 10:10:45 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7] In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 14:13:05 GMT, Coleen Phillimore wrote: >> The issue is not the underlying RHT methods but the semantics of the `jvmtiTagMap` methods. If a call to add always expects to add then it should be a fatal error if it actually did an update as that indicates something is broken. Similarly if an update actually does an add. > > The JvmtiTagMap code adds/updates and removes the entries like below in two places which could probably be simplified, but I think that's outside the scope of this RFE. I suggest removing the bool return from add, remove and update, and add the assert(true) in the remove case. There's already an assert that add/update happened in the other cases. > > ``` // if the object is not already tagged then we tag it > if (found_tag == 0) { > if (tag != 0) { > hashmap->add(o, tag); > } else { > // no-op > } > } else { > // if the object is already tagged then we either update > // the tag (if a new tag value has been provided) > // or remove the object if the new tag value is 0. > if (tag == 0) { > hashmap->remove(o); > } else { > hashmap->update(o, tag); > } > } The methods of HashmapTable are void and have assert to verify the expected function (add/update/remove) is done. ------------- PR: https://git.openjdk.org/jdk/pull/11288 From duke at openjdk.org Wed Jan 11 10:49:59 2023 From: duke at openjdk.org (Afshin Zafari) Date: Wed, 11 Jan 2023 10:49:59 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v10] In-Reply-To: References: Message-ID: <1vK1PJLqYXa1wlcJrSnyFjtiumgX_nb8G178zv3X-c8=.ea74be21-8518-41d8-8fba-f2f5d6267a44@github.com> > test of tier1-5 passed. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: 8292741: Convert JvmtiTagMapTable to ResourceHashtable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11288/files - new: https://git.openjdk.org/jdk/pull/11288/files/b90aad6e..b5a93bd5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=08-09 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11288.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11288/head:pull/11288 PR: https://git.openjdk.org/jdk/pull/11288 From mbaesken at openjdk.org Wed Jan 11 11:23:09 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 11 Jan 2023 11:23:09 GMT Subject: RFR: JDK-8299672: Enhance HeapDump JFR event [v2] In-Reply-To: References: Message-ID: > Enhance the JFR Event HeapDump with the additional interesting fields, compression and overwrite. > Add some UL logging in case the heap dump writing failed . Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Adjust compression check to below in TestHeapDump.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11864/files - new: https://git.openjdk.org/jdk/pull/11864/files/750ccf90..8543c307 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11864&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11864&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11864.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11864/head:pull/11864 PR: https://git.openjdk.org/jdk/pull/11864 From mbaesken at openjdk.org Wed Jan 11 11:23:12 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 11 Jan 2023 11:23:12 GMT Subject: RFR: JDK-8299672: Enhance HeapDump JFR event [v2] In-Reply-To: References: Message-ID: On Mon, 9 Jan 2023 09:39:00 GMT, Ralf Schmelter wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> Adjust compression check to below in TestHeapDump.java > > test/jdk/jdk/jfr/event/diagnostics/TestHeapDump.java line 68: > >> 66: Events.assertField(e, "onOutOfMemoryError").equal(false); >> 67: Events.assertField(e, "size").equal(Files.size(path)); >> 68: Events.assertField(e, "compression").equal(-1); > > I would use below(1) instead of equals(-1), since it is not specified which value < 1 is used when gzip compression is not enabled. Or you could do the sanitizing when storing the value in the event itself. But in that case I would probably use 0 instead of -1. Hi Ralf, thanks for the review. I adjusted the test as suggested. ------------- PR: https://git.openjdk.org/jdk/pull/11864 From clanger at openjdk.org Wed Jan 11 11:27:19 2023 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 11 Jan 2023 11:27:19 GMT Subject: RFR: JDK-8299672: Enhance HeapDump JFR event [v2] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 11:23:09 GMT, Matthias Baesken wrote: >> Enhance the JFR Event HeapDump with the additional interesting fields, compression and overwrite. >> Add some UL logging in case the heap dump writing failed . > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust compression check to below in TestHeapDump.java Some spelling issues, for consistency. src/hotspot/share/jfr/metadata/metadata.xml line 1147: > 1145: > 1146: > 1147: 1147: 1148: stackTrace="true" thread="true"> > 1149: Spelling: In the label we'd write Path and Dump in capitals src/hotspot/share/jfr/metadata/metadata.xml line 1152: > 1150: > 1151: > 1152: Also here: "Dump" in capitals in the label src/hotspot/share/jfr/metadata/metadata.xml line 1154: > 1152: > 1153: > 1154: Here, in description, use small letter for "dump" ------------- Changes requested by clanger (Reviewer). PR: https://git.openjdk.org/jdk/pull/11864 From thartmann at openjdk.org Wed Jan 11 11:38:00 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 11 Jan 2023 11:38:00 GMT Subject: RFR: 8299956: [BACKOUT] 8297487: G1 Remark: no need to keep alive oop constants of nmethods on stack Message-ID: Clean backout after we observed various crashes with different tests after the integration of [JDK-8297487](https://bugs.openjdk.org/browse/JDK-8297487). Thanks, Tobias ------------- Commit messages: - Revert "8297487: G1 Remark: no need to keep alive oop constants of nmethods on stack" Changes: https://git.openjdk.org/jdk/pull/11941/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11941&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299956 Stats: 16 lines in 2 files changed: 13 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11941.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11941/head:pull/11941 PR: https://git.openjdk.org/jdk/pull/11941 From chagedorn at openjdk.org Wed Jan 11 11:38:00 2023 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Wed, 11 Jan 2023 11:38:00 GMT Subject: RFR: 8299956: [BACKOUT] 8297487: G1 Remark: no need to keep alive oop constants of nmethods on stack In-Reply-To: References: Message-ID: <-dPN7u2SVy9aXP_GLaod18ADNEDv0w9L5F_B8biw82U=.aa439e78-828c-438b-a9eb-be9a7eb78e2b@github.com> On Wed, 11 Jan 2023 11:27:43 GMT, Tobias Hartmann wrote: > Clean backout after we observed various crashes with different tests after the integration of [JDK-8297487](https://bugs.openjdk.org/browse/JDK-8297487). > > Thanks, > Tobias Looks good and trivial. ------------- Marked as reviewed by chagedorn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11941 From thartmann at openjdk.org Wed Jan 11 11:38:01 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 11 Jan 2023 11:38:01 GMT Subject: RFR: 8299956: [BACKOUT] 8297487: G1 Remark: no need to keep alive oop constants of nmethods on stack In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 11:27:43 GMT, Tobias Hartmann wrote: > Clean backout after we observed various crashes with different tests after the integration of [JDK-8297487](https://bugs.openjdk.org/browse/JDK-8297487). > > Thanks, > Tobias Thanks for the quick review, Christian! ------------- PR: https://git.openjdk.org/jdk/pull/11941 From mbaesken at openjdk.org Wed Jan 11 11:39:58 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 11 Jan 2023 11:39:58 GMT Subject: RFR: JDK-8299672: Enhance HeapDump JFR event [v3] In-Reply-To: References: Message-ID: > Enhance the JFR Event HeapDump with the additional interesting fields, compression and overwrite. > Add some UL logging in case the heap dump writing failed . Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Some spelling adjustments in metadata.xml ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11864/files - new: https://git.openjdk.org/jdk/pull/11864/files/8543c307..76fc3a9c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11864&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11864&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11864.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11864/head:pull/11864 PR: https://git.openjdk.org/jdk/pull/11864 From mbaesken at openjdk.org Wed Jan 11 11:47:13 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 11 Jan 2023 11:47:13 GMT Subject: RFR: JDK-8299672: Enhance HeapDump JFR event [v3] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 11:39:58 GMT, Matthias Baesken wrote: >> Enhance the JFR Event HeapDump with the additional interesting fields, compression and overwrite. >> Add some UL logging in case the heap dump writing failed . > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Some spelling adjustments in metadata.xml Hi Christoph, I did some adjustments (also compressoion -> compression). ------------- PR: https://git.openjdk.org/jdk/pull/11864 From tschatzl at openjdk.org Wed Jan 11 11:57:16 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 11 Jan 2023 11:57:16 GMT Subject: RFR: 8299956: [BACKOUT] 8297487: G1 Remark: no need to keep alive oop constants of nmethods on stack In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 11:27:43 GMT, Tobias Hartmann wrote: > Clean backout after we observed various crashes with different tests after the integration of [JDK-8297487](https://bugs.openjdk.org/browse/JDK-8297487). > > Thanks, > Tobias Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11941 From clanger at openjdk.org Wed Jan 11 11:59:15 2023 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 11 Jan 2023 11:59:15 GMT Subject: RFR: JDK-8299672: Enhance HeapDump JFR event [v3] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 11:39:58 GMT, Matthias Baesken wrote: >> Enhance the JFR Event HeapDump with the additional interesting fields, compression and overwrite. >> Add some UL logging in case the heap dump writing failed . > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Some spelling adjustments in metadata.xml Looks good to me now. PS: The metadata.xml also has a copyright year to update which you should do before integrating. ------------- Marked as reviewed by clanger (Reviewer). PR: https://git.openjdk.org/jdk/pull/11864 From thartmann at openjdk.org Wed Jan 11 12:01:12 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 11 Jan 2023 12:01:12 GMT Subject: RFR: 8299956: [BACKOUT] 8297487: G1 Remark: no need to keep alive oop constants of nmethods on stack In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 11:27:43 GMT, Tobias Hartmann wrote: > Clean backout after we observed various crashes with different tests after the integration of [JDK-8297487](https://bugs.openjdk.org/browse/JDK-8297487). > > Thanks, > Tobias Thanks Thomas. I'll push this after the sanity testing passed. ------------- PR: https://git.openjdk.org/jdk/pull/11941 From jwaters at openjdk.org Wed Jan 11 12:06:47 2023 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 11 Jan 2023 12:06:47 GMT Subject: RFR: 8250269: Replace ATTRIBUTE_ALIGNED with alignas [v12] In-Reply-To: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com> References: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com> Message-ID: <8b40cSZqtThn1MFimoqnaLlj__tXyyMMMYupBKiT2fc=.8d7e248e-c4ad-4387-be18-630ed280f83c@github.com> > 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 11 additional commits since the last revision: - 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 - ATTRIBUTE_ALIGNED(16) - Merge branch 'openjdk:master' into alignas - Merge branch 'openjdk:master' into alignas - Merge branch 'openjdk:master' into alignas - ... and 1 more: https://git.openjdk.org/jdk/compare/46bf1a4d...8112c286 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11431/files - new: https://git.openjdk.org/jdk/pull/11431/files/bbdb8ea3..8112c286 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11431&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11431&range=10-11 Stats: 7179 lines in 421 files changed: 4074 ins; 1763 del; 1342 mod Patch: https://git.openjdk.org/jdk/pull/11431.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11431/head:pull/11431 PR: https://git.openjdk.org/jdk/pull/11431 From redestad at openjdk.org Wed Jan 11 12:19:21 2023 From: redestad at openjdk.org (Claes Redestad) Date: Wed, 11 Jan 2023 12:19:21 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v18] In-Reply-To: References: Message-ID: <3XcxGKxGGuk9z2Zz5qx32DcWsv5edlNMISuEw0lVawE=.fdc71f3d-ddee-485b-b6b5-c56ef6380368@github.com> On Mon, 9 Jan 2023 16:49:25 GMT, Claes Redestad wrote: >> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. >> >> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. >> >> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. >> >> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. >> >> With the most recent fixes the x64 intrinsic results on my workstation look like this: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op >> >> I.e. no measurable overhead compared to baseline even for `size == 1`. >> >> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. >> >> Benchmark for `Arrays.hashCode`: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op >> ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op >> ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op >> ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op >> ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op >> ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op >> ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op >> ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op >> ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op >> ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op >> ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op >> ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op >> ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op >> ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op >> ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op >> ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op >> ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op >> ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op >> ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op >> ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op >> ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op >> ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op >> ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op >> ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op >> ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op >> >> >> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Explicitly lea external address I'll do another round of internal testing (tier1-4). Unless I hear any objections I plan to integrate this once all testing looks satisfactory. ------------- PR: https://git.openjdk.org/jdk/pull/10847 From mbaesken at openjdk.org Wed Jan 11 12:40:59 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 11 Jan 2023 12:40:59 GMT Subject: RFR: JDK-8299672: Enhance HeapDump JFR event [v4] In-Reply-To: References: Message-ID: > Enhance the JFR Event HeapDump with the additional interesting fields, compression and overwrite. > Add some UL logging in case the heap dump writing failed . Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Adjust Copyright year in metadata.xml ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11864/files - new: https://git.openjdk.org/jdk/pull/11864/files/76fc3a9c..f5c80e1a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11864&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11864&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11864.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11864/head:pull/11864 PR: https://git.openjdk.org/jdk/pull/11864 From fjiang at openjdk.org Wed Jan 11 12:41:15 2023 From: fjiang at openjdk.org (Feilong Jiang) Date: Wed, 11 Jan 2023 12:41:15 GMT Subject: RFR: 8299844: RISC-V: Implement _onSpinWait intrinsic In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 09:52:40 GMT, Yadong Wang wrote: > Implement _onSpinWait() intrinsic for RISC-V, and it can be implemented by using PAUSE instruction from Zihintpause Extension, which is ratified and a mandatory extension of RVA22U64 (https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#rva22u64-mandatory-extensions). > Software can use the PAUSE instruction to reduce energy consumption while executing spinwait > code sequences (https://github.com/riscv/riscv-isa-manual/blob/master/src/zihintpause.tex). > > Add a test case of test/hotspot/jtreg/compiler/onSpinWait/TestOnSpinWaitRISCV64.java, passed on QEMU. Looks good, with some comments: src/hotspot/cpu/riscv/assembler_riscv.hpp line 695: > 693: } > 694: > 695: void pause() { https://github.com/openjdk/jdk/pull/10697 moved all pseudo instructions to macroAssembler, I think `pause` should be defined in there too. test/hotspot/jtreg/compiler/onSpinWait/TestOnSpinWaitRISCV64.java line 2: > 1: /* > 2: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Copyright here is Amazon. ------------- Changes requested by fjiang (Author). PR: https://git.openjdk.org/jdk/pull/11921 From thartmann at openjdk.org Wed Jan 11 12:43:18 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 11 Jan 2023 12:43:18 GMT Subject: Integrated: 8299956: [BACKOUT] 8297487: G1 Remark: no need to keep alive oop constants of nmethods on stack In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 11:27:43 GMT, Tobias Hartmann wrote: > Clean backout after we observed various crashes with different tests after the integration of [JDK-8297487](https://bugs.openjdk.org/browse/JDK-8297487). > > Thanks, > Tobias This pull request has now been integrated. Changeset: d15285f9 Author: Tobias Hartmann URL: https://git.openjdk.org/jdk/commit/d15285f948c5414028790e25b4497d28775eeb54 Stats: 16 lines in 2 files changed: 13 ins; 1 del; 2 mod 8299956: [BACKOUT] 8297487: G1 Remark: no need to keep alive oop constants of nmethods on stack Reviewed-by: chagedorn, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/11941 From egahlin at openjdk.org Wed Jan 11 12:51:14 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 11 Jan 2023 12:51:14 GMT Subject: RFR: JDK-8299672: Enhance HeapDump JFR event In-Reply-To: References: Message-ID: <_PYwXM4NzixmuI3f1_nTrlg3j-sz3CWA3gkxvHUQt38=.3c114648-66d8-4920-9d12-a82b13deca09@github.com> On Tue, 10 Jan 2023 08:19:33 GMT, Matthias Baesken wrote: > The support for gzipped heap dumps was added recently with "8237354: Add option to jcmd to write a gzipped heap dump" but not reflected in JFR so I wanted to add it here too to get a full picture of the heap dump creation. > The overwrite field was just added for completion, no specific reason. Not sure what the user is going to do with the information, but OK. ------------- PR: https://git.openjdk.org/jdk/pull/11864 From qingfeng.yy at alibaba-inc.com Wed Jan 11 12:56:47 2023 From: qingfeng.yy at alibaba-inc.com (Yi Yang) Date: Wed, 11 Jan 2023 20:56:47 +0800 Subject: =?UTF-8?B?UkZDOiByZWdhcmRpbmcgbWV0YXNwYWNlKG1ldGFkYXRhPykgZHVtcA==?= Message-ID: Hi, Internally, we often receive feedback from users and ask for help on metaspace-related issues, for example 1. Users are eager to know which GroovyClassLoader loads which classes, why they are not unloaded, and why they are leading to Metaspace OOME. 2. They want to know the class structure of dynamically generated classes in some scenarios such as deserialization 3. Finding memory leaking about duplicated classes ... Internally we implemented a metaspace dump that generates human-readable text, it looks something like this: [Basic Information] Dump Reason : JCMD MaxMetaspaceSize : 18446744073709547520 B CompressedClassSpaceSize : 1073741824 B Class Space Used : 309992 B Class Space Capacity : 395264 B ... [Class Loader Data] ClassLoaderData : loader = 0x000000008024f928, loader_klass = 0x0000000800010098, loader_klass_name = sun/misc/Launcher$AppClassLoader, label = N/A Class Used Chunks : * Chunk : [0x0000000800060000, 0x0000000800060230, 0x0000000800060800) NonClass Used Chunks : * Chunk : [0x00007fd8379c1000, 0x00007fd8379c1350, 0x00007fd8379c2000) Klasses : Klass : 0x0000000800060028, name = Test, size = 520 B ConstantPool : 0x00007fd8379c1050, size = 296 B ... It has been working effectively for several years and has helped many users solve metaspace-related problems. But a more user-friendly way is that JDK can inherently support this capability. We hope that format of the metaspace dump file can take both flexibility and compatibility into account, and the content of dump file should be detailed enough to meet the needs of both application developers and lower-level developers. Based on above considerations, I think using JSON as its file format is an appropriate solution(But XML or binary format are still not excluded as candidates). Specifically, in earlier thoughts, I thought the format of the metaspace file could be as follows(pretty printed) https://gist.github.com/y1yang0/ab3034b6381b8a9d215602c89af4e9c3 Using the JSON format, we can flexibly add new fields without breaking compatibility. It is debatable as to which data to write. We can reach a consensus that third-party parsers(Metaspace Analyzer Tool) can at least reconstruct Java source code from the dump file. Based on this, we can write more useful information for low-level troubleshooting or debugging. (e.g. the init_state of InstanceKlass). In addition, we can even output the native code and associated information with regard to Method, third-party parser can reconstruct the human-readable assembly representation of the compiled method based on dump file. To some extent, we have implemented code cache dump by the way. For this reason, I'm not sure if the title of the RFC proposal should be called metaspace dump, maybe metadata dump? It looks more like a metadata-dump framework. Do you have any thoughts about metaspace/metadata dump? Looking forward to hearing your feedback, any comments are invaluable! Best regards, Yi Yang -------------- next part -------------- An HTML attachment was scrubbed... URL: From qingfeng.yy at alibaba-inc.com Wed Jan 11 12:56:47 2023 From: qingfeng.yy at alibaba-inc.com (Yi Yang) Date: Wed, 11 Jan 2023 20:56:47 +0800 Subject: =?UTF-8?B?UkZDOiByZWdhcmRpbmcgbWV0YXNwYWNlKG1ldGFkYXRhPykgZHVtcA==?= Message-ID: Hi, Internally, we often receive feedback from users and ask for help on metaspace-related issues, for example 1. Users are eager to know which GroovyClassLoader loads which classes, why they are not unloaded, and why they are leading to Metaspace OOME. 2. They want to know the class structure of dynamically generated classes in some scenarios such as deserialization 3. Finding memory leaking about duplicated classes ... Internally we implemented a metaspace dump that generates human-readable text, it looks something like this: [Basic Information] Dump Reason : JCMD MaxMetaspaceSize : 18446744073709547520 B CompressedClassSpaceSize : 1073741824 B Class Space Used : 309992 B Class Space Capacity : 395264 B ... [Class Loader Data] ClassLoaderData : loader = 0x000000008024f928, loader_klass = 0x0000000800010098, loader_klass_name = sun/misc/Launcher$AppClassLoader, label = N/A Class Used Chunks : * Chunk : [0x0000000800060000, 0x0000000800060230, 0x0000000800060800) NonClass Used Chunks : * Chunk : [0x00007fd8379c1000, 0x00007fd8379c1350, 0x00007fd8379c2000) Klasses : Klass : 0x0000000800060028, name = Test, size = 520 B ConstantPool : 0x00007fd8379c1050, size = 296 B ... It has been working effectively for several years and has helped many users solve metaspace-related problems. But a more user-friendly way is that JDK can inherently support this capability. We hope that format of the metaspace dump file can take both flexibility and compatibility into account, and the content of dump file should be detailed enough to meet the needs of both application developers and lower-level developers. Based on above considerations, I think using JSON as its file format is an appropriate solution(But XML or binary format are still not excluded as candidates). Specifically, in earlier thoughts, I thought the format of the metaspace file could be as follows(pretty printed) https://gist.github.com/y1yang0/ab3034b6381b8a9d215602c89af4e9c3 Using the JSON format, we can flexibly add new fields without breaking compatibility. It is debatable as to which data to write. We can reach a consensus that third-party parsers(Metaspace Analyzer Tool) can at least reconstruct Java source code from the dump file. Based on this, we can write more useful information for low-level troubleshooting or debugging. (e.g. the init_state of InstanceKlass). In addition, we can even output the native code and associated information with regard to Method, third-party parser can reconstruct the human-readable assembly representation of the compiled method based on dump file. To some extent, we have implemented code cache dump by the way. For this reason, I'm not sure if the title of the RFC proposal should be called metaspace dump, maybe metadata dump? It looks more like a metadata-dump framework. Do you have any thoughts about metaspace/metadata dump? Looking forward to hearing your feedback, any comments are invaluable! Best regards, Yi Yang -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcking at openjdk.org Wed Jan 11 14:30:16 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 11 Jan 2023 14:30:16 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v4] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 10:05:33 GMT, Stefan Karlsson wrote: > I'm happy to see this flag getting removed. I'm less happy about seeing usages of the array allocators being replaced by macros. I'd rather see an effort towards getting rid of these macros. Could we limit this patch to only remove the ArrayAllocatorMallocLimit flag and ArrayAllocator class, and defer the discussion around what API to use for array allocations? `ArrayAllocator` with `ArrayAllocatorMallocLimit` removed is effectively `MallocArrayAllocator`. Are you suggesting leaving `MallocArrayAllocator` and `MmapArrayAllocator` thus update references to `ArrayAllocator` to be `MallocArrayAllocator`? As far as APIs, the majority of the codebase uses the macros. IMO consistency would be better and having two ways of doing things doesn't help. But if you feel strongly about it, we can punt and just surgically remove the bare minimum, assuming you clarify your expectation (see above). ------------- PR: https://git.openjdk.org/jdk/pull/11931 From stuefe at openjdk.org Wed Jan 11 14:53:14 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 11 Jan 2023 14:53:14 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v4] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 22:50:11 GMT, Justin King wrote: >> Remove abstraction that is a holdover from Solaris. Direct usages of `MmapArrayAllocator` have been switched to normal `malloc`. The justification is that none of the code paths are called from signal handlers, so using `mmap` directly does not make sense and is potentially slower than going through `malloc` which can potentially re-use memory without making any system calls. The remaining usages of `ArrayAllocator` and `MallocArrayAllocator` are equivalent. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Initialize memory to zero in zGranuleMap > > Signed-off-by: Justin King Curious, I always thought we do ArrayAllocator - using mmap for larger allocations - to prevent memory retention for libc variants whose allocators are "grabby", i.e. which don't promptly return memory to the OS on free(). E.g. because they only use sbrk (Solaris, AIX), or are just cautious about returning memory (glibc). Glibc's retention problem is only relevant for fine-grained allocations, so for glibc this is probably fine. This leaves at least AIX as a potential problem. @backwaterred, does the AIX libc malloc() still exclusively use the data segment ? Does free'd memory still stick to the process? (While writing this, I remember that we at SAP even rewrote Arena allocation to use mmap for AIX, because large compile arenas caused lasting RSS increase, so it has definitely been a problem in the past) ------------- PR: https://git.openjdk.org/jdk/pull/11931 From jcking at openjdk.org Wed Jan 11 15:00:09 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 11 Jan 2023 15:00:09 GMT Subject: RFR: JDK-8299971: Remove metaprogramming/conditional.hpp Message-ID: Code cleanup of pre-C++11 implementations. ------------- Commit messages: - Remove metaprogramming/conditional.hpp Changes: https://git.openjdk.org/jdk/pull/11946/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11946&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299971 Stats: 136 lines in 11 files changed: 7 ins; 105 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/11946.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11946/head:pull/11946 PR: https://git.openjdk.org/jdk/pull/11946 From jcking at openjdk.org Wed Jan 11 15:00:10 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 11 Jan 2023 15:00:10 GMT Subject: RFR: JDK-8299971: Remove metaprogramming/conditional.hpp In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 14:44:11 GMT, Justin King wrote: > Code cleanup of pre-C++11 implementations. @kimbarrett Yet more cleanup. ------------- PR: https://git.openjdk.org/jdk/pull/11946 From stefank at openjdk.org Wed Jan 11 15:11:15 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 11 Jan 2023 15:11:15 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v4] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 14:27:44 GMT, Justin King wrote: > ArrayAllocator with ArrayAllocatorMallocLimit removed is effectively MallocArrayAllocator. Are you suggesting leaving MallocArrayAllocator and MmapArrayAllocator thus update references to ArrayAllocator to be MallocArrayAllocator? Yes, that was what I wanted. > As far as APIs, the majority of the codebase uses the macros. IMO consistency would be better and having two ways of doing things doesn't help. But if you feel strongly about it, we can punt and just surgically remove the bare minimum, assuming you clarify your expectation (see above). I agree about the argument about consistency, so I retract my objection. We can deal with these macros as a separate RFE (if we ever get to it). I would like to retain the usage of mmapped memory for ZGC to minimize the risk of any surprises for us. ZGC code also tend to initialize as much as possible in the initialization list, so the extra memset that comes after initialization lists sticks out a bit. Could you create a private `ZGranuleMap::allocate_array` function that uses os::reserve_memory/commmit_memory and change the code to be: inline ZGranuleMap::ZGranuleMap(size_t max_offset) : _size(max_offset >> ZGranuleSizeShift), _map(allocate_array(_size)) { Or if you like, I can provide a patch on top of your branch to do that. ------------- PR: https://git.openjdk.org/jdk/pull/11931 From redestad at openjdk.org Wed Jan 11 15:22:33 2023 From: redestad at openjdk.org (Claes Redestad) Date: Wed, 11 Jan 2023 15:22:33 GMT Subject: RFR: 8299978: Remove MethodHandleNatives.getMembers Message-ID: This removes `MethodHandleNatives.getMembers`, which has fallen into disuse. ------------- Commit messages: - 8299978: Remove MethodHandleNatives.getMembers Changes: https://git.openjdk.org/jdk/pull/11949/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11949&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299978 Stats: 172 lines in 4 files changed: 0 ins; 171 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11949.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11949/head:pull/11949 PR: https://git.openjdk.org/jdk/pull/11949 From jvernee at openjdk.org Wed Jan 11 15:38:14 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 11 Jan 2023 15:38:14 GMT Subject: RFR: 8299978: Remove MethodHandleNatives.getMembers In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 15:13:14 GMT, Claes Redestad wrote: > This removes `MethodHandleNatives.getMembers`, which has fallen into disuse. Marked as reviewed by jvernee (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11949 From jcking at openjdk.org Wed Jan 11 17:05:16 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 11 Jan 2023 17:05:16 GMT Subject: RFR: JDK-8299972: Remove metaprogramming/removeReference.hpp Message-ID: <2b-IgAfCtFcOvvzUnSIRop-HS2jQZk-ey6owacyEz6o=.b690ff0e-170c-4185-8f72-b16e4c67dec0@github.com> Code cleanup of pre-C++11 implementations. ------------- Commit messages: - Remove metaprogramming/removeReference.hpp Changes: https://git.openjdk.org/jdk/pull/11947/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11947&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299972 Stats: 83 lines in 2 files changed: 0 ins; 83 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11947.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11947/head:pull/11947 PR: https://git.openjdk.org/jdk/pull/11947 From jcking at openjdk.org Wed Jan 11 17:05:18 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 11 Jan 2023 17:05:18 GMT Subject: RFR: JDK-8299972: Remove metaprogramming/removeReference.hpp In-Reply-To: <2b-IgAfCtFcOvvzUnSIRop-HS2jQZk-ey6owacyEz6o=.b690ff0e-170c-4185-8f72-b16e4c67dec0@github.com> References: <2b-IgAfCtFcOvvzUnSIRop-HS2jQZk-ey6owacyEz6o=.b690ff0e-170c-4185-8f72-b16e4c67dec0@github.com> Message-ID: On Wed, 11 Jan 2023 14:51:15 GMT, Justin King wrote: > Code cleanup of pre-C++11 implementations. @kimbarrett And another more simple one. ------------- PR: https://git.openjdk.org/jdk/pull/11947 From mchung at openjdk.org Wed Jan 11 17:18:12 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 11 Jan 2023 17:18:12 GMT Subject: RFR: 8299978: Remove MethodHandleNatives.getMembers In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 15:13:14 GMT, Claes Redestad wrote: > This removes `MethodHandleNatives.getMembers`, which has fallen into disuse. Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11949 From luhenry at openjdk.org Wed Jan 11 17:27:27 2023 From: luhenry at openjdk.org (Ludovic Henry) Date: Wed, 11 Jan 2023 17:27:27 GMT Subject: RFR: 8299844: RISC-V: Implement _onSpinWait intrinsic In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 09:52:40 GMT, Yadong Wang wrote: > Implement _onSpinWait() intrinsic for RISC-V, and it can be implemented by using PAUSE instruction from Zihintpause Extension, which is ratified and a mandatory extension of RVA22U64 (https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#rva22u64-mandatory-extensions). > Software can use the PAUSE instruction to reduce energy consumption while executing spinwait > code sequences (https://github.com/riscv/riscv-isa-manual/blob/master/src/zihintpause.tex). > > Add a test case of test/hotspot/jtreg/compiler/onSpinWait/TestOnSpinWaitRISCV64.java, passed on QEMU. src/hotspot/cpu/riscv/riscv.ad line 1820: > 1818: switch (opcode) { > 1819: case Op_OnSpinWait: > 1820: return VM_Version::supports_on_spin_wait(); You can use `UseZihintpause` directly just like for `UseRVV`, `UsePopCountInstruction`, or `UseZbb` below. ------------- PR: https://git.openjdk.org/jdk/pull/11921 From bpb at openjdk.org Wed Jan 11 17:27:22 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 11 Jan 2023 17:27:22 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v6] In-Reply-To: References: Message-ID: > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299684: More changes addressing reviewer comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11873/files - new: https://git.openjdk.org/jdk/pull/11873/files/d2386a4b..82d9e6f1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=04-05 Stats: 53 lines in 5 files changed: 38 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Wed Jan 11 17:27:24 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 11 Jan 2023 17:27:24 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v4] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 06:09:21 GMT, David Holmes wrote: >> BUILD_JDK_JTREG_LIBRARIES_LIBS_libNewDirectByteBuffer := jvm.lib >> >> as per the preceding line. > > Sorry, my bad, that should be: > > BUILD_JDK_JTREG_LIBRARIES_LIBS_libNewDirectByteBuffer := $(WIN_LIB_JAVA) > > the Windows equivalent of `-ljava`. Thanks. So changed in 82d9e6f1f6782b180943d1136881d58dd2852e58. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Wed Jan 11 17:27:29 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 11 Jan 2023 17:27:29 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v5] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 05:56:16 GMT, David Holmes wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8299684: Changes addressing reviewer comments > > src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 197: > >> 195: throw new IllegalArgumentException >> 196: ("JNI NewDirectByteBuffer passed capacity < 0: (" >> 197: + capacity + " < 0)"); > > You don't need to repeat the `< 0` part. I was matching `Buffer::createCapacityException` but I agree with you. Remove in 82d9e6f1f6782b180943d1136881d58dd2852e58. > src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 201: > >> 199: throw new IllegalArgumentException >> 200: ("JNI NewDirectByteBuffer passed capacity > Integer.MAX_VALUE: (" >> 201: + capacity + " > Integer.MAX_VALUE)"); > > You don't need to repeat the `> Integer.MAX_VALUE` part. Removed in 82d9e6f1f6782b180943d1136881d58dd2852e58. > test/jdk/java/nio/jni/NewDirectByteBuffer.java line 73: > >> 71: public static void main(String[] args) { >> 72: System.out.println("--- Legal Capacities ---"); >> 73: for (long cap : LEGAL_CAPACITIES) { > > I would still expect this to throw OOME for the very large values, so the OOME needs to be caught so that the test continues. Fixed in 82d9e6f1f6782b180943d1136881d58dd2852e58. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Wed Jan 11 17:27:32 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 11 Jan 2023 17:27:32 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v5] In-Reply-To: <72tDSvqfz8V4UlUsCSLtIlplkn32UTucoTq62yRZhdo=.fab73681-bf7b-4ce7-b20b-8f2bca8f9373@github.com> References: <72tDSvqfz8V4UlUsCSLtIlplkn32UTucoTq62yRZhdo=.fab73681-bf7b-4ce7-b20b-8f2bca8f9373@github.com> Message-ID: On Tue, 10 Jan 2023 11:58:03 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8299684: Changes addressing reviewer comments > > test/jdk/java/nio/jni/NewDirectByteBuffer.java line 30: > >> 28: * @summary Verify that JNI NewDirectByteBuffer throws IllegalArgumentException >> 29: * if the capacity is negative or greater than Integer::MAX_VALUE >> 30: * @run main/native NewDirectByteBuffer > > You may have missed the comments about @requires and wondering if this test will run on 32-bit, as it will attempt to malloc 2GB. I saw the comments but was deferring that. > test/jdk/java/nio/jni/NewDirectByteBuffer.java line 50: > >> 48: (long)Integer.MAX_VALUE + 1L, >> 49: 3_000_000_000L, >> 50: 5_000_000_000L > > Long.MIN_VALUE and Long.MAX_VALUE would be good to include. Added in 82d9e6f1f6782b180943d1136881d58dd2852e58. > test/jdk/java/nio/jni/libNewDirectByteBuffer.c line 35: > >> 33: void* addr = malloc(size); >> 34: if (addr == NULL) { >> 35: jclass rtExCls = (*env)->FindClass(env, "java/lang/OutOfMemoryError"); > > rtExCls? Does this stand for "runtime exception class", just asking because this is an Error class. Thanks for catching that. The name `rtExCls` is as you interpreted and is residual from an unpublished version. Fixed in 82d9e6f1f6782b180943d1136881d58dd2852e58. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Wed Jan 11 17:32:28 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 11 Jan 2023 17:32:28 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v7] In-Reply-To: References: Message-ID: <49RhAcil-2bixbBBctq0uRxYbUd7IzMibHcuG9pLulI=.f331dd43-97a8-4196-b3cd-d59d1a8785bc@github.com> > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299684: Change DirectBuffer to DirectByteBuffer ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11873/files - new: https://git.openjdk.org/jdk/pull/11873/files/82d9e6f1..95fd6652 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=05-06 Stats: 9 lines in 2 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Wed Jan 11 17:32:31 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 11 Jan 2023 17:32:31 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v5] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 06:00:10 GMT, David Holmes wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8299684: Changes addressing reviewer comments > > test/jdk/java/nio/jni/NewDirectByteBuffer.java line 106: > >> 104: private static native ByteBuffer newDirectByteBuffer(long size); >> 105: private static native long getDirectBufferCapacity(ByteBuffer buf); >> 106: private static native void freeDirectBufferMemory(ByteBuffer buf); > > Naming nit: ByteBuffer versus Buffer Fixed in 95fd6652148e1b740af599081b3614c54656c8b4 (overlooked in previous commit). ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Wed Jan 11 17:33:16 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 11 Jan 2023 17:33:16 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v5] In-Reply-To: <72tDSvqfz8V4UlUsCSLtIlplkn32UTucoTq62yRZhdo=.fab73681-bf7b-4ce7-b20b-8f2bca8f9373@github.com> References: <72tDSvqfz8V4UlUsCSLtIlplkn32UTucoTq62yRZhdo=.fab73681-bf7b-4ce7-b20b-8f2bca8f9373@github.com> Message-ID: <5aaxI0fqVOy1ehO53y56S3gcuuXUXwPhxpuLdMsJShQ=.54edb592-8196-488e-b8dd-4e6160070862@github.com> On Tue, 10 Jan 2023 12:02:23 GMT, Alan Bateman wrote: > The update looks quite good and maybe some day this can be converted from a psvm test to a junit test. `JUnit` or `TestNG`? ------------- PR: https://git.openjdk.org/jdk/pull/11873 From ccheung at openjdk.org Wed Jan 11 17:44:15 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 11 Jan 2023 17:44:15 GMT Subject: RFR: 8298321: 2 File Leak defect groups in 2 files [v3] In-Reply-To: References: <80ytz5zwYXLeAAQE9ChmGPl9D0iDY-Gbvrr2CRuNMxY=.39d7fb30-17ee-4e80-bd13-29d179fcca77@github.com> Message-ID: On Tue, 10 Jan 2023 22:13:40 GMT, David Holmes wrote: >> The static analysis tool should be fine about the above change. As I mentioned in the bug report, the warning is regarding the fd is not closed under the conditions HAS_PENDING_EXCEPTION and fd != OS_ERR. >> I will run rerun the test to be sure. > > Do we need to test both debug and release builds? The debug build should be fine due to the assert, but in release build ... I re-ran tiers 1 and 2 tests using mach5 which tests debug build. The run with the static analysis tool uses product build. Both passed. ------------- PR: https://git.openjdk.org/jdk/pull/11909 From lancea at openjdk.org Wed Jan 11 17:52:17 2023 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 11 Jan 2023 17:52:17 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v5] In-Reply-To: <5aaxI0fqVOy1ehO53y56S3gcuuXUXwPhxpuLdMsJShQ=.54edb592-8196-488e-b8dd-4e6160070862@github.com> References: <72tDSvqfz8V4UlUsCSLtIlplkn32UTucoTq62yRZhdo=.fab73681-bf7b-4ce7-b20b-8f2bca8f9373@github.com> <5aaxI0fqVOy1ehO53y56S3gcuuXUXwPhxpuLdMsJShQ=.54edb592-8196-488e-b8dd-4e6160070862@github.com> Message-ID: On Wed, 11 Jan 2023 17:31:14 GMT, Brian Burkhalter wrote: > > The update looks quite good and maybe some day this can be converted from a psvm test to a junit test. > > `JUnit` or `TestNG`? It sounds like the suggested way forward is to use junit for new tests and for extra credit convert existing testng tests when/if they need updated ------------- PR: https://git.openjdk.org/jdk/pull/11873 From ccheung at openjdk.org Wed Jan 11 17:52:23 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 11 Jan 2023 17:52:23 GMT Subject: RFR: 8298321: 2 File Leak defect groups in 2 files [v4] In-Reply-To: <0SHxfzBPDAO5XortLBnbAWBKzL7wPAj5bY2xMyG9cdU=.ec5e8469-d421-4a3f-adb4-bf5c454dc687@github.com> References: <0SHxfzBPDAO5XortLBnbAWBKzL7wPAj5bY2xMyG9cdU=.ec5e8469-d421-4a3f-adb4-bf5c454dc687@github.com> Message-ID: On Mon, 9 Jan 2023 20:36:25 GMT, Vladimir Ivanov wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> move the ::close call to immediately after ::read > > Looks good. Thanks @iwanowww, @iklam, @dholmes-ora for the review. ------------- PR: https://git.openjdk.org/jdk/pull/11909 From ccheung at openjdk.org Wed Jan 11 17:52:25 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 11 Jan 2023 17:52:25 GMT Subject: Integrated: 8298321: 2 File Leak defect groups in 2 files In-Reply-To: References: Message-ID: <-9qOdFI_eJQFM9v7jqDEEA_tmUjZ4OI0nbpkOBpSKWg=.87dbecb9-55b6-43cd-86aa-0b3e2a96c75c@github.com> On Mon, 9 Jan 2023 19:34:55 GMT, Calvin Cheung wrote: > Please review this simple change for fixing two file leak warnings: > 1) DirectivesParser::parse_from_file_inner() in open/src/hotspot/share/compiler/directivesParser.cpp > 2) mmap_attach_shared() in open/src/hotspot/os/posix/perfMemory_posix.cpp > > Please refer to the [comment](https://bugs.openjdk.org/browse/JDK-8298321?focusedCommentId=14549361&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14549361) in the bug report for details. > > Passed tiers 1 and 2 testing. This pull request has now been integrated. Changeset: 9c1e98da Author: Calvin Cheung URL: https://git.openjdk.org/jdk/commit/9c1e98dac54ed2ce169f3f3df05bc80052f6a217 Stats: 7 lines in 2 files changed: 4 ins; 2 del; 1 mod 8298321: 2 File Leak defect groups in 2 files Reviewed-by: vlivanov, iklam, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/11909 From jcking at openjdk.org Wed Jan 11 17:55:53 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 11 Jan 2023 17:55:53 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v5] In-Reply-To: References: Message-ID: > Remove abstraction that is a holdover from Solaris. Direct usages of `MmapArrayAllocator` have been switched to normal `malloc`. The justification is that none of the code paths are called from signal handlers, so using `mmap` directly does not make sense and is potentially slower than going through `malloc` which can potentially re-use memory without making any system calls. The remaining usages of `ArrayAllocator` and `MallocArrayAllocator` are equivalent. Justin King has updated the pull request incrementally with one additional commit since the last revision: Restore mmap allocator for zGranuleMap Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11931/files - new: https://git.openjdk.org/jdk/pull/11931/files/3216fb19..d30748e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=03-04 Stats: 33 lines in 2 files changed: 30 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11931.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11931/head:pull/11931 PR: https://git.openjdk.org/jdk/pull/11931 From jwilhelm at openjdk.org Wed Jan 11 17:56:07 2023 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Wed, 11 Jan 2023 17:56:07 GMT Subject: RFR: Merge jdk20 Message-ID: Forwardport JDK 20 -> JDK 21 ------------- Commit messages: - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20 - 8299862: OfAddress setter should disallow heap segments - 8299849: Revert JDK-8294461: wrong effectively final determination by javac - 8299227: host `exif.org` not found in link in doc comment - 8299715: IR test: VectorGatherScatterTest.java fails with SVE randomly - 8294744: AArch64: applications/kitchensink/Kitchensink.java crashed: assert(oopDesc::is_oop(obj)) failed: not an oop - 8299733: AArch64: "unexpected literal addressing mode" assertion failure with -XX:+PrintC1Statistics - 8299693: Change to Xcode12.4+1.1 devkit for building on macOS at Oracle The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk&pr=11952&range=00.0 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=11952&range=00.1 Changes: https://git.openjdk.org/jdk/pull/11952/files Stats: 98 lines in 16 files changed: 53 ins; 19 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/11952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11952/head:pull/11952 PR: https://git.openjdk.org/jdk/pull/11952 From ngasson at openjdk.org Wed Jan 11 18:00:42 2023 From: ngasson at openjdk.org (Nick Gasson) Date: Wed, 11 Jan 2023 18:00:42 GMT Subject: RFR: 8298482: Implement ParallelGC NUMAStats for Linux [v4] In-Reply-To: References: Message-ID: > ParallelGC has a seemingly useful option -XX:+NUMAStats that prints detailed information in GC.heap_info about which NUMA node pages in the eden space are bound to. However as far as I can tell this only ever worked on Solaris and is not implemented on any of the systems we currently support. This patch implements it on Linux using the move_pages system call. > > The function os::get_page_info() and accompanying struct page_info was just a thin wrapper around the Solaris meminfo(2) syscall and was never ported to other systems so I've just removed it rather than try to emulate its interface. > > There's also a method MutableNUMASpace::LGRPSpace::scan_pages() which attempts to find pages on the wrong NUMA node and frees them so that they have another chance to be allocated on the correct node by the first-touching thread, but I think this has always been a no-op on non-Solaris so perhaps should also be removed. On Linux it shouldn't be necessary as you can bind pages to the desired node directly. > > I don't know what the performance of this option was like on Solaris but on Linux the move_pages call can be quite slow: I measured about 25ms/GB on my system. At the moment we call LGRPSpace::accumulate_statistics() twice per GC cycle: I removed the second call as it's likely to see a lot of uncommitted pages if the spaces were just resized. MutableNUMASpace::print_on() also calls accumulate_statistics() directly and since that's the only place this data is used, maybe we can drop the call from MutableNUMASpace::accumulate_statistics() as well? > > Example output: > > > PSYoungGen total 4290560K, used 835628K [0x00000006aac00000, 0x0000000800000000, 0x0000000800000000) > eden space 3096576K, 1% used [0x00000006aac00000,0x00000007176a9f48,0x0000000767c00000) > lgrp 0 space 1761280K, 2% used [0x00000006aac00000,0x00000006acfc4980,0x0000000716400000) > local/remote/unbiased/uncommitted: 1671168K/0K/0K/90112K, large/small pages: 0/440320 > lgrp 1 space 1335296K, 46% used [0x0000000716400000,0x000000073c2abb18,0x0000000767c00000) > local/remote/unbiased/uncommitted: 1335296K/0K/0K/0K, large/small pages: 0/333824 > from space 1193984K, 65% used [0x00000007b7200000,0x00000007e6b9c778,0x0000000800000000) > to space 1247232K, 0% used [0x0000000767c00000,0x0000000767c00000,0x00000007b3e00000) > > > After testing this with SPECjbb for a while I noticed some pages always end up bound to the wrong node. I think this is a regression caused by JDK-8283935 but I'll raise a separate ticket for that. Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: Add missing braces ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11635/files - new: https://git.openjdk.org/jdk/pull/11635/files/80bd78cd..36349264 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11635&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11635&range=02-03 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11635.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11635/head:pull/11635 PR: https://git.openjdk.org/jdk/pull/11635 From ngasson at openjdk.org Wed Jan 11 18:00:44 2023 From: ngasson at openjdk.org (Nick Gasson) Date: Wed, 11 Jan 2023 18:00:44 GMT Subject: RFR: 8298482: Implement ParallelGC NUMAStats for Linux [v3] In-Reply-To: References: <0kLOC8uhdDwwtu901coLNm8UT_7k3pzLn1MjWeXqU-0=.d4d9c100-12bb-4dc1-81d7-a3752e1fd930@github.com> Message-ID: On Tue, 10 Jan 2023 11:32:50 GMT, Stefan Johansson wrote: >> Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: >> >> Do not update NUMAStats in MutableNUMASpace::accumulate_statistics() > > src/hotspot/share/gc/parallel/mutableNUMASpace.cpp line 896: > >> 894: space_stats()->_local_space += os::vm_page_size(); >> 895: else >> 896: space_stats()->_remote_space += os::vm_page_size(); > > Please add braces for the `for`-loop and the `if-else`-statements. Done. Thanks for the reviews! ------------- PR: https://git.openjdk.org/jdk/pull/11635 From jcking at openjdk.org Wed Jan 11 18:01:16 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 11 Jan 2023 18:01:16 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v4] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 15:08:23 GMT, Stefan Karlsson wrote: > > ArrayAllocator with ArrayAllocatorMallocLimit removed is effectively MallocArrayAllocator. Are you suggesting leaving MallocArrayAllocator and MmapArrayAllocator thus update references to ArrayAllocator to be MallocArrayAllocator? > > Yes, that was what I wanted. > > > As far as APIs, the majority of the codebase uses the macros. IMO consistency would be better and having two ways of doing things doesn't help. But if you feel strongly about it, we can punt and just surgically remove the bare minimum, assuming you clarify your expectation (see above). > > I agree about the argument about consistency, so I retract my objection. We can deal with these macros as a separate RFE (if we ever get to it). > > I would like to retain the usage of mmapped memory for ZGC to minimize the risk of any surprises for us. ZGC code also tend to initialize as much as possible in the initialization list, so the extra memset that comes after initialization lists sticks out a bit. Could you create a private `ZGranuleMap::allocate_array` function that uses os::reserve_memory/commmit_memory and change the code to be: > > ``` > inline ZGranuleMap::ZGranuleMap(size_t max_offset) : > _size(max_offset >> ZGranuleSizeShift), > _map(allocate_array(_size)) { > ``` > > Or if you like, I can provide a patch on top of your branch to do that. The extra memset is due to `malloc` not handing out zero initialized memory, it looks like `zGranuleMap` is sensitive to that. Done. Restored mmap as suggested for zGranuleMap. ------------- PR: https://git.openjdk.org/jdk/pull/11931 From jcking at openjdk.org Wed Jan 11 18:13:15 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 11 Jan 2023 18:13:15 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v4] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 14:49:59 GMT, Thomas Stuefe wrote: > Curious, I always thought we do ArrayAllocator - using mmap for larger allocations - to prevent memory retention for libc variants whose allocators are "grabby", i.e. which don't promptly return memory to the OS on free(). E.g. because they only use sbrk (Solaris, AIX), or are just cautious about returning memory (glibc). > > Glibc's retention problem is only relevant for fine-grained allocations, so for glibc this is probably fine. This leaves at least AIX as a potential problem. @backwaterred, does the AIX libc malloc() still exclusively use the data segment ? Does free'd memory still stick to the process? > > (While writing this, I remember that we at SAP even rewrote Arena allocation to use mmap for AIX, because large compile arenas caused lasting RSS increase, so it has definitely been a problem in the past) Correct, glibc always mmap's allocations above a certain limit and always unmaps them on free. I believe most implementations do that, either immediately unmapping or using madvise. AIX still uses sbrk, based on their documentation that I could find. Though AIX does have something called [malloc disclaim](https://www.ibm.com/docs/en/aix/7.2?topic=subsystem-malloc-disclaim). ------------- PR: https://git.openjdk.org/jdk/pull/11931 From jcking at openjdk.org Wed Jan 11 18:26:36 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 11 Jan 2023 18:26:36 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v6] In-Reply-To: References: Message-ID: > Remove abstraction that is a holdover from Solaris. Direct usages of `MmapArrayAllocator` have been switched to normal `malloc`. The justification is that none of the code paths are called from signal handlers, so using `mmap` directly does not make sense and is potentially slower than going through `malloc` which can potentially re-use memory without making any system calls. The remaining usages of `ArrayAllocator` and `MallocArrayAllocator` are equivalent. Justin King has updated the pull request incrementally with one additional commit since the last revision: Ensure Padded2DArray clears memory to preserve compatibility with mmap Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11931/files - new: https://git.openjdk.org/jdk/pull/11931/files/d30748e9..cf3097ec Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=04-05 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11931.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11931/head:pull/11931 PR: https://git.openjdk.org/jdk/pull/11931 From coleenp at openjdk.org Wed Jan 11 18:55:16 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 11 Jan 2023 18:55:16 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v4] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 14:49:59 GMT, Thomas Stuefe wrote: >> Justin King has updated the pull request incrementally with one additional commit since the last revision: >> >> Initialize memory to zero in zGranuleMap >> >> Signed-off-by: Justin King > > Curious, I always thought we do ArrayAllocator - using mmap for larger allocations - to prevent memory retention for libc variants whose allocators are "grabby", i.e. which don't promptly return memory to the OS on free(). E.g. because they only use sbrk (Solaris, AIX), or are just cautious about returning memory (glibc). > > Glibc's retention problem is only relevant for fine-grained allocations, so for glibc this is probably fine. This leaves at least AIX as a potential problem. @backwaterred, does the AIX libc malloc() still exclusively use the data segment ? Does free'd memory still stick to the process? > > (While writing this, I remember that we at SAP even rewrote Arena allocation to use mmap for AIX, because large compile arenas caused lasting RSS increase, so it has definitely been a problem in the past) To follow up on @tstuefe comment - and the one that I tried to say in the bug was that we added this MmapArrayAllocate feature for some G1 marking bits that used so much memory that hit the Solaris _sbrk issue. Maybe @stefank and @tschatzl remember this issue. Maybe it's ok for AIX, then removing this code is a good change. Maybe the G1 usages need a mmap implementation though. ------------- PR: https://git.openjdk.org/jdk/pull/11931 From vlivanov at openjdk.org Wed Jan 11 19:09:36 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 11 Jan 2023 19:09:36 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v18] In-Reply-To: References: Message-ID: <_vJ-5zerpDnHng8O_QZ5LEfVb09knfCRIrWfHRB1eTQ=.f01389ce-82e9-4073-86e3-08b70219cf0b@github.com> On Mon, 9 Jan 2023 16:49:25 GMT, Claes Redestad wrote: >> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. >> >> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. >> >> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. >> >> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. >> >> With the most recent fixes the x64 intrinsic results on my workstation look like this: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op >> >> I.e. no measurable overhead compared to baseline even for `size == 1`. >> >> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. >> >> Benchmark for `Arrays.hashCode`: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op >> ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op >> ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op >> ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op >> ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op >> ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op >> ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op >> ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op >> ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op >> ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op >> ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op >> ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op >> ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op >> ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op >> ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op >> ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op >> ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op >> ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op >> ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op >> ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op >> ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op >> ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op >> ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op >> ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op >> ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op >> >> >> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Explicitly lea external address Before the patch goes in, I'd like to see a plan how the code will be refactored later. At the very least, I expect `is_string_hashcode`-related logic to go away and the intrinsic logic to be guided solely by a basic type of elements. If not in the initial version, then shortly after as a follow-up enhancement. Another thing I want to see is `VectorizedHashCode` node to go away and replaced with a stub call. ------------- Changes requested by vlivanov (Reviewer). PR: https://git.openjdk.org/jdk/pull/10847 From jcking at openjdk.org Wed Jan 11 20:53:38 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 11 Jan 2023 20:53:38 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v7] In-Reply-To: References: Message-ID: > Remove abstraction that is a holdover from Solaris. Direct usages of `MmapArrayAllocator` have been switched to normal `malloc`. The justification is that none of the code paths are called from signal handlers, so using `mmap` directly does not make sense and is potentially slower than going through `malloc` which can potentially re-use memory without making any system calls. The remaining usages of `ArrayAllocator` and `MallocArrayAllocator` are equivalent. Justin King has updated the pull request incrementally with one additional commit since the last revision: Fix incompatible pointer types Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11931/files - new: https://git.openjdk.org/jdk/pull/11931/files/cf3097ec..5d30170a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11931.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11931/head:pull/11931 PR: https://git.openjdk.org/jdk/pull/11931 From jcking at openjdk.org Wed Jan 11 20:59:15 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 11 Jan 2023 20:59:15 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v4] In-Reply-To: References: Message-ID: <0nh4tXVw2rW8szwTMV2Rj2NLSA0x-OjM7htP5jMZBlo=.490e5098-24e3-421c-abbf-4be4e32b15da@github.com> On Wed, 11 Jan 2023 14:49:59 GMT, Thomas Stuefe wrote: >> Justin King has updated the pull request incrementally with one additional commit since the last revision: >> >> Initialize memory to zero in zGranuleMap >> >> Signed-off-by: Justin King > > Curious, I always thought we do ArrayAllocator - using mmap for larger allocations - to prevent memory retention for libc variants whose allocators are "grabby", i.e. which don't promptly return memory to the OS on free(). E.g. because they only use sbrk (Solaris, AIX), or are just cautious about returning memory (glibc). > > Glibc's retention problem is only relevant for fine-grained allocations, so for glibc this is probably fine. This leaves at least AIX as a potential problem. @backwaterred, does the AIX libc malloc() still exclusively use the data segment ? Does free'd memory still stick to the process? > > (While writing this, I remember that we at SAP even rewrote Arena allocation to use mmap for AIX, because large compile arenas caused lasting RSS increase, so it has definitely been a problem in the past) > To follow up on @tstuefe comment - and the one that I tried to say in the bug was that we added this MmapArrayAllocate feature for some G1 marking bits that used so much memory that hit the Solaris _sbrk issue. Maybe @stefank and @tschatzl remember this issue. Maybe it's ok for AIX, then removing this code is a good change. Maybe the G1 usages need a mmap implementation though. The padding.inline.hpp usage seems to have one caller which is called once. The other mmap usage in G1 we can convert to mmap using a similar approach to zGranuleMap if that is preferred. That would then be equivalent behavior, it looks like the G1 code uses the page allocation granularity anyway so maybe keeping it mmap is the better way to go here anyway? ------------- PR: https://git.openjdk.org/jdk/pull/11931 From xuelei at openjdk.org Wed Jan 11 21:03:12 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 11 Jan 2023 21:03:12 GMT Subject: RFR: 8299635: More test issues for deprecated sprintf in Xcode 14 Message-ID: The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. This patch is trying to find the use of sprintf in test cases, and replace it with snprintf accordingly. ------------- Commit messages: - typo correction - 8299635: More test issues for deprecated sprintf in Xcode 14 Changes: https://git.openjdk.org/jdk/pull/11935/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299635 Stats: 43 lines in 26 files changed: 4 ins; 0 del; 39 mod Patch: https://git.openjdk.org/jdk/pull/11935.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11935/head:pull/11935 PR: https://git.openjdk.org/jdk/pull/11935 From mikael at openjdk.org Wed Jan 11 21:19:12 2023 From: mikael at openjdk.org (Mikael Vidstedt) Date: Wed, 11 Jan 2023 21:19:12 GMT Subject: RFR: 8299635: More test issues for deprecated sprintf in Xcode 14 In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 06:26:18 GMT, Xue-Lei Andrew Fan wrote: > The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. > > This patch is trying to find the use of sprintf in test cases, and replace it with snprintf accordingly. This PR does not address all the remaining sprintf:s in hotspot, and with it now explicitly forbidden the build will fail: src/hotspot/os/linux/attachListener_linux.cpp: In member function 'virtual void LinuxAttachOperation::complete(jint, bufferedStream*)': src/hotspot/os/linux/attachListener_linux.cpp:414:10: error: call to 'sprintf' declared with attribute warning: use os::snprintf [-Werror=attribute-warning] 414 | sprintf(msg, "%d\n", result); | ~~~~~~~^~~~~~~~~~~~~~~~~~~~~ I count ~30 sprintf:s that need updating. I'm also curious: some of the sprintfs are C2 (src/hotspot/share/opto) - are your builds including C2? If so, why are you not running into the issue for those files? ------------- PR: https://git.openjdk.org/jdk/pull/11935 From redestad at openjdk.org Wed Jan 11 21:26:21 2023 From: redestad at openjdk.org (Claes Redestad) Date: Wed, 11 Jan 2023 21:26:21 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v18] In-Reply-To: References: Message-ID: On Mon, 9 Jan 2023 16:49:25 GMT, Claes Redestad wrote: >> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. >> >> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. >> >> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. >> >> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. >> >> With the most recent fixes the x64 intrinsic results on my workstation look like this: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op >> >> I.e. no measurable overhead compared to baseline even for `size == 1`. >> >> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. >> >> Benchmark for `Arrays.hashCode`: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op >> ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op >> ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op >> ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op >> ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op >> ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op >> ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op >> ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op >> ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op >> ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op >> ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op >> ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op >> ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op >> ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op >> ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op >> ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op >> ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op >> ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op >> ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op >> ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op >> ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op >> ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op >> ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op >> ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op >> ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op >> >> >> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Explicitly lea external address I'm not convinced using basic types - with `T_BOOLEAN` for unsigned byte - improves this much. It'd of course be nice with something more canonical than a set of adhoc constants strewn in here to steer this, but maybe we should pass element size and signedness. I think this would be a reasonable cleanup. I'd also be willing to spend time rewriting as a stub call if someone could give me some pointers on how to best do that. This might be straightforward and simplify the implementation, but making a stub call could have noticeable overheads for small strings. A this is the common case the stub call overhead *could* be prohibitively expensive. An alternative is to keep the new node but extract the vectorized path as a stub routine and call it from inside the inlined intrinsic - similarly to what's done in `C2_MacroAssembler::string_compare` on aarch64. ------------- PR: https://git.openjdk.org/jdk/pull/10847 From xuelei at openjdk.org Wed Jan 11 21:32:14 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 11 Jan 2023 21:32:14 GMT Subject: RFR: 8299635: More test issues for deprecated sprintf in Xcode 14 In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 21:16:51 GMT, Mikael Vidstedt wrote: > This PR does not address all the remaining sprintf:s in hotspot, and with it now explicitly forbidden the build will fail: > This is a question to me as well. I noticed there are still some use of sprintf, but the building passed on MacOS and Linux. I was wondering if the following update really work (if the '...' parameter works for the forbidden?), or something else matters. FORBID_C_FUNCTION(int sprintf(char*, const char*, ...), "use os::snprintf"); > I count ~30 sprintf:s that need updating. > > I'm also curious: some of the sprintfs are C2 (src/hotspot/share/opto) - are your builds including C2? If so, why are you not running into the issue for those files? I'm new to hotspot. Do you know how could I enable C2? Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/11935 From jwilhelm at openjdk.org Wed Jan 11 21:54:24 2023 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Wed, 11 Jan 2023 21:54:24 GMT Subject: Integrated: Merge jdk20 In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 17:47:27 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 20 -> JDK 21 This pull request has now been integrated. Changeset: 33f3bd8f Author: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/33f3bd8fadb26a0f99c6a13474f8676639f91c0c Stats: 98 lines in 16 files changed: 53 ins; 19 del; 26 mod Merge ------------- PR: https://git.openjdk.org/jdk/pull/11952 From coleenp at openjdk.org Wed Jan 11 22:09:16 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 11 Jan 2023 22:09:16 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v2] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 14:47:45 GMT, Fredrik Bredberg wrote: >> src/hotspot/cpu/aarch64/continuationHelper_aarch64.inline.hpp line 2: >> >>> 1: /* >>> 2: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. >> >> Note, you changed the initial year. Should be: >> >> - * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2022, 2023, Oracle and/or its affiliates. All rights reserved. > > My sed script which updated all copyright headers to 2023 didn't take into account files with only one year in the copyright line. My bad. # foreach f (`cat file.list`) echo $f sed -e "s/Copyright (c) ([12][0-9][0-9][0-9]), [0-9][0-9][0-9][0-9], Oracle/Copyright (c) \1, 2023, Oracle/" \ -e "s/Copyright (c) ([12][0-9][013456789][012456789]), Oracle/Copyright (c) \1, 2023, Oracle/" <$f >$f.new diff $f $f.new mv $f.new $f end ------------- PR: https://git.openjdk.org/jdk/pull/11902 From bpb at openjdk.org Wed Jan 11 23:18:58 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 11 Jan 2023 23:18:58 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v8] In-Reply-To: References: Message-ID: > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299684: Convert test to JUnit 5; require 64-bit system with at least 8GB of memory ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11873/files - new: https://git.openjdk.org/jdk/pull/11873/files/95fd6652..7f99faee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=06-07 Stats: 76 lines in 1 file changed: 16 ins; 27 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Wed Jan 11 23:19:01 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 11 Jan 2023 23:19:01 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v5] In-Reply-To: References: <72tDSvqfz8V4UlUsCSLtIlplkn32UTucoTq62yRZhdo=.fab73681-bf7b-4ce7-b20b-8f2bca8f9373@github.com> Message-ID: On Wed, 11 Jan 2023 17:22:11 GMT, Brian Burkhalter wrote: >> test/jdk/java/nio/jni/NewDirectByteBuffer.java line 30: >> >>> 28: * @summary Verify that JNI NewDirectByteBuffer throws IllegalArgumentException >>> 29: * if the capacity is negative or greater than Integer::MAX_VALUE >>> 30: * @run main/native NewDirectByteBuffer >> >> You may have missed the comments about @requires and wondering if this test will run on 32-bit, as it will attempt to malloc 2GB. > > I saw the comments but was deferring that. Added **@requires** in 7f99faeebaea1dc55b592146aa3ba612bdb63d9e. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Wed Jan 11 23:20:18 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 11 Jan 2023 23:20:18 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v4] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 02:15:42 GMT, Brian Burkhalter wrote: > If you make it a JUnit test then you'll be able to paramatrized test with value sources, and use the assertions API when checking each of the buffer properties. Converted to a JUnit test in 7f99faeebaea1dc55b592146aa3ba612bdb63d9e. > Once the test is re-worded then you can get a sense as to how much memory it needs and whether you need a @requires in the test description to ensue that the test system has sufficient memory. Added **@requires** constraining to 64-bit arch and memory at least 8GB in 7f99faeebaea1dc55b592146aa3ba612bdb63d9e. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Thu Jan 12 00:15:45 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Jan 2023 00:15:45 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v9] In-Reply-To: References: Message-ID: > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299684: Remove spurious file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11873/files - new: https://git.openjdk.org/jdk/pull/11873/files/7f99faee..5269cae1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=07-08 Stats: 32 lines in 1 file changed: 0 ins; 32 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From duke at openjdk.org Thu Jan 12 00:44:22 2023 From: duke at openjdk.org (duke) Date: Thu, 12 Jan 2023 00:44:22 GMT Subject: Withdrawn: JDK-8293114: GC should trim the native heap In-Reply-To: <23KpPM4oPV6F1nz3g5CvIqvuX-ANcsMH4GuVNXjR-Lw=.b8d0fa2d-bb85-4899-8e21-f68ea64b988d@github.com> References: <23KpPM4oPV6F1nz3g5CvIqvuX-ANcsMH4GuVNXjR-Lw=.b8d0fa2d-bb85-4899-8e21-f68ea64b988d@github.com> Message-ID: On Tue, 30 Aug 2022 14:35:26 GMT, Thomas Stuefe wrote: > This RFE adds the option to auto-trim the Glibc heap as part of the GC cycle. If the VM process suffered high temporary malloc spikes (regardless whether from JVM- or user code), this could recover significant amounts of memory. > > We discussed this a year ago [1], but the item got pushed to the bottom of my work pile, therefore it took longer than I thought. > > ### Motivation > > The Glibc allocator is reluctant to return memory to the OS, much more so than other allocators. Temporary malloc spikes often carry over as permanent RSS increase. > > Note that C-heap retention is difficult to observe. Since it is freed memory, it won't show up in NMT, it is just a part of private RSS. > > Theoretically, retained memory is not lost since it will be reused by future mallocs. Retaining memory is therefore a bet on the future behavior of the app. The allocator bets on the application needing memory in the near future, and to satisfy that need via malloc. > > But an app's malloc load can fluctuate wildly, with temporary spikes and long idle periods. And if the app rolls its own custom allocators atop of mmap, as hotspot does, a lot of that memory cannot be reused even though it counts toward its memory footprint. > > To help, Glibc exports an API to trim the C-heap: `malloc_trim(3)`. With JDK 18 [2], SAP contributed a new jcmd command to *manually* trim the C-heap on Linux. This RFE adds a complementary way to trim automatically. > > #### Is this even a problem? > > Do we have high malloc spikes in the JVM process? We assume that malloc load from hotspot is usually low since hotspot typically clusters allocations into custom areas - metaspace, code heap, arenas. > > But arenas are subject to Glibc mem retention too. I was surprised by that since I assumed 32k arena chunks were too big to be subject of Glibc retention. But I saw in experiments that high arena peaks often cause lasting RSS increase. > > And of course, both hotspot and JDK do a lot of finer-granular mallocs outside of custom allocators. > > But many cases of high memory retention in Glibc I have seen in third-party JNI code. Libraries allocate large buffers via malloc as temporary buffers. In fact, since we introduced the jcmd "System.trim_native_heap", some of our customers started to call this command periodically in scripts to counter these issues. > > Therefore I think while high malloc spikes are atypical for a JVM process, they can happen. Having a way to auto-trim the native heap makes sense. > > ### When should we trim? > > We want to trim when we know there is a lull in malloc activity coming. But we have no knowledge of the future. > > We could build a heuristic based on malloc frequency. But on closer inspection that is difficult. We cannot use NMT, since NMT has no complete picture (only knows hotspot) and is usually disabled in production anyway. The only way to get *all* mallocs would be to use Glibc malloc hooks. We have done so in desperate cases at SAP, but Glibc removed malloc hooks in 2.35. It would be a messy solution anyway; best to avoid it. > > The next best thing is synchronizing with the larger C-heap users in the VM: compiler and GC. But compiler turns out not to be such a problem, since the compiler uses arenas, and arena chunks are buffered in a free pool with a five-second delay. That means compiler activity that happens in bursts, like at VM startup, will just shuffle arena chunks around from/to the arena free pool, never bothering to call malloc or free. > > That leaves the GC, which was also the experts' recommendation in last year's discussion [1]. Most GCs do uncommit, and trimming the native heap fits well into this. And we want to time the trim to not get into the way of a GC. Plus, integrating trims into the GC cycle lets us reuse GC logging and timing, thereby making RSS changes caused by trim-native visible to the analyst. > > > ### How it works: > > Patch adds new options (experimental for now, and shared among all GCs): > > > -XX:+GCTrimNativeHeap > -XX:GCTrimNativeHeapInterval= (defaults to 60) > > > `GCTrimNativeHeap` is off by default. If enabled, it will cause the VM to trim the native heap on full GCs as well as periodically. The period is defined by `GCTrimNativeHeapInterval`. Periodic trimming can be completely switched off with `GCTrimNativeHeapInterval=0`; in that case, we will only trim on full GCs. > > ### Examples: > > This is an artificial test that causes two high malloc spikes with long idle periods. Observe how RSS recovers with trim but stays up without trim. The trim interval was set to 15 seconds for the test, and no GC was invoked here; this is periodic trimming. > > ![alloc-test](http://cr.openjdk.java.net/~stuefe/other/autotrim/rss-all-collectors.png) > > (See here for parameters: [run script](http://cr.openjdk.java.net/~stuefe/other/autotrim/run-all.sh) ) > > Spring pet clinic boots up, then idles. Once with, once without trim, with the trim interval at 60 seconds default. Of course, if it were actually doing something instead of idling, trim effects would be smaller. But the point of trimming is to recover memory in idle periods. > > ![petclinic bootup](http://cr.openjdk.java.net/~stuefe/other/autotrim/spring-petclinic-rss-with-and-without-trim.png)) > > (See here for parameters: [run script](http://cr.openjdk.java.net/~stuefe/other/autotrim/run-petclinic-boot.sh) ) > > > > ### Implementation > > One problem I faced when implementing this was that trimming was non-interruptable. GCs usually split the uncommit work into smaller portions, which is impossible for `malloc_trim()`. > > So very slow trims could introduce longer GC pauses. I did not want this, therefore I implemented two ways to trim: > 1) GCs can opt to trim asynchronously. In that case, a `NativeTrimmer` thread runs on behalf of the GC and takes care of all trimming. The GC just nudges the `NativeTrimmer` at the end of its GC cycle, but the trim itself runs concurrently. > 2) GCs can do the trim inside their own thread, synchronously. It will have to wait until the trim is done. > > (1) has the advantage of giving us periodic trims even without GC activity (Shenandoah does this out of the box). > > #### Serial > > Serial does the trimming synchronously as part of a full GC, and only then. I did not want to spawn a separate thread for the SerialGC. Therefore Serial is the only GC that does not offer periodic trimming, it just trims on full GC. > > #### Parallel, G1, Z > > All of them do the trimming asynchronously via `NativeTrimmer`. They schedule the native trim at the end of a full collection. They also pause the trimming at the beginning of a cycle to not trim during GCs. > > #### Shenandoah > > Shenandoah does the trimming synchronously in its service thread, similar to how it handles uncommits. Since the service thread already runs concurrently and continuously, it can do periodic trimming; no need to spin a new thread. And this way we can reuse the Shenandoah timing classes. > > ### Patch details > > - adds three new functions to the `os` namespace: > - `os::trim_native_heap()` implementing trim > - `os::can_trim_native_heap()` and `os::should_trim_native_heap()` to return whether platform supports trimming resp. whether the platform considers trimming to be useful. > - replaces implementation of the cmd "System.trim_native_heap" with the new `os::trim_native_heap` > - provides a new wrapper function wrapping the tedious `mallinfo()` vs `mallinfo2()` business: `os::Linux::get_mallinfo()` > - adds a GC-shared utility class, `GCTrimNative`, that takes care of trimming and GC-logging and houses the `NativeTrimmer` thread class. > - adds a regression test > > > ### Tests > > Tested older Glibc (2.31), and newer Glibc (2.35) (`mallinfo()` vs` mallinfo2()`), on Linux x64. > > The rest of the tests will be done by GHA and in our SAP nightlies. > > > ### Remarks > > #### How about other allocators? > > I have seen this retention problem mainly with the Glibc and the AIX libc. Muslc returns memory more eagerly to the OS. I also tested with jemalloc and found it also reclaims more aggressively, therefore I don't think MacOS or BSD are affected that much by retention either. > > #### Trim costs? > > Trim-native is a tradeoff between memory and performance. We pay > - The cost to do the trim depends on how much is trimmed. Time ranges on my machine between < 1ms for no-op trims, to ~800ms for 32GB trims. > - The cost for re-acquiring the memory, should the memory be needed again, is the second cost factor. > > #### Predicting malloc_trim effects? > > `ShenandoahUncommit` avoids uncommits if they are not necessary, thus avoiding work and gc log spamming. I liked that and tried to follow that example. Tried to devise a way to predict the effect trim could have based on allocator info from mallinfo(3). That was quite frustrating since the documentation was confusing and I had to do a lot of experimenting. In the end, I came up with a heuristic to prevent obviously pointless trim attempts; see `os::should_trim_native_heap()`. I am not completely happy with it. > > #### glibc.malloc.trim_threshold? > > glibc has a tunable that looks like it could influence the willingness of Glibc to return memory to the OS, the "trim_threshold". In practice, I could not get it to do anything useful. Regardless of the setting, it never seemed to influence the trimming behavior. Even if it would work, I'm not sure we'd want to use that, since by doing malloc_trim manually we can space out the trims as we see fit, instead of paying the trim price for free(3). > > > - [1] https://mail.openjdk.org/pipermail/hotspot-dev/2021-August/054323.html > - [2] https://bugs.openjdk.org/browse/JDK-8269345 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/10085 From skuksenko at openjdk.org Thu Jan 12 03:31:00 2023 From: skuksenko at openjdk.org (Sergey Kuksenko) Date: Thu, 12 Jan 2023 03:31:00 GMT Subject: RFR: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions Message-ID: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions ------------- Commit messages: - jckeck cleanup - adjust inlining heuristic - do not count post call noop Changes: https://git.openjdk.org/jdk/pull/11958/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11958&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300002 Stats: 73 lines in 13 files changed: 71 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11958.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11958/head:pull/11958 PR: https://git.openjdk.org/jdk/pull/11958 From eosterlund at openjdk.org Thu Jan 12 06:12:18 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 12 Jan 2023 06:12:18 GMT Subject: RFR: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions In-Reply-To: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> References: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> Message-ID: On Thu, 12 Jan 2023 02:52:17 GMT, Sergey Kuksenko wrote: > 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions src/hotspot/share/opto/bytecodeInfo.cpp line 183: > 181: // Not hot. Check for medium-sized pre-existing nmethod at cold sites. > 182: if (callee_method->has_compiled_code() && > 183: callee_method->inline_instructions_size() > inline_small_code_size) { I do have to wonder if the actual problem is that this method is considered not hot by the InlineFrequenceRatio heuristic above. We are in the else clause and there is a comment saying this isn't hot. But obviously it was. Your approach tweaks the not hot path to still allow inlining, but I do wonder if it's the hot method detection scheme that could need some love. Just a thought... ------------- PR: https://git.openjdk.org/jdk/pull/11958 From thartmann at openjdk.org Thu Jan 12 06:19:16 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 12 Jan 2023 06:19:16 GMT Subject: RFR: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions In-Reply-To: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> References: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> Message-ID: <8RiIpov3KBqW1zB_HHqW0_ELy9K3PjYpfcAyOL83t0U=.ebead259-f9a9-45ca-98b0-01cbfa0354a5@github.com> On Thu, 12 Jan 2023 02:52:17 GMT, Sergey Kuksenko wrote: > 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions Please add a summary to the PR description. If you update the last usage in `ciMethod::has_compiled_code()`, it looks like `ciMethod::instructions_size` is not needed anymore and can be removed. Instead, you could just change its semantic to exclude nops (please also update the method's comments). src/hotspot/share/asm/assembler.hpp line 254: > 252: } > 253: void register_nop() { > 254: _assm->count_post_call_nop(_assm->pc() - _nop_start); Suggestion: _assm->count_post_call_nop(_assm->pc() - _nop_start); src/hotspot/share/asm/codeBuffer.hpp line 211: > 209: > 210: void count_post_call_nop(int size) { > 211: _post_call_nop_size += size; Suggestion: _post_call_nop_size += size; src/hotspot/share/ci/ciMethod.cpp line 1146: > 1144: _inline_instructions_size = 0; > 1145: } > 1146: ); Indentation looks weird. I see that you copied it from `ciMethod::instructions_size`, that one should be fixed as well. ------------- Changes requested by thartmann (Reviewer). PR: https://git.openjdk.org/jdk/pull/11958 From kbarrett at openjdk.org Thu Jan 12 07:04:18 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 12 Jan 2023 07:04:18 GMT Subject: RFR: 8299032: Interface IN_NATIVE oop stores for C2 In-Reply-To: References: <61HZ-hCw_ZoDZCtsDLsz-tfPE6S7Ox_1nXApLQnZ1SU=.60c813cf-a5d8-4a3c-a2a1-86d7af05d042@github.com> Message-ID: On Tue, 10 Jan 2023 09:37:01 GMT, Erik ?sterlund wrote: > > Not a review, since I'm not sufficiently knowledgeable about C2 to really do justice to it. Rather, a couple questions/comments. > > We made a concerted effort to reduce/eliminate oops in native storage, instead using OopStorage entries. This kind of feels like backsliding on that effort. Why? > > It isn't a backsliding on that effort. This code is indeed using OopStorage. An OopHandle::replace uses IN_NATIVE stores. This is essentially an intrinsic that replaces the contents of an OopHandle, so similarly it should use an IN_NATIVE store for that. Having said that, perhaps it would have been more clear if there was a high level function of some sort with a name like oop_handle_replace containing the IN_NATIVE store? Oh, I see now. The `make_load` is smashing through the OopHandle abstraction. That's of course not new to this change. >> src/hotspot/share/opto/library_call.cpp line 3353: >> >>> 3351: thread_obj_handle = _gvn.transform(thread_obj_handle); >>> 3352: const TypePtr *adr_type = _gvn.type(thread_obj_handle)->isa_ptr(); >>> 3353: access_store_at(NULL, thread_obj_handle, adr_type, arr, _gvn.type(arr), T_OBJECT, IN_NATIVE | MO_UNORDERED); >> >> Old code has a `control()` constraint on the store. Is it okay to drop that? > > The first parameter to access_store_at, is the containing object, not the control (which might be different to the address). As for IN_NATIVE stores, there is no containing object, which is what the NULL denotes. In the backend, it does indeed attach the current control inside of BarrierSetC2::store_at_resolved. Thanks for the explanation. ------------- PR: https://git.openjdk.org/jdk/pull/11777 From thomas.stuefe at gmail.com Thu Jan 12 07:06:43 2023 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 12 Jan 2023 08:06:43 +0100 Subject: RFC: regarding metaspace(metadata?) dump In-Reply-To: References: Message-ID: Hi Yi, A lot of what you try to do already exists. For example, we also have `VM.metaspace`. This is a quite powerful command to analyze Metaspace-related issues, especially for fragmentation and other wastages. Generally speaking, it is the tool you use to look at the underpinnings of metaspace, the allocator, while tools like `VM.classloaders`, `VM.classloader_stats` and `VM.classes` look at things "from above", e.g. walk the CLDG. All these tools have already a bit of overlap. For analyzing OOMEs, you need several tools, since it can be caused by multiple issues. E.g. tools that walk the CLDG don't see fragmentation, or unclaimed metaspace for dead loaders. Please find more remarks inline. On Wed, Jan 11, 2023 at 1:56 PM Yi Yang wrote: > Hi, > > Internally, we often receive feedback from users and ask for help on > metaspace-related issues, for example > 1. Users are eager to know which GroovyClassLoader loads which classes, > why they are not unloaded, > and why they are leading to Metaspace OOME. > There are several tools to do this, for example: `VM.metaspace show-loaders show-classes` `VM.classloaders show-classes` both show you loaded classes by loader, and the former also shows you metaspace stats needed to understand OOMEs. None of these tools shows you why loaders are kept alive, but for that you need heap- and GC-root-analysis. This quickly enters the territory of Eclipse MAT and similar tools, where having a text-based tool alone gets cumbersome. > 2. They want to know the class structure of dynamically generated classes > in some scenarios such as > deserialization > Interesting. This seems to be a very specific query; not sure how general the need for this is. `VM.classes -verbose` shows a part of the story. > 3. Finding memory leaking about duplicated classes > Again, `VM.metaspace show-loaders show-classes` `VM.classloaders show-classes` but also `VM.classes` and `VM.classloader_stats` are your friends here. > ... > Internally we implemented a metaspace dump that generates human-readable > text, it looks something like this: > > [Basic Information] > Dump Reason : JCMD > MaxMetaspaceSize : 18446744073709547520 B > CompressedClassSpaceSize : 1073741824 B > Class Space Used : 309992 B > Class Space Capacity : 395264 B > ... > [Class Loader Data] > ClassLoaderData : loader = 0x000000008024f928, loader_klass = > 0x0000000800010098, loader_klass_name = > sun/misc/Launcher$AppClassLoader, label = N/A > Class Used Chunks : > * Chunk : [0x0000000800060000, 0x0000000800060230, 0x0000000800060800) > NonClass Used Chunks : > * Chunk : [0x00007fd8379c1000, 0x00007fd8379c1350, 0x00007fd8379c2000) > Klasses : > Klass : 0x0000000800060028, name = Test, size = 520 B > ConstantPool : 0x00007fd8379c1050, size = 296 B > ... > > `VM.metaspace` shows you the chunk composition of arenas if needed. E.g. : `VM.metaspace by-chunktype show-loaders` ``` Usage per loader: 1: CLD 0x00007f72fc29b820: "app" instance of jdk.internal.loader.ClassLoaders$AppClassLoader Loaded classes: 1: de.stuefe.repros.MiscUtils$$Lambda$1/0x0000000801001448 2: de.stuefe.repros.MiscUtils 3: de.stuefe.repros.Simple2 4: de.stuefe.repros.Simple 5: de.stuefe.repros.SimpleBase 6: de.stuefe.repros.I2 7: de.stuefe.repros.I1 -total-: 7 classes Non-Class: Usage by chunk level: 4m chunks: (none) 2m chunks: (none) 1m chunks: (none) 512k chunks: (none) 256k chunks: (none) 128k chunks: (none) 64k chunks: (none) 32k chunks: (none) 16k chunks: (none) 8k chunks: 1 chunk, 8,00 KB capacity, 8,00 KB (100%) committed, 8,00 KB (100%) used, 0 bytes ( 0%) free, 0 bytes ( 0%) waste 4k chunks: 1 chunk, 4,00 KB capacity, 4,00 KB (100%) committed, 256 bytes ( 6%) used, 3,75 KB ( 94%) free, 0 bytes ( 0%) waste 2k chunks: (none) 1k chunks: (none) -total-: 2 chunks, 12,00 KB capacity, 12,00 KB (100%) committed, 8,25 KB ( 69%) used, 3,75 KB ( 31%) free, 0 bytes ( 0%) waste deallocated: 1 blocks with 24 bytes Class: Usage by chunk level: .... and so forth ``` but for analyzing potential fragmentation issues (which have been rare since JEP 387) the "Waste" section at the end of the printout is much more helpful, e.g.: ``` Waste (unused committed space):(percentages refer to total committed size 384,00 KB): Waste in chunks in use: 0 bytes ( 0%) Free in chunks in use: 85,01 KB ( 22%) In free chunks: 0 bytes ( 0%) Deallocated from chunks in use: 928 bytes ( <1%) (3 blocks) -total-: 85,91 KB ( 22%) ``` It has been working effectively for several years and has helped many users > solve metaspace-related problems. > But a more user-friendly way is that JDK can inherently support this > capability. We hope that format of the metaspace > dump file can take both flexibility and compatibility into account, and > the content of dump file should be detailed > enough to meet the needs of both application developers and lower-level > developers. > > Based on above considerations, I think using JSON as its file format is an > appropriate solution(But XML or binary > format are still not excluded as candidates). Specifically, in earlier > thoughts, I thought the format of the metaspace > file could be as follows(pretty printed) > > https://gist.github.com/y1yang0/ab3034b6381b8a9d215602c89af4e9c3 > > Using the JSON format, we can flexibly add new fields without breaking > compatibility. It is debatable as to which data > to write. We can reach a consensus that third-party parsers(Metaspace > Analyzer Tool) can at least reconstruct Java > source code from the dump file. Based on this, we can write more useful > information for low-level troubleshooting > or debugging. (e.g. the init_state of InstanceKlass). > In addition, we can even output the native code and associated information > with regard to Method, third-party parser > can reconstruct the human-readable assembly representation of the compiled > method based on dump file. To some extent, > we have implemented code cache dump by the way. For this reason, I'm not > sure if the title of the RFC proposal should > be called metaspace dump, maybe metadata dump? It looks more like a > metadata-dump framework. > > Do you have any thoughts about metaspace/metadata dump? Looking forward to > hearing your feedback, any comments are invaluable! > > Best regards, > Yi Yang > Analyzing the structure of generated classes sounds interesting, and could help with analyzing issues with bytecode instrumentation tools. For analyzing general metaspace OOMEs we are already covered quite well. Not perfect, but your proposal does intersect with existing tools a lot. To keep code complexity down, I'd rather avoid adding duplicate features. Cheers, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Thu Jan 12 07:06:43 2023 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 12 Jan 2023 08:06:43 +0100 Subject: RFC: regarding metaspace(metadata?) dump In-Reply-To: References: Message-ID: Hi Yi, A lot of what you try to do already exists. For example, we also have `VM.metaspace`. This is a quite powerful command to analyze Metaspace-related issues, especially for fragmentation and other wastages. Generally speaking, it is the tool you use to look at the underpinnings of metaspace, the allocator, while tools like `VM.classloaders`, `VM.classloader_stats` and `VM.classes` look at things "from above", e.g. walk the CLDG. All these tools have already a bit of overlap. For analyzing OOMEs, you need several tools, since it can be caused by multiple issues. E.g. tools that walk the CLDG don't see fragmentation, or unclaimed metaspace for dead loaders. Please find more remarks inline. On Wed, Jan 11, 2023 at 1:56 PM Yi Yang wrote: > Hi, > > Internally, we often receive feedback from users and ask for help on > metaspace-related issues, for example > 1. Users are eager to know which GroovyClassLoader loads which classes, > why they are not unloaded, > and why they are leading to Metaspace OOME. > There are several tools to do this, for example: `VM.metaspace show-loaders show-classes` `VM.classloaders show-classes` both show you loaded classes by loader, and the former also shows you metaspace stats needed to understand OOMEs. None of these tools shows you why loaders are kept alive, but for that you need heap- and GC-root-analysis. This quickly enters the territory of Eclipse MAT and similar tools, where having a text-based tool alone gets cumbersome. > 2. They want to know the class structure of dynamically generated classes > in some scenarios such as > deserialization > Interesting. This seems to be a very specific query; not sure how general the need for this is. `VM.classes -verbose` shows a part of the story. > 3. Finding memory leaking about duplicated classes > Again, `VM.metaspace show-loaders show-classes` `VM.classloaders show-classes` but also `VM.classes` and `VM.classloader_stats` are your friends here. > ... > Internally we implemented a metaspace dump that generates human-readable > text, it looks something like this: > > [Basic Information] > Dump Reason : JCMD > MaxMetaspaceSize : 18446744073709547520 B > CompressedClassSpaceSize : 1073741824 B > Class Space Used : 309992 B > Class Space Capacity : 395264 B > ... > [Class Loader Data] > ClassLoaderData : loader = 0x000000008024f928, loader_klass = > 0x0000000800010098, loader_klass_name = > sun/misc/Launcher$AppClassLoader, label = N/A > Class Used Chunks : > * Chunk : [0x0000000800060000, 0x0000000800060230, 0x0000000800060800) > NonClass Used Chunks : > * Chunk : [0x00007fd8379c1000, 0x00007fd8379c1350, 0x00007fd8379c2000) > Klasses : > Klass : 0x0000000800060028, name = Test, size = 520 B > ConstantPool : 0x00007fd8379c1050, size = 296 B > ... > > `VM.metaspace` shows you the chunk composition of arenas if needed. E.g. : `VM.metaspace by-chunktype show-loaders` ``` Usage per loader: 1: CLD 0x00007f72fc29b820: "app" instance of jdk.internal.loader.ClassLoaders$AppClassLoader Loaded classes: 1: de.stuefe.repros.MiscUtils$$Lambda$1/0x0000000801001448 2: de.stuefe.repros.MiscUtils 3: de.stuefe.repros.Simple2 4: de.stuefe.repros.Simple 5: de.stuefe.repros.SimpleBase 6: de.stuefe.repros.I2 7: de.stuefe.repros.I1 -total-: 7 classes Non-Class: Usage by chunk level: 4m chunks: (none) 2m chunks: (none) 1m chunks: (none) 512k chunks: (none) 256k chunks: (none) 128k chunks: (none) 64k chunks: (none) 32k chunks: (none) 16k chunks: (none) 8k chunks: 1 chunk, 8,00 KB capacity, 8,00 KB (100%) committed, 8,00 KB (100%) used, 0 bytes ( 0%) free, 0 bytes ( 0%) waste 4k chunks: 1 chunk, 4,00 KB capacity, 4,00 KB (100%) committed, 256 bytes ( 6%) used, 3,75 KB ( 94%) free, 0 bytes ( 0%) waste 2k chunks: (none) 1k chunks: (none) -total-: 2 chunks, 12,00 KB capacity, 12,00 KB (100%) committed, 8,25 KB ( 69%) used, 3,75 KB ( 31%) free, 0 bytes ( 0%) waste deallocated: 1 blocks with 24 bytes Class: Usage by chunk level: .... and so forth ``` but for analyzing potential fragmentation issues (which have been rare since JEP 387) the "Waste" section at the end of the printout is much more helpful, e.g.: ``` Waste (unused committed space):(percentages refer to total committed size 384,00 KB): Waste in chunks in use: 0 bytes ( 0%) Free in chunks in use: 85,01 KB ( 22%) In free chunks: 0 bytes ( 0%) Deallocated from chunks in use: 928 bytes ( <1%) (3 blocks) -total-: 85,91 KB ( 22%) ``` It has been working effectively for several years and has helped many users > solve metaspace-related problems. > But a more user-friendly way is that JDK can inherently support this > capability. We hope that format of the metaspace > dump file can take both flexibility and compatibility into account, and > the content of dump file should be detailed > enough to meet the needs of both application developers and lower-level > developers. > > Based on above considerations, I think using JSON as its file format is an > appropriate solution(But XML or binary > format are still not excluded as candidates). Specifically, in earlier > thoughts, I thought the format of the metaspace > file could be as follows(pretty printed) > > https://gist.github.com/y1yang0/ab3034b6381b8a9d215602c89af4e9c3 > > Using the JSON format, we can flexibly add new fields without breaking > compatibility. It is debatable as to which data > to write. We can reach a consensus that third-party parsers(Metaspace > Analyzer Tool) can at least reconstruct Java > source code from the dump file. Based on this, we can write more useful > information for low-level troubleshooting > or debugging. (e.g. the init_state of InstanceKlass). > In addition, we can even output the native code and associated information > with regard to Method, third-party parser > can reconstruct the human-readable assembly representation of the compiled > method based on dump file. To some extent, > we have implemented code cache dump by the way. For this reason, I'm not > sure if the title of the RFC proposal should > be called metaspace dump, maybe metadata dump? It looks more like a > metadata-dump framework. > > Do you have any thoughts about metaspace/metadata dump? Looking forward to > hearing your feedback, any comments are invaluable! > > Best regards, > Yi Yang > Analyzing the structure of generated classes sounds interesting, and could help with analyzing issues with bytecode instrumentation tools. For analyzing general metaspace OOMEs we are already covered quite well. Not perfect, but your proposal does intersect with existing tools a lot. To keep code complexity down, I'd rather avoid adding duplicate features. Cheers, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei at openjdk.org Thu Jan 12 07:28:13 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Thu, 12 Jan 2023 07:28:13 GMT Subject: RFR: 8299635: More test issues for deprecated sprintf in Xcode 14 In-Reply-To: References: Message-ID: <7NTMxoOgPK0vqq-XGKI350AKnIjnA8_OYKzZLhLMLOc=.cd43cc7d-eff3-4046-989a-98173ee98500@github.com> On Wed, 11 Jan 2023 21:29:01 GMT, Xue-Lei Andrew Fan wrote: > > I'm also curious: some of the sprintfs are C2 (src/hotspot/share/opto) - are your builds including C2? If so, why are you not running into the issue for those files? > > I'm new to hotspot. Do you know how could I enable C2? Thanks! Never mind, I got it from configuration help message (use --with-jvm-features=compiler2). ------------- PR: https://git.openjdk.org/jdk/pull/11935 From stefank at openjdk.org Thu Jan 12 07:35:15 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 12 Jan 2023 07:35:15 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v7] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 20:53:38 GMT, Justin King wrote: >> Remove abstraction that is a holdover from Solaris. Direct usages of `MmapArrayAllocator` have been switched to normal `malloc`. The justification is that none of the code paths are called from signal handlers, so using `mmap` directly does not make sense and is potentially slower than going through `malloc` which can potentially re-use memory without making any system calls. The remaining usages of `ArrayAllocator` and `MallocArrayAllocator` are equivalent. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Fix incompatible pointer types > > Signed-off-by: Justin King Thanks for the ZGC update. I have a request to slightly modify the style a bit. Would you mind taking this patch: https://github.com/stefank/jdk/tree/pr_11931 There's a FIXME about that allocation.inline.hpp file is now empty. Will you remove it in this patch? I'd prefer if you did. Alternatively, remove the FIXME from this patch and then immediately clean this up as a separate patch. ------------- Changes requested by stefank (Reviewer). PR: https://git.openjdk.org/jdk/pull/11931 From mbaesken at openjdk.org Thu Jan 12 08:08:20 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 12 Jan 2023 08:08:20 GMT Subject: Integrated: JDK-8299672: Enhance HeapDump JFR event In-Reply-To: References: Message-ID: <6yF2yeQ3G1GF45XLUBpePBekGJWBBje4b0jGJZh-Ic8=.c41a9d5c-183b-4eef-90a7-9a0ec3e33005@github.com> On Thu, 5 Jan 2023 14:54:31 GMT, Matthias Baesken wrote: > Enhance the JFR Event HeapDump with the additional interesting fields, compression and overwrite. > Add some UL logging in case the heap dump writing failed . This pull request has now been integrated. Changeset: 0ee8cac7 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/0ee8cac7c7b317c780e4a08c2dd6daf36301a3e5 Stats: 15 lines in 3 files changed: 9 ins; 0 del; 6 mod 8299672: Enhance HeapDump JFR event Reviewed-by: rschmelter, clanger ------------- PR: https://git.openjdk.org/jdk/pull/11864 From qingfeng.yy at alibaba-inc.com Thu Jan 12 08:29:00 2023 From: qingfeng.yy at alibaba-inc.com (Yi Yang) Date: Thu, 12 Jan 2023 16:29:00 +0800 Subject: =?UTF-8?B?UmU6IFJGQzogcmVnYXJkaW5nIG1ldGFzcGFjZShtZXRhZGF0YT8pIGR1bXA=?= In-Reply-To: References: , Message-ID: <5575ed15-6783-456c-ae42-703c440f84b5.qingfeng.yy@alibaba-inc.com> Thanks Ioi and Thomas for your valuable thoughts! I list some pros about metaspace dump. 1. Standardization. The format of metadata dump is standard and well-formed. It could be seamlessly integrated with DevOps/Diagnose/APM platforms, while SA is interactively and the output of jcmd is not well-formed and parser-unfriendly, and its content is subject to change. You can't expect DevOps platform to use SA/coredump/gdb conveniently and automatically in production environment. 2. Functionality. MetaspaceDumpBeforeFullGC could generate a small dump for further debugging, it works as well as heap dump. 3. JVM Metadata. Codecache dump, method counter, method data, they are unexplored scopes, reconstruct human-readable representation of compiled method. 4. Complexity. In my humble opinion, all of this stuff such as by-chunktype/show-loaders/VM.classloader_stats/VM.classloader_hierarchy/etc could be done in other place. VM is eligible to provides a standard and rich raw metadata output, third-party parser and UI render display them in their way instead of continuously adding new filter/grouping/hierarcy/VM.method_counter features when we do want to know them. Heap dump is a good example, it dumps all objects/symbols/etc to a binary file, and third-party tools orchestrate them to histogram/thread/classloader/domtree. Basically, I know the content of metaspace dump file has overlap with some existing tools such as SA/jcmd/coredump/gdb/HeapDump, as Thomas commented inlinely, I don?t think metaspace dump can troubleshoot many problems that it is the only solution. I think metadata dump is more about providing a standardized and parser-friendly framework, so that users at all levels can inspect JVM metadata information they care about. In addition, something like M(etaspace)AT could orchestrate dump content with filter/grouping/hierarchy options. > Also you mentioned that "Internally we implemented a metaspace dump that generates human-readable text". Can you share how this tool was implemented? That's not surprising, it iterates CLD/Classes/etc and dumps basic information about metaspace, a demo metaspace dump can be found at https://gist.github.com/y1yang0/683d8a58dd946b3e9180682863df55ea ------------------------------------------------------------------ From:Thomas St?fe Send Time:2023 Jan. 12 (Thu.) 15:06 To:"YANG, Yi" Cc:HotSpot Open Source Developers ; hotspot-runtime-dev ; hotspot-dev Subject:Re: RFC: regarding metaspace(metadata?) dump Hi Yi, A lot of what you try to do already exists. For example, we also have `VM.metaspace`. This is a quite powerful command to analyze Metaspace-related issues, especially for fragmentation and other wastages. Generally speaking, it is the tool you use to look at the underpinnings of metaspace, the allocator, while tools like `VM.classloaders`, `VM.classloader_stats` and `VM.classes` look at things "from above", e.g. walk the CLDG. All these tools have already a bit of overlap. For analyzing OOMEs, you need several tools, since it can be caused by multiple issues. E.g. tools that walk the CLDG don't see fragmentation, or unclaimed metaspace for dead loaders. Please find more remarks inline. On Wed, Jan 11, 2023 at 1:56 PM Yi Yang > wrote: Hi, Internally, we often receive feedback from users and ask for help on metaspace-related issues, for example 1. Users are eager to know which GroovyClassLoader loads which classes, why they are not unloaded, and why they are leading to Metaspace OOME. There are several tools to do this, for example: `VM.metaspace show-loaders show-classes` `VM.classloaders show-classes` both show you loaded classes by loader, and the former also shows you metaspace stats needed to understand OOMEs. None of these tools shows you why loaders are kept alive, but for that you need heap- and GC-root-analysis. This quickly enters the territory of Eclipse MAT and similar tools, where having a text-based tool alone gets cumbersome. 2. They want to know the class structure of dynamically generated classes in some scenarios such as deserialization Interesting. This seems to be a very specific query; not sure how general the need for this is. `VM.classes -verbose` shows a part of the story. 3. Finding memory leaking about duplicated classes Again, `VM.metaspace show-loaders show-classes` `VM.classloaders show-classes` but also `VM.classes` and `VM.classloader_stats` are your friends here. ... Internally we implemented a metaspace dump that generates human-readable text, it looks something like this: [Basic Information] Dump Reason : JCMD MaxMetaspaceSize : 18446744073709547520 B CompressedClassSpaceSize : 1073741824 B Class Space Used : 309992 B Class Space Capacity : 395264 B ... [Class Loader Data] ClassLoaderData : loader = 0x000000008024f928, loader_klass = 0x0000000800010098, loader_klass_name = sun/misc/Launcher$AppClassLoader, label = N/A Class Used Chunks : * Chunk : [0x0000000800060000, 0x0000000800060230, 0x0000000800060800) NonClass Used Chunks : * Chunk : [0x00007fd8379c1000, 0x00007fd8379c1350, 0x00007fd8379c2000) Klasses : Klass : 0x0000000800060028, name = Test, size = 520 B ConstantPool : 0x00007fd8379c1050, size = 296 B ... `VM.metaspace` shows you the chunk composition of arenas if needed. E.g. : `VM.metaspace by-chunktype show-loaders` ``` Usage per loader: 1: CLD 0x00007f72fc29b820: "app" instance of jdk.internal.loader.ClassLoaders$AppClassLoader Loaded classes: 1: de.stuefe.repros.MiscUtils$$Lambda$1/0x0000000801001448 2: de.stuefe.repros.MiscUtils 3: de.stuefe.repros.Simple2 4: de.stuefe.repros.Simple 5: de.stuefe.repros.SimpleBase 6: de.stuefe.repros.I2 7: de.stuefe.repros.I1 -total-: 7 classes Non-Class: Usage by chunk level: 4m chunks: (none) 2m chunks: (none) 1m chunks: (none) 512k chunks: (none) 256k chunks: (none) 128k chunks: (none) 64k chunks: (none) 32k chunks: (none) 16k chunks: (none) 8k chunks: 1 chunk, 8,00 KB capacity, 8,00 KB (100%) committed, 8,00 KB (100%) used, 0 bytes ( 0%) free, 0 bytes ( 0%) waste 4k chunks: 1 chunk, 4,00 KB capacity, 4,00 KB (100%) committed, 256 bytes ( 6%) used, 3,75 KB ( 94%) free, 0 bytes ( 0%) waste 2k chunks: (none) 1k chunks: (none) -total-: 2 chunks, 12,00 KB capacity, 12,00 KB (100%) committed, 8,25 KB ( 69%) used, 3,75 KB ( 31%) free, 0 bytes ( 0%) waste deallocated: 1 blocks with 24 bytes Class: Usage by chunk level: .... and so forth ``` but for analyzing potential fragmentation issues (which have been rare since JEP 387) the "Waste" section at the end of the printout is much more helpful, e.g.: ``` Waste (unused committed space):(percentages refer to total committed size 384,00 KB): Waste in chunks in use: 0 bytes ( 0%) Free in chunks in use: 85,01 KB ( 22%) In free chunks: 0 bytes ( 0%) Deallocated from chunks in use: 928 bytes ( <1%) (3 blocks) -total-: 85,91 KB ( 22%) ``` It has been working effectively for several years and has helped many users solve metaspace-related problems. But a more user-friendly way is that JDK can inherently support this capability. We hope that format of the metaspace dump file can take both flexibility and compatibility into account, and the content of dump file should be detailed enough to meet the needs of both application developers and lower-level developers. Based on above considerations, I think using JSON as its file format is an appropriate solution(But XML or binary format are still not excluded as candidates). Specifically, in earlier thoughts, I thought the format of the metaspace file could be as follows(pretty printed) https://gist.github.com/y1yang0/ab3034b6381b8a9d215602c89af4e9c3 Using the JSON format, we can flexibly add new fields without breaking compatibility. It is debatable as to which data to write. We can reach a consensus that third-party parsers(Metaspace Analyzer Tool) can at least reconstruct Java source code from the dump file. Based on this, we can write more useful information for low-level troubleshooting or debugging. (e.g. the init_state of InstanceKlass). In addition, we can even output the native code and associated information with regard to Method, third-party parser can reconstruct the human-readable assembly representation of the compiled method based on dump file. To some extent, we have implemented code cache dump by the way. For this reason, I'm not sure if the title of the RFC proposal should be called metaspace dump, maybe metadata dump? It looks more like a metadata-dump framework. Do you have any thoughts about metaspace/metadata dump? Looking forward to hearing your feedback, any comments are invaluable! Best regards, Yi Yang Analyzing the structure of generated classes sounds interesting, and could help with analyzing issues with bytecode instrumentation tools. For analyzing general metaspace OOMEs we are already covered quite well. Not perfect, but your proposal does intersect with existing tools a lot. To keep code complexity down, I'd rather avoid adding duplicate features. Cheers, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From qingfeng.yy at alibaba-inc.com Thu Jan 12 08:29:00 2023 From: qingfeng.yy at alibaba-inc.com (Yi Yang) Date: Thu, 12 Jan 2023 16:29:00 +0800 Subject: =?UTF-8?B?UmU6IFJGQzogcmVnYXJkaW5nIG1ldGFzcGFjZShtZXRhZGF0YT8pIGR1bXA=?= In-Reply-To: References: , Message-ID: <5575ed15-6783-456c-ae42-703c440f84b5.qingfeng.yy@alibaba-inc.com> Thanks Ioi and Thomas for your valuable thoughts! I list some pros about metaspace dump. 1. Standardization. The format of metadata dump is standard and well-formed. It could be seamlessly integrated with DevOps/Diagnose/APM platforms, while SA is interactively and the output of jcmd is not well-formed and parser-unfriendly, and its content is subject to change. You can't expect DevOps platform to use SA/coredump/gdb conveniently and automatically in production environment. 2. Functionality. MetaspaceDumpBeforeFullGC could generate a small dump for further debugging, it works as well as heap dump. 3. JVM Metadata. Codecache dump, method counter, method data, they are unexplored scopes, reconstruct human-readable representation of compiled method. 4. Complexity. In my humble opinion, all of this stuff such as by-chunktype/show-loaders/VM.classloader_stats/VM.classloader_hierarchy/etc could be done in other place. VM is eligible to provides a standard and rich raw metadata output, third-party parser and UI render display them in their way instead of continuously adding new filter/grouping/hierarcy/VM.method_counter features when we do want to know them. Heap dump is a good example, it dumps all objects/symbols/etc to a binary file, and third-party tools orchestrate them to histogram/thread/classloader/domtree. Basically, I know the content of metaspace dump file has overlap with some existing tools such as SA/jcmd/coredump/gdb/HeapDump, as Thomas commented inlinely, I don?t think metaspace dump can troubleshoot many problems that it is the only solution. I think metadata dump is more about providing a standardized and parser-friendly framework, so that users at all levels can inspect JVM metadata information they care about. In addition, something like M(etaspace)AT could orchestrate dump content with filter/grouping/hierarchy options. > Also you mentioned that "Internally we implemented a metaspace dump that generates human-readable text". Can you share how this tool was implemented? That's not surprising, it iterates CLD/Classes/etc and dumps basic information about metaspace, a demo metaspace dump can be found at https://gist.github.com/y1yang0/683d8a58dd946b3e9180682863df55ea ------------------------------------------------------------------ From:Thomas St?fe Send Time:2023 Jan. 12 (Thu.) 15:06 To:"YANG, Yi" Cc:HotSpot Open Source Developers ; hotspot-runtime-dev ; hotspot-dev Subject:Re: RFC: regarding metaspace(metadata?) dump Hi Yi, A lot of what you try to do already exists. For example, we also have `VM.metaspace`. This is a quite powerful command to analyze Metaspace-related issues, especially for fragmentation and other wastages. Generally speaking, it is the tool you use to look at the underpinnings of metaspace, the allocator, while tools like `VM.classloaders`, `VM.classloader_stats` and `VM.classes` look at things "from above", e.g. walk the CLDG. All these tools have already a bit of overlap. For analyzing OOMEs, you need several tools, since it can be caused by multiple issues. E.g. tools that walk the CLDG don't see fragmentation, or unclaimed metaspace for dead loaders. Please find more remarks inline. On Wed, Jan 11, 2023 at 1:56 PM Yi Yang > wrote: Hi, Internally, we often receive feedback from users and ask for help on metaspace-related issues, for example 1. Users are eager to know which GroovyClassLoader loads which classes, why they are not unloaded, and why they are leading to Metaspace OOME. There are several tools to do this, for example: `VM.metaspace show-loaders show-classes` `VM.classloaders show-classes` both show you loaded classes by loader, and the former also shows you metaspace stats needed to understand OOMEs. None of these tools shows you why loaders are kept alive, but for that you need heap- and GC-root-analysis. This quickly enters the territory of Eclipse MAT and similar tools, where having a text-based tool alone gets cumbersome. 2. They want to know the class structure of dynamically generated classes in some scenarios such as deserialization Interesting. This seems to be a very specific query; not sure how general the need for this is. `VM.classes -verbose` shows a part of the story. 3. Finding memory leaking about duplicated classes Again, `VM.metaspace show-loaders show-classes` `VM.classloaders show-classes` but also `VM.classes` and `VM.classloader_stats` are your friends here. ... Internally we implemented a metaspace dump that generates human-readable text, it looks something like this: [Basic Information] Dump Reason : JCMD MaxMetaspaceSize : 18446744073709547520 B CompressedClassSpaceSize : 1073741824 B Class Space Used : 309992 B Class Space Capacity : 395264 B ... [Class Loader Data] ClassLoaderData : loader = 0x000000008024f928, loader_klass = 0x0000000800010098, loader_klass_name = sun/misc/Launcher$AppClassLoader, label = N/A Class Used Chunks : * Chunk : [0x0000000800060000, 0x0000000800060230, 0x0000000800060800) NonClass Used Chunks : * Chunk : [0x00007fd8379c1000, 0x00007fd8379c1350, 0x00007fd8379c2000) Klasses : Klass : 0x0000000800060028, name = Test, size = 520 B ConstantPool : 0x00007fd8379c1050, size = 296 B ... `VM.metaspace` shows you the chunk composition of arenas if needed. E.g. : `VM.metaspace by-chunktype show-loaders` ``` Usage per loader: 1: CLD 0x00007f72fc29b820: "app" instance of jdk.internal.loader.ClassLoaders$AppClassLoader Loaded classes: 1: de.stuefe.repros.MiscUtils$$Lambda$1/0x0000000801001448 2: de.stuefe.repros.MiscUtils 3: de.stuefe.repros.Simple2 4: de.stuefe.repros.Simple 5: de.stuefe.repros.SimpleBase 6: de.stuefe.repros.I2 7: de.stuefe.repros.I1 -total-: 7 classes Non-Class: Usage by chunk level: 4m chunks: (none) 2m chunks: (none) 1m chunks: (none) 512k chunks: (none) 256k chunks: (none) 128k chunks: (none) 64k chunks: (none) 32k chunks: (none) 16k chunks: (none) 8k chunks: 1 chunk, 8,00 KB capacity, 8,00 KB (100%) committed, 8,00 KB (100%) used, 0 bytes ( 0%) free, 0 bytes ( 0%) waste 4k chunks: 1 chunk, 4,00 KB capacity, 4,00 KB (100%) committed, 256 bytes ( 6%) used, 3,75 KB ( 94%) free, 0 bytes ( 0%) waste 2k chunks: (none) 1k chunks: (none) -total-: 2 chunks, 12,00 KB capacity, 12,00 KB (100%) committed, 8,25 KB ( 69%) used, 3,75 KB ( 31%) free, 0 bytes ( 0%) waste deallocated: 1 blocks with 24 bytes Class: Usage by chunk level: .... and so forth ``` but for analyzing potential fragmentation issues (which have been rare since JEP 387) the "Waste" section at the end of the printout is much more helpful, e.g.: ``` Waste (unused committed space):(percentages refer to total committed size 384,00 KB): Waste in chunks in use: 0 bytes ( 0%) Free in chunks in use: 85,01 KB ( 22%) In free chunks: 0 bytes ( 0%) Deallocated from chunks in use: 928 bytes ( <1%) (3 blocks) -total-: 85,91 KB ( 22%) ``` It has been working effectively for several years and has helped many users solve metaspace-related problems. But a more user-friendly way is that JDK can inherently support this capability. We hope that format of the metaspace dump file can take both flexibility and compatibility into account, and the content of dump file should be detailed enough to meet the needs of both application developers and lower-level developers. Based on above considerations, I think using JSON as its file format is an appropriate solution(But XML or binary format are still not excluded as candidates). Specifically, in earlier thoughts, I thought the format of the metaspace file could be as follows(pretty printed) https://gist.github.com/y1yang0/ab3034b6381b8a9d215602c89af4e9c3 Using the JSON format, we can flexibly add new fields without breaking compatibility. It is debatable as to which data to write. We can reach a consensus that third-party parsers(Metaspace Analyzer Tool) can at least reconstruct Java source code from the dump file. Based on this, we can write more useful information for low-level troubleshooting or debugging. (e.g. the init_state of InstanceKlass). In addition, we can even output the native code and associated information with regard to Method, third-party parser can reconstruct the human-readable assembly representation of the compiled method based on dump file. To some extent, we have implemented code cache dump by the way. For this reason, I'm not sure if the title of the RFC proposal should be called metaspace dump, maybe metadata dump? It looks more like a metadata-dump framework. Do you have any thoughts about metaspace/metadata dump? Looking forward to hearing your feedback, any comments are invaluable! Best regards, Yi Yang Analyzing the structure of generated classes sounds interesting, and could help with analyzing issues with bytecode instrumentation tools. For analyzing general metaspace OOMEs we are already covered quite well. Not perfect, but your proposal does intersect with existing tools a lot. To keep code complexity down, I'd rather avoid adding duplicate features. Cheers, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.walls at oracle.com Thu Jan 12 09:13:50 2023 From: kevin.walls at oracle.com (Kevin Walls) Date: Thu, 12 Jan 2023 09:13:50 +0000 Subject: Potential sensitive information leak through JVM crash logs In-Reply-To: <2d297b97-0fe1-2388-9ad2-23c5d1788225@syntevo.com> References: <2d297b97-0fe1-2388-9ad2-23c5d1788225@syntevo.com> Message-ID: Hi, 8266967: debug.cpp utility find() should print Java Object fields. This was providing tooling which brought product builds in line with debug builds for object printing. So what we now see in hs_err was previously limited to debug builds. (Your customers probably weren't running debug builds of course (and that's fine!), so the object details were previously hidden.) Escaping Strings in the printer seems worth considering anyway, as a Java String could contain control characters, and yes that will help those who want to process the file. We can think further if anything else needs doing. Thanks Kevin -----Original Message----- From: Alexandr Miloslavskiy Sent: 24 December 2022 13:15 To: hotspot-dev at openjdk.java.net Cc: kevinw at openjdk.org; Marc Strapetz Subject: Potential sensitive information leak through JVM crash logs Hello, For a quick understanding, consider the following potential hs_err_pid*.log file: ---------------------------------------- ... stack at sp + 2 slots: 0x00000000c0401098 is an oop: org.x.y.z {0x00000000c0401098} - klass: 'org/x/y/z' - ---- fields (total size 141 words): ... - 'x' 'Lorg/a/b/c;' @184 NULL (0) - 'myPasswordString' 'Ljava/lang/String;' @188 "My password: correct-horse-battery-staple"{0x00000000c0b01ef0} (c0b01ef0) - 'y' 'Ljava/lang/String;' @192 "foobar" ... stack at sp + 3 slots: 0x00007fb06effd7c0 is pointing into the stack for thread: 0x00007fb0680240f0 ... ---------------------------------------- Here, crash log accidentally exposes a sensitive bit of user's information (the password). In our product, when JVM crashes, we ask user to send a crash report. But users shouldn't be worried that said report may contain something really sensitive. For this reason, since we upgraded to JDK that has this feature, we decided to strip these object dumps from the crash log before sending it. So far we decided to strip all lines starting from `- ---- fields` until one of 1) `stack at sp + 3 slots` where `+ 3` is exactly 1 more than previously seen `stack at sp + 2 slots` 2) a line that starts with `R??=` where ?? is any two chars, to handle registers 3) next section in crash log such as 'Registers:' or '--------------- P R O C E S S ---------------'. It can be seen how it's not convenient and not very reliable to strip due to parsing issues. Especially when a String contains embedded \n, which prevents the easy solution to strip all lines beginning with ` - ` (see example crash log above). We propose the following possible solutions: 1) Add some unique marker to begin and end of each object dump, so that everything between the markers can be stripped. 2) Otherwise, ensure that Strings don't span to next line when there's an embedded \n. For your reference, a typical crash log can be seen in [1], where object dumps are seen in both sections 'Register to memory mapping:' 'Stack slot to memory mapping:' According to my research, the feature of dumping objects in crash logs was (accidentally?) introduced in commit: 5e557d86 by Kevin Walls, 2021-06-08 01:26:13 8266967: debug.cpp utility find() should print Java Object fields. [1] https://bugs.openjdk.org/browse/JDK-8284988 From ngasson at openjdk.org Thu Jan 12 09:32:26 2023 From: ngasson at openjdk.org (Nick Gasson) Date: Thu, 12 Jan 2023 09:32:26 GMT Subject: Integrated: 8298482: Implement ParallelGC NUMAStats for Linux In-Reply-To: References: Message-ID: On Mon, 12 Dec 2022 15:19:21 GMT, Nick Gasson wrote: > ParallelGC has a seemingly useful option -XX:+NUMAStats that prints detailed information in GC.heap_info about which NUMA node pages in the eden space are bound to. However as far as I can tell this only ever worked on Solaris and is not implemented on any of the systems we currently support. This patch implements it on Linux using the move_pages system call. > > The function os::get_page_info() and accompanying struct page_info was just a thin wrapper around the Solaris meminfo(2) syscall and was never ported to other systems so I've just removed it rather than try to emulate its interface. > > There's also a method MutableNUMASpace::LGRPSpace::scan_pages() which attempts to find pages on the wrong NUMA node and frees them so that they have another chance to be allocated on the correct node by the first-touching thread, but I think this has always been a no-op on non-Solaris so perhaps should also be removed. On Linux it shouldn't be necessary as you can bind pages to the desired node directly. > > I don't know what the performance of this option was like on Solaris but on Linux the move_pages call can be quite slow: I measured about 25ms/GB on my system. At the moment we call LGRPSpace::accumulate_statistics() twice per GC cycle: I removed the second call as it's likely to see a lot of uncommitted pages if the spaces were just resized. MutableNUMASpace::print_on() also calls accumulate_statistics() directly and since that's the only place this data is used, maybe we can drop the call from MutableNUMASpace::accumulate_statistics() as well? > > Example output: > > > PSYoungGen total 4290560K, used 835628K [0x00000006aac00000, 0x0000000800000000, 0x0000000800000000) > eden space 3096576K, 1% used [0x00000006aac00000,0x00000007176a9f48,0x0000000767c00000) > lgrp 0 space 1761280K, 2% used [0x00000006aac00000,0x00000006acfc4980,0x0000000716400000) > local/remote/unbiased/uncommitted: 1671168K/0K/0K/90112K, large/small pages: 0/440320 > lgrp 1 space 1335296K, 46% used [0x0000000716400000,0x000000073c2abb18,0x0000000767c00000) > local/remote/unbiased/uncommitted: 1335296K/0K/0K/0K, large/small pages: 0/333824 > from space 1193984K, 65% used [0x00000007b7200000,0x00000007e6b9c778,0x0000000800000000) > to space 1247232K, 0% used [0x0000000767c00000,0x0000000767c00000,0x00000007b3e00000) > > > After testing this with SPECjbb for a while I noticed some pages always end up bound to the wrong node. I think this is a regression caused by JDK-8283935 but I'll raise a separate ticket for that. This pull request has now been integrated. Changeset: 036c8084 Author: Nick Gasson URL: https://git.openjdk.org/jdk/commit/036c80844e30559bdced3587bb70b29ee38af498 Stats: 64 lines in 7 files changed: 10 ins; 30 del; 24 mod 8298482: Implement ParallelGC NUMAStats for Linux Reviewed-by: ayang, sjohanss, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/11635 From thomas.stuefe at gmail.com Thu Jan 12 09:55:22 2023 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 12 Jan 2023 10:55:22 +0100 Subject: RFC: regarding metaspace(metadata?) dump In-Reply-To: <5575ed15-6783-456c-ae42-703c440f84b5.qingfeng.yy@alibaba-inc.com> References: <5575ed15-6783-456c-ae42-703c440f84b5.qingfeng.yy@alibaba-inc.com> Message-ID: Hi Yi, On Thu, Jan 12, 2023 at 9:29 AM Yi Yang wrote: > Thanks Ioi and Thomas for your valuable thoughts! I list some pros about > metaspace dump. > > 1. Standardization. The format of metadata dump is standard and > well-formed. It could be seamlessly integrated with DevOps/Diagnose/APM > platforms, while SA is interactively and the output of jcmd is not > well-formed and parser-unfriendly, and its content is subject to change. > You can't expect DevOps platform to use SA/coredump/gdb conveniently and > automatically in production environment. > I'm not convinced that json solves the standardization problem. These tools are for hotspot devs mainly, so they expose implementation details that are frequently changing. That runs the risk of breakage, regardless of the format. Json will give you better parsing (at the expense of developer experience), but their content will change. Your renderer needs to make sense of the data to do something useful beyond printing the raw json soup. So the renderer can break if the implementation changes. But it is not maintained by us, in contrast to our jcmds, so we cannot easily fix it. We see these kinds of problems even with JFR, and that we maintain ourselves. If standardization is the goal we take seriously, we'd need to carefully choose the information we expose, limiting them to those that are stable. That limits the usefulness of the command. It also puts the onus of backward compatibility on us. Regression tests and all that. If we don't take standardization seriously, why do it at all? Why worsen the experience for hotspot devs to get machine-readable output? We could add json output as an option beside the normal human-readable output. I could see this to be useful. But it increases code complexity. It would also be good to have this consistently for all jcmds, or all that produce table-like output. > > 2. Functionality. MetaspaceDumpBeforeFullGC could generate a small dump > for further debugging, it works as well as heap dump. > Sounds useful. > > 3. JVM Metadata. Codecache dump, method counter, method data, they are > unexplored scopes, reconstruct human-readable representation of compiled > method. > > 4. Complexity. In my humble opinion, all of this stuff such as > by-chunktype/show-loaders/VM.classloader_stats/VM.classloader_hierarchy/etc > could be done in other place. VM is eligible to provides a standard and > rich raw metadata output, third-party parser and UI render display them in > their way instead of continuously adding new > filter/grouping/hierarcy/VM.method_counter features when we do want to know > them. Heap dump is a good example, it dumps all objects/symbols/etc to a > binary file, and third-party tools orchestrate them to > histogram/thread/classloader/domtree. > Heap dump is a good example of the limits of this approach, since the sheer size of data can make them cumbersome and expensive to get. There is a niche for tools that quickly tell you what you need, without a lot of fuss, runtime costs, and intermediate steps. And that help you along the way of analysis. One pro of doing rendering in hotspot instead of dumping the whole thing and letting tool providers figure it out is that the backend developers know their backend best. They write analysis tools for themselves (e.g. VM.metaspace was carefully designed to answer the common Metaspace OOMEs quickly). They also can get a quick turnaround. Of course, there is a limit somewhere, which is why we have JFR and JMC. Tool providers need to understand the backend in order to intelligently display internal status. Then, they need to agree with hotspot devs on the data to be provided, then need to render them in an intelligent way. E.g. if you were to provide a "waste" section equally useful as that one from VM.metaspace, we would need to expose a lot of internals to the tool provider. The interface would be broad and very brittle. > Basically, I know the content of metaspace dump file has overlap with some > existing tools such as SA/jcmd/coredump/gdb/HeapDump, as Thomas commented > inlinely, I don?t think metaspace dump can troubleshoot many problems that > it is the only solution. I think metadata dump is more about providing a > standardized and parser-friendly framework, so that users at all levels can > inspect JVM metadata information they care about. In addition, something > like M(etaspace)AT could orchestrate dump content with > filter/grouping/hierarchy options. > > > Also you mentioned that "Internally we implemented a metaspace dump that > generates human-readable text". Can you share how this tool was implemented? > > That's not surprising, it iterates CLD/Classes/etc and dumps basic > information about metaspace, a demo metaspace dump can be found at > https://gist.github.com/y1yang0/683d8a58dd946b3e9180682863df55ea > > In that case, it misses an important part of the picture that VM.metaspace provides (Fragmentation and dead-memory analysis). --- I am not opposed to adding json format output to jcmd, but not at the expense of the current human-readable reports. There are still a lot of questions are unanswered. Lets see what others think. A jcmd that dumps metadata could be useful as an addition to existing commands if we can keep the overlap small. Cheers, Thomas ------------------------------------------------------------------ > From:Thomas St?fe > Send Time:2023 Jan. 12 (Thu.) 15:06 > To:"YANG, Yi" > Cc:HotSpot Open Source Developers ; > hotspot-runtime-dev ; hotspot-dev < > hotspot-dev at openjdk.org> > Subject:Re: RFC: regarding metaspace(metadata?) dump > > Hi Yi, > > A lot of what you try to do already exists. For example, we also have > `VM.metaspace`. This is a quite powerful command to analyze > Metaspace-related issues, especially for fragmentation and other wastages. > Generally speaking, it is the tool you use to look at the underpinnings of > metaspace, the allocator, while tools like `VM.classloaders`, > `VM.classloader_stats` and `VM.classes` look at things "from above", e.g. > walk the CLDG. All these tools have already a bit of overlap. > > For analyzing OOMEs, you need several tools, since it can be caused by > multiple issues. E.g. tools that walk the CLDG don't see fragmentation, or > unclaimed metaspace for dead loaders. > > Please find more remarks inline. > > On Wed, Jan 11, 2023 at 1:56 PM Yi Yang > wrote: > Hi, > > Internally, we often receive feedback from users and ask for help on > metaspace-related issues, for example > 1. Users are eager to know which GroovyClassLoader loads which classes, > why they are not unloaded, > and why they are leading to Metaspace OOME. > > There are several tools to do this, for example: > > `VM.metaspace show-loaders show-classes` > `VM.classloaders show-classes` > > both show you loaded classes by loader, and the former also shows you > metaspace stats needed to understand OOMEs. None of these tools shows you > why loaders are kept alive, but for that you need heap- and > GC-root-analysis. This quickly enters the territory of Eclipse MAT and > similar tools, where having a text-based tool alone gets cumbersome. > > 2. They want to know the class structure of dynamically generated classes > in some scenarios such as > deserialization > > Interesting. This seems to be a very specific query; not sure how general > the need for this is. `VM.classes -verbose` shows a part of the story. > > 3. Finding memory leaking about duplicated classes > > Again, > > `VM.metaspace show-loaders show-classes` > `VM.classloaders show-classes` > > but also `VM.classes` and `VM.classloader_stats` are your friends here. > > > ... > Internally we implemented a metaspace dump that generates human-readable > text, it looks something like this: > > [Basic Information] > Dump Reason : JCMD > MaxMetaspaceSize : 18446744073709547520 B > CompressedClassSpaceSize : 1073741824 B > Class Space Used : 309992 B > Class Space Capacity : 395264 B > ... > [Class Loader Data] > ClassLoaderData : loader = 0x000000008024f928, loader_klass = > 0x0000000800010098, loader_klass_name = > sun/misc/Launcher$AppClassLoader, label = N/A > Class Used Chunks : > * Chunk : [0x0000000800060000, 0x0000000800060230, 0x0000000800060800) > NonClass Used Chunks : > * Chunk : [0x00007fd8379c1000, 0x00007fd8379c1350, 0x00007fd8379c2000) > Klasses : > Klass : 0x0000000800060028, name = Test, size = 520 B > ConstantPool : 0x00007fd8379c1050, size = 296 B > ... > > > `VM.metaspace` shows you the chunk composition of arenas if needed. > > E.g. : `VM.metaspace by-chunktype show-loaders` > > ``` > Usage per loader: > > > > 1: CLD 0x00007f72fc29b820: "app" instance of > jdk.internal.loader.ClassLoaders$AppClassLoader > > > Loaded classes: > > > > 1: de.stuefe.repros.MiscUtils$$Lambda$1/0x0000000801001448 > > 2: de.stuefe.repros.MiscUtils > > 3: de.stuefe.repros.Simple2 > > > > 4: de.stuefe.repros.Simple > > 5: de.stuefe.repros.SimpleBase > > 6: de.stuefe.repros.I2 > 7: de.stuefe.repros.I1 > -total-: 7 classes > Non-Class: > Usage by chunk level: > 4m chunks: (none) > 2m chunks: (none) > 1m chunks: (none) > 512k chunks: (none) > 256k chunks: (none) > 128k chunks: (none) > 64k chunks: (none) > 32k chunks: (none) > 16k chunks: (none) > 8k chunks: 1 chunk, 8,00 KB capacity, 8,00 KB (100%) > committed, 8,00 KB (100%) used, 0 bytes ( 0%) free, 0 bytes ( > 0%) waste > 4k chunks: 1 chunk, 4,00 KB capacity, 4,00 KB (100%) > committed, 256 bytes ( 6%) used, 3,75 KB ( 94%) free, 0 bytes ( > 0%) waste > 2k chunks: (none) > 1k chunks: (none) > -total-: 2 chunks, 12,00 KB capacity, 12,00 KB > (100%) committed, 8,25 KB ( 69%) used, 3,75 KB ( 31%) free, 0 > bytes ( 0%) waste > deallocated: 1 blocks with 24 bytes > > Class: > Usage by chunk level: > .... and so forth > ``` > > but for analyzing potential fragmentation issues (which have been rare > since JEP 387) the "Waste" section at the end of the printout is much more > helpful, e.g.: > > ``` > Waste (unused committed space):(percentages refer to total committed size > 384,00 KB): > Waste in chunks in use: 0 bytes ( 0%) > Free in chunks in use: 85,01 KB ( 22%) > In free chunks: 0 bytes ( 0%) > Deallocated from chunks in use: 928 bytes ( <1%) (3 blocks) > -total-: 85,91 KB ( 22%) > ``` > > It has been working effectively for several years and has helped many > users solve metaspace-related problems. > But a more user-friendly way is that JDK can inherently support this > capability. We hope that format of the metaspace > dump file can take both flexibility and compatibility into account, and > the content of dump file should be detailed > enough to meet the needs of both application developers and lower-level > developers. > > Based on above considerations, I think using JSON as its file format is an > appropriate solution(But XML or binary > format are still not excluded as candidates). Specifically, in earlier > thoughts, I thought the format of the metaspace > file could be as follows(pretty printed) > > https://gist.github.com/y1yang0/ab3034b6381b8a9d215602c89af4e9c3 > > Using the JSON format, we can flexibly add new fields without breaking > compatibility. It is debatable as to which data > to write. We can reach a consensus that third-party parsers(Metaspace > Analyzer Tool) can at least reconstruct Java > source code from the dump file. Based on this, we can write more useful > information for low-level troubleshooting > or debugging. (e.g. the init_state of InstanceKlass). > In addition, we can even output the native code and associated information > with regard to Method, third-party parser > can reconstruct the human-readable assembly representation of the compiled > method based on dump file. To some extent, > we have implemented code cache dump by the way. For this reason, I'm not > sure if the title of the RFC proposal should > be called metaspace dump, maybe metadata dump? It looks more like a > metadata-dump framework. > > Do you have any thoughts about metaspace/metadata dump? Looking forward to > hearing your feedback, any comments are invaluable! > > Best regards, > Yi Yang > > > Analyzing the structure of generated classes sounds interesting, and could > help with analyzing issues with bytecode instrumentation tools. > > For analyzing general metaspace OOMEs we are already covered quite well. > Not perfect, but your proposal does intersect with existing tools a lot. To > keep code complexity down, I'd rather avoid adding duplicate features. > > Cheers, Thomas > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Thu Jan 12 09:55:22 2023 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 12 Jan 2023 10:55:22 +0100 Subject: RFC: regarding metaspace(metadata?) dump In-Reply-To: <5575ed15-6783-456c-ae42-703c440f84b5.qingfeng.yy@alibaba-inc.com> References: <5575ed15-6783-456c-ae42-703c440f84b5.qingfeng.yy@alibaba-inc.com> Message-ID: Hi Yi, On Thu, Jan 12, 2023 at 9:29 AM Yi Yang wrote: > Thanks Ioi and Thomas for your valuable thoughts! I list some pros about > metaspace dump. > > 1. Standardization. The format of metadata dump is standard and > well-formed. It could be seamlessly integrated with DevOps/Diagnose/APM > platforms, while SA is interactively and the output of jcmd is not > well-formed and parser-unfriendly, and its content is subject to change. > You can't expect DevOps platform to use SA/coredump/gdb conveniently and > automatically in production environment. > I'm not convinced that json solves the standardization problem. These tools are for hotspot devs mainly, so they expose implementation details that are frequently changing. That runs the risk of breakage, regardless of the format. Json will give you better parsing (at the expense of developer experience), but their content will change. Your renderer needs to make sense of the data to do something useful beyond printing the raw json soup. So the renderer can break if the implementation changes. But it is not maintained by us, in contrast to our jcmds, so we cannot easily fix it. We see these kinds of problems even with JFR, and that we maintain ourselves. If standardization is the goal we take seriously, we'd need to carefully choose the information we expose, limiting them to those that are stable. That limits the usefulness of the command. It also puts the onus of backward compatibility on us. Regression tests and all that. If we don't take standardization seriously, why do it at all? Why worsen the experience for hotspot devs to get machine-readable output? We could add json output as an option beside the normal human-readable output. I could see this to be useful. But it increases code complexity. It would also be good to have this consistently for all jcmds, or all that produce table-like output. > > 2. Functionality. MetaspaceDumpBeforeFullGC could generate a small dump > for further debugging, it works as well as heap dump. > Sounds useful. > > 3. JVM Metadata. Codecache dump, method counter, method data, they are > unexplored scopes, reconstruct human-readable representation of compiled > method. > > 4. Complexity. In my humble opinion, all of this stuff such as > by-chunktype/show-loaders/VM.classloader_stats/VM.classloader_hierarchy/etc > could be done in other place. VM is eligible to provides a standard and > rich raw metadata output, third-party parser and UI render display them in > their way instead of continuously adding new > filter/grouping/hierarcy/VM.method_counter features when we do want to know > them. Heap dump is a good example, it dumps all objects/symbols/etc to a > binary file, and third-party tools orchestrate them to > histogram/thread/classloader/domtree. > Heap dump is a good example of the limits of this approach, since the sheer size of data can make them cumbersome and expensive to get. There is a niche for tools that quickly tell you what you need, without a lot of fuss, runtime costs, and intermediate steps. And that help you along the way of analysis. One pro of doing rendering in hotspot instead of dumping the whole thing and letting tool providers figure it out is that the backend developers know their backend best. They write analysis tools for themselves (e.g. VM.metaspace was carefully designed to answer the common Metaspace OOMEs quickly). They also can get a quick turnaround. Of course, there is a limit somewhere, which is why we have JFR and JMC. Tool providers need to understand the backend in order to intelligently display internal status. Then, they need to agree with hotspot devs on the data to be provided, then need to render them in an intelligent way. E.g. if you were to provide a "waste" section equally useful as that one from VM.metaspace, we would need to expose a lot of internals to the tool provider. The interface would be broad and very brittle. > Basically, I know the content of metaspace dump file has overlap with some > existing tools such as SA/jcmd/coredump/gdb/HeapDump, as Thomas commented > inlinely, I don?t think metaspace dump can troubleshoot many problems that > it is the only solution. I think metadata dump is more about providing a > standardized and parser-friendly framework, so that users at all levels can > inspect JVM metadata information they care about. In addition, something > like M(etaspace)AT could orchestrate dump content with > filter/grouping/hierarchy options. > > > Also you mentioned that "Internally we implemented a metaspace dump that > generates human-readable text". Can you share how this tool was implemented? > > That's not surprising, it iterates CLD/Classes/etc and dumps basic > information about metaspace, a demo metaspace dump can be found at > https://gist.github.com/y1yang0/683d8a58dd946b3e9180682863df55ea > > In that case, it misses an important part of the picture that VM.metaspace provides (Fragmentation and dead-memory analysis). --- I am not opposed to adding json format output to jcmd, but not at the expense of the current human-readable reports. There are still a lot of questions are unanswered. Lets see what others think. A jcmd that dumps metadata could be useful as an addition to existing commands if we can keep the overlap small. Cheers, Thomas ------------------------------------------------------------------ > From:Thomas St?fe > Send Time:2023 Jan. 12 (Thu.) 15:06 > To:"YANG, Yi" > Cc:HotSpot Open Source Developers ; > hotspot-runtime-dev ; hotspot-dev < > hotspot-dev at openjdk.org> > Subject:Re: RFC: regarding metaspace(metadata?) dump > > Hi Yi, > > A lot of what you try to do already exists. For example, we also have > `VM.metaspace`. This is a quite powerful command to analyze > Metaspace-related issues, especially for fragmentation and other wastages. > Generally speaking, it is the tool you use to look at the underpinnings of > metaspace, the allocator, while tools like `VM.classloaders`, > `VM.classloader_stats` and `VM.classes` look at things "from above", e.g. > walk the CLDG. All these tools have already a bit of overlap. > > For analyzing OOMEs, you need several tools, since it can be caused by > multiple issues. E.g. tools that walk the CLDG don't see fragmentation, or > unclaimed metaspace for dead loaders. > > Please find more remarks inline. > > On Wed, Jan 11, 2023 at 1:56 PM Yi Yang > wrote: > Hi, > > Internally, we often receive feedback from users and ask for help on > metaspace-related issues, for example > 1. Users are eager to know which GroovyClassLoader loads which classes, > why they are not unloaded, > and why they are leading to Metaspace OOME. > > There are several tools to do this, for example: > > `VM.metaspace show-loaders show-classes` > `VM.classloaders show-classes` > > both show you loaded classes by loader, and the former also shows you > metaspace stats needed to understand OOMEs. None of these tools shows you > why loaders are kept alive, but for that you need heap- and > GC-root-analysis. This quickly enters the territory of Eclipse MAT and > similar tools, where having a text-based tool alone gets cumbersome. > > 2. They want to know the class structure of dynamically generated classes > in some scenarios such as > deserialization > > Interesting. This seems to be a very specific query; not sure how general > the need for this is. `VM.classes -verbose` shows a part of the story. > > 3. Finding memory leaking about duplicated classes > > Again, > > `VM.metaspace show-loaders show-classes` > `VM.classloaders show-classes` > > but also `VM.classes` and `VM.classloader_stats` are your friends here. > > > ... > Internally we implemented a metaspace dump that generates human-readable > text, it looks something like this: > > [Basic Information] > Dump Reason : JCMD > MaxMetaspaceSize : 18446744073709547520 B > CompressedClassSpaceSize : 1073741824 B > Class Space Used : 309992 B > Class Space Capacity : 395264 B > ... > [Class Loader Data] > ClassLoaderData : loader = 0x000000008024f928, loader_klass = > 0x0000000800010098, loader_klass_name = > sun/misc/Launcher$AppClassLoader, label = N/A > Class Used Chunks : > * Chunk : [0x0000000800060000, 0x0000000800060230, 0x0000000800060800) > NonClass Used Chunks : > * Chunk : [0x00007fd8379c1000, 0x00007fd8379c1350, 0x00007fd8379c2000) > Klasses : > Klass : 0x0000000800060028, name = Test, size = 520 B > ConstantPool : 0x00007fd8379c1050, size = 296 B > ... > > > `VM.metaspace` shows you the chunk composition of arenas if needed. > > E.g. : `VM.metaspace by-chunktype show-loaders` > > ``` > Usage per loader: > > > > 1: CLD 0x00007f72fc29b820: "app" instance of > jdk.internal.loader.ClassLoaders$AppClassLoader > > > Loaded classes: > > > > 1: de.stuefe.repros.MiscUtils$$Lambda$1/0x0000000801001448 > > 2: de.stuefe.repros.MiscUtils > > 3: de.stuefe.repros.Simple2 > > > > 4: de.stuefe.repros.Simple > > 5: de.stuefe.repros.SimpleBase > > 6: de.stuefe.repros.I2 > 7: de.stuefe.repros.I1 > -total-: 7 classes > Non-Class: > Usage by chunk level: > 4m chunks: (none) > 2m chunks: (none) > 1m chunks: (none) > 512k chunks: (none) > 256k chunks: (none) > 128k chunks: (none) > 64k chunks: (none) > 32k chunks: (none) > 16k chunks: (none) > 8k chunks: 1 chunk, 8,00 KB capacity, 8,00 KB (100%) > committed, 8,00 KB (100%) used, 0 bytes ( 0%) free, 0 bytes ( > 0%) waste > 4k chunks: 1 chunk, 4,00 KB capacity, 4,00 KB (100%) > committed, 256 bytes ( 6%) used, 3,75 KB ( 94%) free, 0 bytes ( > 0%) waste > 2k chunks: (none) > 1k chunks: (none) > -total-: 2 chunks, 12,00 KB capacity, 12,00 KB > (100%) committed, 8,25 KB ( 69%) used, 3,75 KB ( 31%) free, 0 > bytes ( 0%) waste > deallocated: 1 blocks with 24 bytes > > Class: > Usage by chunk level: > .... and so forth > ``` > > but for analyzing potential fragmentation issues (which have been rare > since JEP 387) the "Waste" section at the end of the printout is much more > helpful, e.g.: > > ``` > Waste (unused committed space):(percentages refer to total committed size > 384,00 KB): > Waste in chunks in use: 0 bytes ( 0%) > Free in chunks in use: 85,01 KB ( 22%) > In free chunks: 0 bytes ( 0%) > Deallocated from chunks in use: 928 bytes ( <1%) (3 blocks) > -total-: 85,91 KB ( 22%) > ``` > > It has been working effectively for several years and has helped many > users solve metaspace-related problems. > But a more user-friendly way is that JDK can inherently support this > capability. We hope that format of the metaspace > dump file can take both flexibility and compatibility into account, and > the content of dump file should be detailed > enough to meet the needs of both application developers and lower-level > developers. > > Based on above considerations, I think using JSON as its file format is an > appropriate solution(But XML or binary > format are still not excluded as candidates). Specifically, in earlier > thoughts, I thought the format of the metaspace > file could be as follows(pretty printed) > > https://gist.github.com/y1yang0/ab3034b6381b8a9d215602c89af4e9c3 > > Using the JSON format, we can flexibly add new fields without breaking > compatibility. It is debatable as to which data > to write. We can reach a consensus that third-party parsers(Metaspace > Analyzer Tool) can at least reconstruct Java > source code from the dump file. Based on this, we can write more useful > information for low-level troubleshooting > or debugging. (e.g. the init_state of InstanceKlass). > In addition, we can even output the native code and associated information > with regard to Method, third-party parser > can reconstruct the human-readable assembly representation of the compiled > method based on dump file. To some extent, > we have implemented code cache dump by the way. For this reason, I'm not > sure if the title of the RFC proposal should > be called metaspace dump, maybe metadata dump? It looks more like a > metadata-dump framework. > > Do you have any thoughts about metaspace/metadata dump? Looking forward to > hearing your feedback, any comments are invaluable! > > Best regards, > Yi Yang > > > Analyzing the structure of generated classes sounds interesting, and could > help with analyzing issues with bytecode instrumentation tools. > > For analyzing general metaspace OOMEs we are already covered quite well. > Not perfect, but your proposal does intersect with existing tools a lot. To > keep code complexity down, I'd rather avoid adding duplicate features. > > Cheers, Thomas > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Thu Jan 12 10:09:20 2023 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 12 Jan 2023 11:09:20 +0100 Subject: Potential sensitive information leak through JVM crash logs In-Reply-To: References: <2d297b97-0fe1-2388-9ad2-23c5d1788225@syntevo.com> Message-ID: Hi, A simple way to deal with this could be to mark error reporting steps that potentially display security-sensitive information. See VM::report, STEP macro. These steps could print a little prefix/suffix for strippers to do their work. Cheers, Thomas On Thu, Jan 12, 2023 at 10:13 AM Kevin Walls wrote: > Hi, > > 8266967: debug.cpp utility find() should print Java Object fields. > > This was providing tooling which brought product builds in line with debug > builds for object printing. So what we now see in hs_err was previously > limited to debug builds. (Your customers probably weren't running debug > builds of course (and that's fine!), so the object details were previously > hidden.) > > Escaping Strings in the printer seems worth considering anyway, as a Java > String could contain control characters, and yes that will help those who > want to process the file. We can think further if anything else needs > doing. > > Thanks > Kevin > > > -----Original Message----- > From: Alexandr Miloslavskiy > Sent: 24 December 2022 13:15 > To: hotspot-dev at openjdk.java.net > Cc: kevinw at openjdk.org; Marc Strapetz > Subject: Potential sensitive information leak through JVM crash logs > > Hello, > > For a quick understanding, consider the following potential > hs_err_pid*.log file: > > ---------------------------------------- > ... > stack at sp + 2 slots: 0x00000000c0401098 is an oop: org.x.y.z > {0x00000000c0401098} - klass: 'org/x/y/z' > - ---- fields (total size 141 words): > ... > - 'x' 'Lorg/a/b/c;' @184 NULL (0) > - 'myPasswordString' 'Ljava/lang/String;' @188 "My password: > correct-horse-battery-staple"{0x00000000c0b01ef0} (c0b01ef0) > - 'y' 'Ljava/lang/String;' @192 "foobar" > ... > stack at sp + 3 slots: 0x00007fb06effd7c0 is pointing into the stack for > thread: 0x00007fb0680240f0 > ... > ---------------------------------------- > > Here, crash log accidentally exposes a sensitive bit of user's information > (the password). > > In our product, when JVM crashes, we ask user to send a crash report. > But users shouldn't be worried that said report may contain something > really sensitive. > > For this reason, since we upgraded to JDK that has this feature, we > decided to strip these object dumps from the crash log before sending it. > > So far we decided to strip all lines starting from `- ---- fields` until > one of > 1) `stack at sp + 3 slots` where `+ 3` is exactly 1 more than > previously seen `stack at sp + 2 slots` > 2) a line that starts with `R??=` where ?? is any two chars, > to handle registers > 3) next section in crash log such as > 'Registers:' or > '--------------- P R O C E S S ---------------'. > > It can be seen how it's not convenient and not very reliable to strip due > to parsing issues. Especially when a String contains embedded \n, which > prevents the easy solution to strip all lines beginning with ` - ` (see > example crash log above). > > We propose the following possible solutions: > 1) Add some unique marker to begin and end of each object dump, so that > everything between the markers can be stripped. > 2) Otherwise, ensure that Strings don't span to next line when there's an > embedded \n. > > For your reference, a typical crash log can be seen in [1], where object > dumps are seen in both sections 'Register to memory mapping:' > 'Stack slot to memory mapping:' > > According to my research, the feature of dumping objects in crash logs was > (accidentally?) introduced in commit: > 5e557d86 by Kevin Walls, 2021-06-08 01:26:13 > 8266967: debug.cpp utility find() should print Java Object fields. > > [1] https://bugs.openjdk.org/browse/JDK-8284988 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xlinzheng at openjdk.org Thu Jan 12 10:18:20 2023 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Thu, 12 Jan 2023 10:18:20 GMT Subject: RFR: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions In-Reply-To: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> References: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> Message-ID: On Thu, 12 Jan 2023 02:52:17 GMT, Sergey Kuksenko wrote: > 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions Hi Sergey, Would you mind some RV part taking a ride? Thank you! (no need to add a contributor for this) By the way, seems GHA says `assert(assm->inst_mark() == NULL, "overlapping instructions");` may need some changes; it seems that x86 and aarch64 have an `InstructionMark` in `post_call_nop()` but ppc and riscv do not always have an `InstructionMark` in `post_call_nop()`. [rv.txt](https://github.com/openjdk/jdk/files/10400394/rv.txt) Thanks, Xiaolin ------------- PR: https://git.openjdk.org/jdk/pull/11958 From alanb at openjdk.org Thu Jan 12 10:28:29 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 12 Jan 2023 10:28:29 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v9] In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 00:15:45 GMT, Brian Burkhalter wrote: >> Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299684: Remove spurious file The test looks much better now but I think can be improved a bit more. test/jdk/java/nio/jni/NewDirectByteBuffer.java line 28: > 26: import org.junit.jupiter.api.Assertions; > 27: import org.junit.jupiter.params.ParameterizedTest; > 28: import org.junit.jupiter.params.provider.ValueSource; Up to you but in other tests, we import static org.junit.jupiter.api.Assertions.* so that the asserts are simple assertXXX calls. test/jdk/java/nio/jni/NewDirectByteBuffer.java line 36: > 34: * IllegalArgumentException if the capacity is negative or greater than > 35: * Integer::MAX_VALUE > 36: * @requires (sun.arch.data.model == "64" & os.maxMemory >= 8g) The @summary should probably be updated to say that it's a unit test for JNI NewDirectBufferBuffer. test/jdk/java/nio/jni/NewDirectByteBuffer.java line 53: > 51: "Buffer::position returned unexpected value"); > 52: Assertions.assertEquals(capacity, buf.limit(), > 53: "Buffer::limit returned unexpected value"); For completeness, I think checkBuffer should also set/get some elements. test/jdk/java/nio/jni/NewDirectByteBuffer.java line 77: > 75: } > 76: } catch (OutOfMemoryError ignored) { > 77: // Ignore the error If I read this correctly, this frees the backing memory before it tests the buffer methods. This may be safe because checkBuffer doesn't access the buffer contents but if the checks are expanded then this will crash. I think you should be able to reduce this method down to this: ByteBuffer buf = newDirectByteBuffer(capacity); try { checkBuffer(buf, capacity); } finally { freeDirectByteBufferMemory(buf); } test/jdk/java/nio/jni/NewDirectByteBuffer.java line 83: > 81: @ParameterizedTest > 82: @ValueSource(longs = {Long.MIN_VALUE, (long)Integer.MIN_VALUE - 1L, -1L, > 83: (long)Integer.MAX_VALUE + 1L, 3_000_000_000L, 5_000_000_000L, Just curious why 3_000_000_000L and 5_000_000_000L are in the values to test. test/jdk/java/nio/jni/NewDirectByteBuffer.java line 93: > 91: } > 92: }); > 93: } catch (OutOfMemoryError ignored) { Why is there is catch of OOME here? ------------- PR: https://git.openjdk.org/jdk/pull/11873 From fyang at openjdk.org Thu Jan 12 11:22:17 2023 From: fyang at openjdk.org (Fei Yang) Date: Thu, 12 Jan 2023 11:22:17 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v2] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 09:22:03 GMT, Fredrik Bredberg wrote: >> Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. >> Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. >> Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > Updated some copyright dates. Also verified on linux-riscv64 HiFive Unmatched board running hotspot_loom & jdk_loom jtreg tests with extra VM options: -XX:+VerifyStack -XX:+VerifyContinuations. ------------- PR: https://git.openjdk.org/jdk/pull/11902 From jwaters at openjdk.org Thu Jan 12 11:23:12 2023 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 12 Jan 2023 11:23:12 GMT Subject: RFR: 8250269: Replace ATTRIBUTE_ALIGNED with alignas [v12] In-Reply-To: <8b40cSZqtThn1MFimoqnaLlj__tXyyMMMYupBKiT2fc=.8d7e248e-c4ad-4387-be18-630ed280f83c@github.com> References: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com> <8b40cSZqtThn1MFimoqnaLlj__tXyyMMMYupBKiT2fc=.8d7e248e-c4ad-4387-be18-630ed280f83c@github.com> Message-ID: On Wed, 11 Jan 2023 12:06:47 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 11 additional commits since the last revision: > > - 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 > - ATTRIBUTE_ALIGNED(16) > - Merge branch 'openjdk:master' into alignas > - Merge branch 'openjdk:master' into alignas > - Merge branch 'openjdk:master' into alignas > - ... and 1 more: https://git.openjdk.org/jdk/compare/a5c2f4b5...8112c286 Pinging mailing list for further guidance on what to do with the commit, I think it may have been buried by more recent Pulls ------------- PR: https://git.openjdk.org/jdk/pull/11431 From aboldtch at openjdk.org Thu Jan 12 12:41:29 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 12 Jan 2023 12:41:29 GMT Subject: Integrated: 8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly In-Reply-To: References: Message-ID: On Tue, 20 Dec 2022 16:30:47 GMT, Axel Boldt-Christmas wrote: > In a similar vain to [JDK-8299089](https://bugs.openjdk.org/browse/JDK-8299089) there are different semantics for OopStorage and thread local oops. UnifiedOopRef in the jfr leakprofiler must be able to distinguish these and treat them appropriately. > > Testing: Running test at the moment. Has been running on the generational branch of ZGC for over three months. Not many tests exercise the leakprofiler. x86_32 has mostly been tested with GHA. > > Note: The accessBackend changes are only there to facilitate comparing OopLoadProxy objects directly with nullptr instead of creating and comparing with an `oop()` / `oop(NULL)`. Can be backed out of this PR and put in a different RFE instead. This pull request has now been integrated. Changeset: 89d3f3d9 Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/89d3f3d96b220c249e7b273a09cc3897428f8814 Stats: 110 lines in 4 files changed: 86 ins; 6 del; 18 mod 8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly Reviewed-by: eosterlund, mgronlun ------------- PR: https://git.openjdk.org/jdk/pull/11741 From lkorinth at openjdk.org Thu Jan 12 12:51:43 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 12 Jan 2023 12:51:43 GMT Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable [v5] In-Reply-To: References: Message-ID: > I am replacing the old hash table with ResourceHashtable. In the process I am also removing the redundant `_length` field. By removing the `_length` field, a lot of asserts can be removed as the length will trivially match the length of the underlying table. > > I would like to have feedback on the addition of `unlink_destruct(Function&& should_remove)`. I added it because I prefer to use a functor object that can be used by lambdas instead of an iterator object. However, I did add code to "destruct" resource objects when they are removed instead of just letting them be to reflect that we use `delete` on c-heap objects. Maybe I should remove this "improvement" and then maybe implement the function by calling the existing unlink? Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: add mem_size() method to resourceHash.hpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11675/files - new: https://git.openjdk.org/jdk/pull/11675/files/32976d38..f3d9145e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11675&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11675&range=03-04 Stats: 13 lines in 4 files changed: 7 ins; 3 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11675.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11675/head:pull/11675 PR: https://git.openjdk.org/jdk/pull/11675 From lkorinth at openjdk.org Thu Jan 12 12:56:51 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 12 Jan 2023 12:56:51 GMT Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable [v6] In-Reply-To: References: Message-ID: > I am replacing the old hash table with ResourceHashtable. In the process I am also removing the redundant `_length` field. By removing the `_length` field, a lot of asserts can be removed as the length will trivially match the length of the underlying table. > > I would like to have feedback on the addition of `unlink_destruct(Function&& should_remove)`. I added it because I prefer to use a functor object that can be used by lambdas instead of an iterator object. However, I did add code to "destruct" resource objects when they are removed instead of just letting them be to reflect that we use `delete` on c-heap objects. Maybe I should remove this "improvement" and then maybe implement the function by calling the existing unlink? Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: revert copyright year after changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11675/files - new: https://git.openjdk.org/jdk/pull/11675/files/f3d9145e..a58ef05d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11675&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11675&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11675.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11675/head:pull/11675 PR: https://git.openjdk.org/jdk/pull/11675 From lkorinth at openjdk.org Thu Jan 12 12:56:52 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 12 Jan 2023 12:56:52 GMT Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable [v4] In-Reply-To: <51wTA2TBRihuiQnFfY2JPQLJErKrvsFhrrpFFH8he34=.ab38ab01-761a-44c2-bbf7-ac5432d23a61@github.com> References: <51wTA2TBRihuiQnFfY2JPQLJErKrvsFhrrpFFH8he34=.ab38ab01-761a-44c2-bbf7-ac5432d23a61@github.com> Message-ID: On Sat, 24 Dec 2022 04:58:02 GMT, Ioi Lam wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> can not use contains in combination with add without a lock > > src/hotspot/share/gc/g1/g1CodeCacheRemSet.cpp line 44: > >> 42: return sizeof(*this) + >> 43: _table.table_size() * sizeof(Table::Node*) + >> 44: _table.number_of_entries() * sizeof(Table::Node); > > Instead of exporting Table::Node and the details of the implementation, maybe ResourceHashtable should have a function that returns its footprint? I don't know what name we usually use for that. Maybe `ResourceHashtable::mem_size()` to follow the example of `G1CodeRootSetTable::mem_size()`? I am back after vacation, I added a `ResourceHashtable::mem_size()`, does it look okay? ------------- PR: https://git.openjdk.org/jdk/pull/11675 From redestad at openjdk.org Thu Jan 12 13:43:22 2023 From: redestad at openjdk.org (Claes Redestad) Date: Thu, 12 Jan 2023 13:43:22 GMT Subject: RFR: 8299978: Remove MethodHandleNatives.getMembers In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 15:13:14 GMT, Claes Redestad wrote: > This removes `MethodHandleNatives.getMembers`, which has fallen into disuse. Thanks for reviewing! ------------- PR: https://git.openjdk.org/jdk/pull/11949 From redestad at openjdk.org Thu Jan 12 13:43:23 2023 From: redestad at openjdk.org (Claes Redestad) Date: Thu, 12 Jan 2023 13:43:23 GMT Subject: Integrated: 8299978: Remove MethodHandleNatives.getMembers In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 15:13:14 GMT, Claes Redestad wrote: > This removes `MethodHandleNatives.getMembers`, which has fallen into disuse. This pull request has now been integrated. Changeset: 48c8fb39 Author: Claes Redestad URL: https://git.openjdk.org/jdk/commit/48c8fb39a74f07335d366a0a3052e3c00634d869 Stats: 172 lines in 4 files changed: 0 ins; 171 del; 1 mod 8299978: Remove MethodHandleNatives.getMembers Reviewed-by: jvernee, mchung ------------- PR: https://git.openjdk.org/jdk/pull/11949 From rcastanedalo at openjdk.org Thu Jan 12 14:07:22 2023 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Thu, 12 Jan 2023 14:07:22 GMT Subject: RFR: 8299032: Interface IN_NATIVE oop stores for C2 In-Reply-To: <61HZ-hCw_ZoDZCtsDLsz-tfPE6S7Ox_1nXApLQnZ1SU=.60c813cf-a5d8-4a3c-a2a1-86d7af05d042@github.com> References: <61HZ-hCw_ZoDZCtsDLsz-tfPE6S7Ox_1nXApLQnZ1SU=.60c813cf-a5d8-4a3c-a2a1-86d7af05d042@github.com> Message-ID: On Fri, 23 Dec 2022 13:54:44 GMT, Erik ?sterlund wrote: > Loom added the first IN_NATIVE oop store to C2 code, when switching the current virtual thread of a platform thread. Instead of interfacing this properly, a raw store was used. But a future GC algorithm, such as generational ZGC, might not work well with raw stores. We should add support to the access API for this. Looks like Shenandoah was already missing something here as they do concurrent root processing requiring SATB barriers on IN_NATIVE oop stores. It is not in the scope of this PR to fix the Shenandoah bug - someone working on Shenandoah should do this. This PR merely adds an interface such that GCs that need to do something different here, can do that. Serial, Parallel and G1 don't need to do anything for IN_NATIVE stores as they do STW root processing. ZGC doesn't (yet) have store barriers at all, and hence doesn't need to do anything special either. Looks good! Do not forget to update the copyright headers. I checked the coverage of `inline_native_setCurrentThread()` in tiers 1-3, and this function is only exercised by the serviceability and a few long-running, CTW-like test cases. We should probably extend `test/hotspot/jtreg/compiler/intrinsics` with specific tests for Loom intrinsics (in a separate RFE). ------------- Marked as reviewed by rcastanedalo (Reviewer). PR: https://git.openjdk.org/jdk/pull/11777 From lucy at openjdk.org Thu Jan 12 14:44:35 2023 From: lucy at openjdk.org (Lutz Schmidt) Date: Thu, 12 Jan 2023 14:44:35 GMT Subject: RFR: 8299817: [s390] AES-CTR mode intrinsic fails with multiple short update() calls Message-ID: This PR addresses an issue in the AES-CTR mode intrinsic on s390. When a message is ciphered in multiple, small (< 16 bytes) segments, the result is incorrect. This is not just a band-aid fix. The issue was taken as a chance to restructure the code. though still complicated, It is now easier to read and (hopefully) understand. Except for the new jetreg test, the changes are purely s390. There are no side effects on other platforms. Issue-specific tests pass. Other tests are in progress. I will update this PR once they are complete. **Reviews and comments are very much appreciated.** @backwaterred could you please run some "official" s390 tests? Thanks. ------------- Commit messages: - 8299817: [s390] AES-CTR mode intrinsic fails with multiple short update() calls Changes: https://git.openjdk.org/jdk/pull/11967/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11967&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299817 Stats: 714 lines in 5 files changed: 513 ins; 61 del; 140 mod Patch: https://git.openjdk.org/jdk/pull/11967.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11967/head:pull/11967 PR: https://git.openjdk.org/jdk/pull/11967 From eosterlund at openjdk.org Thu Jan 12 15:31:31 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 12 Jan 2023 15:31:31 GMT Subject: RFR: 8299032: Interface IN_NATIVE oop stores for C2 In-Reply-To: References: <61HZ-hCw_ZoDZCtsDLsz-tfPE6S7Ox_1nXApLQnZ1SU=.60c813cf-a5d8-4a3c-a2a1-86d7af05d042@github.com> Message-ID: On Thu, 12 Jan 2023 14:04:35 GMT, Roberto Casta?eda Lozano wrote: >> Loom added the first IN_NATIVE oop store to C2 code, when switching the current virtual thread of a platform thread. Instead of interfacing this properly, a raw store was used. But a future GC algorithm, such as generational ZGC, might not work well with raw stores. We should add support to the access API for this. Looks like Shenandoah was already missing something here as they do concurrent root processing requiring SATB barriers on IN_NATIVE oop stores. It is not in the scope of this PR to fix the Shenandoah bug - someone working on Shenandoah should do this. This PR merely adds an interface such that GCs that need to do something different here, can do that. Serial, Parallel and G1 don't need to do anything for IN_NATIVE stores as they do STW root processing. ZGC doesn't (yet) have store barriers at all, and hence doesn't need to do anything special either. > > Looks good! Do not forget to update the copyright headers. > > I checked the coverage of `inline_native_setCurrentThread()` in tiers 1-3, and this function is only exercised by the serviceability and a few long-running, CTW-like test cases. We should probably extend `test/hotspot/jtreg/compiler/intrinsics` with specific tests for Loom intrinsics (in a separate RFE). Thanks for the review, @robcasloz! ------------- PR: https://git.openjdk.org/jdk/pull/11777 From ayang at openjdk.org Thu Jan 12 16:27:58 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 12 Jan 2023 16:27:58 GMT Subject: RFR: 8300054: Use static_assert in basic_types_init Message-ID: Simple change to use `static_assert` when applicable inside a function. ------------- Commit messages: - static-assert Changes: https://git.openjdk.org/jdk/pull/11971/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11971&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300054 Stats: 31 lines in 1 file changed: 0 ins; 0 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/11971.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11971/head:pull/11971 PR: https://git.openjdk.org/jdk/pull/11971 From coleenp at openjdk.org Thu Jan 12 16:37:24 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 12 Jan 2023 16:37:24 GMT Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable [v6] In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 12:56:51 GMT, Leo Korinth wrote: >> I am replacing the old hash table with ResourceHashtable. In the process I am also removing the redundant `_length` field. By removing the `_length` field, a lot of asserts can be removed as the length will trivially match the length of the underlying table. >> >> I would like to have feedback on the addition of `unlink_destruct(Function&& should_remove)`. I added it because I prefer to use a functor object that can be used by lambdas instead of an iterator object. However, I did add code to "destruct" resource objects when they are removed instead of just letting them be to reflect that we use `delete` on c-heap objects. Maybe I should remove this "improvement" and then maybe implement the function by calling the existing unlink? > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > revert copyright year after changes src/hotspot/share/utilities/resourceHash.hpp line 302: > 300: table_size() * sizeof(Node*) + > 301: number_of_entries() * sizeof(Node); > 302: } Thank you Leo and Ioi. This was a good suggested change. ------------- PR: https://git.openjdk.org/jdk/pull/11675 From stefank at openjdk.org Thu Jan 12 16:42:20 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 12 Jan 2023 16:42:20 GMT Subject: RFR: 8300054: Use static_assert in basic_types_init In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 16:17:49 GMT, Albert Mingkun Yang wrote: > Simple change to use `static_assert` when applicable inside a function. Looks good. One nit: src/hotspot/share/utilities/globalDefinitions.cpp line 162: > 160: static_assert((size_t)HeapWordSize >= sizeof(juint), > 161: "HeapWord should be at least as large as juint"); > 162: static_assert(sizeof(NULL) == sizeof(char*), "NULL must be same size as pointer"); Maybe fix alignment here. ------------- Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.org/jdk/pull/11971 From stuefe at openjdk.org Thu Jan 12 16:55:35 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 12 Jan 2023 16:55:35 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v4] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 14:49:59 GMT, Thomas Stuefe wrote: >> Justin King has updated the pull request incrementally with one additional commit since the last revision: >> >> Initialize memory to zero in zGranuleMap >> >> Signed-off-by: Justin King > > Curious, I always thought we do ArrayAllocator - using mmap for larger allocations - to prevent memory retention for libc variants whose allocators are "grabby", i.e. which don't promptly return memory to the OS on free(). E.g. because they only use sbrk (Solaris, AIX), or are just cautious about returning memory (glibc). > > Glibc's retention problem is only relevant for fine-grained allocations, so for glibc this is probably fine. This leaves at least AIX as a potential problem. @backwaterred, does the AIX libc malloc() still exclusively use the data segment ? Does free'd memory still stick to the process? > > (While writing this, I remember that we at SAP even rewrote Arena allocation to use mmap for AIX, because large compile arenas caused lasting RSS increase, so it has definitely been a problem in the past) > > To follow up on @tstuefe comment - and the one that I tried to say in the bug was that we added this MmapArrayAllocate feature for some G1 marking bits that used so much memory that hit the Solaris _sbrk issue. Maybe @stefank and @tschatzl remember this issue. Maybe it's ok for AIX, then removing this code is a good change. Maybe the G1 usages need a mmap implementation though. > > The padding.inline.hpp usage seems to have one caller which is called once. The other mmap usage in G1 we can convert to mmap using a similar approach to zGranuleMap if that is preferred. That would then be equivalent behavior, it looks like the G1 code uses the page allocation granularity anyway so maybe keeping it mmap is the better way to go here anyway? My uninformed opinion (I'm not the G1 code owner) is that it would be fine to use explicit mmap. I'd love the complexity reduction this patch brings. ------------- PR: https://git.openjdk.org/jdk/pull/11931 From stuefe at openjdk.org Thu Jan 12 16:59:18 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 12 Jan 2023 16:59:18 GMT Subject: RFR: JDK-8293114: GC should trim the native heap [v4] In-Reply-To: <23KpPM4oPV6F1nz3g5CvIqvuX-ANcsMH4GuVNXjR-Lw=.b8d0fa2d-bb85-4899-8e21-f68ea64b988d@github.com> References: <23KpPM4oPV6F1nz3g5CvIqvuX-ANcsMH4GuVNXjR-Lw=.b8d0fa2d-bb85-4899-8e21-f68ea64b988d@github.com> Message-ID: > This RFE adds the option to auto-trim the Glibc heap as part of the GC cycle. If the VM process suffered high temporary malloc spikes (regardless whether from JVM- or user code), this could recover significant amounts of memory. > > We discussed this a year ago [1], but the item got pushed to the bottom of my work pile, therefore it took longer than I thought. > > ### Motivation > > The Glibc allocator is reluctant to return memory to the OS, much more so than other allocators. Temporary malloc spikes often carry over as permanent RSS increase. > > Note that C-heap retention is difficult to observe. Since it is freed memory, it won't show up in NMT, it is just a part of private RSS. > > Theoretically, retained memory is not lost since it will be reused by future mallocs. Retaining memory is therefore a bet on the future behavior of the app. The allocator bets on the application needing memory in the near future, and to satisfy that need via malloc. > > But an app's malloc load can fluctuate wildly, with temporary spikes and long idle periods. And if the app rolls its own custom allocators atop of mmap, as hotspot does, a lot of that memory cannot be reused even though it counts toward its memory footprint. > > To help, Glibc exports an API to trim the C-heap: `malloc_trim(3)`. With JDK 18 [2], SAP contributed a new jcmd command to *manually* trim the C-heap on Linux. This RFE adds a complementary way to trim automatically. > > #### Is this even a problem? > > Do we have high malloc spikes in the JVM process? We assume that malloc load from hotspot is usually low since hotspot typically clusters allocations into custom areas - metaspace, code heap, arenas. > > But arenas are subject to Glibc mem retention too. I was surprised by that since I assumed 32k arena chunks were too big to be subject of Glibc retention. But I saw in experiments that high arena peaks often cause lasting RSS increase. > > And of course, both hotspot and JDK do a lot of finer-granular mallocs outside of custom allocators. > > But many cases of high memory retention in Glibc I have seen in third-party JNI code. Libraries allocate large buffers via malloc as temporary buffers. In fact, since we introduced the jcmd "System.trim_native_heap", some of our customers started to call this command periodically in scripts to counter these issues. > > Therefore I think while high malloc spikes are atypical for a JVM process, they can happen. Having a way to auto-trim the native heap makes sense. > > ### When should we trim? > > We want to trim when we know there is a lull in malloc activity coming. But we have no knowledge of the future. > > We could build a heuristic based on malloc frequency. But on closer inspection that is difficult. We cannot use NMT, since NMT has no complete picture (only knows hotspot) and is usually disabled in production anyway. The only way to get *all* mallocs would be to use Glibc malloc hooks. We have done so in desperate cases at SAP, but Glibc removed malloc hooks in 2.35. It would be a messy solution anyway; best to avoid it. > > The next best thing is synchronizing with the larger C-heap users in the VM: compiler and GC. But compiler turns out not to be such a problem, since the compiler uses arenas, and arena chunks are buffered in a free pool with a five-second delay. That means compiler activity that happens in bursts, like at VM startup, will just shuffle arena chunks around from/to the arena free pool, never bothering to call malloc or free. > > That leaves the GC, which was also the experts' recommendation in last year's discussion [1]. Most GCs do uncommit, and trimming the native heap fits well into this. And we want to time the trim to not get into the way of a GC. Plus, integrating trims into the GC cycle lets us reuse GC logging and timing, thereby making RSS changes caused by trim-native visible to the analyst. > > > ### How it works: > > Patch adds new options (experimental for now, and shared among all GCs): > > > -XX:+GCTrimNativeHeap > -XX:GCTrimNativeHeapInterval= (defaults to 60) > > > `GCTrimNativeHeap` is off by default. If enabled, it will cause the VM to trim the native heap on full GCs as well as periodically. The period is defined by `GCTrimNativeHeapInterval`. Periodic trimming can be completely switched off with `GCTrimNativeHeapInterval=0`; in that case, we will only trim on full GCs. > > ### Examples: > > This is an artificial test that causes two high malloc spikes with long idle periods. Observe how RSS recovers with trim but stays up without trim. The trim interval was set to 15 seconds for the test, and no GC was invoked here; this is periodic trimming. > > ![alloc-test](http://cr.openjdk.java.net/~stuefe/other/autotrim/rss-all-collectors.png) > > (See here for parameters: [run script](http://cr.openjdk.java.net/~stuefe/other/autotrim/run-all.sh) ) > > Spring pet clinic boots up, then idles. Once with, once without trim, with the trim interval at 60 seconds default. Of course, if it were actually doing something instead of idling, trim effects would be smaller. But the point of trimming is to recover memory in idle periods. > > ![petclinic bootup](http://cr.openjdk.java.net/~stuefe/other/autotrim/spring-petclinic-rss-with-and-without-trim.png)) > > (See here for parameters: [run script](http://cr.openjdk.java.net/~stuefe/other/autotrim/run-petclinic-boot.sh) ) > > > > ### Implementation > > One problem I faced when implementing this was that trimming was non-interruptable. GCs usually split the uncommit work into smaller portions, which is impossible for `malloc_trim()`. > > So very slow trims could introduce longer GC pauses. I did not want this, therefore I implemented two ways to trim: > 1) GCs can opt to trim asynchronously. In that case, a `NativeTrimmer` thread runs on behalf of the GC and takes care of all trimming. The GC just nudges the `NativeTrimmer` at the end of its GC cycle, but the trim itself runs concurrently. > 2) GCs can do the trim inside their own thread, synchronously. It will have to wait until the trim is done. > > (1) has the advantage of giving us periodic trims even without GC activity (Shenandoah does this out of the box). > > #### Serial > > Serial does the trimming synchronously as part of a full GC, and only then. I did not want to spawn a separate thread for the SerialGC. Therefore Serial is the only GC that does not offer periodic trimming, it just trims on full GC. > > #### Parallel, G1, Z > > All of them do the trimming asynchronously via `NativeTrimmer`. They schedule the native trim at the end of a full collection. They also pause the trimming at the beginning of a cycle to not trim during GCs. > > #### Shenandoah > > Shenandoah does the trimming synchronously in its service thread, similar to how it handles uncommits. Since the service thread already runs concurrently and continuously, it can do periodic trimming; no need to spin a new thread. And this way we can reuse the Shenandoah timing classes. > > ### Patch details > > - adds three new functions to the `os` namespace: > - `os::trim_native_heap()` implementing trim > - `os::can_trim_native_heap()` and `os::should_trim_native_heap()` to return whether platform supports trimming resp. whether the platform considers trimming to be useful. > - replaces implementation of the cmd "System.trim_native_heap" with the new `os::trim_native_heap` > - provides a new wrapper function wrapping the tedious `mallinfo()` vs `mallinfo2()` business: `os::Linux::get_mallinfo()` > - adds a GC-shared utility class, `GCTrimNative`, that takes care of trimming and GC-logging and houses the `NativeTrimmer` thread class. > - adds a regression test > > > ### Tests > > Tested older Glibc (2.31), and newer Glibc (2.35) (`mallinfo()` vs` mallinfo2()`), on Linux x64. > > The rest of the tests will be done by GHA and in our SAP nightlies. > > > ### Remarks > > #### How about other allocators? > > I have seen this retention problem mainly with the Glibc and the AIX libc. Muslc returns memory more eagerly to the OS. I also tested with jemalloc and found it also reclaims more aggressively, therefore I don't think MacOS or BSD are affected that much by retention either. > > #### Trim costs? > > Trim-native is a tradeoff between memory and performance. We pay > - The cost to do the trim depends on how much is trimmed. Time ranges on my machine between < 1ms for no-op trims, to ~800ms for 32GB trims. > - The cost for re-acquiring the memory, should the memory be needed again, is the second cost factor. > > #### Predicting malloc_trim effects? > > `ShenandoahUncommit` avoids uncommits if they are not necessary, thus avoiding work and gc log spamming. I liked that and tried to follow that example. Tried to devise a way to predict the effect trim could have based on allocator info from mallinfo(3). That was quite frustrating since the documentation was confusing and I had to do a lot of experimenting. In the end, I came up with a heuristic to prevent obviously pointless trim attempts; see `os::should_trim_native_heap()`. I am not completely happy with it. > > #### glibc.malloc.trim_threshold? > > glibc has a tunable that looks like it could influence the willingness of Glibc to return memory to the OS, the "trim_threshold". In practice, I could not get it to do anything useful. Regardless of the setting, it never seemed to influence the trimming behavior. Even if it would work, I'm not sure we'd want to use that, since by doing malloc_trim manually we can space out the trims as we see fit, instead of paying the trim price for free(3). > > > - [1] https://mail.openjdk.org/pipermail/hotspot-dev/2021-August/054323.html > - [2] https://bugs.openjdk.org/browse/JDK-8269345 Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Fix merge errors - merge - Merge branch 'master' into JDK-8293114-GC-trim-native - Merge branch 'master' into JDK-8293114-GC-trim-native - Make test more fault tolerant - Merge branch 'master' into JDK-8293114-GC-trim-native - reduce test runtime on slow hardware - make tests more stable on slow hardware - wip - Fixes and Simplifications - ... and 2 more: https://git.openjdk.org/jdk/compare/d716ec5d...5b997d65 ------------- Changes: https://git.openjdk.org/jdk/pull/10085/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10085&range=03 Stats: 923 lines in 22 files changed: 920 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10085.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10085/head:pull/10085 PR: https://git.openjdk.org/jdk/pull/10085 From ayang at openjdk.org Thu Jan 12 17:10:36 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 12 Jan 2023 17:10:36 GMT Subject: RFR: 8300054: Use static_assert in basic_types_init [v2] In-Reply-To: References: Message-ID: > Simple change to use `static_assert` when applicable inside a function. Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11971/files - new: https://git.openjdk.org/jdk/pull/11971/files/108368e2..688d5762 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11971&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11971&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11971.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11971/head:pull/11971 PR: https://git.openjdk.org/jdk/pull/11971 From stefank at openjdk.org Thu Jan 12 17:12:14 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 12 Jan 2023 17:12:14 GMT Subject: RFR: 8300054: Use static_assert in basic_types_init [v2] In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 17:10:36 GMT, Albert Mingkun Yang wrote: >> Simple change to use `static_assert` when applicable inside a function. > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11971 From lkorinth at openjdk.org Thu Jan 12 18:09:20 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 12 Jan 2023 18:09:20 GMT Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable [v6] In-Reply-To: References: Message-ID: <694H4dKzN6YRMIUT_sEdSgiAn4R3z77fX8SbLCABw7E=.e98be249-3716-4f18-b563-15246cd3ceab@github.com> On Thu, 12 Jan 2023 12:56:51 GMT, Leo Korinth wrote: >> I am replacing the old hash table with ResourceHashtable. In the process I am also removing the redundant `_length` field. By removing the `_length` field, a lot of asserts can be removed as the length will trivially match the length of the underlying table. >> >> I would like to have feedback on the addition of `unlink_destruct(Function&& should_remove)`. I added it because I prefer to use a functor object that can be used by lambdas instead of an iterator object. However, I did add code to "destruct" resource objects when they are removed instead of just letting them be to reflect that we use `delete` on c-heap objects. Maybe I should remove this "improvement" and then maybe implement the function by calling the existing unlink? > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > revert copyright year after changes Although I have no test problems, I am still looking into stuff that worries me. My worries are around the code cache methods that do *not* use locks (`contains` and `nmethods_do`). The earlier hash table used used `Atomic::release_store(&_entry, l)`. Interleaved (non-locked) accesses might now pick bad pointers (the reason why I removed `contains` from `add`). I will update you on my findings... ------------- PR: https://git.openjdk.org/jdk/pull/11675 From vlivanov at openjdk.org Thu Jan 12 18:14:24 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 12 Jan 2023 18:14:24 GMT Subject: RFR: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions In-Reply-To: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> References: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> Message-ID: On Thu, 12 Jan 2023 02:52:17 GMT, Sergey Kuksenko wrote: > 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions As an alternative way to count nops, have you considered iterating over relocations and counting `post_call_nop_Reolcation`s then multiplying the count by `NativePostCallNop::instruction_size`? (So far, there's no `NativePostCallNop::instruction_size` declared on aarch64 and ppc, but that's the common pattern in nativeInst_*.hpp.) BTW I'm curious why there's no relocation registered on PPC while both x86 and aarch64 have it. ------------- PR: https://git.openjdk.org/jdk/pull/11958 From iklam at openjdk.org Thu Jan 12 19:14:44 2023 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 12 Jan 2023 19:14:44 GMT Subject: RFR: 8297914: Remove java_lang_Class::process_archived_mirror() [v2] In-Reply-To: References: Message-ID: > This is another prerequisite for [JDK-8296344](https://bugs.openjdk.org/browse/JDK-8296344). > > Before this PR, when archiving mirror objects (i.e., instances of `java.lang.Class`): > - We first allocate a copy of the mirror inside a safepoint. > - We then reinitialize the contents of the copy to the desired state (so that it can be used by `Klass::restore_unshareable_info()` > > This copy-and-modify operation inside the safepoint makes it difficult to implement [JDK-8296344](https://bugs.openjdk.org/browse/JDK-8296344). It violates the requirements [1] and [2] as stated in [JDK-8298600](https://bugs.openjdk.org/browse/JDK-8298600). Also, the reinitialization code is complicated. > > After this PR: > - During the creation of each regular mirror object, we allocate a "scratch mirror" object, which has the states as expected by `Klass::restore_unshareable_info()`. See `java_lang_Class::create_scratch_mirror()`. > - When the archive heap is dumped inside a safepoint, we use the scratch mirror, so we can avoid the copy-and-modify operation. See `HeapShared::archive_java_mirrors()`. > > Testing: tiers 1-4 Ioi Lam has updated the pull request incrementally with three additional commits since the last revision: - review comments from @ashu-mehra and @dholmes-ora - fixed repo - tmp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11853/files - new: https://git.openjdk.org/jdk/pull/11853/files/85871277..0fba1448 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11853&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11853&range=00-01 Stats: 8 lines in 3 files changed: 3 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11853.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11853/head:pull/11853 PR: https://git.openjdk.org/jdk/pull/11853 From iklam at openjdk.org Thu Jan 12 19:14:48 2023 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 12 Jan 2023 19:14:48 GMT Subject: RFR: 8297914: Remove java_lang_Class::process_archived_mirror() [v2] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 19:14:27 GMT, Ashutosh Mehra wrote: >> Ioi Lam has updated the pull request incrementally with three additional commits since the last revision: >> >> - review comments from @ashu-mehra and @dholmes-ora >> - fixed repo >> - tmp > > src/hotspot/share/cds/heapShared.cpp line 379: > >> 377: }; >> 378: >> 379: static KlassToOopHandleTable* _scratch_java_mirror_table = NULL; > > Any reason why `_scratch_basic_type_mirrors` is a static member of `HeapShared` but `_scratch_java_mirror_table` is not? I moved this field as a static member of `HeapShared` as well. > src/hotspot/share/classfile/javaClasses.cpp line 1347: > >> 1345: assert(java_class == Universe::void_mirror(), "only valid non-array primitive"); >> 1346: } >> 1347: assert(Universe::java_mirror(type) == java_class || > > If we need the condition `HeapShared::scratch_java_mirror(type) == java_class` here, shouldn't the previous assert be also updated to check for scratch java mirror for void type? > > `assert(java_class == Universe::void_mirror() |, "only valid non-array primitive");` This change doesn't seem to be needed. I've removed it and my local tests passed. I'll test more thoroughly in my CI pipeline. ------------- PR: https://git.openjdk.org/jdk/pull/11853 From iklam at openjdk.org Thu Jan 12 19:14:49 2023 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 12 Jan 2023 19:14:49 GMT Subject: RFR: 8297914: Remove java_lang_Class::process_archived_mirror() [v2] In-Reply-To: References: Message-ID: On Thu, 5 Jan 2023 01:38:32 GMT, David Holmes wrote: >> Ioi Lam has updated the pull request incrementally with three additional commits since the last revision: >> >> - review comments from @ashu-mehra and @dholmes-ora >> - fixed repo >> - tmp > > src/hotspot/share/classfile/javaClasses.cpp line 1062: > >> 1060: // >> 1061: // Note: we archive the "scratch mirror" instead of k->java_mirror(), because the >> 1062: // later may contain dumptime-specific information that cannot be archived > > s/later/latter/ Fixed. ------------- PR: https://git.openjdk.org/jdk/pull/11853 From ioi.lam at oracle.com Thu Jan 12 19:36:36 2023 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 12 Jan 2023 11:36:36 -0800 Subject: RFC: regarding metaspace(metadata?) dump In-Reply-To: <5575ed15-6783-456c-ae42-703c440f84b5.qingfeng.yy@alibaba-inc.com> References: <5575ed15-6783-456c-ae42-703c440f84b5.qingfeng.yy@alibaba-inc.com> Message-ID: <8d31b2d1-b092-8295-960b-fa953e56cf5e@oracle.com> On 1/12/2023 12:29 AM, Yi Yang wrote: > Thanks Ioi and Thomas for your valuable thoughts! I list some pros > about metaspace dump. > > 1. Standardization. The format of metadata dump is standard and > well-formed. It could be seamlessly integrated with > DevOps/Diagnose/APM platforms, while SA is interactively and the > output of jcmd is not well-formed and parser-unfriendly, and its > content is subject to change. You can't expect DevOps platform to use > SA/coredump/gdb conveniently and automatically in production environment. > The reason I mentioned SA is for implementing the dumper that you're proposing on top of SA, because SA already has APIs for reflective access into the metadata. This would be much less intrusive than modifying HotSpot itself. I once implemented something similar (but much more simple: jcmd GC.class_stats). It was removed in https://bugs.openjdk.org/browse/JDK-8232759 due to lack of usage and cost of maintenance. Thanks - Ioi > 2. Functionality. MetaspaceDumpBeforeFullGC could generate a small > dump for further debugging, it works as well as heap dump. > > 3. JVM Metadata. Codecache dump, method counter, method data, they are > unexplored scopes, reconstruct human-readable representation of > compiled method. > > 4. Complexity. In my humble opinion, all of this stuff such as > by-chunktype/show-loaders/VM.classloader_stats/VM.classloader_hierarchy/etc > could be done in other place. VM is eligible to provides a standard > and rich raw metadata output, third-party parser and UI render display > them in their way instead of continuously adding new > filter/grouping/hierarcy/VM.method_counter features when we do want to > know them. Heap dump is a good example, it dumps all > objects/symbols/etc to a binary file, and third-party tools > orchestrate them to histogram/thread/classloader/domtree. > > Basically, I know the content of metaspace dump file has overlap with > some existing tools such as SA/jcmd/coredump/gdb/HeapDump, as Thomas > commented inlinely, I don?t think metaspace dump can troubleshoot many > problems that it is the only solution. I think metadata dump is more > about providing a standardized and parser-friendly framework, so that > users at all levels can inspect JVM metadata information they care > about. In addition, something like M(etaspace)AT could orchestrate > dump content with filter/grouping/hierarchy options. > > > Also you mentioned that "Internally we implemented a metaspace dump > that generates human-readable text". Can you share how this tool was > implemented? > > That's not surprising, it iterates CLD/Classes/etc and dumps basic > information about metaspace, a demo metaspace dump can be found at > https://gist.github.com/y1yang0/683d8a58dd946b3e9180682863df55ea > > > ------------------------------------------------------------------ > From:Thomas St?fe > Send Time:2023 Jan. 12 (Thu.) 15:06 > To:"YANG, Yi" > Cc:HotSpot Open Source Developers ; > hotspot-runtime-dev ; > hotspot-dev > Subject:Re: RFC: regarding metaspace(metadata?) dump > > Hi Yi, > > A lot of what you try to do already exists. For example, we also > have `VM.metaspace`. This is a quite powerful command to analyze > Metaspace-related issues, especially for fragmentation and other > wastages. Generally speaking, it is the tool you use to look at > the underpinnings of metaspace, the allocator, while tools like > `VM.classloaders`, `VM.classloader_stats` and `VM.classes` look at > things "from above", e.g. walk the CLDG. All these tools have > already a bit of overlap. > > For analyzing OOMEs, you need several tools, since it can be > caused by multiple issues. E.g. tools that walk the CLDG don't see > fragmentation, or unclaimed metaspace for dead loaders. > > Please find more remarks inline. > > On Wed, Jan 11, 2023 at 1:56 PM Yi Yang > wrote: > Hi, > > Internally, we often receive feedback from users and ask for help > on metaspace-related issues, for example > 1. Users are eager to know which GroovyClassLoader loads which > classes, why they are not unloaded, > and why they are leading to Metaspace OOME. > > There are several tools to do this, for example: > > `VM.metaspace show-loaders show-classes` > `VM.classloaders show-classes` > > both show you loaded classes by loader, and the former also shows > you metaspace stats needed to understand OOMEs. None of these > tools shows you why loaders are kept alive, but for that you need > heap- and GC-root-analysis. This quickly enters the territory of > Eclipse MAT and similar tools, where having a text-based tool > alone gets cumbersome. > 2. They want to know the class structure of dynamically generated > classes in some scenarios such as > deserialization > > Interesting. This seems to be a very specific query; not sure how > general the need for this is. `VM.classes -verbose` shows a part > of the story. > 3. Finding memory leaking about duplicated classes > > Again, > > `VM.metaspace show-loaders show-classes` > `VM.classloaders show-classes` > > but also `VM.classes` and `VM.classloader_stats` are your friends > here. > > ... > Internally we implemented a metaspace dump that generates > human-readable text, it looks something like this: > > [Basic Information] > Dump Reason : JCMD > MaxMetaspaceSize : 18446744073709547520 B > CompressedClassSpaceSize : 1073741824 B > Class Space Used : 309992 B > Class Space Capacity : 395264 B > ... > [Class Loader Data] > ClassLoaderData : loader = 0x000000008024f928, loader_klass = > 0x0000000800010098, loader_klass_name = > sun/misc/Launcher$AppClassLoader, label = N/A > ? Class Used Chunks : > ? ? * Chunk : [0x0000000800060000, 0x0000000800060230, > 0x0000000800060800) > ? NonClass Used Chunks : > ? ? * Chunk : [0x00007fd8379c1000, 0x00007fd8379c1350, > 0x00007fd8379c2000) > ? Klasses : > ? ? Klass : 0x0000000800060028, name = Test, size = 520 B > ? ? ? ConstantPool : 0x00007fd8379c1050, size = 296 B > ... > > > `VM.metaspace` shows you the chunk composition of arenas if needed. > > E.g. : `VM.metaspace by-chunktype show-loaders` > > ``` > Usage per loader: > > ? ?1: CLD 0x00007f72fc29b820: "app" instance of > jdk.internal.loader.ClassLoaders$AppClassLoader > ? ? ? Loaded classes: > ? ? ? ? ?1: ?de.stuefe.repros.MiscUtils$$Lambda$1/0x0000000801001448 > ? ? ? ? ?2: ? ?de.stuefe.repros.MiscUtils > ? ? ? ? ?3: ? ?de.stuefe.repros.Simple2 > ? ? ? ? ?4: ? ?de.stuefe.repros.Simple > ? ? ? ? ?5: ? ?de.stuefe.repros.SimpleBase > ? ? ? ? ?6: ? ?de.stuefe.repros.I2 > ? ? ? ? ?7: ? ?de.stuefe.repros.I1 > ? ? ? -total-: 7 classes > ? Non-Class: > ? ? Usage by chunk level: > ? ? ? ? 4m chunks: ?(none) > ? ? ? ? 2m chunks: ?(none) > ? ? ? ? 1m chunks: ?(none) > ? ? ? 512k chunks: ?(none) > ? ? ? 256k chunks: ?(none) > ? ? ? 128k chunks: ?(none) > ? ? ? ?64k chunks: ?(none) > ? ? ? ?32k chunks: ?(none) > ? ? ? ?16k chunks: ?(none) > ? ? ? ? 8k chunks: ? ?1 chunk, ? ? ? 8,00 KB capacity, ? ?8,00 KB > (100%) committed, ? ? 8,00 KB (100%) used, ? ? 0 bytes ( ?0%) > free, ? ? 0 bytes ( ?0%) waste > ? ? ? ? 4k chunks: ? ?1 chunk, ? ? ? 4,00 KB capacity, ? ?4,00 KB > (100%) committed, ? 256 bytes ( ?6%) used, ? ? 3,75 KB ( 94%) > free, ? ? 0 bytes ( ?0%) waste > ? ? ? ? 2k chunks: ?(none) > ? ? ? ? 1k chunks: ?(none) > ? ? ? ? ? ? ? -total-: ? ?2 chunks, ? ? 12,00 KB capacity, ? 12,00 > KB (100%) committed, ? ? 8,25 KB ( 69%) used, ? ? 3,75 KB ( 31%) > free, ? ? 0 bytes ( ?0%) waste > ? ? deallocated: 1 blocks with 24 bytes > > ? ? ? Class: > ? ? Usage by chunk level: > ? ?? .... and so forth > ``` > > but for analyzing potential fragmentation issues (which have been > rare since JEP 387) the "Waste" section at the end of the printout > is much more helpful, e.g.: > > ``` > Waste (unused committed space):(percentages refer to total > committed size 384,00 KB): > ? ? ? ? Waste in chunks in use: ? ? ?0 bytes ( ?0%) > ? ? ? ? Free in chunks in use: ? ? 85,01 KB ( 22%) > ? ? ? ? ? ? ? ? In free chunks: ? ? ?0 bytes ( ?0%) > Deallocated from chunks in use: ? ?928 bytes ( <1%) (3 blocks) > ? ? ? ? ? ? ? ? ? ? ? ?-total-: ? ? 85,91 KB ( 22%) > ``` > > It has been working effectively for several years and has helped > many users solve metaspace-related problems. > But a more user-friendly way is that JDK can inherently support > this capability. We hope that format of the metaspace > dump file can take both flexibility and compatibility into > account,? and the content of dump file should be detailed > enough to meet the needs of both application developers and > lower-level developers. > > Based on above considerations, I think using JSON as its file > format is an appropriate solution(But XML or binary > format are still not excluded as candidates). Specifically, in > earlier thoughts, I thought the format of the metaspace > file could be as follows(pretty printed) > > https://gist.github.com/y1yang0/ab3034b6381b8a9d215602c89af4e9c3 > > > Using the JSON format, we can flexibly add new fields without > breaking compatibility. It is debatable as to which data > to write. We can reach a consensus that third-party > parsers(Metaspace Analyzer Tool) can at least reconstruct Java > source code from the dump file. Based on this, we can write more > useful information for low-level troubleshooting > or debugging. (e.g. the init_state of InstanceKlass). > In addition, we can even output the native code and associated > information with regard to Method, third-party parser > can reconstruct the human-readable assembly representation of the > compiled method based on dump file. To some extent, > we have implemented code cache dump by the way. For this reason, > I'm not sure if the title of the RFC proposal should > be called metaspace dump, maybe metadata dump?? It looks more like > a metadata-dump framework. > > Do you have any thoughts about metaspace/metadata dump? Looking > forward to hearing your feedback, any comments are invaluable! > > Best regards, > Yi Yang > > > Analyzing the structure of generated classes sounds interesting, > and could help with analyzing issues with bytecode instrumentation > tools. > > For analyzing general metaspace OOMEs we are already covered quite > well. Not perfect, but your proposal does intersect with existing > tools a lot. To keep code complexity down, I'd rather avoid adding > duplicate features. > > Cheers, Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ioi.lam at oracle.com Thu Jan 12 19:36:36 2023 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 12 Jan 2023 11:36:36 -0800 Subject: RFC: regarding metaspace(metadata?) dump In-Reply-To: <5575ed15-6783-456c-ae42-703c440f84b5.qingfeng.yy@alibaba-inc.com> References: <5575ed15-6783-456c-ae42-703c440f84b5.qingfeng.yy@alibaba-inc.com> Message-ID: <8d31b2d1-b092-8295-960b-fa953e56cf5e@oracle.com> On 1/12/2023 12:29 AM, Yi Yang wrote: > Thanks Ioi and Thomas for your valuable thoughts! I list some pros > about metaspace dump. > > 1. Standardization. The format of metadata dump is standard and > well-formed. It could be seamlessly integrated with > DevOps/Diagnose/APM platforms, while SA is interactively and the > output of jcmd is not well-formed and parser-unfriendly, and its > content is subject to change. You can't expect DevOps platform to use > SA/coredump/gdb conveniently and automatically in production environment. > The reason I mentioned SA is for implementing the dumper that you're proposing on top of SA, because SA already has APIs for reflective access into the metadata. This would be much less intrusive than modifying HotSpot itself. I once implemented something similar (but much more simple: jcmd GC.class_stats). It was removed in https://bugs.openjdk.org/browse/JDK-8232759 due to lack of usage and cost of maintenance. Thanks - Ioi > 2. Functionality. MetaspaceDumpBeforeFullGC could generate a small > dump for further debugging, it works as well as heap dump. > > 3. JVM Metadata. Codecache dump, method counter, method data, they are > unexplored scopes, reconstruct human-readable representation of > compiled method. > > 4. Complexity. In my humble opinion, all of this stuff such as > by-chunktype/show-loaders/VM.classloader_stats/VM.classloader_hierarchy/etc > could be done in other place. VM is eligible to provides a standard > and rich raw metadata output, third-party parser and UI render display > them in their way instead of continuously adding new > filter/grouping/hierarcy/VM.method_counter features when we do want to > know them. Heap dump is a good example, it dumps all > objects/symbols/etc to a binary file, and third-party tools > orchestrate them to histogram/thread/classloader/domtree. > > Basically, I know the content of metaspace dump file has overlap with > some existing tools such as SA/jcmd/coredump/gdb/HeapDump, as Thomas > commented inlinely, I don?t think metaspace dump can troubleshoot many > problems that it is the only solution. I think metadata dump is more > about providing a standardized and parser-friendly framework, so that > users at all levels can inspect JVM metadata information they care > about. In addition, something like M(etaspace)AT could orchestrate > dump content with filter/grouping/hierarchy options. > > > Also you mentioned that "Internally we implemented a metaspace dump > that generates human-readable text". Can you share how this tool was > implemented? > > That's not surprising, it iterates CLD/Classes/etc and dumps basic > information about metaspace, a demo metaspace dump can be found at > https://gist.github.com/y1yang0/683d8a58dd946b3e9180682863df55ea > > > ------------------------------------------------------------------ > From:Thomas St?fe > Send Time:2023 Jan. 12 (Thu.) 15:06 > To:"YANG, Yi" > Cc:HotSpot Open Source Developers ; > hotspot-runtime-dev ; > hotspot-dev > Subject:Re: RFC: regarding metaspace(metadata?) dump > > Hi Yi, > > A lot of what you try to do already exists. For example, we also > have `VM.metaspace`. This is a quite powerful command to analyze > Metaspace-related issues, especially for fragmentation and other > wastages. Generally speaking, it is the tool you use to look at > the underpinnings of metaspace, the allocator, while tools like > `VM.classloaders`, `VM.classloader_stats` and `VM.classes` look at > things "from above", e.g. walk the CLDG. All these tools have > already a bit of overlap. > > For analyzing OOMEs, you need several tools, since it can be > caused by multiple issues. E.g. tools that walk the CLDG don't see > fragmentation, or unclaimed metaspace for dead loaders. > > Please find more remarks inline. > > On Wed, Jan 11, 2023 at 1:56 PM Yi Yang > wrote: > Hi, > > Internally, we often receive feedback from users and ask for help > on metaspace-related issues, for example > 1. Users are eager to know which GroovyClassLoader loads which > classes, why they are not unloaded, > and why they are leading to Metaspace OOME. > > There are several tools to do this, for example: > > `VM.metaspace show-loaders show-classes` > `VM.classloaders show-classes` > > both show you loaded classes by loader, and the former also shows > you metaspace stats needed to understand OOMEs. None of these > tools shows you why loaders are kept alive, but for that you need > heap- and GC-root-analysis. This quickly enters the territory of > Eclipse MAT and similar tools, where having a text-based tool > alone gets cumbersome. > 2. They want to know the class structure of dynamically generated > classes in some scenarios such as > deserialization > > Interesting. This seems to be a very specific query; not sure how > general the need for this is. `VM.classes -verbose` shows a part > of the story. > 3. Finding memory leaking about duplicated classes > > Again, > > `VM.metaspace show-loaders show-classes` > `VM.classloaders show-classes` > > but also `VM.classes` and `VM.classloader_stats` are your friends > here. > > ... > Internally we implemented a metaspace dump that generates > human-readable text, it looks something like this: > > [Basic Information] > Dump Reason : JCMD > MaxMetaspaceSize : 18446744073709547520 B > CompressedClassSpaceSize : 1073741824 B > Class Space Used : 309992 B > Class Space Capacity : 395264 B > ... > [Class Loader Data] > ClassLoaderData : loader = 0x000000008024f928, loader_klass = > 0x0000000800010098, loader_klass_name = > sun/misc/Launcher$AppClassLoader, label = N/A > ? Class Used Chunks : > ? ? * Chunk : [0x0000000800060000, 0x0000000800060230, > 0x0000000800060800) > ? NonClass Used Chunks : > ? ? * Chunk : [0x00007fd8379c1000, 0x00007fd8379c1350, > 0x00007fd8379c2000) > ? Klasses : > ? ? Klass : 0x0000000800060028, name = Test, size = 520 B > ? ? ? ConstantPool : 0x00007fd8379c1050, size = 296 B > ... > > > `VM.metaspace` shows you the chunk composition of arenas if needed. > > E.g. : `VM.metaspace by-chunktype show-loaders` > > ``` > Usage per loader: > > ? ?1: CLD 0x00007f72fc29b820: "app" instance of > jdk.internal.loader.ClassLoaders$AppClassLoader > ? ? ? Loaded classes: > ? ? ? ? ?1: ?de.stuefe.repros.MiscUtils$$Lambda$1/0x0000000801001448 > ? ? ? ? ?2: ? ?de.stuefe.repros.MiscUtils > ? ? ? ? ?3: ? ?de.stuefe.repros.Simple2 > ? ? ? ? ?4: ? ?de.stuefe.repros.Simple > ? ? ? ? ?5: ? ?de.stuefe.repros.SimpleBase > ? ? ? ? ?6: ? ?de.stuefe.repros.I2 > ? ? ? ? ?7: ? ?de.stuefe.repros.I1 > ? ? ? -total-: 7 classes > ? Non-Class: > ? ? Usage by chunk level: > ? ? ? ? 4m chunks: ?(none) > ? ? ? ? 2m chunks: ?(none) > ? ? ? ? 1m chunks: ?(none) > ? ? ? 512k chunks: ?(none) > ? ? ? 256k chunks: ?(none) > ? ? ? 128k chunks: ?(none) > ? ? ? ?64k chunks: ?(none) > ? ? ? ?32k chunks: ?(none) > ? ? ? ?16k chunks: ?(none) > ? ? ? ? 8k chunks: ? ?1 chunk, ? ? ? 8,00 KB capacity, ? ?8,00 KB > (100%) committed, ? ? 8,00 KB (100%) used, ? ? 0 bytes ( ?0%) > free, ? ? 0 bytes ( ?0%) waste > ? ? ? ? 4k chunks: ? ?1 chunk, ? ? ? 4,00 KB capacity, ? ?4,00 KB > (100%) committed, ? 256 bytes ( ?6%) used, ? ? 3,75 KB ( 94%) > free, ? ? 0 bytes ( ?0%) waste > ? ? ? ? 2k chunks: ?(none) > ? ? ? ? 1k chunks: ?(none) > ? ? ? ? ? ? ? -total-: ? ?2 chunks, ? ? 12,00 KB capacity, ? 12,00 > KB (100%) committed, ? ? 8,25 KB ( 69%) used, ? ? 3,75 KB ( 31%) > free, ? ? 0 bytes ( ?0%) waste > ? ? deallocated: 1 blocks with 24 bytes > > ? ? ? Class: > ? ? Usage by chunk level: > ? ?? .... and so forth > ``` > > but for analyzing potential fragmentation issues (which have been > rare since JEP 387) the "Waste" section at the end of the printout > is much more helpful, e.g.: > > ``` > Waste (unused committed space):(percentages refer to total > committed size 384,00 KB): > ? ? ? ? Waste in chunks in use: ? ? ?0 bytes ( ?0%) > ? ? ? ? Free in chunks in use: ? ? 85,01 KB ( 22%) > ? ? ? ? ? ? ? ? In free chunks: ? ? ?0 bytes ( ?0%) > Deallocated from chunks in use: ? ?928 bytes ( <1%) (3 blocks) > ? ? ? ? ? ? ? ? ? ? ? ?-total-: ? ? 85,91 KB ( 22%) > ``` > > It has been working effectively for several years and has helped > many users solve metaspace-related problems. > But a more user-friendly way is that JDK can inherently support > this capability. We hope that format of the metaspace > dump file can take both flexibility and compatibility into > account,? and the content of dump file should be detailed > enough to meet the needs of both application developers and > lower-level developers. > > Based on above considerations, I think using JSON as its file > format is an appropriate solution(But XML or binary > format are still not excluded as candidates). Specifically, in > earlier thoughts, I thought the format of the metaspace > file could be as follows(pretty printed) > > https://gist.github.com/y1yang0/ab3034b6381b8a9d215602c89af4e9c3 > > > Using the JSON format, we can flexibly add new fields without > breaking compatibility. It is debatable as to which data > to write. We can reach a consensus that third-party > parsers(Metaspace Analyzer Tool) can at least reconstruct Java > source code from the dump file. Based on this, we can write more > useful information for low-level troubleshooting > or debugging. (e.g. the init_state of InstanceKlass). > In addition, we can even output the native code and associated > information with regard to Method, third-party parser > can reconstruct the human-readable assembly representation of the > compiled method based on dump file. To some extent, > we have implemented code cache dump by the way. For this reason, > I'm not sure if the title of the RFC proposal should > be called metaspace dump, maybe metadata dump?? It looks more like > a metadata-dump framework. > > Do you have any thoughts about metaspace/metadata dump? Looking > forward to hearing your feedback, any comments are invaluable! > > Best regards, > Yi Yang > > > Analyzing the structure of generated classes sounds interesting, > and could help with analyzing issues with bytecode instrumentation > tools. > > For analyzing general metaspace OOMEs we are already covered quite > well. Not perfect, but your proposal does intersect with existing > tools a lot. To keep code complexity down, I'd rather avoid adding > duplicate features. > > Cheers, Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpb at openjdk.org Thu Jan 12 19:41:49 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Jan 2023 19:41:49 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v10] In-Reply-To: References: Message-ID: > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299684: Miscellaneous cleanup of unit test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11873/files - new: https://git.openjdk.org/jdk/pull/11873/files/5269cae1..2fe819ba Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=08-09 Stats: 69 lines in 1 file changed: 46 ins; 14 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From kbarrett at openjdk.org Thu Jan 12 19:46:15 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 12 Jan 2023 19:46:15 GMT Subject: RFR: 8300054: Use static_assert in basic_types_init [v2] In-Reply-To: References: Message-ID: <3whhxA3UG_xLeq7-e0EMRs9U9rXb8sxEc9YD5EAKZ9c=.42b7dd0e-2fca-4524-82a8-095c5236b8f1@github.com> On Thu, 12 Jan 2023 17:10:36 GMT, Albert Mingkun Yang wrote: >> Simple change to use `static_assert` when applicable inside a function. > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/11971 From bpb at openjdk.org Thu Jan 12 19:48:59 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Jan 2023 19:48:59 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v11] In-Reply-To: References: Message-ID: > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299684: Remove unneeded OutOfMemoryError catch ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11873/files - new: https://git.openjdk.org/jdk/pull/11873/files/2fe819ba..38ea7997 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=09-10 Stats: 9 lines in 1 file changed: 1 ins; 5 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Thu Jan 12 19:49:06 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Jan 2023 19:49:06 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v9] In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 10:17:04 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8299684: Remove spurious file > > test/jdk/java/nio/jni/NewDirectByteBuffer.java line 28: > >> 26: import org.junit.jupiter.api.Assertions; >> 27: import org.junit.jupiter.params.ParameterizedTest; >> 28: import org.junit.jupiter.params.provider.ValueSource; > > Up to you but in other tests, we import static org.junit.jupiter.api.Assertions.* so that the asserts are simple assertXXX calls. Fixed in 2fe819ba1fd929eaaa6cc31caee38e217006c3f0. > test/jdk/java/nio/jni/NewDirectByteBuffer.java line 36: > >> 34: * IllegalArgumentException if the capacity is negative or greater than >> 35: * Integer::MAX_VALUE >> 36: * @requires (sun.arch.data.model == "64" & os.maxMemory >= 8g) > > The @summary should probably be updated to say that it's a unit test for JNI NewDirectBufferBuffer. So changed in 2fe819ba1fd929eaaa6cc31caee38e217006c3f0. > test/jdk/java/nio/jni/NewDirectByteBuffer.java line 53: > >> 51: "Buffer::position returned unexpected value"); >> 52: Assertions.assertEquals(capacity, buf.limit(), >> 53: "Buffer::limit returned unexpected value"); > > For completeness, I think checkBuffer should also set/get some elements. Tests added in 2fe819ba1fd929eaaa6cc31caee38e217006c3f0. > test/jdk/java/nio/jni/NewDirectByteBuffer.java line 77: > >> 75: } >> 76: } catch (OutOfMemoryError ignored) { >> 77: // Ignore the error > > If I read this correctly, this frees the backing memory before it tests the buffer methods. This may be safe because checkBuffer doesn't access the buffer contents but if the checks are expanded then this will crash. > > I think you should be able to reduce this method down to this: > > > ByteBuffer buf = newDirectByteBuffer(capacity); > try { > checkBuffer(buf, capacity); > } finally { > freeDirectByteBufferMemory(buf); > } So changed in 2fe819ba1fd929eaaa6cc31caee38e217006c3f0. > test/jdk/java/nio/jni/NewDirectByteBuffer.java line 83: > >> 81: @ParameterizedTest >> 82: @ValueSource(longs = {Long.MIN_VALUE, (long)Integer.MIN_VALUE - 1L, -1L, >> 83: (long)Integer.MAX_VALUE + 1L, 3_000_000_000L, 5_000_000_000L, > > Just curious why 3_000_000_000L and 5_000_000_000L are in the values to test. They were in the initial bug report. > test/jdk/java/nio/jni/NewDirectByteBuffer.java line 93: > >> 91: } >> 92: }); >> 93: } catch (OutOfMemoryError ignored) { > > Why is there is catch of OOME here? Apparently it is not needed so removed in 38ea7997be2be59e2cea97c7dabf929210c0edfa. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From alanb at openjdk.org Thu Jan 12 20:08:29 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 12 Jan 2023 20:08:29 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v11] In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 19:48:59 GMT, Brian Burkhalter wrote: >> Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299684: Remove unneeded OutOfMemoryError catch I think this looks okay. If you are doing any further edits then the try-finally OOME can be removed from the illegalCapacities test. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Thu Jan 12 20:28:56 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Jan 2023 20:28:56 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v12] In-Reply-To: References: Message-ID: > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299684: Removed try-finally OOME from the illegalCapacities test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11873/files - new: https://git.openjdk.org/jdk/pull/11873/files/38ea7997..7d526352 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=10-11 Stats: 10 lines in 1 file changed: 0 ins; 4 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From alanb at openjdk.org Thu Jan 12 20:34:22 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 12 Jan 2023 20:34:22 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v12] In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 20:28:56 GMT, Brian Burkhalter wrote: >> Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299684: Removed try-finally OOME from the illegalCapacities test Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11873 From jcking at openjdk.org Thu Jan 12 20:39:54 2023 From: jcking at openjdk.org (Justin King) Date: Thu, 12 Jan 2023 20:39:54 GMT Subject: RFR: JDK-8300080: offset_of for GCC/Clang exhibits undefined behavior and is not always a compile-time constant Message-ID: The implementation of `offset_of` for GCC/Clang only deals with types are aligned to 16 bytes or less, if they are more, such as `zCollectedHeap` the behavior is undefined. UBSan also suggests that `offset_of` is not always a compile time constant, as the stack trace came from the dynamic loader during library loading. This patch changes `offset_of` to use `offsetof` and disables the warning `invalid-offsetof` for the JVM. ------------- Commit messages: - offset_of for GCC/Clang exhibits undefined behavior and is not always a compile-time constant Changes: https://git.openjdk.org/jdk/pull/11978/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11978&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300080 Stats: 19 lines in 2 files changed: 1 ins; 15 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11978.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11978/head:pull/11978 PR: https://git.openjdk.org/jdk/pull/11978 From jcking at openjdk.org Thu Jan 12 20:39:55 2023 From: jcking at openjdk.org (Justin King) Date: Thu, 12 Jan 2023 20:39:55 GMT Subject: RFR: JDK-8300080: offset_of for GCC/Clang exhibits undefined behavior and is not always a compile-time constant In-Reply-To: References: Message-ID: <6PF63HtQHJCGi4aTX7WhUCcmPFWmWa7gBJJRQms8q4M=.9d081701-a7df-48c6-9d8b-961525613afc@github.com> On Thu, 12 Jan 2023 20:28:50 GMT, Justin King wrote: > The implementation of `offset_of` for GCC/Clang only deals with types are aligned to 16 bytes or less, if they are more, such as `zCollectedHeap` the behavior is undefined. UBSan also suggests that `offset_of` is not always a compile time constant, as the stack trace came from the dynamic loader during library loading. This patch changes `offset_of` to use `offsetof` and disables the warning `invalid-offsetof` for the JVM. @aph FYI undoes `offset_of` change from JDK-8294902 ------------- PR: https://git.openjdk.org/jdk/pull/11978 From ioi.lam at oracle.com Thu Jan 12 20:56:03 2023 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 12 Jan 2023 12:56:03 -0800 Subject: RFC: regarding metaspace(metadata?) dump In-Reply-To: References: <5575ed15-6783-456c-ae42-703c440f84b5.qingfeng.yy@alibaba-inc.com> Message-ID: On 1/12/2023 1:55 AM, Thomas St?fe wrote: > > If standardization is the goal we take seriously, we'd need to > carefully choose the information we expose, limiting them to those > that are stable. That limits the usefulness of the command. > [...] > Heap dump is a good example of the limits of this approach, since the > sheer size of data can make them cumbersome and expensive to get. > There is a niche for tools that quickly tell you what you need, > without a lot of fuss, runtime costs, and intermediate steps. And that > help you along the way of analysis. > There's one big difference between dumping the heap vs metaspace. The contents of the Java objects are well defined, and have a very limited set of types (primitive types plus references). This makes it very easy to write tools to analyze a heap dump and we can guarantee that such tools will work for future versions of JDK (well, maybe some mods are needed when we have value types). However, there is no spec for the metaspace object layout. We *could* limit the data to just those specified by the JVM spec (i.e., just print out the equivalent of a .class file for every loaded class). If we do just this, what kind of use cases can benefit from it? I'll give an example here that such a generic dump will not help: I wanted to analyze the linkage of invokedynamic instructions. If we had a metaspace dump, it would solve one of my problems -- indys are linked using generated classes, which aren't available on the classpath. So with a metaspace dump, I can get to the generated classes. However, if I have more than one indys, how do I find out which generated class is related to which indy? Since the linkage may be implemented differently in each HotSpot version, it's not possible to represent that in a portable way. For this problem, I had to write the findclass() debug method. See JDK-8292699. I have some example dumps in the PR (https://github.com/openjdk/jdk/pull/9957). -------------- next part -------------- An HTML attachment was scrubbed... URL: From ioi.lam at oracle.com Thu Jan 12 20:56:03 2023 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 12 Jan 2023 12:56:03 -0800 Subject: RFC: regarding metaspace(metadata?) dump In-Reply-To: References: <5575ed15-6783-456c-ae42-703c440f84b5.qingfeng.yy@alibaba-inc.com> Message-ID: On 1/12/2023 1:55 AM, Thomas St?fe wrote: > > If standardization is the goal we take seriously, we'd need to > carefully choose the information we expose, limiting them to those > that are stable. That limits the usefulness of the command. > [...] > Heap dump is a good example of the limits of this approach, since the > sheer size of data can make them cumbersome and expensive to get. > There is a niche for tools that quickly tell you what you need, > without a lot of fuss, runtime costs, and intermediate steps. And that > help you along the way of analysis. > There's one big difference between dumping the heap vs metaspace. The contents of the Java objects are well defined, and have a very limited set of types (primitive types plus references). This makes it very easy to write tools to analyze a heap dump and we can guarantee that such tools will work for future versions of JDK (well, maybe some mods are needed when we have value types). However, there is no spec for the metaspace object layout. We *could* limit the data to just those specified by the JVM spec (i.e., just print out the equivalent of a .class file for every loaded class). If we do just this, what kind of use cases can benefit from it? I'll give an example here that such a generic dump will not help: I wanted to analyze the linkage of invokedynamic instructions. If we had a metaspace dump, it would solve one of my problems -- indys are linked using generated classes, which aren't available on the classpath. So with a metaspace dump, I can get to the generated classes. However, if I have more than one indys, how do I find out which generated class is related to which indy? Since the linkage may be implemented differently in each HotSpot version, it's not possible to represent that in a portable way. For this problem, I had to write the findclass() debug method. See JDK-8292699. I have some example dumps in the PR (https://github.com/openjdk/jdk/pull/9957). -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Thu Jan 12 21:21:25 2023 From: duke at openjdk.org (Ashutosh Mehra) Date: Thu, 12 Jan 2023 21:21:25 GMT Subject: RFR: 8297914: Remove java_lang_Class::process_archived_mirror() [v2] In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 19:14:44 GMT, Ioi Lam wrote: >> This is another prerequisite for [JDK-8296344](https://bugs.openjdk.org/browse/JDK-8296344). >> >> Before this PR, when archiving mirror objects (i.e., instances of `java.lang.Class`): >> - We first allocate a copy of the mirror inside a safepoint. >> - We then reinitialize the contents of the copy to the desired state (so that it can be used by `Klass::restore_unshareable_info()` >> >> This copy-and-modify operation inside the safepoint makes it difficult to implement [JDK-8296344](https://bugs.openjdk.org/browse/JDK-8296344). It violates the requirements [1] and [2] as stated in [JDK-8298600](https://bugs.openjdk.org/browse/JDK-8298600). Also, the reinitialization code is complicated. >> >> After this PR: >> - During the creation of each regular mirror object, we allocate a "scratch mirror" object, which has the states as expected by `Klass::restore_unshareable_info()`. See `java_lang_Class::create_scratch_mirror()`. >> - When the archive heap is dumped inside a safepoint, we use the scratch mirror, so we can avoid the copy-and-modify operation. See `HeapShared::archive_java_mirrors()`. >> >> Testing: tiers 1-4 > > Ioi Lam has updated the pull request incrementally with three additional commits since the last revision: > > - review comments from @ashu-mehra and @dholmes-ora > - fixed repo > - tmp Marked as reviewed by ashu-mehra at github.com (no known OpenJDK username). lgtm! thanks for addressing the comments. ------------- PR: https://git.openjdk.org/jdk/pull/11853 From shade at openjdk.org Fri Jan 13 04:02:47 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 13 Jan 2023 04:02:47 GMT Subject: RFR: JDK-8300080: offset_of for GCC/Clang exhibits undefined behavior and is not always a compile-time constant In-Reply-To: References: Message-ID: <6daznGbtxGUhIgyQvhTxqn6K_2VyJSj9sSHjJ1ADQak=.e346570a-6a15-4b39-8375-afe8a67b318b@github.com> On Thu, 12 Jan 2023 20:28:50 GMT, Justin King wrote: > The implementation of `offset_of` for GCC/Clang only deals with types are aligned to 16 bytes or less, if they are more, such as `zCollectedHeap` the behavior is undefined. UBSan also suggests that `offset_of` is not always a compile time constant, as the stack trace came from the dynamic loader during library loading. This patch changes `offset_of` to use `offsetof` and disables the warning `invalid-offsetof` for the JVM. You need to page @theRealAph for this. ------------- PR: https://git.openjdk.org/jdk/pull/11978 From fyang at openjdk.org Fri Jan 13 04:02:58 2023 From: fyang at openjdk.org (Fei Yang) Date: Fri, 13 Jan 2023 04:02:58 GMT Subject: RFR: 8299844: RISC-V: Implement _onSpinWait intrinsic In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 09:52:40 GMT, Yadong Wang wrote: > Implement _onSpinWait() intrinsic for RISC-V, and it can be implemented by using PAUSE instruction from Zihintpause Extension, which is ratified and a mandatory extension of RVA22U64 (https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#rva22u64-mandatory-extensions). > Software can use the PAUSE instruction to reduce energy consumption while executing spinwait > code sequences (https://github.com/riscv/riscv-isa-manual/blob/master/src/zihintpause.tex). > > Add a test case of test/hotspot/jtreg/compiler/onSpinWait/TestOnSpinWaitRISCV64.java, passed on QEMU. Don't forget to update the copyright year of the changes files. ------------- Changes requested by fyang (Reviewer). PR: https://git.openjdk.org/jdk/pull/11921 From sspitsyn at openjdk.org Fri Jan 13 04:02:58 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 13 Jan 2023 04:02:58 GMT Subject: RFR: 8299635: More test issues for deprecated sprintf in Xcode 14 In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 06:26:18 GMT, Xue-Lei Andrew Fan wrote: > The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. > > This patch is trying to find the use of sprintf in test cases, and replace it with snprintf accordingly. This looks good. Thank you for fixing it. Serguei There are more uses of sprintf in some serviceability folders: src/jdk.hotspot.agent/linux/native/libsaproc/ps_proc.c: sprintf(fname, "/proc/%d/status", pid); src/jdk.hotspot.agent/linux/native/libsaproc/ps_proc.c: sprintf(fname, "/proc/%d/maps", ph->pid); src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c: s = filename + sprintf (filename, "%s/.build-id/", debug_file_directory); src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c: s += sprintf (s, "%02x", *data++); src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c: s += sprintf (s, "%02x", *data++); src/jdk.hotspot.agent/windows/native/libsaproc/sawindbg.cpp: sprintf(errmsg, "%s (hr: 0x%08X)", str, hr); \ src/jdk.management/share/native/libmanagement_ext/management_ext.c: sprintf(errmsg, "errno: %d error: %s\n", errno, msg); src/java.management/share/native/libmanagement/VMManagementImpl.c: sprintf(buf, "%d.%d", major, minor); src/java.management/share/native/libmanagement/management.c: sprintf(errmsg, "errno: %d error: %s\n", errno, msg); src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c: sprintf(msg, "handshake failed - received >%s< - expected >%s<", b, hello); src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c: sprintf(buf, "%d", portNum); src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c: sprintf(ebuf, "ERROR: Peer not allowed to connect: %s\n", src/jdk.jdwp.agent/windows/native/libdt_socket/socket_md.c: sprintf(buf, "winsock error %d", error); src/jdk.jdwp.agent/windows/native/libjdwp/linker_md.c: sprintf(holder, "%s.dll", fname); ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11935 From joe.darcy at oracle.com Fri Jan 13 04:03:31 2023 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 12 Jan 2023 20:03:31 -0800 Subject: Difference in behaviour in native math library In-Reply-To: References: Message-ID: <502bd2d9-d64e-68e4-0bea-40c719a4190f@oracle.com> Hi Ludovic, Catching up on email, your understanding of my comments is correct. Since the relevant Java specification are agnostic towards what bits are in a NaN's significand, I don't think the Java implementations of this these methods should be updated to accommodate additional requirements for NaN handling used elsewhere. Thanks, -Joe On 12/8/2022 11:27 AM, Ludovic Henry wrote: > Hi Joe, > > I got an answer on the glibc mailing list, and the overall answer is > "it is the expected?behavior" [1]. > > From your answer, IIUC, you would want things to stand as-is, and it's > the test case that should be fixed, correct? > > Ludovic > > [1] > https://sourceware.org/pipermail/libc-alpha/2022-December/143912.html > > > On Thu, Dec 8, 2022 at 4:08 PM Joseph D. Darcy > wrote: > > > On 12/8/2022 10:01 AM, Ludovic Henry wrote: >> Hi, >> >> Yes, this is very much a difference of behavior at the libm/libc >> level. I'm trying to figure out whether that behavior difference >> is acceptable from the libm/libc level (is it considered a bug to >> behave differently across architectures in that case?). If that >> behaviour is acceptable in libm/libc, then is it acceptable to >> behave differently in Java across architectures? >> >> From your answer Palmer, the difference _might_ not be acceptable >> in the glibc test suite (I haven't check why the tests are >> failing). I'm still trying to figure that one out. >> >> From your answer Joe, the difference _is_ acceptable from the >> documentation. IMO the question becomes whether it's a case of >> the implementation details bleeding into the API and whether we >> want to be 100% compatible to avoid further issues. The fix for >> that could be a simple `RISCV_ONLY(if (isnan(v)) return v);` or >> equivalent in?src/java.base/share/native/libjava/StrictMath.c to >> match the behavior without any extra cost for other platforms. > > > I would not support changing the library native sources (or Java > sources) in this way to accommodate NaN handling. > > -Joe > >> >> Thanks, >> Ludovic >> >> On Thu, Dec 8, 2022 at 2:50 PM Palmer Dabbelt >> wrote: >> >> On Thu, 08 Dec 2022 08:26:30 PST (-0800), >> ludovic at rivosinc.com wrote: >> > Adding the right address for core-libs-dev. >> > >> > On Thu, Dec 8, 2022 at 12:19 PM Ludovic Henry >> wrote: >> > >> >> Hello, >> >> >> >> I've noticed that some Math trigonometry tests are failing >> in the GNU >> >> Mauve test suite. From digging into it, it's related to >> NaN values being >> >> passed to java.lang.Math trigonometry functions, and how >> these values are >> >> handled in the native libm library. >> >> >> >> Given the following C test case compiled and run with `gcc >> acos.c -lm && >> >> ./a.out` >> >> >> >> ``` >> >> #include >> >> #include >> >> #include >> >> #include >> >> >> >> void main(int argc, char* argv[]) { >> >>? ? ?int64_t bitsNaN = 0x7fff800000000000L; >> >>? ? ?double valNaN = *((double*)&bitsNaN); >> >> >> >>? ? ?double resD = acos(valNaN); >> >>? ? ?int64_t res = *((int64_t*)&resD); >> >>? ? ?if (!(res == bitsNaN)) { >> >>? ? ? ? ?printf("expected 0x%lx but got 0x%lx\n", bitsNaN, >> res); >> >>? ? ? ? ?exit(1); >> >>? ? ?} >> >> } >> >> ``` >> >> >> >> On a Linux-x64, the test succeeds, but on Linux-RISC-V, >> the test fails. >> >> >> >> You've the same test failure in the equivalent Java code: >> >> >> >> ``` >> >> public class acos { >> >>? ? ?public static void main (String[] args) { >> >>? ? ? ? ?long bitsNaN = 0x7fff800000000000L; >> >>? ? ? ? ?double valNaN = Double.longBitsToDouble(bitsNaN); >> >> >> >>? ? ? ? ?long res = >> Double.doubleToRawLongBits(Math.acos(valNaN)); >> >>? ? ? ? ?if (!(res == bitsNaN)) { >> >>? ? ? ? ? ? ?throw new >> RuntimeException(String.format("expected 0x%x but >> >> got 0x%x", bitsNaN, res)); >> >>? ? ? ? ?} >> >>? ? ?} >> >> } >> >> ``` >> >> >> >> What approach should we take in these cases? Is it that >> the test case is >> >> wrong, and should assume that given a NaN, any value of >> NaN returned is >> >> valid? Or should we make sure that the behavior is the >> same across >> >> platforms and that we "fix" any difference in behavior of >> the native >> >> library? >> >> It might just be a glibc bug, we're failing the acos() tests: >> https://sourceware.org/glibc/wiki/Release/2.35#RISC-V_.28rv64imafdc.2Flp64d.29 >> >> >> .? I haven't looked at why, but they do have some nan-related >> bits in >> there. >> >> >> >> >> Cheers, >> >> Ludovic >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Fri Jan 13 07:22:55 2023 From: duke at openjdk.org (Damon Fenacci) Date: Fri, 13 Jan 2023 07:22:55 GMT Subject: RFR: JDK-8293410: assert(ptr != top()) failed: top should go hand-in-hand with stopped Message-ID: The JVM crashes with an assertion failure when array range checks are disabled using `-XX:-GenerateRangeChecks` and we're trying to access the array with an index outside its boundaries. Such a behaviour is actually expected. What is unclear is the reason for having a _GenerateRangeChecks_ flag (basically to force not to perform range checks). An inspection of the change that introduced the flag didn't clarify its original use-case. So, removing the `GenerateRangeChecks` flag. ------------- Commit messages: - JDK-8293410: assert(ptr != top()) failed: top should go hand-in-hand with stopped Changes: https://git.openjdk.org/jdk/pull/11964/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11964&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293410 Stats: 9 lines in 3 files changed: 0 ins; 3 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/11964.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11964/head:pull/11964 PR: https://git.openjdk.org/jdk/pull/11964 From thartmann at openjdk.org Fri Jan 13 07:22:56 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 13 Jan 2023 07:22:56 GMT Subject: RFR: JDK-8293410: assert(ptr != top()) failed: top should go hand-in-hand with stopped In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 11:32:54 GMT, Damon Fenacci wrote: > The JVM crashes with an assertion failure when array range checks are disabled using `-XX:-GenerateRangeChecks` and we're trying to access the array with an index outside its boundaries. > > Such a behaviour is actually expected. What is unclear is the reason for having a _GenerateRangeChecks_ flag (basically to force not to perform range checks). An inspection of the change that introduced the flag didn't clarify its original use-case. > > So, removing the `GenerateRangeChecks` flag. Looks good to me! ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.org/jdk/pull/11964 From sspitsyn at openjdk.org Fri Jan 13 08:06:13 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 13 Jan 2023 08:06:13 GMT Subject: RFR: 8299635: More test issues for deprecated sprintf in Xcode 14 In-Reply-To: <7NTMxoOgPK0vqq-XGKI350AKnIjnA8_OYKzZLhLMLOc=.cd43cc7d-eff3-4046-989a-98173ee98500@github.com> References: <7NTMxoOgPK0vqq-XGKI350AKnIjnA8_OYKzZLhLMLOc=.cd43cc7d-eff3-4046-989a-98173ee98500@github.com> Message-ID: On Thu, 12 Jan 2023 07:25:07 GMT, Xue-Lei Andrew Fan wrote: >>> This PR does not address all the remaining sprintf:s in hotspot, and with it now explicitly forbidden the build will fail: >>> >> >> This is a question to me as well. I noticed there are still some use of sprintf, but the building passed on MacOS and Linux. I was wondering if the following update really work (if the '...' parameter works for the forbidden?), or something else matters. >> >> >> FORBID_C_FUNCTION(int sprintf(char*, const char*, ...), "use os::snprintf"); >> >> >>> I count ~30 sprintf:s that need updating. >>> >>> I'm also curious: some of the sprintfs are C2 (src/hotspot/share/opto) - are your builds including C2? If so, why are you not running into the issue for those files? >> >> I'm new to hotspot. Do you know how could I enable C2? Thanks! > >> > I'm also curious: some of the sprintfs are C2 (src/hotspot/share/opto) - are your builds including C2? If so, why are you not running into the issue for those files? >> >> I'm new to hotspot. Do you know how could I enable C2? Thanks! > > Never mind, I got it from configuration help message (use --with-jvm-features=compiler2). @XueleiFan Could you, please, do not integrate until more cases with the same problem are fixed? ------------- PR: https://git.openjdk.org/jdk/pull/11935 From chagedorn at openjdk.org Fri Jan 13 08:14:13 2023 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Fri, 13 Jan 2023 08:14:13 GMT Subject: RFR: JDK-8293410: Remove GenerateRangeChecks flag In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 11:32:54 GMT, Damon Fenacci wrote: > The JVM crashes with an assertion failure when array range checks are disabled using `-XX:-GenerateRangeChecks` and we're trying to access the array with an index outside its boundaries. > > Such a behaviour is actually expected. What is unclear is the reason for having a _GenerateRangeChecks_ flag (basically to force not to perform range checks). An inspection of the change that introduced the flag didn't clarify its original use-case. > > So, removing the `GenerateRangeChecks` flag. Looks good! ------------- Marked as reviewed by chagedorn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11964 From sspitsyn at openjdk.org Fri Jan 13 08:18:17 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 13 Jan 2023 08:18:17 GMT Subject: RFR: 8299635: More test issues for deprecated sprintf in Xcode 14 In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 06:26:18 GMT, Xue-Lei Andrew Fan wrote: > The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. > > This patch is trying to find the use of sprintf in test cases, and replace it with snprintf accordingly. More cases with the same issue were found. ------------- Changes requested by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11935 From tschatzl at openjdk.org Fri Jan 13 08:41:16 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 13 Jan 2023 08:41:16 GMT Subject: RFR: JDK-8299971: Remove metaprogramming/conditional.hpp In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 14:44:11 GMT, Justin King wrote: > Code cleanup of pre-C++11 implementations. Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11946 From tschatzl at openjdk.org Fri Jan 13 08:42:15 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 13 Jan 2023 08:42:15 GMT Subject: RFR: JDK-8299972: Remove metaprogramming/removeReference.hpp In-Reply-To: <2b-IgAfCtFcOvvzUnSIRop-HS2jQZk-ey6owacyEz6o=.b690ff0e-170c-4185-8f72-b16e4c67dec0@github.com> References: <2b-IgAfCtFcOvvzUnSIRop-HS2jQZk-ey6owacyEz6o=.b690ff0e-170c-4185-8f72-b16e4c67dec0@github.com> Message-ID: On Wed, 11 Jan 2023 14:51:15 GMT, Justin King wrote: > Code cleanup of pre-C++11 implementations. Looks good and trivial code removal. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.org/jdk/pull/11947 From xuelei at openjdk.org Fri Jan 13 08:45:16 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 13 Jan 2023 08:45:16 GMT Subject: RFR: 8299635: More test issues for deprecated sprintf in Xcode 14 In-Reply-To: <7NTMxoOgPK0vqq-XGKI350AKnIjnA8_OYKzZLhLMLOc=.cd43cc7d-eff3-4046-989a-98173ee98500@github.com> References: <7NTMxoOgPK0vqq-XGKI350AKnIjnA8_OYKzZLhLMLOc=.cd43cc7d-eff3-4046-989a-98173ee98500@github.com> Message-ID: <831CK10pKtyMvjCIInY9jDxfXiLD68orvfLXhm6koRs=.d1b87cbc-0969-4d1a-a3c5-48c00a60a754@github.com> On Thu, 12 Jan 2023 07:25:07 GMT, Xue-Lei Andrew Fan wrote: >>> This PR does not address all the remaining sprintf:s in hotspot, and with it now explicitly forbidden the build will fail: >>> >> >> This is a question to me as well. I noticed there are still some use of sprintf, but the building passed on MacOS and Linux. I was wondering if the following update really work (if the '...' parameter works for the forbidden?), or something else matters. >> >> >> FORBID_C_FUNCTION(int sprintf(char*, const char*, ...), "use os::snprintf"); >> >> >>> I count ~30 sprintf:s that need updating. >>> >>> I'm also curious: some of the sprintfs are C2 (src/hotspot/share/opto) - are your builds including C2? If so, why are you not running into the issue for those files? >> >> I'm new to hotspot. Do you know how could I enable C2? Thanks! > >> > I'm also curious: some of the sprintfs are C2 (src/hotspot/share/opto) - are your builds including C2? If so, why are you not running into the issue for those files? >> >> I'm new to hotspot. Do you know how could I enable C2? Thanks! > > Never mind, I got it from configuration help message (use --with-jvm-features=compiler2). > @XueleiFan Could you, please, do not integrate until more cases with the same problem are fixed? Sure. That's on my plan. I am trying to figure out how to get these files included in the building. My build passed on MacOS and Linux, even with C2 enabled. The update on test may be different from src update. I may divide the fix into two PRs, if I figure out how to build the missing uses of sprintf:s. Thank for for the feedback. I appreciated it. ------------- PR: https://git.openjdk.org/jdk/pull/11935 From kbarrett at openjdk.org Fri Jan 13 09:27:13 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 13 Jan 2023 09:27:13 GMT Subject: RFR: JDK-8300080: offset_of for GCC/Clang exhibits undefined behavior and is not always a compile-time constant In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 20:28:50 GMT, Justin King wrote: > The implementation of `offset_of` for GCC/Clang only deals with types are aligned to 16 bytes or less, if they are more, such as `zCollectedHeap` the behavior is undefined. UBSan also suggests that `offset_of` is not always a compile time constant, as the stack trace came from the dynamic loader during library loading. This patch changes `offset_of` to use `offsetof` and disables the warning `invalid-offsetof` for the JVM. Please don't make this change. We are intentionally not using offsetof. See JDK-8239357. A change to the existing code would be to use `alignof(klass)` to align the space buffer, once use of `alignof` is approved. That would fix the alignment problem. ------------- PR: https://git.openjdk.org/jdk/pull/11978 From kbarrett at openjdk.org Fri Jan 13 09:31:16 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 13 Jan 2023 09:31:16 GMT Subject: RFR: JDK-8300080: offset_of for GCC/Clang exhibits undefined behavior and is not always a compile-time constant In-Reply-To: References: Message-ID: <2V21MwM9m2hahe27IKlpEmcUklH2ITD-pgX8Gnla3uY=.c78cd923-f58f-4c78-bbea-8fa9b1069497@github.com> On Thu, 12 Jan 2023 20:28:50 GMT, Justin King wrote: > The implementation of `offset_of` for GCC/Clang only deals with types are aligned to 16 bytes or less, if they are more, such as `zCollectedHeap` the behavior is undefined. UBSan also suggests that `offset_of` is not always a compile time constant, as the stack trace came from the dynamic loader during library loading. This patch changes `offset_of` to use `offsetof` and disables the warning `invalid-offsetof` for the JVM. Also, the FIXME comment added by JDK-8294902 suggesting using `offsetof` should be removed. ------------- PR: https://git.openjdk.org/jdk/pull/11978 From kbarrett at openjdk.org Fri Jan 13 09:43:13 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 13 Jan 2023 09:43:13 GMT Subject: RFR: JDK-8300080: offset_of for GCC/Clang exhibits undefined behavior and is not always a compile-time constant In-Reply-To: <6PF63HtQHJCGi4aTX7WhUCcmPFWmWa7gBJJRQms8q4M=.9d081701-a7df-48c6-9d8b-961525613afc@github.com> References: <6PF63HtQHJCGi4aTX7WhUCcmPFWmWa7gBJJRQms8q4M=.9d081701-a7df-48c6-9d8b-961525613afc@github.com> Message-ID: On Thu, 12 Jan 2023 20:36:31 GMT, Justin King wrote: >> The implementation of `offset_of` for GCC/Clang only deals with types are aligned to 16 bytes or less, if they are more, such as `zCollectedHeap` the behavior is undefined. UBSan also suggests that `offset_of` is not always a compile time constant, as the stack trace came from the dynamic loader during library loading. This patch changes `offset_of` to use `offsetof` and disables the warning `invalid-offsetof` for the JVM. > > @aph FYI undoes `offset_of` change from JDK-8294902 Also @jcking , please always assign a subcompent for hotspot bugs in JBS. I moved this one to the runtime subcomponent. ------------- PR: https://git.openjdk.org/jdk/pull/11978 From kbarrett at openjdk.org Fri Jan 13 09:54:20 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 13 Jan 2023 09:54:20 GMT Subject: RFR: JDK-8299971: Remove metaprogramming/conditional.hpp In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 14:44:11 GMT, Justin King wrote: > Code cleanup of pre-C++11 implementations. Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/11946 From kbarrett at openjdk.org Fri Jan 13 09:56:13 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 13 Jan 2023 09:56:13 GMT Subject: RFR: JDK-8299972: Remove metaprogramming/removeReference.hpp In-Reply-To: <2b-IgAfCtFcOvvzUnSIRop-HS2jQZk-ey6owacyEz6o=.b690ff0e-170c-4185-8f72-b16e4c67dec0@github.com> References: <2b-IgAfCtFcOvvzUnSIRop-HS2jQZk-ey6owacyEz6o=.b690ff0e-170c-4185-8f72-b16e4c67dec0@github.com> Message-ID: On Wed, 11 Jan 2023 14:51:15 GMT, Justin King wrote: > Code cleanup of pre-C++11 implementations. Looks good and trivial. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/11947 From duke at openjdk.org Fri Jan 13 11:18:18 2023 From: duke at openjdk.org (Afshin Zafari) Date: Fri, 13 Jan 2023 11:18:18 GMT Subject: RFR: 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug [v5] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 09:42:19 GMT, Afshin Zafari wrote: >> ### Description >> The following problems found and solved: >> >> 1) Reporting which regex pattern did not match with error messages was incorrect. To report the mismatched pattern, the head of the pattern list was peeked, while it was the already peeked item from that did not match. So the next pattern to the mismatched one was reported. >> >> 2) The pattern for finding a crash was incorrectly set to "# .*VMError::controlled_crash.*", while it has to be "# .*crash_with_segfault.*". >> >> 3) `crash_with_segfault` function is too small and was `inline`d in compiler optimisations. So it was not in the stack trace when the error message is created. >> >> ### Patch >> 1 and 2 corrected and added the `NOINLINE` to the `crash_with_segfault` signature. The same applied for `crash_with_sigfpe` function. >> >> ### Test >> runtime/ErrorHandling/* and tier1-5 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug Copyright years are backed to 2022. ------------- PR: https://git.openjdk.org/jdk/pull/11704 From jvernee at openjdk.org Fri Jan 13 11:33:14 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 13 Jan 2023 11:33:14 GMT Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory API (Preview) [v5] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 15:15:23 GMT, Feilong Jiang wrote: >> Add experimental Foreign Function & Memory API support for RISC-V. >> >> For details of the FFM API RISC-V port please refer to [JBS issue](https://bugs.openjdk.org/browse/JDK-8293841) >> >> Testing: >> >> - [x] jdk_foreign with release/fastdebug build on linux-riscv64 >> - [x] jdk_foreign with release/fastdebug build on linux-x64 >> - [x] jdk_foreign with release/fastdebug build on linux-aarch64 > > Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision: > > fix callArranger Excellent. No Comments. I am running some sanity testing on our CI, and will approve when it comes back green. ------------- PR: https://git.openjdk.org/jdk/pull/11004 From eosterlund at openjdk.org Fri Jan 13 12:51:32 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 13 Jan 2023 12:51:32 GMT Subject: Integrated: 8299032: Interface IN_NATIVE oop stores for C2 In-Reply-To: <61HZ-hCw_ZoDZCtsDLsz-tfPE6S7Ox_1nXApLQnZ1SU=.60c813cf-a5d8-4a3c-a2a1-86d7af05d042@github.com> References: <61HZ-hCw_ZoDZCtsDLsz-tfPE6S7Ox_1nXApLQnZ1SU=.60c813cf-a5d8-4a3c-a2a1-86d7af05d042@github.com> Message-ID: On Fri, 23 Dec 2022 13:54:44 GMT, Erik ?sterlund wrote: > Loom added the first IN_NATIVE oop store to C2 code, when switching the current virtual thread of a platform thread. Instead of interfacing this properly, a raw store was used. But a future GC algorithm, such as generational ZGC, might not work well with raw stores. We should add support to the access API for this. Looks like Shenandoah was already missing something here as they do concurrent root processing requiring SATB barriers on IN_NATIVE oop stores. It is not in the scope of this PR to fix the Shenandoah bug - someone working on Shenandoah should do this. This PR merely adds an interface such that GCs that need to do something different here, can do that. Serial, Parallel and G1 don't need to do anything for IN_NATIVE stores as they do STW root processing. ZGC doesn't (yet) have store barriers at all, and hence doesn't need to do anything special either. This pull request has now been integrated. Changeset: e7fa150b Author: Erik ?sterlund URL: https://git.openjdk.org/jdk/commit/e7fa150bc15b1bf5ab8921bfdf1a628ae08f5624 Stats: 8 lines in 2 files changed: 0 ins; 7 del; 1 mod 8299032: Interface IN_NATIVE oop stores for C2 Reviewed-by: stefank, rcastanedalo ------------- PR: https://git.openjdk.org/jdk/pull/11777 From jcking at openjdk.org Fri Jan 13 14:40:15 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 13 Jan 2023 14:40:15 GMT Subject: RFR: JDK-8300080: offset_of for GCC/Clang exhibits undefined behavior and is not always a compile-time constant In-Reply-To: References: Message-ID: <3W9odCGw246_RJmL2Xo3TuZnZtCALonws_SykOrJaCY=.f701e500-dc53-4386-a85e-83c17ce7e6d0@github.com> On Thu, 12 Jan 2023 20:28:50 GMT, Justin King wrote: > The implementation of `offset_of` for GCC/Clang only deals with types are aligned to 16 bytes or less, if they are more, such as `zCollectedHeap` the behavior is undefined. UBSan also suggests that `offset_of` is not always a compile time constant, as the stack trace came from the dynamic loader during library loading. This patch changes `offset_of` to use `offsetof` and disables the warning `invalid-offsetof` for the JVM. I read JDK-8239357 and related information. I am not sure I understand why `offsetof` is being avoided given that C++17 shifted the behavior to be `conditionally-supported`. `conditionally-supported` is a nice way of saying it's up to the compiler on whether it gives meaningful answers or fails to compile. All compilers I am aware of give meaningful answers. Were going to have to agree to disagree on the rationale of not using `offsetof`, but it appears Clang/GCC optimize it nicely at least in isolation. Looking at godbolt, the current definition of `offset_of` produces some horrific assembly without optimizations. Thankfully with `-O2` it boils down to a constant. I am guessing UBSan prevents the optimization so it can instrument it, or rather it instruments it making it unable to optimize it. Perhaps we should apply `ALWAYSINLINE` to the lambda to get better results regardless of build mode and use `alignas` now due to `std::aligned_storage_t` being deprecated in C++23? ------------- PR: https://git.openjdk.org/jdk/pull/11978 From jcking at openjdk.org Fri Jan 13 14:52:39 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 13 Jan 2023 14:52:39 GMT Subject: RFR: JDK-8300080: offset_of for GCC/Clang exhibits undefined behavior and is not always a compile-time constant [v2] In-Reply-To: References: Message-ID: > The implementation of `offset_of` for GCC/Clang only deals with types are aligned to 16 bytes or less, if they are more, such as `zCollectedHeap` the behavior is undefined. UBSan also suggests that `offset_of` is not always a compile time constant, as the stack trace came from the dynamic loader during library loading. This patch changes `offset_of` to use `offsetof` and disables the warning `invalid-offsetof` for the JVM. Justin King has updated the pull request incrementally with one additional commit since the last revision: Revert offset_of change, use alignas, and force lambda inline Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11978/files - new: https://git.openjdk.org/jdk/pull/11978/files/98c9ea24..3f46a86b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11978&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11978&range=00-01 Stats: 15 lines in 2 files changed: 11 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11978.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11978/head:pull/11978 PR: https://git.openjdk.org/jdk/pull/11978 From jcking at openjdk.org Fri Jan 13 14:52:41 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 13 Jan 2023 14:52:41 GMT Subject: RFR: JDK-8300080: offset_of for GCC/Clang exhibits undefined behavior and is not always a compile-time constant In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 20:28:50 GMT, Justin King wrote: > The implementation of `offset_of` for GCC/Clang only deals with types are aligned to 16 bytes or less, if they are more, such as `zCollectedHeap` the behavior is undefined. UBSan also suggests that `offset_of` is not always a compile time constant, as the stack trace came from the dynamic loader during library loading. This patch changes `offset_of` to use `offsetof` and disables the warning `invalid-offsetof` for the JVM. I reverted `offset_of` back, added `alignas`, and added `__attribute__((always_inline))` to force GCC/Clang to produce a constant regardless of build options. ------------- PR: https://git.openjdk.org/jdk/pull/11978 From jcking at openjdk.org Fri Jan 13 14:56:44 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 13 Jan 2023 14:56:44 GMT Subject: RFR: JDK-8300080: offset_of for GCC/Clang exhibits undefined behavior and is not always a compile-time constant [v3] In-Reply-To: References: Message-ID: > The implementation of `offset_of` for GCC/Clang only deals with types are aligned to 16 bytes or less, if they are more, such as `zCollectedHeap` the behavior is undefined. UBSan also suggests that `offset_of` is not always a compile time constant, as the stack trace came from the dynamic loader during library loading. This patch changes `offset_of` to use `offsetof` and disables the warning `invalid-offsetof` for the JVM. Justin King has updated the pull request incrementally with one additional commit since the last revision: Use parenthesis Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11978/files - new: https://git.openjdk.org/jdk/pull/11978/files/3f46a86b..8d0b73c8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11978&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11978&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11978.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11978/head:pull/11978 PR: https://git.openjdk.org/jdk/pull/11978 From gziemski at openjdk.org Fri Jan 13 15:42:18 2023 From: gziemski at openjdk.org (Gerard Ziemski) Date: Fri, 13 Jan 2023 15:42:18 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v2] In-Reply-To: References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> Message-ID: On Tue, 6 Dec 2022 07:07:33 GMT, Thomas Stuefe wrote: >> Rework NMT `MallocLimit` to make it more useful for native OOM analysis. Also remove `MallocMaxTestWords`, which had been mostly redundant with NMT (for background, see JDK-8293292). >> >> >> ### Background >> >> Some months ago we had [JDK-8291919](https://bugs.openjdk.org/browse/JDK-8291919), a compiler regression that caused compiler arenas to grow boundlessly. Process was usually OOM-killed before we could take a look, so this was difficult to analyze. >> >> To improve analysis options, we added NMT *malloc limits* with [JDK-8291878](https://bugs.openjdk.org/browse/JDK-8291878). Malloc limits let us set one or multiple limits to malloc load. Surpassing a limit causes the VM to stop with a fatal error in the allocation function, giving us a hs-err file and a core right at the point that (probably) causes the leak. This makes error analysis a lot simpler, and is also valuable for regression-testing footprint usage. >> >> Some people wished for a way to not end with a fatal error but to mimic a native OOM (causing os::malloc to return NULL). This would allow us to test resilience in the face of native OOMs, among other things. >> >> ### Patch >> >> - Expands the `MallocLimit` option syntax, allowing for an "oom mode" that mimics an oom: >> >> >> >> Global form: >> -XX:MallocLimit=[:] >> Category-specific form: >> -XX:MallocLimit=:[:][,:[:] ...] >> Examples: >> -XX:MallocLimit=3g >> -XX:MallocLimit=3g:oom >> -XX:MallocLimit=compiler:200m:oom >> >> >> - moves parsing of `-XX:MallocLimit` out of arguments.cpp into `mallocLimit.hpp/cpp`, and rewrites it. >> >> - changes when limits are checked. Before, the limits were checked *after* the allocation that caused the threshold overflow. Now we check beforehand. >> >> - removes `MallocMaxTestWords`, replacing its uses with `MallocLimit` >> >> - adds new gtests and new jtreg tests >> >> - removes a bunch of jtreg tests which are now better served by the new gtests. >> >> - gives us more precise error messages upon reaching a limit. For example: >> >> before: >> >> # fatal error: MallocLimit: category "Compiler" reached limit (size: 20997680, limit: 20971520) >> >> >> now: >> >> # fatal error: MallocLimit: reached category "Compiler" limit (triggering allocation size: 1920B, allocated so far: 20505K, limit: 20480K) > > 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 two additional commits since the last revision: > > - Merge branch 'master' into JDK-8293313-NMT-fake-oom > - MallocLimit Just FYI I'm taking a look at this... ------------- PR: https://git.openjdk.org/jdk/pull/11371 From jcking at openjdk.org Fri Jan 13 16:06:44 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 13 Jan 2023 16:06:44 GMT Subject: RFR: JDK-8300080: offset_of for GCC/Clang exhibits undefined behavior and is not always a compile-time constant [v4] In-Reply-To: References: Message-ID: > The implementation of `offset_of` for GCC/Clang only deals with types are aligned to 16 bytes or less, if they are more, such as `zCollectedHeap` the behavior is undefined. UBSan also suggests that `offset_of` is not always a compile time constant, as the stack trace came from the dynamic loader during library loading. This patch changes `offset_of` to use `offsetof` and disables the warning `invalid-offsetof` for the JVM. Justin King has updated the pull request incrementally with one additional commit since the last revision: Move attribute on lambda to correct location Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11978/files - new: https://git.openjdk.org/jdk/pull/11978/files/8d0b73c8..2d2f7528 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11978&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11978&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11978.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11978/head:pull/11978 PR: https://git.openjdk.org/jdk/pull/11978 From jcking at openjdk.org Fri Jan 13 16:19:51 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 13 Jan 2023 16:19:51 GMT Subject: RFR: JDK-8299688: Adopt C++14 compatible std::bit_cast introduced in C++20 [v4] In-Reply-To: References: Message-ID: > Adopts a C++14 compatible implementation of [std::bit_cast](https://en.cppreference.com/w/cpp/numeric/bit_cast). > > `PrimitiveConversions::cast` is refactored into `bit_cast` and extended to support all compatible types. Additionally it makes use of `__builtin_bit_cast` when available, which is strictly well defined compared to fallback approaches which are sometimes lurking in undefined behavior territory. > > Lastly some legacy casting is updated to use `bit_cast` in `utilities/globalDefinitions.hpp`. Justin King has updated the pull request incrementally with one additional commit since the last revision: Remove addressof as nobody should be overloading operator& Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11865/files - new: https://git.openjdk.org/jdk/pull/11865/files/e5921255..ccb8f280 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11865&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11865&range=02-03 Stats: 24 lines in 2 files changed: 0 ins; 20 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11865.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11865/head:pull/11865 PR: https://git.openjdk.org/jdk/pull/11865 From eosterlund at openjdk.org Fri Jan 13 16:22:17 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 13 Jan 2023 16:22:17 GMT Subject: RFR: 8299673: Simplify object pinning interactions with string deduplication In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 04:43:54 GMT, Kim Barrett wrote: >> When raw char* String contents are exposed to JNI code, we >> >> 1. Load the string.value and pin it >> 2. Run native code >> 3. Load the string.value and unpin it >> >> Given this sequence we would be in trouble if between 1 and 3, string deduplication changed the value object. Then the pinning and unpinning wouldn't be balanced. >> >> The current approach for dealing with this is to have a bunch of code to guard against deduplication. An alternative simpler solution is to just change step 3 to pass in the same value. We already have enough information available to do that. Then the pinning and unpinning is also balanced, and we don't need to have any special interactions with string deduplication and can decouple these orthogonal concerns. >> >> It's worth noting though that the contract of pin_object now makes it explicit that pinned objects must not be recycled, even if not otherwise reachable. That seems to come naturally for region based pinning, but is worth keeping in mind. The exposed char* might be the only thing referencing the string value when string dedup happens concurrently. > > Looks good. Thank you for the reviews, @kimbarrett and @stefank! ------------- PR: https://git.openjdk.org/jdk/pull/11923 From coleenp at openjdk.org Fri Jan 13 16:51:22 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 13 Jan 2023 16:51:22 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v2] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 09:22:03 GMT, Fredrik Bredberg wrote: >> Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. >> Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. >> Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > Updated some copyright dates. This looks great. Very nice work! src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 306: > 304: // set relativized locals > 305: // this line can be changed into an assert when we have fixed the "frame padding problem" > 306: *f.addr_at(frame::interpreter_frame_locals_offset) = (bottom - 1) - f.fp(); Thank you for this comment. When you file the CR for this problem, can you point to this CR? src/hotspot/cpu/ppc/continuationFreezeThaw_ppc.inline.hpp line 554: > 552: inline void ThawBase::set_interpreter_frame_bottom(const frame& f, intptr_t* bottom) { > 553: // set relativized locals > 554: // this line can be changed into an assert when we have fixed the "frame padding problem" Can you file an RFE (or is there already one) to describe this? ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/11902 From ayang at openjdk.org Fri Jan 13 16:53:32 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 13 Jan 2023 16:53:32 GMT Subject: RFR: 8300054: Use static_assert in basic_types_init [v2] In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 17:10:36 GMT, Albert Mingkun Yang wrote: >> Simple change to use `static_assert` when applicable inside a function. > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Thanks for the review. ------------- PR: https://git.openjdk.org/jdk/pull/11971 From ayang at openjdk.org Fri Jan 13 16:53:35 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 13 Jan 2023 16:53:35 GMT Subject: Integrated: 8300054: Use static_assert in basic_types_init In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 16:17:49 GMT, Albert Mingkun Yang wrote: > Simple change to use `static_assert` when applicable inside a function. This pull request has now been integrated. Changeset: d1179795 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/d1179795031ec1429850e2f835fc2abf173ac35a Stats: 32 lines in 1 file changed: 0 ins; 0 del; 32 mod 8300054: Use static_assert in basic_types_init Reviewed-by: stefank, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/11971 From rkennke at openjdk.org Fri Jan 13 17:11:39 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 13 Jan 2023 17:11:39 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v10] In-Reply-To: References: Message-ID: <-EX0igd2_yCwNm8NyWtuQ6ctvEx-4uLQnuYQIuMTvBg=.1f40f533-e839-456a-936c-772ee2a922cf@github.com> > See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details. > > Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements. > > Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16. > > Testing: > - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390) > - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390) > - [x] tier1 (x86_64, x86_32, aarch64, riscv) > - [x] tier2 (x86_64, aarch64, riscv) > - [x] tier3 (x86_64, riscv) Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Fix gtest for correct base offsets in 32bit builds ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11044/files - new: https://git.openjdk.org/jdk/pull/11044/files/b12d99cc..3fb59330 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=08-09 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/11044.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11044/head:pull/11044 PR: https://git.openjdk.org/jdk/pull/11044 From jcking at openjdk.org Fri Jan 13 17:39:41 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 13 Jan 2023 17:39:41 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v8] In-Reply-To: References: Message-ID: > Remove abstraction that is a holdover from Solaris. Direct usages of `MmapArrayAllocator` have been switched to normal `malloc`. The justification is that none of the code paths are called from signal handlers, so using `mmap` directly does not make sense and is potentially slower than going through `malloc` which can potentially re-use memory without making any system calls. The remaining usages of `ArrayAllocator` and `MallocArrayAllocator` are equivalent. Justin King has updated the pull request incrementally with one additional commit since the last revision: Apply patch from stefank@ Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11931/files - new: https://git.openjdk.org/jdk/pull/11931/files/5d30170a..4aba784e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=06-07 Stats: 10 lines in 1 file changed: 3 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/11931.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11931/head:pull/11931 PR: https://git.openjdk.org/jdk/pull/11931 From jcking at openjdk.org Fri Jan 13 17:39:43 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 13 Jan 2023 17:39:43 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v4] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 15:08:23 GMT, Stefan Karlsson wrote: >>> I'm happy to see this flag getting removed. I'm less happy about seeing usages of the array allocators being replaced by macros. I'd rather see an effort towards getting rid of these macros. Could we limit this patch to only remove the ArrayAllocatorMallocLimit flag and ArrayAllocator class, and defer the discussion around what API to use for array allocations? >> >> `ArrayAllocator` with `ArrayAllocatorMallocLimit` removed is effectively `MallocArrayAllocator`. Are you suggesting leaving `MallocArrayAllocator` and `MmapArrayAllocator` thus update references to `ArrayAllocator` to be `MallocArrayAllocator`? >> >> As far as APIs, the majority of the codebase uses the macros. IMO consistency would be better and having two ways of doing things doesn't help. But if you feel strongly about it, we can punt and just surgically remove the bare minimum, assuming you clarify your expectation (see above). > >> ArrayAllocator with ArrayAllocatorMallocLimit removed is effectively MallocArrayAllocator. Are you suggesting leaving MallocArrayAllocator and MmapArrayAllocator thus update references to ArrayAllocator to be MallocArrayAllocator? > > Yes, that was what I wanted. > >> As far as APIs, the majority of the codebase uses the macros. IMO consistency would be better and having two ways of doing things doesn't help. But if you feel strongly about it, we can punt and just surgically remove the bare minimum, assuming you clarify your expectation (see above). > > I agree about the argument about consistency, so I retract my objection. We can deal with these macros as a separate RFE (if we ever get to it). > > I would like to retain the usage of mmapped memory for ZGC to minimize the risk of any surprises for us. ZGC code also tend to initialize as much as possible in the initialization list, so the extra memset that comes after initialization lists sticks out a bit. Could you create a private `ZGranuleMap::allocate_array` function that uses os::reserve_memory/commmit_memory and change the code to be: > > inline ZGranuleMap::ZGranuleMap(size_t max_offset) : > _size(max_offset >> ZGranuleSizeShift), > _map(allocate_array(_size)) { > > > Or if you like, I can provide a patch on top of your branch to do that. Applied your patch @stefank ------------- PR: https://git.openjdk.org/jdk/pull/11931 From jcking at openjdk.org Fri Jan 13 17:50:52 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 13 Jan 2023 17:50:52 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v8] In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 17:39:41 GMT, Justin King wrote: >> Remove abstraction that is a holdover from Solaris. Direct usages of `MmapArrayAllocator` have been switched to normal `malloc`. The justification is that none of the code paths are called from signal handlers, so using `mmap` directly does not make sense and is potentially slower than going through `malloc` which can potentially re-use memory without making any system calls. The remaining usages of `ArrayAllocator` and `MallocArrayAllocator` are equivalent. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Apply patch from stefank@ > > Signed-off-by: Justin King Restored `mmap` for G1, though in the future it might make sense to switch to just using malloc. ------------- PR: https://git.openjdk.org/jdk/pull/11931 From jcking at openjdk.org Fri Jan 13 17:50:50 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 13 Jan 2023 17:50:50 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v9] In-Reply-To: References: Message-ID: > Remove abstraction that is a holdover from Solaris. Direct usages of `MmapArrayAllocator` have been switched to normal `malloc`. The justification is that none of the code paths are called from signal handlers, so using `mmap` directly does not make sense and is potentially slower than going through `malloc` which can potentially re-use memory without making any system calls. The remaining usages of `ArrayAllocator` and `MallocArrayAllocator` are equivalent. Justin King has updated the pull request incrementally with two additional commits since the last revision: - Fix compilation error Signed-off-by: Justin King - Preserve mmap usage in gc/g1/g1ConcurrentMark Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11931/files - new: https://git.openjdk.org/jdk/pull/11931/files/4aba784e..4b5ce84b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=07-08 Stats: 33 lines in 2 files changed: 30 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11931.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11931/head:pull/11931 PR: https://git.openjdk.org/jdk/pull/11931 From kvn at openjdk.org Fri Jan 13 18:32:15 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 13 Jan 2023 18:32:15 GMT Subject: RFR: JDK-8293410: Remove GenerateRangeChecks flag In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 11:32:54 GMT, Damon Fenacci wrote: > The JVM crashes with an assertion failure when array range checks are disabled using `-XX:-GenerateRangeChecks` and we're trying to access the array with an index outside its boundaries. > > Such a behaviour is actually expected. What is unclear is the reason for having a _GenerateRangeChecks_ flag (basically to force not to perform range checks). An inspection of the change that introduced the flag didn't clarify its original use-case. > > So, removing the `GenerateRangeChecks` flag. This flag (and some others) was added for debugging purpose when range check code was introduced. Change looks good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11964 From ccheung at openjdk.org Fri Jan 13 18:42:16 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 13 Jan 2023 18:42:16 GMT Subject: RFR: 8297914: Remove java_lang_Class::process_archived_mirror() [v2] In-Reply-To: References: Message-ID: <8aR1ZM5vJ1xZWWbzOQChM_jQA1mSnR29py105guxQyg=.2267d8b2-0e3f-47a5-8527-70ff54b9875d@github.com> On Thu, 12 Jan 2023 19:14:44 GMT, Ioi Lam wrote: >> This is another prerequisite for [JDK-8296344](https://bugs.openjdk.org/browse/JDK-8296344). >> >> Before this PR, when archiving mirror objects (i.e., instances of `java.lang.Class`): >> - We first allocate a copy of the mirror inside a safepoint. >> - We then reinitialize the contents of the copy to the desired state (so that it can be used by `Klass::restore_unshareable_info()` >> >> This copy-and-modify operation inside the safepoint makes it difficult to implement [JDK-8296344](https://bugs.openjdk.org/browse/JDK-8296344). It violates the requirements [1] and [2] as stated in [JDK-8298600](https://bugs.openjdk.org/browse/JDK-8298600). Also, the reinitialization code is complicated. >> >> After this PR: >> - During the creation of each regular mirror object, we allocate a "scratch mirror" object, which has the states as expected by `Klass::restore_unshareable_info()`. See `java_lang_Class::create_scratch_mirror()`. >> - When the archive heap is dumped inside a safepoint, we use the scratch mirror, so we can avoid the copy-and-modify operation. See `HeapShared::archive_java_mirrors()`. >> >> Testing: tiers 1-4 > > Ioi Lam has updated the pull request incrementally with three additional commits since the last revision: > > - review comments from @ashu-mehra and @dholmes-ora > - fixed repo > - tmp I have one question. src/hotspot/share/oops/objArrayKlass.cpp line 442: > 440: } > 441: } > 442: #endif When will the above function be called? >From `ClassLoaderData::free_deallocate_list()` // Cast them so they can be used by the template function. if (m->is_method()) { MetadataFactory::free_metadata(this, (Method*)m); } else if (m->is_constantPool()) { MetadataFactory::free_metadata(this, (ConstantPool*)m); } else if (m->is_klass()) { MetadataFactory::free_metadata(this, (InstanceKlass*)m); } else { ShouldNotReachHere(); } `free_metadata` will call `deallocate_contents` but I don't see how it will call the` ObjectArrayKlass` version. ------------- PR: https://git.openjdk.org/jdk/pull/11853 From skuksenko at openjdk.org Fri Jan 13 18:59:17 2023 From: skuksenko at openjdk.org (Sergey Kuksenko) Date: Fri, 13 Jan 2023 18:59:17 GMT Subject: RFR: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions In-Reply-To: References: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> Message-ID: On Thu, 12 Jan 2023 06:08:53 GMT, Erik ?sterlund wrote: >> 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions > > src/hotspot/share/opto/bytecodeInfo.cpp line 183: > >> 181: // Not hot. Check for medium-sized pre-existing nmethod at cold sites. >> 182: if (callee_method->has_compiled_code() && >> 183: callee_method->inline_instructions_size() > inline_small_code_size) { > > I do have to wonder if the actual problem is that this method is considered not hot by the InlineFrequenceRatio heuristic above. We are in the else clause and there is a comment saying this isn't hot. But obviously it was. Your approach tweaks the not hot path to still allow inlining, but I do wonder if it's the hot method detection scheme that could need some love. Just a thought... It's not hot (by C2 meaning way). But if non-inlining causes 2x times performance regression -> that is a "hot" by performance meaning. Here is the key issue - methods became non-inlined by "already compiled to large/medium method". But it happened only because noop instructions were added. Common sense says that adding noops shouldn't change inline decisions. ------------- PR: https://git.openjdk.org/jdk/pull/11958 From iklam at openjdk.org Fri Jan 13 19:00:40 2023 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 13 Jan 2023 19:00:40 GMT Subject: RFR: 8297914: Remove java_lang_Class::process_archived_mirror() [v3] In-Reply-To: References: Message-ID: > This is another prerequisite for [JDK-8296344](https://bugs.openjdk.org/browse/JDK-8296344). > > Before this PR, when archiving mirror objects (i.e., instances of `java.lang.Class`): > - We first allocate a copy of the mirror inside a safepoint. > - We then reinitialize the contents of the copy to the desired state (so that it can be used by `Klass::restore_unshareable_info()` > > This copy-and-modify operation inside the safepoint makes it difficult to implement [JDK-8296344](https://bugs.openjdk.org/browse/JDK-8296344). It violates the requirements [1] and [2] as stated in [JDK-8298600](https://bugs.openjdk.org/browse/JDK-8298600). Also, the reinitialization code is complicated. > > After this PR: > - During the creation of each regular mirror object, we allocate a "scratch mirror" object, which has the states as expected by `Klass::restore_unshareable_info()`. See `java_lang_Class::create_scratch_mirror()`. > - When the archive heap is dumped inside a safepoint, we use the scratch mirror, so we can avoid the copy-and-modify operation. See `HeapShared::archive_java_mirrors()`. > > Testing: tiers 1-4 Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @calvinccheung comment - removed unnecessary ObjArrayKlass::deallocate_contents ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11853/files - new: https://git.openjdk.org/jdk/pull/11853/files/0fba1448..c1460a4c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11853&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11853&range=01-02 Stats: 15 lines in 2 files changed: 0 ins; 13 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11853.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11853/head:pull/11853 PR: https://git.openjdk.org/jdk/pull/11853 From iklam at openjdk.org Fri Jan 13 19:00:44 2023 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 13 Jan 2023 19:00:44 GMT Subject: RFR: 8297914: Remove java_lang_Class::process_archived_mirror() [v2] In-Reply-To: <8aR1ZM5vJ1xZWWbzOQChM_jQA1mSnR29py105guxQyg=.2267d8b2-0e3f-47a5-8527-70ff54b9875d@github.com> References: <8aR1ZM5vJ1xZWWbzOQChM_jQA1mSnR29py105guxQyg=.2267d8b2-0e3f-47a5-8527-70ff54b9875d@github.com> Message-ID: On Fri, 13 Jan 2023 18:39:02 GMT, Calvin Cheung wrote: >> Ioi Lam has updated the pull request incrementally with three additional commits since the last revision: >> >> - review comments from @ashu-mehra and @dholmes-ora >> - fixed repo >> - tmp > > src/hotspot/share/oops/objArrayKlass.cpp line 442: > >> 440: } >> 441: } >> 442: #endif > > When will the above function be called? > > From `ClassLoaderData::free_deallocate_list()` > > > // Cast them so they can be used by the template function. > if (m->is_method()) { > MetadataFactory::free_metadata(this, (Method*)m); > } else if (m->is_constantPool()) { > MetadataFactory::free_metadata(this, (ConstantPool*)m); > } else if (m->is_klass()) { > MetadataFactory::free_metadata(this, (InstanceKlass*)m); > } else { > ShouldNotReachHere(); > } > > `free_metadata` will call `deallocate_contents` but I don't see how it will call the` ObjectArrayKlass` version. Thanks for finding this. `::free_deallocate_list` is called only by the template function `MetadataFactory::free_metadata`. I removed `ObjArrayKlass::deallocate_contents()` and HotSpot still builds. This means nobody uses `free_metadata` with the `ObjArrayKlass` type. ------------- PR: https://git.openjdk.org/jdk/pull/11853 From rkennke at openjdk.org Fri Jan 13 19:04:59 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 13 Jan 2023 19:04:59 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v11] In-Reply-To: References: Message-ID: > See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details. > > Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements. > > Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16. > > Testing: > - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390) > - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390) > - [x] tier1 (x86_64, x86_32, aarch64, riscv) > - [x] tier2 (x86_64, aarch64, riscv) > - [x] tier3 (x86_64, riscv) Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: - Merge branch 'master' into JDK-8139457 - Fix gtest for correct base offsets in 32bit builds - Fix cast warning - Revert relaxation of array length - Add guards to ArrayBaseOffsets test to allow running with -UseCompressedClassPointers - Fix another cast warning - Clean cast warning from size_t to int - Clear leading 32bits in Z array allocator - SA adjustments - Test for 32bit build - ... and 15 more: https://git.openjdk.org/jdk/compare/500b45e1...c278a53b ------------- Changes: https://git.openjdk.org/jdk/pull/11044/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=10 Stats: 564 lines in 32 files changed: 434 ins; 58 del; 72 mod Patch: https://git.openjdk.org/jdk/pull/11044.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11044/head:pull/11044 PR: https://git.openjdk.org/jdk/pull/11044 From skuksenko at openjdk.org Fri Jan 13 19:10:17 2023 From: skuksenko at openjdk.org (Sergey Kuksenko) Date: Fri, 13 Jan 2023 19:10:17 GMT Subject: RFR: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions In-Reply-To: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> References: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> Message-ID: On Thu, 12 Jan 2023 02:52:17 GMT, Sergey Kuksenko wrote: > 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions Xiaolin, It was my fault. That assert shouldn't be there. Removed. ------------- PR: https://git.openjdk.org/jdk/pull/11958 From skuksenko at openjdk.org Fri Jan 13 19:10:24 2023 From: skuksenko at openjdk.org (Sergey Kuksenko) Date: Fri, 13 Jan 2023 19:10:24 GMT Subject: RFR: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions In-Reply-To: <8RiIpov3KBqW1zB_HHqW0_ELy9K3PjYpfcAyOL83t0U=.ebead259-f9a9-45ca-98b0-01cbfa0354a5@github.com> References: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> <8RiIpov3KBqW1zB_HHqW0_ELy9K3PjYpfcAyOL83t0U=.ebead259-f9a9-45ca-98b0-01cbfa0354a5@github.com> Message-ID: On Thu, 12 Jan 2023 06:03:09 GMT, Tobias Hartmann wrote: >> 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions > > src/hotspot/share/asm/assembler.hpp line 254: > >> 252: } >> 253: void register_nop() { >> 254: _assm->count_post_call_nop(_assm->pc() - _nop_start); > > Suggestion: > > _assm->count_post_call_nop(_assm->pc() - _nop_start); ok > src/hotspot/share/asm/codeBuffer.hpp line 211: > >> 209: >> 210: void count_post_call_nop(int size) { >> 211: _post_call_nop_size += size; > > Suggestion: > > _post_call_nop_size += size; ok > src/hotspot/share/ci/ciMethod.cpp line 1146: > >> 1144: _inline_instructions_size = 0; >> 1145: } >> 1146: ); > > Indentation looks weird. I see that you copied it from `ciMethod::instructions_size`, that one should be fixed as well. ok ------------- PR: https://git.openjdk.org/jdk/pull/11958 From skuksenko at openjdk.org Fri Jan 13 19:19:23 2023 From: skuksenko at openjdk.org (Sergey Kuksenko) Date: Fri, 13 Jan 2023 19:19:23 GMT Subject: RFR: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions In-Reply-To: <8RiIpov3KBqW1zB_HHqW0_ELy9K3PjYpfcAyOL83t0U=.ebead259-f9a9-45ca-98b0-01cbfa0354a5@github.com> References: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> <8RiIpov3KBqW1zB_HHqW0_ELy9K3PjYpfcAyOL83t0U=.ebead259-f9a9-45ca-98b0-01cbfa0354a5@github.com> Message-ID: On Thu, 12 Jan 2023 06:16:14 GMT, Tobias Hartmann wrote: > If you update the last usage in `ciMethod::has_compiled_code()`, it looks like `ciMethod::instructions_size` is not needed anymore and can be removed. Instead, you could just change its semantic to exclude nops (please also update the method's comments). I thought about it. The issue is naming. "instructions_size" says nothing about the fact that nop instructions were excluded. On the other side using "inline_instructions_size" in `ciMethod::has_compiled_code()` looks weird. I am open to any suggestions. ------------- PR: https://git.openjdk.org/jdk/pull/11958 From skuksenko at openjdk.org Fri Jan 13 19:28:34 2023 From: skuksenko at openjdk.org (Sergey Kuksenko) Date: Fri, 13 Jan 2023 19:28:34 GMT Subject: RFR: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions [v2] In-Reply-To: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> References: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> Message-ID: > 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions Sergey Kuksenko has updated the pull request incrementally with one additional commit since the last revision: fix identation, remove faulty assert ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11958/files - new: https://git.openjdk.org/jdk/pull/11958/files/82e35e75..035d8fe6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11958&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11958&range=00-01 Stats: 18 lines in 3 files changed: 0 ins; 1 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/11958.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11958/head:pull/11958 PR: https://git.openjdk.org/jdk/pull/11958 From skuksenko at openjdk.org Fri Jan 13 19:31:13 2023 From: skuksenko at openjdk.org (Sergey Kuksenko) Date: Fri, 13 Jan 2023 19:31:13 GMT Subject: RFR: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions [v2] In-Reply-To: References: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> Message-ID: On Thu, 12 Jan 2023 18:11:22 GMT, Vladimir Ivanov wrote: > As an alternative way to count nops, have you considered iterating over relocations and counting `post_call_nop_Reolcation`s then multiplying the count by `NativePostCallNop::instruction_size`? (So far, there's no `NativePostCallNop::instruction_size` declared on aarch64 and ppc, but that's the common pattern in nativeInst_*.hpp.) It was my first draft which I didn't show here. I just thought that the current way is more generic and doesn't have dependency on relocation size. In the future (if needed), such inline heuristic may be expanded by excluding some other instructions. > BTW I'm curious why there's no relocation registered on PPC while both x86 and aarch64 have it. I don't know the answer. ------------- PR: https://git.openjdk.org/jdk/pull/11958 From dcubed at openjdk.org Fri Jan 13 19:42:17 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 13 Jan 2023 19:42:17 GMT Subject: RFR: 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug [v5] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 09:42:19 GMT, Afshin Zafari wrote: >> ### Description >> The following problems found and solved: >> >> 1) Reporting which regex pattern did not match with error messages was incorrect. To report the mismatched pattern, the head of the pattern list was peeked, while it was the already peeked item from that did not match. So the next pattern to the mismatched one was reported. >> >> 2) The pattern for finding a crash was incorrectly set to "# .*VMError::controlled_crash.*", while it has to be "# .*crash_with_segfault.*". >> >> 3) `crash_with_segfault` function is too small and was `inline`d in compiler optimisations. So it was not in the stack trace when the error message is created. >> >> ### Patch >> 1 and 2 corrected and added the `NOINLINE` to the `crash_with_segfault` signature. The same applied for `crash_with_sigfpe` function. >> >> ### Test >> runtime/ErrorHandling/* and tier1-5 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug Thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/11704 From eosterlund at openjdk.org Fri Jan 13 19:50:14 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 13 Jan 2023 19:50:14 GMT Subject: RFR: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions [v2] In-Reply-To: References: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> Message-ID: On Fri, 13 Jan 2023 19:28:00 GMT, Sergey Kuksenko wrote: > > As an alternative way to count nops, have you considered iterating over relocations and counting `post_call_nop_Reolcation`s then multiplying the count by `NativePostCallNop::instruction_size`? (So far, there's no `NativePostCallNop::instruction_size` declared on aarch64 and ppc, but that's the common pattern in nativeInst_*.hpp.) > > > > It was my first draft which I didn't show here. > > I just thought that the current way is more generic and doesn't have dependency on relocation size. In the future (if needed), such inline heuristic may be expanded by excluding some other instructions. > > I agree with you. In fact I think we might want to do this route for generational ZGC as well. We don't want our different barriers to cause different inlining decisions. But if we go down that route, perhaps the name of the exclusion tool should be more generic? ------------- PR: https://git.openjdk.org/jdk/pull/11958 From ccheung at openjdk.org Fri Jan 13 20:01:20 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 13 Jan 2023 20:01:20 GMT Subject: RFR: 8297914: Remove java_lang_Class::process_archived_mirror() [v3] In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 19:00:40 GMT, Ioi Lam wrote: >> This is another prerequisite for [JDK-8296344](https://bugs.openjdk.org/browse/JDK-8296344). >> >> Before this PR, when archiving mirror objects (i.e., instances of `java.lang.Class`): >> - We first allocate a copy of the mirror inside a safepoint. >> - We then reinitialize the contents of the copy to the desired state (so that it can be used by `Klass::restore_unshareable_info()` >> >> This copy-and-modify operation inside the safepoint makes it difficult to implement [JDK-8296344](https://bugs.openjdk.org/browse/JDK-8296344). It violates the requirements [1] and [2] as stated in [JDK-8298600](https://bugs.openjdk.org/browse/JDK-8298600). Also, the reinitialization code is complicated. >> >> After this PR: >> - During the creation of each regular mirror object, we allocate a "scratch mirror" object, which has the states as expected by `Klass::restore_unshareable_info()`. See `java_lang_Class::create_scratch_mirror()`. >> - When the archive heap is dumped inside a safepoint, we use the scratch mirror, so we can avoid the copy-and-modify operation. See `HeapShared::archive_java_mirrors()`. >> >> Testing: tiers 1-4 > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @calvinccheung comment - removed unnecessary ObjArrayKlass::deallocate_contents Thanks for the update. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.org/jdk/pull/11853 From skuksenko at openjdk.org Fri Jan 13 20:08:34 2023 From: skuksenko at openjdk.org (Sergey Kuksenko) Date: Fri, 13 Jan 2023 20:08:34 GMT Subject: RFR: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions [v2] In-Reply-To: References: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> Message-ID: On Fri, 13 Jan 2023 19:47:33 GMT, Erik ?sterlund wrote: > I agree with you. In fact I think we might want to do this route for generational ZGC as well. We don't want our different barriers to cause different inlining decisions. But if we go down that route, perhaps the name of the exclusion tool should be more generic? I was surprised to find out about other usages so fast. I will do renaming. ------------- PR: https://git.openjdk.org/jdk/pull/11958 From never at openjdk.org Fri Jan 13 20:11:13 2023 From: never at openjdk.org (Tom Rodriguez) Date: Fri, 13 Jan 2023 20:11:13 GMT Subject: RFR: JDK-8299229: Allow UseZGC with JVMCI and enable nmethod entry barrier support Message-ID: This exposes the required ZGC values to JVMCI and adds support for nmethod entry barriers. The ZGC support is straightforward but the nmethod entry barrier required some reworking to fit better into JVMCI usage. I also removed the epoch based barrier since it was no longer used with simplified the assumptions on the JVMCI side. There is also a minor loom related fix to support post call nops included. I could move that into a separate PR if that would be preferred. ------------- Commit messages: - Allow UseZGC with JVMCI and enable nmethod entry barrier support Changes: https://git.openjdk.org/jdk/pull/11996/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11996&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299229 Stats: 610 lines in 31 files changed: 335 ins; 149 del; 126 mod Patch: https://git.openjdk.org/jdk/pull/11996.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11996/head:pull/11996 PR: https://git.openjdk.org/jdk/pull/11996 From eosterlund at openjdk.org Fri Jan 13 20:50:17 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 13 Jan 2023 20:50:17 GMT Subject: RFR: JDK-8299229: Allow UseZGC with JVMCI and enable nmethod entry barrier support In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 20:02:26 GMT, Tom Rodriguez wrote: > This exposes the required ZGC values to JVMCI and adds support for nmethod entry barriers. The ZGC support is straightforward but the nmethod entry barrier required some reworking to fit better into JVMCI usage. I also removed the epoch based barrier since it was no longer used with simplified the assumptions on the JVMCI side. There is also a minor loom related fix to support post call nops included. I could move that into a separate PR if that would be preferred. Please do not remove the patching epoch code for AArch64. It is used by generational ZGC so that it can do self modifying code on AArch64 safely. Generational ZGC is just around the corner. We are currently upstreaming shared runtime code separately so it doesn't need to be merged with the JEP. ------------- Changes requested by eosterlund (Reviewer). PR: https://git.openjdk.org/jdk/pull/11996 From never at openjdk.org Fri Jan 13 21:11:12 2023 From: never at openjdk.org (Tom Rodriguez) Date: Fri, 13 Jan 2023 21:11:12 GMT Subject: RFR: JDK-8299229: Allow UseZGC with JVMCI and enable nmethod entry barrier support In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 20:02:26 GMT, Tom Rodriguez wrote: > This exposes the required ZGC values to JVMCI and adds support for nmethod entry barriers. The ZGC support is straightforward but the nmethod entry barrier required some reworking to fit better into JVMCI usage. I also removed the epoch based barrier since it was no longer used with simplified the assumptions on the JVMCI side. There is also a minor loom related fix to support post call nops included. I could move that into a separate PR if that would be preferred. Ok. I wondered why it was still around since it seemed pretty obviously dead. I'll restore that code and expose the extra state needed to support code generation for it. Are 3 different strategies really required? ------------- PR: https://git.openjdk.org/jdk/pull/11996 From eosterlund at openjdk.org Fri Jan 13 21:30:12 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 13 Jan 2023 21:30:12 GMT Subject: RFR: JDK-8299229: Allow UseZGC with JVMCI and enable nmethod entry barrier support In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 21:08:08 GMT, Tom Rodriguez wrote: > Ok. I wondered why it was still around since it seemed pretty obviously dead. I'll restore that code and expose the extra state needed to support code generation for it. Are 3 different strategies really required? We are right at a transition point. We need the STW strategy to not regress for the normal GCs. The conc data + instruction approach, however, is strictly better than the conc data approach. It performs better and allows modifying both data and instructions. But it isn't directly compatible with mainline ZGC, as it kind of wants the colour bits to be enclosed in the low order 32 bits of the thread-local disarm guard value. It is in generational ZGC, but not in mainline ZGC. I suppose it is possible to poke the mainline ZGC code to conform to the new requirements, but as generational ZGC is around the corner, we were sort out waiting for that instead. Presumably something similar would have to be done to Shenandoah as well to migrate to the new better barrier. ------------- PR: https://git.openjdk.org/jdk/pull/11996 From xuelei at openjdk.org Fri Jan 13 23:27:36 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 13 Jan 2023 23:27:36 GMT Subject: RFR: 8299635: More test issues for deprecated sprintf in Xcode 14 [v2] In-Reply-To: References: Message-ID: <9QM0jWWZ-iupPlS3I9Ym-VDl6egK0jHXGezReju0vCs=.b8396d23-68b6-4ea6-8ee3-4ab0fca39963@github.com> > The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. > > This patch is trying to find the use of sprintf in test cases, and replace it with snprintf accordingly. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: more in src/hotspot ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11935/files - new: https://git.openjdk.org/jdk/pull/11935/files/1f7706f9..62a6be82 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=00-01 Stats: 59 lines in 12 files changed: 2 ins; 2 del; 55 mod Patch: https://git.openjdk.org/jdk/pull/11935.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11935/head:pull/11935 PR: https://git.openjdk.org/jdk/pull/11935 From mikael at openjdk.org Sat Jan 14 00:44:11 2023 From: mikael at openjdk.org (Mikael Vidstedt) Date: Sat, 14 Jan 2023 00:44:11 GMT Subject: RFR: 8299635: More test issues for deprecated sprintf in Xcode 14 [v2] In-Reply-To: <9QM0jWWZ-iupPlS3I9Ym-VDl6egK0jHXGezReju0vCs=.b8396d23-68b6-4ea6-8ee3-4ab0fca39963@github.com> References: <9QM0jWWZ-iupPlS3I9Ym-VDl6egK0jHXGezReju0vCs=.b8396d23-68b6-4ea6-8ee3-4ab0fca39963@github.com> Message-ID: On Fri, 13 Jan 2023 23:27:36 GMT, Xue-Lei Andrew Fan wrote: >> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. >> >> This patch is trying to find the use of sprintf in test cases, and replace it with snprintf accordingly. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > more in src/hotspot Thank you for making these additional changes! I'm still seeing some issue building on linux-x64, for example: src/hotspot/share/opto/regalloc.hpp:130:17: note: candidate: 'virtual char* PhaseRegAlloc::dump_register(const Node*, char*, size_t) const' 130 | virtual char *dump_register( const Node *n, char *buf, size_t buf_size) const = 0; | ^~~~~~~~~~~~~ ------------- PR: https://git.openjdk.org/jdk/pull/11935 From sspitsyn at openjdk.org Sat Jan 14 01:43:20 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 14 Jan 2023 01:43:20 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions [v5] In-Reply-To: References: <-u9V0TIbZ41IPEmql4jeLKzAmT9OPIZAurEoN-K2BXc=.0b8e5b84-47be-4d49-b99c-9317b25258e4@github.com> Message-ID: On Wed, 4 Jan 2023 07:45:48 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/prims/jvmtiThreadState.cpp line 482: >> >>> 480: _VTMS_transition_disable_for_all_count > 0) { >>> 481: MonitorLocker ml(JvmtiVTMSTransition_lock, Mutex::_no_safepoint_check_flag); >>> 482: ml.notify_all(); >> >> Checking the counts outside the lock seems really racy. Maybe it is safe in the original code but now we have two counters it is very hard to ascertain this is correct. Overall I find it very hard to see exactly how these counters get used. > > This notification code is just an optimization. All related waiting fragments are with timeouts. > I agree this sync protocol is kind of complicated and also does not scale well. I'm still thinking on how to improve it. I have a two week vacation starting from Monday. Not sure, that I'll be able to see review comments this time. ------------- PR: https://git.openjdk.org/jdk/pull/11690 From xuelei at openjdk.org Sat Jan 14 03:37:26 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Sat, 14 Jan 2023 03:37:26 GMT Subject: RFR: 8299635: More test issues for deprecated sprintf in Xcode 14 [v3] In-Reply-To: References: Message-ID: > The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. > > This patch is trying to find the use of sprintf in test cases, and replace it with snprintf accordingly. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: missed update for debug mode ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11935/files - new: https://git.openjdk.org/jdk/pull/11935/files/62a6be82..98c7d3dd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=01-02 Stats: 14 lines in 6 files changed: 0 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/11935.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11935/head:pull/11935 PR: https://git.openjdk.org/jdk/pull/11935 From xuelei at openjdk.org Sat Jan 14 06:36:33 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Sat, 14 Jan 2023 06:36:33 GMT Subject: RFR: 8299635: More test issues for deprecated sprintf in Xcode 14 [v4] In-Reply-To: References: Message-ID: > The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. > > This patch is trying to find the use of sprintf in test cases, and replace it with snprintf accordingly. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: correction for ppc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11935/files - new: https://git.openjdk.org/jdk/pull/11935/files/98c7d3dd..076f8b54 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11935.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11935/head:pull/11935 PR: https://git.openjdk.org/jdk/pull/11935 From iklam at openjdk.org Sat Jan 14 07:23:43 2023 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 14 Jan 2023 07:23:43 GMT Subject: RFR: 8297914: Remove java_lang_Class::process_archived_mirror() [v4] In-Reply-To: References: Message-ID: > This is another prerequisite for [JDK-8296344](https://bugs.openjdk.org/browse/JDK-8296344). > > Before this PR, when archiving mirror objects (i.e., instances of `java.lang.Class`): > - We first allocate a copy of the mirror inside a safepoint. > - We then reinitialize the contents of the copy to the desired state (so that it can be used by `Klass::restore_unshareable_info()` > > This copy-and-modify operation inside the safepoint makes it difficult to implement [JDK-8296344](https://bugs.openjdk.org/browse/JDK-8296344). It violates the requirements [1] and [2] as stated in [JDK-8298600](https://bugs.openjdk.org/browse/JDK-8298600). Also, the reinitialization code is complicated. > > After this PR: > - During the creation of each regular mirror object, we allocate a "scratch mirror" object, which has the states as expected by `Klass::restore_unshareable_info()`. See `java_lang_Class::create_scratch_mirror()`. > - When the archive heap is dumped inside a safepoint, we use the scratch mirror, so we can avoid the copy-and-modify operation. See `HeapShared::archive_java_mirrors()`. > > 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 ten additional commits since the last revision: - Merge branch 'master' into 8297914-remove-java-lang-class-process-archived-mirror - @calvinccheung comment - removed unnecessary ObjArrayKlass::deallocate_contents - review comments from @ashu-mehra and @dholmes-ora - fixed repo - tmp - refactored KlassToOopHandleTable - refactor java_lang_Class::allocate_mirror (step2) - refactor java_lang_Class::allocate_mirror (step1) - 8297914: Remove java_lang_Class::process_archived_mirror() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11853/files - new: https://git.openjdk.org/jdk/pull/11853/files/c1460a4c..70e6a86d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11853&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11853&range=02-03 Stats: 10724 lines in 514 files changed: 6587 ins; 2244 del; 1893 mod Patch: https://git.openjdk.org/jdk/pull/11853.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11853/head:pull/11853 PR: https://git.openjdk.org/jdk/pull/11853 From jvernee at openjdk.org Sat Jan 14 10:23:10 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Sat, 14 Jan 2023 10:23:10 GMT Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory API (Preview) [v5] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 15:15:23 GMT, Feilong Jiang wrote: >> Add experimental Foreign Function & Memory API support for RISC-V. >> >> For details of the FFM API RISC-V port please refer to [JBS issue](https://bugs.openjdk.org/browse/JDK-8293841) >> >> Testing: >> >> - [x] jdk_foreign with release/fastdebug build on linux-riscv64 >> - [x] jdk_foreign with release/fastdebug build on linux-x64 >> - [x] jdk_foreign with release/fastdebug build on linux-aarch64 > > Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision: > > fix callArranger Marked as reviewed by jvernee (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11004 From alexandr.miloslavskiy at syntevo.com Sat Jan 14 10:44:36 2023 From: alexandr.miloslavskiy at syntevo.com (Alexandr Miloslavskiy) Date: Sat, 14 Jan 2023 13:44:36 +0300 Subject: Potential sensitive information leak through JVM crash logs In-Reply-To: References: <2d297b97-0fe1-2388-9ad2-23c5d1788225@syntevo.com> Message-ID: <4da58f89-aac4-7e16-3fe5-444713e17761@syntevo.com> Hi, > A simple way to deal with this could be to mark error reporting steps > that potentially display security-sensitive information. See VM::report, > STEP macro. > > These steps could print a little prefix/suffix for strippers to do their > work. Unfortunately this won't help, because we don't want to strip entire sections that might contain sensitive information. For debugging purposes, the contents of registers and stack values are quite important. At the same time, we consider these values unlikely to disclose any sensitive information. For example, this is what we received before objects started to print: ---- RIP=0x00007ff96c395f8c jvm.dll RAX=0x0000000400000003 is an unknown value RBX=0x000000001c623290 points into unknown readable memory: 48 66 dc 1b 00 00 00 00 RCX=0x0000000000000004 is an unknown value ---- In numerous cases, these values helped me to bucket and debug problems. The problem for us is that it now prints not just numbers, but also entire objects, which are much more likely to contain sensitive information. The objects are of course also useful in debugging, just they are too sensitive. From alexandr.miloslavskiy at syntevo.com Sat Jan 14 10:49:47 2023 From: alexandr.miloslavskiy at syntevo.com (Alexandr Miloslavskiy) Date: Sat, 14 Jan 2023 13:49:47 +0300 Subject: Potential sensitive information leak through JVM crash logs In-Reply-To: References: <2d297b97-0fe1-2388-9ad2-23c5d1788225@syntevo.com> Message-ID: <0c1941d7-c064-0d9c-0dec-f29f84eb4fcb@syntevo.com> Hi, > Escaping Strings in the printer seems worth considering anyway, > as a Java String could contain control characters, > and yes that will help those who want to process the file. That would be nice to have! With strings issue fixed, it would probably be trivial enough to parse out object dumps when needed. From thomas.stuefe at gmail.com Sat Jan 14 10:54:11 2023 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 14 Jan 2023 11:54:11 +0100 Subject: Potential sensitive information leak through JVM crash logs In-Reply-To: References: <2d297b97-0fe1-2388-9ad2-23c5d1788225@syntevo.com> Message-ID: On Sat, Jan 14, 2023 at 11:39 AM Alexandr Miloslavskiy < alexandr.miloslavskiy at syntevo.com> wrote: > Hi, > > > A simple way to deal with this could be to mark error reporting steps > > that potentially display security-sensitive information. See VM::report, > > STEP macro. > > > > These steps could print a little prefix/suffix for strippers to do their > > work. > > Unfortunately this won't help, because we don't want to strip entire > sections that might contain sensitive information. > > For debugging purposes, the contents of registers and stack values are > quite important. At the same time, we consider these values unlikely to > disclose any sensitive information. > > Sure, but registers may contain parts of a string, e.g. when processing strings, or accidentally reading from text. How do you want to prevent that, or do you consider unlikely enough to live with it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.miloslavskiy at syntevo.com Sat Jan 14 11:01:23 2023 From: alexandr.miloslavskiy at syntevo.com (Alexandr Miloslavskiy) Date: Sat, 14 Jan 2023 14:01:23 +0300 Subject: Potential sensitive information leak through JVM crash logs In-Reply-To: References: <2d297b97-0fe1-2388-9ad2-23c5d1788225@syntevo.com> Message-ID: <6955b18b-0d78-a7ab-a7aa-081f993319f2@syntevo.com> Hi, > Sure, but registers may contain parts of a string, e.g. when processing > strings, or accidentally reading from text. How do you want to prevent > that, or do you consider unlikely enough to live with it? We consider it unlikely enough: * In order to have something sensitive in registers, JVM must crash exactly while handling something sensitive. This is already "unlikely enough". * Having something sensitive in stack values is even more unlikely, because Java don't usually write strings/data directly on stack and rather writes it to heap objects. * Even if it does happen, a single register may contain up to 8 characters only. Object dumps include all direct members of the object and their values, which increases the probability significantly. From jiefu at openjdk.org Sat Jan 14 14:35:00 2023 From: jiefu at openjdk.org (Jie Fu) Date: Sat, 14 Jan 2023 14:35:00 GMT Subject: RFR: 8300169: Build failure with clang-15 Message-ID: Hi all, Please review the fix for the build failure with clang-15. 1. -Wbitwise-instead-of-logical 1) src/hotspot/share/oops/generateOopMap.cpp <--- fixed the warning 2) src/hotspot/share/runtime/notificationThread.cpp <--- keep the code and disable warnings 3) src/hotspot/share/runtime/serviceThread.cpp <--- keep the code and disable warnings 2. -Wdeprecated-non-prototype (all the warnings are disabled) 1) Mainly caused by files under `src/java.base/share/native/libzip/zlib/` <--- keep the code and disable warnings It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN. 2) While compiling src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c <--- keep the code and disable warnings 3) Caused by src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m <--- fixed the warnings 3. -Wdeprecated-builtins Caused by files under src/java.desktop/share/native/libharfbuzz/ <--- fixed the warnings Ref: https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202 4. -Wgnu-folding-constant Caused by src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m <--- keep the code and disable warnings Thanks. Best regards, Jie ------------- Commit messages: - 8300169: Build failure with clang-15 Changes: https://git.openjdk.org/jdk/pull/12005/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12005&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300169 Stats: 15 lines in 6 files changed: 5 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/12005.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12005/head:pull/12005 PR: https://git.openjdk.org/jdk/pull/12005 From kcr at openjdk.org Sat Jan 14 15:06:09 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 14 Jan 2023 15:06:09 GMT Subject: RFR: 8300169: Build failure with clang-15 In-Reply-To: References: Message-ID: On Sat, 14 Jan 2023 14:28:32 GMT, Jie Fu wrote: > Hi all, > > Please review the fix for the build failure with clang-15. > > 1. -Wbitwise-instead-of-logical > > 1) src/hotspot/share/oops/generateOopMap.cpp <--- fixed the warning > 2) src/hotspot/share/runtime/notificationThread.cpp <--- keep the code and disable warnings > 3) src/hotspot/share/runtime/serviceThread.cpp <--- keep the code and disable warnings > > > 2. -Wdeprecated-non-prototype (all the warnings are disabled) > > 1) Mainly caused by files under `src/java.base/share/native/libzip/zlib/` <--- keep the code and disable warnings > It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN. > > 2) While compiling src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c <--- keep the code and disable warnings > > 3) Caused by src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m <--- fixed the warnings > > > 3. -Wdeprecated-builtins > > Caused by files under src/java.desktop/share/native/libharfbuzz/ <--- fixed the warnings > > Ref: https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202 > > 4. -Wgnu-folding-constant > > Caused by src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m <--- keep the code and disable warnings > > > Thanks. > Best regards, > Jie src/java.desktop/share/native/libharfbuzz/hb-meta.hh line 191: > 189: #define hb_int_max(T) hb_int_max::value > 190: > 191: #if defined(__GNUC__) && __GNUC__ < 5 && !defined(__clang__) Normally, such changes in third-party libraries need to be done upstream, and not locally. @prrace can confirm. ------------- PR: https://git.openjdk.org/jdk/pull/12005 From xuelei at openjdk.org Sat Jan 14 18:52:09 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Sat, 14 Jan 2023 18:52:09 GMT Subject: RFR: 8299635: More test issues for deprecated sprintf in Xcode 14 In-Reply-To: References: Message-ID: <2uKA4WjPxwJ_rBTfaHM6d60QEplxWxMDLlL8falWyD4=.889cee2f-9ec0-48b0-a34a-37080ae7e038@github.com> On Fri, 13 Jan 2023 01:56:23 GMT, Serguei Spitsyn wrote: > There are more uses of sprintf in some serviceability folders: Yes. There are at least 57 src files that use sprintf function, as far as I can see. This PR is pretty big now. I would like to clean them up in an other PR so that it is easier to review. ------------- PR: https://git.openjdk.org/jdk/pull/11935 From xuelei at openjdk.org Sat Jan 14 19:01:52 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Sat, 14 Jan 2023 19:01:52 GMT Subject: RFR: 8299635: More test issues for deprecated sprintf in Xcode 14 [v5] In-Reply-To: References: Message-ID: <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com> > The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. > > This patch is trying to find the use of sprintf in test cases, and replace it with snprintf accordingly. Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge - correction for ppc - missed update for debug mode - more in src/hotspot - typo correction - 8299635: More test issues for deprecated sprintf in Xcode 14 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11935/files - new: https://git.openjdk.org/jdk/pull/11935/files/076f8b54..143887e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=03-04 Stats: 8279 lines in 310 files changed: 5031 ins; 1837 del; 1411 mod Patch: https://git.openjdk.org/jdk/pull/11935.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11935/head:pull/11935 PR: https://git.openjdk.org/jdk/pull/11935 From jiefu at openjdk.org Sun Jan 15 01:59:11 2023 From: jiefu at openjdk.org (Jie Fu) Date: Sun, 15 Jan 2023 01:59:11 GMT Subject: RFR: 8300169: Build failure with clang-15 In-Reply-To: References: Message-ID: <0hacUHSSaPqiYtv3EsaC4UVe_da0hydgcTrpUpn9w6s=.ae39b693-7f04-40ab-94c0-a90f95c6c260@github.com> On Sat, 14 Jan 2023 15:03:42 GMT, Kevin Rushforth wrote: > Normally, such changes in third-party libraries need to be done upstream, and not locally. @prrace can confirm. Thanks @kevinrushforth for your review. Yes, it had been fixed in the upstream and I just follow it. Please see https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202 . Or did you mean we had to sync the whole harfbuzz with the upstream? If so, I would suggest doing it in a separate PR. What do you think? Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/12005 From yadongwang at openjdk.org Sun Jan 15 02:24:12 2023 From: yadongwang at openjdk.org (Yadong Wang) Date: Sun, 15 Jan 2023 02:24:12 GMT Subject: RFR: 8299844: RISC-V: Implement _onSpinWait intrinsic In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 17:23:13 GMT, Ludovic Henry wrote: >> Implement _onSpinWait() intrinsic for RISC-V, and it can be implemented by using PAUSE instruction from Zihintpause Extension, which is ratified and a mandatory extension of RVA22U64 (https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#rva22u64-mandatory-extensions). >> Software can use the PAUSE instruction to reduce energy consumption while executing spinwait >> code sequences (https://github.com/riscv/riscv-isa-manual/blob/master/src/zihintpause.tex). >> >> Add a test case of test/hotspot/jtreg/compiler/onSpinWait/TestOnSpinWaitRISCV64.java, passed on QEMU. > > src/hotspot/cpu/riscv/riscv.ad line 1820: > >> 1818: switch (opcode) { >> 1819: case Op_OnSpinWait: >> 1820: return VM_Version::supports_on_spin_wait(); > > You can use `UseZihintpause` directly just like for `UseRVV`, `UsePopCountInstruction`, or `UseZbb` below. supports_on_spin_wait() is called both from share and cpu specific code. I think it's better to be a unified switch. ------------- PR: https://git.openjdk.org/jdk/pull/11921 From yadongwang at openjdk.org Sun Jan 15 03:05:41 2023 From: yadongwang at openjdk.org (Yadong Wang) Date: Sun, 15 Jan 2023 03:05:41 GMT Subject: RFR: 8299844: RISC-V: Implement _onSpinWait intrinsic [v2] In-Reply-To: References: Message-ID: <7G2iIv_Cp4V7gVBQPtCpltHId_RdEYWfwwaGA8SPUfY=.3fe90aa9-229c-477d-930f-9eff633d7da7@github.com> > Implement _onSpinWait() intrinsic for RISC-V, and it can be implemented by using PAUSE instruction from Zihintpause Extension, which is ratified and a mandatory extension of RVA22U64 (https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#rva22u64-mandatory-extensions). > Software can use the PAUSE instruction to reduce energy consumption while executing spinwait > code sequences (https://github.com/riscv/riscv-isa-manual/blob/master/src/zihintpause.tex). > > Add a test case of test/hotspot/jtreg/compiler/onSpinWait/TestOnSpinWaitRISCV64.java, passed on QEMU. Yadong Wang has updated the pull request incrementally with one additional commit since the last revision: fix copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11921/files - new: https://git.openjdk.org/jdk/pull/11921/files/7d9861e1..4f8a526e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11921&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11921&range=00-01 Stats: 17 lines in 9 files changed: 5 ins; 4 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/11921.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11921/head:pull/11921 PR: https://git.openjdk.org/jdk/pull/11921 From fjiang at openjdk.org Sun Jan 15 04:33:11 2023 From: fjiang at openjdk.org (Feilong Jiang) Date: Sun, 15 Jan 2023 04:33:11 GMT Subject: RFR: 8299844: RISC-V: Implement _onSpinWait intrinsic [v2] In-Reply-To: <7G2iIv_Cp4V7gVBQPtCpltHId_RdEYWfwwaGA8SPUfY=.3fe90aa9-229c-477d-930f-9eff633d7da7@github.com> References: <7G2iIv_Cp4V7gVBQPtCpltHId_RdEYWfwwaGA8SPUfY=.3fe90aa9-229c-477d-930f-9eff633d7da7@github.com> Message-ID: On Sun, 15 Jan 2023 03:05:41 GMT, Yadong Wang wrote: >> Implement _onSpinWait() intrinsic for RISC-V, and it can be implemented by using PAUSE instruction from Zihintpause Extension, which is ratified and a mandatory extension of RVA22U64 (https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#rva22u64-mandatory-extensions). >> Software can use the PAUSE instruction to reduce energy consumption while executing spinwait >> code sequences (https://github.com/riscv/riscv-isa-manual/blob/master/src/zihintpause.tex). >> >> Add a test case of test/hotspot/jtreg/compiler/onSpinWait/TestOnSpinWaitRISCV64.java, passed on QEMU. > > Yadong Wang has updated the pull request incrementally with one additional commit since the last revision: > > fix copyright year src/hotspot/cpu/riscv/assembler_riscv.cpp line 4: > 2: * Copyright (c) 1997, 2012, Oracle and/or its affiliates. All rights reserved. > 3: * Copyright (c) 2014, Red Hat Inc. All rights reserved. > 4: * Copyright (c) 2020, 2022, Huawei Technologies Co., Ltd. All rights reserved. Unnecessary copyright year update of `asembler_riscv.cpp`. ------------- PR: https://git.openjdk.org/jdk/pull/11921 From fyang at openjdk.org Sun Jan 15 09:12:10 2023 From: fyang at openjdk.org (Fei Yang) Date: Sun, 15 Jan 2023 09:12:10 GMT Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory API (Preview) [v5] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 15:15:23 GMT, Feilong Jiang wrote: >> Add experimental Foreign Function & Memory API support for RISC-V. >> >> For details of the FFM API RISC-V port please refer to [JBS issue](https://bugs.openjdk.org/browse/JDK-8293841) >> >> Testing: >> >> - [x] jdk_foreign with release/fastdebug build on linux-riscv64 >> - [x] jdk_foreign with release/fastdebug build on linux-x64 >> - [x] jdk_foreign with release/fastdebug build on linux-aarch64 > > Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision: > > fix callArranger Changes requested by fyang (Reviewer). test/jdk/java/foreign/callarranger/TestRISCV64CallArranger.java line 3: > 1: /* > 2: * Copyright (c) 2020, 2022, Oracle and/or its affiliates. All rights reserved. > 3: * Copyright (c) 2023, Institute of Software, Chinese Academy of Sciences. All rights reserved. I think we should also break this into two separate lines like you do for other newly-added files. ------------- PR: https://git.openjdk.org/jdk/pull/11004 From fjiang at openjdk.org Sun Jan 15 15:31:52 2023 From: fjiang at openjdk.org (Feilong Jiang) Date: Sun, 15 Jan 2023 15:31:52 GMT Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory API (Preview) [v6] In-Reply-To: References: Message-ID: <5EFRZ3OVzKXhrdzba7Pcvpx-9gV8tu_ttcAvUsFtrUk=.0c60959f-9849-42c3-a8aa-c1cd712e816a@github.com> > Add experimental Foreign Function & Memory API support for RISC-V. > > For details of the FFM API RISC-V port please refer to [JBS issue](https://bugs.openjdk.org/browse/JDK-8293841) > > Testing: > > - [x] jdk_foreign with release/fastdebug build on linux-riscv64 > - [x] jdk_foreign with release/fastdebug build on linux-x64 > - [x] jdk_foreign with release/fastdebug build on linux-aarch64 Feilong Jiang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - fix comment & code adjustment - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8293841-foreign-api-riscv - fix callArranger - fix callArranger - fix build - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8293841-foreign-api-riscv - code adjustment and remove unnecessary static - sync with JDK-8296477 - sync with JDK-8295044 - JDK-8293841: RISC-V: Implementation of Foreign Function & Memory API (Preview) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11004/files - new: https://git.openjdk.org/jdk/pull/11004/files/fee96ae8..be0826db Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11004&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11004&range=04-05 Stats: 5077 lines in 204 files changed: 3274 ins; 964 del; 839 mod Patch: https://git.openjdk.org/jdk/pull/11004.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11004/head:pull/11004 PR: https://git.openjdk.org/jdk/pull/11004 From fjiang at openjdk.org Sun Jan 15 15:33:10 2023 From: fjiang at openjdk.org (Feilong Jiang) Date: Sun, 15 Jan 2023 15:33:10 GMT Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory API (Preview) [v5] In-Reply-To: References: Message-ID: On Sun, 15 Jan 2023 09:09:07 GMT, Fei Yang wrote: >> Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision: >> >> fix callArranger > > test/jdk/java/foreign/callarranger/TestRISCV64CallArranger.java line 3: > >> 1: /* >> 2: * Copyright (c) 2020, 2022, Oracle and/or its affiliates. All rights reserved. >> 3: * Copyright (c) 2023, Institute of Software, Chinese Academy of Sciences. All rights reserved. > > I think we should also break this into two separate lines like you do for other newly-added files. Oops! Missed here, fixed. ------------- PR: https://git.openjdk.org/jdk/pull/11004 From iklam at openjdk.org Sun Jan 15 20:34:16 2023 From: iklam at openjdk.org (Ioi Lam) Date: Sun, 15 Jan 2023 20:34:16 GMT Subject: Integrated: 8297914: Remove java_lang_Class::process_archived_mirror() In-Reply-To: References: Message-ID: <468e5K-Ba5-dMRukjp0uRklcPtDXmPZ80SIqbk7Hx54=.f99f489d-6285-4e98-ab34-ee334a470e57@github.com> On Wed, 4 Jan 2023 21:01:28 GMT, Ioi Lam wrote: > This is another prerequisite for [JDK-8296344](https://bugs.openjdk.org/browse/JDK-8296344). > > Before this PR, when archiving mirror objects (i.e., instances of `java.lang.Class`): > - We first allocate a copy of the mirror inside a safepoint. > - We then reinitialize the contents of the copy to the desired state (so that it can be used by `Klass::restore_unshareable_info()` > > This copy-and-modify operation inside the safepoint makes it difficult to implement [JDK-8296344](https://bugs.openjdk.org/browse/JDK-8296344). It violates the requirements [1] and [2] as stated in [JDK-8298600](https://bugs.openjdk.org/browse/JDK-8298600). Also, the reinitialization code is complicated. > > After this PR: > - During the creation of each regular mirror object, we allocate a "scratch mirror" object, which has the states as expected by `Klass::restore_unshareable_info()`. See `java_lang_Class::create_scratch_mirror()`. > - When the archive heap is dumped inside a safepoint, we use the scratch mirror, so we can avoid the copy-and-modify operation. See `HeapShared::archive_java_mirrors()`. > > Testing: tiers 1-4 This pull request has now been integrated. Changeset: 7bcd5f41 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/7bcd5f418c399678e9459dc376c3ef061493b33f Stats: 495 lines in 10 files changed: 214 ins; 226 del; 55 mod 8297914: Remove java_lang_Class::process_archived_mirror() Reviewed-by: ccheung ------------- PR: https://git.openjdk.org/jdk/pull/11853 From iklam at openjdk.org Sun Jan 15 20:31:17 2023 From: iklam at openjdk.org (Ioi Lam) Date: Sun, 15 Jan 2023 20:31:17 GMT Subject: RFR: 8297914: Remove java_lang_Class::process_archived_mirror() [v2] In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 21:18:49 GMT, Ashutosh Mehra wrote: >> Ioi Lam has updated the pull request incrementally with three additional commits since the last revision: >> >> - review comments from @ashu-mehra and @dholmes-ora >> - fixed repo >> - tmp > > lgtm! thanks for addressing the comments. Thanks @ashu-mehra and @calvinccheung for the review. Passes tiers 1 - 5. ------------- PR: https://git.openjdk.org/jdk/pull/11853 From redestad at openjdk.org Sun Jan 15 23:24:18 2023 From: redestad at openjdk.org (Claes Redestad) Date: Sun, 15 Jan 2023 23:24:18 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v18] In-Reply-To: References: Message-ID: On Mon, 9 Jan 2023 16:49:25 GMT, Claes Redestad wrote: >> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. >> >> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. >> >> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. >> >> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. >> >> With the most recent fixes the x64 intrinsic results on my workstation look like this: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op >> >> I.e. no measurable overhead compared to baseline even for `size == 1`. >> >> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. >> >> Benchmark for `Arrays.hashCode`: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op >> ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op >> ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op >> ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op >> ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op >> ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op >> ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op >> ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op >> ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op >> ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op >> ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op >> ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op >> ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op >> ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op >> ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op >> ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op >> ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op >> ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op >> ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op >> ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op >> ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op >> ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op >> ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op >> ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op >> ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op >> >> >> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Explicitly lea external address FWIW I prototyped a follow-up to use basic types and extracted the String special-casing from the code. To do so a few things unraveled, such as needing to pass the initial value, but arguably it all ended up a bit neater. I've put this experiment in another branch for now (https://github.com/openjdk/jdk/compare/pr/10847...cl4es:jdk:8282664-type-cleanup?expand=1) since I need to test it through thoroughly, but functionally and to ensure there's no obvious performance impact (did some quick sanity testing on micros that look perfectly neutral) @iwanowww does this make you a bit happier? I think of it as an immediate follow-up - but if there's strong preference I can merge it into this PR. ------------- PR: https://git.openjdk.org/jdk/pull/10847 From dholmes at openjdk.org Mon Jan 16 00:42:13 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 16 Jan 2023 00:42:13 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v9] In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 19:44:08 GMT, Brian Burkhalter wrote: >> test/jdk/java/nio/jni/NewDirectByteBuffer.java line 93: >> >>> 91: } >>> 92: }); >>> 93: } catch (OutOfMemoryError ignored) { >> >> Why is there is catch of OOME here? > > Apparently it is not needed so removed in 38ea7997be2be59e2cea97c7dabf929210c0edfa. No wonder I couldn't find this change! The catch of OOME was added because I still believe that trying to allocate a buffer of capacity Integer.MAX_VALUE will throw OOME (at least some of the time). If that happens then the test should not fail. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From skuksenko at openjdk.org Mon Jan 16 01:36:32 2023 From: skuksenko at openjdk.org (Sergey Kuksenko) Date: Mon, 16 Jan 2023 01:36:32 GMT Subject: RFR: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions [v3] In-Reply-To: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> References: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> Message-ID: > Post call nop instructions increase the size of methods, which leads to different inline decisions and performance regression. > Restore inline behavior by excluding post call nop instructions sizes from inline heuristics. Sergey Kuksenko has updated the pull request incrementally with two additional commits since the last revision: - whitespace clenup - renaming; generalize; make methods independent on post call noops naming ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11958/files - new: https://git.openjdk.org/jdk/pull/11958/files/035d8fe6..eb9c494f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11958&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11958&range=01-02 Stats: 42 lines in 9 files changed: 2 ins; 12 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/11958.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11958/head:pull/11958 PR: https://git.openjdk.org/jdk/pull/11958 From kvn at openjdk.org Mon Jan 16 01:58:11 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 16 Jan 2023 01:58:11 GMT Subject: RFR: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions [v3] In-Reply-To: References: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> Message-ID: On Mon, 16 Jan 2023 01:36:32 GMT, Sergey Kuksenko wrote: >> Post call nop instructions increase the size of methods, which leads to different inline decisions and performance regression. >> Restore inline behavior by excluding post call nop instructions sizes from inline heuristics. > > Sergey Kuksenko has updated the pull request incrementally with two additional commits since the last revision: > > - whitespace clenup > - renaming; generalize; make methods independent on post call noops naming I don't see `_instructions_size` is used anymore so I suggest simply remove it and use `_inline_instructions_size`. Which was original purpose of this value anyway. You missed ciReplay change to record `_inline_instructions_size` and restore it. That is what is used in inlining decision in your changes. Also you need to record it in vmStructs.cpp. Just rename it. ------------- Changes requested by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11958 From skuksenko at openjdk.org Mon Jan 16 02:46:32 2023 From: skuksenko at openjdk.org (Sergey Kuksenko) Date: Mon, 16 Jan 2023 02:46:32 GMT Subject: RFR: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions [v4] In-Reply-To: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> References: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> Message-ID: > Post call nop instructions increase the size of methods, which leads to different inline decisions and performance regression. > Restore inline behavior by excluding post call nop instructions sizes from inline heuristics. Sergey Kuksenko has updated the pull request incrementally with one additional commit since the last revision: names clenup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11958/files - new: https://git.openjdk.org/jdk/pull/11958/files/eb9c494f..c1379493 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11958&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11958&range=02-03 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/11958.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11958/head:pull/11958 PR: https://git.openjdk.org/jdk/pull/11958 From kvn at openjdk.org Mon Jan 16 02:46:33 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 16 Jan 2023 02:46:33 GMT Subject: RFR: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions [v3] In-Reply-To: References: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> Message-ID: On Mon, 16 Jan 2023 01:36:32 GMT, Sergey Kuksenko wrote: >> Post call nop instructions increase the size of methods, which leads to different inline decisions and performance regression. >> Restore inline behavior by excluding post call nop instructions sizes from inline heuristics. > > Sergey Kuksenko has updated the pull request incrementally with two additional commits since the last revision: > > - whitespace clenup > - renaming; generalize; make methods independent on post call noops naming src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 1188: > 1186: return; > 1187: } > 1188: PostCallNopCounter nopCounter(this); Did you forgot to change it to `InlineSkippedInstructionsCounter`? src/hotspot/share/asm/assembler.hpp line 248: > 246: class InlineSkippedInstructionsCounter: public StackObj { > 247: private: > 248: AbstractAssembler* _assm; May be you should record `_assm->_code_section` instead and directly call `_code_section->register_skipped(_start)` instead of adding `AbstractAssembler:: register_skipped(size)`. With `CodeSection` code: register_skipped(address start) { _skipped_instructions_size += (_end - start); } src/hotspot/share/asm/codeBuffer.cpp line 600: > 598: > 599: int CodeBuffer::total_skipped_instructions_size() const { > 600: int total_nop_size = 0; `total_nop_size` --> `total_skipped_size` ------------- PR: https://git.openjdk.org/jdk/pull/11958 From skuksenko at openjdk.org Mon Jan 16 02:46:33 2023 From: skuksenko at openjdk.org (Sergey Kuksenko) Date: Mon, 16 Jan 2023 02:46:33 GMT Subject: RFR: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions [v3] In-Reply-To: References: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> Message-ID: <_uV_nQ3Nyl05pUzLaImDG07AXWA_XxDYZDtIOz60rWc=.4df50489-2a93-4962-bc4d-39a26ec6f84e@github.com> On Mon, 16 Jan 2023 02:11:48 GMT, Vladimir Kozlov wrote: >> Sergey Kuksenko has updated the pull request incrementally with two additional commits since the last revision: >> >> - whitespace clenup >> - renaming; generalize; make methods independent on post call noops naming > > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 1188: > >> 1186: return; >> 1187: } >> 1188: PostCallNopCounter nopCounter(this); > > Did you forgot to change it to `InlineSkippedInstructionsCounter`? I forgot other thing, but forgot. fixing. ------------- PR: https://git.openjdk.org/jdk/pull/11958 From skuksenko at openjdk.org Mon Jan 16 02:59:32 2023 From: skuksenko at openjdk.org (Sergey Kuksenko) Date: Mon, 16 Jan 2023 02:59:32 GMT Subject: RFR: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions [v5] In-Reply-To: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> References: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> Message-ID: <1p4LqC5qz2G2jC1o4jKUkojrPSunDKphonFYcBE9hdc=.caf05d56-3243-44b2-8259-dcfcac94fe24@github.com> > Post call nop instructions increase the size of methods, which leads to different inline decisions and performance regression. > Restore inline behavior by excluding post call nop instructions sizes from inline heuristics. Sergey Kuksenko has updated the pull request incrementally with one additional commit since the last revision: remove unused fields ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11958/files - new: https://git.openjdk.org/jdk/pull/11958/files/c1379493..dc849600 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11958&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11958&range=03-04 Stats: 8 lines in 4 files changed: 0 ins; 4 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11958.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11958/head:pull/11958 PR: https://git.openjdk.org/jdk/pull/11958 From dholmes at openjdk.org Mon Jan 16 03:03:10 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 16 Jan 2023 03:03:10 GMT Subject: RFR: 8300052: PdhDll::PdhCollectQueryData and PdhLookupPerfNameByIndex will never be NULL In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 15:21:37 GMT, Julian Waters wrote: > Both PdhDll::PdhCollectQueryData and PdhLookupPerfNameByIndex are concrete definitions and not pointers to executable code (Former is defined by us and the latter is a macro that expands into a concrete declaration), so it makes no sense to check if they will be NULL. The code fails to compile on Windows before this commit when gcc has warnings as errors enabled (-Waddress in this case) > > In the case of PdhCollectQueryData I'm assuming the check actually intended to check for _PdhCollectQueryData with the leading underscore, which is actually a pointer and can be NULL. Do correct me if I'm wrong and point me to what the appropriate check would be otherwise Changes requested by dholmes (Reviewer). src/hotspot/os/windows/pdh_interface.cpp line 116: > 114: && _PdhCloseQuery != NULL && PdhCollectQueryData != NULL > 115: && _PdhGetFormattedCounterValue != NULL && _PdhEnumObjectItems != NULL > 116: && _PdhRemoveCounter != NULL && PdhLookupPerfNameByIndex != NULL Shouldn't this also be checking the underscore version ie `_PdhLookupPerfNameByIndex`? ------------- PR: https://git.openjdk.org/jdk/pull/11968 From jwaters at openjdk.org Mon Jan 16 03:45:11 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 16 Jan 2023 03:45:11 GMT Subject: RFR: 8300052: PdhDll::PdhCollectQueryData and PdhLookupPerfNameByIndex will never be NULL In-Reply-To: References: Message-ID: On Mon, 16 Jan 2023 02:59:56 GMT, David Holmes wrote: >> Both PdhDll::PdhCollectQueryData and PdhLookupPerfNameByIndex are concrete definitions and not pointers to executable code (Former is defined by us and the latter is a macro that expands into a concrete declaration), so it makes no sense to check if they will be NULL. The code fails to compile on Windows before this commit when gcc has warnings as errors enabled (-Waddress in this case) >> >> In the case of PdhCollectQueryData I'm assuming the check actually intended to check for _PdhCollectQueryData with the leading underscore, which is actually a pointer and can be NULL. Do correct me if I'm wrong and point me to what the appropriate check would be otherwise > > src/hotspot/os/windows/pdh_interface.cpp line 116: > >> 114: && _PdhCloseQuery != NULL && PdhCollectQueryData != NULL >> 115: && _PdhGetFormattedCounterValue != NULL && _PdhEnumObjectItems != NULL >> 116: && _PdhRemoveCounter != NULL && PdhLookupPerfNameByIndex != NULL > > Shouldn't this also be checking the underscore version ie `_PdhLookupPerfNameByIndex`? Ah, oh dear, I have no idea how I missed that. Will fix as requested ------------- PR: https://git.openjdk.org/jdk/pull/11968 From jwaters at openjdk.org Mon Jan 16 04:00:43 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 16 Jan 2023 04:00:43 GMT Subject: RFR: 8300052: PdhDll::PdhCollectQueryData and PdhLookupPerfNameByIndex will never be NULL [v2] In-Reply-To: References: Message-ID: <0aDtDwPk8wuLh0rYgWFln_VvmPb-cFPgmCiKTvO4tIs=.e7eca0ee-9af9-41fe-9976-3232eff262d0@github.com> > Both PdhDll::PdhCollectQueryData and PdhLookupPerfNameByIndex are concrete definitions and not pointers to executable code (Former is defined by us and the latter is a macro that expands into a concrete declaration), so it makes no sense to check if they will be NULL. The code fails to compile on Windows before this commit when gcc has warnings as errors enabled (-Waddress in this case) > > In the case of PdhCollectQueryData I'm assuming the check actually intended to check for _PdhCollectQueryData with the leading underscore, which is actually a pointer and can be NULL. Do correct me if I'm wrong and point me to what the appropriate check would be otherwise Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Change Checks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11968/files - new: https://git.openjdk.org/jdk/pull/11968/files/d3c8d639..41068a05 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11968&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11968&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11968.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11968/head:pull/11968 PR: https://git.openjdk.org/jdk/pull/11968 From dholmes at openjdk.org Mon Jan 16 04:18:11 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 16 Jan 2023 04:18:11 GMT Subject: RFR: 8300052: PdhDll::PdhCollectQueryData and PdhLookupPerfNameByIndex will never be NULL [v2] In-Reply-To: <0aDtDwPk8wuLh0rYgWFln_VvmPb-cFPgmCiKTvO4tIs=.e7eca0ee-9af9-41fe-9976-3232eff262d0@github.com> References: <0aDtDwPk8wuLh0rYgWFln_VvmPb-cFPgmCiKTvO4tIs=.e7eca0ee-9af9-41fe-9976-3232eff262d0@github.com> Message-ID: On Mon, 16 Jan 2023 04:00:43 GMT, Julian Waters wrote: >> Both PdhDll::PdhCollectQueryData and PdhLookupPerfNameByIndex are concrete definitions and not pointers to executable code (Former is defined by us and the latter is a macro that expands into a concrete declaration), so it makes no sense to check if they will be NULL. The code fails to compile on Windows before this commit when gcc has warnings as errors enabled (-Waddress in this case) >> >> In the case of PdhCollectQueryData I'm assuming the check actually intended to check for _PdhCollectQueryData with the leading underscore, which is actually a pointer and can be NULL. Do correct me if I'm wrong and point me to what the appropriate check would be otherwise > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Change Checks Good catch! Simple typos that were never noticed. There is another one in this assert on line 158: assert(_initialized && PdhExpandWildCardPath != NULL, "PdhAvailable() not yet called"); Thanks ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/11968 From duke at openjdk.org Mon Jan 16 04:31:09 2023 From: duke at openjdk.org (Amit Kumar) Date: Mon, 16 Jan 2023 04:31:09 GMT Subject: RFR: 8299817: [s390] AES-CTR mode intrinsic fails with multiple short update() calls In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 14:29:34 GMT, Lutz Schmidt wrote: > This PR addresses an issue in the AES-CTR mode intrinsic on s390. When a message is ciphered in multiple, small (< 16 bytes) segments, the result is incorrect. > > This is not just a band-aid fix. The issue was taken as a chance to restructure the code. though still complicated, It is now easier to read and (hopefully) understand. > > Except for the new jetreg test, the changes are purely s390. There are no side effects on other platforms. Issue-specific tests pass. Other tests are in progress. I will update this PR once they are complete. > > **Reviews and comments are very much appreciated.** > > @backwaterred could you please run some "official" s390 tests? Thanks. Hi @RealLucy , Sorry for kept you waiting. I've run tests over s390/Z machine and everything seems fine (Test failures I'm seeing were already there even before this PR). But please let me know if anything specific you want me to test, as of now I've run tier1 test in fast & slow debug build for this PR. ------------- PR: https://git.openjdk.org/jdk/pull/11967 From jwaters at openjdk.org Mon Jan 16 04:40:41 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 16 Jan 2023 04:40:41 GMT Subject: RFR: 8300052: PdhDll::PdhCollectQueryData and PdhLookupPerfNameByIndex will never be NULL [v3] In-Reply-To: References: Message-ID: > Both PdhDll::PdhCollectQueryData and PdhLookupPerfNameByIndex are concrete definitions and not pointers to executable code (Former is defined by us and the latter is a macro that expands into a concrete declaration), so it makes no sense to check if they will be NULL. The code fails to compile on Windows before this commit when gcc has warnings as errors enabled (-Waddress in this case) > > In the case of PdhCollectQueryData I'm assuming the check actually intended to check for _PdhCollectQueryData with the leading underscore, which is actually a pointer and can be NULL. Do correct me if I'm wrong and point me to what the appropriate check would be otherwise Julian Waters has updated the pull request incrementally with one additional commit since the last revision: PdhExpandWildCardPath ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11968/files - new: https://git.openjdk.org/jdk/pull/11968/files/41068a05..e67974a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11968&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11968&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11968.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11968/head:pull/11968 PR: https://git.openjdk.org/jdk/pull/11968 From jwaters at openjdk.org Mon Jan 16 05:35:12 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 16 Jan 2023 05:35:12 GMT Subject: RFR: 8300052: PdhDll::PdhCollectQueryData and PdhLookupPerfNameByIndex will never be NULL [v3] In-Reply-To: References: Message-ID: <7OnmnLM3eW9XIe6zCloLE3qAWIu11T3orjpAHgY4zv4=.e3edf243-e437-4e43-93bc-ea0e3cd8ab85@github.com> On Mon, 16 Jan 2023 04:40:41 GMT, Julian Waters wrote: >> Both PdhDll::PdhCollectQueryData and PdhLookupPerfNameByIndex are concrete definitions and not pointers to executable code (Former is defined by us and the latter is a macro that expands into a concrete declaration), so it makes no sense to check if they will be NULL. The code fails to compile on Windows before this commit when gcc has warnings as errors enabled (-Waddress in this case) >> >> In the case of PdhCollectQueryData I'm assuming the check actually intended to check for _PdhCollectQueryData with the leading underscore, which is actually a pointer and can be NULL. Do correct me if I'm wrong and point me to what the appropriate check would be otherwise > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > PdhExpandWildCardPath Alright, done ------------- PR: https://git.openjdk.org/jdk/pull/11968 From dholmes at openjdk.org Mon Jan 16 05:41:10 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 16 Jan 2023 05:41:10 GMT Subject: RFR: 8300052: PdhDll::PdhCollectQueryData and PdhLookupPerfNameByIndex will never be NULL [v3] In-Reply-To: References: Message-ID: <1d6dBLLjuJWN35UfUMJ8YyDO1jC039KsfTjiKKB6CgY=.ece7bc39-aea9-4a4f-9e88-6f7b544e4763@github.com> On Mon, 16 Jan 2023 04:40:41 GMT, Julian Waters wrote: >> Both PdhDll::PdhCollectQueryData and PdhLookupPerfNameByIndex are concrete definitions and not pointers to executable code (Former is defined by us and the latter is a macro that expands into a concrete declaration), so it makes no sense to check if they will be NULL. The code fails to compile on Windows before this commit when gcc has warnings as errors enabled (-Waddress in this case) >> >> In the case of PdhCollectQueryData I'm assuming the check actually intended to check for _PdhCollectQueryData with the leading underscore, which is actually a pointer and can be NULL. Do correct me if I'm wrong and point me to what the appropriate check would be otherwise > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > PdhExpandWildCardPath Looks good. Thanks for the update. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/11968 From jwaters at openjdk.org Mon Jan 16 06:02:13 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 16 Jan 2023 06:02:13 GMT Subject: RFR: 8300052: PdhDll::PdhCollectQueryData and PdhLookupPerfNameByIndex will never be NULL [v3] In-Reply-To: References: Message-ID: On Mon, 16 Jan 2023 04:40:41 GMT, Julian Waters wrote: >> Both PdhDll::PdhCollectQueryData and PdhLookupPerfNameByIndex are concrete definitions and not pointers to executable code (Former is defined by us and the latter is a macro that expands into a concrete declaration), so it makes no sense to check if they will be NULL. The code fails to compile on Windows before this commit when gcc has warnings as errors enabled (-Waddress in this case) >> >> In the case of PdhCollectQueryData I'm assuming the check actually intended to check for _PdhCollectQueryData with the leading underscore, which is actually a pointer and can be NULL. Do correct me if I'm wrong and point me to what the appropriate check would be otherwise > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > PdhExpandWildCardPath Thanks for the review David! Will integrate after I apply these changes locally so that I don't completely wreck my local branches ------------- PR: https://git.openjdk.org/jdk/pull/11968 From jwaters at openjdk.org Mon Jan 16 06:08:12 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 16 Jan 2023 06:08:12 GMT Subject: RFR: 8300052: PdhDll::PdhCollectQueryData and PdhLookupPerfNameByIndex will never be NULL [v3] In-Reply-To: References: Message-ID: On Mon, 16 Jan 2023 04:40:41 GMT, Julian Waters wrote: >> Both PdhDll::PdhCollectQueryData and PdhLookupPerfNameByIndex are concrete definitions and not pointers to executable code (Former is defined by us and the latter is a macro that expands into a concrete declaration), so it makes no sense to check if they will be NULL. The code fails to compile on Windows before this commit when gcc has warnings as errors enabled (-Waddress in this case) >> >> In the case of PdhCollectQueryData I'm assuming the check actually intended to check for _PdhCollectQueryData with the leading underscore, which is actually a pointer and can be NULL. Do correct me if I'm wrong and point me to what the appropriate check would be otherwise > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > PdhExpandWildCardPath Done. Will integrate now and then watch in dismay at the limitations of GitHub's Pulls API > Good catch! Simple typos that were never noticed. Haha, gcc did most of the actual work catching those oversights, not me ;) ------------- PR: https://git.openjdk.org/jdk/pull/11968 From jwaters at openjdk.org Mon Jan 16 06:11:15 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 16 Jan 2023 06:11:15 GMT Subject: Integrated: 8300052: PdhDll::PdhCollectQueryData and PdhLookupPerfNameByIndex will never be NULL In-Reply-To: References: Message-ID: <2NhrtPL6RxTckilZkGH9aOObe_S6mXKgVAeeAwLK5eg=.1f011e36-f335-47c3-b7ad-d965b107071b@github.com> On Thu, 12 Jan 2023 15:21:37 GMT, Julian Waters wrote: > Both PdhDll::PdhCollectQueryData and PdhLookupPerfNameByIndex are concrete definitions and not pointers to executable code (Former is defined by us and the latter is a macro that expands into a concrete declaration), so it makes no sense to check if they will be NULL. The code fails to compile on Windows before this commit when gcc has warnings as errors enabled (-Waddress in this case) > > In the case of PdhCollectQueryData I'm assuming the check actually intended to check for _PdhCollectQueryData with the leading underscore, which is actually a pointer and can be NULL. Do correct me if I'm wrong and point me to what the appropriate check would be otherwise This pull request has now been integrated. Changeset: 12edd6f9 Author: Julian Waters URL: https://git.openjdk.org/jdk/commit/12edd6f922195f193659814d6c37c361c83e6797 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8300052: PdhDll::PdhCollectQueryData and PdhLookupPerfNameByIndex will never be NULL Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/11968 From jwaters at openjdk.org Mon Jan 16 06:16:31 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 16 Jan 2023 06:16:31 GMT Subject: RFR: 8250269: Replace ATTRIBUTE_ALIGNED with alignas [v13] In-Reply-To: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com> References: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com> Message-ID: > 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 12 additional commits since the last revision: - 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 - ATTRIBUTE_ALIGNED(16) - Merge branch 'openjdk:master' into alignas - Merge branch 'openjdk:master' into alignas - ... and 2 more: https://git.openjdk.org/jdk/compare/5a525107...7792baa5 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11431/files - new: https://git.openjdk.org/jdk/pull/11431/files/8112c286..7792baa5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11431&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11431&range=11-12 Stats: 4080 lines in 119 files changed: 2742 ins; 722 del; 616 mod Patch: https://git.openjdk.org/jdk/pull/11431.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11431/head:pull/11431 PR: https://git.openjdk.org/jdk/pull/11431 From jwaters at openjdk.org Mon Jan 16 06:38:10 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 16 Jan 2023 06:38:10 GMT Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof In-Reply-To: References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com> Message-ID: On Thu, 22 Dec 2022 20:04:17 GMT, Kim Barrett wrote: > An obvious use-case was for computing the alignment of a type for use in > ATTRIBUTE_ALIGNED (which currently has compiler-specific implementations that > only support alignment values, though see JDK-8250269). But since we can now > use `alignas` directly (JDK-8297912), that's no longer important. Side tangent while speaking of 8297912, is the corresponding change at https://github.com/openjdk/jdk/pull/11431 sufficient or are there more corner cases to consider? ------------- PR: https://git.openjdk.org/jdk/pull/11761 From fjiang at openjdk.org Mon Jan 16 06:38:35 2023 From: fjiang at openjdk.org (Feilong Jiang) Date: Mon, 16 Jan 2023 06:38:35 GMT Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory API (Preview) [v7] In-Reply-To: References: Message-ID: > Add experimental Foreign Function & Memory API support for RISC-V. > > For details of the FFM API RISC-V port please refer to [JBS issue](https://bugs.openjdk.org/browse/JDK-8293841) > > Testing: > > - [x] jdk_foreign with release/fastdebug build on linux-riscv64 > - [x] jdk_foreign with release/fastdebug build on linux-x64 > - [x] jdk_foreign with release/fastdebug build on linux-aarch64 Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision: more code style adjustment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11004/files - new: https://git.openjdk.org/jdk/pull/11004/files/be0826db..c4809317 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11004&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11004&range=05-06 Stats: 17 lines in 1 file changed: 1 ins; 15 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11004.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11004/head:pull/11004 PR: https://git.openjdk.org/jdk/pull/11004 From fyang at openjdk.org Mon Jan 16 06:47:10 2023 From: fyang at openjdk.org (Fei Yang) Date: Mon, 16 Jan 2023 06:47:10 GMT Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory API (Preview) [v7] In-Reply-To: References: Message-ID: On Mon, 16 Jan 2023 06:38:35 GMT, Feilong Jiang wrote: >> Add experimental Foreign Function & Memory API support for RISC-V. >> >> For details of the FFM API RISC-V port please refer to [JBS issue](https://bugs.openjdk.org/browse/JDK-8293841) >> >> Testing: >> >> - [x] jdk_foreign with release/fastdebug build on linux-riscv64 >> - [x] jdk_foreign with release/fastdebug build on linux-x64 >> - [x] jdk_foreign with release/fastdebug build on linux-aarch64 > > Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision: > > more code style adjustment Looks good to me. This also passed tier1-4 tests on my HiFive Unmatched boards. ------------- Marked as reviewed by fyang (Reviewer). PR: https://git.openjdk.org/jdk/pull/11004 From duke at openjdk.org Mon Jan 16 07:19:09 2023 From: duke at openjdk.org (Damon Fenacci) Date: Mon, 16 Jan 2023 07:19:09 GMT Subject: RFR: JDK-8293410: Remove GenerateRangeChecks flag In-Reply-To: References: Message-ID: <2BImzMS6yjuBu62mR9IZw1IB4DuilusxuHLKVpKW26U=.364afffa-1c8f-40fe-869d-ba2d8bc3fa4e@github.com> On Fri, 13 Jan 2023 07:11:35 GMT, Tobias Hartmann wrote: >> The JVM crashes with an assertion failure when array range checks are disabled using `-XX:-GenerateRangeChecks` and we're trying to access the array with an index outside its boundaries. >> >> Such a behaviour is actually expected. What is unclear is the reason for having a _GenerateRangeChecks_ flag (basically to force not to perform range checks). An inspection of the change that introduced the flag didn't clarify its original use-case. >> >> So, removing the `GenerateRangeChecks` flag. > > Looks good to me! @TobiHartmann @chhagedorn thanks for your reviews and @vnkozlov for your explanation as well! ------------- PR: https://git.openjdk.org/jdk/pull/11964 From thartmann at openjdk.org Mon Jan 16 07:35:11 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 16 Jan 2023 07:35:11 GMT Subject: RFR: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions [v5] In-Reply-To: References: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> <8RiIpov3KBqW1zB_HHqW0_ELy9K3PjYpfcAyOL83t0U=.ebead259-f9a9-45ca-98b0-01cbfa0354a5@github.com> Message-ID: On Fri, 13 Jan 2023 19:16:04 GMT, Sergey Kuksenko wrote: > I thought about it. The issue is naming. "instructions_size" says nothing about the fact that nop instructions were excluded. On the other side using "inline_instructions_size" in ciMethod::has_compiled_code() looks weird. I am open to any suggestions. I think this is just a matter of how we define "instruction size". We could simply define it as not including oops. I would prefer to rename the existing usages to `inline_instructions_size` though. `ciMethod::has_compiled_code()` is only used in the context of "should (not) inline", we could rename it as well. I see that Vladimir suggested the same. @vnkozlov, regarding > You missed ciReplay change to record _inline_instructions_size and restore it. That is what is used in inlining decision in your changes. We currently don't record/restore `_instructions_size` in replay compilation either, probably because inlining decisions are enforced explicitly: https://github.com/openjdk/jdk/blob/9f24a6f43c6a5e1fa92275e0a87af4f1f0603ba3/src/hotspot/share/ci/ciReplay.cpp#L1531-L1532 But I agree that it's better to be consistent here. ------------- PR: https://git.openjdk.org/jdk/pull/11958 From duke at openjdk.org Mon Jan 16 07:37:19 2023 From: duke at openjdk.org (Damon Fenacci) Date: Mon, 16 Jan 2023 07:37:19 GMT Subject: Integrated: JDK-8293410: Remove GenerateRangeChecks flag In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 11:32:54 GMT, Damon Fenacci wrote: > The JVM crashes with an assertion failure when array range checks are disabled using `-XX:-GenerateRangeChecks` and we're trying to access the array with an index outside its boundaries. > > Such a behaviour is actually expected. What is unclear is the reason for having a _GenerateRangeChecks_ flag (basically to force not to perform range checks). An inspection of the change that introduced the flag didn't clarify its original use-case. > > So, removing the `GenerateRangeChecks` flag. This pull request has now been integrated. Changeset: 83f2c9a2 Author: Damon Fenacci Committer: Tobias Hartmann URL: https://git.openjdk.org/jdk/commit/83f2c9a2b290f11fbfb118a22c9667f26ac7c516 Stats: 9 lines in 3 files changed: 0 ins; 3 del; 6 mod 8293410: Remove GenerateRangeChecks flag Reviewed-by: thartmann, chagedorn, kvn ------------- PR: https://git.openjdk.org/jdk/pull/11964 From alanb at openjdk.org Mon Jan 16 08:22:15 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 16 Jan 2023 08:22:15 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v9] In-Reply-To: References: Message-ID: On Mon, 16 Jan 2023 00:39:33 GMT, David Holmes wrote: >> Apparently it is not needed so removed in 38ea7997be2be59e2cea97c7dabf929210c0edfa. > > No wonder I couldn't find this change! The catch of OOME was added because I still believe that trying to allocate a buffer of capacity Integer.MAX_VALUE will throw OOME (at least some of the time). If that happens then the test should not fail. No objection to having the test pass if malloc fails but it would be better if the native newDirectByteBuffer were changed to just call JNI NewDirectByteBuffer with a given address so that the malloc + JNI function aren't in the same native method. That allows the test to distinguish malloc returning NULl from NewDirectByteBuffer throwing OOME. The native method freeDirectByteBufferMemory can be split too so that there is native method get the direct buffer address. With these changes, the test can use Unsafe allocateMemory/freeMemory (changing to FFM APIs in the future) or have native methods that do the malloc/free. The more basic methods means the test can be improved, e.g. checkBuffer doesn't currently test that GetDirectBufferAddress returns the address that the DBB was created to wrap. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From alanb at openjdk.org Mon Jan 16 08:24:10 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 16 Jan 2023 08:24:10 GMT Subject: RFR: 8300169: Build failure with clang-15 In-Reply-To: References: Message-ID: On Sat, 14 Jan 2023 14:28:32 GMT, Jie Fu wrote: > It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN. Is there a list of the issues building libjli? I don't see the in the PR or the JBS issue. For the libzip issues, are these in the native methods or when compiling the zlib code, just wondering if there are bug reports for upstream there too. ------------- PR: https://git.openjdk.org/jdk/pull/12005 From lucy at openjdk.org Mon Jan 16 08:40:09 2023 From: lucy at openjdk.org (Lutz Schmidt) Date: Mon, 16 Jan 2023 08:40:09 GMT Subject: RFR: 8299817: [s390] AES-CTR mode intrinsic fails with multiple short update() calls In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 14:29:34 GMT, Lutz Schmidt wrote: > This PR addresses an issue in the AES-CTR mode intrinsic on s390. When a message is ciphered in multiple, small (< 16 bytes) segments, the result is incorrect. > > This is not just a band-aid fix. The issue was taken as a chance to restructure the code. though still complicated, It is now easier to read and (hopefully) understand. > > Except for the new jetreg test, the changes are purely s390. There are no side effects on other platforms. Issue-specific tests pass. Other tests are in progress. I will update this PR once they are complete. > > **Reviews and comments are very much appreciated.** > > @backwaterred could you please run some "official" s390 tests? Thanks. Thank you for testing, Amit. In addition to that, an identical version of the code runs in our internal tests for our commercial product. Everything is fine there as well. ------------- PR: https://git.openjdk.org/jdk/pull/11967 From jiefu at openjdk.org Mon Jan 16 08:54:10 2023 From: jiefu at openjdk.org (Jie Fu) Date: Mon, 16 Jan 2023 08:54:10 GMT Subject: RFR: 8300169: Build failure with clang-15 In-Reply-To: References: Message-ID: On Mon, 16 Jan 2023 08:21:47 GMT, Alan Bateman wrote: > Is there a list of the issues building libjli? I don't see the in the PR or the JBS issue. For the libzip issues, are these in the native methods or when compiling the zlib code, just wondering if there are bug reports for upstream there too. Thanks @AlanBateman for the review. Here is the bug report while building libjli (target support_native_java.base_libjli_zadler32.o). 1 error generated. * For target support_native_java.base_libjli_zadler32.o: ------------- PR: https://git.openjdk.org/jdk/pull/12005 From jiefu at openjdk.org Mon Jan 16 08:59:10 2023 From: jiefu at openjdk.org (Jie Fu) Date: Mon, 16 Jan 2023 08:59:10 GMT Subject: RFR: 8300169: Build failure with clang-15 In-Reply-To: References: Message-ID: <6Mm3-SXiwwATYs4GgS9dCU-bPbj1C2zLMJffm7vgTYk=.ac455538-e0e0-4af7-ae87-af7c778d23e9@github.com> On Mon, 16 Jan 2023 08:51:34 GMT, Jie Fu wrote: > For the libzip issues, are these in the native methods or when compiling the zlib code, just wondering if there are bug reports for upstream there too. Mainly caused by files under `src/java.base/share/native/libzip/zlib/`. I'm not sure if there is already a bug report to the upstream. ------------- PR: https://git.openjdk.org/jdk/pull/12005 From alanb at openjdk.org Mon Jan 16 09:06:10 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 16 Jan 2023 09:06:10 GMT Subject: RFR: 8300169: Build failure with clang-15 In-Reply-To: <6Mm3-SXiwwATYs4GgS9dCU-bPbj1C2zLMJffm7vgTYk=.ac455538-e0e0-4af7-ae87-af7c778d23e9@github.com> References: <6Mm3-SXiwwATYs4GgS9dCU-bPbj1C2zLMJffm7vgTYk=.ac455538-e0e0-4af7-ae87-af7c778d23e9@github.com> Message-ID: On Mon, 16 Jan 2023 08:56:13 GMT, Jie Fu wrote: > Mainly caused by files under `src/java.base/share/native/libzip/zlib/`. I'm not sure if there is already a bug report to the upstream. Maybe this one: https://github.com/madler/zlib/issues/633 ------------- PR: https://git.openjdk.org/jdk/pull/12005 From duke at openjdk.org Mon Jan 16 09:18:51 2023 From: duke at openjdk.org (Afshin Zafari) Date: Mon, 16 Jan 2023 09:18:51 GMT Subject: RFR: 8299213: Bad cast in GrowableArrayWithAllocator<>::grow Message-ID: ### Description The grow size was wrongfully casted from `int` to `uint32`. ### Patch The casting is removed. ### Tests Local: **gtest:GrowableArrays*** mach5 tier1-5 ------------- Commit messages: - 8299213: Bad cast in GrowableArrayWithAllocator<>::grow Changes: https://git.openjdk.org/jdk/pull/12007/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12007&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299213 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12007.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12007/head:pull/12007 PR: https://git.openjdk.org/jdk/pull/12007 From aboldtch at openjdk.org Mon Jan 16 09:33:13 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 16 Jan 2023 09:33:13 GMT Subject: RFR: 8299089: Instrument global jni handles with tag to make them distinguishable In-Reply-To: References: Message-ID: On Wed, 21 Dec 2022 09:40:56 GMT, David Holmes wrote: >> Weak global jni handles are tagged so the GC can distinguish them when resolving the object. Today there is no cheap way of distinguishing global jni handles from local jni handles. For generational ZGC the OopStorage handles and the thread local handles semantical difference requires the handles to be distinguishable. >> >> This enhancements instruments the jni handles with a global tag similarly to the jweak tag. >> >> Note: >> * the s390 implementation has minimal changes and requires improvement. >> * There is room for enchantment here to create the same abstraction that ppc uses for all platforms, i.e. move the resolve_jobject from the MacroAssembler to the BarrierSetAssembler which allows for more optimised code for GCs that can treat local and global handles the same. >> >> Testing: GHA. Oracle supported platforms tier1-3. Will run higher tiers. Has also been tested on the generational branch of ZGC for over three months. Requires testing on non Oracle platforms. > >> Today there is no cheap way of distinguishing global jni handles from local jni handles. > > So is the code you added "cheap"? Else what is the performance hit for adding this? Thanks. @dholmes-ora Ran a suite of microbenchmarks, SPECxxx and Renaissance benchmarks. Could not see any significant change. If there is some other benchmark / tests that tests the JNI performance more heavily that you want run? @fisk and @stefank Changed some of the names and asserts based on @albertnetymk's feedback. Given that this change touches all platforms, do porters have any comments? The changeset has been tested on generational ZGC for PPC by @TheRealMDoerr ------------- PR: https://git.openjdk.org/jdk/pull/11740 From jsjolen at openjdk.org Mon Jan 16 09:54:11 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 16 Jan 2023 09:54:11 GMT Subject: RFR: 8299213: Bad cast in GrowableArrayWithAllocator<>::grow In-Reply-To: References: Message-ID: <0IfO97B0uwJ7tXO3rPIWpUepxIXPoCOaw2wb7xuecjk=.a9bbffb9-cb4b-4dae-81a7-a85f652ca558@github.com> On Mon, 16 Jan 2023 09:11:19 GMT, Afshin Zafari wrote: > ### Description > The grow size was wrongfully casted from `int` to `uint32`. > > ### Patch > The casting is removed. > > ### Tests > Local: **gtest:GrowableArrays*** > mach5 tier1-5 // precondition: if signed, value >= 0. // precondition: value < maximum power of two representable by T. template ::value)> inline T next_power_of_2(T value) { So this should require an assert that `j >= 0`. ------------- PR: https://git.openjdk.org/jdk/pull/12007 From johan.sjolen at oracle.com Mon Jan 16 10:32:06 2023 From: johan.sjolen at oracle.com (=?UTF-8?B?Sm9oYW4gU2rDtmzDqW4=?=) Date: Mon, 16 Jan 2023 11:32:06 +0100 Subject: En masse conversion from NULL to nullptr Message-ID: Hi Hotspot devs, For the beginning of 2023 us at Oracle want to make a push to convert NULL into nullptr. This is something that has been in the works for some time, where conversions have been made as part of other PRs in a "change as you go" approach. This is taking a long time and there are tensions between local consistency and not cluttering reviews with cleanup changes. We'd therefore like to finish the job, so instead we will be creating PRs which solely do this conversion. David Holmes has created a task for this (JDK-8299837) and subtasks are added for each subdirectory. Therefore one subdirectory will be converted in a single PR. This will keep PR sizes down and split the reviewing up. I will be the one creating the subtasks and PRs. After these changes you might have "legitimate" merge conflicts mixed in with NULL/nullptr conflicts if you merge directly to HEAD. In order to deal with the legitimate conflicts first, I suggest that you: 1. Merge on top of the commit just before the NULL/nullptr conversion that causes issues. 2. Merge on top of the NULL/nullptr conversion commit 3. Merge the rest of the way to HEAD Best regards, Johan Sj?l?n From lkorinth at openjdk.org Mon Jan 16 11:09:46 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 16 Jan 2023 11:09:46 GMT Subject: RFR: 8296401: ConcurrentHashTable::bulk_delete might miss to delete some objects [v7] In-Reply-To: References: Message-ID: > ConcurrentHashTable::bulk_delete might miss to delete some objects if a bucket has more than 256 entries. Current uses of ConcurrentHashTable are not harmed by this behaviour. > > I modified gtest:ConcurrentHashTable to detect the problem (first commit), and fixed the problem in the code (second commit). > > Tests passes tier1-3. Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: rerun test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10983/files - new: https://git.openjdk.org/jdk/pull/10983/files/b9d8b105..a4d5b80f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10983&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10983&range=05-06 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10983.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10983/head:pull/10983 PR: https://git.openjdk.org/jdk/pull/10983 From eosterlund at openjdk.org Mon Jan 16 11:32:52 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 16 Jan 2023 11:32:52 GMT Subject: RFR: 8299673: Simplify object pinning interactions with string deduplication [v2] In-Reply-To: References: Message-ID: > When raw char* String contents are exposed to JNI code, we > > 1. Load the string.value and pin it > 2. Run native code > 3. Load the string.value and unpin it > > Given this sequence we would be in trouble if between 1 and 3, string deduplication changed the value object. Then the pinning and unpinning wouldn't be balanced. > > The current approach for dealing with this is to have a bunch of code to guard against deduplication. An alternative simpler solution is to just change step 3 to pass in the same value. We already have enough information available to do that. Then the pinning and unpinning is also balanced, and we don't need to have any special interactions with string deduplication and can decouple these orthogonal concerns. > > It's worth noting though that the contract of pin_object now makes it explicit that pinned objects must not be recycled, even if not otherwise reachable. That seems to come naturally for region based pinning, but is worth keeping in mind. The exposed char* might be the only thing referencing the string value when string dedup happens concurrently. Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Include sorting order - Merge branch 'master' into 8299673_pin_dedup - More Kim feedback - Feedback from Kim - 8299673: Simplify object pinning interactions with string deduplication ------------- Changes: https://git.openjdk.org/jdk/pull/11923/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11923&range=01 Stats: 153 lines in 14 files changed: 65 ins; 68 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/11923.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11923/head:pull/11923 PR: https://git.openjdk.org/jdk/pull/11923 From duke at openjdk.org Mon Jan 16 11:34:47 2023 From: duke at openjdk.org (Fredrik Bredberg) Date: Mon, 16 Jan 2023 11:34:47 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v3] In-Reply-To: References: Message-ID: > Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. > Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. > Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: Added references to JDK-8300197 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11902/files - new: https://git.openjdk.org/jdk/pull/11902/files/54a0931d..ac821a10 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11902&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11902&range=01-02 Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/11902.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11902/head:pull/11902 PR: https://git.openjdk.org/jdk/pull/11902 From duke at openjdk.org Mon Jan 16 12:40:17 2023 From: duke at openjdk.org (Afshin Zafari) Date: Mon, 16 Jan 2023 12:40:17 GMT Subject: Integrated: 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug In-Reply-To: References: Message-ID: On Fri, 16 Dec 2022 07:56:39 GMT, Afshin Zafari wrote: > ### Description > The following problems found and solved: > > 1) Reporting which regex pattern did not match with error messages was incorrect. To report the mismatched pattern, the head of the pattern list was peeked, while it was the already peeked item from that did not match. So the next pattern to the mismatched one was reported. > > 2) The pattern for finding a crash was incorrectly set to "# .*VMError::controlled_crash.*", while it has to be "# .*crash_with_segfault.*". > > 3) `crash_with_segfault` function is too small and was `inline`d in compiler optimisations. So it was not in the stack trace when the error message is created. > > ### Patch > 1 and 2 corrected and added the `NOINLINE` to the `crash_with_segfault` signature. The same applied for `crash_with_sigfpe` function. > > ### Test > runtime/ErrorHandling/* and tier1-5 This pull request has now been integrated. Changeset: 289aed46 Author: Afshin Zafari Committer: Robbin Ehn URL: https://git.openjdk.org/jdk/commit/289aed465e9b8449938d4cdb515748e7aca1d070 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug Reviewed-by: dcubed, dholmes, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/11704 From lkorinth at openjdk.org Mon Jan 16 13:15:38 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 16 Jan 2023 13:15:38 GMT Subject: RFR: 8296401: ConcurrentHashTable::bulk_delete might miss to delete some objects [v8] In-Reply-To: References: Message-ID: > ConcurrentHashTable::bulk_delete might miss to delete some objects if a bucket has more than 256 entries. Current uses of ConcurrentHashTable are not harmed by this behaviour. > > I modified gtest:ConcurrentHashTable to detect the problem (first commit), and fixed the problem in the code (second commit). > > Tests passes tier1-3. Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: - Merge branch '_master_jdk' into _8296401_ConcurrentHashTable - rerun test - growable array is limited by (signed) int, this should not be a problem - GrowableArray is indexed by int :-( - renam stack limit, and add comments - Make ndel a reference to a pointer so that we can poison it. Also fix POISON_PTR to be of correct type (the pointer is const, not the memory pointed to). - fix counting bug - growable stacked - Revert "working!" This reverts commit 5366f22c7202eaa2182976c084d02e9af4f56de0. - working! - ... and 1 more: https://git.openjdk.org/jdk/compare/e2024092...1b91238a ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10983/files - new: https://git.openjdk.org/jdk/pull/10983/files/a4d5b80f..1b91238a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10983&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10983&range=06-07 Stats: 234939 lines in 4112 files changed: 105205 ins; 99231 del; 30503 mod Patch: https://git.openjdk.org/jdk/pull/10983.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10983/head:pull/10983 PR: https://git.openjdk.org/jdk/pull/10983 From rehn at openjdk.org Mon Jan 16 13:15:38 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Mon, 16 Jan 2023 13:15:38 GMT Subject: RFR: 8296401: ConcurrentHashTable::bulk_delete might miss to delete some objects [v8] In-Reply-To: References: Message-ID: On Mon, 16 Jan 2023 13:11:18 GMT, Leo Korinth wrote: >> ConcurrentHashTable::bulk_delete might miss to delete some objects if a bucket has more than 256 entries. Current uses of ConcurrentHashTable are not harmed by this behaviour. >> >> I modified gtest:ConcurrentHashTable to detect the problem (first commit), and fixed the problem in the code (second commit). >> >> Tests passes tier1-3. > > Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - Merge branch '_master_jdk' into _8296401_ConcurrentHashTable > - rerun test > - growable array is limited by (signed) int, this should not be a problem > - GrowableArray is indexed by int :-( > - renam stack limit, and add comments > - Make ndel a reference to a pointer so that we can poison it. Also fix > POISON_PTR to be of correct type (the pointer is const, not the memory > pointed to). > - fix counting bug > - growable stacked > - Revert "working!" > > This reverts commit 5366f22c7202eaa2182976c084d02e9af4f56de0. > - working! > - ... and 1 more: https://git.openjdk.org/jdk/compare/e2024092...1b91238a Marked as reviewed by rehn (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10983 From duke at openjdk.org Mon Jan 16 13:41:13 2023 From: duke at openjdk.org (Fredrik Bredberg) Date: Mon, 16 Jan 2023 13:41:13 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v2] In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 16:47:59 GMT, Coleen Phillimore wrote: >> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated some copyright dates. > > src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 306: > >> 304: // set relativized locals >> 305: // this line can be changed into an assert when we have fixed the "frame padding problem" >> 306: *f.addr_at(frame::interpreter_frame_locals_offset) = (bottom - 1) - f.fp(); > > Thank you for this comment. When you file the CR for this problem, can you point to this CR? Created JDK-8300197 and added references in the source to i. ------------- PR: https://git.openjdk.org/jdk/pull/11902 From coleenp at openjdk.org Mon Jan 16 13:51:18 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 16 Jan 2023 13:51:18 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v10] In-Reply-To: <1vK1PJLqYXa1wlcJrSnyFjtiumgX_nb8G178zv3X-c8=.ea74be21-8518-41d8-8fba-f2f5d6267a44@github.com> References: <1vK1PJLqYXa1wlcJrSnyFjtiumgX_nb8G178zv3X-c8=.ea74be21-8518-41d8-8fba-f2f5d6267a44@github.com> Message-ID: On Wed, 11 Jan 2023 10:49:59 GMT, Afshin Zafari wrote: >> test of tier1-5 passed. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8292741: Convert JvmtiTagMapTable to ResourceHashtable I have no further comments. This patch passes testing tier 1-7 for me. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/11288 From jsjolen at openjdk.org Mon Jan 16 14:34:18 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 16 Jan 2023 14:34:18 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v2] In-Reply-To: References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> Message-ID: On Tue, 6 Dec 2022 07:07:33 GMT, Thomas Stuefe wrote: >> Rework NMT `MallocLimit` to make it more useful for native OOM analysis. Also remove `MallocMaxTestWords`, which had been mostly redundant with NMT (for background, see JDK-8293292). >> >> >> ### Background >> >> Some months ago we had [JDK-8291919](https://bugs.openjdk.org/browse/JDK-8291919), a compiler regression that caused compiler arenas to grow boundlessly. Process was usually OOM-killed before we could take a look, so this was difficult to analyze. >> >> To improve analysis options, we added NMT *malloc limits* with [JDK-8291878](https://bugs.openjdk.org/browse/JDK-8291878). Malloc limits let us set one or multiple limits to malloc load. Surpassing a limit causes the VM to stop with a fatal error in the allocation function, giving us a hs-err file and a core right at the point that (probably) causes the leak. This makes error analysis a lot simpler, and is also valuable for regression-testing footprint usage. >> >> Some people wished for a way to not end with a fatal error but to mimic a native OOM (causing os::malloc to return NULL). This would allow us to test resilience in the face of native OOMs, among other things. >> >> ### Patch >> >> - Expands the `MallocLimit` option syntax, allowing for an "oom mode" that mimics an oom: >> >> >> >> Global form: >> -XX:MallocLimit=[:] >> Category-specific form: >> -XX:MallocLimit=:[:][,:[:] ...] >> Examples: >> -XX:MallocLimit=3g >> -XX:MallocLimit=3g:oom >> -XX:MallocLimit=compiler:200m:oom >> >> >> - moves parsing of `-XX:MallocLimit` out of arguments.cpp into `mallocLimit.hpp/cpp`, and rewrites it. >> >> - changes when limits are checked. Before, the limits were checked *after* the allocation that caused the threshold overflow. Now we check beforehand. >> >> - removes `MallocMaxTestWords`, replacing its uses with `MallocLimit` >> >> - adds new gtests and new jtreg tests >> >> - removes a bunch of jtreg tests which are now better served by the new gtests. >> >> - gives us more precise error messages upon reaching a limit. For example: >> >> before: >> >> # fatal error: MallocLimit: category "Compiler" reached limit (size: 20997680, limit: 20971520) >> >> >> now: >> >> # fatal error: MallocLimit: reached category "Compiler" limit (triggering allocation size: 1920B, allocated so far: 20505K, limit: 20480K) > > 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 two additional commits since the last revision: > > - Merge branch 'master' into JDK-8293313-NMT-fake-oom > - MallocLimit This looks good. I've added some nits for style and a couple of comments concerning style which aren't nits. Logic wise, easy to follow and straight forward code, I could find nothing to complain about. src/hotspot/share/services/mallocLimit.cpp line 43: > 41: const char* const _s; > 42: const char* const _end; > 43: const char* _p; Please add a comment for what these are! Or a general idea of what occurs (I assume `_p == _end` means that parsing has succeeded?) src/hotspot/share/services/mallocLimit.cpp line 53: > 51: // Advance position on match. > 52: bool match_mode_flag(malloclimit_mode_t* out) { > 53: if (!eof()) { Nit: Swapping the branch condition avoids indenting the main body of code: if (eof()) return false; // Go on without else branch src/hotspot/share/services/mallocLimit.cpp line 71: > 69: bool match_category(MEMFLAGS* out) { > 70: if (!eof()) { > 71: const char* end = strchr(_p, ':'); Nit: This is `strchrnul` src/hotspot/share/services/mallocLimit.hpp line 33: > 31: #include "utilities/globalDefinitions.hpp" > 32: > 33: enum class malloclimit_mode_t { Can we use Hotspot style (`MallocLimitMode`) for this and `malloclimit_t`? src/hotspot/share/services/mallocLimit.hpp line 40: > 38: struct malloclimit_t { > 39: size_t v; // Limit size > 40: malloclimit_mode_t f; // Behavior flags Nit: `sz` and `lim` are short names that still gives more info than `v`, which is nice when reading the code. test/hotspot/gtest/nmt/test_nmt_malloclimit.cpp line 57: > 55: > 56: static void test(const char* s, const MallocLimitSet& expected) { > 57: // LOG_HERE("%s", s); Seems like a left over from development. test/hotspot/gtest/nmt/test_nmt_malloclimit.cpp line 60: > 58: MallocLimitSet set; > 59: const char* err; > 60: ASSERT_TRUE(set.parse_malloclimit_option(s, &err)) << err; Using EXPECT would let the test proceed, is it necessary to use ASSERT here? test/hotspot/gtest/nmt/test_nmt_malloclimit.cpp line 82: > 80: } > 81: > 82: TEST(NMT, malloclimit_per_category) { >malloclimit_per_category Can we use CamelCase for test case names instead? This is a convention that we *should* use for gtest: http://google.github.io/googletest/faq.html Unfortunately, we don't consistently do this, but I do want to avoid introducing new instances of this. test/hotspot/jtreg/runtime/Unsafe/Reallocate.java line 65: > 63: // Make sure we can throw an OOME when we fail to reallocate due to OOM > 64: try { > 65: unsafe.reallocateMemory(address, 100 * 1024 * 1024); Why are we changing the test here? Just because 800m is a lot larger than the required 100m? ------------- PR: https://git.openjdk.org/jdk/pull/11371 From stuefe at openjdk.org Mon Jan 16 16:22:14 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 16 Jan 2023 16:22:14 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v2] In-Reply-To: References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> Message-ID: On Mon, 16 Jan 2023 11:09:50 GMT, Johan Sj?len wrote: >> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8293313-NMT-fake-oom >> - MallocLimit > > src/hotspot/share/services/mallocLimit.hpp line 33: > >> 31: #include "utilities/globalDefinitions.hpp" >> 32: >> 33: enum class malloclimit_mode_t { > > Can we use Hotspot style (`MallocLimitMode`) for this and `malloclimit_t`? Well, `MallocLimit` would class with the option name. I'll think of something. ------------- PR: https://git.openjdk.org/jdk/pull/11371 From stuefe at openjdk.org Mon Jan 16 16:28:13 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 16 Jan 2023 16:28:13 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v2] In-Reply-To: References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> Message-ID: On Mon, 16 Jan 2023 11:22:12 GMT, Johan Sj?len wrote: >> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8293313-NMT-fake-oom >> - MallocLimit > > src/hotspot/share/services/mallocLimit.cpp line 43: > >> 41: const char* const _s; >> 42: const char* const _end; >> 43: const char* _p; > > Please add a comment for what these are! Or a general idea of what occurs (I assume `_p == _end` means that parsing has succeeded?) It means end of input, eol. The ParserHelper is dumb, it does not know what successful parsing is. It just extracts stuff. > src/hotspot/share/services/mallocLimit.hpp line 40: > >> 38: struct malloclimit_t { >> 39: size_t v; // Limit size >> 40: malloclimit_mode_t f; // Behavior flags > > Nit: `sz` and `lim` are short names that still gives more info than `v`, which is nice when reading the code. Sure ------------- PR: https://git.openjdk.org/jdk/pull/11371 From stuefe at openjdk.org Mon Jan 16 16:35:14 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 16 Jan 2023 16:35:14 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v2] In-Reply-To: References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> Message-ID: On Mon, 16 Jan 2023 14:19:23 GMT, Johan Sj?len wrote: >> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8293313-NMT-fake-oom >> - MallocLimit > > test/hotspot/gtest/nmt/test_nmt_malloclimit.cpp line 57: > >> 55: >> 56: static void test(const char* s, const MallocLimitSet& expected) { >> 57: // LOG_HERE("%s", s); > > Seems like a left over from development. I often leave these in at neuralgic points to quickly analyze problems, they use the LOG_HERE macro in testutils.hpp. But I can remove it. ------------- PR: https://git.openjdk.org/jdk/pull/11371 From lkorinth at openjdk.org Mon Jan 16 16:40:14 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 16 Jan 2023 16:40:14 GMT Subject: Integrated: 8296401: ConcurrentHashTable::bulk_delete might miss to delete some objects In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 13:38:23 GMT, Leo Korinth wrote: > ConcurrentHashTable::bulk_delete might miss to delete some objects if a bucket has more than 256 entries. Current uses of ConcurrentHashTable are not harmed by this behaviour. > > I modified gtest:ConcurrentHashTable to detect the problem (first commit), and fixed the problem in the code (second commit). > > Tests passes tier1-3. This pull request has now been integrated. Changeset: 506c8186 Author: Leo Korinth URL: https://git.openjdk.org/jdk/commit/506c81868997cdea656fb480ebe18d49ab0e075e Stats: 94 lines in 3 files changed: 46 ins; 3 del; 45 mod 8296401: ConcurrentHashTable::bulk_delete might miss to delete some objects Reviewed-by: rehn, iwalulya, aboldtch ------------- PR: https://git.openjdk.org/jdk/pull/10983 From stuefe at openjdk.org Mon Jan 16 16:42:15 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 16 Jan 2023 16:42:15 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v2] In-Reply-To: References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> Message-ID: On Mon, 16 Jan 2023 14:25:14 GMT, Johan Sj?len wrote: >> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8293313-NMT-fake-oom >> - MallocLimit > > test/hotspot/gtest/nmt/test_nmt_malloclimit.cpp line 82: > >> 80: } >> 81: >> 82: TEST(NMT, malloclimit_per_category) { > >>malloclimit_per_category > > Can we use CamelCase for test case names instead? This is a convention that we *should* use for gtest: http://google.github.io/googletest/faq.html > > Unfortunately, we don't consistently do this, but I do want to avoid introducing new instances of this. I can see the point, though my names often follow a vague hierarchy if the suitename is already very generic. E.g. "malloclimit_xxx". - suitename is "NMT" and should remain so, all tests in this file concern MallocLimit, and then something. I like to separate "MallocLimit" visually from the "something". I guess its okay, just a minor annoyance. ------------- PR: https://git.openjdk.org/jdk/pull/11371 From stuefe at openjdk.org Mon Jan 16 16:51:14 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 16 Jan 2023 16:51:14 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v2] In-Reply-To: References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> Message-ID: On Mon, 16 Jan 2023 14:27:05 GMT, Johan Sj?len wrote: >> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8293313-NMT-fake-oom >> - MallocLimit > > test/hotspot/jtreg/runtime/Unsafe/Reallocate.java line 65: > >> 63: // Make sure we can throw an OOME when we fail to reallocate due to OOM >> 64: try { >> 65: unsafe.reallocateMemory(address, 100 * 1024 * 1024); > > Why are we changing the test here? Just because 800m is a lot larger than the required 100m? MallocMaxTestWords took the value in *words*, that's where the 8 comes in. Note that it was broken anyway since it never shrank - it ignored free calls. Therefore the values given to MallocMaxTestWords have only ever been guesswork. ------------- PR: https://git.openjdk.org/jdk/pull/11371 From stuefe at openjdk.org Mon Jan 16 17:17:56 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 16 Jan 2023 17:17:56 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v3] In-Reply-To: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> Message-ID: > Rework NMT `MallocLimit` to make it more useful for native OOM analysis. Also remove `MallocMaxTestWords`, which had been mostly redundant with NMT (for background, see JDK-8293292). > > > ### Background > > Some months ago we had [JDK-8291919](https://bugs.openjdk.org/browse/JDK-8291919), a compiler regression that caused compiler arenas to grow boundlessly. Process was usually OOM-killed before we could take a look, so this was difficult to analyze. > > To improve analysis options, we added NMT *malloc limits* with [JDK-8291878](https://bugs.openjdk.org/browse/JDK-8291878). Malloc limits let us set one or multiple limits to malloc load. Surpassing a limit causes the VM to stop with a fatal error in the allocation function, giving us a hs-err file and a core right at the point that (probably) causes the leak. This makes error analysis a lot simpler, and is also valuable for regression-testing footprint usage. > > Some people wished for a way to not end with a fatal error but to mimic a native OOM (causing os::malloc to return NULL). This would allow us to test resilience in the face of native OOMs, among other things. > > ### Patch > > - Expands the `MallocLimit` option syntax, allowing for an "oom mode" that mimics an oom: > > > > Global form: > -XX:MallocLimit=[:] > Category-specific form: > -XX:MallocLimit=:[:][,:[:] ...] > Examples: > -XX:MallocLimit=3g > -XX:MallocLimit=3g:oom > -XX:MallocLimit=compiler:200m:oom > > > - moves parsing of `-XX:MallocLimit` out of arguments.cpp into `mallocLimit.hpp/cpp`, and rewrites it. > > - changes when limits are checked. Before, the limits were checked *after* the allocation that caused the threshold overflow. Now we check beforehand. > > - removes `MallocMaxTestWords`, replacing its uses with `MallocLimit` > > - adds new gtests and new jtreg tests > > - removes a bunch of jtreg tests which are now better served by the new gtests. > > - gives us more precise error messages upon reaching a limit. For example: > > before: > > # fatal error: MallocLimit: category "Compiler" reached limit (size: 20997680, limit: 20971520) > > > now: > > # fatal error: MallocLimit: reached category "Compiler" limit (triggering allocation size: 1920B, allocated so far: 20505K, limit: 20480K) Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Copyrights - Feedback Johan - Merge - Merge branch 'master' into JDK-8293313-NMT-fake-oom - MallocLimit ------------- Changes: https://git.openjdk.org/jdk/pull/11371/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11371&range=02 Stats: 1008 lines in 21 files changed: 643 ins; 266 del; 99 mod Patch: https://git.openjdk.org/jdk/pull/11371.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11371/head:pull/11371 PR: https://git.openjdk.org/jdk/pull/11371 From stuefe at openjdk.org Mon Jan 16 17:17:57 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 16 Jan 2023 17:17:57 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v2] In-Reply-To: References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> Message-ID: On Mon, 16 Jan 2023 14:31:04 GMT, Johan Sj?len wrote: > This looks good. I've added some nits for style and a couple of comments concerning style which aren't nits. Logic wise, easy to follow and straight forward code, I could find nothing to complain about. Thanks @jdksjolen, I massaged in your feedback. Cheers, Thomas ------------- PR: https://git.openjdk.org/jdk/pull/11371 From kbarrett at openjdk.org Mon Jan 16 18:00:12 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 16 Jan 2023 18:00:12 GMT Subject: RFR: 8299213: Bad cast in GrowableArrayWithAllocator<>::grow In-Reply-To: References: Message-ID: On Mon, 16 Jan 2023 09:11:19 GMT, Afshin Zafari wrote: > ### Description > The grow size was wrongfully casted from `int` to `uint32`. > > ### Patch > The casting is removed. > > ### Tests > Local: **gtest:GrowableArrays*** > mach5 tier1-5 Looks good. src/hotspot/share/utilities/growableArray.hpp line 517: > 515: void GrowableArrayWithAllocator::grow(int j) { > 516: // grow the array by increasing _capacity to the first power of two larger than the size we need > 517: expand_to(next_power_of_2(j)); I thought I'd gotten rid of this cast as part of JDK-8295808, but obviously not. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/12007 From kbarrett at openjdk.org Mon Jan 16 18:00:14 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 16 Jan 2023 18:00:14 GMT Subject: RFR: 8299213: Bad cast in GrowableArrayWithAllocator<>::grow In-Reply-To: <0IfO97B0uwJ7tXO3rPIWpUepxIXPoCOaw2wb7xuecjk=.a9bbffb9-cb4b-4dae-81a7-a85f652ca558@github.com> References: <0IfO97B0uwJ7tXO3rPIWpUepxIXPoCOaw2wb7xuecjk=.a9bbffb9-cb4b-4dae-81a7-a85f652ca558@github.com> Message-ID: <6jQGROHIrj9JKwZ5uWG2pVpdOBTxq77secob3OKV0Is=.9840e111-d2ce-4414-a181-f31dc149bc41@github.com> On Mon, 16 Jan 2023 09:51:01 GMT, Johan Sj?len wrote: > ``` > // precondition: if signed, value >= 0. > // precondition: value < maximum power of two representable by T. > template ::value)> > inline T next_power_of_2(T value) { > ``` > > So this should require an assert that `j >= 0`. `next_power_of_2` already has that as a precondition that the argument is >= 0 if signed. And it's (indirectly) asserted. ------------- PR: https://git.openjdk.org/jdk/pull/12007 From jsjolen at openjdk.org Mon Jan 16 19:03:10 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 16 Jan 2023 19:03:10 GMT Subject: RFR: 8299213: Bad cast in GrowableArrayWithAllocator<>::grow In-Reply-To: References: Message-ID: On Mon, 16 Jan 2023 09:11:19 GMT, Afshin Zafari wrote: > ### Description > The grow size was wrongfully casted from `int` to `uint32`. > > ### Patch > The casting is removed. > > ### Tests > Local: **gtest:GrowableArrays*** > mach5 tier1-5 Marked as reviewed by jsjolen (Committer). > Aha, it's asserted in the next call. LGTM then. ------------- PR: https://git.openjdk.org/jdk/pull/12007 From iveresov at openjdk.org Mon Jan 16 19:16:12 2023 From: iveresov at openjdk.org (Igor Veresov) Date: Mon, 16 Jan 2023 19:16:12 GMT Subject: RFR: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions [v3] In-Reply-To: References: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> Message-ID: On Mon, 16 Jan 2023 02:12:23 GMT, Vladimir Kozlov wrote: >> Sergey Kuksenko has updated the pull request incrementally with two additional commits since the last revision: >> >> - whitespace clenup >> - renaming; generalize; make methods independent on post call noops naming > > src/hotspot/share/asm/assembler.hpp line 248: > >> 246: class InlineSkippedInstructionsCounter: public StackObj { >> 247: private: >> 248: AbstractAssembler* _assm; > > May be you should record `_assm->_code_section` instead and directly call `_code_section->register_skipped(_start)` instead of adding `AbstractAssembler:: register_skipped(size)`. With `CodeSection` code: > > register_skipped(address start) { > _skipped_instructions_size += (_end - start); > } Or may be it should be done in the destructor of `InlineSkippedInstructionsCounter`? Would be IMO cleaner. ------------- PR: https://git.openjdk.org/jdk/pull/11958 From iveresov at openjdk.org Mon Jan 16 19:16:15 2023 From: iveresov at openjdk.org (Igor Veresov) Date: Mon, 16 Jan 2023 19:16:15 GMT Subject: RFR: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions [v5] In-Reply-To: <1p4LqC5qz2G2jC1o4jKUkojrPSunDKphonFYcBE9hdc=.caf05d56-3243-44b2-8259-dcfcac94fe24@github.com> References: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> <1p4LqC5qz2G2jC1o4jKUkojrPSunDKphonFYcBE9hdc=.caf05d56-3243-44b2-8259-dcfcac94fe24@github.com> Message-ID: On Mon, 16 Jan 2023 02:59:32 GMT, Sergey Kuksenko wrote: >> Post call nop instructions increase the size of methods, which leads to different inline decisions and performance regression. >> Restore inline behavior by excluding post call nop instructions sizes from inline heuristics. > > Sergey Kuksenko has updated the pull request incrementally with one additional commit since the last revision: > > remove unused fields src/hotspot/share/asm/assembler.hpp line 257: > 255: } > 256: }; > 257: friend class InlineSkippedInstructionsCounter; Technically, in C++11 this is not necessary. Nested classes are automatically friends with the outer class. src/hotspot/share/ci/ciMethod.cpp line 1127: > 1125: CompiledMethod* code = get_Method()->code(); > 1126: if (code != NULL && (code->comp_level() == CompLevel_full_optimization)) { > 1127: int isize = code->insts_end() - code->verified_entry_point() - code->skipped_instructions_size(); FYI, there is `CompiledMethod` has `insts_size()` that returns the code size. May be use it? ------------- PR: https://git.openjdk.org/jdk/pull/11958 From jcking at openjdk.org Mon Jan 16 19:32:14 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 16 Jan 2023 19:32:14 GMT Subject: Integrated: JDK-8299971: Remove metaprogramming/conditional.hpp In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 14:44:11 GMT, Justin King wrote: > Code cleanup of pre-C++11 implementations. This pull request has now been integrated. Changeset: 4c1e66e0 Author: Justin King Committer: Kim Barrett URL: https://git.openjdk.org/jdk/commit/4c1e66e0abe9e379926e555bd651e9fcc5a0e8b6 Stats: 136 lines in 11 files changed: 7 ins; 105 del; 24 mod 8299971: Remove metaprogramming/conditional.hpp Reviewed-by: tschatzl, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/11946 From jcking at openjdk.org Mon Jan 16 19:33:24 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 16 Jan 2023 19:33:24 GMT Subject: Integrated: JDK-8299972: Remove metaprogramming/removeReference.hpp In-Reply-To: <2b-IgAfCtFcOvvzUnSIRop-HS2jQZk-ey6owacyEz6o=.b690ff0e-170c-4185-8f72-b16e4c67dec0@github.com> References: <2b-IgAfCtFcOvvzUnSIRop-HS2jQZk-ey6owacyEz6o=.b690ff0e-170c-4185-8f72-b16e4c67dec0@github.com> Message-ID: On Wed, 11 Jan 2023 14:51:15 GMT, Justin King wrote: > Code cleanup of pre-C++11 implementations. This pull request has now been integrated. Changeset: f52f6e65 Author: Justin King Committer: Kim Barrett URL: https://git.openjdk.org/jdk/commit/f52f6e65fba0360d3cf114e19fea402ab0d65eba Stats: 83 lines in 2 files changed: 0 ins; 83 del; 0 mod 8299972: Remove metaprogramming/removeReference.hpp Reviewed-by: tschatzl, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/11947 From xliu at openjdk.org Mon Jan 16 19:57:55 2023 From: xliu at openjdk.org (Xin Liu) Date: Mon, 16 Jan 2023 19:57:55 GMT Subject: RFR: 8300184: Optimize ResourceHashtableBase::iterate_all using _number_of_entries Message-ID: Current implementation needs to visit all buckets. In extreme case, an empty hashtable with 1k buckets. iterate_all() has to load 1k buckets for nothing. _number_of_entries is the number of nodes in the hashtable. This patch leverages that to quit iteration earlier. The real effect is up to the distribution of nodes among buckets. ------------- Commit messages: - 8300184: Optimize ResourceHashtableBase::iterate_all using _number_of_entries Changes: https://git.openjdk.org/jdk/pull/12016/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12016&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300184 Stats: 12 lines in 1 file changed: 11 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12016.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12016/head:pull/12016 PR: https://git.openjdk.org/jdk/pull/12016 From redestad at openjdk.org Mon Jan 16 23:19:49 2023 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 16 Jan 2023 23:19:49 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v19] In-Reply-To: References: Message-ID: > Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. > > I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. > > Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. > > The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. > > With the most recent fixes the x64 intrinsic results on my workstation look like this: > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op > StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op > StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op > StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op > > Baseline: > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op > StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op > StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op > StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op > > I.e. no measurable overhead compared to baseline even for `size == 1`. > > The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. > > Benchmark for `Arrays.hashCode`: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op > ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op > ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op > ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op > ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op > ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op > ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op > ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op > ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op > ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op > ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op > ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op > ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op > ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op > ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op > ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op > > Baseline: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op > ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op > ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op > ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op > ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op > ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op > ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op > ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op > ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op > ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op > ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op > ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op > ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op > ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op > ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op > ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op > > > As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. Claes Redestad has updated the pull request incrementally with three additional commits since the last revision: - Change signature to offset + length, add sanity test - Adapt end input to len (fix latent bug with sub-ranges - Clean-up types, simplify, hoist special-casing of String variants from arrays_hashcode, add initial value and range to intrinsic ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10847/files - new: https://git.openjdk.org/jdk/pull/10847/files/c8c58f4a..59e179c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=17-18 Stats: 210 lines in 13 files changed: 41 ins; 61 del; 108 mod Patch: https://git.openjdk.org/jdk/pull/10847.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10847/head:pull/10847 PR: https://git.openjdk.org/jdk/pull/10847 From dholmes at openjdk.org Mon Jan 16 23:21:19 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 16 Jan 2023 23:21:19 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v10] In-Reply-To: <1vK1PJLqYXa1wlcJrSnyFjtiumgX_nb8G178zv3X-c8=.ea74be21-8518-41d8-8fba-f2f5d6267a44@github.com> References: <1vK1PJLqYXa1wlcJrSnyFjtiumgX_nb8G178zv3X-c8=.ea74be21-8518-41d8-8fba-f2f5d6267a44@github.com> Message-ID: On Wed, 11 Jan 2023 10:49:59 GMT, Afshin Zafari wrote: >> test of tier1-5 passed. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8292741: Convert JvmtiTagMapTable to ResourceHashtable Still have a couple of nits regarding comments and some uncertainty about API use/behaviour. But okay. Thanks for the updates. src/hotspot/share/prims/jvmtiTagMapTable.cpp line 80: > 78: } > 79: } remove_all; > 80: _table.unlink(&remove_all); This logic is a bit unclear - can you add some comments. I guess I need to understand what unlink does when reading this code. src/hotspot/share/prims/jvmtiTagMapTable.cpp line 101: > 99: JvmtiTagMapKey jtme(obj); > 100: jlong* found = _table.get(jtme); > 101: return found == NULL ? 0 : *found; Please use nullptr in new code ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/11288 From dholmes at openjdk.org Mon Jan 16 23:21:20 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 16 Jan 2023 23:21:20 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7] In-Reply-To: <31ZthS6SqGpb-qVWc9EOZFk0x2KYf16KDL5hecw8HmY=.b1ee5b8e-1be0-4c20-bb33-c68d7202d0b2@github.com> References: <31ZthS6SqGpb-qVWc9EOZFk0x2KYf16KDL5hecw8HmY=.b1ee5b8e-1be0-4c20-bb33-c68d7202d0b2@github.com> Message-ID: On Thu, 15 Dec 2022 01:53:32 GMT, David Holmes wrote: >> In the `iterate` method of ResourceHashTable, in respurceHash.hpp lines 227-240 copied here, requires a function that returns boolean. If returned false the iterate will break. >> >> template >> void iterate(Function function) const { // lambda enabled API >> Node* const* bucket = table(); >> const unsigned sz = table_size(); >> while (bucket < bucket_at(sz)) { >> Node* node = *bucket; >> while (node != NULL) { >> bool cont = function(node->_key, node->_value); // <--------------****** >> if (!cont) { return; } >> node = node->_next; >> } >> ++bucket; >> } >> } >> >> The other `iterate` methods are wrappers around this one. >> Always returning true means to continue iterating over all the existing items. >> The former base table for jvmtiTagMapTable needs the `do_entry` be `void`. > > Okay in that case please add to the comment preceding this method: > > // Always return true so the iteration continues. You didn't add the comment I requested. ------------- PR: https://git.openjdk.org/jdk/pull/11288 From dholmes at openjdk.org Mon Jan 16 23:21:22 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 16 Jan 2023 23:21:22 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v10] In-Reply-To: <0pbB8d_Ihehf2KgV16rg4dh7cLy_eeZE2lGwovLEiBs=.4a05bd73-4252-449a-ae46-448fda30e2e6@github.com> References: <0pbB8d_Ihehf2KgV16rg4dh7cLy_eeZE2lGwovLEiBs=.4a05bd73-4252-449a-ae46-448fda30e2e6@github.com> Message-ID: On Mon, 12 Dec 2022 00:44:29 GMT, David Holmes wrote: >> src/hotspot/share/prims/jvmtiTagMapTable.cpp line 88: >> >>> 86: } >>> 87: >>> 88: JvmtiTagMapTable::~JvmtiTagMapTable() { >> >> Is this the only use of `clear`? If so we can just inline its code here and remove it from the API. > > This issue is not resolved. For clarity `clear()` is also called from `JvmtiTagMap::clear()` ------------- PR: https://git.openjdk.org/jdk/pull/11288 From dholmes at openjdk.org Mon Jan 16 23:21:23 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 16 Jan 2023 23:21:23 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 10:01:57 GMT, Afshin Zafari wrote: >> The JvmtiTagMap code adds/updates and removes the entries like below in two places which could probably be simplified, but I think that's outside the scope of this RFE. I suggest removing the bool return from add, remove and update, and add the assert(true) in the remove case. There's already an assert that add/update happened in the other cases. >> >> ``` // if the object is not already tagged then we tag it >> if (found_tag == 0) { >> if (tag != 0) { >> hashmap->add(o, tag); >> } else { >> // no-op >> } >> } else { >> // if the object is already tagged then we either update >> // the tag (if a new tag value has been provided) >> // or remove the object if the new tag value is 0. >> if (tag == 0) { >> hashmap->remove(o); >> } else { >> hashmap->update(o, tag); >> } >> } > > The methods of HashmapTable are void and have assert to verify the expected function (add/update/remove) is done. I'm still somewhat concerned about the use of this API and how it will behave in product mode, but okay ... ------------- PR: https://git.openjdk.org/jdk/pull/11288 From xliu at openjdk.org Mon Jan 16 23:24:23 2023 From: xliu at openjdk.org (Xin Liu) Date: Mon, 16 Jan 2023 23:24:23 GMT Subject: RFR: 8300184: Optimize ResourceHashtableBase::iterate_all using _number_of_entries [v2] In-Reply-To: References: Message-ID: > Current implementation needs to visit all buckets. In extreme case, an empty hashtable with 1k buckets. iterate_all() loads 1k buckets for nothing. `_number_of_entries` is the number of nodes in the hashtable. This patch leverages that to quit iteration earlier. The real effect is up to the distribution of nodes among buckets. > > I also included a debug log in the original patch. It was used for the observation in the following section, but I deleted it because it introduces circular dependency. > > log_debug(hashtables)("ResourceHashtableBase table_size = %d, break at " INTX_FORMAT, sz, (bucket - table())); > > **Evaluation** > In release build, the patch is very marginal. class loading do use ResourceHashtable but they are saturated. > > I use it to run `Renaissance/finagle-http`. hahstable iterate_all quits a little bit earlier and save some loads. eg. in line 2, there are 109 buckets in the hashable. the iteration quit at 68th bucket, we save 42 loads. > > > $java -Xlog:hashtables=debug -jar renaissance-gpl-0.14.1.jar finagle-http > ... > [12.824s][debug][hashtables] table_size = 109, break at 109 > [12.824s][debug][hashtables] table_size = 109, break at 68 > [12.824s][debug][hashtables] table_size = 109, break at 107 > [12.825s][debug][hashtables] table_size = 109, break at 108 > [12.825s][debug][hashtables] table_size = 109, break at 99 > [12.825s][debug][hashtables] table_size = 109, break at 108 > [12.825s][debug][hashtables] table_size = 109, break at 98 > [12.825s][debug][hashtables] table_size = 109, break at 109 > [12.825s][debug][hashtables] table_size = 109, break at 102 > ... > > > Another application is in AsyncLog Thread. We have a hashtable with 17 buckets. Each Log Output creates one node in the hashtable. In common cases, there are only 2~3 nodes in the hashtable. Each time AsyncLog Thread flushes the buffer, it has to scan the hashtable twice. Saving loads means saving the memory bandwidth for the application. > > In fastdebug build, extra verification is deployed. It's common to observe that JVM scan an empty hashtable. It's in destroy_VM. > > > ./build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xlog:hashtables=debug --version > openjdk 21-internal 2023-09-19 > OpenJDK Runtime Environment (fastdebug build 21-internal-adhoc.xxinliu.jdk) > OpenJDK 64-Bit Server VM (fastdebug build 21-internal-adhoc.xxinliu.jdk, mixed mode, sharing) > [0.130s][debug][hashtables] table_size = 139, break at 0 > [0.136s][debug][hashtables] table_size = 107, break at 0 > [0.136s][debug][hashtables] table_size = 1009, break at 0 > [0.136s][debug][hashtables] table_size = 109, break at 107 > [0.136s][debug][hashtables] table_size = 109, break at 109 > [0.137s][debug][hashtables] table_size = 109, break at 101 Xin Liu has updated the pull request incrementally with two additional commits since the last revision: - Remove log_debug. Thread::name() isn't safe in gtest. We don't need the log line. - Fixed the build error on x86-32. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12016/files - new: https://git.openjdk.org/jdk/pull/12016/files/93533a64..00a8abb5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12016&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12016&range=00-01 Stats: 9 lines in 1 file changed: 0 ins; 8 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12016.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12016/head:pull/12016 PR: https://git.openjdk.org/jdk/pull/12016 From redestad at openjdk.org Mon Jan 16 23:28:37 2023 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 16 Jan 2023 23:28:37 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v20] In-Reply-To: References: Message-ID: > Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. > > I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. > > Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. > > The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. > > With the most recent fixes the x64 intrinsic results on my workstation look like this: > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op > StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op > StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op > StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op > > Baseline: > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op > StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op > StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op > StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op > > I.e. no measurable overhead compared to baseline even for `size == 1`. > > The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. > > Benchmark for `Arrays.hashCode`: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op > ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op > ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op > ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op > ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op > ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op > ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op > ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op > ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op > ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op > ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op > ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op > ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op > ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op > ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op > ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op > > Baseline: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op > ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op > ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op > ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op > ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op > ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op > ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op > ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op > ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op > ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op > ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op > ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op > ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op > ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op > ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op > ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op > > > As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: trailing ws ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10847/files - new: https://git.openjdk.org/jdk/pull/10847/files/59e179c5..ffe5b66d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=18-19 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10847.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10847/head:pull/10847 PR: https://git.openjdk.org/jdk/pull/10847 From redestad at openjdk.org Mon Jan 16 23:32:13 2023 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 16 Jan 2023 23:32:13 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v13] In-Reply-To: References: <6lAQI6kDDTGbskylHcWReX8ExaB6qkwgqoai7E6ikZY=.8a69a63c-453d-4bbd-8c76-4d477bfb77fe@github.com> Message-ID: On Mon, 14 Nov 2022 18:28:53 GMT, Vladimir Ivanov wrote: >>> Also, I'd like to note that C2 auto-vectorization support is not too far away from being able to optimize hash code computations. At some point, I was able to achieve some promising results with modest tweaking of SuperWord pass: https://github.com/iwanowww/jdk/blob/superword/notes.txt http://cr.openjdk.java.net/~vlivanov/superword.reduction/webrev.00/ >> >> Intriguing. How far off is this - and do you think it'll be able to match the efficiency we see here with a memoized coefficient table etc? >> >> If we turn this intrinsic into a stub we might also be able to reuse the optimization in other places, including from within the VM (calculating String hashCodes happen in a couple of places, including String deduplication). So I think there are still a few compelling reasons to go the manual route and continue on this path. > >> How far off is this ...? > > Back then it looked way too constrained (tight constraints on code shapes). But I considered it as a generally applicable optimization. > >> ... do you think it'll be able to match the efficiency we see here with a memoized coefficient table etc? > > Yes, it is able to build the constant table at runtime when folding multiplications of constant coefficients produced during loop unrolling and then packing scalars into a constant vector. > > Moreover, briefly looking at the code shape, the vectorizer would produce a more optimal loop shape (pre-loop would align vector accesses and would use 512-bit vectors when available; vector post-loop could help as well). I've opted to include the changes spurred by @iwanowww's comments since it led to a number of revisions to the intrinsified method API, and it would be strange to introduce an intrinsified method just to change the API drastically in a follow-up. Basically `ArraysSupport.vectorizedHashCode` has been changed to take an offset + length, an initial value and the logical basic type of the array elements. Which means any necessary scaling of index and length needs to be taken care of before calling the intrinsic. This makes the implementation more flexible at no measurable performance cost. Overall the refactoring might have reduced complexity a bit. Reviewers might observe that nothing is currently passing anything but `0` and `length` to `vectorizedHashCode` outside of the simple sanity test I've added, but I've verified this feature can be used to some effect elsewhere in the JDK, e.g: https://github.com/openjdk/jdk/compare/pr/10847...cl4es:jdk:zipcoder-hashcode?expand=1 (which improves speed of opening `ZipFile` by a small percentage in microbenchmarks). ------------- PR: https://git.openjdk.org/jdk/pull/10847 From dholmes at openjdk.org Tue Jan 17 01:22:08 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 17 Jan 2023 01:22:08 GMT Subject: RFR: 8299089: Instrument global jni handles with tag to make them distinguishable In-Reply-To: References: Message-ID: On Mon, 16 Jan 2023 09:30:48 GMT, Axel Boldt-Christmas wrote: > Ran a suite of microbenchmarks, SPECxxx and Renaissance benchmarks. Could not see any significant change. Thanks for checking that. ------------- PR: https://git.openjdk.org/jdk/pull/11740 From dholmes at openjdk.org Tue Jan 17 01:31:14 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 17 Jan 2023 01:31:14 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v5] In-Reply-To: <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com> References: <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com> Message-ID: On Sat, 14 Jan 2023 19:01:52 GMT, Xue-Lei Andrew Fan wrote: >> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. >> >> This patch is trying to find the use of sprintf in hotspot iml and test cases. > > Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge > - correction for ppc > - missed update for debug mode > - more in src/hotspot > - typo correction > - 8299635: More test issues for deprecated sprintf in Xcode 14 src/hotspot/os/windows/os_windows.cpp line 387: > 385: os::snprintf_checked(buf, sizeof(buf), "%s%s;%s%s%s", > 386: Arguments::get_java_home(), EXT_DIR, > 387: path, PACKAGE_DIR, EXT_DIR); When the call is split across multiple lines like this, the subsequent lines should align with the first parameter i.e. align under `buf`. ------------- PR: https://git.openjdk.org/jdk/pull/11935 From dholmes at openjdk.org Tue Jan 17 01:39:14 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 17 Jan 2023 01:39:14 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v5] In-Reply-To: <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com> References: <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com> Message-ID: On Sat, 14 Jan 2023 19:01:52 GMT, Xue-Lei Andrew Fan wrote: >> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. >> >> This patch is trying to find the use of sprintf in hotspot iml and test cases. > > Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge > - correction for ppc > - missed update for debug mode > - more in src/hotspot > - typo correction > - 8299635: More test issues for deprecated sprintf in Xcode 14 I would suggest constraining this PR to src/hotspot and test/hotspot and deal with the JDK serviceability files in a different PR (and there may be other JDK files impacted too). src/hotspot/share/utilities/globalDefinitions.hpp line 191: > 189: FORBID_C_FUNCTION(char* strerror(int), "use os::strerror"); > 190: FORBID_C_FUNCTION(char* strtok(char*, const char*), "use strtok_r"); > 191: FORBID_C_FUNCTION(int sprintf(char*, const char*, ...), "use os::snprintf"); I have to wonder whether this actually works too. Perhaps @kbarrett can comment? ------------- PR: https://git.openjdk.org/jdk/pull/11935 From fjiang at openjdk.org Tue Jan 17 02:00:11 2023 From: fjiang at openjdk.org (Feilong Jiang) Date: Tue, 17 Jan 2023 02:00:11 GMT Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory API (Preview) [v5] In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 11:30:35 GMT, Jorn Vernee wrote: > Excellent. No Comments. > > I am running some sanity testing on our CI, and will approve when it comes back green. @JornVernee, thanks for the reviewing and testing! ------------- PR: https://git.openjdk.org/jdk/pull/11004 From dholmes at openjdk.org Tue Jan 17 02:05:11 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 17 Jan 2023 02:05:11 GMT Subject: RFR: 8299673: Simplify object pinning interactions with string deduplication [v2] In-Reply-To: References: Message-ID: On Mon, 16 Jan 2023 11:32:52 GMT, Erik ?sterlund wrote: >> When raw char* String contents are exposed to JNI code, we >> >> 1. Load the string.value and pin it >> 2. Run native code >> 3. Load the string.value and unpin it >> >> Given this sequence we would be in trouble if between 1 and 3, string deduplication changed the value object. Then the pinning and unpinning wouldn't be balanced. >> >> The current approach for dealing with this is to have a bunch of code to guard against deduplication. An alternative simpler solution is to just change step 3 to pass in the same value. We already have enough information available to do that. Then the pinning and unpinning is also balanced, and we don't need to have any special interactions with string deduplication and can decouple these orthogonal concerns. >> >> It's worth noting though that the contract of pin_object now makes it explicit that pinned objects must not be recycled, even if not otherwise reachable. That seems to come naturally for region based pinning, but is worth keeping in mind. The exposed char* might be the only thing referencing the string value when string dedup happens concurrently. > > Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Include sorting order > - Merge branch 'master' into 8299673_pin_dedup > - More Kim feedback > - Feedback from Kim > - 8299673: Simplify object pinning interactions with string deduplication Initially I was a bit unsure about the conceptual model here, as I was thinking that pinning is a very general concept, where in fact it only relates to these JNI "critical" functions. So in that sense every GC must support pinning as required by those functions, so this simplification looks very neat. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/11923 From dholmes at openjdk.org Tue Jan 17 03:00:15 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 17 Jan 2023 03:00:15 GMT Subject: RFR: 8300052: PdhDll::PdhCollectQueryData and PdhLookupPerfNameByIndex will never be NULL [v3] In-Reply-To: References: Message-ID: On Mon, 16 Jan 2023 06:05:44 GMT, Julian Waters wrote: >> Julian Waters has updated the pull request incrementally with one additional commit since the last revision: >> >> PdhExpandWildCardPath > > Done. Will integrate now and then watch in dismay at the limitations of GitHub's Pulls API > >> Good catch! Simple typos that were never noticed. > > Haha, gcc did most of the actual work catching those oversights, not me ;) @TheShermanTanker Two reviews are required before integrating hotspot changes. ------------- PR: https://git.openjdk.org/jdk/pull/11968 From jwaters at openjdk.org Tue Jan 17 03:24:17 2023 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 17 Jan 2023 03:24:17 GMT Subject: RFR: 8300052: PdhDll::PdhCollectQueryData and PdhLookupPerfNameByIndex will never be NULL [v3] In-Reply-To: References: Message-ID: On Mon, 16 Jan 2023 04:40:41 GMT, Julian Waters wrote: >> Both PdhDll::PdhCollectQueryData and PdhLookupPerfNameByIndex are concrete definitions and not pointers to executable code (Former is defined by us and the latter is a macro that expands into a concrete declaration), so it makes no sense to check if they will be NULL. The code fails to compile on Windows before this commit when gcc has warnings as errors enabled (-Waddress in this case) >> >> In the case of PdhCollectQueryData I'm assuming the check actually intended to check for _PdhCollectQueryData with the leading underscore, which is actually a pointer and can be NULL. Do correct me if I'm wrong and point me to what the appropriate check would be otherwise > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > PdhExpandWildCardPath Not again... I thought that was only for Style Guide changes, will keep this in mind for all my future HotSpot Pull Requests. Good thing this particular change wasn't that extensive :/ ------------- PR: https://git.openjdk.org/jdk/pull/11968 From dholmes at openjdk.org Tue Jan 17 04:32:08 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 17 Jan 2023 04:32:08 GMT Subject: RFR: 8300169: Build failure with clang-15 In-Reply-To: References: Message-ID: On Sat, 14 Jan 2023 14:28:32 GMT, Jie Fu wrote: > Hi all, > > Please review the fix for the build failure with clang-15. > > 1. -Wbitwise-instead-of-logical > > 1) src/hotspot/share/oops/generateOopMap.cpp <--- fixed the warning > 2) src/hotspot/share/runtime/notificationThread.cpp <--- keep the code and disable warnings > 3) src/hotspot/share/runtime/serviceThread.cpp <--- keep the code and disable warnings > > > 2. -Wdeprecated-non-prototype (all the warnings are disabled) > > 1) Mainly caused by files under `src/java.base/share/native/libzip/zlib/` <--- keep the code and disable warnings > It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN. > > 2) While compiling src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c <--- keep the code and disable warnings > > 3) Caused by src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m <--- fixed the warnings > > > 3. -Wdeprecated-builtins > > Caused by files under src/java.desktop/share/native/libharfbuzz/ <--- fixed the warnings > > Ref: https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202 > > 4. -Wgnu-folding-constant > > Caused by src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m <--- keep the code and disable warnings > > > Thanks. > Best regards, > Jie Hotspot changes are good. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12005 From jwaters at openjdk.org Tue Jan 17 04:36:11 2023 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 17 Jan 2023 04:36:11 GMT Subject: RFR: 8299213: Bad cast in GrowableArrayWithAllocator<>::grow In-Reply-To: References: Message-ID: On Mon, 16 Jan 2023 09:11:19 GMT, Afshin Zafari wrote: > ### Description > The grow size was wrongfully casted from `int` to `uint32`. > > ### Patch > The casting is removed. > > ### Tests > Local: **gtest:GrowableArrays*** > mach5 tier1-5 Looks Good, though you should be careful to only issue `/integrate` when you have at least 2 reviews if your change happens to be on the JVM itself (I learnt that the hard way) ------------- Marked as reviewed by jwaters (Committer). PR: https://git.openjdk.org/jdk/pull/12007 From dholmes at openjdk.org Tue Jan 17 04:53:12 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 17 Jan 2023 04:53:12 GMT Subject: RFR: 8300184: Optimize ResourceHashtableBase::iterate_all using _number_of_entries [v2] In-Reply-To: References: Message-ID: On Mon, 16 Jan 2023 23:24:23 GMT, Xin Liu wrote: >> Current implementation needs to visit all buckets. In extreme case, an empty hashtable with 1k buckets. iterate_all() loads 1k buckets for nothing. `_number_of_entries` is the number of nodes in the hashtable. This patch leverages that to quit iteration earlier. The real effect is up to the distribution of nodes among buckets. >> >> I also included a debug log in the original patch. It was used for the observation in the following section, but I deleted it because it introduces circular dependency. >> >> log_debug(hashtables)("ResourceHashtableBase table_size = %d, break at " INTX_FORMAT, sz, (bucket - table())); >> >> **Evaluation** >> In release build, the patch is very marginal. class loading do use ResourceHashtable but they are saturated. >> >> I use it to run `Renaissance/finagle-http`. hahstable iterate_all quits a little bit earlier and save some loads. eg. in line 2, there are 109 buckets in the hashable. the iteration quit at 68th bucket, we save 42 loads. >> >> >> $java -Xlog:hashtables=debug -jar renaissance-gpl-0.14.1.jar finagle-http >> ... >> [12.824s][debug][hashtables] table_size = 109, break at 109 >> [12.824s][debug][hashtables] table_size = 109, break at 68 >> [12.824s][debug][hashtables] table_size = 109, break at 107 >> [12.825s][debug][hashtables] table_size = 109, break at 108 >> [12.825s][debug][hashtables] table_size = 109, break at 99 >> [12.825s][debug][hashtables] table_size = 109, break at 108 >> [12.825s][debug][hashtables] table_size = 109, break at 98 >> [12.825s][debug][hashtables] table_size = 109, break at 109 >> [12.825s][debug][hashtables] table_size = 109, break at 102 >> ... >> >> >> Another application is in AsyncLog Thread. We have a hashtable with 17 buckets. Each Log Output creates one node in the hashtable. In common cases, there are only 2~3 nodes in the hashtable. Each time AsyncLog Thread flushes the buffer, it has to scan the hashtable twice. Saving loads means saving the memory bandwidth for the application. >> >> In fastdebug build, extra verification is deployed. It's common to observe that JVM scan an empty hashtable. It's in destroy_VM. >> >> >> ./build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xlog:hashtables=debug --version >> openjdk 21-internal 2023-09-19 >> OpenJDK Runtime Environment (fastdebug build 21-internal-adhoc.xxinliu.jdk) >> OpenJDK 64-Bit Server VM (fastdebug build 21-internal-adhoc.xxinliu.jdk, mixed mode, sharing) >> [0.130s][debug][hashtables] table_size = 139, break at 0 >> [0.136s][debug][hashtables] table_size = 107, break at 0 >> [0.136s][debug][hashtables] table_size = 1009, break at 0 >> [0.136s][debug][hashtables] table_size = 109, break at 107 >> [0.136s][debug][hashtables] table_size = 109, break at 109 >> [0.137s][debug][hashtables] table_size = 109, break at 101 > > Xin Liu has updated the pull request incrementally with two additional commits since the last revision: > > - Remove log_debug. > > Thread::name() isn't safe in gtest. We don't need the log line. > - Fixed the build error on x86-32. This seems quite reasonable to me. Thanks. Nit: the bug synopsis says `iterate_all` but you actually changed `iterate`. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12016 From duke at openjdk.org Tue Jan 17 05:48:16 2023 From: duke at openjdk.org (Afshin Zafari) Date: Tue, 17 Jan 2023 05:48:16 GMT Subject: Integrated: 8299213: Bad cast in GrowableArrayWithAllocator<>::grow In-Reply-To: References: Message-ID: <8_K4DgSGGldrva5Ofp2u16V7FwxeAtX0DCSiFaMS-B0=.76bead4c-637d-4a18-8121-74131ae926b6@github.com> On Mon, 16 Jan 2023 09:11:19 GMT, Afshin Zafari wrote: > ### Description > The grow size was wrongfully casted from `int` to `uint32`. > > ### Patch > The casting is removed. > > ### Tests > Local: **gtest:GrowableArrays*** > mach5 tier1-5 This pull request has now been integrated. Changeset: 6a81d528 Author: Afshin Zafari Committer: David Holmes URL: https://git.openjdk.org/jdk/commit/6a81d528e89de73183d6b51c9c366c85ae594d9d Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8299213: Bad cast in GrowableArrayWithAllocator<>::grow Reviewed-by: kbarrett, jsjolen, jwaters ------------- PR: https://git.openjdk.org/jdk/pull/12007 From jiefu at openjdk.org Tue Jan 17 06:03:13 2023 From: jiefu at openjdk.org (Jie Fu) Date: Tue, 17 Jan 2023 06:03:13 GMT Subject: RFR: 8300169: Build failure with clang-15 In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 04:29:31 GMT, David Holmes wrote: > Hotspot changes are good. Thanks @dholmes-ora . ------------- PR: https://git.openjdk.org/jdk/pull/12005 From duke at openjdk.org Tue Jan 17 07:03:18 2023 From: duke at openjdk.org (duke) Date: Tue, 17 Jan 2023 07:03:18 GMT Subject: Withdrawn: 8296263: Uniform APIs for using archived heap regions In-Reply-To: <3yfa0M_ZNG6oyLFj9qM9JYXyX-qzusaHw7R54wddmbE=.22a4a865-bb12-4d17-9d6a-cf95e2cc430f@github.com> References: <3yfa0M_ZNG6oyLFj9qM9JYXyX-qzusaHw7R54wddmbE=.22a4a865-bb12-4d17-9d6a-cf95e2cc430f@github.com> Message-ID: On Thu, 3 Nov 2022 16:06:47 GMT, Ashutosh Mehra wrote: > This is an attempt to unify the two different approaches for using archived heap regions. Main goal is to restructure and modify the code to have a single set of GC APIs that can be called for using archived heap regions. > > In current state, the VM either tries to "map" (for G1) or "load" (for non-G1 GC policies) the archived heap regions into the java heap. > When mapping, the VM determines the address range in the java heap where the archived regions should be mapped. It tries to map the regions towards the end of the heap. The APIs used for this purpose are G1 specific. > When loading, the VM asks the GC to provide a chunk of memory from the heap, into which it reads the contents of the archived heap regions. The APIs used are GC policy agnostic but challenging to use for region based collectors. > > This PR attempts to add new set of GC APIs that can be used by the VM to reserve space in the heap for mapping the archived heap regions. It combines the good parts of the two existing approaches. Similar to the "loading" API, in this new approach VM is not responsible for determining the mapping address. That responsibility always resides with the GC policy. This also allows the flexibility for the GC implementation to decide where and how to reserve the space for the archived regions. For instance, G1 implementation can continue to attempt to allocate the space towards the end of the heap. > This PR also provides the implementation of the new APIs for all the existing GC policies that currently support archived heap regions viz G1, serial, parallel and epsilon. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/10970 From xliu at openjdk.org Tue Jan 17 07:21:10 2023 From: xliu at openjdk.org (Xin Liu) Date: Tue, 17 Jan 2023 07:21:10 GMT Subject: RFR: 8300184: Optimize ResourceHashtableBase::iterate_all using _number_of_entries [v2] In-Reply-To: References: Message-ID: On Mon, 16 Jan 2023 23:24:23 GMT, Xin Liu wrote: >> Current implementation needs to visit all buckets. In extreme case, an empty hashtable with 1k buckets. iterate_all() loads 1k buckets for nothing. `_number_of_entries` is the number of nodes in the hashtable. This patch leverages that to quit iteration earlier. The real effect is up to the distribution of nodes among buckets. >> >> I also included a debug log in the original patch. It was used for the observation in the following section, but I deleted it because it introduces circular dependency. >> >> log_debug(hashtables)("ResourceHashtableBase table_size = %d, break at " INTX_FORMAT, sz, (bucket - table())); >> >> **Evaluation** >> In release build, the patch is very marginal. class loading do use ResourceHashtable but they are saturated. >> >> I use it to run `Renaissance/finagle-http`. hahstable iterate_all quits a little bit earlier and save some loads. eg. in line 2, there are 109 buckets in the hashable. the iteration quit at 68th bucket, we save 42 loads. >> >> >> $java -Xlog:hashtables=debug -jar renaissance-gpl-0.14.1.jar finagle-http >> ... >> [12.824s][debug][hashtables] table_size = 109, break at 109 >> [12.824s][debug][hashtables] table_size = 109, break at 68 >> [12.824s][debug][hashtables] table_size = 109, break at 107 >> [12.825s][debug][hashtables] table_size = 109, break at 108 >> [12.825s][debug][hashtables] table_size = 109, break at 99 >> [12.825s][debug][hashtables] table_size = 109, break at 108 >> [12.825s][debug][hashtables] table_size = 109, break at 98 >> [12.825s][debug][hashtables] table_size = 109, break at 109 >> [12.825s][debug][hashtables] table_size = 109, break at 102 >> ... >> >> >> Another application is in AsyncLog Thread. We have a hashtable with 17 buckets. Each Log Output creates one node in the hashtable. In common cases, there are only 2~3 nodes in the hashtable. Each time AsyncLog Thread flushes the buffer, it has to scan the hashtable twice. Saving loads means saving the memory bandwidth for the application. >> >> In fastdebug build, extra verification is deployed. It's common to observe that JVM scan an empty hashtable. It's in destroy_VM. >> >> >> ./build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xlog:hashtables=debug --version >> openjdk 21-internal 2023-09-19 >> OpenJDK Runtime Environment (fastdebug build 21-internal-adhoc.xxinliu.jdk) >> OpenJDK 64-Bit Server VM (fastdebug build 21-internal-adhoc.xxinliu.jdk, mixed mode, sharing) >> [0.130s][debug][hashtables] table_size = 139, break at 0 >> [0.136s][debug][hashtables] table_size = 107, break at 0 >> [0.136s][debug][hashtables] table_size = 1009, break at 0 >> [0.136s][debug][hashtables] table_size = 109, break at 107 >> [0.136s][debug][hashtables] table_size = 109, break at 109 >> [0.137s][debug][hashtables] table_size = 109, break at 101 > > Xin Liu has updated the pull request incrementally with two additional commits since the last revision: > > - Remove log_debug. > > Thread::name() isn't safe in gtest. We don't need the log line. > - Fixed the build error on x86-32. Hi, David, Thank you for reviewing this patch. > Nit: the bug synopsis says `iterate_all` but you actually changed `iterate`. This is intentional. iterate_all() calls iterate() with a lambda '()->true'. For iterate(), there are two cases. If the lambda returns constant value true, it mandates iterate() to traverse all elements. By contrast, user-defined lambdas could return false and stop iterating immediately. This patch only optimizes the former case. That's why I claim to optimize iterate_all rather than iterate. Sometimes, we need to traverse all elements. eg. we want to print out the contents, copy hashable or do statistics. thanks, --lx ------------- PR: https://git.openjdk.org/jdk/pull/12016 From eosterlund at openjdk.org Tue Jan 17 07:58:12 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 17 Jan 2023 07:58:12 GMT Subject: RFR: 8299673: Simplify object pinning interactions with string deduplication [v2] In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 02:02:47 GMT, David Holmes wrote: >> Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: >> >> - Include sorting order >> - Merge branch 'master' into 8299673_pin_dedup >> - More Kim feedback >> - Feedback from Kim >> - 8299673: Simplify object pinning interactions with string deduplication > > Initially I was a bit unsure about the conceptual model here, as I was thinking that pinning is a very general concept, where in fact it only relates to these JNI "critical" functions. So in that sense every GC must support pinning as required by those functions, so this simplification looks very neat. Thanks. Thanks for the review, @dholmes-ora! ------------- PR: https://git.openjdk.org/jdk/pull/11923 From eosterlund at openjdk.org Tue Jan 17 08:04:16 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 17 Jan 2023 08:04:16 GMT Subject: Integrated: 8299673: Simplify object pinning interactions with string deduplication In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 10:04:48 GMT, Erik ?sterlund wrote: > When raw char* String contents are exposed to JNI code, we > > 1. Load the string.value and pin it > 2. Run native code > 3. Load the string.value and unpin it > > Given this sequence we would be in trouble if between 1 and 3, string deduplication changed the value object. Then the pinning and unpinning wouldn't be balanced. > > The current approach for dealing with this is to have a bunch of code to guard against deduplication. An alternative simpler solution is to just change step 3 to pass in the same value. We already have enough information available to do that. Then the pinning and unpinning is also balanced, and we don't need to have any special interactions with string deduplication and can decouple these orthogonal concerns. > > It's worth noting though that the contract of pin_object now makes it explicit that pinned objects must not be recycled, even if not otherwise reachable. That seems to come naturally for region based pinning, but is worth keeping in mind. The exposed char* might be the only thing referencing the string value when string dedup happens concurrently. This pull request has now been integrated. Changeset: 9a36f8aa Author: Erik ?sterlund URL: https://git.openjdk.org/jdk/commit/9a36f8aadb08f8ade578530c70d9abe38f1826c6 Stats: 153 lines in 14 files changed: 65 ins; 68 del; 20 mod 8299673: Simplify object pinning interactions with string deduplication Co-authored-by: Stefan Karlsson Co-authored-by: Axel Boldt-Christmas Reviewed-by: kbarrett, stefank, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/11923 From duke at openjdk.org Tue Jan 17 08:35:45 2023 From: duke at openjdk.org (Fredrik Bredberg) Date: Tue, 17 Jan 2023 08:35:45 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v4] In-Reply-To: References: Message-ID: > Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. > Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. > Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. Fredrik Bredberg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' into relativize-locals-JDK-8299795_2023-01-09 - Added references to JDK-8300197 - Updated some copyright dates. - Changed copyright date to 2023 - 8299795: Relativize locals in interpreter frames ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11902/files - new: https://git.openjdk.org/jdk/pull/11902/files/ac821a10..98354c6e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11902&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11902&range=02-03 Stats: 8598 lines in 696 files changed: 4531 ins; 1692 del; 2375 mod Patch: https://git.openjdk.org/jdk/pull/11902.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11902/head:pull/11902 PR: https://git.openjdk.org/jdk/pull/11902 From duke at openjdk.org Tue Jan 17 08:43:13 2023 From: duke at openjdk.org (Fredrik Bredberg) Date: Tue, 17 Jan 2023 08:43:13 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 15:14:34 GMT, Martin Doerr wrote: > Works on PPC64. Thanks! Tests have passed on other platforms as well. Does "other platforms" include S390? ------------- PR: https://git.openjdk.org/jdk/pull/11902 From duke at openjdk.org Tue Jan 17 09:00:17 2023 From: duke at openjdk.org (Fredrik Bredberg) Date: Tue, 17 Jan 2023 09:00:17 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v4] In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 08:35:45 GMT, Fredrik Bredberg wrote: >> Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. >> Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. >> Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. > > Fredrik Bredberg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' into relativize-locals-JDK-8299795_2023-01-09 > - Added references to JDK-8300197 > - Updated some copyright dates. > - Changed copyright date to 2023 > - 8299795: Relativize locals in interpreter frames Hi @bulasevich, can you verify that this PR works on Arm32? I've done sanity checking on Arm32 using Qemu, but nothing extensive. ------------- PR: https://git.openjdk.org/jdk/pull/11902 From rehn at openjdk.org Tue Jan 17 09:03:12 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Tue, 17 Jan 2023 09:03:12 GMT Subject: RFR: 8300184: Optimize ResourceHashtableBase::iterate_all using _number_of_entries [v2] In-Reply-To: References: Message-ID: On Mon, 16 Jan 2023 23:24:23 GMT, Xin Liu wrote: >> Current implementation needs to visit all buckets. In extreme case, an empty hashtable with 1k buckets. iterate_all() loads 1k buckets for nothing. `_number_of_entries` is the number of nodes in the hashtable. This patch leverages that to quit iteration earlier. The real effect is up to the distribution of nodes among buckets. >> >> I also included a debug log in the original patch. It was used for the observation in the following section, but I deleted it because it introduces circular dependency. >> >> log_debug(hashtables)("ResourceHashtableBase table_size = %d, break at " INTX_FORMAT, sz, (bucket - table())); >> >> **Evaluation** >> In release build, the patch is very marginal. class loading do use ResourceHashtable but they are saturated. >> >> I use it to run `Renaissance/finagle-http`. hahstable iterate_all quits a little bit earlier and save some loads. eg. in line 2, there are 109 buckets in the hashable. the iteration quit at 68th bucket, we save 42 loads. >> >> >> $java -Xlog:hashtables=debug -jar renaissance-gpl-0.14.1.jar finagle-http >> ... >> [12.824s][debug][hashtables] table_size = 109, break at 109 >> [12.824s][debug][hashtables] table_size = 109, break at 68 >> [12.824s][debug][hashtables] table_size = 109, break at 107 >> [12.825s][debug][hashtables] table_size = 109, break at 108 >> [12.825s][debug][hashtables] table_size = 109, break at 99 >> [12.825s][debug][hashtables] table_size = 109, break at 108 >> [12.825s][debug][hashtables] table_size = 109, break at 98 >> [12.825s][debug][hashtables] table_size = 109, break at 109 >> [12.825s][debug][hashtables] table_size = 109, break at 102 >> ... >> >> >> Another application is in AsyncLog Thread. We have a hashtable with 17 buckets. Each Log Output creates one node in the hashtable. In common cases, there are only 2~3 nodes in the hashtable. Each time AsyncLog Thread flushes the buffer, it has to scan the hashtable twice. Saving loads means saving the memory bandwidth for the application. >> >> In fastdebug build, extra verification is deployed. It's common to observe that JVM scan an empty hashtable. It's in destroy_VM. >> >> >> ./build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xlog:hashtables=debug --version >> openjdk 21-internal 2023-09-19 >> OpenJDK Runtime Environment (fastdebug build 21-internal-adhoc.xxinliu.jdk) >> OpenJDK 64-Bit Server VM (fastdebug build 21-internal-adhoc.xxinliu.jdk, mixed mode, sharing) >> [0.130s][debug][hashtables] table_size = 139, break at 0 >> [0.136s][debug][hashtables] table_size = 107, break at 0 >> [0.136s][debug][hashtables] table_size = 1009, break at 0 >> [0.136s][debug][hashtables] table_size = 109, break at 107 >> [0.136s][debug][hashtables] table_size = 109, break at 109 >> [0.137s][debug][hashtables] table_size = 109, break at 101 > > Xin Liu has updated the pull request incrementally with two additional commits since the last revision: > > - Remove log_debug. > > Thread::name() isn't safe in gtest. We don't need the log line. > - Fixed the build error on x86-32. Thanks! ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.org/jdk/pull/12016 From xliu at openjdk.org Tue Jan 17 09:08:16 2023 From: xliu at openjdk.org (Xin Liu) Date: Tue, 17 Jan 2023 09:08:16 GMT Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof [v3] In-Reply-To: <1VvY0OUOTV6QoOICCC7D-bossOFuNcElgxJwOK0ATcg=.4d805893-07a4-4c0c-b9c0-82a2ee3be0cf@github.com> References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com> <1VvY0OUOTV6QoOICCC7D-bossOFuNcElgxJwOK0ATcg=.4d805893-07a4-4c0c-b9c0-82a2ee3be0cf@github.com> Message-ID: <1hEloz4xpYz6Ofo_RItjyhbSYfv8OY_f11SSvCgFjL8=.8c3d3051-54fb-4436-be68-7b493ddb6af5@github.com> On Fri, 30 Dec 2022 02:09:11 GMT, Kim Barrett wrote: > > What is the use-case for permitting use of `alignof`? Usually we don't add such permits without some use-case in mind. > > [...] > > I'm not opposed to permitting the use of `alignof`, but wondering why we might need it. > > Responding to myself, I've found a usage category where `alignof` would be appropriate. We have various places where we are aligning a pointer to the size of some type, where it would be more appropriate to align to the alignment of that type. See, for example, `Message::calc_size()` (logging/logAsyncWriter.hpp), which uses `sizeof(void*)` where it seems like it should be using `alignof(Message)`. Alignment of 'sizeof(void*)' here is a performance hint. We would like to see the address of next Message is aligned of pointer size. It eases the load instruction of 'Message::_output'. It's more effective to load from the aligned address. static constexpr size_t calc_size(size_t message_len) { return align_up(sizeof(Message) + message_len + 1, sizeof(void*)); } In this context, alignof(Message) is correct but a little bit wasteful. ------------- PR: https://git.openjdk.org/jdk/pull/11761 From shade at openjdk.org Tue Jan 17 09:10:14 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 17 Jan 2023 09:10:14 GMT Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory API (Preview) [v7] In-Reply-To: References: Message-ID: <41xEWGTTnbRsMRBtD_z3a1KmyM4AhWlUOuVFDktzeuM=.ce6e03db-1df5-403b-93f1-abab371f8b1c@github.com> On Mon, 16 Jan 2023 06:38:35 GMT, Feilong Jiang wrote: >> Add experimental Foreign Function & Memory API support for RISC-V. >> >> For details of the FFM API RISC-V port please refer to [JBS issue](https://bugs.openjdk.org/browse/JDK-8293841) >> >> Testing: >> >> - [x] jdk_foreign with release/fastdebug build on linux-riscv64 >> - [x] jdk_foreign with release/fastdebug build on linux-x64 >> - [x] jdk_foreign with release/fastdebug build on linux-aarch64 > > Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision: > > more code style adjustment Looks okay from the cursory review. src/hotspot/cpu/riscv/codeBuffer_riscv.cpp line 3: > 1: /* > 2: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > 3: * Copyright (c) 2022, Institute of Software, Chinese Academy of Sciences. Not sure if this change is accidental? ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/11004 From yadongwang at openjdk.org Tue Jan 17 09:45:43 2023 From: yadongwang at openjdk.org (Yadong Wang) Date: Tue, 17 Jan 2023 09:45:43 GMT Subject: RFR: 8299844: RISC-V: Implement _onSpinWait intrinsic [v3] In-Reply-To: References: Message-ID: > Implement _onSpinWait() intrinsic for RISC-V, and it can be implemented by using PAUSE instruction from Zihintpause Extension, which is ratified and a mandatory extension of RVA22U64 (https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#rva22u64-mandatory-extensions). > Software can use the PAUSE instruction to reduce energy consumption while executing spinwait > code sequences (https://github.com/riscv/riscv-isa-manual/blob/master/src/zihintpause.tex). > > Add a test case of test/hotspot/jtreg/compiler/onSpinWait/TestOnSpinWaitRISCV64.java, passed on QEMU. Yadong Wang has updated the pull request incrementally with one additional commit since the last revision: fix copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11921/files - new: https://git.openjdk.org/jdk/pull/11921/files/4f8a526e..295fa7cb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11921&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11921&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11921.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11921/head:pull/11921 PR: https://git.openjdk.org/jdk/pull/11921 From rehn at openjdk.org Tue Jan 17 10:04:16 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Tue, 17 Jan 2023 10:04:16 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v4] In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 08:35:45 GMT, Fredrik Bredberg wrote: >> Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. >> Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. >> Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. > > Fredrik Bredberg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' into relativize-locals-JDK-8299795_2023-01-09 > - Added references to JDK-8300197 > - Updated some copyright dates. > - Changed copyright date to 2023 > - 8299795: Relativize locals in interpreter frames Thank you, looks good! ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11902 From luhenry at openjdk.org Tue Jan 17 10:34:17 2023 From: luhenry at openjdk.org (Ludovic Henry) Date: Tue, 17 Jan 2023 10:34:17 GMT Subject: RFR: 8299844: RISC-V: Implement _onSpinWait intrinsic [v3] In-Reply-To: References: Message-ID: <85NBOw3k5bTRLCBrctxHtGalBE8-Jm-yg2XYUj7VvJk=.951a5256-fc46-4199-ac41-539314bf27bd@github.com> On Tue, 17 Jan 2023 09:45:43 GMT, Yadong Wang wrote: >> Implement _onSpinWait() intrinsic for RISC-V, and it can be implemented by using PAUSE instruction from Zihintpause Extension, which is ratified and a mandatory extension of RVA22U64 (https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#rva22u64-mandatory-extensions). >> Software can use the PAUSE instruction to reduce energy consumption while executing spinwait >> code sequences (https://github.com/riscv/riscv-isa-manual/blob/master/src/zihintpause.tex). >> >> Add a test case of test/hotspot/jtreg/compiler/onSpinWait/TestOnSpinWaitRISCV64.java, passed on QEMU. > > Yadong Wang has updated the pull request incrementally with one additional commit since the last revision: > > fix copyright year Marked as reviewed by luhenry (Committer). ------------- PR: https://git.openjdk.org/jdk/pull/11921 From duke at openjdk.org Tue Jan 17 10:56:56 2023 From: duke at openjdk.org (Afshin Zafari) Date: Tue, 17 Jan 2023 10:56:56 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v11] In-Reply-To: References: Message-ID: > test of tier1-5 passed. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: 8292741: Convert JvmtiTagMapTable to ResourceHashtable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11288/files - new: https://git.openjdk.org/jdk/pull/11288/files/b5a93bd5..64b19330 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=09-10 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11288.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11288/head:pull/11288 PR: https://git.openjdk.org/jdk/pull/11288 From fjiang at openjdk.org Tue Jan 17 11:13:22 2023 From: fjiang at openjdk.org (Feilong Jiang) Date: Tue, 17 Jan 2023 11:13:22 GMT Subject: RFR: 8299844: RISC-V: Implement _onSpinWait intrinsic [v3] In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 09:45:43 GMT, Yadong Wang wrote: >> Implement _onSpinWait() intrinsic for RISC-V, and it can be implemented by using PAUSE instruction from Zihintpause Extension, which is ratified and a mandatory extension of RVA22U64 (https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#rva22u64-mandatory-extensions). >> Software can use the PAUSE instruction to reduce energy consumption while executing spinwait >> code sequences (https://github.com/riscv/riscv-isa-manual/blob/master/src/zihintpause.tex). >> >> Add a test case of test/hotspot/jtreg/compiler/onSpinWait/TestOnSpinWaitRISCV64.java, passed on QEMU. > > Yadong Wang has updated the pull request incrementally with one additional commit since the last revision: > > fix copyright year Marked as reviewed by fjiang (Author). ------------- PR: https://git.openjdk.org/jdk/pull/11921 From jiefu at openjdk.org Tue Jan 17 11:33:12 2023 From: jiefu at openjdk.org (Jie Fu) Date: Tue, 17 Jan 2023 11:33:12 GMT Subject: RFR: 8300169: Build failure with clang-15 In-Reply-To: References: Message-ID: On Sat, 14 Jan 2023 14:28:32 GMT, Jie Fu wrote: > Hi all, > > Please review the fix for the build failure with clang-15. > > 1. -Wbitwise-instead-of-logical > > 1) src/hotspot/share/oops/generateOopMap.cpp <--- fixed the warning > 2) src/hotspot/share/runtime/notificationThread.cpp <--- keep the code and disable warnings > 3) src/hotspot/share/runtime/serviceThread.cpp <--- keep the code and disable warnings > > > 2. -Wdeprecated-non-prototype (all the warnings are disabled) > > 1) Mainly caused by files under `src/java.base/share/native/libzip/zlib/` <--- keep the code and disable warnings > It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN. > > 2) While compiling src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c <--- keep the code and disable warnings > > 3) Caused by src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m <--- fixed the warnings > > > 3. -Wdeprecated-builtins > > Caused by files under src/java.desktop/share/native/libharfbuzz/ <--- fixed the warnings > > Ref: https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202 > > 4. -Wgnu-folding-constant > > Caused by src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m <--- keep the code and disable warnings > > > Thanks. > Best regards, > Jie Hi @kevinrushforth and @AlanBateman , are you fine with this change? Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/12005 From fjiang at openjdk.org Tue Jan 17 12:49:15 2023 From: fjiang at openjdk.org (Feilong Jiang) Date: Tue, 17 Jan 2023 12:49:15 GMT Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory API (Preview) [v7] In-Reply-To: <41xEWGTTnbRsMRBtD_z3a1KmyM4AhWlUOuVFDktzeuM=.ce6e03db-1df5-403b-93f1-abab371f8b1c@github.com> References: <41xEWGTTnbRsMRBtD_z3a1KmyM4AhWlUOuVFDktzeuM=.ce6e03db-1df5-403b-93f1-abab371f8b1c@github.com> Message-ID: On Mon, 16 Jan 2023 11:48:21 GMT, Aleksey Shipilev wrote: >> Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision: >> >> more code style adjustment > > src/hotspot/cpu/riscv/codeBuffer_riscv.cpp line 3: > >> 1: /* >> 2: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. >> 3: * Copyright (c) 2022, Institute of Software, Chinese Academy of Sciences. > > Not sure if this change is accidental? The copyright of ISCAS is too long for one line, so we split them into separate lines. ------------- PR: https://git.openjdk.org/jdk/pull/11004 From jwaters at openjdk.org Tue Jan 17 13:04:15 2023 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 17 Jan 2023 13:04:15 GMT Subject: RFR: JDK-8300080: offset_of for GCC/Clang exhibits undefined behavior and is not always a compile-time constant [v4] In-Reply-To: References: Message-ID: <4ltfrlbK1mihSHTgnsAfH93eXfOscyhVgf5UId15Rbk=.fdb00440-7658-49cc-8ec9-a781a7e037e3@github.com> On Fri, 13 Jan 2023 16:06:44 GMT, Justin King wrote: >> The implementation of `offset_of` for GCC/Clang only deals with types are aligned to 16 bytes or less, if they are more, such as `zCollectedHeap` the behavior is undefined. UBSan also suggests that `offset_of` is not always a compile time constant, as the stack trace came from the dynamic loader during library loading. This patch changes `offset_of` to use `offsetof` and disables the warning `invalid-offsetof` for the JVM. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Move attribute on lambda to correct location > > Signed-off-by: Justin King Small nit, I think it might be better to use `ALWAYSINLINE` instead of the attribute for the custom `offset_of`, it looks somewhat neater > Also, the FIXME comment added by JDK-8294902 suggesting using `offsetof` should be removed. I partially agree with Justin on this one when it comes to `offsetof`, if I'm missing something important perhaps we could leave the comment as is or reword it to not be a `FIXME` while we stay on C++14, to leave it open for if HotSpot properly moves to a newer C++ version in the future. Just my 2? on the issue > A change to the existing code would be to use `alignof(klass)` to align the space buffer, once use of > `alignof` is approved. That would fix the alignment problem. The `alignof` proposal is still awaiting approval, given that we're speaking of it :P ------------- PR: https://git.openjdk.org/jdk/pull/11978 From duke at openjdk.org Tue Jan 17 13:23:51 2023 From: duke at openjdk.org (Afshin Zafari) Date: Tue, 17 Jan 2023 13:23:51 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v12] In-Reply-To: References: Message-ID: > test of tier1-5 passed. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: 8292741: Convert JvmtiTagMapTable to ResourceHashtable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11288/files - new: https://git.openjdk.org/jdk/pull/11288/files/64b19330..d953b0bb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=10-11 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11288.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11288/head:pull/11288 PR: https://git.openjdk.org/jdk/pull/11288 From fyang at openjdk.org Tue Jan 17 13:28:16 2023 From: fyang at openjdk.org (Fei Yang) Date: Tue, 17 Jan 2023 13:28:16 GMT Subject: RFR: 8299844: RISC-V: Implement _onSpinWait intrinsic [v3] In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 09:45:43 GMT, Yadong Wang wrote: >> Implement _onSpinWait() intrinsic for RISC-V, and it can be implemented by using PAUSE instruction from Zihintpause Extension, which is ratified and a mandatory extension of RVA22U64 (https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#rva22u64-mandatory-extensions). >> Software can use the PAUSE instruction to reduce energy consumption while executing spinwait >> code sequences (https://github.com/riscv/riscv-isa-manual/blob/master/src/zihintpause.tex). >> >> Add a test case of test/hotspot/jtreg/compiler/onSpinWait/TestOnSpinWaitRISCV64.java, passed on QEMU. > > Yadong Wang has updated the pull request incrementally with one additional commit since the last revision: > > fix copyright year Looks fine to me. ------------- Marked as reviewed by fyang (Reviewer). PR: https://git.openjdk.org/jdk/pull/11921 From mdoerr at openjdk.org Tue Jan 17 13:36:18 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 17 Jan 2023 13:36:18 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 08:40:18 GMT, Fredrik Bredberg wrote: > > Works on PPC64. Thanks! Tests have passed on other platforms as well. > > Does "other platforms" include S390? No, @backwaterred you may want to check. ------------- PR: https://git.openjdk.org/jdk/pull/11902 From mdoerr at openjdk.org Tue Jan 17 13:36:24 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 17 Jan 2023 13:36:24 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v4] In-Reply-To: References: Message-ID: <3mWF3cL69YLzYwYI7z0nQB66c_JxuTUMPfTHVn_YjiQ=.00a62b19-8dd8-42ba-9d71-078cf21f2657@github.com> On Tue, 17 Jan 2023 08:35:45 GMT, Fredrik Bredberg wrote: >> Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. >> Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. >> Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. > > Fredrik Bredberg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' into relativize-locals-JDK-8299795_2023-01-09 > - Added references to JDK-8300197 > - Updated some copyright dates. > - Changed copyright date to 2023 > - 8299795: Relativize locals in interpreter frames src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp line 1035: > 1033: __ sub(R12_scratch2, R18_locals, R1_SP); > 1034: __ srdi(R12_scratch2, R12_scratch2, Interpreter::logStackElementSize); > 1035: // Now &fp()[R12_scratch2] == R18_locals I think this comment makes no sense. Please remove it. Otherwise, PPC64 code LGTM. ------------- PR: https://git.openjdk.org/jdk/pull/11902 From kcr at openjdk.org Tue Jan 17 13:38:14 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 17 Jan 2023 13:38:14 GMT Subject: RFR: 8300169: Build failure with clang-15 In-Reply-To: References: Message-ID: On Sat, 14 Jan 2023 14:28:32 GMT, Jie Fu wrote: > Hi all, > > Please review the fix for the build failure with clang-15. > > 1. -Wbitwise-instead-of-logical > > 1) src/hotspot/share/oops/generateOopMap.cpp <--- fixed the warning > 2) src/hotspot/share/runtime/notificationThread.cpp <--- keep the code and disable warnings > 3) src/hotspot/share/runtime/serviceThread.cpp <--- keep the code and disable warnings > > > 2. -Wdeprecated-non-prototype (all the warnings are disabled) > > 1) Mainly caused by files under `src/java.base/share/native/libzip/zlib/` <--- keep the code and disable warnings > It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN. > > 2) While compiling src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c <--- keep the code and disable warnings > > 3) Caused by src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m <--- fixed the warnings > > > 3. -Wdeprecated-builtins > > Caused by files under src/java.desktop/share/native/libharfbuzz/ <--- fixed the warnings > > Ref: https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202 > > 4. -Wgnu-folding-constant > > Caused by src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m <--- keep the code and disable warnings > > > Thanks. > Best regards, > Jie Yes, but I would wait for @prrace to review the Harfbuzz change. ------------- PR: https://git.openjdk.org/jdk/pull/12005 From kcr at openjdk.org Tue Jan 17 13:38:17 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 17 Jan 2023 13:38:17 GMT Subject: RFR: 8300169: Build failure with clang-15 In-Reply-To: <0hacUHSSaPqiYtv3EsaC4UVe_da0hydgcTrpUpn9w6s=.ae39b693-7f04-40ab-94c0-a90f95c6c260@github.com> References: <0hacUHSSaPqiYtv3EsaC4UVe_da0hydgcTrpUpn9w6s=.ae39b693-7f04-40ab-94c0-a90f95c6c260@github.com> Message-ID: On Sun, 15 Jan 2023 01:56:06 GMT, Jie Fu wrote: >> src/java.desktop/share/native/libharfbuzz/hb-meta.hh line 191: >> >>> 189: #define hb_int_max(T) hb_int_max::value >>> 190: >>> 191: #if defined(__GNUC__) && __GNUC__ < 5 && !defined(__clang__) >> >> Normally, such changes in third-party libraries need to be done upstream, and not locally. @prrace can confirm. > >> Normally, such changes in third-party libraries need to be done upstream, and not locally. @prrace can confirm. > > Thanks @kevinrushforth for your review. > > Yes, it had been fixed in the upstream and I just follow it. > Please see https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202 . > > Or did you mean we had to sync the whole harfbuzz with the upstream? > If so, I would suggest doing it in a separate PR. > What do you think? > Thanks. No, I didn't mean to update all of harfbuzz. What you've done seems fine to me, but let's see what @prrace says. ------------- PR: https://git.openjdk.org/jdk/pull/12005 From eosterlund at openjdk.org Tue Jan 17 13:57:00 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 17 Jan 2023 13:57:00 GMT Subject: RFR: 8300253: Introduce AArch64 nzcv accessors Message-ID: Some code, such as verification code, might want to run without changing the state of the system. To do that, it's useful to be able to get and set the nzcv flags. This enhancement aims at adding accessors for that. ------------- Commit messages: - 8300253: Introduce AArch64 nzcv accessors Changes: https://git.openjdk.org/jdk/pull/12038/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12038&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300253 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12038.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12038/head:pull/12038 PR: https://git.openjdk.org/jdk/pull/12038 From aph at openjdk.org Tue Jan 17 14:04:23 2023 From: aph at openjdk.org (Andrew Haley) Date: Tue, 17 Jan 2023 14:04:23 GMT Subject: RFR: 8300253: Introduce AArch64 nzcv accessors In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 13:47:26 GMT, Erik ?sterlund wrote: > Some code, such as verification code, might want to run without changing the state of the system. To do that, it's useful to be able to get and set the nzcv flags. This enhancement aims at adding accessors for that. src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 591: > 589: msr(0b011, 0b0100, 0b0010, 0b000, reg); > 590: } > 591: We've tried never to to add such things speculatively, as much as anything else because it's impossible to test. ------------- PR: https://git.openjdk.org/jdk/pull/12038 From jcking at openjdk.org Tue Jan 17 14:17:59 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 17 Jan 2023 14:17:59 GMT Subject: RFR: JDK-8300260: Remove metaprogramming/isSame.hpp Message-ID: Code cleanup of pre-C++11 implementations. ------------- Commit messages: - Remove metaprogramming/isSame.hpp Changes: https://git.openjdk.org/jdk/pull/12040/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12040&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300260 Stats: 111 lines in 7 files changed: 2 ins; 93 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/12040.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12040/head:pull/12040 PR: https://git.openjdk.org/jdk/pull/12040 From jcking at openjdk.org Tue Jan 17 14:31:00 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 17 Jan 2023 14:31:00 GMT Subject: RFR: JDK-8300264: Remove metaprogramming/isPointer.hpp Message-ID: Code cleanup of pre-C++11 implementations. ------------- Commit messages: - Remove metaprogramming/isPointer.hpp Changes: https://git.openjdk.org/jdk/pull/12041/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12041&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300264 Stats: 106 lines in 5 files changed: 2 ins; 95 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/12041.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12041/head:pull/12041 PR: https://git.openjdk.org/jdk/pull/12041 From jcking at openjdk.org Tue Jan 17 14:37:00 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 17 Jan 2023 14:37:00 GMT Subject: RFR: JDK-8300265: Remove metaprogramming/isSigned.hpp Message-ID: <5FdmclkgEZHyCgDKZvz2MZd0OyCCE2_oOLxZj8K9Ojs=.51b51fae-08c0-4bd1-be6f-f4b55cd72efd@github.com> Code cleanup of pre-C++11 implementations. ------------- Commit messages: - Remove metaprogramming/isSigned.hpp Changes: https://git.openjdk.org/jdk/pull/12042/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12042&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300265 Stats: 105 lines in 6 files changed: 3 ins; 91 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/12042.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12042/head:pull/12042 PR: https://git.openjdk.org/jdk/pull/12042 From jcking at openjdk.org Tue Jan 17 14:41:13 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 17 Jan 2023 14:41:13 GMT Subject: RFR: JDK-8300080: offset_of for GCC/Clang exhibits undefined behavior and is not always a compile-time constant [v4] In-Reply-To: <4ltfrlbK1mihSHTgnsAfH93eXfOscyhVgf5UId15Rbk=.fdb00440-7658-49cc-8ec9-a781a7e037e3@github.com> References: <4ltfrlbK1mihSHTgnsAfH93eXfOscyhVgf5UId15Rbk=.fdb00440-7658-49cc-8ec9-a781a7e037e3@github.com> Message-ID: On Tue, 17 Jan 2023 13:01:47 GMT, Julian Waters wrote: > Small nit, I think it might be better to use `ALWAYSINLINE` instead of the attribute for the custom `offset_of`, it looks somewhat neater Unfortunately `ALWAYSINLINE` includes the `inline` keyword, which I do not believe can be used at the location we need to place the attribute. ------------- PR: https://git.openjdk.org/jdk/pull/11978 From goetz.lindenmaier at sap.com Tue Jan 17 15:04:47 2023 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 17 Jan 2023 15:04:47 +0000 Subject: CFV: New Hotspot Group Member: Richard Reingruber Message-ID: I hereby nominate Richard Reingruber (rrich)[1] to Membership in the Hotspot Group. Last, Richard has ported loom to PPC. He is an expert in GC algorithms and has deep knowledge of JVMTI and the escape analysis of C2. He enriched the escape analysis to run when JVMTI debugging capabilities of the JVM are enabled. He analyzed a lot of complex issues, digging down even into the implementation of operating systems as Solaris. Votes are due by January 31, 2023. Only current Members of the hotspot Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Best regards, Goetz. [1] https://openjdk.org/census#rrich [2] https://openjdk.org/census#hotspot [3] https://openjdk.org/groups/#member-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From ChrisPhi at LGonQn.Org Tue Jan 17 15:12:45 2023 From: ChrisPhi at LGonQn.Org (Chris Phillips) Date: Tue, 17 Jan 2023 10:12:45 -0500 Subject: CFV: New Hotspot Group Member: Richard Reingruber In-Reply-To: References: Message-ID: <8ae81e6b-9f61-f191-6cb4-ecf8eb9ff204@LGonQn.Org> Hi Vote: yes Cheers! Chris On 2023-01-17 10:04, Lindenmaier, Goetz wrote: > I hereby nominate Richard Reingruber (rrich)[1] to Membership > > in the Hotspot Group. > > Last, Richard has ported loom to PPC. He is an expert in GC > > algorithms and has deep knowledge of JVMTI and the > > escape analysis of C2. ?He enriched the escape analysis > > to run when JVMTI debugging capabilities of the JVM are > > enabled. He analyzed a lot of complex issues, digging down > > even into the implementation of operating systems as > > Solaris. > > Votes are due by January 31, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on > > this nomination.? Votes must be cast in the open by replying to this > > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best regards, > > ? Goetz. > > [1] https://openjdk.org/census#rrich > > [2] https://openjdk.org/census#hotspot > > [3] https://openjdk.org/groups/#member-vote > > From martin.doerr at sap.com Tue Jan 17 15:14:07 2023 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 17 Jan 2023 15:14:07 +0000 Subject: CFV: New Hotspot Group Member: Richard Reingruber In-Reply-To: References: Message-ID: Vote: yes Best regards, Martin Von: hotspot-dev im Auftrag von Lindenmaier, Goetz Datum: Dienstag, 17. Januar 2023 um 22:05 An: hotspot-dev at openjdk.org Betreff: CFV: New Hotspot Group Member: Richard Reingruber I hereby nominate Richard Reingruber (rrich)[1] to Membership in the Hotspot Group. Last, Richard has ported loom to PPC. He is an expert in GC algorithms and has deep knowledge of JVMTI and the escape analysis of C2. He enriched the escape analysis to run when JVMTI debugging capabilities of the JVM are enabled. He analyzed a lot of complex issues, digging down even into the implementation of operating systems as Solaris. Votes are due by January 31, 2023. Only current Members of the hotspot Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Best regards, Goetz. [1] https://openjdk.org/census#rrich [2] https://openjdk.org/census#hotspot [3] https://openjdk.org/groups/#member-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Tue Jan 17 15:20:44 2023 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 17 Jan 2023 16:20:44 +0100 Subject: CFV: New Hotspot Group Member: Richard Reingruber In-Reply-To: References: Message-ID: Vote: yes On Tue, Jan 17, 2023 at 4:05 PM Lindenmaier, Goetz < goetz.lindenmaier at sap.com> wrote: > I hereby nominate Richard Reingruber (rrich)[1] to Membership > > in the Hotspot Group. > > > > Last, Richard has ported loom to PPC. He is an expert in GC > > algorithms and has deep knowledge of JVMTI and the > > escape analysis of C2. He enriched the escape analysis > > to run when JVMTI debugging capabilities of the JVM are > > enabled. He analyzed a lot of complex issues, digging down > > even into the implementation of operating systems as > > Solaris. > > > > Votes are due by January 31, 2023. > > > > Only current Members of the hotspot Group [2] are eligible to vote on > > this nomination. Votes must be cast in the open by replying to this > > mailing list. > > > > For Lazy Consensus voting instructions, see [3]. > > > > Best regards, > > Goetz. > > > > [1] https://openjdk.org/census#rrich > > [2] https://openjdk.org/census#hotspot > > [3] https://openjdk.org/groups/#member-vote > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hartmann at oracle.com Tue Jan 17 15:27:05 2023 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 17 Jan 2023 16:27:05 +0100 Subject: CFV: New Hotspot Group Member: Richard Reingruber In-Reply-To: References: Message-ID: Vote: yes Best regards, Tobias On 17.01.23 16:04, Lindenmaier, Goetz wrote: > I hereby nominate Richard Reingruber (rrich)[1] to Membership > > in the Hotspot Group. > > ? > > Last, Richard has ported loom to PPC. He is an expert in GC > > algorithms and has deep knowledge of JVMTI and the > > escape analysis of C2. ?He enriched the escape analysis > > to run when JVMTI debugging capabilities of the JVM are > > enabled. He analyzed a lot of complex issues, digging down > > even into the implementation of operating systems as > > Solaris. > > ? > > Votes are due by January 31, 2023. > > ? > > Only current Members of the hotspot Group [2] are eligible to vote on > > this nomination.? Votes must be cast in the open by replying to this > > mailing list. > > ? > > For Lazy Consensus voting instructions, see [3]. > > ? > > Best regards, > > ? Goetz. > > ? > > [1] https://openjdk.org/census#rrich > > [2] https://openjdk.org/census#hotspot > > [3] https://openjdk.org/groups/#member-vote > > ? > From goetz.lindenmaier at sap.com Tue Jan 17 15:42:31 2023 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 17 Jan 2023 15:42:31 +0000 Subject: CFV: New Hotspot Group Member: Richard Reingruber In-Reply-To: References: Message-ID: Vote: yes Best, Goetz. From: hotspot-dev On Behalf Of Lindenmaier, Goetz Sent: Tuesday, January 17, 2023 4:05 PM To: hotspot-dev at openjdk.org Subject: CFV: New Hotspot Group Member: Richard Reingruber I hereby nominate Richard Reingruber (rrich)[1] to Membership in the Hotspot Group. Last, Richard has ported loom to PPC. He is an expert in GC algorithms and has deep knowledge of JVMTI and the escape analysis of C2. He enriched the escape analysis to run when JVMTI debugging capabilities of the JVM are enabled. He analyzed a lot of complex issues, digging down even into the implementation of operating systems as Solaris. Votes are due by January 31, 2023. Only current Members of the hotspot Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Best regards, Goetz. [1] https://openjdk.org/census#rrich [2] https://openjdk.org/census#hotspot [3] https://openjdk.org/groups/#member-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcking at openjdk.org Tue Jan 17 16:00:23 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 17 Jan 2023 16:00:23 GMT Subject: RFR: JDK-8299688: Adopt C++14 compatible std::bit_cast introduced in C++20 [v4] In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 16:19:51 GMT, Justin King wrote: >> Adopts a C++14 compatible implementation of [std::bit_cast](https://en.cppreference.com/w/cpp/numeric/bit_cast). >> >> `PrimitiveConversions::cast` is refactored into `bit_cast` and extended to support all compatible types. Additionally it makes use of `__builtin_bit_cast` when available, which is strictly well defined compared to fallback approaches which are sometimes lurking in undefined behavior territory. >> >> Lastly some legacy casting is updated to use `bit_cast` in `utilities/globalDefinitions.hpp`. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Remove addressof as nobody should be overloading operator& > > Signed-off-by: Justin King @kimbarrett Friendly poke. Benefit is when we eventually get to C++20 we can just do `using std::bit_cast`. ------------- PR: https://git.openjdk.org/jdk/pull/11865 From jcking at openjdk.org Tue Jan 17 16:34:05 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 17 Jan 2023 16:34:05 GMT Subject: RFR: JDK-8300260: Remove metaprogramming/isSame.hpp [v2] In-Reply-To: References: Message-ID: <0qxLrvJHTjcItIhgu7sls0aCAeLoMQSuFZjbxb4H4gg=.fda1f0af-87f2-4e22-8e05-bce5390e5c7e@github.com> > Code cleanup of pre-C++11 implementations. Justin King has updated the pull request incrementally with one additional commit since the last revision: Revert back from std::is_void to std::is_same Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12040/files - new: https://git.openjdk.org/jdk/pull/12040/files/827f8d81..19a991ad Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12040&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12040&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12040.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12040/head:pull/12040 PR: https://git.openjdk.org/jdk/pull/12040 From alanb at openjdk.org Tue Jan 17 16:54:14 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 17 Jan 2023 16:54:14 GMT Subject: RFR: 8300169: Build failure with clang-15 In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 13:33:06 GMT, Kevin Rushforth wrote: >> Hi all, >> >> Please review the fix for the build failure with clang-15. >> >> 1. -Wbitwise-instead-of-logical >> >> 1) src/hotspot/share/oops/generateOopMap.cpp <--- fixed the warning >> 2) src/hotspot/share/runtime/notificationThread.cpp <--- keep the code and disable warnings >> 3) src/hotspot/share/runtime/serviceThread.cpp <--- keep the code and disable warnings >> >> >> 2. -Wdeprecated-non-prototype (all the warnings are disabled) >> >> 1) Mainly caused by files under `src/java.base/share/native/libzip/zlib/` <--- keep the code and disable warnings >> It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN. >> >> 2) While compiling src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c <--- keep the code and disable warnings >> >> 3) Caused by src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m <--- fixed the warnings >> >> >> 3. -Wdeprecated-builtins >> >> Caused by files under src/java.desktop/share/native/libharfbuzz/ <--- fixed the warnings >> >> Ref: https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202 >> >> 4. -Wgnu-folding-constant >> >> Caused by src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m <--- keep the code and disable warnings >> >> >> Thanks. >> Best regards, >> Jie > > Yes, but I would wait for @prrace to review the Harfbuzz change. > Hi @kevinrushforth and @AlanBateman , are you fine with this change? No objection from me but I agree with Kevin to wait to see what Phil says about Harfbuzz. ------------- PR: https://git.openjdk.org/jdk/pull/12005 From duke at openjdk.org Tue Jan 17 17:04:49 2023 From: duke at openjdk.org (Fredrik Bredberg) Date: Tue, 17 Jan 2023 17:04:49 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v4] In-Reply-To: <3mWF3cL69YLzYwYI7z0nQB66c_JxuTUMPfTHVn_YjiQ=.00a62b19-8dd8-42ba-9d71-078cf21f2657@github.com> References: <3mWF3cL69YLzYwYI7z0nQB66c_JxuTUMPfTHVn_YjiQ=.00a62b19-8dd8-42ba-9d71-078cf21f2657@github.com> Message-ID: On Tue, 17 Jan 2023 13:32:47 GMT, Martin Doerr wrote: >> Fredrik Bredberg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Merge branch 'master' into relativize-locals-JDK-8299795_2023-01-09 >> - Added references to JDK-8300197 >> - Updated some copyright dates. >> - Changed copyright date to 2023 >> - 8299795: Relativize locals in interpreter frames > > src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp line 1035: > >> 1033: __ sub(R12_scratch2, R18_locals, R1_SP); >> 1034: __ srdi(R12_scratch2, R12_scratch2, Interpreter::logStackElementSize); >> 1035: // Now &fp()[R12_scratch2] == R18_locals > > I think this comment makes no sense. Please remove it. Otherwise, PPC64 code LGTM. My intention was to show how the contents of R18_locals (the absolute address to locals) can be recreated by using R12_scratch2 as an index from the frame pointer. Before we stored R18_locals in the stackframe, now we store R12_scratch2. Does that make more sense? ------------- PR: https://git.openjdk.org/jdk/pull/11902 From xliu at openjdk.org Tue Jan 17 17:12:42 2023 From: xliu at openjdk.org (Xin Liu) Date: Tue, 17 Jan 2023 17:12:42 GMT Subject: Integrated: 8300184: Optimize ResourceHashtableBase::iterate_all using _number_of_entries In-Reply-To: References: Message-ID: On Mon, 16 Jan 2023 19:50:37 GMT, Xin Liu wrote: > Current implementation needs to visit all buckets. In extreme case, an empty hashtable with 1k buckets. iterate_all() loads 1k buckets for nothing. `_number_of_entries` is the number of nodes in the hashtable. This patch leverages that to quit iteration earlier. The real effect is up to the distribution of nodes among buckets. > > I also included a debug log in the original patch. It was used for the observation in the following section, but I deleted it because it introduces circular dependency. > > log_debug(hashtables)("ResourceHashtableBase table_size = %d, break at " INTX_FORMAT, sz, (bucket - table())); > > **Evaluation** > In release build, the patch is very marginal. class loading do use ResourceHashtable but they are saturated. > > I use it to run `Renaissance/finagle-http`. hahstable iterate_all quits a little bit earlier and save some loads. eg. in line 2, there are 109 buckets in the hashable. the iteration quit at 68th bucket, we save 42 loads. > > > $java -Xlog:hashtables=debug -jar renaissance-gpl-0.14.1.jar finagle-http > ... > [12.824s][debug][hashtables] table_size = 109, break at 109 > [12.824s][debug][hashtables] table_size = 109, break at 68 > [12.824s][debug][hashtables] table_size = 109, break at 107 > [12.825s][debug][hashtables] table_size = 109, break at 108 > [12.825s][debug][hashtables] table_size = 109, break at 99 > [12.825s][debug][hashtables] table_size = 109, break at 108 > [12.825s][debug][hashtables] table_size = 109, break at 98 > [12.825s][debug][hashtables] table_size = 109, break at 109 > [12.825s][debug][hashtables] table_size = 109, break at 102 > ... > > > Another application is in AsyncLog Thread. We have a hashtable with 17 buckets. Each Log Output creates one node in the hashtable. In common cases, there are only 2~3 nodes in the hashtable. Each time AsyncLog Thread flushes the buffer, it has to scan the hashtable twice. Saving loads means saving the memory bandwidth for the application. > > In fastdebug build, extra verification is deployed. It's common to observe that JVM scan an empty hashtable. It's in destroy_VM. > > > ./build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xlog:hashtables=debug --version > openjdk 21-internal 2023-09-19 > OpenJDK Runtime Environment (fastdebug build 21-internal-adhoc.xxinliu.jdk) > OpenJDK 64-Bit Server VM (fastdebug build 21-internal-adhoc.xxinliu.jdk, mixed mode, sharing) > [0.130s][debug][hashtables] table_size = 139, break at 0 > [0.136s][debug][hashtables] table_size = 107, break at 0 > [0.136s][debug][hashtables] table_size = 1009, break at 0 > [0.136s][debug][hashtables] table_size = 109, break at 107 > [0.136s][debug][hashtables] table_size = 109, break at 109 > [0.137s][debug][hashtables] table_size = 109, break at 101 This pull request has now been integrated. Changeset: 0b9ff06f Author: Xin Liu URL: https://git.openjdk.org/jdk/commit/0b9ff06f3a72d26d64cdc43f9991005bba2aedba Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod 8300184: Optimize ResourceHashtableBase::iterate_all using _number_of_entries Reviewed-by: dholmes, rehn ------------- PR: https://git.openjdk.org/jdk/pull/12016 From aph at openjdk.org Tue Jan 17 17:37:20 2023 From: aph at openjdk.org (Andrew Haley) Date: Tue, 17 Jan 2023 17:37:20 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v4] In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 08:35:45 GMT, Fredrik Bredberg wrote: >> Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. >> Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. >> Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. > > Fredrik Bredberg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' into relativize-locals-JDK-8299795_2023-01-09 > - Added references to JDK-8300197 > - Updated some copyright dates. > - Changed copyright date to 2023 > - 8299795: Relativize locals in interpreter frames > Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. Please explain for the record the purpose of this patch. Neither the PR nor the Jira issue explain. I presume it's something to do with making the mounting and unmounting of interpreter frames easier, but this must be said somewhere. ------------- PR: https://git.openjdk.org/jdk/pull/11902 From skuksenko at openjdk.org Tue Jan 17 17:56:21 2023 From: skuksenko at openjdk.org (Sergey Kuksenko) Date: Tue, 17 Jan 2023 17:56:21 GMT Subject: RFR: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions [v3] In-Reply-To: References: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> Message-ID: On Mon, 16 Jan 2023 18:47:12 GMT, Igor Veresov wrote: >> src/hotspot/share/asm/assembler.hpp line 248: >> >>> 246: class InlineSkippedInstructionsCounter: public StackObj { >>> 247: private: >>> 248: AbstractAssembler* _assm; >> >> May be you should record `_assm->_code_section` instead and directly call `_code_section->register_skipped(_start)` instead of adding `AbstractAssembler:: register_skipped(size)`. With `CodeSection` code: >> >> register_skipped(address start) { >> _skipped_instructions_size += (_end - start); >> } > > Or may be it should be done in the destructor of `InlineSkippedInstructionsCounter`? Would be IMO cleaner. I could do it as you wish. Please, tell me which variant is preferable for you. PS But personally, I don't like putting actions inside destructors due to implicitness/non-visibility. ------------- PR: https://git.openjdk.org/jdk/pull/11958 From prr at openjdk.org Tue Jan 17 18:05:14 2023 From: prr at openjdk.org (Phil Race) Date: Tue, 17 Jan 2023 18:05:14 GMT Subject: RFR: 8300169: Build failure with clang-15 In-Reply-To: References: <0hacUHSSaPqiYtv3EsaC4UVe_da0hydgcTrpUpn9w6s=.ae39b693-7f04-40ab-94c0-a90f95c6c260@github.com> Message-ID: On Tue, 17 Jan 2023 13:35:25 GMT, Kevin Rushforth wrote: >>> Normally, such changes in third-party libraries need to be done upstream, and not locally. @prrace can confirm. >> >> Thanks @kevinrushforth for your review. >> >> Yes, it had been fixed in the upstream and I just follow it. >> Please see https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202 . >> >> Or did you mean we had to sync the whole harfbuzz with the upstream? >> If so, I would suggest doing it in a separate PR. >> What do you think? >> Thanks. > > No, I didn't mean to update all of harfbuzz. What you've done seems fine to me, but let's see what @prrace says. If the *exact* same change has been committed upstream then we are OK to take this because then when we upgrade harfbuzz (under a separate bug) whoever doing the upgrade can be blissfully ignorant of this. In fact it is because there is no easy way to be track changes on the JDK side and reapply them that we have this rule. ------------- PR: https://git.openjdk.org/jdk/pull/12005 From skuksenko at openjdk.org Tue Jan 17 18:10:45 2023 From: skuksenko at openjdk.org (Sergey Kuksenko) Date: Tue, 17 Jan 2023 18:10:45 GMT Subject: RFR: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions [v5] In-Reply-To: References: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> <1p4LqC5qz2G2jC1o4jKUkojrPSunDKphonFYcBE9hdc=.caf05d56-3243-44b2-8259-dcfcac94fe24@github.com> Message-ID: On Mon, 16 Jan 2023 19:07:54 GMT, Igor Veresov wrote: >> Sergey Kuksenko has updated the pull request incrementally with one additional commit since the last revision: >> >> remove unused fields > > src/hotspot/share/asm/assembler.hpp line 257: > >> 255: } >> 256: }; >> 257: friend class InlineSkippedInstructionsCounter; > > Technically, in C++11 this is not necessary. Nested classes are automatically friends with the outer class. Let's make it more clear. Should I remove friend class declaration or not? > src/hotspot/share/ci/ciMethod.cpp line 1127: > >> 1125: CompiledMethod* code = get_Method()->code(); >> 1126: if (code != NULL && (code->comp_level() == CompLevel_full_optimization)) { >> 1127: int isize = code->insts_end() - code->verified_entry_point() - code->skipped_instructions_size(); > > FYI, there is `CompiledMethod` has `insts_size()` that returns the code size. May be use it? I'd rather prefer to have smaller changes to the current code. Now we use ciMethod::instructions_size(), let's continue to this (even it was renamed to ciMethod::inline_instructions_size()) ------------- PR: https://git.openjdk.org/jdk/pull/11958 From iveresov at openjdk.org Tue Jan 17 18:10:48 2023 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 17 Jan 2023 18:10:48 GMT Subject: RFR: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions [v5] In-Reply-To: References: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> <1p4LqC5qz2G2jC1o4jKUkojrPSunDKphonFYcBE9hdc=.caf05d56-3243-44b2-8259-dcfcac94fe24@github.com> Message-ID: <6EKxWfM9R-zD2S467g8Uw2GcLiCKbZlVALm9ZUaTU9s=.ec02c601-f730-42b0-87a2-b3823ce1e32c@github.com> On Tue, 17 Jan 2023 18:06:24 GMT, Sergey Kuksenko wrote: >> src/hotspot/share/asm/assembler.hpp line 257: >> >>> 255: } >>> 256: }; >>> 257: friend class InlineSkippedInstructionsCounter; >> >> Technically, in C++11 this is not necessary. Nested classes are automatically friends with the outer class. > > Let's make it more clear. Should I remove friend class declaration or not? Yes, remove it, it's redundant. ------------- PR: https://git.openjdk.org/jdk/pull/11958 From iveresov at openjdk.org Tue Jan 17 18:13:50 2023 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 17 Jan 2023 18:13:50 GMT Subject: RFR: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions [v3] In-Reply-To: References: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> Message-ID: On Tue, 17 Jan 2023 17:53:30 GMT, Sergey Kuksenko wrote: >> Or may be it should be done in the destructor of `InlineSkippedInstructionsCounter`? Would be IMO cleaner. > > I could do it as you wish. Please, tell me which variant is preferable for you. > PS But personally, I don't like putting actions inside destructors due to implicitness/non-visibility. There are a lot of classes that do that (the scoped accumulator pattern) already in the JVM. Let's move it do the destructor. ------------- PR: https://git.openjdk.org/jdk/pull/11958 From coleen.phillimore at oracle.com Tue Jan 17 18:15:21 2023 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 17 Jan 2023 13:15:21 -0500 Subject: CFV: New Hotspot Group Member: Richard Reingruber In-Reply-To: References: Message-ID: <7d67cdff-5f79-55f4-97bb-9f50bf63923e@oracle.com> Vote: yes On 1/17/23 10:04 AM, Lindenmaier, Goetz wrote: > > I hereby nominate Richard Reingruber (rrich)[1] to Membership > > in the Hotspot Group. > > Last, Richard has ported loom to PPC. He is an expert in GC > > algorithms and has deep knowledge of JVMTI and the > > escape analysis of C2. ?He enriched the escape analysis > > to run when JVMTI debugging capabilities of the JVM are > > enabled. He analyzed a lot of complex issues, digging down > > even into the implementation of operating systems as > > Solaris. > > Votes are due by January 31, 2023. > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > For Lazy Consensus voting instructions, see [3]. > Best regards, > ? Goetz. > [1] https://openjdk.org/census#rrich > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prr at openjdk.org Tue Jan 17 18:16:01 2023 From: prr at openjdk.org (Phil Race) Date: Tue, 17 Jan 2023 18:16:01 GMT Subject: RFR: 8300169: Build failure with clang-15 In-Reply-To: References: Message-ID: <4D6-l2p6z4lIpe84jpo-YMcnf1dUfmzrdF3C_KV1EgY=.ddd7f85b-58c5-451c-af94-aaae35f114bc@github.com> On Sat, 14 Jan 2023 14:28:32 GMT, Jie Fu wrote: > Hi all, > > Please review the fix for the build failure with clang-15. > > 1. -Wbitwise-instead-of-logical > > 1) src/hotspot/share/oops/generateOopMap.cpp <--- fixed the warning > 2) src/hotspot/share/runtime/notificationThread.cpp <--- keep the code and disable warnings > 3) src/hotspot/share/runtime/serviceThread.cpp <--- keep the code and disable warnings > > > 2. -Wdeprecated-non-prototype (all the warnings are disabled) > > 1) Mainly caused by files under `src/java.base/share/native/libzip/zlib/` <--- keep the code and disable warnings > It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN. > > 2) While compiling src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c <--- keep the code and disable warnings > > 3) Caused by src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m <--- fixed the warnings > > > 3. -Wdeprecated-builtins > > Caused by files under src/java.desktop/share/native/libharfbuzz/ <--- fixed the warnings > > Ref: https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202 > > 4. -Wgnu-folding-constant > > Caused by src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m <--- keep the code and disable warnings > > > Thanks. > Best regards, > Jie client changes are OK by me. ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.org/jdk/pull/12005 From smonteith at openjdk.org Tue Jan 17 18:33:06 2023 From: smonteith at openjdk.org (Stuart Monteith) Date: Tue, 17 Jan 2023 18:33:06 GMT Subject: RFR: 8300253: Introduce AArch64 nzcv accessors In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 14:01:05 GMT, Andrew Haley wrote: >> Some code, such as verification code, might want to run without changing the state of the system. To do that, it's useful to be able to get and set the nzcv flags. This enhancement aims at adding accessors for that. > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 591: > >> 589: msr(0b011, 0b0100, 0b0010, 0b000, reg); >> 590: } >> 591: > > We've tried never to to add such things speculatively, as much as anything else because it's impossible to test. Could @fisk provide an example of where this might be used? My assumption is that you are looking to execute code verification within, say, a GC memory barrier, and the code has been inserted in between where the condition codes might have been set and then used. This could avoid breaking the existing code when the verification code itself sets the condition codes. It's not all of the pstate, but then this is just userspace, so it ought to be ok? ------------- PR: https://git.openjdk.org/jdk/pull/12038 From eosterlund at openjdk.org Tue Jan 17 18:52:40 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 17 Jan 2023 18:52:40 GMT Subject: RFR: 8300253: Introduce AArch64 nzcv accessors In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 18:30:02 GMT, Stuart Monteith wrote: > Could @fisk provide an example of where this might be used? > > My assumption is that you are looking to execute code verification within, say, a GC memory barrier, and the code has been inserted in between where the condition codes might have been set and then used. This could avoid breaking the existing code when the verification code itself sets the condition codes. > > It's not all of the pstate, but then this is just userspace, so it ought to be ok? > > Your guess is spot on. We have a bunch of GC barrier nodes in C1, and C1 sprinkles oop verification all over the place - including when spilling oops between lir ops - sometimes between producing a condition code and consuming it. So I figured the verification code shouldn't really alter the state of execution such that it does something different. And I don't really want to reduce the amount of verification, because it was very useful in tracking down bugs. ------------- PR: https://git.openjdk.org/jdk/pull/12038 From vlivanov at openjdk.org Tue Jan 17 18:59:51 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 17 Jan 2023 18:59:51 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v20] In-Reply-To: References: Message-ID: On Mon, 16 Jan 2023 23:28:37 GMT, Claes Redestad wrote: >> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. >> >> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. >> >> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. >> >> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. >> >> With the most recent fixes the x64 intrinsic results on my workstation look like this: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op >> >> I.e. no measurable overhead compared to baseline even for `size == 1`. >> >> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. >> >> Benchmark for `Arrays.hashCode`: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op >> ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op >> ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op >> ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op >> ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op >> ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op >> ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op >> ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op >> ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op >> ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op >> ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op >> ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op >> ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op >> ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op >> ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op >> ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op >> ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op >> ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op >> ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op >> ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op >> ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op >> ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op >> ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op >> ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op >> ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op >> >> >> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > trailing ws Thanks, Claes. Looks good. Please, file an RFE for the follow-up work. src/hotspot/share/opto/machnode.cpp line 211: > 209: opcnt++; // Bump operand count > 210: assert( opcnt < numopnds, "Accessing non-existent operand" ); > 211: A leftover from a previous change? src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 168: > 166: // See https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-6.html#jvms-6.5.newarray. > 167: > 168: public static final int T_BOOLEAN = 4; As an idea for a follow-up enhancement, unless there are plans to implement runtime dispatching between different stubs, the basic type can be coded as a Class and on compiler side the corresponding basic type extracted with `java_lang_Class::as_BasicType()`. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.org/jdk/pull/10847 From vladimir.kozlov at oracle.com Tue Jan 17 19:12:37 2023 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 17 Jan 2023 11:12:37 -0800 Subject: CFV: New Hotspot Group Member: Richard Reingruber In-Reply-To: References: Message-ID: <601b10a7-7d2e-3605-61ea-9c6728043555@oracle.com> Vote: yes Thanks, Vladimir K On 1/17/23 7:04 AM, Lindenmaier, Goetz wrote: > I hereby nominate Richard Reingruber (rrich)[1] to Membership > > in the Hotspot Group. > > Last, Richard has ported loom to PPC. He is an expert in GC > > algorithms and has deep knowledge of JVMTI and the > > escape analysis of C2. ?He enriched the escape analysis > > to run when JVMTI debugging capabilities of the JVM are > > enabled. He analyzed a lot of complex issues, digging down > > even into the implementation of operating systems as > > Solaris. > > Votes are due by January 31, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on > > this nomination.? Votes must be cast in the open by replying to this > > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best regards, > > ? Goetz. > > [1] https://openjdk.org/census#rrich > > [2] https://openjdk.org/census#hotspot > > [3] https://openjdk.org/groups/#member-vote > From rkennke at openjdk.org Tue Jan 17 19:20:52 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 17 Jan 2023 19:20:52 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme Message-ID: This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal pro tocols. The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. This change enables to simplify (and speed-up!) a lot of code: - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR Testing: - [x] tier1 x86_64 x aarch64 x +UseFastLocking - [x] tier2 x86_64 x aarch64 x +UseFastLocking - [x] tier3 x86_64 x aarch64 x +UseFastLocking - [x] tier4 x86_64 x aarch64 x +UseFastLocking - [x] tier1 x86_64 x aarch64 x -UseFastLocking - [x] tier2 x86_64 x aarch64 x -UseFastLocking - [x] tier3 x86_64 x aarch64 x -UseFastLocking - [x] tier4 x86_64 x aarch64 x -UseFastLocking - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet ### Performance #### Renaissance ? | x86_64 | ? | ? | ? | aarch64 | ? | ? -- | -- | -- | -- | -- | -- | -- | -- ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% ------------- Commit messages: - Use testb when testing for anon owner in fast-path - Merge branch 'master' into JDK-8291555-v2 - In x86_32 C2 fast_lock(), CAS thread directly, instead of CASing stack-pointer and then storing thread - x86 part of optimization to check for anon owner - Optimize the check-for-anon-owner fast-path - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2 - Fix method signature of build_frame() on ppc, arm and s390 - Remove unnecessary assert - Refactorings and cleanups (runtime) - Some refactorings (x86) - ... and 72 more: https://git.openjdk.org/jdk/compare/e7fa150b...c4746710 Changes: https://git.openjdk.org/jdk/pull/10907/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291555 Stats: 1924 lines in 74 files changed: 1212 ins; 97 del; 615 mod Patch: https://git.openjdk.org/jdk/pull/10907.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10907/head:pull/10907 PR: https://git.openjdk.org/jdk/pull/10907 From rkennke at openjdk.org Tue Jan 17 19:20:53 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 17 Jan 2023 19:20:53 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 20:17:37 GMT, Roman Kennke wrote: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Renaissance > > > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > Hi, I have also updated the riscv part from #10590. Could you please put these changes in this PR? Thanks. I can run non-trivial benchmark workloads with +UseFastLocking on linux-riscv64 platform. I will try to perform more tests as needed. > > [10907-riscv-v1.txt](https://github.com/openjdk/jdk/files/10012199/10907-riscv-v1.txt) Thanks, Fei! I have pushed your changes. I will very likely need your help with this again later, I am currently working on some optimizations that should make fast-locking even better. ------------- PR: https://git.openjdk.org/jdk/pull/10907 From fyang at openjdk.org Tue Jan 17 19:20:53 2023 From: fyang at openjdk.org (Fei Yang) Date: Tue, 17 Jan 2023 19:20:53 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 20:17:37 GMT, Roman Kennke wrote: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Renaissance > > > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Hi, I have also updated the riscv part from https://github.com/openjdk/jdk/pull/10590. Could you please put these changes in this PR? Thanks. I can run non-trivial benchmark workloads with +UseFastLocking on linux-riscv64 platform. I will try to perform more tests as needed. [10907-riscv-v1.txt](https://github.com/openjdk/jdk/files/10012199/10907-riscv-v1.txt) ------------- PR: https://git.openjdk.org/jdk/pull/10907 From rehn at openjdk.org Tue Jan 17 19:20:55 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Tue, 17 Jan 2023 19:20:55 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 20:17:37 GMT, Roman Kennke wrote: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Renaissance > > > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% src/hotspot/share/runtime/objectMonitor.hpp line 274: > 272: > 273: bool is_owner_anonymous() const { > 274: return _owner == ANONYMOUS_OWNER; This should be `return owner_raw() == ANONYMOUS_OWNER;` test/hotspot/jtreg/compiler/floatingpoint/TestFloatSyncJNIArgs.java line 30: > 28: * > 29: * > 30: * @run main/othervm/native -XX:TieredStopAtLevel=1 compiler.floatingpoint.TestFloatSyncJNIArgs Is this related somehow? ------------- PR: https://git.openjdk.org/jdk/pull/10907 From dholmes at openjdk.org Tue Jan 17 19:20:56 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 17 Jan 2023 19:20:56 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme In-Reply-To: References: Message-ID: <3qWct3v1u9hKt7N8ZWTZfOAyeVfY-N9x6B2O9aMAR-Q=.76f9b404-7e30-4472-b5b5-f23563ff7958@github.com> On Fri, 28 Oct 2022 20:17:37 GMT, Roman Kennke wrote: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Renaissance > > > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% src/hotspot/share/runtime/thread.cpp line 77: > 75: > 76: Thread::Thread() : > 77: _lock_stack() { Surely only needed for `JavaThread`? ------------- PR: https://git.openjdk.org/jdk/pull/10907 From never at openjdk.org Tue Jan 17 19:27:31 2023 From: never at openjdk.org (Tom Rodriguez) Date: Tue, 17 Jan 2023 19:27:31 GMT Subject: RFR: JDK-8299229: Allow UseZGC with JVMCI and enable nmethod entry barrier support [v2] In-Reply-To: References: Message-ID: > This exposes the required ZGC values to JVMCI and adds support for nmethod entry barriers. The ZGC support is straightforward but the nmethod entry barrier required some reworking to fit better into JVMCI usage. I also removed the epoch based barrier since it was no longer used with simplified the assumptions on the JVMCI side. There is also a minor loom related fix to support post call nops included. I could move that into a separate PR if that would be preferred. Tom Rodriguez 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: Allow UseZGC with JVMCI and enable nmethod entry barrier support ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11996/files - new: https://git.openjdk.org/jdk/pull/11996/files/bbc7df3b..d3ae96cb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11996&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11996&range=00-01 Stats: 3429 lines in 495 files changed: 1184 ins; 681 del; 1564 mod Patch: https://git.openjdk.org/jdk/pull/11996.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11996/head:pull/11996 PR: https://git.openjdk.org/jdk/pull/11996 From never at openjdk.org Tue Jan 17 19:27:33 2023 From: never at openjdk.org (Tom Rodriguez) Date: Tue, 17 Jan 2023 19:27:33 GMT Subject: RFR: JDK-8299229: Allow UseZGC with JVMCI and enable nmethod entry barrier support In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 20:02:26 GMT, Tom Rodriguez wrote: > This exposes the required ZGC values to JVMCI and adds support for nmethod entry barriers. The ZGC support is straightforward but the nmethod entry barrier required some reworking to fit better into JVMCI usage. I also removed the epoch based barrier since it was no longer used with simplified the assumptions on the JVMCI side. There is also a minor loom related fix to support post call nops included. I could move that into a separate PR if that would be preferred. I've dropped the removal of the epoch stuff and exposed the epoch addr for use by code generation. ------------- PR: https://git.openjdk.org/jdk/pull/11996 From daniel.daugherty at oracle.com Tue Jan 17 19:39:27 2023 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Tue, 17 Jan 2023 14:39:27 -0500 Subject: CFV: New Hotspot Group Member: Richard Reingruber In-Reply-To: References: Message-ID: <9f372670-30c2-7860-184d-28a84eff456e@oracle.com> Vote: yes Dan On 1/17/23 10:04 AM, Lindenmaier, Goetz wrote: > > I hereby nominate Richard Reingruber (rrich)[1] to Membership > > in the Hotspot Group. > > Last, Richard has ported loom to PPC. He is an expert in GC > > algorithms and has deep knowledge of JVMTI and the > > escape analysis of C2. ?He enriched the escape analysis > > to run when JVMTI debugging capabilities of the JVM are > > enabled. He analyzed a lot of complex issues, digging down > > even into the implementation of operating systems as > > Solaris. > > Votes are due by January 31, 2023. > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list. > For Lazy Consensus voting instructions, see [3]. > Best regards, > ? Goetz. > [1] https://openjdk.org/census#rrich > [2] https://openjdk.org/census#hotspot > [3] https://openjdk.org/groups/#member-vote > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.osterlund at oracle.com Tue Jan 17 19:47:08 2023 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Tue, 17 Jan 2023 19:47:08 +0000 Subject: CFV: New Hotspot Group Member: Richard Reingruber In-Reply-To: References: Message-ID: <2CAC22CF-B8EF-4F29-A286-29B8BFFEDCCC@oracle.com> Vote: yes /Erik On 17 Jan 2023, at 16:05, Lindenmaier, Goetz wrote: ? I hereby nominate Richard Reingruber (rrich)[1] to Membership in the Hotspot Group. Last, Richard has ported loom to PPC. He is an expert in GC algorithms and has deep knowledge of JVMTI and the escape analysis of C2. He enriched the escape analysis to run when JVMTI debugging capabilities of the JVM are enabled. He analyzed a lot of complex issues, digging down even into the implementation of operating systems as Solaris. Votes are due by January 31, 2023. Only current Members of the hotspot Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Best regards, Goetz. [1] https://openjdk.org/census#rrich [2] https://openjdk.org/census#hotspot [3] https://openjdk.org/groups/#member-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From skuksenko at openjdk.org Tue Jan 17 20:23:05 2023 From: skuksenko at openjdk.org (Sergey Kuksenko) Date: Tue, 17 Jan 2023 20:23:05 GMT Subject: RFR: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions [v6] In-Reply-To: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> References: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> Message-ID: > Post call nop instructions increase the size of methods, which leads to different inline decisions and performance regression. > Restore inline behavior by excluding post call nop instructions sizes from inline heuristics. Sergey Kuksenko has updated the pull request incrementally with one additional commit since the last revision: move register noops size into destructor ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11958/files - new: https://git.openjdk.org/jdk/pull/11958/files/dc849600..e6ae63f0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11958&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11958&range=04-05 Stats: 5 lines in 4 files changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11958.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11958/head:pull/11958 PR: https://git.openjdk.org/jdk/pull/11958 From skuksenko at openjdk.org Tue Jan 17 20:23:07 2023 From: skuksenko at openjdk.org (Sergey Kuksenko) Date: Tue, 17 Jan 2023 20:23:07 GMT Subject: RFR: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions [v5] In-Reply-To: <6EKxWfM9R-zD2S467g8Uw2GcLiCKbZlVALm9ZUaTU9s=.ec02c601-f730-42b0-87a2-b3823ce1e32c@github.com> References: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> <1p4LqC5qz2G2jC1o4jKUkojrPSunDKphonFYcBE9hdc=.caf05d56-3243-44b2-8259-dcfcac94fe24@github.com> <6EKxWfM9R-zD2S467g8Uw2GcLiCKbZlVALm9ZUaTU9s=.ec02c601-f730-42b0-87a2-b3823ce1e32c@github.com> Message-ID: On Tue, 17 Jan 2023 18:07:34 GMT, Igor Veresov wrote: >> Let's make it more clear. Should I remove friend class declaration or not? > > Yes, remove it, it's redundant. done ------------- PR: https://git.openjdk.org/jdk/pull/11958 From skuksenko at openjdk.org Tue Jan 17 20:23:06 2023 From: skuksenko at openjdk.org (Sergey Kuksenko) Date: Tue, 17 Jan 2023 20:23:06 GMT Subject: RFR: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions [v3] In-Reply-To: References: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> Message-ID: On Tue, 17 Jan 2023 18:10:45 GMT, Igor Veresov wrote: >> I could do it as you wish. Please, tell me which variant is preferable for you. >> PS But personally, I don't like putting actions inside destructors due to implicitness/non-visibility. > > There are a lot of classes that do that (the scoped accumulator pattern) already in the JVM. Let's move it do the destructor. done ------------- PR: https://git.openjdk.org/jdk/pull/11958 From cjplummer at openjdk.org Tue Jan 17 20:53:23 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 17 Jan 2023 20:53:23 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v5] In-Reply-To: References: <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com> Message-ID: On Tue, 17 Jan 2023 01:28:08 GMT, David Holmes wrote: >> Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Merge >> - correction for ppc >> - missed update for debug mode >> - more in src/hotspot >> - typo correction >> - 8299635: More test issues for deprecated sprintf in Xcode 14 > > src/hotspot/os/windows/os_windows.cpp line 387: > >> 385: os::snprintf_checked(buf, sizeof(buf), "%s%s;%s%s%s", >> 386: Arguments::get_java_home(), EXT_DIR, >> 387: path, PACKAGE_DIR, EXT_DIR); > > When the call is split across multiple lines like this, the subsequent lines should align with the first parameter i.e. align under `buf`. I think the other acceptable approach is to put the first argument on the 2nd line, and then indent all the argument lines by 8. That works well if the first argument would otherwise start too far to the right. For the above, I think either approach would look ok. ------------- PR: https://git.openjdk.org/jdk/pull/11935 From redestad at openjdk.org Tue Jan 17 20:55:08 2023 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 17 Jan 2023 20:55:08 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v21] In-Reply-To: References: Message-ID: > Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. > > I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. > > Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. > > The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. > > With the most recent fixes the x64 intrinsic results on my workstation look like this: > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op > StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op > StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op > StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op > > Baseline: > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op > StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op > StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op > StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op > > I.e. no measurable overhead compared to baseline even for `size == 1`. > > The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. > > Benchmark for `Arrays.hashCode`: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op > ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op > ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op > ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op > ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op > ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op > ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op > ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op > ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op > ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op > ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op > ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op > ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op > ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op > ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op > ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op > > Baseline: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op > ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op > ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op > ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op > ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op > ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op > ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op > ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op > ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op > ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op > ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op > ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op > ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op > ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op > ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op > ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op > > > As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Remove spurious newline ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10847/files - new: https://git.openjdk.org/jdk/pull/10847/files/ffe5b66d..48c068bb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=20 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=19-20 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10847.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10847/head:pull/10847 PR: https://git.openjdk.org/jdk/pull/10847 From redestad at openjdk.org Tue Jan 17 20:55:12 2023 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 17 Jan 2023 20:55:12 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v20] In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 18:46:00 GMT, Vladimir Ivanov wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> trailing ws > > src/hotspot/share/opto/machnode.cpp line 211: > >> 209: opcnt++; // Bump operand count >> 210: assert( opcnt < numopnds, "Accessing non-existent operand" ); >> 211: > > A leftover from a previous change? Fixed ------------- PR: https://git.openjdk.org/jdk/pull/10847 From redestad at openjdk.org Tue Jan 17 21:06:01 2023 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 17 Jan 2023 21:06:01 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v22] In-Reply-To: References: Message-ID: > Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. > > I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. > > Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. > > The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. > > With the most recent fixes the x64 intrinsic results on my workstation look like this: > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op > StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op > StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op > StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op > > Baseline: > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op > StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op > StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op > StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op > > I.e. no measurable overhead compared to baseline even for `size == 1`. > > The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. > > Benchmark for `Arrays.hashCode`: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op > ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op > ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op > ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op > ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op > ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op > ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op > ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op > ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op > ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op > ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op > ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op > ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op > ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op > ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op > ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op > > Baseline: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op > ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op > ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op > ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op > ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op > ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op > ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op > ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op > ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op > ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op > ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op > ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op > ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op > ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op > ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op > ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op > > > As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 76 commits: - Copyrights - Merge branch 'master' into 8282664-polyhash - Remove spurious newline - trailing ws - Change signature to offset + length, add sanity test - Adapt end input to len (fix latent bug with sub-ranges - Clean-up types, simplify, hoist special-casing of String variants from arrays_hashcode, add initial value and range to intrinsic - Explicitly lea external address - Merge branch 'master' into 8282664-polyhash - Treat Op_VectorizedHashCode as other similar Ops in split_unique_types - ... and 66 more: https://git.openjdk.org/jdk/compare/ade08e19...7e6080b6 ------------- Changes: https://git.openjdk.org/jdk/pull/10847/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=21 Stats: 1062 lines in 33 files changed: 975 ins; 9 del; 78 mod Patch: https://git.openjdk.org/jdk/pull/10847.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10847/head:pull/10847 PR: https://git.openjdk.org/jdk/pull/10847 From redestad at openjdk.org Tue Jan 17 21:09:56 2023 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 17 Jan 2023 21:09:56 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v21] In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 20:55:08 GMT, Claes Redestad wrote: >> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. >> >> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. >> >> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. >> >> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. >> >> With the most recent fixes the x64 intrinsic results on my workstation look like this: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op >> >> I.e. no measurable overhead compared to baseline even for `size == 1`. >> >> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. >> >> Benchmark for `Arrays.hashCode`: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op >> ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op >> ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op >> ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op >> ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op >> ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op >> ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op >> ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op >> ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op >> ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op >> ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op >> ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op >> ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op >> ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op >> ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op >> ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op >> ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op >> ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op >> ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op >> ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op >> ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op >> ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op >> ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op >> ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op >> ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op >> >> >> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Remove spurious newline Thanks for your patience and reviews. ------------- PR: https://git.openjdk.org/jdk/pull/10847 From redestad at openjdk.org Tue Jan 17 21:09:58 2023 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 17 Jan 2023 21:09:58 GMT Subject: Integrated: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops In-Reply-To: References: Message-ID: On Tue, 25 Oct 2022 10:37:40 GMT, Claes Redestad wrote: > Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. > > I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. > > Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. > > The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. > > With the most recent fixes the x64 intrinsic results on my workstation look like this: > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op > StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op > StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op > StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op > > Baseline: > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op > StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op > StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op > StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op > > I.e. no measurable overhead compared to baseline even for `size == 1`. > > The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. > > Benchmark for `Arrays.hashCode`: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op > ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op > ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op > ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op > ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op > ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op > ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op > ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op > ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op > ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op > ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op > ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op > ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op > ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op > ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op > ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op > > Baseline: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op > ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op > ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op > ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op > ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op > ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op > ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op > ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op > ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op > ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op > ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op > ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op > ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op > ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op > ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op > ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op > > > As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. This pull request has now been integrated. Changeset: e37078f5 Author: Claes Redestad URL: https://git.openjdk.org/jdk/commit/e37078f5bb626c7ce0348a38bb86ca2ca62ba915 Stats: 1062 lines in 33 files changed: 975 ins; 9 del; 78 mod 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops Co-authored-by: Sandhya Viswanathan Co-authored-by: Ludovic Henry Co-authored-by: Claes Redestad Reviewed-by: vlivanov, sviswanathan, luhenry ------------- PR: https://git.openjdk.org/jdk/pull/10847 From vladimir.x.ivanov at oracle.com Tue Jan 17 21:19:19 2023 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 17 Jan 2023 13:19:19 -0800 Subject: CFV: New Hotspot Group Member: Richard Reingruber In-Reply-To: References: Message-ID: <4df37450-7bc6-a79e-7c00-7e500773759c@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 1/17/23 07:04, Lindenmaier, Goetz wrote: > I hereby nominate Richard Reingruber (rrich)[1] to Membership > > in the Hotspot Group. > From eosterlund at openjdk.org Tue Jan 17 21:50:46 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 17 Jan 2023 21:50:46 GMT Subject: RFR: JDK-8299229: Allow UseZGC with JVMCI and enable nmethod entry barrier support [v2] In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 19:27:31 GMT, Tom Rodriguez wrote: >> This exposes the required ZGC values to JVMCI and adds support for nmethod entry barriers. The ZGC support is straightforward but the nmethod entry barrier required some reworking to fit better into JVMCI usage. I also removed the epoch based barrier since it was no longer used with simplified the assumptions on the JVMCI side. There is also a minor loom related fix to support post call nops included. I could move that into a separate PR if that would be preferred. > > Tom Rodriguez 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: > > Allow UseZGC with JVMCI and enable nmethod entry barrier support Changes requested by eosterlund (Reviewer). src/hotspot/cpu/riscv/gc/shared/barrierSetNMethod_riscv.cpp line 53: > 51: case NMethodPatchingType::conc_data_patch: > 52: return -4 * (5 + slow_path_size(nm)); > 53: case NMethodPatchingType::conc_instruction_and_data_patch: Please re-instate these two lines. src/hotspot/cpu/x86/gc/shared/barrierSetNMethod_x86.cpp line 189: > 187: } else > 188: #endif > 189: barrier_address = nm->code_begin() + nm->frame_complete_offset() + entry_barrier_offset(nm); This line looks like a ticking bomb. Can we have brackets or something? src/hotspot/share/code/nmethod.cpp line 562: > 560: nmethod* nm = NULL; > 561: #if INCLUDE_JVMCI > 562: int jvmci_data_size = compiler->is_jvmci() ? jvmci_data->size() : 0; Weird indentation src/hotspot/share/jvmci/jvmciCodeInstaller.cpp line 732: > 730: > 731: if (UseZGC && _nmethod_entry_patch_offset == -1) { > 732: // ZGC requires the use of entry barriers for correctness Note that G1 also requires nmethod entry barriers for correctness. src/hotspot/share/jvmci/jvmciCodeInstaller.cpp line 774: > 772: if (_nmethod_entry_patch_offset != -1) { > 773: BarrierSetNMethod* bs_nm = BarrierSet::barrier_set()->barrier_set_nmethod(); > 774: if (bs_nm == nullptr) { Should never be null. ARM32 was the last to enter the scene but now all platforms have these. src/hotspot/share/jvmci/jvmciRuntime.hpp line 460: > 458: FailedSpeculation** failed_speculations, > 459: char* speculations, > 460: int speculations_len, Weird indentation ------------- PR: https://git.openjdk.org/jdk/pull/11996 From kvn at openjdk.org Tue Jan 17 23:07:49 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 17 Jan 2023 23:07:49 GMT Subject: RFR: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions [v6] In-Reply-To: References: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> Message-ID: On Tue, 17 Jan 2023 20:23:05 GMT, Sergey Kuksenko wrote: >> Post call nop instructions increase the size of methods, which leads to different inline decisions and performance regression. >> Restore inline behavior by excluding post call nop instructions sizes from inline heuristics. > > Sergey Kuksenko has updated the pull request incrementally with one additional commit since the last revision: > > move register noops size into destructor Update looks good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11958 From iveresov at openjdk.org Tue Jan 17 23:17:26 2023 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 17 Jan 2023 23:17:26 GMT Subject: RFR: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions [v6] In-Reply-To: References: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> Message-ID: On Tue, 17 Jan 2023 20:23:05 GMT, Sergey Kuksenko wrote: >> Post call nop instructions increase the size of methods, which leads to different inline decisions and performance regression. >> Restore inline behavior by excluding post call nop instructions sizes from inline heuristics. > > Sergey Kuksenko has updated the pull request incrementally with one additional commit since the last revision: > > move register noops size into destructor Marked as reviewed by iveresov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11958 From eosterlund at openjdk.org Tue Jan 17 23:36:31 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 17 Jan 2023 23:36:31 GMT Subject: RFR: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions [v6] In-Reply-To: References: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> Message-ID: <6BTg4wqDr_-OReKtPVbQSFJxZ2bFvSVIOvtlU2m3KvE=.e9ecebbe-a9ae-4e6f-a90d-1baad4c1d690@github.com> On Tue, 17 Jan 2023 20:23:05 GMT, Sergey Kuksenko wrote: >> Post call nop instructions increase the size of methods, which leads to different inline decisions and performance regression. >> Restore inline behavior by excluding post call nop instructions sizes from inline heuristics. > > Sergey Kuksenko has updated the pull request incrementally with one additional commit since the last revision: > > move register noops size into destructor Marked as reviewed by eosterlund (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11958 From jiefu at openjdk.org Tue Jan 17 23:56:34 2023 From: jiefu at openjdk.org (Jie Fu) Date: Tue, 17 Jan 2023 23:56:34 GMT Subject: RFR: 8300169: Build failure with clang-15 In-Reply-To: <4D6-l2p6z4lIpe84jpo-YMcnf1dUfmzrdF3C_KV1EgY=.ddd7f85b-58c5-451c-af94-aaae35f114bc@github.com> References: <4D6-l2p6z4lIpe84jpo-YMcnf1dUfmzrdF3C_KV1EgY=.ddd7f85b-58c5-451c-af94-aaae35f114bc@github.com> Message-ID: On Tue, 17 Jan 2023 18:12:44 GMT, Phil Race wrote: > client changes are OK by me. Thanks @prrace . ------------- PR: https://git.openjdk.org/jdk/pull/12005 From jiefu at openjdk.org Tue Jan 17 23:56:32 2023 From: jiefu at openjdk.org (Jie Fu) Date: Tue, 17 Jan 2023 23:56:32 GMT Subject: RFR: 8300169: Build failure with clang-15 In-Reply-To: References: Message-ID: <0NMWnUwU-YKzQ9V5AtT03yxs2OQQ6GnbrqLfi989mkg=.34ce9025-a67a-40fd-b27c-fa5aee2795be@github.com> On Sat, 14 Jan 2023 14:28:32 GMT, Jie Fu wrote: > Hi all, > > Please review the fix for the build failure with clang-15. > > 1. -Wbitwise-instead-of-logical > > 1) src/hotspot/share/oops/generateOopMap.cpp <--- fixed the warning > 2) src/hotspot/share/runtime/notificationThread.cpp <--- keep the code and disable warnings > 3) src/hotspot/share/runtime/serviceThread.cpp <--- keep the code and disable warnings > > > 2. -Wdeprecated-non-prototype (all the warnings are disabled) > > 1) Mainly caused by files under `src/java.base/share/native/libzip/zlib/` <--- keep the code and disable warnings > It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN. > > 2) While compiling src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c <--- keep the code and disable warnings > > 3) Caused by src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m <--- fixed the warnings > > > 3. -Wdeprecated-builtins > > Caused by files under src/java.desktop/share/native/libharfbuzz/ <--- fixed the warnings > > Ref: https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202 > > 4. -Wgnu-folding-constant > > Caused by src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m <--- keep the code and disable warnings > > > Thanks. > Best regards, > Jie > _Mailing list message from [Patrick Chen](mailto:chen.j.patrick at gmail.com) on [build-dev](mailto:build-dev at mail.openjdk.org):_ > > no you have to revert the commit Why? Is there anything wrong? Thanks. > > Le mar. 17 janv. 2023 ? 17:55, Alan Bateman a ?crit : > > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------- PR: https://git.openjdk.org/jdk/pull/12005 From skuksenko at openjdk.org Wed Jan 18 00:19:43 2023 From: skuksenko at openjdk.org (Sergey Kuksenko) Date: Wed, 18 Jan 2023 00:19:43 GMT Subject: Integrated: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions In-Reply-To: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> References: <6-jLuxS9KfsPI52kru100qVY36CCnwUXbbdbZ8mnPpk=.aec17c58-bec3-4cf2-9f9c-80d3108bacab@github.com> Message-ID: On Thu, 12 Jan 2023 02:52:17 GMT, Sergey Kuksenko wrote: > Post call nop instructions increase the size of methods, which leads to different inline decisions and performance regression. > Restore inline behavior by excluding post call nop instructions sizes from inline heuristics. This pull request has now been integrated. Changeset: 89a032dc Author: Sergey Kuksenko URL: https://git.openjdk.org/jdk/commit/89a032dc057d04c996632ad317a0303cf3560852 Stats: 73 lines in 14 files changed: 52 ins; 0 del; 21 mod 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions Reviewed-by: kvn, iveresov, eosterlund ------------- PR: https://git.openjdk.org/jdk/pull/11958 From hohensee at amazon.com Wed Jan 18 01:46:13 2023 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 18 Jan 2023 01:46:13 +0000 Subject: CFV: New Hotspot Group Member: Richard Reingruber Message-ID: <0FD7F8D7-03D6-4DE2-A9DE-360409F6B0C8@amazon.com> Vote: yes From: hotspot-dev on behalf of "Lindenmaier, Goetz" Date: Tuesday, January 17, 2023 at 7:05 AM To: "hotspot-dev at openjdk.org" Subject: CFV: New Hotspot Group Member: Richard Reingruber I hereby nominate Richard Reingruber (rrich)[1] to Membership in the Hotspot Group. Last, Richard has ported loom to PPC. He is an expert in GC algorithms and has deep knowledge of JVMTI and the escape analysis of C2. He enriched the escape analysis to run when JVMTI debugging capabilities of the JVM are enabled. He analyzed a lot of complex issues, digging down even into the implementation of operating systems as Solaris. Votes are due by January 31, 2023. Only current Members of the hotspot Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Best regards, Goetz. [1] https://openjdk.org/census#rrich [2] https://openjdk.org/census#hotspot [3] https://openjdk.org/groups/#member-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Jan 18 01:47:41 2023 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Jan 2023 11:47:41 +1000 Subject: CFV: New Hotspot Group Member: Richard Reingruber In-Reply-To: References: Message-ID: <8747edc4-3c7e-ab10-a311-a450fdf8e718@oracle.com> Vote: yes David On 18/01/2023 1:04 am, Lindenmaier, Goetz wrote: > I hereby nominate Richard Reingruber (rrich)[1] to Membership > > in the Hotspot Group. > > Last, Richard has ported loom to PPC. He is an expert in GC > > algorithms and has deep knowledge of JVMTI and the > > escape analysis of C2. ?He enriched the escape analysis > > to run when JVMTI debugging capabilities of the JVM are > > enabled. He analyzed a lot of complex issues, digging down > > even into the implementation of operating systems as > > Solaris. > > Votes are due by January 31, 2023. > > Only current Members of the hotspot Group [2] are eligible to vote on > > this nomination.? Votes must be cast in the open by replying to this > > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best regards, > > ? Goetz. > > [1] https://openjdk.org/census#rrich > > [2] https://openjdk.org/census#hotspot > > [3] https://openjdk.org/groups/#member-vote > > From dholmes at openjdk.org Wed Jan 18 02:24:29 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 18 Jan 2023 02:24:29 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v12] In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 13:23:51 GMT, Afshin Zafari wrote: >> test of tier1-5 passed. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8292741: Convert JvmtiTagMapTable to ResourceHashtable Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11288 From dholmes at openjdk.org Wed Jan 18 02:56:27 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 18 Jan 2023 02:56:27 GMT Subject: RFR: 8300184: Optimize ResourceHashtableBase::iterate_all using _number_of_entries [v2] In-Reply-To: References: Message-ID: <6Iihmw1225-bQxOeP2t479SoklZGC0dmGZsy7oxLYoM=.ff18bcaf-3553-4c53-99c1-eda8edb2ff98@github.com> On Tue, 17 Jan 2023 07:18:19 GMT, Xin Liu wrote: > That's why I claim to optimize iterate_all rather than iterate. A call to `iterate` can result in iterating all elements if the lambda does not find an element to trigger iteration to cease; in which case this optimisation also applies. ------------- PR: https://git.openjdk.org/jdk/pull/12016 From bpb at openjdk.org Wed Jan 18 03:15:53 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 18 Jan 2023 03:15:53 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v13] In-Reply-To: References: Message-ID: > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299684: Split native methods; use Unsafe ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11873/files - new: https://git.openjdk.org/jdk/pull/11873/files/7d526352..abc6b586 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=11-12 Stats: 37 lines in 2 files changed: 9 ins; 15 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Wed Jan 18 03:17:53 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 18 Jan 2023 03:17:53 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v14] In-Reply-To: References: Message-ID: <1b3G5rQeMqfO1YyuB1oOylhjz6s0Un-pwDaXrZYZAt8=.e22dc3f0-621e-43fc-b3b8-651bfdcb6a2b@github.com> > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299684: Clean up memory deallocation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11873/files - new: https://git.openjdk.org/jdk/pull/11873/files/abc6b586..3b64bd20 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=12-13 Stats: 5 lines in 1 file changed: 2 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From mdoerr at openjdk.org Wed Jan 18 05:10:26 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 18 Jan 2023 05:10:26 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v4] In-Reply-To: References: <3mWF3cL69YLzYwYI7z0nQB66c_JxuTUMPfTHVn_YjiQ=.00a62b19-8dd8-42ba-9d71-078cf21f2657@github.com> Message-ID: <968FbsOPB5eLgb9XhRv7RrOvFqWz6XW55YAbEtl-c-s=.2a5ff2a1-2e9f-4775-b4b7-8d06aec19f19@github.com> On Tue, 17 Jan 2023 17:02:04 GMT, Fredrik Bredberg wrote: >> src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp line 1035: >> >>> 1033: __ sub(R12_scratch2, R18_locals, R1_SP); >>> 1034: __ srdi(R12_scratch2, R12_scratch2, Interpreter::logStackElementSize); >>> 1035: // Now &fp()[R12_scratch2] == R18_locals >> >> I think this comment makes no sense. Please remove it. Otherwise, PPC64 code LGTM. > > My intention was to show how the contents of R18_locals (the absolute address to locals) can be recreated by using R12_scratch2 as an index from the frame pointer. Before we stored R18_locals in the stackframe, now we store R12_scratch2. Does that make more sense? The code uses &sp()[R12_scratch2]. I think your comment is confusing. Please remove it or write something comprehensive. E.g. save R18_locals in compressed format relative to the frame's SP. ------------- PR: https://git.openjdk.org/jdk/pull/11902 From dean.long at oracle.com Wed Jan 18 05:33:29 2023 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 17 Jan 2023 21:33:29 -0800 Subject: CFV: New Hotspot Group Member: Richard Reingruber In-Reply-To: References: Message-ID: <83370434-7c27-39a8-b2f6-a5261ff1d0d4@oracle.com> Vote: yes From jwaters at openjdk.org Wed Jan 18 05:59:19 2023 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 18 Jan 2023 05:59:19 GMT Subject: RFR: JDK-8300080: offset_of for GCC/Clang exhibits undefined behavior and is not always a compile-time constant [v4] In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 16:06:44 GMT, Justin King wrote: >> The implementation of `offset_of` for GCC/Clang only deals with types are aligned to 16 bytes or less, if they are more, such as `zCollectedHeap` the behavior is undefined. UBSan also suggests that `offset_of` is not always a compile time constant, as the stack trace came from the dynamic loader during library loading. This patch changes `offset_of` to use `offsetof` and disables the warning `invalid-offsetof` for the JVM. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Move attribute on lambda to correct location > > Signed-off-by: Justin King Ah, right, I completely forgot about that. I wonder why we still need the `inline` keyword though? I know for early versions of gcc you needed the `inline` declaration for always_inline to have any effect, but somewhere down the line gcc's maintainers (rightfully) decided that requiring the keyword and the attribute together was a little ridiculous, so today gcc will forcefully inline such declarations as we want it to, even with only the always_inline attribute requested without the corresponding `inline` keyword specified ------------- PR: https://git.openjdk.org/jdk/pull/11978 From luhenry at openjdk.org Wed Jan 18 08:37:46 2023 From: luhenry at openjdk.org (Ludovic Henry) Date: Wed, 18 Jan 2023 08:37:46 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v22] In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 21:06:01 GMT, Claes Redestad wrote: >> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. >> >> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. >> >> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. >> >> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. >> >> With the most recent fixes the x64 intrinsic results on my workstation look like this: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op >> >> I.e. no measurable overhead compared to baseline even for `size == 1`. >> >> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. >> >> Benchmark for `Arrays.hashCode`: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op >> ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op >> ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op >> ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op >> ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op >> ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op >> ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op >> ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op >> ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op >> ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op >> ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op >> ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op >> ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op >> ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op >> ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op >> ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op >> ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op >> ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op >> ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op >> ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op >> ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op >> ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op >> ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op >> ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op >> ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op >> >> >> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. > > Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 76 commits: > > - Copyrights > - Merge branch 'master' into 8282664-polyhash > - Remove spurious newline > - trailing ws > - Change signature to offset + length, add sanity test > - Adapt end input to len (fix latent bug with sub-ranges > - Clean-up types, simplify, hoist special-casing of String variants from arrays_hashcode, add initial value and range to intrinsic > - Explicitly lea external address > - Merge branch 'master' into 8282664-polyhash > - Treat Op_VectorizedHashCode as other similar Ops in split_unique_types > - ... and 66 more: https://git.openjdk.org/jdk/compare/ade08e19...7e6080b6 Thanks for pushing it all the way! ------------- PR: https://git.openjdk.org/jdk/pull/10847 From eosterlund at openjdk.org Wed Jan 18 09:06:22 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 18 Jan 2023 09:06:22 GMT Subject: RFR: 8300253: Introduce AArch64 nzcv accessors In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 18:50:18 GMT, Erik ?sterlund wrote: >> Could @fisk provide an example of where this might be used? >> My assumption is that you are looking to execute code verification within, say, a GC memory barrier, and the code has been inserted in between where the condition codes might have been set and then used. This could avoid breaking the existing code when the verification code itself sets the condition codes. >> It's not all of the pstate, but then this is just userspace, so it ought to be ok? > >> Could @fisk provide an example of where this might be used? >> >> My assumption is that you are looking to execute code verification within, say, a GC memory barrier, and the code has been inserted in between where the condition codes might have been set and then used. This could avoid breaking the existing code when the verification code itself sets the condition codes. >> >> It's not all of the pstate, but then this is just userspace, so it ought to be ok? >> >> > > Your guess is spot on. We have a bunch of GC barrier nodes in C1, and C1 sprinkles oop verification all over the place - including when spilling oops between lir ops - sometimes between producing a condition code and consuming it. So I figured the verification code shouldn't really alter the state of execution such that it does something different. And I don't really want to reduce the amount of verification, because it was very useful in tracking down bugs. The specific use case we have is here: https://github.com/openjdk/zgc/blob/c23bd9e059df2759adaa5d316ec7d269ef5154a6/src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.cpp#L119 ------------- PR: https://git.openjdk.org/jdk/pull/12038 From alanb at openjdk.org Wed Jan 18 09:15:34 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 18 Jan 2023 09:15:34 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v14] In-Reply-To: <1b3G5rQeMqfO1YyuB1oOylhjz6s0Un-pwDaXrZYZAt8=.e22dc3f0-621e-43fc-b3b8-651bfdcb6a2b@github.com> References: <1b3G5rQeMqfO1YyuB1oOylhjz6s0Un-pwDaXrZYZAt8=.e22dc3f0-621e-43fc-b3b8-651bfdcb6a2b@github.com> Message-ID: On Wed, 18 Jan 2023 03:17:53 GMT, Brian Burkhalter wrote: >> Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299684: Clean up memory deallocation test/jdk/java/nio/jni/NewDirectByteBuffer.java line 106: > 104: (long)Integer.MAX_VALUE - 1, (long)Integer.MAX_VALUE}) > 105: void legalCapacities(long capacity) { > 106: long addr = UNSAFE.allocateMemory(capacity); I think David was asking for the test to continue when malloc fails. Now that the test is changed to use Unsafe.allocateMemory it means it has to catch OOME. test/jdk/java/nio/jni/libNewDirectByteBuffer.c line 49: > 47: (JNIEnv *env, jclass cls, jobject buf) > 48: { > 49: return (jlong)(*env)->GetDirectBufferAddress(env, buf); The cast to jlong should be okay for 64-bit. For 32-bit then it will likely need a double cast, as in ((jlong)(int)( .. )) but maybe okay for now as you've restricted the test to 64-bit. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From redestad at openjdk.org Wed Jan 18 09:16:47 2023 From: redestad at openjdk.org (Claes Redestad) Date: Wed, 18 Jan 2023 09:16:47 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v22] In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 21:06:01 GMT, Claes Redestad wrote: >> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. >> >> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. >> >> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. >> >> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. >> >> With the most recent fixes the x64 intrinsic results on my workstation look like this: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op >> >> I.e. no measurable overhead compared to baseline even for `size == 1`. >> >> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. >> >> Benchmark for `Arrays.hashCode`: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op >> ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op >> ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op >> ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op >> ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op >> ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op >> ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op >> ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op >> ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op >> ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op >> ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op >> ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op >> ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op >> ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op >> ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op >> ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op >> ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op >> ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op >> ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op >> ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op >> ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op >> ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op >> ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op >> ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op >> ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op >> >> >> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. > > Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 76 commits: > > - Copyrights > - Merge branch 'master' into 8282664-polyhash > - Remove spurious newline > - trailing ws > - Change signature to offset + length, add sanity test > - Adapt end input to len (fix latent bug with sub-ranges > - Clean-up types, simplify, hoist special-casing of String variants from arrays_hashcode, add initial value and range to intrinsic > - Explicitly lea external address > - Merge branch 'master' into 8282664-polyhash > - Treat Op_VectorizedHashCode as other similar Ops in split_unique_types > - ... and 66 more: https://git.openjdk.org/jdk/compare/ade08e19...7e6080b6 Filed https://bugs.openjdk.org/browse/JDK-8300448 to follow-up and rewrite part of or all of the inlined code as a stub call. ------------- PR: https://git.openjdk.org/jdk/pull/10847 From stefank at openjdk.org Wed Jan 18 09:24:14 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 18 Jan 2023 09:24:14 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v2] In-Reply-To: References: Message-ID: > The JfrVFrameStream is used while generating stack traces for events. One of the events are the ZPage allocation event. This event is sometimes sent when ZGC is relocating. The current implementation of JfrVFrameStream uses WalkContinuation::include, which causes JFR to walk the continuation and perform GC barriers. This is problematic, since ZGC has a requirement that we never perform load barriers while running the relocation code. If we do, we might end up performing other reloctions from the the relocation code, and in some cases that causes dead locks. > > I propose that JFR doesn't walk the continuations when sending events. An alternative could be to limit this to ZGC, but I'd like to get some feedback around that from JFR / Loom devs. > > We've been testing this patch in the Generational ZGC repository. Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into 8298377_zgc_jfr_loom_deadlock - Start stack watermark processing from JFR async profiler - Only skip if stack watermark processing has not started - Merge remote-tracking branch 'upstream/master' into 8298377_zgc_jfr_loom_deadlock - 8298377: JfrVframeStream causes deadlocks in ZGC ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11586/files - new: https://git.openjdk.org/jdk/pull/11586/files/b6566b2d..9fe191e2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11586&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11586&range=00-01 Stats: 38617 lines in 2044 files changed: 22568 ins; 8579 del; 7470 mod Patch: https://git.openjdk.org/jdk/pull/11586.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11586/head:pull/11586 PR: https://git.openjdk.org/jdk/pull/11586 From aboldtch at openjdk.org Wed Jan 18 09:24:37 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 18 Jan 2023 09:24:37 GMT Subject: Integrated: 8299089: Instrument global jni handles with tag to make them distinguishable In-Reply-To: References: Message-ID: On Tue, 20 Dec 2022 11:44:33 GMT, Axel Boldt-Christmas wrote: > Weak global jni handles are tagged so the GC can distinguish them when resolving the object. Today there is no cheap way of distinguishing global jni handles from local jni handles. For generational ZGC the OopStorage handles and the thread local handles semantical difference requires the handles to be distinguishable. > > This enhancements instruments the jni handles with a global tag similarly to the jweak tag. > > Note: > * the s390 implementation has minimal changes and requires improvement. > * There is room for enchantment here to create the same abstraction that ppc uses for all platforms, i.e. move the resolve_jobject from the MacroAssembler to the BarrierSetAssembler which allows for more optimised code for GCs that can treat local and global handles the same. > > Testing: GHA. Oracle supported platforms tier1-3. Will run higher tiers. Has also been tested on the generational branch of ZGC for over three months. Requires testing on non Oracle platforms. This pull request has now been integrated. Changeset: c7056737 Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/c7056737e33d3d5a6ec24639d46b9e3e7a8da01a Stats: 528 lines in 36 files changed: 306 ins; 63 del; 159 mod 8299089: Instrument global jni handles with tag to make them distinguishable Co-authored-by: Stefan Karlsson Co-authored-by: Martin Doerr Co-authored-by: Leslie Zhai Reviewed-by: eosterlund, stefank, ayang ------------- PR: https://git.openjdk.org/jdk/pull/11740 From eosterlund at openjdk.org Wed Jan 18 09:39:26 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 18 Jan 2023 09:39:26 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 09:24:14 GMT, Stefan Karlsson wrote: >> The JfrVFrameStream is used while generating stack traces for events. One of the events are the ZPage allocation event. This event is sometimes sent when ZGC is relocating. The current implementation of JfrVFrameStream uses WalkContinuation::include, which causes JFR to walk the continuation and perform GC barriers. This is problematic, since ZGC has a requirement that we never perform load barriers while running the relocation code. If we do, we might end up performing other reloctions from the the relocation code, and in some cases that causes dead locks. >> >> I propose that JFR doesn't walk the continuations when sending events. An alternative could be to limit this to ZGC, but I'd like to get some feedback around that from JFR / Loom devs. >> >> We've been testing this patch in the Generational ZGC repository. > > Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into 8298377_zgc_jfr_loom_deadlock > - Start stack watermark processing from JFR async profiler > - Only skip if stack watermark processing has not started > - Merge remote-tracking branch 'upstream/master' into 8298377_zgc_jfr_loom_deadlock > - 8298377: JfrVframeStream causes deadlocks in ZGC Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.org/jdk/pull/11586 From duke at openjdk.org Wed Jan 18 09:48:29 2023 From: duke at openjdk.org (Fredrik Bredberg) Date: Wed, 18 Jan 2023 09:48:29 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v4] In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 17:34:53 GMT, Andrew Haley wrote: > > Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. > > Please explain for the record the purpose of this patch. Neither the PR nor the Jira issue explain. I presume it's something to do with making the mounting and unmounting of interpreter frames easier, but this must be said somewhere. This PR implements JDK-8299795 which is a subtask to JDK-8289296, which briefly explains the reasons for the RFE. Anyhow I've added more information in JDK-8299795 regarding this PR. ------------- PR: https://git.openjdk.org/jdk/pull/11902 From aph at openjdk.org Wed Jan 18 10:00:23 2023 From: aph at openjdk.org (Andrew Haley) Date: Wed, 18 Jan 2023 10:00:23 GMT Subject: RFR: 8300253: Introduce AArch64 nzcv accessors In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 09:03:58 GMT, Erik ?sterlund wrote: >>> Could @fisk provide an example of where this might be used? >>> >>> My assumption is that you are looking to execute code verification within, say, a GC memory barrier, and the code has been inserted in between where the condition codes might have been set and then used. This could avoid breaking the existing code when the verification code itself sets the condition codes. >>> >>> It's not all of the pstate, but then this is just userspace, so it ought to be ok? >>> >>> >> >> Your guess is spot on. We have a bunch of GC barrier nodes in C1, and C1 sprinkles oop verification all over the place - including when spilling oops between lir ops - sometimes between producing a condition code and consuming it. So I figured the verification code shouldn't really alter the state of execution such that it does something different. And I don't really want to reduce the amount of verification, because it was very useful in tracking down bugs. > > The specific use case we have is here: https://github.com/openjdk/zgc/blob/c23bd9e059df2759adaa5d316ec7d269ef5154a6/src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.cpp#L119 OK, I'm not wild about checking in dead code, but if it's imminently needed, OK. Please add the instructions to `test/hotspot/gtest/aarch64/aarch64-asmtest.py` so they get tested.. ------------- PR: https://git.openjdk.org/jdk/pull/12038 From aph at openjdk.org Wed Jan 18 10:16:33 2023 From: aph at openjdk.org (Andrew Haley) Date: Wed, 18 Jan 2023 10:16:33 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v4] In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 08:35:45 GMT, Fredrik Bredberg wrote: >> Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. >> Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. >> Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. > > Fredrik Bredberg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' into relativize-locals-JDK-8299795_2023-01-09 > - Added references to JDK-8300197 > - Updated some copyright dates. > - Changed copyright date to 2023 > - 8299795: Relativize locals in interpreter frames src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 236: > 234: caller.set_sp(fp + frame::sender_sp_offset); > 235: frame f(frame_sp, frame_sp, fp, hf.pc()); > 236: // we need to set the locals now so that the caller of new_stack_frame() can call Suggestion: // we need to set the locals so that the caller of new_stack_frame() can call ------------- PR: https://git.openjdk.org/jdk/pull/11902 From smonteith at openjdk.org Wed Jan 18 10:35:23 2023 From: smonteith at openjdk.org (Stuart Monteith) Date: Wed, 18 Jan 2023 10:35:23 GMT Subject: RFR: 8300253: Introduce AArch64 nzcv accessors In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 09:57:20 GMT, Andrew Haley wrote: >> The specific use case we have is here: https://github.com/openjdk/zgc/blob/c23bd9e059df2759adaa5d316ec7d269ef5154a6/src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.cpp#L119 > > OK, I'm not wild about checking in dead code, but if it's imminently needed, OK. Please add the instructions to `test/hotspot/gtest/aarch64/aarch64-asmtest.py` so they get tested.. The bits for the instructions are correct. I presume there'll be a train of patches for ZGC generational to necessitate it. ------------- PR: https://git.openjdk.org/jdk/pull/12038 From jiefu at openjdk.org Wed Jan 18 10:35:30 2023 From: jiefu at openjdk.org (Jie Fu) Date: Wed, 18 Jan 2023 10:35:30 GMT Subject: Integrated: 8300169: Build failure with clang-15 In-Reply-To: References: Message-ID: On Sat, 14 Jan 2023 14:28:32 GMT, Jie Fu wrote: > Hi all, > > Please review the fix for the build failure with clang-15. > > 1. -Wbitwise-instead-of-logical > > 1) src/hotspot/share/oops/generateOopMap.cpp <--- fixed the warning > 2) src/hotspot/share/runtime/notificationThread.cpp <--- keep the code and disable warnings > 3) src/hotspot/share/runtime/serviceThread.cpp <--- keep the code and disable warnings > > > 2. -Wdeprecated-non-prototype (all the warnings are disabled) > > 1) Mainly caused by files under `src/java.base/share/native/libzip/zlib/` <--- keep the code and disable warnings > It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN. > > 2) While compiling src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c <--- keep the code and disable warnings > > 3) Caused by src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m <--- fixed the warnings > > > 3. -Wdeprecated-builtins > > Caused by files under src/java.desktop/share/native/libharfbuzz/ <--- fixed the warnings > > Ref: https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202 > > 4. -Wgnu-folding-constant > > Caused by src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m <--- keep the code and disable warnings > > > Thanks. > Best regards, > Jie This pull request has now been integrated. Changeset: 15a9186d Author: Jie Fu URL: https://git.openjdk.org/jdk/commit/15a9186db251f4be7a13e173842ac1bd858f984d Stats: 15 lines in 6 files changed: 5 ins; 0 del; 10 mod 8300169: Build failure with clang-15 Reviewed-by: dholmes, prr ------------- PR: https://git.openjdk.org/jdk/pull/12005 From eosterlund at openjdk.org Wed Jan 18 10:58:35 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 18 Jan 2023 10:58:35 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v4] In-Reply-To: References: <1rK2mzryGeyI-Yak0rUIqYZBuK5zrxCYwPe9zJbjHpY=.5471f1af-f8b8-4219-ae93-8b5a5fecaad9@github.com> Message-ID: On Thu, 5 Jan 2023 13:04:45 GMT, Erik ?sterlund wrote: >> The JfrVFrameStream is used while generating stack traces for events. One of the events are the ZPage allocation event. This event is sometimes sent when ZGC is relocating. The current implementation of JfrVFrameStream uses WalkContinuation::include, which causes JFR to walk the continuation and perform GC barriers. This is problematic, since ZGC has a requirement that we never perform load barriers while running the relocation code. If we do, we might end up performing other reloctions from the the relocation code, and in some cases that causes dead locks. >> >> I propose that JFR doesn't walk the stack during stack watermark processing. This PR implements that change. This PR replaces https://github.com/openjdk/jdk/pull/11586 > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > More renaming Closing in favour of @stefank PR. ------------- PR: https://git.openjdk.org/jdk/pull/11778 From eosterlund at openjdk.org Wed Jan 18 10:58:38 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 18 Jan 2023 10:58:38 GMT Subject: Withdrawn: 8298377: JfrVframeStream causes deadlocks in ZGC In-Reply-To: <1rK2mzryGeyI-Yak0rUIqYZBuK5zrxCYwPe9zJbjHpY=.5471f1af-f8b8-4219-ae93-8b5a5fecaad9@github.com> References: <1rK2mzryGeyI-Yak0rUIqYZBuK5zrxCYwPe9zJbjHpY=.5471f1af-f8b8-4219-ae93-8b5a5fecaad9@github.com> Message-ID: On Fri, 23 Dec 2022 14:06:07 GMT, Erik ?sterlund wrote: > The JfrVFrameStream is used while generating stack traces for events. One of the events are the ZPage allocation event. This event is sometimes sent when ZGC is relocating. The current implementation of JfrVFrameStream uses WalkContinuation::include, which causes JFR to walk the continuation and perform GC barriers. This is problematic, since ZGC has a requirement that we never perform load barriers while running the relocation code. If we do, we might end up performing other reloctions from the the relocation code, and in some cases that causes dead locks. > > I propose that JFR doesn't walk the stack during stack watermark processing. This PR implements that change. This PR replaces https://github.com/openjdk/jdk/pull/11586 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/11778 From fjiang at openjdk.org Wed Jan 18 11:11:30 2023 From: fjiang at openjdk.org (Feilong Jiang) Date: Wed, 18 Jan 2023 11:11:30 GMT Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory API (Preview) [v8] In-Reply-To: References: Message-ID: > Add experimental Foreign Function & Memory API support for RISC-V. > > For details of the FFM API RISC-V port please refer to [JBS issue](https://bugs.openjdk.org/browse/JDK-8293841) > > Testing: > > - [x] jdk_foreign with release/fastdebug build on linux-riscv64 > - [x] jdk_foreign with release/fastdebug build on linux-x64 > - [x] jdk_foreign with release/fastdebug build on linux-aarch64 Feilong Jiang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8293841-foreign-api-riscv - more code style adjustment - fix comment & code adjustment - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8293841-foreign-api-riscv - fix callArranger - fix callArranger - fix build - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8293841-foreign-api-riscv - code adjustment and remove unnecessary static - sync with JDK-8296477 - ... and 2 more: https://git.openjdk.org/jdk/compare/e680b137...feac5fa8 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11004/files - new: https://git.openjdk.org/jdk/pull/11004/files/c4809317..feac5fa8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11004&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11004&range=06-07 Stats: 5459 lines in 620 files changed: 2808 ins; 769 del; 1882 mod Patch: https://git.openjdk.org/jdk/pull/11004.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11004/head:pull/11004 PR: https://git.openjdk.org/jdk/pull/11004 From mgronlun at openjdk.org Wed Jan 18 11:21:21 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 18 Jan 2023 11:21:21 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 09:24:14 GMT, Stefan Karlsson wrote: >> The JfrVFrameStream is used while generating stack traces for events. One of the events are the ZPage allocation event. This event is sometimes sent when ZGC is relocating. The current implementation of JfrVFrameStream uses WalkContinuation::include, which causes JFR to walk the continuation and perform GC barriers. This is problematic, since ZGC has a requirement that we never perform load barriers while running the relocation code. If we do, we might end up performing other reloctions from the the relocation code, and in some cases that causes dead locks. >> >> I propose that JFR doesn't walk the continuations when sending events. An alternative could be to limit this to ZGC, but I'd like to get some feedback around that from JFR / Loom devs. >> >> We've been testing this patch in the Generational ZGC repository. > > Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into 8298377_zgc_jfr_loom_deadlock > - Start stack watermark processing from JFR async profiler > - Only skip if stack watermark processing has not started > - Merge remote-tracking branch 'upstream/master' into 8298377_zgc_jfr_loom_deadlock > - 8298377: JfrVframeStream causes deadlocks in ZGC Question: does the "start_processing()" call ever reach a malloc, directly or indirectly? If so, it is problematic to call from the sampler thread. ------------- PR: https://git.openjdk.org/jdk/pull/11586 From duke at openjdk.org Wed Jan 18 12:20:56 2023 From: duke at openjdk.org (Johannes Bechberger) Date: Wed, 18 Jan 2023 12:20:56 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 09:24:14 GMT, Stefan Karlsson wrote: >> The JfrVFrameStream is used while generating stack traces for events. One of the events are the ZPage allocation event. This event is sometimes sent when ZGC is relocating. The current implementation of JfrVFrameStream uses WalkContinuation::include, which causes JFR to walk the continuation and perform GC barriers. This is problematic, since ZGC has a requirement that we never perform load barriers while running the relocation code. If we do, we might end up performing other reloctions from the the relocation code, and in some cases that causes dead locks. >> >> I propose that JFR doesn't walk the continuations when sending events. An alternative could be to limit this to ZGC, but I'd like to get some feedback around that from JFR / Loom devs. >> >> We've been testing this patch in the Generational ZGC repository. > > Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into 8298377_zgc_jfr_loom_deadlock > - Start stack watermark processing from JFR async profiler > - Only skip if stack watermark processing has not started > - Merge remote-tracking branch 'upstream/master' into 8298377_zgc_jfr_loom_deadlock > - 8298377: JfrVframeStream causes deadlocks in ZGC As a side note: AsyncGetCallTrace does not have the described problem, as it always skips. ------------- PR: https://git.openjdk.org/jdk/pull/11586 From mgronlun at openjdk.org Wed Jan 18 12:47:14 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 18 Jan 2023 12:47:14 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 12:40:25 GMT, Erik ?sterlund wrote: > > Question: does the "start_processing()" call ever reach a malloc, directly or indirectly? If so, it is problematic to call from the sampler thread. > > It does allocate a stack iterator with malloc if it really did need to start processing and it was not yet started. So yes. Would you mind explaining why using malloc is problematic? The problem is that the suspendee can be holding the malloc lock. Please see https://bugs.openjdk.org/browse/JDK-8274298 for an example situation. ------------- PR: https://git.openjdk.org/jdk/pull/11586 From eosterlund at openjdk.org Wed Jan 18 12:43:32 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 18 Jan 2023 12:43:32 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 11:18:19 GMT, Markus Gr?nlund wrote: > Question: does the "start_processing()" call ever reach a malloc, directly or indirectly? If so, it is problematic to call from the sampler thread. It does allocate a stack iterator with malloc if it really did need to start processing and it was not yet started. So yes. Would you mind explaining why using malloc is problematic? ------------- PR: https://git.openjdk.org/jdk/pull/11586 From mgronlun at openjdk.org Wed Jan 18 12:43:38 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 18 Jan 2023 12:43:38 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 09:24:14 GMT, Stefan Karlsson wrote: >> The JfrVFrameStream is used while generating stack traces for events. One of the events are the ZPage allocation event. This event is sometimes sent when ZGC is relocating. The current implementation of JfrVFrameStream uses WalkContinuation::include, which causes JFR to walk the continuation and perform GC barriers. This is problematic, since ZGC has a requirement that we never perform load barriers while running the relocation code. If we do, we might end up performing other reloctions from the the relocation code, and in some cases that causes dead locks. >> >> I propose that JFR doesn't walk the continuations when sending events. An alternative could be to limit this to ZGC, but I'd like to get some feedback around that from JFR / Loom devs. >> >> We've been testing this patch in the Generational ZGC repository. > > Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into 8298377_zgc_jfr_loom_deadlock > - Start stack watermark processing from JFR async profiler > - Only skip if stack watermark processing has not started > - Merge remote-tracking branch 'upstream/master' into 8298377_zgc_jfr_loom_deadlock > - 8298377: JfrVframeStream causes deadlocks in ZGC src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp line 393: > 391: // stack walk over Loom continuations. The stack walking code will otherwise > 392: // skip frames in stack chunks on the Java heap. > 393: StackWatermarkSet::start_processing(thread, StackWatermarkKind::gc); does the "start_processing()" call ever reach a malloc, directly or indirectly? If so, it is problematic to call from the sampler thread. ------------- PR: https://git.openjdk.org/jdk/pull/11586 From eosterlund at openjdk.org Wed Jan 18 12:50:10 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 18 Jan 2023 12:50:10 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 12:44:29 GMT, Markus Gr?nlund wrote: > > > Question: does the "start_processing()" call ever reach a malloc, directly or indirectly? If so, it is problematic to call from the sampler thread. > > > > > > It does allocate a stack iterator with malloc if it really did need to start processing and it was not yet started. So yes. Would you mind explaining why using malloc is problematic? > > The problem is that the suspendee can be holding the malloc lock. Please see https://bugs.openjdk.org/browse/JDK-8274298 for an example situation. Right - that makes sense. But I thought the processing is poked here before we suspend the target thread? Or did I read the code wrong? ------------- PR: https://git.openjdk.org/jdk/pull/11586 From mgronlun at openjdk.org Wed Jan 18 13:03:22 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 18 Jan 2023 13:03:22 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 12:47:48 GMT, Erik ?sterlund wrote: > > > > Question: does the "start_processing()" call ever reach a malloc, directly or indirectly? If so, it is problematic to call from the sampler thread. > > > > > > > > > It does allocate a stack iterator with malloc if it really did need to start processing and it was not yet started. So yes. Would you mind explaining why using malloc is problematic? > > > > > > The problem is that the suspendee can be holding the malloc lock. Please see https://bugs.openjdk.org/browse/JDK-8274298 for an example situation. > > Right - that makes sense. But I thought the processing is poked here before we suspend the target thread? Or did I read the code wrong? Ah. The call is now located before the suspend is attempted. That is good from a sampling perspective. Is it mt safe to call start_processing() on another running thread? ------------- PR: https://git.openjdk.org/jdk/pull/11586 From duke at openjdk.org Wed Jan 18 13:25:04 2023 From: duke at openjdk.org (Afshin Zafari) Date: Wed, 18 Jan 2023 13:25:04 GMT Subject: Integrated: 8292741: Convert JvmtiTagMapTable to ResourceHashtable In-Reply-To: References: Message-ID: On Tue, 22 Nov 2022 14:48:11 GMT, Afshin Zafari wrote: > test of tier1-5 passed. This pull request has now been integrated. Changeset: c464ef1d Author: Afshin Zafari Committer: Robbin Ehn URL: https://git.openjdk.org/jdk/commit/c464ef1d61c2ea4a37759546f0ee39b1f530ccdc Stats: 291 lines in 4 files changed: 46 ins; 124 del; 121 mod 8292741: Convert JvmtiTagMapTable to ResourceHashtable Reviewed-by: dholmes, coleenp, rehn ------------- PR: https://git.openjdk.org/jdk/pull/11288 From rehn at openjdk.org Wed Jan 18 13:27:55 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 18 Jan 2023 13:27:55 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 20:17:37 GMT, Roman Kennke wrote: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Renaissance > > > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Hi Roman, I get this error on aarch64 in random tests: # Internal Error (.../open/src/hotspot/share/runtime/lockStack.cpp:50), pid=422380, tid=422437 # assert(*loc1 != *loc2) failed: entries must be unique: pre-contains V [libjvm.so+0x12a9f48] LockStack::validate(char const*) const+0x118 (lockStack.cpp:50) V [libjvm.so+0x17c5e60] is_lock_owned(Thread*, oop)+0x70 (lockStack.inline.hpp:72) V [libjvm.so+0x17cac8c] ObjectSynchronizer::inflate(Thread*, oop, ObjectSynchronizer::InflateCause)+0x6cc (synchronizer.cpp:1323) V [libjvm.so+0x17d0648] ObjectSynchronizer::enter(Handle, BasicLock*, JavaThread*)+0x108 (synchronizer.cpp:544) V [libjvm.so+0x16a23b8] SharedRuntime::monitor_enter_helper(oopDesc*, BasicLock*, JavaThread*)+0x1e8 (sharedRuntime.cpp:2294) V [libjvm.so+0x16a2724] SharedRuntime::complete_monitor_locking_C(oopDesc*, BasicLock*, JavaThread*)+0xb4 (sharedRuntime.cpp:2301) Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) v ~RuntimeStub::_complete_monitor_locking_Java 0x0000fffd30576414 J 9196 c2 java.util.jar.JarFile.getManEntry()Ljava/util/jar/JarEntry; java.base at 21-internal (39 bytes) @ 0x0000fffd3154715c [0x0000fffd31546a80+0x00000000000006dc] ------------- PR: https://git.openjdk.org/jdk/pull/10907 From mbaesken at openjdk.org Wed Jan 18 14:06:03 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 18 Jan 2023 14:06:03 GMT Subject: RFR: JDK-8300266: Detect Virtualization on Linux aarch64 Message-ID: Currently we detect virtualization on Linux x86_64 (cpuid call) and Linux ppc64le ; the result is afterwards used e.g. in hs_err and JFR output. On Linux aarch64 the detection is missing, this should be added. One option would be to look at /sys/devices/virtual/dmi/id/product_name and related files , at least KVM and VMWare can be detected using these files. ------------- Commit messages: - JDK-8300266 Changes: https://git.openjdk.org/jdk/pull/12071/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12071&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300266 Stats: 39 lines in 2 files changed: 39 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12071.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12071/head:pull/12071 PR: https://git.openjdk.org/jdk/pull/12071 From rkennke at openjdk.org Wed Jan 18 14:13:47 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 18 Jan 2023 14:13:47 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 13:25:22 GMT, Robbin Ehn wrote: > Hi Roman, I get this error on aarch64 in random tests: > ... Ok, that is ... surprising! I'll re-run tests on aarch64. Meanwhile, can you let me know what exactly you have run to get these failures? Thank you! Roman ------------- PR: https://git.openjdk.org/jdk/pull/10907 From eosterlund at openjdk.org Wed Jan 18 14:26:30 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 18 Jan 2023 14:26:30 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v2] In-Reply-To: References: Message-ID: <8_foA-JRBTq6PIOjznkKwGTUSiwFC2W-omyq5MsGSug=.3e273bb1-5625-4824-bc9b-1d6681f5d581@github.com> On Wed, 18 Jan 2023 13:00:46 GMT, Markus Gr?nlund wrote: > > > > > Question: does the "start_processing()" call ever reach a malloc, directly or indirectly? If so, it is problematic to call from the sampler thread. > > > > > > > > > > > > It does allocate a stack iterator with malloc if it really did need to start processing and it was not yet started. So yes. Would you mind explaining why using malloc is problematic? > > > > > > > > > The problem is that the suspendee can be holding the malloc lock. Please see https://bugs.openjdk.org/browse/JDK-8274298 for an example situation. > > > > > > Right - that makes sense. But I thought the processing is poked here before we suspend the target thread? Or did I read the code wrong? > > Ah. The call is now located before the suspend is attempted. That is good from a sampling perspective. Is it mt safe to call start_processing() on another running thread? Yes, it is perfectly thread safe, because it has a per-thread lock that ensures mutual exclusion. Other than that, the fact that we also hold the Threads_lock here means that we can guarantee it remains processed until the signal hits the target thread. ------------- PR: https://git.openjdk.org/jdk/pull/11586 From coleen.phillimore at oracle.com Wed Jan 18 14:33:35 2023 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 18 Jan 2023 09:33:35 -0500 Subject: Result: New hotspot Group Member: Ron Pressler Message-ID: <768b0d73-a67e-684b-875f-be4148c6208b@oracle.com> The vote for Ron Pressler [1] is now closed. Yes: 15 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Coleen Phillimore [1] https://mail.openjdk.org/pipermail/hotspot-dev/2023-January/068341.html From coleen.phillimore at oracle.com Wed Jan 18 14:34:19 2023 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 18 Jan 2023 09:34:19 -0500 Subject: Result: New hotspot Group Member: Robbin Ehn Message-ID: The vote for Robbin Ehn [1] is now closed. Yes: 16 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Coleen Phillimore [1] https://mail.openjdk.org/pipermail/hotspot-dev/2023-January/068344.html From coleen.phillimore at oracle.com Wed Jan 18 14:34:57 2023 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 18 Jan 2023 09:34:57 -0500 Subject: Result: New hotspot Group Member: Patricio Chilano Mateo Message-ID: <6670211f-ee0d-87b2-7de3-724b98eaaf70@oracle.com> The vote for Patricio Chilano Mateo [1] is now closed. Yes: 17 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Coleen Phillimore [1] https://mail.openjdk.org/pipermail/hotspot-dev/2023-January/068345.html From coleen.phillimore at oracle.com Wed Jan 18 14:35:52 2023 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 18 Jan 2023 09:35:52 -0500 Subject: Result: New hotspot Group Member: Lois Foltan Message-ID: <09940c19-0e1d-4113-259a-90b968fb388c@oracle.com> The vote for Lois Foltan [1] is now closed. Yes: 18 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Coleen Phillimore [1] https://mail.openjdk.org/pipermail/hotspot-dev/2023-January/068348.html From coleen.phillimore at oracle.com Wed Jan 18 14:36:36 2023 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 18 Jan 2023 09:36:36 -0500 Subject: Result: New hotspot Group Member: Frederic Parain Message-ID: <86d77c83-e8be-3756-b7a5-78598d71a79f@oracle.com> The vote for Frederic Parain [1] is now closed. Yes: 17 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Coleen Phillimore [1] https://mail.openjdk.org/pipermail/hotspot-dev/2023-January/068349.html From mgronlun at openjdk.org Wed Jan 18 14:36:43 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 18 Jan 2023 14:36:43 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 09:24:14 GMT, Stefan Karlsson wrote: >> The JfrVFrameStream is used while generating stack traces for events. One of the events are the ZPage allocation event. This event is sometimes sent when ZGC is relocating. The current implementation of JfrVFrameStream uses WalkContinuation::include, which causes JFR to walk the continuation and perform GC barriers. This is problematic, since ZGC has a requirement that we never perform load barriers while running the relocation code. If we do, we might end up performing other reloctions from the the relocation code, and in some cases that causes dead locks. >> >> I propose that JFR doesn't walk the continuations when sending events. An alternative could be to limit this to ZGC, but I'd like to get some feedback around that from JFR / Loom devs. >> >> We've been testing this patch in the Generational ZGC repository. > > Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into 8298377_zgc_jfr_loom_deadlock > - Start stack watermark processing from JFR async profiler > - Only skip if stack watermark processing has not started > - Merge remote-tracking branch 'upstream/master' into 8298377_zgc_jfr_loom_deadlock > - 8298377: JfrVframeStream causes deadlocks in ZGC src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp line 393: > 391: // stack walk over Loom continuations. The stack walking code will otherwise > 392: // skip frames in stack chunks on the Java heap. > 393: StackWatermarkSet::start_processing(thread, StackWatermarkKind::gc); Maybe this should be moved to under each thread_state_in_java() and thread_state_in_native() preliminary check, see below. That way we only call on threads that we will eventually attempt to suspend. ------------- PR: https://git.openjdk.org/jdk/pull/11586 From coleen.phillimore at oracle.com Wed Jan 18 14:37:14 2023 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 18 Jan 2023 09:37:14 -0500 Subject: Result: New hotspot Group Member: Serguei Spitsyn Message-ID: <830ba8ab-69e3-5153-db6f-3238d7f14efc@oracle.com> The vote for Serguei Spitsyn [1] is now closed. Yes: 18 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Coleen Phillimore [1] https://mail.openjdk.org/pipermail/hotspot-dev/2023-January/068350.html From kbarrett at openjdk.org Wed Jan 18 14:48:32 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 18 Jan 2023 14:48:32 GMT Subject: RFR: JDK-8300264: Remove metaprogramming/isPointer.hpp In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 14:24:08 GMT, Justin King wrote: > Code cleanup of pre-C++11 implementations. Looks good. src/hotspot/share/utilities/concurrentHashTable.inline.hpp line 510: > 508: have_deletable(bucket, eval_f, prefetch_bucket)) { > 509: // Nothing to remove in this bucket. > 510: continue; [pre-existing] The if-body is mis-indented. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/12041 From rehn at openjdk.org Wed Jan 18 15:01:44 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 18 Jan 2023 15:01:44 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 20:17:37 GMT, Roman Kennke wrote: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Renaissance > > > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Here are some tests that seems provide some reproducability (mac/linux aarch64): runtime/handshake/HandshakeDirectTest.java vmTestbase/gc/gctests/ObjectMonitorCleanup/ObjectMonitorCleanup.java (crashes in AccessInternal::PostRuntimeDispatch, (AccessInternal::BarrierType)2, 594020ul>::oop_access_barrier(void*)+0x1c) vmTestbase/nsk/jdi/stress/serial/heapwalking00X (options don't seem to matter) ------------- PR: https://git.openjdk.org/jdk/pull/10907 From mgronlun at openjdk.org Wed Jan 18 15:07:14 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 18 Jan 2023 15:07:14 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 14:31:17 GMT, Markus Gr?nlund wrote: >> Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Merge remote-tracking branch 'upstream/master' into 8298377_zgc_jfr_loom_deadlock >> - Start stack watermark processing from JFR async profiler >> - Only skip if stack watermark processing has not started >> - Merge remote-tracking branch 'upstream/master' into 8298377_zgc_jfr_loom_deadlock >> - 8298377: JfrVframeStream causes deadlocks in ZGC > > src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp line 393: > >> 391: // stack walk over Loom continuations. The stack walking code will otherwise >> 392: // skip frames in stack chunks on the Java heap. >> 393: StackWatermarkSet::start_processing(thread, StackWatermarkKind::gc); > > Maybe this should be moved to under each thread_state_in_java() and thread_state_in_native() preliminary check, see below. That way we only call on threads that we will eventually attempt to suspend. Just put it in each of JfrThreadSampleClosure::sample_thread_in_java() and JfrThreadSampleClosure::sample_thread_in_native() member functions, ------------- PR: https://git.openjdk.org/jdk/pull/11586 From kbarrett at openjdk.org Wed Jan 18 15:11:22 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 18 Jan 2023 15:11:22 GMT Subject: RFR: JDK-8300265: Remove metaprogramming/isSigned.hpp In-Reply-To: <5FdmclkgEZHyCgDKZvz2MZd0OyCCE2_oOLxZj8K9Ojs=.51b51fae-08c0-4bd1-be6f-f4b55cd72efd@github.com> References: <5FdmclkgEZHyCgDKZvz2MZd0OyCCE2_oOLxZj8K9Ojs=.51b51fae-08c0-4bd1-be6f-f4b55cd72efd@github.com> Message-ID: On Tue, 17 Jan 2023 14:29:41 GMT, Justin King wrote: > Code cleanup of pre-C++11 implementations. Looks good. src/hotspot/share/memory/metaspace/counters.hpp line 47: > 45: > 46: // Only allow unsigned values for now > 47: STATIC_ASSERT(std::is_signed::value == false); [pre-existing] I was going to say that we use `! _bool-expr_` rather than `_bool-expr_ == false`, and I thought that was in the Style Guide. But it seems I was wrong about the Style Guide, and there are a surprising (to me) number of occurrences of this sort of thing in our code (> 200). src/hotspot/share/memory/metaspace/counters.hpp line 47: > 45: > 46: // Only allow unsigned values for now > 47: STATIC_ASSERT(std::is_signed::value == false); [pre-existing] Perhaps these should also be testing for `std::is_integral`, since that is not implied by `std::is_signed`. Although in the atomic case that will fall out implicitly since we don't support atomic arithmetic on floating point values. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/12042 From tschatzl at openjdk.org Wed Jan 18 15:28:40 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 18 Jan 2023 15:28:40 GMT Subject: RFR: JDK-8300264: Remove metaprogramming/isPointer.hpp In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 14:24:08 GMT, Justin King wrote: > Code cleanup of pre-C++11 implementations. Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12041 From tschatzl at openjdk.org Wed Jan 18 15:30:19 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 18 Jan 2023 15:30:19 GMT Subject: RFR: JDK-8300265: Remove metaprogramming/isSigned.hpp In-Reply-To: <5FdmclkgEZHyCgDKZvz2MZd0OyCCE2_oOLxZj8K9Ojs=.51b51fae-08c0-4bd1-be6f-f4b55cd72efd@github.com> References: <5FdmclkgEZHyCgDKZvz2MZd0OyCCE2_oOLxZj8K9Ojs=.51b51fae-08c0-4bd1-be6f-f4b55cd72efd@github.com> Message-ID: On Tue, 17 Jan 2023 14:29:41 GMT, Justin King wrote: > Code cleanup of pre-C++11 implementations. Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12042 From pchilanomate at openjdk.org Wed Jan 18 15:36:56 2023 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 18 Jan 2023 15:36:56 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v4] In-Reply-To: References: Message-ID: <6Nx7afJLt0AfEGcg5in2RWspQGMYuVWHNRaw3XpM9jA=.9dfe61aa-7d8b-4df0-b424-2383e794cb02@github.com> On Tue, 17 Jan 2023 08:35:45 GMT, Fredrik Bredberg wrote: >> Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. >> Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. >> Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. > > Fredrik Bredberg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' into relativize-locals-JDK-8299795_2023-01-09 > - Added references to JDK-8300197 > - Updated some copyright dates. > - Changed copyright date to 2023 > - 8299795: Relativize locals in interpreter frames Looks good to me, thanks! Patricio ------------- Marked as reviewed by pchilanomate (Reviewer). PR: https://git.openjdk.org/jdk/pull/11902 From rkennke at openjdk.org Wed Jan 18 15:45:38 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 18 Jan 2023 15:45:38 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v2] In-Reply-To: References: Message-ID: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Renaissance > > > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Properly set ZF on anon-check path; avoid some conditional branches ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10907/files - new: https://git.openjdk.org/jdk/pull/10907/files/c4746710..a270919e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=00-01 Stats: 19 lines in 1 file changed: 12 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/10907.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10907/head:pull/10907 PR: https://git.openjdk.org/jdk/pull/10907 From rkennke at openjdk.org Wed Jan 18 15:48:14 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 18 Jan 2023 15:48:14 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 14:57:33 GMT, Robbin Ehn wrote: > Here are some tests that seems provide some reproducability (mac/linux aarch64): runtime/handshake/HandshakeDirectTest.java vmTestbase/gc/gctests/ObjectMonitorCleanup/ObjectMonitorCleanup.java (crashes in AccessInternal::PostRuntimeDispatch, (AccessInternal::BarrierType)2, 594020ul>::oop_access_barrier(void*)+0x1c) vmTestbase/nsk/jdi/stress/serial/heapwalking00X > > (options don't seem to matter) > > Well of course you need to turn it on. I was running with this applied: > > ``` > diff --git a/src/hotspot/share/runtime/globals.hpp b/src/hotspot/share/runtime/globals.hpp > index f07a37b3d9f..c01c4f450a6 100644 > --- a/src/hotspot/share/runtime/globals.hpp > +++ b/src/hotspot/share/runtime/globals.hpp > @@ -1986 +1986 @@ const int ObjectAlignmentInBytes = 8; > - product(bool, UseFastLocking, false, EXPERIMENTAL, \ > + product(bool, UseFastLocking, true, EXPERIMENTAL, \ > ``` Thanks, Robbin! Turns out that this bug has been caused by one of the most recent commits: I used tnbz to branch to the exit of fast_unlock, but this doesn't set the ZF properly. I need to use regular tst & br instead. I pushed a fix, together with a number of minor improvements (avoid some conditional branches). Could you re-test? Thank you! Roman ------------- PR: https://git.openjdk.org/jdk/pull/10907 From duke at openjdk.org Wed Jan 18 15:49:16 2023 From: duke at openjdk.org (Fredrik Bredberg) Date: Wed, 18 Jan 2023 15:49:16 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v4] In-Reply-To: <968FbsOPB5eLgb9XhRv7RrOvFqWz6XW55YAbEtl-c-s=.2a5ff2a1-2e9f-4775-b4b7-8d06aec19f19@github.com> References: <3mWF3cL69YLzYwYI7z0nQB66c_JxuTUMPfTHVn_YjiQ=.00a62b19-8dd8-42ba-9d71-078cf21f2657@github.com> <968FbsOPB5eLgb9XhRv7RrOvFqWz6XW55YAbEtl-c-s=.2a5ff2a1-2e9f-4775-b4b7-8d06aec19f19@github.com> Message-ID: On Wed, 18 Jan 2023 05:07:38 GMT, Martin Doerr wrote: >> My intention was to show how the contents of R18_locals (the absolute address to locals) can be recreated by using R12_scratch2 as an index from the frame pointer. Before we stored R18_locals in the stackframe, now we store R12_scratch2. Does that make more sense? > > The code uses &sp()[R12_scratch2]. I think your comment is confusing. Please remove it or write something comprehensive. E.g. save R18_locals in compressed format relative to the new top frame's FP (= current SP). See what you mean, the R1_SP being the frame pointer is confusing. So how about changing the comment into: "// Store relativized R18_locals, see frame::interpreter_frame_locals()." Would that work for you? If not I'll just remove it. ------------- PR: https://git.openjdk.org/jdk/pull/11902 From mdoerr at openjdk.org Wed Jan 18 16:01:16 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 18 Jan 2023 16:01:16 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v4] In-Reply-To: References: <3mWF3cL69YLzYwYI7z0nQB66c_JxuTUMPfTHVn_YjiQ=.00a62b19-8dd8-42ba-9d71-078cf21f2657@github.com> <968FbsOPB5eLgb9XhRv7RrOvFqWz6XW55YAbEtl-c-s=.2a5ff2a1-2e9f-4775-b4b7-8d06aec19f19@github.com> Message-ID: On Wed, 18 Jan 2023 15:46:22 GMT, Fredrik Bredberg wrote: >> The code uses &sp()[R12_scratch2]. I think your comment is confusing. Please remove it or write something comprehensive. E.g. save R18_locals in compressed format relative to the new top frame's FP (= current SP). > > See what you mean, the R1_SP being the frame pointer is confusing. So how about changing the comment into: > "// Store relativized R18_locals, see frame::interpreter_frame_locals()." > Would that work for you? If not I'll just remove it. That's fine. Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/11902 From bpb at openjdk.org Wed Jan 18 16:58:54 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 18 Jan 2023 16:58:54 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v14] In-Reply-To: References: <1b3G5rQeMqfO1YyuB1oOylhjz6s0Un-pwDaXrZYZAt8=.e22dc3f0-621e-43fc-b3b8-651bfdcb6a2b@github.com> Message-ID: On Wed, 18 Jan 2023 09:07:06 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8299684: Clean up memory deallocation > > test/jdk/java/nio/jni/NewDirectByteBuffer.java line 106: > >> 104: (long)Integer.MAX_VALUE - 1, (long)Integer.MAX_VALUE}) >> 105: void legalCapacities(long capacity) { >> 106: long addr = UNSAFE.allocateMemory(capacity); > > I think David was asking for the test to continue when malloc fails. Now that the test is changed to use Unsafe.allocateMemory it means it has to catch OOME. Added catch of OOME in f9350695c3a6f90e3acdf2176d78c06406e49387. > test/jdk/java/nio/jni/libNewDirectByteBuffer.c line 49: > >> 47: (JNIEnv *env, jclass cls, jobject buf) >> 48: { >> 49: return (jlong)(*env)->GetDirectBufferAddress(env, buf); > > The cast to jlong should be okay for 64-bit. For 32-bit then it will likely need a double cast, as in ((jlong)(int)( .. )) but maybe okay for now as you've restricted the test to 64-bit. Leaving it as-is for now. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Wed Jan 18 16:58:53 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 18 Jan 2023 16:58:53 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v15] In-Reply-To: References: Message-ID: > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299684: Catch OOME from Unsafe::allocateMemory ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11873/files - new: https://git.openjdk.org/jdk/pull/11873/files/3b64bd20..f9350695 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=13-14 Stats: 19 lines in 1 file changed: 8 ins; 2 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Wed Jan 18 17:17:44 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 18 Jan 2023 17:17:44 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v16] In-Reply-To: References: Message-ID: <_Q4DQU03y9ghePhsOBkypY4umDdG4ZWDYTwMQB879-M=.4a6bcaa3-78fd-45dc-8a7a-a63a6bba8e9c@github.com> > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299684: Further cleanup around handling OOME (or not) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11873/files - new: https://git.openjdk.org/jdk/pull/11873/files/f9350695..040374bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=14-15 Stats: 29 lines in 1 file changed: 13 ins; 12 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From alanb at openjdk.org Wed Jan 18 17:30:21 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 18 Jan 2023 17:30:21 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v16] In-Reply-To: <_Q4DQU03y9ghePhsOBkypY4umDdG4ZWDYTwMQB879-M=.4a6bcaa3-78fd-45dc-8a7a-a63a6bba8e9c@github.com> References: <_Q4DQU03y9ghePhsOBkypY4umDdG4ZWDYTwMQB879-M=.4a6bcaa3-78fd-45dc-8a7a-a63a6bba8e9c@github.com> Message-ID: On Wed, 18 Jan 2023 17:17:44 GMT, Brian Burkhalter wrote: >> Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299684: Further cleanup around handling OOME (or not) Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11873 From rehn at openjdk.org Wed Jan 18 17:55:16 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 18 Jan 2023 17:55:16 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 15:45:38 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Renaissance >> >> >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Properly set ZF on anon-check path; avoid some conditional branches So far so good. If this passes I'll do some stressing. This one fails runtime/logging/MonitorInflationTest.java missing an output. ------------- PR: https://git.openjdk.org/jdk/pull/10907 From jcking at openjdk.org Wed Jan 18 18:31:57 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 18 Jan 2023 18:31:57 GMT Subject: RFR: JDK-8300582: Introduce interface for unaligned memory accesses Message-ID: Introduce interface for unaligned memory accesses `UnalignedAccess`, consolidate the byte swapping implementation to `byteswap`, and switch to a generic implementation of `Bytes`. ------------- Commit messages: - Unaligned access Changes: https://git.openjdk.org/jdk/pull/12078/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12078&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300582 Stats: 2246 lines in 25 files changed: 470 ins; 1770 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/12078.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12078/head:pull/12078 PR: https://git.openjdk.org/jdk/pull/12078 From rkennke at openjdk.org Wed Jan 18 18:29:40 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 18 Jan 2023 18:29:40 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v3] In-Reply-To: References: Message-ID: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Renaissance > > > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Change log message inflate(locked) -> inflate(has_locker) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10907/files - new: https://git.openjdk.org/jdk/pull/10907/files/a270919e..c35e5a34 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10907.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10907/head:pull/10907 PR: https://git.openjdk.org/jdk/pull/10907 From rkennke at openjdk.org Wed Jan 18 18:29:41 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 18 Jan 2023 18:29:41 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 17:52:24 GMT, Robbin Ehn wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Properly set ZF on anon-check path; avoid some conditional branches > > So far so good. If this passes I'll do some stressing. > > This one fails runtime/logging/MonitorInflationTest.java missing an output. @robehn how have you found this? This apparently slipped my testing because the test requires vm.flagless, but I would run it with TEST_VM_OPTS="-XX:+UnlockExperimentalVMOptions -XX:+UseFastLocking". I have changed the log message from inflate(locked) to inflate(has_locker) so that it matches the current stack-locking output. ------------- PR: https://git.openjdk.org/jdk/pull/10907 From jcking at openjdk.org Wed Jan 18 18:35:19 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 18 Jan 2023 18:35:19 GMT Subject: RFR: JDK-8300582: Introduce interface for unaligned memory accesses In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 18:22:35 GMT, Justin King wrote: > Introduce interface for unaligned memory accesses `UnalignedAccess`, consolidate the byte swapping implementation to `byteswap`, and switch to a generic implementation of `Bytes`. Note that this could potentially be split so that byteswap is first, I just did them together because they both touch `Bytes`. ------------- PR: https://git.openjdk.org/jdk/pull/12078 From xuelei at openjdk.org Wed Jan 18 19:34:46 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 18 Jan 2023 19:34:46 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v5] In-Reply-To: References: <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com> Message-ID: On Tue, 17 Jan 2023 20:50:26 GMT, Chris Plummer wrote: >> src/hotspot/os/windows/os_windows.cpp line 387: >> >>> 385: os::snprintf_checked(buf, sizeof(buf), "%s%s;%s%s%s", >>> 386: Arguments::get_java_home(), EXT_DIR, >>> 387: path, PACKAGE_DIR, EXT_DIR); >> >> When the call is split across multiple lines like this, the subsequent lines should align with the first parameter i.e. align under `buf`. > > I think the other acceptable approach is to put the first argument on the 2nd line, and then indent all the argument lines by 8. That works well if the first argument would otherwise start too far to the right. For the above, I think either approach would look ok. I can see both styles are used in this file. The current code here uses 8 whitespaces indent, I would like to keep it. ------------- PR: https://git.openjdk.org/jdk/pull/11935 From xuelei at openjdk.org Wed Jan 18 19:34:55 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 18 Jan 2023 19:34:55 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v5] In-Reply-To: References: <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com> Message-ID: <1ClKpQgCeS1zWMqBwXYSR3Y0LzX_l2-uOHoy_lFDQuQ=.9fb3d52b-0421-4945-860b-e149e5c07a8c@github.com> On Tue, 17 Jan 2023 01:34:49 GMT, David Holmes wrote: >> Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Merge >> - correction for ppc >> - missed update for debug mode >> - more in src/hotspot >> - typo correction >> - 8299635: More test issues for deprecated sprintf in Xcode 14 > > src/hotspot/share/utilities/globalDefinitions.hpp line 191: > >> 189: FORBID_C_FUNCTION(char* strerror(int), "use os::strerror"); >> 190: FORBID_C_FUNCTION(char* strtok(char*, const char*), "use strtok_r"); >> 191: FORBID_C_FUNCTION(int sprintf(char*, const char*, ...), "use os::snprintf"); > > I have to wonder whether this actually works too. Perhaps @kbarrett can comment? I am not confident with it. Maybe it is better to remove this change and consider it later. ------------- PR: https://git.openjdk.org/jdk/pull/11935 From xuelei at openjdk.org Wed Jan 18 19:41:11 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 18 Jan 2023 19:41:11 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v6] In-Reply-To: References: Message-ID: > The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. > > This patch is trying to find the use of sprintf in hotspot iml and test cases. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: Remove FORBID_C_FUNCTION update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11935/files - new: https://git.openjdk.org/jdk/pull/11935/files/143887e9..99d5c611 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11935.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11935/head:pull/11935 PR: https://git.openjdk.org/jdk/pull/11935 From xuelei at openjdk.org Wed Jan 18 19:41:12 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 18 Jan 2023 19:41:12 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v5] In-Reply-To: References: <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com> Message-ID: On Tue, 17 Jan 2023 01:36:43 GMT, David Holmes wrote: > I would suggest constraining this PR to src/hotspot and test/hotspot and deal with the JDK serviceability files in a different PR (and there may be other JDK files impacted too). I agreed. This PR is mainly focus on the hotspot, except two test files for jdk management. The test clean up is done with this PR, but there are still a lot (57+) use in other src component. One or more PR will be filed for the remaining clean up. ------------- PR: https://git.openjdk.org/jdk/pull/11935 From cjplummer at openjdk.org Wed Jan 18 19:48:18 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 18 Jan 2023 19:48:18 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v5] In-Reply-To: References: <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com> Message-ID: <5RjH-SG_Tv8lcUfEwfnAx1LzLThe3Kl__Vv_O6W5sz4=.f9128d51-3bcf-4adb-9097-32c312d045ce@github.com> On Wed, 18 Jan 2023 19:28:42 GMT, Xue-Lei Andrew Fan wrote: >> I think the other acceptable approach is to put the first argument on the 2nd line, and then indent all the argument lines by 8. That works well if the first argument would otherwise start too far to the right. For the above, I think either approach would look ok. > > I can see both styles are used in this file. The current code here uses 8 whitespaces indent, I would like to keep it. I scanned the first 1000 lines and saw many cases of multi-line argument passing, and they all indent as David suggested. I'm not saying there are non in the file that indent has you have, but it seems if there are cases, they are the exception. ------------- PR: https://git.openjdk.org/jdk/pull/11935 From duke at openjdk.org Wed Jan 18 19:55:45 2023 From: duke at openjdk.org (Scott Gibbons) Date: Wed, 18 Jan 2023 19:55:45 GMT Subject: RFR: JDK-8300584: Accelerate AVX-512 CRC32C for small buffers Message-ID: Use AVX2 code for CRC32C for small buffers in the AVX-512 path. Breakeven buffer size between the two algorithms is on the order of 384 bytes. **Performance numbers for previous:** Benchmark (count) Mode Cnt Score Error Units TestCRC32C.testCRC32CUpdate 64 thrpt 4 66974.957 ? 8.872 ops/ms TestCRC32C.testCRC32CUpdate 128 thrpt 4 44224.810 ? 11.801 ops/ms TestCRC32C.testCRC32CUpdate 256 thrpt 4 63997.611 ? 173.577 ops/ms TestCRC32C.testCRC32CUpdate 512 thrpt 4 56068.683 ? 269.582 ops/ms TestCRC32C.testCRC32CUpdate 2048 thrpt 4 27048.098 ? 87.350 ops/ms TestCRC32C.testCRC32CUpdate 16384 thrpt 4 4066.736 ? 10.318 ops/ms TestCRC32C.testCRC32CUpdate 65536 thrpt 4 1040.754 ? 6.419 ops/ms **Performance numbers for this version:** Benchmark (count) Mode Cnt Score Error Units TestCRC32C.testCRC32CUpdate 64 thrpt 3 161659.326 ? 74.974 ops/ms TestCRC32C.testCRC32CUpdate 128 thrpt 3 88456.935 ? 11.940 ops/ms TestCRC32C.testCRC32CUpdate 256 thrpt 3 73254.993 ? 5.004 ops/ms TestCRC32C.testCRC32CUpdate 512 thrpt 3 56508.541 ? 298.229 ops/ms TestCRC32C.testCRC32CUpdate 2048 thrpt 3 26701.995 ? 31.369 ops/ms TestCRC32C.testCRC32CUpdate 16384 thrpt 3 4110.819 ? 4.618 ops/ms TestCRC32C.testCRC32CUpdate 65536 thrpt 3 1045.821 ? 2.037 ops/ms ------------- Commit messages: - Use AVX2 code for CRC32C for small buffers in the AVX-512 path. Changes: https://git.openjdk.org/jdk/pull/12079/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12079&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300584 Stats: 20 lines in 1 file changed: 20 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12079.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12079/head:pull/12079 PR: https://git.openjdk.org/jdk/pull/12079 From xuelei at openjdk.org Wed Jan 18 20:07:35 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 18 Jan 2023 20:07:35 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v5] In-Reply-To: <5RjH-SG_Tv8lcUfEwfnAx1LzLThe3Kl__Vv_O6W5sz4=.f9128d51-3bcf-4adb-9097-32c312d045ce@github.com> References: <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com> <5RjH-SG_Tv8lcUfEwfnAx1LzLThe3Kl__Vv_O6W5sz4=.f9128d51-3bcf-4adb-9097-32c312d045ce@github.com> Message-ID: <29kkAIFV45-0r65aIMq0TnkQcfNE8q8tlvswoTmzv7k=.b35606a8-bb9e-4ba1-a419-a5f1c2dcbc62@github.com> On Wed, 18 Jan 2023 19:45:55 GMT, Chris Plummer wrote: >> I can see both styles are used in this file. The current code here uses 8 whitespaces indent, I would like to keep it. > > I scanned the first 1000 lines and saw many cases of multi-line argument passing, and they all indent as David suggested. I'm not saying there are non in the file that indent has you have, but it seems if there are cases, they are the exception. OK. I have no strong preference. Updated to align with the 1st parameter. ------------- PR: https://git.openjdk.org/jdk/pull/11935 From rkennke at openjdk.org Wed Jan 18 20:10:21 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 18 Jan 2023 20:10:21 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v4] In-Reply-To: References: Message-ID: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Renaissance > > > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Revert UseFastLocking to default to off ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10907/files - new: https://git.openjdk.org/jdk/pull/10907/files/c35e5a34..4504c1ce Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10907.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10907/head:pull/10907 PR: https://git.openjdk.org/jdk/pull/10907 From xuelei at openjdk.org Wed Jan 18 20:07:31 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 18 Jan 2023 20:07:31 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v7] In-Reply-To: References: Message-ID: > The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. > > This patch is trying to find the use of sprintf in hotspot iml and test cases. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: align splited lines ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11935/files - new: https://git.openjdk.org/jdk/pull/11935/files/99d5c611..62589ae5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=05-06 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11935.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11935/head:pull/11935 PR: https://git.openjdk.org/jdk/pull/11935 From rkennke at openjdk.org Wed Jan 18 20:26:11 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 18 Jan 2023 20:26:11 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v11] In-Reply-To: References: Message-ID: <2eLY5ofPr19n9ZwpF4HRuUTA6t4eqfXlMIAXDi1A4DY=.117c1c95-dcdd-4f5c-86a8-88d564076bb7@github.com> On Wed, 7 Dec 2022 08:40:25 GMT, Stefan Karlsson wrote: >> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: >> >> - Merge branch 'master' into JDK-8139457 >> - Fix gtest for correct base offsets in 32bit builds >> - Fix cast warning >> - Revert relaxation of array length >> - Add guards to ArrayBaseOffsets test to allow running with -UseCompressedClassPointers >> - Fix another cast warning >> - Clean cast warning from size_t to int >> - Clear leading 32bits in Z array allocator >> - SA adjustments >> - Test for 32bit build >> - ... and 15 more: https://git.openjdk.org/jdk/compare/500b45e1...c278a53b > > Changes requested by stefank (Reviewer). Ping? @stefank @tstuefe @fisk, maybe? Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/11044 From jcking at openjdk.org Wed Jan 18 21:42:58 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 18 Jan 2023 21:42:58 GMT Subject: RFR: JDK-8300582: Introduce interface for unaligned memory accesses [v2] In-Reply-To: References: Message-ID: > Introduce interface for unaligned memory accesses `UnalignedAccess`, consolidate the byte swapping implementation to `byteswap`, and switch to a generic implementation of `Bytes`. Justin King has updated the pull request incrementally with one additional commit since the last revision: Update comment to be correct Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12078/files - new: https://git.openjdk.org/jdk/pull/12078/files/3c75964c..b181ce9f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12078&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12078&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12078.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12078/head:pull/12078 PR: https://git.openjdk.org/jdk/pull/12078 From kvn at openjdk.org Wed Jan 18 22:04:26 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 18 Jan 2023 22:04:26 GMT Subject: RFR: JDK-8300584: Accelerate AVX-512 CRC32C for small buffers In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 19:21:58 GMT, Scott Gibbons wrote: > Use AVX2 code for CRC32C for small buffers in the AVX-512 path. Breakeven buffer size between the two algorithms is on the order of 384 bytes. > > **Performance numbers for previous:** > > Benchmark (count) Mode Cnt Score Error Units > TestCRC32C.testCRC32CUpdate 64 thrpt 4 66974.957 ? 8.872 ops/ms > TestCRC32C.testCRC32CUpdate 128 thrpt 4 44224.810 ? 11.801 ops/ms > TestCRC32C.testCRC32CUpdate 256 thrpt 4 63997.611 ? 173.577 ops/ms > TestCRC32C.testCRC32CUpdate 512 thrpt 4 56068.683 ? 269.582 ops/ms > TestCRC32C.testCRC32CUpdate 2048 thrpt 4 27048.098 ? 87.350 ops/ms > TestCRC32C.testCRC32CUpdate 16384 thrpt 4 4066.736 ? 10.318 ops/ms > TestCRC32C.testCRC32CUpdate 65536 thrpt 4 1040.754 ? 6.419 ops/ms > > > **Performance numbers for this version:** > > Benchmark (count) Mode Cnt Score Error Units > TestCRC32C.testCRC32CUpdate 64 thrpt 3 161659.326 ? 74.974 ops/ms > TestCRC32C.testCRC32CUpdate 128 thrpt 3 88456.935 ? 11.940 ops/ms > TestCRC32C.testCRC32CUpdate 256 thrpt 3 73254.993 ? 5.004 ops/ms > TestCRC32C.testCRC32CUpdate 512 thrpt 3 56508.541 ? 298.229 ops/ms > TestCRC32C.testCRC32CUpdate 2048 thrpt 3 26701.995 ? 31.369 ops/ms > TestCRC32C.testCRC32CUpdate 16384 thrpt 3 4110.819 ? 4.618 ops/ms > TestCRC32C.testCRC32CUpdate 65536 thrpt 3 1045.821 ? 2.037 ops/ms We should avoid duplicating code. Since `crc32c_ipl_alg2_alt2` is used in both cases we can reshape code like next (pseudo code): if (supports_avx512()) { if (len > 384) { kernel_crc32_avx512(); jmp Exit; } } crc32c_ipl_alg2_alt2(); Exit: ... ------------- Changes requested by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/12079 From duke at openjdk.org Wed Jan 18 22:19:24 2023 From: duke at openjdk.org (Scott Gibbons) Date: Wed, 18 Jan 2023 22:19:24 GMT Subject: RFR: JDK-8300584: Accelerate AVX-512 CRC32C for small buffers In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 22:02:03 GMT, Vladimir Kozlov wrote: >> Use AVX2 code for CRC32C for small buffers in the AVX-512 path. Breakeven buffer size between the two algorithms is on the order of 384 bytes. >> >> **Performance numbers for previous:** >> >> Benchmark (count) Mode Cnt Score Error Units >> TestCRC32C.testCRC32CUpdate 64 thrpt 4 66974.957 ? 8.872 ops/ms >> TestCRC32C.testCRC32CUpdate 128 thrpt 4 44224.810 ? 11.801 ops/ms >> TestCRC32C.testCRC32CUpdate 256 thrpt 4 63997.611 ? 173.577 ops/ms >> TestCRC32C.testCRC32CUpdate 512 thrpt 4 56068.683 ? 269.582 ops/ms >> TestCRC32C.testCRC32CUpdate 2048 thrpt 4 27048.098 ? 87.350 ops/ms >> TestCRC32C.testCRC32CUpdate 16384 thrpt 4 4066.736 ? 10.318 ops/ms >> TestCRC32C.testCRC32CUpdate 65536 thrpt 4 1040.754 ? 6.419 ops/ms >> >> >> **Performance numbers for this version:** >> >> Benchmark (count) Mode Cnt Score Error Units >> TestCRC32C.testCRC32CUpdate 64 thrpt 3 161659.326 ? 74.974 ops/ms >> TestCRC32C.testCRC32CUpdate 128 thrpt 3 88456.935 ? 11.940 ops/ms >> TestCRC32C.testCRC32CUpdate 256 thrpt 3 73254.993 ? 5.004 ops/ms >> TestCRC32C.testCRC32CUpdate 512 thrpt 3 56508.541 ? 298.229 ops/ms >> TestCRC32C.testCRC32CUpdate 2048 thrpt 3 26701.995 ? 31.369 ops/ms >> TestCRC32C.testCRC32CUpdate 16384 thrpt 3 4110.819 ? 4.618 ops/ms >> TestCRC32C.testCRC32CUpdate 65536 thrpt 3 1045.821 ? 2.037 ops/ms > > We should avoid duplicating code. Since `crc32c_ipl_alg2_alt2` is used in both cases we can reshape code like next (pseudo code): > > > if (supports_avx512()) { > if (len > 384) { > kernel_crc32_avx512(); > jmp Exit; > } > } > crc32c_ipl_alg2_alt2(); > Exit: > ... @vnkozlov - There is really no code duplication here. This is generating code, so the `if(supports_avx512())` construct is directing which code is generated for the intrinsic. That is, it either generates the AVX-512 kernel -OR- it generates the AVX2 routine. I need *both* generated for this fix. In the original code, there is no fall-through, so the `crc32c_ipl_alg2_alt2()` block can't be jumped to (because it's never generated). In the case where AVX-512 is not a capability of the platform, only `crc32c_ipl_alg2_alt2()` is generated. In any case, the check on `len` is a *runtime* check, not a code-generation check. Does this make sense? ------------- PR: https://git.openjdk.org/jdk/pull/12079 From jsjolen at openjdk.org Wed Jan 18 22:33:25 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 18 Jan 2023 22:33:25 GMT Subject: RFR: 8299973: Replace NULL with nullptr in share/utilities/ Message-ID: <2zedOytL52BSGlcMPHvfc7ykU9HFcx_1WGMzkgRo4ss=.3b4f9835-3349-4029-a8f1-9975618ead86@github.com> Do the conversion in the share/utilities sub-directory and all of its files. ------------- Commit messages: - More manual fixes - Missed manual fix - Merge remote-tracking branch 'origin/master' into JDK-8299837 - Manual fixes - Replace NULL with nullptr in share/utilities Changes: https://git.openjdk.org/jdk/pull/12015/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12015&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299973 Stats: 574 lines in 59 files changed: 1 ins; 0 del; 573 mod Patch: https://git.openjdk.org/jdk/pull/12015.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12015/head:pull/12015 PR: https://git.openjdk.org/jdk/pull/12015 From jsjolen at openjdk.org Wed Jan 18 22:33:26 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 18 Jan 2023 22:33:26 GMT Subject: RFR: 8299973: Replace NULL with nullptr in share/utilities/ In-Reply-To: <2zedOytL52BSGlcMPHvfc7ykU9HFcx_1WGMzkgRo4ss=.3b4f9835-3349-4029-a8f1-9975618ead86@github.com> References: <2zedOytL52BSGlcMPHvfc7ykU9HFcx_1WGMzkgRo4ss=.3b4f9835-3349-4029-a8f1-9975618ead86@github.com> Message-ID: On Mon, 16 Jan 2023 19:22:43 GMT, Johan Sj?len wrote: > Do the conversion in the share/utilities sub-directory and all of its files. Opening this up for review now. Please look at the manual fixes commits for were I made my own decisions (had to make more than I have had to so far). Running tests right now. src/hotspot/share/utilities/debug.cpp line 425: > 423: CodeBlob* cb = CodeCache::find_blob((address)p); > 424: if (cb == nullptr) { > 425: tty->print_cr("nullptr"); Changes log, OK? src/hotspot/share/utilities/globalDefinitions.cpp line 162: > 160: static_assert((size_t)HeapWordSize >= sizeof(juint), > 161: "HeapWord should be at least as large as juint"); > 162: static_assert(sizeof(nullptr) == sizeof(char*), "nullptr must be same size as pointer"); Adding in another static_assert here so that both cases are represented. ------------- PR: https://git.openjdk.org/jdk/pull/12015 From kvn at openjdk.org Wed Jan 18 22:36:28 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 18 Jan 2023 22:36:28 GMT Subject: RFR: JDK-8300584: Accelerate AVX-512 CRC32C for small buffers In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 19:21:58 GMT, Scott Gibbons wrote: > Use AVX2 code for CRC32C for small buffers in the AVX-512 path. Breakeven buffer size between the two algorithms is on the order of 384 bytes. > > **Performance numbers for previous:** > > Benchmark (count) Mode Cnt Score Error Units > TestCRC32C.testCRC32CUpdate 64 thrpt 4 66974.957 ? 8.872 ops/ms > TestCRC32C.testCRC32CUpdate 128 thrpt 4 44224.810 ? 11.801 ops/ms > TestCRC32C.testCRC32CUpdate 256 thrpt 4 63997.611 ? 173.577 ops/ms > TestCRC32C.testCRC32CUpdate 512 thrpt 4 56068.683 ? 269.582 ops/ms > TestCRC32C.testCRC32CUpdate 2048 thrpt 4 27048.098 ? 87.350 ops/ms > TestCRC32C.testCRC32CUpdate 16384 thrpt 4 4066.736 ? 10.318 ops/ms > TestCRC32C.testCRC32CUpdate 65536 thrpt 4 1040.754 ? 6.419 ops/ms > > > **Performance numbers for this version:** > > Benchmark (count) Mode Cnt Score Error Units > TestCRC32C.testCRC32CUpdate 64 thrpt 3 161659.326 ? 74.974 ops/ms > TestCRC32C.testCRC32CUpdate 128 thrpt 3 88456.935 ? 11.940 ops/ms > TestCRC32C.testCRC32CUpdate 256 thrpt 3 73254.993 ? 5.004 ops/ms > TestCRC32C.testCRC32CUpdate 512 thrpt 3 56508.541 ? 298.229 ops/ms > TestCRC32C.testCRC32CUpdate 2048 thrpt 3 26701.995 ? 31.369 ops/ms > TestCRC32C.testCRC32CUpdate 16384 thrpt 3 4110.819 ? 4.618 ops/ms > TestCRC32C.testCRC32CUpdate 65536 thrpt 3 1045.821 ? 2.037 ops/ms I mean this (`else` is removed so that `AVX2` code is always generated): __ enter(); // required for proper stackwalking of RuntimeStub frame Label L_small, L_continue; if (VM_Version::supports_sse4_1() && VM_Version::supports_avx512_vpclmulqdq() && VM_Version::supports_avx512bw() && VM_Version::supports_avx512vl()) { __ cmpl(len, 384); __ jcc(Assembler::belowEqual, L_small); __ lea(j, ExternalAddress(StubRoutines::x86::crc32c_table_avx512_addr())); __ kernel_crc32_avx512(crc, buf, len, j, l, k); __ jmp(L_continue); __ bind(L_small); } #ifdef _WIN64 __ push(y); __ push(z); #endif __ crc32c_ipl_alg2_alt2(crc, buf, len, a, j, k, l, y, z, c_farg0, c_farg1, c_farg2, is_pclmulqdq_supported); #ifdef _WIN64 __ pop(z); __ pop(y); #endif __ bind(L_continue); __ movl(rax, crc); __ vzeroupper(); __ leave(); // required for proper stackwalking of RuntimeStub frame __ ret(0); ------------- PR: https://git.openjdk.org/jdk/pull/12079 From coleenp at openjdk.org Wed Jan 18 22:51:31 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 18 Jan 2023 22:51:31 GMT Subject: RFR: 8299973: Replace NULL with nullptr in share/utilities/ In-Reply-To: <2zedOytL52BSGlcMPHvfc7ykU9HFcx_1WGMzkgRo4ss=.3b4f9835-3349-4029-a8f1-9975618ead86@github.com> References: <2zedOytL52BSGlcMPHvfc7ykU9HFcx_1WGMzkgRo4ss=.3b4f9835-3349-4029-a8f1-9975618ead86@github.com> Message-ID: On Mon, 16 Jan 2023 19:22:43 GMT, Johan Sj?len wrote: > Do the conversion in the share/utilities sub-directory and all of its files. ? src/hotspot/share/utilities/globalDefinitions_visCPP.hpp line 2: > 1: /* > 2: * Copyright (c) 1997, 2023, Oracle and/or its affiliates. All rights reserved. You updated the copyright without changing anything in this file. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/12015 From coleenp at openjdk.org Wed Jan 18 22:51:33 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 18 Jan 2023 22:51:33 GMT Subject: RFR: 8299973: Replace NULL with nullptr in share/utilities/ In-Reply-To: References: <2zedOytL52BSGlcMPHvfc7ykU9HFcx_1WGMzkgRo4ss=.3b4f9835-3349-4029-a8f1-9975618ead86@github.com> Message-ID: On Wed, 18 Jan 2023 22:11:17 GMT, Johan Sj?len wrote: >> Do the conversion in the share/utilities sub-directory and all of its files. > > src/hotspot/share/utilities/debug.cpp line 425: > >> 423: CodeBlob* cb = CodeCache::find_blob((address)p); >> 424: if (cb == nullptr) { >> 425: tty->print_cr("nullptr"); > > Changes log, OK? I think it's ok. Unless we have tests that check for NULL, but they're likely in gtests and you'll find them pretty quickly and can fix them pretty quickly if they slip through. ------------- PR: https://git.openjdk.org/jdk/pull/12015 From duke at openjdk.org Wed Jan 18 23:10:12 2023 From: duke at openjdk.org (Scott Gibbons) Date: Wed, 18 Jan 2023 23:10:12 GMT Subject: RFR: JDK-8300584: Accelerate AVX-512 CRC32C for small buffers [v2] In-Reply-To: References: Message-ID: > Use AVX2 code for CRC32C for small buffers in the AVX-512 path. Breakeven buffer size between the two algorithms is on the order of 384 bytes. > > **Performance numbers for previous:** > > Benchmark (count) Mode Cnt Score Error Units > TestCRC32C.testCRC32CUpdate 64 thrpt 4 66974.957 ? 8.872 ops/ms > TestCRC32C.testCRC32CUpdate 128 thrpt 4 44224.810 ? 11.801 ops/ms > TestCRC32C.testCRC32CUpdate 256 thrpt 4 63997.611 ? 173.577 ops/ms > TestCRC32C.testCRC32CUpdate 512 thrpt 4 56068.683 ? 269.582 ops/ms > TestCRC32C.testCRC32CUpdate 2048 thrpt 4 27048.098 ? 87.350 ops/ms > TestCRC32C.testCRC32CUpdate 16384 thrpt 4 4066.736 ? 10.318 ops/ms > TestCRC32C.testCRC32CUpdate 65536 thrpt 4 1040.754 ? 6.419 ops/ms > > > **Performance numbers for this version:** > > Benchmark (count) Mode Cnt Score Error Units > TestCRC32C.testCRC32CUpdate 64 thrpt 3 161659.326 ? 74.974 ops/ms > TestCRC32C.testCRC32CUpdate 128 thrpt 3 88456.935 ? 11.940 ops/ms > TestCRC32C.testCRC32CUpdate 256 thrpt 3 73254.993 ? 5.004 ops/ms > TestCRC32C.testCRC32CUpdate 512 thrpt 3 56508.541 ? 298.229 ops/ms > TestCRC32C.testCRC32CUpdate 2048 thrpt 3 26701.995 ? 31.369 ops/ms > TestCRC32C.testCRC32CUpdate 16384 thrpt 3 4110.819 ? 4.618 ops/ms > TestCRC32C.testCRC32CUpdate 65536 thrpt 3 1045.821 ? 2.037 ops/ms Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision: Incorporate review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12079/files - new: https://git.openjdk.org/jdk/pull/12079/files/7ec6a8ea..e076cab5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12079&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12079&range=00-01 Stats: 36 lines in 1 file changed: 7 ins; 15 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/12079.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12079/head:pull/12079 PR: https://git.openjdk.org/jdk/pull/12079 From duke at openjdk.org Wed Jan 18 23:10:14 2023 From: duke at openjdk.org (Scott Gibbons) Date: Wed, 18 Jan 2023 23:10:14 GMT Subject: RFR: JDK-8300584: Accelerate AVX-512 CRC32C for small buffers In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 22:32:17 GMT, Vladimir Kozlov wrote: >> Use AVX2 code for CRC32C for small buffers in the AVX-512 path. Breakeven buffer size between the two algorithms is on the order of 384 bytes. >> >> **Performance numbers for previous:** >> >> Benchmark (count) Mode Cnt Score Error Units >> TestCRC32C.testCRC32CUpdate 64 thrpt 4 66974.957 ? 8.872 ops/ms >> TestCRC32C.testCRC32CUpdate 128 thrpt 4 44224.810 ? 11.801 ops/ms >> TestCRC32C.testCRC32CUpdate 256 thrpt 4 63997.611 ? 173.577 ops/ms >> TestCRC32C.testCRC32CUpdate 512 thrpt 4 56068.683 ? 269.582 ops/ms >> TestCRC32C.testCRC32CUpdate 2048 thrpt 4 27048.098 ? 87.350 ops/ms >> TestCRC32C.testCRC32CUpdate 16384 thrpt 4 4066.736 ? 10.318 ops/ms >> TestCRC32C.testCRC32CUpdate 65536 thrpt 4 1040.754 ? 6.419 ops/ms >> >> >> **Performance numbers for this version:** >> >> Benchmark (count) Mode Cnt Score Error Units >> TestCRC32C.testCRC32CUpdate 64 thrpt 3 161659.326 ? 74.974 ops/ms >> TestCRC32C.testCRC32CUpdate 128 thrpt 3 88456.935 ? 11.940 ops/ms >> TestCRC32C.testCRC32CUpdate 256 thrpt 3 73254.993 ? 5.004 ops/ms >> TestCRC32C.testCRC32CUpdate 512 thrpt 3 56508.541 ? 298.229 ops/ms >> TestCRC32C.testCRC32CUpdate 2048 thrpt 3 26701.995 ? 31.369 ops/ms >> TestCRC32C.testCRC32CUpdate 16384 thrpt 3 4110.819 ? 4.618 ops/ms >> TestCRC32C.testCRC32CUpdate 65536 thrpt 3 1045.821 ? 2.037 ops/ms > > I mean this (`else` is removed so that `AVX2` code is always generated): > > __ enter(); // required for proper stackwalking of RuntimeStub frame > > Label L_small, L_continue; > > if (VM_Version::supports_sse4_1() && VM_Version::supports_avx512_vpclmulqdq() && > VM_Version::supports_avx512bw() && > VM_Version::supports_avx512vl()) { > __ cmpl(len, 384); > __ jcc(Assembler::belowEqual, L_small); > > __ lea(j, ExternalAddress(StubRoutines::x86::crc32c_table_avx512_addr())); > __ kernel_crc32_avx512(crc, buf, len, j, l, k); > __ jmp(L_continue); > > __ bind(L_small); > } > #ifdef _WIN64 > __ push(y); > __ push(z); > #endif > __ crc32c_ipl_alg2_alt2(crc, buf, len, > a, j, k, > l, y, z, > c_farg0, c_farg1, c_farg2, > is_pclmulqdq_supported); > #ifdef _WIN64 > __ pop(z); > __ pop(y); > #endif > __ bind(L_continue); > __ movl(rax, crc); > __ vzeroupper(); > __ leave(); // required for proper stackwalking of RuntimeStub frame > __ ret(0); @vnkozlov Thanks for clarifying. I've pushed changed code - let me know if this is what you were thinking. ------------- PR: https://git.openjdk.org/jdk/pull/12079 From kvn at openjdk.org Wed Jan 18 23:37:29 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 18 Jan 2023 23:37:29 GMT Subject: RFR: JDK-8300584: Accelerate AVX-512 CRC32C for small buffers [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 23:10:12 GMT, Scott Gibbons wrote: >> Use AVX2 code for CRC32C for small buffers in the AVX-512 path. Breakeven buffer size between the two algorithms is on the order of 384 bytes. >> >> **Performance numbers for previous:** >> >> Benchmark (count) Mode Cnt Score Error Units >> TestCRC32C.testCRC32CUpdate 64 thrpt 4 66974.957 ? 8.872 ops/ms >> TestCRC32C.testCRC32CUpdate 128 thrpt 4 44224.810 ? 11.801 ops/ms >> TestCRC32C.testCRC32CUpdate 256 thrpt 4 63997.611 ? 173.577 ops/ms >> TestCRC32C.testCRC32CUpdate 512 thrpt 4 56068.683 ? 269.582 ops/ms >> TestCRC32C.testCRC32CUpdate 2048 thrpt 4 27048.098 ? 87.350 ops/ms >> TestCRC32C.testCRC32CUpdate 16384 thrpt 4 4066.736 ? 10.318 ops/ms >> TestCRC32C.testCRC32CUpdate 65536 thrpt 4 1040.754 ? 6.419 ops/ms >> >> >> **Performance numbers for this version:** >> >> Benchmark (count) Mode Cnt Score Error Units >> TestCRC32C.testCRC32CUpdate 64 thrpt 3 161659.326 ? 74.974 ops/ms >> TestCRC32C.testCRC32CUpdate 128 thrpt 3 88456.935 ? 11.940 ops/ms >> TestCRC32C.testCRC32CUpdate 256 thrpt 3 73254.993 ? 5.004 ops/ms >> TestCRC32C.testCRC32CUpdate 512 thrpt 3 56508.541 ? 298.229 ops/ms >> TestCRC32C.testCRC32CUpdate 2048 thrpt 3 26701.995 ? 31.369 ops/ms >> TestCRC32C.testCRC32CUpdate 16384 thrpt 3 4110.819 ? 4.618 ops/ms >> TestCRC32C.testCRC32CUpdate 65536 thrpt 3 1045.821 ? 2.037 ops/ms > > Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Incorporate review comments Good. Please, rerun performance tests. I will run our regular testing. ------------- PR: https://git.openjdk.org/jdk/pull/12079 From duke at openjdk.org Wed Jan 18 23:40:30 2023 From: duke at openjdk.org (Scott Gibbons) Date: Wed, 18 Jan 2023 23:40:30 GMT Subject: RFR: JDK-8300584: Accelerate AVX-512 CRC32C for small buffers [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 23:10:12 GMT, Scott Gibbons wrote: >> Use AVX2 code for CRC32C for small buffers in the AVX-512 path. Breakeven buffer size between the two algorithms is on the order of 384 bytes. >> >> **Performance numbers for previous:** >> >> Benchmark (count) Mode Cnt Score Error Units >> TestCRC32C.testCRC32CUpdate 64 thrpt 4 66974.957 ? 8.872 ops/ms >> TestCRC32C.testCRC32CUpdate 128 thrpt 4 44224.810 ? 11.801 ops/ms >> TestCRC32C.testCRC32CUpdate 256 thrpt 4 63997.611 ? 173.577 ops/ms >> TestCRC32C.testCRC32CUpdate 512 thrpt 4 56068.683 ? 269.582 ops/ms >> TestCRC32C.testCRC32CUpdate 2048 thrpt 4 27048.098 ? 87.350 ops/ms >> TestCRC32C.testCRC32CUpdate 16384 thrpt 4 4066.736 ? 10.318 ops/ms >> TestCRC32C.testCRC32CUpdate 65536 thrpt 4 1040.754 ? 6.419 ops/ms >> >> >> **Performance numbers for this version:** >> >> Benchmark (count) Mode Cnt Score Error Units >> TestCRC32C.testCRC32CUpdate 64 thrpt 3 161659.326 ? 74.974 ops/ms >> TestCRC32C.testCRC32CUpdate 128 thrpt 3 88456.935 ? 11.940 ops/ms >> TestCRC32C.testCRC32CUpdate 256 thrpt 3 73254.993 ? 5.004 ops/ms >> TestCRC32C.testCRC32CUpdate 512 thrpt 3 56508.541 ? 298.229 ops/ms >> TestCRC32C.testCRC32CUpdate 2048 thrpt 3 26701.995 ? 31.369 ops/ms >> TestCRC32C.testCRC32CUpdate 16384 thrpt 3 4110.819 ? 4.618 ops/ms >> TestCRC32C.testCRC32CUpdate 65536 thrpt 3 1045.821 ? 2.037 ops/ms > > Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Incorporate review comments Here are the new results. They seem to be in-line with what was reported in the initial description: Benchmark (count) Mode Cnt Score Error Units TestCRC32C.testCRC32CUpdate 64 thrpt 4 161653.588 ? 90.568 ops/ms TestCRC32C.testCRC32CUpdate 128 thrpt 4 88458.045 ? 1.664 ops/ms TestCRC32C.testCRC32CUpdate 256 thrpt 4 73253.929 ? 2.757 ops/ms TestCRC32C.testCRC32CUpdate 512 thrpt 4 56095.367 ? 33.203 ops/ms TestCRC32C.testCRC32CUpdate 2048 thrpt 4 27714.763 ? 7.075 ops/ms TestCRC32C.testCRC32CUpdate 16384 thrpt 4 4120.630 ? 13.723 ops/ms TestCRC32C.testCRC32CUpdate 65536 thrpt 4 1046.727 ? 0.227 ops/ms ------------- PR: https://git.openjdk.org/jdk/pull/12079 From kvn at openjdk.org Thu Jan 19 00:58:29 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 19 Jan 2023 00:58:29 GMT Subject: RFR: JDK-8300584: Accelerate AVX-512 CRC32C for small buffers [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 23:10:12 GMT, Scott Gibbons wrote: >> Use AVX2 code for CRC32C for small buffers in the AVX-512 path. Breakeven buffer size between the two algorithms is on the order of 384 bytes. >> >> **Performance numbers for previous:** >> >> Benchmark (count) Mode Cnt Score Error Units >> TestCRC32C.testCRC32CUpdate 64 thrpt 4 66974.957 ? 8.872 ops/ms >> TestCRC32C.testCRC32CUpdate 128 thrpt 4 44224.810 ? 11.801 ops/ms >> TestCRC32C.testCRC32CUpdate 256 thrpt 4 63997.611 ? 173.577 ops/ms >> TestCRC32C.testCRC32CUpdate 512 thrpt 4 56068.683 ? 269.582 ops/ms >> TestCRC32C.testCRC32CUpdate 2048 thrpt 4 27048.098 ? 87.350 ops/ms >> TestCRC32C.testCRC32CUpdate 16384 thrpt 4 4066.736 ? 10.318 ops/ms >> TestCRC32C.testCRC32CUpdate 65536 thrpt 4 1040.754 ? 6.419 ops/ms >> >> >> **Performance numbers for this version:** >> >> Benchmark (count) Mode Cnt Score Error Units >> TestCRC32C.testCRC32CUpdate 64 thrpt 3 161659.326 ? 74.974 ops/ms >> TestCRC32C.testCRC32CUpdate 128 thrpt 3 88456.935 ? 11.940 ops/ms >> TestCRC32C.testCRC32CUpdate 256 thrpt 3 73254.993 ? 5.004 ops/ms >> TestCRC32C.testCRC32CUpdate 512 thrpt 3 56508.541 ? 298.229 ops/ms >> TestCRC32C.testCRC32CUpdate 2048 thrpt 3 26701.995 ? 31.369 ops/ms >> TestCRC32C.testCRC32CUpdate 16384 thrpt 3 4110.819 ? 4.618 ops/ms >> TestCRC32C.testCRC32CUpdate 65536 thrpt 3 1045.821 ? 2.037 ops/ms > > Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Incorporate review comments Good. You need second review. ------------- PR: https://git.openjdk.org/jdk/pull/12079 From yadongwang at openjdk.org Thu Jan 19 01:22:37 2023 From: yadongwang at openjdk.org (Yadong Wang) Date: Thu, 19 Jan 2023 01:22:37 GMT Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory API (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 11:11:30 GMT, Feilong Jiang wrote: >> Add experimental Foreign Function & Memory API support for RISC-V. >> >> For details of the FFM API RISC-V port please refer to [JBS issue](https://bugs.openjdk.org/browse/JDK-8293841) >> >> Testing: >> >> - [x] jdk_foreign with release/fastdebug build on linux-riscv64 >> - [x] jdk_foreign with release/fastdebug build on linux-x64 >> - [x] jdk_foreign with release/fastdebug build on linux-aarch64 > > Feilong Jiang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: > > - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8293841-foreign-api-riscv > - more code style adjustment > - fix comment & code adjustment > - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8293841-foreign-api-riscv > - fix callArranger > - fix callArranger > - fix build > - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8293841-foreign-api-riscv > - code adjustment and remove unnecessary static > - sync with JDK-8296477 > - ... and 2 more: https://git.openjdk.org/jdk/compare/0245ec81...feac5fa8 lgtm ------------- Marked as reviewed by yadongwang (Author). PR: https://git.openjdk.org/jdk/pull/11004 From fjiang at openjdk.org Thu Jan 19 01:27:26 2023 From: fjiang at openjdk.org (Feilong Jiang) Date: Thu, 19 Jan 2023 01:27:26 GMT Subject: RFR: 8293841: RISC-V: Implementation of Foreign Function & Memory API (Preview) [v5] In-Reply-To: References: Message-ID: <69LvUbE51AIQC5P9WBhyYS9Cy5RkPwx8Po_N25jsNO0=.c151cb06-d444-4eae-b51b-e4b4226d59f7@github.com> On Sat, 14 Jan 2023 10:20:22 GMT, Jorn Vernee wrote: >> Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision: >> >> fix callArranger > > Marked as reviewed by jvernee (Reviewer). @JornVernee @RealFYang @shipilev @yadongw -- Thank you all for the review! I'm going to integrate it then. ------------- PR: https://git.openjdk.org/jdk/pull/11004 From fjiang at openjdk.org Thu Jan 19 01:36:36 2023 From: fjiang at openjdk.org (Feilong Jiang) Date: Thu, 19 Jan 2023 01:36:36 GMT Subject: Integrated: 8293841: RISC-V: Implementation of Foreign Function & Memory API (Preview) In-Reply-To: References: Message-ID: <0-s0h5-Y5OYozZSQUxCi86Be9JI2uI2Mu7IaQuBOOsE=.62dd2b76-0de8-4590-a759-03f940b9f790@github.com> On Sat, 5 Nov 2022 03:48:01 GMT, Feilong Jiang wrote: > Add experimental Foreign Function & Memory API support for RISC-V. > > For details of the FFM API RISC-V port please refer to [JBS issue](https://bugs.openjdk.org/browse/JDK-8293841) > > Testing: > > - [x] jdk_foreign with release/fastdebug build on linux-riscv64 > - [x] jdk_foreign with release/fastdebug build on linux-x64 > - [x] jdk_foreign with release/fastdebug build on linux-aarch64 This pull request has now been integrated. Changeset: 24cdcd4c Author: Feilong Jiang Committer: Fei Yang URL: https://git.openjdk.org/jdk/commit/24cdcd4c70dd538fd6c6c9f05da480ea65463209 Stats: 2846 lines in 64 files changed: 2721 ins; 2 del; 123 mod 8293841: RISC-V: Implementation of Foreign Function & Memory API (Preview) Co-authored-by: Weikai He Co-authored-by: Fei Yang Reviewed-by: jvernee, fyang, shade, yadongwang ------------- PR: https://git.openjdk.org/jdk/pull/11004 From haosun at openjdk.org Thu Jan 19 07:06:26 2023 From: haosun at openjdk.org (Hao Sun) Date: Thu, 19 Jan 2023 07:06:26 GMT Subject: RFR: 8300253: Introduce AArch64 nzcv accessors In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 10:32:33 GMT, Stuart Monteith wrote: >> OK, I'm not wild about checking in dead code, but if it's imminently needed, OK. Please add the instructions to `test/hotspot/gtest/aarch64/aarch64-asmtest.py` so they get tested.. > > The bits for the instructions are correct. I presume there'll be a train of patches for ZGC generational to necessitate it. I suggest adding one comment here. How about: // macro instructions for accessing and updating // PSTATE.{N,Z,C,V} fields at EL0 // // NZCV: op1 = 011 // CRn = 0100 // CRm = 0010 // op2 = 000 ------------- PR: https://git.openjdk.org/jdk/pull/12038 From dholmes at openjdk.org Thu Jan 19 07:13:30 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 19 Jan 2023 07:13:30 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 18:25:15 GMT, Roman Kennke wrote: > This apparently slipped my testing because the test requires vm.flagless, but I would run it with TEST_VM_OPTS="-XX:+UnlockExperimentalVMOptions -XX:+UseFastLocking". You need to test this by having it enabled by default, otherwise you may miss many tests that either won't run (flagless) or won't pass the flags through to any exec'd VMs. ------------- PR: https://git.openjdk.org/jdk/pull/10907 From dholmes at openjdk.org Thu Jan 19 07:34:31 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 19 Jan 2023 07:34:31 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v6] In-Reply-To: References: Message-ID: <83nPGVU0MkRtftZHs_NJN_5ZOzPb6lrWUyzTdZCkRNw=.e122aa01-d981-4d9e-bb23-65aa9670ebf1@github.com> On Wed, 18 Jan 2023 19:41:11 GMT, Xue-Lei Andrew Fan wrote: >> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. >> >> This patch is trying to find the use of sprintf in hotspot iml and test cases. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > Remove FORBID_C_FUNCTION update src/hotspot/share/utilities/globalDefinitions.hpp line 191: > 189: FORBID_C_FUNCTION(char* strerror(int), "use os::strerror"); > 190: FORBID_C_FUNCTION(char* strtok(char*, const char*), "use strtok_r"); > 191: FORBID_C_FUNCTION(int vsprintf(char*, const char*, va_list), "use os::vsnprintf"); At some point we would want this and as this should be the last PR to touch hotspot code in this area then this seems like the right PR to have it in. We just need to check that it is actually working as expected. ------------- PR: https://git.openjdk.org/jdk/pull/11935 From stefank at openjdk.org Thu Jan 19 07:36:31 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 19 Jan 2023 07:36:31 GMT Subject: RFR: 8299973: Replace NULL with nullptr in share/utilities/ In-Reply-To: <2zedOytL52BSGlcMPHvfc7ykU9HFcx_1WGMzkgRo4ss=.3b4f9835-3349-4029-a8f1-9975618ead86@github.com> References: <2zedOytL52BSGlcMPHvfc7ykU9HFcx_1WGMzkgRo4ss=.3b4f9835-3349-4029-a8f1-9975618ead86@github.com> Message-ID: On Mon, 16 Jan 2023 19:22:43 GMT, Johan Sj?len wrote: > Do the conversion in the share/utilities sub-directory and all of its files. Changes requested by stefank (Reviewer). src/hotspot/share/utilities/globalDefinitions_xlc.hpp line 85: > 83: // In this case you need to copy the following defines to a position after #include > 84: #include > 85: #ifdef _LP64 This entire section seems wrong to me. Could you take a closer look at this part? ------------- PR: https://git.openjdk.org/jdk/pull/12015 From dholmes at openjdk.org Thu Jan 19 07:37:28 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 19 Jan 2023 07:37:28 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v5] In-Reply-To: References: <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com> Message-ID: On Wed, 18 Jan 2023 19:35:08 GMT, Xue-Lei Andrew Fan wrote: > This PR is mainly focus on the hotspot, except two test files for jdk management. I would suggest leaving those two management files for the serviceability PR. ------------- PR: https://git.openjdk.org/jdk/pull/11935 From dholmes at openjdk.org Thu Jan 19 07:45:36 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 19 Jan 2023 07:45:36 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v16] In-Reply-To: <_Q4DQU03y9ghePhsOBkypY4umDdG4ZWDYTwMQB879-M=.4a6bcaa3-78fd-45dc-8a7a-a63a6bba8e9c@github.com> References: <_Q4DQU03y9ghePhsOBkypY4umDdG4ZWDYTwMQB879-M=.4a6bcaa3-78fd-45dc-8a7a-a63a6bba8e9c@github.com> Message-ID: <_9HNX36UyNqea-82du1juKCEGv5T8StcAGScA-T8S-Y=.baec0d25-e7b0-495a-a840-b8d5486c569f@github.com> On Wed, 18 Jan 2023 17:17:44 GMT, Brian Burkhalter wrote: >> Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299684: Further cleanup around handling OOME (or not) test/jdk/java/nio/jni/NewDirectByteBuffer.java line 130: > 128: void illegalCapacities(long capacity) { > 129: assertThrows(IllegalArgumentException.class, () -> { > 130: long addr = UNSAFE.allocateMemory(capacity); How is `allocateMemory` going to respond to these illegal capacity requests? If we expect `newDirectByteBuffer` to throw then can't we use a dummy buffer value as it will never be used? ------------- PR: https://git.openjdk.org/jdk/pull/11873 From alanb at openjdk.org Thu Jan 19 07:56:32 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 19 Jan 2023 07:56:32 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v16] In-Reply-To: <_9HNX36UyNqea-82du1juKCEGv5T8StcAGScA-T8S-Y=.baec0d25-e7b0-495a-a840-b8d5486c569f@github.com> References: <_Q4DQU03y9ghePhsOBkypY4umDdG4ZWDYTwMQB879-M=.4a6bcaa3-78fd-45dc-8a7a-a63a6bba8e9c@github.com> <_9HNX36UyNqea-82du1juKCEGv5T8StcAGScA-T8S-Y=.baec0d25-e7b0-495a-a840-b8d5486c569f@github.com> Message-ID: On Thu, 19 Jan 2023 07:42:54 GMT, David Holmes wrote: > How is `allocateMemory` going to respond to these illegal capacity requests? > > If we expect `newDirectByteBuffer` to throw then can't we use a dummy buffer value as it will never be used? For illegalCapacities it should call allocateMemory with some fixed value, say 1, not capacity. Surprised the allocateMemory isn't failing for the test inputs. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From rehn at openjdk.org Thu Jan 19 08:24:03 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 19 Jan 2023 08:24:03 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v4] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 20:10:21 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Renaissance >> >> >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Revert UseFastLocking to default to off I always change the flags in code for the reasons David state and I can't forget to add any flags. (Test batch is stilling running, no failures except MonitorInflationTest.java) ------------- PR: https://git.openjdk.org/jdk/pull/10907 From jsjolen at openjdk.org Thu Jan 19 08:55:19 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 19 Jan 2023 08:55:19 GMT Subject: RFR: 8299973: Replace NULL with nullptr in share/utilities/ In-Reply-To: References: <2zedOytL52BSGlcMPHvfc7ykU9HFcx_1WGMzkgRo4ss=.3b4f9835-3349-4029-a8f1-9975618ead86@github.com> Message-ID: On Wed, 18 Jan 2023 22:46:43 GMT, Coleen Phillimore wrote: >> Do the conversion in the share/utilities sub-directory and all of its files. > > src/hotspot/share/utilities/globalDefinitions_visCPP.hpp line 2: > >> 1: /* >> 2: * Copyright (c) 1997, 2023, Oracle and/or its affiliates. All rights reserved. > > You updated the copyright without changing anything in this file. Thanks, I guess I reverted the changes without removing the copyright change. ------------- PR: https://git.openjdk.org/jdk/pull/12015 From jsjolen at openjdk.org Thu Jan 19 09:02:05 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 19 Jan 2023 09:02:05 GMT Subject: RFR: 8299973: Replace NULL with nullptr in share/utilities/ [v2] In-Reply-To: <2zedOytL52BSGlcMPHvfc7ykU9HFcx_1WGMzkgRo4ss=.3b4f9835-3349-4029-a8f1-9975618ead86@github.com> References: <2zedOytL52BSGlcMPHvfc7ykU9HFcx_1WGMzkgRo4ss=.3b4f9835-3349-4029-a8f1-9975618ead86@github.com> Message-ID: > Do the conversion in the share/utilities sub-directory and all of its files. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: More manual fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12015/files - new: https://git.openjdk.org/jdk/pull/12015/files/a3fec8f0..d982fae8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12015&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12015&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/12015.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12015/head:pull/12015 PR: https://git.openjdk.org/jdk/pull/12015 From jsjolen at openjdk.org Thu Jan 19 09:02:08 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 19 Jan 2023 09:02:08 GMT Subject: RFR: 8299973: Replace NULL with nullptr in share/utilities/ [v2] In-Reply-To: References: <2zedOytL52BSGlcMPHvfc7ykU9HFcx_1WGMzkgRo4ss=.3b4f9835-3349-4029-a8f1-9975618ead86@github.com> Message-ID: On Thu, 19 Jan 2023 07:31:51 GMT, Stefan Karlsson wrote: >> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: >> >> More manual fixes > > src/hotspot/share/utilities/globalDefinitions_xlc.hpp line 85: > >> 83: // In this case you need to copy the following defines to a position after #include >> 84: #include >> 85: #ifdef _LP64 > > This entire section seems wrong to me. Could you take a closer look at this part? I thought I reverted all of those! Good catch, fixed. ------------- PR: https://git.openjdk.org/jdk/pull/12015 From aph at openjdk.org Thu Jan 19 09:06:44 2023 From: aph at openjdk.org (Andrew Haley) Date: Thu, 19 Jan 2023 09:06:44 GMT Subject: RFR: 8300253: Introduce AArch64 nzcv accessors In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 07:03:39 GMT, Hao Sun wrote: >> The bits for the instructions are correct. I presume there'll be a train of patches for ZGC generational to necessitate it. > > I suggest adding one comment here. How about: > > // macro instructions for accessing and updating > // PSTATE.{N,Z,C,V} fields at EL0 > // > // NZCV: op1 = 011 > // CRn = 0100 > // CRm = 0010 > // op2 = 000 As a general rule, we don't add commentary that duplicates information in the Architecture Reference Manual. In this case, it's obvious that `MRS , NZCV` is intended, and the information above is on Page C5-689 of ARM DDI 0487H.a ------------- PR: https://git.openjdk.org/jdk/pull/12038 From jsjolen at openjdk.org Thu Jan 19 09:10:25 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 19 Jan 2023 09:10:25 GMT Subject: RFR: 8299973: Replace NULL with nullptr in share/utilities/ [v3] In-Reply-To: <2zedOytL52BSGlcMPHvfc7ykU9HFcx_1WGMzkgRo4ss=.3b4f9835-3349-4029-a8f1-9975618ead86@github.com> References: <2zedOytL52BSGlcMPHvfc7ykU9HFcx_1WGMzkgRo4ss=.3b4f9835-3349-4029-a8f1-9975618ead86@github.com> Message-ID: > Do the conversion in the share/utilities sub-directory and all of its files. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Fix incorrect copyrights, reverts change in file that was only comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12015/files - new: https://git.openjdk.org/jdk/pull/12015/files/d982fae8..992a8f6f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12015&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12015&range=01-02 Stats: 6 lines in 5 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/12015.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12015/head:pull/12015 PR: https://git.openjdk.org/jdk/pull/12015 From stefank at openjdk.org Thu Jan 19 09:10:28 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 19 Jan 2023 09:10:28 GMT Subject: RFR: 8299973: Replace NULL with nullptr in share/utilities/ [v2] In-Reply-To: References: <2zedOytL52BSGlcMPHvfc7ykU9HFcx_1WGMzkgRo4ss=.3b4f9835-3349-4029-a8f1-9975618ead86@github.com> Message-ID: On Thu, 19 Jan 2023 09:02:05 GMT, Johan Sj?len wrote: >> Do the conversion in the share/utilities sub-directory and all of its files. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > More manual fixes Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12015 From duke at openjdk.org Thu Jan 19 09:13:42 2023 From: duke at openjdk.org (Fredrik Bredberg) Date: Thu, 19 Jan 2023 09:13:42 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v5] In-Reply-To: References: Message-ID: > Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. > Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. > Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: Updated after review. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11902/files - new: https://git.openjdk.org/jdk/pull/11902/files/98354c6e..3f2a8bdd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11902&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11902&range=03-04 Stats: 12 lines in 9 files changed: 0 ins; 2 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/11902.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11902/head:pull/11902 PR: https://git.openjdk.org/jdk/pull/11902 From tschatzl at openjdk.org Thu Jan 19 09:14:39 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 19 Jan 2023 09:14:39 GMT Subject: RFR: JDK-8300260: Remove metaprogramming/isSame.hpp [v2] In-Reply-To: <0qxLrvJHTjcItIhgu7sls0aCAeLoMQSuFZjbxb4H4gg=.fda1f0af-87f2-4e22-8e05-bce5390e5c7e@github.com> References: <0qxLrvJHTjcItIhgu7sls0aCAeLoMQSuFZjbxb4H4gg=.fda1f0af-87f2-4e22-8e05-bce5390e5c7e@github.com> Message-ID: On Tue, 17 Jan 2023 16:34:05 GMT, Justin King wrote: >> Code cleanup of pre-C++11 implementations. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Revert back from std::is_void to std::is_same > > Signed-off-by: Justin King Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.org/jdk/pull/12040 From jcking at openjdk.org Thu Jan 19 09:14:46 2023 From: jcking at openjdk.org (Justin King) Date: Thu, 19 Jan 2023 09:14:46 GMT Subject: Integrated: JDK-8300264: Remove metaprogramming/isPointer.hpp In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 14:24:08 GMT, Justin King wrote: > Code cleanup of pre-C++11 implementations. This pull request has now been integrated. Changeset: eba87a0e Author: Justin King Committer: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/eba87a0ee0410f61ae764293986ecc162f48c707 Stats: 106 lines in 5 files changed: 2 ins; 95 del; 9 mod 8300264: Remove metaprogramming/isPointer.hpp Reviewed-by: kbarrett, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/12041 From dholmes at openjdk.org Thu Jan 19 09:32:44 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 19 Jan 2023 09:32:44 GMT Subject: RFR: 8299973: Replace NULL with nullptr in share/utilities/ [v3] In-Reply-To: References: <2zedOytL52BSGlcMPHvfc7ykU9HFcx_1WGMzkgRo4ss=.3b4f9835-3349-4029-a8f1-9975618ead86@github.com> Message-ID: <_XPEuXylw9M9Ru5wNS1nyIeM1R1q6Fmtu5q4kB26IdI=.ecd55329-ffce-44d5-9f4c-56c0ad8f03ed@github.com> On Thu, 19 Jan 2023 09:10:25 GMT, Johan Sj?len wrote: >> Do the conversion in the share/utilities sub-directory and all of its files. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Fix incorrect copyrights, reverts change in file that was only comment A few suggestions about nullptr -> null (only suggestions) Some unchanged files need their copyrights restored. The AIX changes need reverting. Thanks. src/hotspot/share/utilities/compilerWarnings.hpp line 2: > 1: /* > 2: * Copyright (c) 2017, 2023, Oracle and/or its affiliates. All rights reserved. No changes have been made to this file. src/hotspot/share/utilities/compilerWarnings_gcc.hpp line 2: > 1: /* > 2: * Copyright (c) 2017, 2023, Oracle and/or its affiliates. All rights reserved. No changes have been made to this file. src/hotspot/share/utilities/copy.cpp line 71: > 69: static void conjoint_swap_if_needed(const void* src, void* dst, size_t byte_count, size_t elem_size) { > 70: assert(src != nullptr, "address must not be nullptr"); > 71: assert(dst != nullptr, "address must not be nullptr"); I think "null" is more appropriate in assertion messages like this. src/hotspot/share/utilities/debug.cpp line 488: > 486: FlagSetting fl(DisplayVMOutput, true); > 487: if (p == nullptr) { > 488: tty->print_cr("nullptr"); Ditto: "null" src/hotspot/share/utilities/globalDefinitions_gcc.hpp line 142: > 140: > 141: // gcc warns about applying offsetof() to non-POD object or calculating > 142: // offset directly when base address is nullptr. The -Wno-invalid-offsetof Again I prefer "null" src/hotspot/share/utilities/globalDefinitions_xlc.hpp line 78: > 76: // Some platform/tool-chain combinations can't assign NULL to an integer > 77: // type so we define NULL_WORD to use in those contexts. For xlc they are the same. > 78: #define NULL_WORD nullptr Hmmm so maybe NULL_WORD can be retired after this change? src/hotspot/share/utilities/json.hpp line 2: > 1: /* > 2: * Copyright (c) 2015, 2023, Oracle and/or its affiliates. All rights reserved. There are no changes in this file. src/hotspot/share/utilities/linkedlist.hpp line 305: > 303: > 304: virtual bool remove_before(LinkedListNode* ref) { > 305: assert(ref != nullptr, "nullptr pointer"); null pointer (though it's a poor message anyway) src/hotspot/share/utilities/vmError.hpp line 190: > 188: DEBUG_ONLY(static void controlled_crash(int how);) > 189: > 190: // Non-nullptr address guaranteed to generate a SEGV mapping error on read, for test purposes. Non-null ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12015 From dholmes at openjdk.org Thu Jan 19 09:32:48 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 19 Jan 2023 09:32:48 GMT Subject: RFR: 8299973: Replace NULL with nullptr in share/utilities/ [v3] In-Reply-To: References: <2zedOytL52BSGlcMPHvfc7ykU9HFcx_1WGMzkgRo4ss=.3b4f9835-3349-4029-a8f1-9975618ead86@github.com> Message-ID: On Wed, 18 Jan 2023 22:44:48 GMT, Coleen Phillimore wrote: >> src/hotspot/share/utilities/debug.cpp line 425: >> >>> 423: CodeBlob* cb = CodeCache::find_blob((address)p); >>> 424: if (cb == nullptr) { >>> 425: tty->print_cr("nullptr"); >> >> Changes log, OK? > > I think it's ok. Unless we have tests that check for NULL, but they're likely in gtests and you'll find them pretty quickly and can fix them pretty quickly if they slip through. Again I think "null" is preferable in this context. ------------- PR: https://git.openjdk.org/jdk/pull/12015 From dholmes at openjdk.org Thu Jan 19 09:32:49 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 19 Jan 2023 09:32:49 GMT Subject: RFR: 8299973: Replace NULL with nullptr in share/utilities/ [v3] In-Reply-To: References: <2zedOytL52BSGlcMPHvfc7ykU9HFcx_1WGMzkgRo4ss=.3b4f9835-3349-4029-a8f1-9975618ead86@github.com> Message-ID: On Wed, 18 Jan 2023 22:14:08 GMT, Johan Sj?len wrote: >> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix incorrect copyrights, reverts change in file that was only comment > > src/hotspot/share/utilities/globalDefinitions.cpp line 162: > >> 160: static_assert((size_t)HeapWordSize >= sizeof(juint), >> 161: "HeapWord should be at least as large as juint"); >> 162: static_assert(sizeof(nullptr) == sizeof(char*), "nullptr must be same size as pointer"); > > Adding in another static_assert here so that both cases are represented. Not sure this makes any sense for `nullptr`. ------------- PR: https://git.openjdk.org/jdk/pull/12015 From dholmes at openjdk.org Thu Jan 19 09:32:53 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 19 Jan 2023 09:32:53 GMT Subject: RFR: 8299973: Replace NULL with nullptr in share/utilities/ [v3] In-Reply-To: References: <2zedOytL52BSGlcMPHvfc7ykU9HFcx_1WGMzkgRo4ss=.3b4f9835-3349-4029-a8f1-9975618ead86@github.com> Message-ID: On Thu, 19 Jan 2023 08:58:26 GMT, Johan Sj?len wrote: >> src/hotspot/share/utilities/globalDefinitions_xlc.hpp line 85: >> >>> 83: // In this case you need to copy the following defines to a position after #include >>> 84: #include >>> 85: #ifdef _LP64 >> >> This entire section seems wrong to me. Could you take a closer look at this part? > > I thought I reverted all of those! Good catch, fixed. I agree this looks like it should not be changed. ------------- PR: https://git.openjdk.org/jdk/pull/12015 From stuefe at openjdk.org Thu Jan 19 09:34:42 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 19 Jan 2023 09:34:42 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v11] In-Reply-To: References: Message-ID: <4JYaWJZ_p_b6xp0us9SZGBPyoTCz4WJO5lIN_441Yq4=.807eead7-166f-4e05-abf9-f135a5f2bc10@github.com> On Wed, 7 Dec 2022 08:40:25 GMT, Stefan Karlsson wrote: >> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: >> >> - Merge branch 'master' into JDK-8139457 >> - Fix gtest for correct base offsets in 32bit builds >> - Fix cast warning >> - Revert relaxation of array length >> - Add guards to ArrayBaseOffsets test to allow running with -UseCompressedClassPointers >> - Fix another cast warning >> - Clean cast warning from size_t to int >> - Clear leading 32bits in Z array allocator >> - SA adjustments >> - Test for 32bit build >> - ... and 15 more: https://git.openjdk.org/jdk/compare/500b45e1...c278a53b > > Changes requested by stefank (Reviewer). > Ping? @stefank @tstuefe @fisk, maybe? > > Thanks! Haven't forgotten you, but I'm snowed in atm, sorry :-( Maybe next week. Cheers, Thomas ------------- PR: https://git.openjdk.org/jdk/pull/11044 From duke at openjdk.org Thu Jan 19 09:37:44 2023 From: duke at openjdk.org (Amit Kumar) Date: Thu, 19 Jan 2023 09:37:44 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 13:33:34 GMT, Martin Doerr wrote: >>> Works on PPC64. Thanks! Tests have passed on other platforms as well. >> >> Does "other platforms" include S390? > >> > Works on PPC64. Thanks! Tests have passed on other platforms as well. >> >> Does "other platforms" include S390? > > No, @backwaterred you may want to check. Hi @TheRealMDoerr and @fbredber , I've executed tier1 & tier2 test on slow, fast and release build on s390 and test-result seems fine. But please let me know if any specific tier I need to test. I would happily do it. ------------- PR: https://git.openjdk.org/jdk/pull/11902 From jsjolen at openjdk.org Thu Jan 19 10:03:36 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 19 Jan 2023 10:03:36 GMT Subject: RFR: 8299973: Replace NULL with nullptr in share/utilities/ [v3] In-Reply-To: <_XPEuXylw9M9Ru5wNS1nyIeM1R1q6Fmtu5q4kB26IdI=.ecd55329-ffce-44d5-9f4c-56c0ad8f03ed@github.com> References: <2zedOytL52BSGlcMPHvfc7ykU9HFcx_1WGMzkgRo4ss=.3b4f9835-3349-4029-a8f1-9975618ead86@github.com> <_XPEuXylw9M9Ru5wNS1nyIeM1R1q6Fmtu5q4kB26IdI=.ecd55329-ffce-44d5-9f4c-56c0ad8f03ed@github.com> Message-ID: On Thu, 19 Jan 2023 09:29:10 GMT, David Holmes wrote: > A few suggestions about nullptr -> null (only suggestions) > > Some unchanged files need their copyrights restored. > > The AIX changes need reverting. > > Thanks. Thanks David. I agree with your suggested changes to messages, I'll apply those and send off for testing. The others I've fixed (I think you started your review while I was fixing them). ------------- PR: https://git.openjdk.org/jdk/pull/12015 From stefank at openjdk.org Thu Jan 19 10:03:38 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 19 Jan 2023 10:03:38 GMT Subject: RFR: 8299973: Replace NULL with nullptr in share/utilities/ [v3] In-Reply-To: <_XPEuXylw9M9Ru5wNS1nyIeM1R1q6Fmtu5q4kB26IdI=.ecd55329-ffce-44d5-9f4c-56c0ad8f03ed@github.com> References: <2zedOytL52BSGlcMPHvfc7ykU9HFcx_1WGMzkgRo4ss=.3b4f9835-3349-4029-a8f1-9975618ead86@github.com> <_XPEuXylw9M9Ru5wNS1nyIeM1R1q6Fmtu5q4kB26IdI=.ecd55329-ffce-44d5-9f4c-56c0ad8f03ed@github.com> Message-ID: On Thu, 19 Jan 2023 09:29:10 GMT, David Holmes wrote: >> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix incorrect copyrights, reverts change in file that was only comment > > A few suggestions about nullptr -> null (only suggestions) > > Some unchanged files need their copyrights restored. > > The AIX changes need reverting. > > Thanks. FWIW, I agree with @dholmes-ora about using the word "null" in most comments and logging. ------------- PR: https://git.openjdk.org/jdk/pull/12015 From eosterlund at openjdk.org Thu Jan 19 10:18:53 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 19 Jan 2023 10:18:53 GMT Subject: RFR: 8300253: Introduce AArch64 nzcv accessors [v2] In-Reply-To: References: Message-ID: > Some code, such as verification code, might want to run without changing the state of the system. To do that, it's useful to be able to get and set the nzcv flags. This enhancement aims at adding accessors for that. Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: Add test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12038/files - new: https://git.openjdk.org/jdk/pull/12038/files/e2e740df..6dbd9871 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12038&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12038&range=00-01 Stats: 65 lines in 1 file changed: 65 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12038.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12038/head:pull/12038 PR: https://git.openjdk.org/jdk/pull/12038 From eosterlund at openjdk.org Thu Jan 19 10:18:55 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 19 Jan 2023 10:18:55 GMT Subject: RFR: 8300253: Introduce AArch64 nzcv accessors [v2] In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 09:03:44 GMT, Andrew Haley wrote: >> I suggest adding one comment here. How about: >> >> // macro instructions for accessing and updating >> // PSTATE.{N,Z,C,V} fields at EL0 >> // >> // NZCV: op1 = 011 >> // CRn = 0100 >> // CRm = 0010 >> // op2 = 000 > > As a general rule, we don't add commentary that duplicates information in the Architecture Reference Manual. In this case, it's obvious that `MRS , NZCV` is intended, and the information above is on Page C5-689 of ARM DDI 0487H.a > OK, I'm not wild about checking in dead code, but if it's imminently needed, OK. Please add the instructions to `test/hotspot/gtest/aarch64/aarch64-asmtest.py` so they get tested.. I added mrs and msr tests for the system registers we use to aarch64-asmtest.py ------------- PR: https://git.openjdk.org/jdk/pull/12038 From jsjolen at openjdk.org Thu Jan 19 10:28:18 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 19 Jan 2023 10:28:18 GMT Subject: RFR: 8299973: Replace NULL with nullptr in share/utilities/ [v4] In-Reply-To: <2zedOytL52BSGlcMPHvfc7ykU9HFcx_1WGMzkgRo4ss=.3b4f9835-3349-4029-a8f1-9975618ead86@github.com> References: <2zedOytL52BSGlcMPHvfc7ykU9HFcx_1WGMzkgRo4ss=.3b4f9835-3349-4029-a8f1-9975618ead86@github.com> Message-ID: <4fTPAco9iqxr9IIMbwC2mmWey1mjloPSo0mZIMJVCUY=.89550071-af1a-4189-b61d-2295de0d49e3@github.com> > Do the conversion in the share/utilities sub-directory and all of its files. Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision: - Remove redundant assert - Use "null" as generic term in logs and comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12015/files - new: https://git.openjdk.org/jdk/pull/12015/files/992a8f6f..e35d240c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12015&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12015&range=02-03 Stats: 5 lines in 4 files changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/12015.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12015/head:pull/12015 PR: https://git.openjdk.org/jdk/pull/12015 From jsjolen at openjdk.org Thu Jan 19 10:28:22 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 19 Jan 2023 10:28:22 GMT Subject: RFR: 8299973: Replace NULL with nullptr in share/utilities/ [v4] In-Reply-To: References: <2zedOytL52BSGlcMPHvfc7ykU9HFcx_1WGMzkgRo4ss=.3b4f9835-3349-4029-a8f1-9975618ead86@github.com> Message-ID: On Thu, 19 Jan 2023 09:13:36 GMT, David Holmes wrote: >> src/hotspot/share/utilities/globalDefinitions.cpp line 162: >> >>> 160: static_assert((size_t)HeapWordSize >= sizeof(juint), >>> 161: "HeapWord should be at least as large as juint"); >>> 162: static_assert(sizeof(nullptr) == sizeof(char*), "nullptr must be same size as pointer"); >> >> Adding in another static_assert here so that both cases are represented. > > Not sure this makes any sense for `nullptr`. Yeah, I'm removing this static assert. ------------- PR: https://git.openjdk.org/jdk/pull/12015 From duke at openjdk.org Thu Jan 19 11:06:46 2023 From: duke at openjdk.org (Afshin Zafari) Date: Thu, 19 Jan 2023 11:06:46 GMT Subject: RFR: 8151413: os::allocation_granularity/page_size and friends return signed values Message-ID: ### Description os::allocation_granularity/page_size and friends return signed values ### Patch - Type of `vm_page_size` and `vm_allocation_granularity` members of `OSInfo` class and their wrappers in `os` class changed to `size_t` - Initial value of them changed from -1 to 0. - In setters, checking for *set only once* condition is updated accordingly (comparing with 0 instead of -1). - Equal to 0 (instead of `<= 0` ) is used to check if calling setters failed. - All `(size_t)` casting of getters removed. - In arithmetic and negation operations, the operand related to the getters casted to `(int)`. Otherwise, the Windows builds complain. - Explicitly casted to `(int)` where `jint` needed. - In ` align_up(T size, A alignment)`, assignment of variables of type `A` to type `T` (i.e., `T t = (A) a;`) should be safe. `T : size_t` and `A : int` won't compile. Fixed appropriately. - `"%d"` format-flags replaced with `SIZE_FORMAT`. - Type of `CompilerToVM::Data::vm_page_size` changed to `size_t`. ### Test tier1-5: all green, except an unrelated fail for whom a bug is already created. job-id: afshin-8151413-20230117-1255-40910454 ------------- Commit messages: - 8151413: os::allocation_granularity/page_size and friends return signed values Changes: https://git.openjdk.org/jdk/pull/12091/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12091&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8151413 Stats: 129 lines in 62 files changed: 0 ins; 0 del; 129 mod Patch: https://git.openjdk.org/jdk/pull/12091.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12091/head:pull/12091 PR: https://git.openjdk.org/jdk/pull/12091 From jsjolen at openjdk.org Thu Jan 19 11:26:21 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 19 Jan 2023 11:26:21 GMT Subject: RFR: 8299973: Replace NULL with nullptr in share/utilities/ [v4] In-Reply-To: <4fTPAco9iqxr9IIMbwC2mmWey1mjloPSo0mZIMJVCUY=.89550071-af1a-4189-b61d-2295de0d49e3@github.com> References: <2zedOytL52BSGlcMPHvfc7ykU9HFcx_1WGMzkgRo4ss=.3b4f9835-3349-4029-a8f1-9975618ead86@github.com> <4fTPAco9iqxr9IIMbwC2mmWey1mjloPSo0mZIMJVCUY=.89550071-af1a-4189-b61d-2295de0d49e3@github.com> Message-ID: On Thu, 19 Jan 2023 10:28:18 GMT, Johan Sj?len wrote: >> Do the conversion in the share/utilities sub-directory and all of its files. > > Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision: > > - Remove redundant assert > - Use "null" as generic term in logs and comments I'd appreciate a new thumbs up for this PR as I made quite a few changes. ------------- PR: https://git.openjdk.org/jdk/pull/12015 From kbarrett at openjdk.org Thu Jan 19 11:29:37 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 19 Jan 2023 11:29:37 GMT Subject: RFR: 8299973: Replace NULL with nullptr in share/utilities/ [v4] In-Reply-To: <_XPEuXylw9M9Ru5wNS1nyIeM1R1q6Fmtu5q4kB26IdI=.ecd55329-ffce-44d5-9f4c-56c0ad8f03ed@github.com> References: <2zedOytL52BSGlcMPHvfc7ykU9HFcx_1WGMzkgRo4ss=.3b4f9835-3349-4029-a8f1-9975618ead86@github.com> <_XPEuXylw9M9Ru5wNS1nyIeM1R1q6Fmtu5q4kB26IdI=.ecd55329-ffce-44d5-9f4c-56c0ad8f03ed@github.com> Message-ID: <3lfdPcuU5bM8ceru67ECEpnpHIEW67Wfl7hq1mmisEM=.6ef08045-e8c1-4687-9a17-7954a9dd4d14@github.com> On Thu, 19 Jan 2023 09:15:03 GMT, David Holmes wrote: >> Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision: >> >> - Remove redundant assert >> - Use "null" as generic term in logs and comments > > src/hotspot/share/utilities/globalDefinitions_xlc.hpp line 78: > >> 76: // Some platform/tool-chain combinations can't assign NULL to an integer >> 77: // type so we define NULL_WORD to use in those contexts. For xlc they are the same. >> 78: #define NULL_WORD nullptr > > Hmmm so maybe NULL_WORD can be retired after this change? NULL_WORD is mostly used in the x86 assembler, for overloading purposes. I've made a couple of attempts at improving it but it was messy because of NULL and the lack of a known type for it (though decltype could be used for that now). It might be easier with NULL => nullptr everywhere. There are a small number of uses of NULL_WORD elsewhere, most/all of which I think are mistakes. And I agree this ought not be changed at this time. ------------- PR: https://git.openjdk.org/jdk/pull/12015 From stefank at openjdk.org Thu Jan 19 11:30:00 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 19 Jan 2023 11:30:00 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v11] In-Reply-To: References: Message-ID: <0oSGAyFe1v4NSMKc-zmIKOm9KIchWhj7TSOf4qGpM78=.f9ea7cd7-e60f-40ae-a003-c935a5400d2f@github.com> On Fri, 13 Jan 2023 19:04:59 GMT, Roman Kennke wrote: >> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details. >> >> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements. >> >> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16. >> >> Testing: >> - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] tier1 (x86_64, x86_32, aarch64, riscv) >> - [x] tier2 (x86_64, aarch64, riscv) >> - [x] tier3 (x86_64, riscv) > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: > > - Merge branch 'master' into JDK-8139457 > - Fix gtest for correct base offsets in 32bit builds > - Fix cast warning > - Revert relaxation of array length > - Add guards to ArrayBaseOffsets test to allow running with -UseCompressedClassPointers > - Fix another cast warning > - Clean cast warning from size_t to int > - Clear leading 32bits in Z array allocator > - SA adjustments > - Test for 32bit build > - ... and 15 more: https://git.openjdk.org/jdk/compare/500b45e1...c278a53b I tried to read the code very carefully, but it's not entirely easy to review a patch like this. I think I found two bugs, and a number of things that I think could help the readability of the code. I didn't look to closely at the tests, but I think I'd like to see a test that checks the boundary conditions of the max array calculations. I'd suggest that more Reviewers take a close look at the code. src/hotspot/cpu/ppc/c1_MacroAssembler_ppc.cpp line 376: > 374: addi(base, base, BytesPerInt); > 375: // Note: initialize_body will align index down, no need to correct it here. > 376: } What do `dword` refer to here? Do you mean `word`? For if statements, I think it's good to consider if the comment describes the conditional, or what happens if the conditional is true. The comment above describes what happens if it is true, so it would be better to move it to after Line 371. Alternatively, rewrite the comment to say "Check if elements are not word aligned", and move the "Zero out leading word". Or change it two the riscv comment: `// Zero first 4 bytes, if start offset is not word aligned.` src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp line 276: > 274: Register t1, // temp register > 275: Register t2, // temp register > 276: int base_offset_in_bytes, // offset of array elements in bytes This comment is not consistent with the PPC comment: `int base_offset_in_bytes, // elements offset in bytes` src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp line 313: > 311: Register object_fields = t1; > 312: Register Rzero = Z_R1_scratch; > 313: z_aghi(arr_size, -(base_offset_in_bytes)); Maybe remove the brackets? `z_aghi(arr_size, -(base_offset_in_bytes));` src/hotspot/cpu/x86/macroAssembler_x86.cpp line 4136: > 4134: assert(is_aligned(offset_in_bytes, BytesPerInt), "offset must be a multiple of BytesPerInt"); > 4135: > 4136: // note: for the remaining code to work, index must be a multiple of BytesPerInt Maybe move the comment to above the assert that checks the invariant described by the comment? src/hotspot/cpu/x86/macroAssembler_x86.cpp line 4154: > 4152: // Emit single 32bit store to clear leading bytes, if necessary. > 4153: xorptr(temp, temp); // use _zero reg to clear memory (shorter code) > 4154: #ifdef _LP64 Since temp is used outside of the section L4152-4164, I think it would be appropriate to hoist it above the comment on 4152. src/hotspot/share/gc/shared/collectedHeap.cpp line 258: > 256: int header_size_in_bytes = arrayOopDesc::base_offset_in_bytes(T_INT); > 257: assert(is_aligned(header_size_in_bytes, BytesPerInt), "must be aligned to int"); > 258: int header_size_in_ints = header_size_in_bytes / BytesPerInt; I wonder if it would make sense to create an arrayOopDesc::base_offset_in_ints(T_INT)? src/hotspot/share/gc/shared/collectedHeap.cpp line 427: > 425: ((juint) max_jint / (size_t) HeapWordSize); > 426: return align_down(max_int_size, MinObjAlignment); > 427: } Why isn't this using `_filler_array_max_size` instead of calculating its own value? Are these two values different, and if so, why? src/hotspot/share/gc/shared/collectedHeap.cpp line 431: > 429: size_t CollectedHeap::filler_array_min_size() { > 430: size_t aligned_header_size_words = heap_word_size(arrayOopDesc::base_offset_in_bytes(T_INT)); > 431: return align_object_size(aligned_header_size_words); // align to MinObjAlignment src/hotspot/share/gc/parallel/mutableNUMASpace.cpp makes the same calculation. There might be an opportunity to extract these two calculations into a helper function. src/hotspot/share/gc/shared/collectedHeap.cpp line 444: > 442: payload_start = payload_start / HeapWordSize; > 443: Copy::fill_to_words(start + payload_start, > 444: words - payload_start, value); This mixes bytes and words. I don't think this is correct. src/hotspot/share/gc/shared/memAllocator.cpp line 427: > 425: } > 426: ArrayKlass* array_klass = ArrayKlass::cast(_klass); > 427: const size_t hs = heap_word_size(arrayOopDesc::base_offset_in_bytes(array_klass->element_type())); I don't think this makes sense. If base_offset_in_bytes return something that isn't word aligned, then `heap_word_size` will truncate the value and `hs` will less than the actual header size. This then snowballs back to the caller of `obj_memory_range`. Maybe we need change obj_memory_range to work with bytes instead of words? src/hotspot/share/gc/z/zObjArrayAllocator.cpp line 55: > 53: int base_offset = arrayOopDesc::base_offset_in_bytes(element_type); > 54: > 55: // Clear leading 32 bit, if necessary. 32 bit => 32 bits? src/hotspot/share/oops/arrayOop.hpp line 54: > 52: // sizeof(arrayOopDesc) which should not appear in the code. > 53: static int header_size_in_bytes() { > 54: size_t hs = length_offset_in_bytes() + sizeof(int); The comment above states that this returns the "aligned" value. It doesn't, so I think the comment needs to be updated. src/hotspot/share/oops/arrayOop.hpp line 96: > 94: return (int)(element_type_should_be_aligned(type) > 95: ? align_up(typesize_in_bytes, BytesPerLong) > 96: : typesize_in_bytes); I think that the name typesize is confusing here. Maybe just use a short name for this very short function. Say, `value` or `hs`? src/hotspot/share/oops/arrayOop.hpp line 141: > 139: assert(type2aelembytes(type) != 0, "wrong type"); > 140: > 141: int elem_size = type2aelembytes(type); The rest of the nearby locals seems to be declared const, so maybe follow that style here? src/hotspot/share/oops/arrayOop.hpp line 143: > 141: int elem_size = type2aelembytes(type); > 142: const size_t max_size_bytes = align_down(SIZE_MAX - base_offset_in_bytes(type), MinObjAlignmentInBytes); > 143: assert(max_size_bytes % elem_size == 0, "max_size_bytes should be aligned to element size"); Use is_aligned? src/hotspot/share/oops/arrayOop.hpp line 151: > 149: // overflowing an int when we add the header. See CRs 4718400 and 7110613. > 150: size_t header_size_words = heap_word_size(base_offset_in_bytes(type)); > 151: return align_down(max_jint - static_cast(header_size_words), MinObjAlignment); Can't immediately tell if this is correct, given that `heap_word_size` truncates the header. (Haven't checked yet if you have written unittests for this). src/hotspot/share/oops/objArrayOop.hpp line 55: > 53: private: > 54: // Give size of objArrayOop in bytes minus the header > 55: static size_t array_size_in_bytes(int length) { This is such a misleading name. I wouldn't mind getting rid of this function by inlining it into the its single call site. src/hotspot/share/opto/runtime.cpp line 316: > 314: HeapWord* obj = cast_from_oop(result); > 315: if (aligned_hs_bytes > hs_bytes) { > 316: Copy::zero_to_bytes(obj + hs_bytes, aligned_hs_bytes - hs_bytes); I think this is wrong. `obj` is a `HeapWord*` and hs_bytes is in bytes. You shouldn't be adding to a pointer with a variable holding bytes. test/hotspot/gtest/oops/test_arrayOop.cpp line 83: > 81: // T_VOID and T_ADDRESS are not supported by max_array_length() > 82: > 83: Nit: spurious newline ------------- Changes requested by stefank (Reviewer). PR: https://git.openjdk.org/jdk/pull/11044 From stefank at openjdk.org Thu Jan 19 11:43:34 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 19 Jan 2023 11:43:34 GMT Subject: RFR: 8151413: os::allocation_granularity/page_size and friends return signed values In-Reply-To: References: Message-ID: <3NiiB066CB1zaeStjXuFQNdH1ZHdiubvmNkjoWqqgLg=.49dab42f-062a-4c42-b0e2-7b36f6c55fc9@github.com> On Thu, 19 Jan 2023 10:59:02 GMT, Afshin Zafari wrote: > ### Description > os::allocation_granularity/page_size and friends return signed values > > ### Patch > - Type of `vm_page_size` and `vm_allocation_granularity` members of `OSInfo` class and their wrappers in `os` class changed to `size_t` > - Initial value of them changed from -1 to 0. > - In setters, checking for *set only once* condition is updated accordingly (comparing with 0 instead of -1). > - Equal to 0 (instead of `<= 0` ) is used to check if calling setters failed. > - All `(size_t)` casting of getters removed. > - In arithmetic and negation operations, the operand related to the getters casted to `(int)`. Otherwise, the Windows builds complain. > - Explicitly casted to `(int)` where `jint` needed. > - In ` align_up(T size, A alignment)`, assignment of variables of type `A` to type `T` (i.e., `T t = (A) a;`) should be safe. `T : size_t` and `A : int` won't compile. Fixed appropriately. > - `"%d"` format-flags replaced with `SIZE_FORMAT`. > - Type of `CompilerToVM::Data::vm_page_size` changed to `size_t`. > > ### Test > tier1-5: all green, except an unrelated fail for whom a bug is already created. > job-id: afshin-8151413-20230117-1255-40910454 I think this mostly looks good. I've one thing I'd like to get checked. src/hotspot/os/linux/os_linux.cpp line 4285: > 4283: clock_tics_per_sec = sysconf(_SC_CLK_TCK); > 4284: > 4285: size_t page_size = (size_t) sysconf(_SC_PAGESIZE); This cast voids the check for negative return values below. Maybe check this value first, then cast it to a size_t? ------------- Changes requested by stefank (Reviewer). PR: https://git.openjdk.org/jdk/pull/12091 From kbarrett at openjdk.org Thu Jan 19 11:58:58 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 19 Jan 2023 11:58:58 GMT Subject: RFR: 8299973: Replace NULL with nullptr in share/utilities/ [v4] In-Reply-To: <4fTPAco9iqxr9IIMbwC2mmWey1mjloPSo0mZIMJVCUY=.89550071-af1a-4189-b61d-2295de0d49e3@github.com> References: <2zedOytL52BSGlcMPHvfc7ykU9HFcx_1WGMzkgRo4ss=.3b4f9835-3349-4029-a8f1-9975618ead86@github.com> <4fTPAco9iqxr9IIMbwC2mmWey1mjloPSo0mZIMJVCUY=.89550071-af1a-4189-b61d-2295de0d49e3@github.com> Message-ID: On Thu, 19 Jan 2023 10:28:18 GMT, Johan Sj?len wrote: >> Do the conversion in the share/utilities sub-directory and all of its files. > > Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision: > > - Remove redundant assert > - Use "null" as generic term in logs and comments Looks good. src/hotspot/share/utilities/ostream.cpp line 759: > 757: xs->tail("launcher"); > 758: } > 759: if (Arguments::system_properties() != nullptr) { [pre-existing] Nit: extra space before nullptr. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/12015 From rkennke at openjdk.org Thu Jan 19 12:11:48 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 19 Jan 2023 12:11:48 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v4] In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 08:19:54 GMT, Robbin Ehn wrote: > I always change the flags in code for the reasons David state and I can't forget to add any flags. > > (Test batch is stilling running, no failures except MonitorInflationTest.java) Ok, right. I just re-ran tier1-3 with the flag changed in code, on aarch64 and x86_64 without regressions. Will run tier4 overnight. ------------- PR: https://git.openjdk.org/jdk/pull/10907 From rkennke at openjdk.org Thu Jan 19 12:20:26 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 19 Jan 2023 12:20:26 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v11] In-Reply-To: <0oSGAyFe1v4NSMKc-zmIKOm9KIchWhj7TSOf4qGpM78=.f9ea7cd7-e60f-40ae-a003-c935a5400d2f@github.com> References: <0oSGAyFe1v4NSMKc-zmIKOm9KIchWhj7TSOf4qGpM78=.f9ea7cd7-e60f-40ae-a003-c935a5400d2f@github.com> Message-ID: On Thu, 19 Jan 2023 10:21:10 GMT, Stefan Karlsson wrote: >> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: >> >> - Merge branch 'master' into JDK-8139457 >> - Fix gtest for correct base offsets in 32bit builds >> - Fix cast warning >> - Revert relaxation of array length >> - Add guards to ArrayBaseOffsets test to allow running with -UseCompressedClassPointers >> - Fix another cast warning >> - Clean cast warning from size_t to int >> - Clear leading 32bits in Z array allocator >> - SA adjustments >> - Test for 32bit build >> - ... and 15 more: https://git.openjdk.org/jdk/compare/500b45e1...c278a53b > > src/hotspot/cpu/x86/macroAssembler_x86.cpp line 4136: > >> 4134: assert(is_aligned(offset_in_bytes, BytesPerInt), "offset must be a multiple of BytesPerInt"); >> 4135: >> 4136: // note: for the remaining code to work, index must be a multiple of BytesPerInt > > Maybe move the comment to above the assert that checks the invariant described by the comment? I think it is. The whole block below the comment is the runtime check for the described invariant. I re-worded it to be a bit clearer: // For the remaining code to work, length must be a multiple of BytesPerInt. // Check that here. ------------- PR: https://git.openjdk.org/jdk/pull/11044 From dholmes at openjdk.org Thu Jan 19 12:42:37 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 19 Jan 2023 12:42:37 GMT Subject: RFR: 8299973: Replace NULL with nullptr in share/utilities/ [v4] In-Reply-To: <4fTPAco9iqxr9IIMbwC2mmWey1mjloPSo0mZIMJVCUY=.89550071-af1a-4189-b61d-2295de0d49e3@github.com> References: <2zedOytL52BSGlcMPHvfc7ykU9HFcx_1WGMzkgRo4ss=.3b4f9835-3349-4029-a8f1-9975618ead86@github.com> <4fTPAco9iqxr9IIMbwC2mmWey1mjloPSo0mZIMJVCUY=.89550071-af1a-4189-b61d-2295de0d49e3@github.com> Message-ID: On Thu, 19 Jan 2023 10:28:18 GMT, Johan Sj?len wrote: >> Do the conversion in the share/utilities sub-directory and all of its files. > > Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision: > > - Remove redundant assert > - Use "null" as generic term in logs and comments LGTM! Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12015 From duke at openjdk.org Thu Jan 19 12:46:42 2023 From: duke at openjdk.org (Afshin Zafari) Date: Thu, 19 Jan 2023 12:46:42 GMT Subject: RFR: 8151413: os::allocation_granularity/page_size and friends return signed values [v2] In-Reply-To: References: Message-ID: > ### Description > os::allocation_granularity/page_size and friends return signed values > > ### Patch > - Type of `vm_page_size` and `vm_allocation_granularity` members of `OSInfo` class and their wrappers in `os` class changed to `size_t` > - Initial value of them changed from -1 to 0. > - In setters, checking for *set only once* condition is updated accordingly (comparing with 0 instead of -1). Also, checking the argument be positive is removed. > - Equal to 0 (instead of `<= 0` ) is used to check if calling setters failed. > - All `(size_t)` casting of getters removed. > - In arithmetic and negation operations, the operand related to the getters casted to `(int)`. Otherwise, the Windows builds complain. > - Explicitly casted to `(int)` where `jint` needed. > - In ` align_up(T size, A alignment)`, assignment of variables of type `A` to type `T` (i.e., `T t = (A) a;`) should be safe. `T : size_t` and `A : int` won't compile. Fixed appropriately. > - `"%d"` format-flags replaced with `SIZE_FORMAT`. > - Type of `CompilerToVM::Data::vm_page_size` changed to `size_t`. > > ### Test > tier1-5: all green, except an unrelated fail for whom a bug is already created. > job-id: afshin-8151413-20230117-1255-40910454 Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: 8151413: os::allocation_granularity/page_size and friends return signed values ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12091/files - new: https://git.openjdk.org/jdk/pull/12091/files/97670c79..74c859b7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12091&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12091&range=00-01 Stats: 10 lines in 2 files changed: 4 ins; 3 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12091.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12091/head:pull/12091 PR: https://git.openjdk.org/jdk/pull/12091 From stefank at openjdk.org Thu Jan 19 13:16:02 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 19 Jan 2023 13:16:02 GMT Subject: RFR: 8151413: os::allocation_granularity/page_size and friends return signed values [v2] In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 12:46:42 GMT, Afshin Zafari wrote: >> ### Description >> os::allocation_granularity/page_size and friends return signed values >> >> ### Patch >> - Type of `vm_page_size` and `vm_allocation_granularity` members of `OSInfo` class and their wrappers in `os` class changed to `size_t` >> - Initial value of them changed from -1 to 0. >> - In setters, checking for *set only once* condition is updated accordingly (comparing with 0 instead of -1). Also, checking the argument be positive is removed. >> - Equal to 0 (instead of `<= 0` ) is used to check if calling setters failed. >> - All `(size_t)` casting of getters removed. >> - In arithmetic and negation operations, the operand related to the getters casted to `(int)`. Otherwise, the Windows builds complain. >> - Explicitly casted to `(int)` where `jint` needed. >> - In ` align_up(T size, A alignment)`, assignment of variables of type `A` to type `T` (i.e., `T t = (A) a;`) should be safe. `T : size_t` and `A : int` won't compile. Fixed appropriately. >> - `"%d"` format-flags replaced with `SIZE_FORMAT`. >> - Type of `CompilerToVM::Data::vm_page_size` changed to `size_t`. >> >> ### Test >> tier1-5: all green, except an unrelated fail for whom a bug is already created. >> job-id: afshin-8151413-20230117-1255-40910454 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8151413: os::allocation_granularity/page_size and friends return signed values Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12091 From rkennke at openjdk.org Thu Jan 19 13:17:19 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 19 Jan 2023 13:17:19 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v11] In-Reply-To: <0oSGAyFe1v4NSMKc-zmIKOm9KIchWhj7TSOf4qGpM78=.f9ea7cd7-e60f-40ae-a003-c935a5400d2f@github.com> References: <0oSGAyFe1v4NSMKc-zmIKOm9KIchWhj7TSOf4qGpM78=.f9ea7cd7-e60f-40ae-a003-c935a5400d2f@github.com> Message-ID: On Thu, 19 Jan 2023 10:43:09 GMT, Stefan Karlsson wrote: >> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: >> >> - Merge branch 'master' into JDK-8139457 >> - Fix gtest for correct base offsets in 32bit builds >> - Fix cast warning >> - Revert relaxation of array length >> - Add guards to ArrayBaseOffsets test to allow running with -UseCompressedClassPointers >> - Fix another cast warning >> - Clean cast warning from size_t to int >> - Clear leading 32bits in Z array allocator >> - SA adjustments >> - Test for 32bit build >> - ... and 15 more: https://git.openjdk.org/jdk/compare/500b45e1...c278a53b > > src/hotspot/share/gc/shared/collectedHeap.cpp line 444: > >> 442: payload_start = payload_start / HeapWordSize; >> 443: Copy::fill_to_words(start + payload_start, >> 444: words - payload_start, value); > > This mixes bytes and words. I don't think this is correct. How does it mix bytes and words? start is a heapword*, payload_start is in word units (I am going to change the line above to make it clearer, words is words ;-). ------------- PR: https://git.openjdk.org/jdk/pull/11044 From stefank at openjdk.org Thu Jan 19 13:18:17 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 19 Jan 2023 13:18:17 GMT Subject: RFR: 8299973: Replace NULL with nullptr in share/utilities/ [v4] In-Reply-To: <4fTPAco9iqxr9IIMbwC2mmWey1mjloPSo0mZIMJVCUY=.89550071-af1a-4189-b61d-2295de0d49e3@github.com> References: <2zedOytL52BSGlcMPHvfc7ykU9HFcx_1WGMzkgRo4ss=.3b4f9835-3349-4029-a8f1-9975618ead86@github.com> <4fTPAco9iqxr9IIMbwC2mmWey1mjloPSo0mZIMJVCUY=.89550071-af1a-4189-b61d-2295de0d49e3@github.com> Message-ID: On Thu, 19 Jan 2023 10:28:18 GMT, Johan Sj?len wrote: >> Do the conversion in the share/utilities sub-directory and all of its files. > > Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision: > > - Remove redundant assert > - Use "null" as generic term in logs and comments Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12015 From rkennke at openjdk.org Thu Jan 19 13:23:00 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 19 Jan 2023 13:23:00 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v11] In-Reply-To: <0oSGAyFe1v4NSMKc-zmIKOm9KIchWhj7TSOf4qGpM78=.f9ea7cd7-e60f-40ae-a003-c935a5400d2f@github.com> References: <0oSGAyFe1v4NSMKc-zmIKOm9KIchWhj7TSOf4qGpM78=.f9ea7cd7-e60f-40ae-a003-c935a5400d2f@github.com> Message-ID: On Thu, 19 Jan 2023 10:48:52 GMT, Stefan Karlsson wrote: >> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: >> >> - Merge branch 'master' into JDK-8139457 >> - Fix gtest for correct base offsets in 32bit builds >> - Fix cast warning >> - Revert relaxation of array length >> - Add guards to ArrayBaseOffsets test to allow running with -UseCompressedClassPointers >> - Fix another cast warning >> - Clean cast warning from size_t to int >> - Clear leading 32bits in Z array allocator >> - SA adjustments >> - Test for 32bit build >> - ... and 15 more: https://git.openjdk.org/jdk/compare/500b45e1...c278a53b > > src/hotspot/share/gc/shared/memAllocator.cpp line 427: > >> 425: } >> 426: ArrayKlass* array_klass = ArrayKlass::cast(_klass); >> 427: const size_t hs = heap_word_size(arrayOopDesc::base_offset_in_bytes(array_klass->element_type())); > > I don't think this makes sense. If base_offset_in_bytes return something that isn't word aligned, then `heap_word_size` will truncate the value and `hs` will less than the actual header size. This then snowballs back to the caller of `obj_memory_range`. Maybe we need change obj_memory_range to work with bytes instead of words? I think that heap_word_size() aligns up: inline size_t heap_word_size(size_t byte_size) { return (byte_size + (HeapWordSize-1)) >> LogHeapWordSize; } which makes obj_memory_range() ok as it is? I agree that it is not great, but it seems to be used only by check_for_bad_heap_word_value(), and for that purpose it is ok? Not 100% sure. ------------- PR: https://git.openjdk.org/jdk/pull/11044 From duke at openjdk.org Thu Jan 19 13:26:15 2023 From: duke at openjdk.org (Fredrik Bredberg) Date: Thu, 19 Jan 2023 13:26:15 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 13:33:34 GMT, Martin Doerr wrote: >>> Works on PPC64. Thanks! Tests have passed on other platforms as well. >> >> Does "other platforms" include S390? > >> > Works on PPC64. Thanks! Tests have passed on other platforms as well. >> >> Does "other platforms" include S390? > > No, @backwaterred you may want to check. > Hi @TheRealMDoerr and @fbredber , I've executed tier1 & tier2 test on slow, fast and release build on s390 and test-result seems fine. But please let me know if any specific tier I need to test. I would happily do it. Since I haven't done any major change in s390, I think it's good enough to know that it passes tier1-tier2. Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/11902 From stefank at openjdk.org Thu Jan 19 13:36:25 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 19 Jan 2023 13:36:25 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v11] In-Reply-To: References: <0oSGAyFe1v4NSMKc-zmIKOm9KIchWhj7TSOf4qGpM78=.f9ea7cd7-e60f-40ae-a003-c935a5400d2f@github.com> Message-ID: On Thu, 19 Jan 2023 12:17:15 GMT, Roman Kennke wrote: >> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 4136: >> >>> 4134: assert(is_aligned(offset_in_bytes, BytesPerInt), "offset must be a multiple of BytesPerInt"); >>> 4135: >>> 4136: // note: for the remaining code to work, index must be a multiple of BytesPerInt >> >> Maybe move the comment to above the assert that checks the invariant described by the comment? > > I think it is. The whole block below the comment is the runtime check for the described invariant. I re-worded it to be a bit clearer: > // For the remaining code to work, length must be a multiple of BytesPerInt. > // Check that here. OK. Makes sense. >> src/hotspot/share/gc/shared/collectedHeap.cpp line 444: >> >>> 442: payload_start = payload_start / HeapWordSize; >>> 443: Copy::fill_to_words(start + payload_start, >>> 444: words - payload_start, value); >> >> This mixes bytes and words. I don't think this is correct. > > How does it mix bytes and words? start is a heapword*, payload_start is in word units (I am going to change the line above to make it clearer, words is words ;-). Oh, I see now, you reassigned the variable that used to contain a value in bytes to contain a value in words. How evil. I'd prefer if never do things like that in HotSpot. Could this be split into two variables? >> src/hotspot/share/gc/shared/memAllocator.cpp line 427: >> >>> 425: } >>> 426: ArrayKlass* array_klass = ArrayKlass::cast(_klass); >>> 427: const size_t hs = heap_word_size(arrayOopDesc::base_offset_in_bytes(array_klass->element_type())); >> >> I don't think this makes sense. If base_offset_in_bytes return something that isn't word aligned, then `heap_word_size` will truncate the value and `hs` will less than the actual header size. This then snowballs back to the caller of `obj_memory_range`. Maybe we need change obj_memory_range to work with bytes instead of words? > > I think that heap_word_size() aligns up: > inline size_t heap_word_size(size_t byte_size) { > return (byte_size + (HeapWordSize-1)) >> LogHeapWordSize; > } > which makes obj_memory_range() ok as it is? I agree that it is not great, but it seems to be used only by check_for_bad_heap_word_value(), and for that purpose it is ok? Not 100% sure. You are right that it aligns up. I agree that it's not 100% clear that check_for_bad_heap_word_value is correct. ------------- PR: https://git.openjdk.org/jdk/pull/11044 From stefank at openjdk.org Thu Jan 19 13:36:35 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 19 Jan 2023 13:36:35 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v11] In-Reply-To: <0oSGAyFe1v4NSMKc-zmIKOm9KIchWhj7TSOf4qGpM78=.f9ea7cd7-e60f-40ae-a003-c935a5400d2f@github.com> References: <0oSGAyFe1v4NSMKc-zmIKOm9KIchWhj7TSOf4qGpM78=.f9ea7cd7-e60f-40ae-a003-c935a5400d2f@github.com> Message-ID: On Thu, 19 Jan 2023 11:05:33 GMT, Stefan Karlsson wrote: >> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: >> >> - Merge branch 'master' into JDK-8139457 >> - Fix gtest for correct base offsets in 32bit builds >> - Fix cast warning >> - Revert relaxation of array length >> - Add guards to ArrayBaseOffsets test to allow running with -UseCompressedClassPointers >> - Fix another cast warning >> - Clean cast warning from size_t to int >> - Clear leading 32bits in Z array allocator >> - SA adjustments >> - Test for 32bit build >> - ... and 15 more: https://git.openjdk.org/jdk/compare/500b45e1...c278a53b > > src/hotspot/share/oops/arrayOop.hpp line 151: > >> 149: // overflowing an int when we add the header. See CRs 4718400 and 7110613. >> 150: size_t header_size_words = heap_word_size(base_offset_in_bytes(type)); >> 151: return align_down(max_jint - static_cast(header_size_words), MinObjAlignment); > > Can't immediately tell if this is correct, given that `heap_word_size` truncates the header. (Haven't checked yet if you have written unittests for this). Strike this comment. heap_word_size doesn't truncate but instead align up. ------------- PR: https://git.openjdk.org/jdk/pull/11044 From rkennke at openjdk.org Thu Jan 19 13:36:38 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 19 Jan 2023 13:36:38 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v11] In-Reply-To: <0oSGAyFe1v4NSMKc-zmIKOm9KIchWhj7TSOf4qGpM78=.f9ea7cd7-e60f-40ae-a003-c935a5400d2f@github.com> References: <0oSGAyFe1v4NSMKc-zmIKOm9KIchWhj7TSOf4qGpM78=.f9ea7cd7-e60f-40ae-a003-c935a5400d2f@github.com> Message-ID: On Thu, 19 Jan 2023 11:14:48 GMT, Stefan Karlsson wrote: >> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: >> >> - Merge branch 'master' into JDK-8139457 >> - Fix gtest for correct base offsets in 32bit builds >> - Fix cast warning >> - Revert relaxation of array length >> - Add guards to ArrayBaseOffsets test to allow running with -UseCompressedClassPointers >> - Fix another cast warning >> - Clean cast warning from size_t to int >> - Clear leading 32bits in Z array allocator >> - SA adjustments >> - Test for 32bit build >> - ... and 15 more: https://git.openjdk.org/jdk/compare/500b45e1...c278a53b > > src/hotspot/share/opto/runtime.cpp line 316: > >> 314: HeapWord* obj = cast_from_oop(result); >> 315: if (aligned_hs_bytes > hs_bytes) { >> 316: Copy::zero_to_bytes(obj + hs_bytes, aligned_hs_bytes - hs_bytes); > > I think this is wrong. `obj` is a `HeapWord*` and hs_bytes is in bytes. You shouldn't be adding to a pointer with a variable holding bytes. Ugh, right. Good find. I have rewritten that code to be a little clearer. ------------- PR: https://git.openjdk.org/jdk/pull/11044 From rkennke at openjdk.org Thu Jan 19 13:46:20 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 19 Jan 2023 13:46:20 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v12] In-Reply-To: References: Message-ID: > See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details. > > Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements. > > Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16. > > Testing: > - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390) > - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390) > - [x] tier1 (x86_64, x86_32, aarch64, riscv) > - [x] tier2 (x86_64, aarch64, riscv) > - [x] tier3 (x86_64, riscv) Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Several fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11044/files - new: https://git.openjdk.org/jdk/pull/11044/files/c278a53b..b6168df4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=10-11 Stats: 63 lines in 10 files changed: 12 ins; 25 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/11044.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11044/head:pull/11044 PR: https://git.openjdk.org/jdk/pull/11044 From jsjolen at openjdk.org Thu Jan 19 13:46:26 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 19 Jan 2023 13:46:26 GMT Subject: Integrated: 8299973: Replace NULL with nullptr in share/utilities/ In-Reply-To: <2zedOytL52BSGlcMPHvfc7ykU9HFcx_1WGMzkgRo4ss=.3b4f9835-3349-4029-a8f1-9975618ead86@github.com> References: <2zedOytL52BSGlcMPHvfc7ykU9HFcx_1WGMzkgRo4ss=.3b4f9835-3349-4029-a8f1-9975618ead86@github.com> Message-ID: On Mon, 16 Jan 2023 19:22:43 GMT, Johan Sj?len wrote: > Do the conversion in the share/utilities sub-directory and all of its files. This pull request has now been integrated. Changeset: 1084fd24 Author: Johan Sj?len URL: https://git.openjdk.org/jdk/commit/1084fd24eb118d4131538c2a3ead714db7d0357b Stats: 563 lines in 53 files changed: 0 ins; 0 del; 563 mod 8299973: Replace NULL with nullptr in share/utilities/ Reviewed-by: coleenp, stefank, dholmes, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/12015 From jsjolen at openjdk.org Thu Jan 19 13:46:58 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 19 Jan 2023 13:46:58 GMT Subject: RFR: JDK-8300651: Replace NULL with nullptr in share/runtime/ Message-ID: Do the conversion in the share/runtime/ sub-directory and all of its files. ------------- Commit messages: - More manual fixes - fixes - Fixes - Replace NULL with nullptr in share/runtime/ Changes: https://git.openjdk.org/jdk/pull/12094/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12094&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300651 Stats: 2071 lines in 112 files changed: 0 ins; 0 del; 2071 mod Patch: https://git.openjdk.org/jdk/pull/12094.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12094/head:pull/12094 PR: https://git.openjdk.org/jdk/pull/12094 From stefank at openjdk.org Thu Jan 19 13:54:05 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 19 Jan 2023 13:54:05 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v3] In-Reply-To: References: Message-ID: <7-tBgZjoAf7cGGztx_Pi9U-u0yj60uvowstbv64Z9B4=.bfdfcffa-4136-40e3-831c-7ccaf42ab82c@github.com> > The JfrVFrameStream is used while generating stack traces for events. One of the events are the ZPage allocation event. This event is sometimes sent when ZGC is relocating. The current implementation of JfrVFrameStream uses WalkContinuation::include, which causes JFR to walk the continuation and perform GC barriers. This is problematic, since ZGC has a requirement that we never perform load barriers while running the relocation code. If we do, we might end up performing other reloctions from the the relocation code, and in some cases that causes dead locks. > > I propose that JFR doesn't walk the continuations when sending events. An alternative could be to limit this to ZGC, but I'd like to get some feedback around that from JFR / Loom devs. > > We've been testing this patch in the Generational ZGC repository. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Review comment from Markus ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11586/files - new: https://git.openjdk.org/jdk/pull/11586/files/9fe191e2..b6b504e3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11586&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11586&range=01-02 Stats: 15 lines in 1 file changed: 10 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11586.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11586/head:pull/11586 PR: https://git.openjdk.org/jdk/pull/11586 From mgronlun at openjdk.org Thu Jan 19 13:54:07 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 19 Jan 2023 13:54:07 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v3] In-Reply-To: <7-tBgZjoAf7cGGztx_Pi9U-u0yj60uvowstbv64Z9B4=.bfdfcffa-4136-40e3-831c-7ccaf42ab82c@github.com> References: <7-tBgZjoAf7cGGztx_Pi9U-u0yj60uvowstbv64Z9B4=.bfdfcffa-4136-40e3-831c-7ccaf42ab82c@github.com> Message-ID: On Thu, 19 Jan 2023 13:49:56 GMT, Stefan Karlsson wrote: >> The JfrVFrameStream is used while generating stack traces for events. One of the events are the ZPage allocation event. This event is sometimes sent when ZGC is relocating. The current implementation of JfrVFrameStream uses WalkContinuation::include, which causes JFR to walk the continuation and perform GC barriers. This is problematic, since ZGC has a requirement that we never perform load barriers while running the relocation code. If we do, we might end up performing other reloctions from the the relocation code, and in some cases that causes dead locks. >> >> I propose that JFR doesn't walk the continuations when sending events. An alternative could be to limit this to ZGC, but I'd like to get some feedback around that from JFR / Loom devs. >> >> We've been testing this patch in the Generational ZGC repository. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Review comment from Markus Looks good! ------------- Marked as reviewed by mgronlun (Reviewer). PR: https://git.openjdk.org/jdk/pull/11586 From stefank at openjdk.org Thu Jan 19 13:54:08 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 19 Jan 2023 13:54:08 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v2] In-Reply-To: References: Message-ID: <4IemKvfr85lq7JV8T1UP-uTCbFqK84Dtu3o9yzavx7Q=.d1e82e96-4c68-497d-ba37-66b456333cce@github.com> On Wed, 18 Jan 2023 13:00:46 GMT, Markus Gr?nlund wrote: >>> > > Question: does the "start_processing()" call ever reach a malloc, directly or indirectly? If so, it is problematic to call from the sampler thread. >>> > >>> > >>> > It does allocate a stack iterator with malloc if it really did need to start processing and it was not yet started. So yes. Would you mind explaining why using malloc is problematic? >>> >>> The problem is that the suspendee can be holding the malloc lock. Please see https://bugs.openjdk.org/browse/JDK-8274298 for an example situation. >> >> Right - that makes sense. But I thought the processing is poked here before we suspend the target thread? Or did I read the code wrong? > >> > > > Question: does the "start_processing()" call ever reach a malloc, directly or indirectly? If so, it is problematic to call from the sampler thread. >> > > >> > > >> > > It does allocate a stack iterator with malloc if it really did need to start processing and it was not yet started. So yes. Would you mind explaining why using malloc is problematic? >> > >> > >> > The problem is that the suspendee can be holding the malloc lock. Please see https://bugs.openjdk.org/browse/JDK-8274298 for an example situation. >> >> Right - that makes sense. But I thought the processing is poked here before we suspend the target thread? Or did I read the code wrong? > > Ah. The call is now located before the suspend is attempted. That is good from a sampling perspective. Is it mt safe to call start_processing() on another running thread? @mgronlun Like this? ------------- PR: https://git.openjdk.org/jdk/pull/11586 From stefank at openjdk.org Thu Jan 19 13:54:12 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 19 Jan 2023 13:54:12 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v2] In-Reply-To: References: Message-ID: <3l_Z6ra5ps09TRSQeeiINQ_WKF7pLvcdYXvd_QjIadY=.e2415fe9-bc6e-4aa7-ab08-b418a7474b2b@github.com> On Wed, 18 Jan 2023 09:24:14 GMT, Stefan Karlsson wrote: >> The JfrVFrameStream is used while generating stack traces for events. One of the events are the ZPage allocation event. This event is sometimes sent when ZGC is relocating. The current implementation of JfrVFrameStream uses WalkContinuation::include, which causes JFR to walk the continuation and perform GC barriers. This is problematic, since ZGC has a requirement that we never perform load barriers while running the relocation code. If we do, we might end up performing other reloctions from the the relocation code, and in some cases that causes dead locks. >> >> I propose that JFR doesn't walk the continuations when sending events. An alternative could be to limit this to ZGC, but I'd like to get some feedback around that from JFR / Loom devs. >> >> We've been testing this patch in the Generational ZGC repository. > > Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into 8298377_zgc_jfr_loom_deadlock > - Start stack watermark processing from JFR async profiler > - Only skip if stack watermark processing has not started > - Merge remote-tracking branch 'upstream/master' into 8298377_zgc_jfr_loom_deadlock > - 8298377: JfrVframeStream causes deadlocks in ZGC Thanks for the review! ------------- PR: https://git.openjdk.org/jdk/pull/11586 From stefank at openjdk.org Thu Jan 19 13:54:16 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 19 Jan 2023 13:54:16 GMT Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 15:03:34 GMT, Markus Gr?nlund wrote: >> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp line 393: >> >>> 391: // stack walk over Loom continuations. The stack walking code will otherwise >>> 392: // skip frames in stack chunks on the Java heap. >>> 393: StackWatermarkSet::start_processing(thread, StackWatermarkKind::gc); >> >> Maybe this should be moved to under each thread_state_in_java() and thread_state_in_native() preliminary check, see below. That way we only call on threads that we will eventually attempt to suspend. > > Just stick it into each of JfrThreadSampleClosure::sample_thread_in_java() and JfrThreadSampleClosure::sample_thread_in_native() member functions, Pushed a commit. Could you check it? ------------- PR: https://git.openjdk.org/jdk/pull/11586 From stefank at openjdk.org Thu Jan 19 13:54:17 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 19 Jan 2023 13:54:17 GMT Subject: Integrated: 8298377: JfrVframeStream causes deadlocks in ZGC In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 11:23:57 GMT, Stefan Karlsson wrote: > The JfrVFrameStream is used while generating stack traces for events. One of the events are the ZPage allocation event. This event is sometimes sent when ZGC is relocating. The current implementation of JfrVFrameStream uses WalkContinuation::include, which causes JFR to walk the continuation and perform GC barriers. This is problematic, since ZGC has a requirement that we never perform load barriers while running the relocation code. If we do, we might end up performing other reloctions from the the relocation code, and in some cases that causes dead locks. > > I propose that JFR doesn't walk the continuations when sending events. An alternative could be to limit this to ZGC, but I'd like to get some feedback around that from JFR / Loom devs. > > We've been testing this patch in the Generational ZGC repository. This pull request has now been integrated. Changeset: 453dbd12 Author: Stefan Karlsson URL: https://git.openjdk.org/jdk/commit/453dbd12ee42731d7ebfd1a856338099429277c8 Stats: 24 lines in 2 files changed: 23 ins; 0 del; 1 mod 8298377: JfrVframeStream causes deadlocks in ZGC Co-authored-by: Erik ?sterlund Reviewed-by: eosterlund, mgronlun ------------- PR: https://git.openjdk.org/jdk/pull/11586 From stefank at openjdk.org Thu Jan 19 13:59:28 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 19 Jan 2023 13:59:28 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v12] In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 13:46:20 GMT, Roman Kennke wrote: >> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details. >> >> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements. >> >> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16. >> >> Testing: >> - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] tier1 (x86_64, x86_32, aarch64, riscv) >> - [x] tier2 (x86_64, aarch64, riscv) >> - [x] tier3 (x86_64, riscv) > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Several fixes src/hotspot/share/opto/runtime.cpp line 315: > 313: HeapWord* obj = cast_from_oop(result); > 314: if (!is_aligned(hs_bytes, HeapWordSize)) { > 315: *reinterpret_cast(reinterpret_cast(obj + hs_bytes)) = 0; This seems be adding a value in bytes to a HeapWord*. Shouldn't it be `reinterpret_cast(obj) + hs_bytes`? ------------- PR: https://git.openjdk.org/jdk/pull/11044 From sgehwolf at openjdk.org Thu Jan 19 14:05:48 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 19 Jan 2023 14:05:48 GMT Subject: RFR: 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values Message-ID: Please review this refactoring of a container test. It now uses WhiteBox to retrieve the host values it asserts for. In terms of functionality this is basically a no-op except for the now more precise assertion on systems with swap accounting disabled at the kernel level. *Testing* - [x] Container tests on Linux x86_64 cgv1 and cgv2 - [x] Container tests on Linux x86_64 cgv1 and cgv2 on systems with swapaccount=0 - [ ] GHA in progress Thoughts? ------------- Commit messages: - 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values Changes: https://git.openjdk.org/jdk/pull/12097/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12097&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300659 Stats: 44 lines in 3 files changed: 27 ins; 1 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/12097.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12097/head:pull/12097 PR: https://git.openjdk.org/jdk/pull/12097 From rkennke at openjdk.org Thu Jan 19 15:56:48 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 19 Jan 2023 15:56:48 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v13] In-Reply-To: References: Message-ID: > See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details. > > Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements. > > Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16. > > Testing: > - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390) > - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390) > - [x] tier1 (x86_64, x86_32, aarch64, riscv) > - [x] tier2 (x86_64, aarch64, riscv) > - [x] tier3 (x86_64, riscv) Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11044/files - new: https://git.openjdk.org/jdk/pull/11044/files/b6168df4..85317ab5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=11-12 Stats: 7 lines in 2 files changed: 3 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11044.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11044/head:pull/11044 PR: https://git.openjdk.org/jdk/pull/11044 From rkennke at openjdk.org Thu Jan 19 15:56:55 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 19 Jan 2023 15:56:55 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v12] In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 13:56:16 GMT, Stefan Karlsson wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Several fixes > > src/hotspot/share/opto/runtime.cpp line 315: > >> 313: HeapWord* obj = cast_from_oop(result); >> 314: if (!is_aligned(hs_bytes, HeapWordSize)) { >> 315: *reinterpret_cast(reinterpret_cast(obj + hs_bytes)) = 0; > > This seems be adding a value in bytes to a HeapWord*. Shouldn't it be `reinterpret_cast(obj) + hs_bytes`? Duh. Yes, indeed. Fixed in follow-up commit. Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/11044 From jcking at openjdk.org Thu Jan 19 17:15:41 2023 From: jcking at openjdk.org (Justin King) Date: Thu, 19 Jan 2023 17:15:41 GMT Subject: RFR: JDK-8300260: Remove metaprogramming/isSame.hpp [v3] In-Reply-To: References: Message-ID: > Code cleanup of pre-C++11 implementations. Justin King has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' into remove-is-same - Revert back from std::is_void to std::is_same Signed-off-by: Justin King - Remove metaprogramming/isSame.hpp Signed-off-by: Justin King ------------- Changes: https://git.openjdk.org/jdk/pull/12040/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12040&range=02 Stats: 111 lines in 7 files changed: 2 ins; 93 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/12040.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12040/head:pull/12040 PR: https://git.openjdk.org/jdk/pull/12040 From kvn at openjdk.org Thu Jan 19 17:18:20 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 19 Jan 2023 17:18:20 GMT Subject: RFR: JDK-8300584: Accelerate AVX-512 CRC32C for small buffers [v2] In-Reply-To: References: Message-ID: <6zLnJtdFeq5VIiYVy2e6fnsgLk4lKa5N2nkx2L45nak=.4f8a9401-266a-45e2-b7bb-b7f8f40a733e@github.com> On Wed, 18 Jan 2023 23:10:12 GMT, Scott Gibbons wrote: >> Use AVX2 code for CRC32C for small buffers in the AVX-512 path. Breakeven buffer size between the two algorithms is on the order of 384 bytes. >> >> **Performance numbers for previous:** >> >> Benchmark (count) Mode Cnt Score Error Units >> TestCRC32C.testCRC32CUpdate 64 thrpt 4 66974.957 ? 8.872 ops/ms >> TestCRC32C.testCRC32CUpdate 128 thrpt 4 44224.810 ? 11.801 ops/ms >> TestCRC32C.testCRC32CUpdate 256 thrpt 4 63997.611 ? 173.577 ops/ms >> TestCRC32C.testCRC32CUpdate 512 thrpt 4 56068.683 ? 269.582 ops/ms >> TestCRC32C.testCRC32CUpdate 2048 thrpt 4 27048.098 ? 87.350 ops/ms >> TestCRC32C.testCRC32CUpdate 16384 thrpt 4 4066.736 ? 10.318 ops/ms >> TestCRC32C.testCRC32CUpdate 65536 thrpt 4 1040.754 ? 6.419 ops/ms >> >> >> **Performance numbers for this version:** >> >> Benchmark (count) Mode Cnt Score Error Units >> TestCRC32C.testCRC32CUpdate 64 thrpt 3 161659.326 ? 74.974 ops/ms >> TestCRC32C.testCRC32CUpdate 128 thrpt 3 88456.935 ? 11.940 ops/ms >> TestCRC32C.testCRC32CUpdate 256 thrpt 3 73254.993 ? 5.004 ops/ms >> TestCRC32C.testCRC32CUpdate 512 thrpt 3 56508.541 ? 298.229 ops/ms >> TestCRC32C.testCRC32CUpdate 2048 thrpt 3 26701.995 ? 31.369 ops/ms >> TestCRC32C.testCRC32CUpdate 16384 thrpt 3 4110.819 ? 4.618 ops/ms >> TestCRC32C.testCRC32CUpdate 65536 thrpt 3 1045.821 ? 2.037 ops/ms > > Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Incorporate review comments My testing passed. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/12079 From jcking at openjdk.org Thu Jan 19 17:23:19 2023 From: jcking at openjdk.org (Justin King) Date: Thu, 19 Jan 2023 17:23:19 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v10] In-Reply-To: References: Message-ID: <1tLJ8wDSBDX9Zq3UYPG8ssYO2-FH2QrErn8DF4X6f9o=.7ce4c592-f973-41c1-9ce2-8acd3f5ed6e7@github.com> > Remove abstraction that is a holdover from Solaris. Direct usages of `MmapArrayAllocator` have been switched to normal `malloc`. The justification is that none of the code paths are called from signal handlers, so using `mmap` directly does not make sense and is potentially slower than going through `malloc` which can potentially re-use memory without making any system calls. The remaining usages of `ArrayAllocator` and `MallocArrayAllocator` are equivalent. Justin King has updated the pull request incrementally with one additional commit since the last revision: Do not pass nullptr to os::release_memory Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11931/files - new: https://git.openjdk.org/jdk/pull/11931/files/4b5ce84b..de7d3ab6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=08-09 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11931.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11931/head:pull/11931 PR: https://git.openjdk.org/jdk/pull/11931 From sgehwolf at openjdk.org Thu Jan 19 17:24:57 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 19 Jan 2023 17:24:57 GMT Subject: RFR: 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values [v2] In-Reply-To: References: Message-ID: > Please review this refactoring of a container test. It now uses WhiteBox to retrieve the host values it asserts for. In terms of functionality this is basically a no-op except for the now more precise assertion on systems with swap accounting disabled at the kernel level. > > *Testing* > - [x] Container tests on Linux x86_64 cgv1 and cgv2 > - [x] Container tests on Linux x86_64 cgv1 and cgv2 on systems with swapaccount=0 > - [ ] GHA in progress > > Thoughts? Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values ------------- Changes: https://git.openjdk.org/jdk/pull/12097/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12097&range=01 Stats: 44 lines in 3 files changed: 27 ins; 1 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/12097.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12097/head:pull/12097 PR: https://git.openjdk.org/jdk/pull/12097 From jcking at openjdk.org Thu Jan 19 17:44:24 2023 From: jcking at openjdk.org (Justin King) Date: Thu, 19 Jan 2023 17:44:24 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v7] In-Reply-To: References: Message-ID: <6YyCx_tBArtnIrd5KMSoDN5EbeaUiqP0ndX_UgUmhzk=.8f727199-8b3b-48e0-a01e-a34c00889c32@github.com> On Thu, 12 Jan 2023 07:32:24 GMT, Stefan Karlsson wrote: > There's a FIXME about that allocation.inline.hpp file is now empty. Will you remove it in this patch? I'd prefer if you did. Alternatively, remove the FIXME from this patch and then immediately clean this up as a separate patch. Yeah, separate patch immediately after is probably best. Trying to avoid having to mass update includes and enter merge conflict hell for this patch. After is easier. ------------- PR: https://git.openjdk.org/jdk/pull/11931 From jsjolen at openjdk.org Thu Jan 19 18:11:49 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 19 Jan 2023 18:11:49 GMT Subject: RFR: JDK-8300651: Replace NULL with nullptr in share/runtime/ In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 12:27:23 GMT, Johan Sj?len wrote: > Do the conversion in the share/runtime/ sub-directory and all of its files. Seems like uploading the GHA results are failing. ------------- PR: https://git.openjdk.org/jdk/pull/12094 From xuelei at openjdk.org Thu Jan 19 18:54:08 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Thu, 19 Jan 2023 18:54:08 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v8] In-Reply-To: References: Message-ID: > The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. > > This patch is trying to find the use of sprintf in hotspot iml and test cases. Xue-Lei Andrew Fan has updated the pull request incrementally with two additional commits since the last revision: - remove serviceability update and add back forbid of sprintf - remove serviceability update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11935/files - new: https://git.openjdk.org/jdk/pull/11935/files/62589ae5..ec0bb486 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=06-07 Stats: 9 lines in 3 files changed: 1 ins; 2 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/11935.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11935/head:pull/11935 PR: https://git.openjdk.org/jdk/pull/11935 From duke at openjdk.org Thu Jan 19 19:00:30 2023 From: duke at openjdk.org (Afshin Zafari) Date: Thu, 19 Jan 2023 19:00:30 GMT Subject: RFR: 8151413: os::allocation_granularity/page_size and friends return signed values [v3] In-Reply-To: References: Message-ID: <5ZV3GHTMWBLxQ1UHVC3hT4rhjMx2clU_QbaPFORdTSM=.8ac9810a-48e8-4639-8616-b5ce7f340f17@github.com> > ### Description > os::allocation_granularity/page_size and friends return signed values > > ### Patch > - Type of `vm_page_size` and `vm_allocation_granularity` members of `OSInfo` class and their wrappers in `os` class changed to `size_t` > - Initial value of them changed from -1 to 0. > - In setters, checking for *set only once* condition is updated accordingly (comparing with 0 instead of -1). Also, checking the argument be positive is removed. > - Equal to 0 (instead of `<= 0` ) is used to check if calling setters failed. > - All `(size_t)` casting of getters removed. > - In arithmetic and negation operations, the operand related to the getters casted to `(int)`. Otherwise, the Windows builds complain. > - Explicitly casted to `(int)` where `jint` needed. > - In ` align_up(T size, A alignment)`, assignment of variables of type `A` to type `T` (i.e., `T t = (A) a;`) should be safe. `T : size_t` and `A : int` won't compile. Fixed appropriately. > - `"%d"` format-flags replaced with `SIZE_FORMAT`. > - Type of `CompilerToVM::Data::vm_page_size` changed to `size_t`. > > ### Test > tier1-5: all green, except an unrelated fail for whom a bug is already created. > job-id: afshin-8151413-20230117-1255-40910454 Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: 8151413: os::allocation_granularity/page_size and friends return signed values ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12091/files - new: https://git.openjdk.org/jdk/pull/12091/files/74c859b7..7b9c0361 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12091&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12091&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12091.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12091/head:pull/12091 PR: https://git.openjdk.org/jdk/pull/12091 From ccheung at openjdk.org Thu Jan 19 19:32:13 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 19 Jan 2023 19:32:13 GMT Subject: RFR: 8151413: os::allocation_granularity/page_size and friends return signed values [v3] In-Reply-To: <5ZV3GHTMWBLxQ1UHVC3hT4rhjMx2clU_QbaPFORdTSM=.8ac9810a-48e8-4639-8616-b5ce7f340f17@github.com> References: <5ZV3GHTMWBLxQ1UHVC3hT4rhjMx2clU_QbaPFORdTSM=.8ac9810a-48e8-4639-8616-b5ce7f340f17@github.com> Message-ID: On Thu, 19 Jan 2023 19:00:30 GMT, Afshin Zafari wrote: >> ### Description >> os::allocation_granularity/page_size and friends return signed values >> >> ### Patch >> - Type of `vm_page_size` and `vm_allocation_granularity` members of `OSInfo` class and their wrappers in `os` class changed to `size_t` >> - Initial value of them changed from -1 to 0. >> - In setters, checking for *set only once* condition is updated accordingly (comparing with 0 instead of -1). Also, checking the argument be positive is removed. >> - Equal to 0 (instead of `<= 0` ) is used to check if calling setters failed. >> - All `(size_t)` casting of getters removed. >> - In arithmetic and negation operations, the operand related to the getters casted to `(int)`. Otherwise, the Windows builds complain. >> - Explicitly casted to `(int)` where `jint` needed. >> - In ` align_up(T size, A alignment)`, assignment of variables of type `A` to type `T` (i.e., `T t = (A) a;`) should be safe. `T : size_t` and `A : int` won't compile. Fixed appropriately. >> - `"%d"` format-flags replaced with `SIZE_FORMAT`. >> - Type of `CompilerToVM::Data::vm_page_size` changed to `size_t`. >> >> ### Test >> tier1-5: all green, except an unrelated fail for whom a bug is already created. >> job-id: afshin-8151413-20230117-1255-40910454 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8151413: os::allocation_granularity/page_size and friends return signed values I have a suggestion below. Also, you may want to update the copyright year of some of the files. The `make/scripts/update_copyright_year.sh` can help on that. src/hotspot/share/prims/whitebox.cpp line 160: > 158: > 159: WB_ENTRY(jint, WB_GetVMPageSize(JNIEnv* env, jobject o)) > 160: return (int)os::vm_page_size(); Maybe typecast it to `jint`? ------------- PR: https://git.openjdk.org/jdk/pull/12091 From coleenp at openjdk.org Thu Jan 19 20:15:03 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 19 Jan 2023 20:15:03 GMT Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable [v6] In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 12:56:51 GMT, Leo Korinth wrote: >> I am replacing the old hash table with ResourceHashtable. In the process I am also removing the redundant `_length` field. By removing the `_length` field, a lot of asserts can be removed as the length will trivially match the length of the underlying table. >> >> I would like to have feedback on the addition of `unlink_destruct(Function&& should_remove)`. I added it because I prefer to use a functor object that can be used by lambdas instead of an iterator object. However, I did add code to "destruct" resource objects when they are removed instead of just letting them be to reflect that we use `delete` on c-heap objects. Maybe I should remove this "improvement" and then maybe implement the function by calling the existing unlink? > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > revert copyright year after changes This hashtable requires locking, so your nmethods_do function must be protected by either your _m lock or maybe CodeCache_lock (?) contains() should assert that _m lock is held. ------------- PR: https://git.openjdk.org/jdk/pull/11675 From jwilhelm at openjdk.org Thu Jan 19 20:49:26 2023 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Thu, 19 Jan 2023 20:49:26 GMT Subject: RFR: Merge jdk20 Message-ID: Forwardport JDK 20 -> JDK 21 ------------- Commit messages: - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20 - 8298400: Virtual thread instability when stack overflows - 8300490: Spaces in name of MacOS Code Signing Identity are not correctly handled after JDK-8293550 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk&pr=12103&range=00.0 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=12103&range=00.1 Changes: https://git.openjdk.org/jdk/pull/12103/files Stats: 45 lines in 6 files changed: 40 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/12103.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12103/head:pull/12103 PR: https://git.openjdk.org/jdk/pull/12103 From mikael at openjdk.org Thu Jan 19 21:10:11 2023 From: mikael at openjdk.org (Mikael Vidstedt) Date: Thu, 19 Jan 2023 21:10:11 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v8] In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 18:54:08 GMT, Xue-Lei Andrew Fan wrote: >> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. >> >> This patch is trying to find the use of sprintf in hotspot iml and test cases. > > Xue-Lei Andrew Fan has updated the pull request incrementally with two additional commits since the last revision: > > - remove serviceability update and add back forbid of sprintf > - remove serviceability update I was (still) puzzled by the remaining sprintf:s in the JDK and the fact that the build completed successfully even if not all of them had been address/updated, so I investigated it a bit and came to the conclusion that the Xcode/clang warning (which we turn into an error with `-Werror`) only seems to be generated for C++ files, not for C files. For many reasons we may still want to fix the remaining occurrences as well, but for the immediate case of the new Xcode version it seems to be sufficient to fix the C++ files. ------------- PR: https://git.openjdk.org/jdk/pull/11935 From coleenp at openjdk.org Thu Jan 19 22:00:52 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 19 Jan 2023 22:00:52 GMT Subject: RFR: 8300682: InstanceKlassMiscStatus is a bad name Message-ID: This patch is to simply rename InstanceKlassMiscStatus to InstanceKlassFlags. This matches the naming for upcoming Field changes that add a FieldFlags class. Tested with tier1-4. ------------- Commit messages: - 8300682: InstanceKlassMiscStatus is a bad name Changes: https://git.openjdk.org/jdk/pull/12106/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12106&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300682 Stats: 180 lines in 6 files changed: 69 ins; 69 del; 42 mod Patch: https://git.openjdk.org/jdk/pull/12106.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12106/head:pull/12106 PR: https://git.openjdk.org/jdk/pull/12106 From fparain at openjdk.org Thu Jan 19 22:04:50 2023 From: fparain at openjdk.org (Frederic Parain) Date: Thu, 19 Jan 2023 22:04:50 GMT Subject: RFR: 8300682: InstanceKlassMiscStatus is a bad name In-Reply-To: References: Message-ID: <4GA30z0Tk1dudsUWSHGynkz3dTlFTvGJFcFHRd7_LkQ=.dac3346e-12b2-40ba-81ca-1ee211a67d31@github.com> On Thu, 19 Jan 2023 21:50:46 GMT, Coleen Phillimore wrote: > This patch is to simply rename InstanceKlassMiscStatus to InstanceKlassFlags. This matches the naming for upcoming Field changes that add a FieldFlags class. > Tested with tier1-4. LGTM, just minor nits in instanceKlassFlags.hpp. LGTM, just minor nits in instanceKlassFlags.hpp. src/hotspot/share/oops/instanceKlassFlags.hpp line 30: > 28: class ClassLoaderData; > 29: > 30: class InstanceKlassFlags { The macro to prevent multiple inclusions should have the same name as the file after the renaming. Should we add a comment stating that "Flags" are immutable, and mutable status should be put elsewhere? ------------- Changes requested by fparain (Committer). PR: https://git.openjdk.org/jdk/pull/12106 From coleenp at openjdk.org Thu Jan 19 22:09:53 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 19 Jan 2023 22:09:53 GMT Subject: RFR: 8300682: InstanceKlassMiscStatus is a bad name In-Reply-To: <4GA30z0Tk1dudsUWSHGynkz3dTlFTvGJFcFHRd7_LkQ=.dac3346e-12b2-40ba-81ca-1ee211a67d31@github.com> References: <4GA30z0Tk1dudsUWSHGynkz3dTlFTvGJFcFHRd7_LkQ=.dac3346e-12b2-40ba-81ca-1ee211a67d31@github.com> Message-ID: On Thu, 19 Jan 2023 22:01:33 GMT, Frederic Parain wrote: >> This patch is to simply rename InstanceKlassMiscStatus to InstanceKlassFlags. This matches the naming for upcoming Field changes that add a FieldFlags class. >> Tested with tier1-4. > > src/hotspot/share/oops/instanceKlassFlags.hpp line 30: > >> 28: class ClassLoaderData; >> 29: >> 30: class InstanceKlassFlags { > > The macro to prevent multiple inclusions should have the same name as the file after the renaming. > Should we add a comment stating that "Flags" are immutable, and mutable status should be put elsewhere? Oh whoops. Thank you for noticing that. ------------- PR: https://git.openjdk.org/jdk/pull/12106 From coleenp at openjdk.org Thu Jan 19 22:22:44 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 19 Jan 2023 22:22:44 GMT Subject: RFR: 8300682: InstanceKlassMiscStatus is a bad name [v2] In-Reply-To: References: Message-ID: > This patch is to simply rename InstanceKlassMiscStatus to InstanceKlassFlags. This matches the naming for upcoming Field changes that add a FieldFlags class. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Fix include guards. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12106/files - new: https://git.openjdk.org/jdk/pull/12106/files/fba9a31e..2b79fd3c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12106&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12106&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12106.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12106/head:pull/12106 PR: https://git.openjdk.org/jdk/pull/12106 From fparain at openjdk.org Thu Jan 19 22:22:44 2023 From: fparain at openjdk.org (Frederic Parain) Date: Thu, 19 Jan 2023 22:22:44 GMT Subject: RFR: 8300682: InstanceKlassMiscStatus is a bad name [v2] In-Reply-To: References: Message-ID: <0PCQkbSG_4cF3ogLdEBO05KLoIhfsLCuBfQtzr1mPHA=.40605337-af94-4b9f-ad95-e60f81e40321@github.com> On Thu, 19 Jan 2023 22:19:21 GMT, Coleen Phillimore wrote: >> This patch is to simply rename InstanceKlassMiscStatus to InstanceKlassFlags. This matches the naming for upcoming Field changes that add a FieldFlags class. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix include guards. Marked as reviewed by fparain (Committer). ------------- PR: https://git.openjdk.org/jdk/pull/12106 From coleenp at openjdk.org Thu Jan 19 22:22:46 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 19 Jan 2023 22:22:46 GMT Subject: RFR: 8300682: InstanceKlassMiscStatus is a bad name [v2] In-Reply-To: References: <4GA30z0Tk1dudsUWSHGynkz3dTlFTvGJFcFHRd7_LkQ=.dac3346e-12b2-40ba-81ca-1ee211a67d31@github.com> Message-ID: On Thu, 19 Jan 2023 22:07:07 GMT, Coleen Phillimore wrote: >> src/hotspot/share/oops/instanceKlassFlags.hpp line 30: >> >>> 28: class ClassLoaderData; >>> 29: >>> 30: class InstanceKlassFlags { >> >> The macro to prevent multiple inclusions should have the same name as the file after the renaming. >> Should we add a comment stating that "Flags" are immutable, and mutable status should be put elsewhere? > > Oh whoops. Thank you for noticing that. I was going to put this comment when adding the mutable status class, in a following change. ------------- PR: https://git.openjdk.org/jdk/pull/12106 From jwilhelm at openjdk.org Thu Jan 19 22:30:48 2023 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Thu, 19 Jan 2023 22:30:48 GMT Subject: Integrated: Merge jdk20 In-Reply-To: References: Message-ID: <-qTsD-dG7EWBdc6Wy_5XPMQyJChbXnh-zJrpsPS5oK0=.e6a7c1a5-a365-4e6b-9bc6-19cbe0580eed@github.com> On Thu, 19 Jan 2023 20:42:26 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 20 -> JDK 21 This pull request has now been integrated. Changeset: dfcd65c2 Author: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/dfcd65c2719cae19d41caf25f9aa0691568247e8 Stats: 45 lines in 6 files changed: 40 ins; 0 del; 5 mod Merge ------------- PR: https://git.openjdk.org/jdk/pull/12103 From ysr at openjdk.org Thu Jan 19 22:54:27 2023 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Thu, 19 Jan 2023 22:54:27 GMT Subject: RFR: 8151413: os::allocation_granularity/page_size and friends return signed values [v3] In-Reply-To: <5ZV3GHTMWBLxQ1UHVC3hT4rhjMx2clU_QbaPFORdTSM=.8ac9810a-48e8-4639-8616-b5ce7f340f17@github.com> References: <5ZV3GHTMWBLxQ1UHVC3hT4rhjMx2clU_QbaPFORdTSM=.8ac9810a-48e8-4639-8616-b5ce7f340f17@github.com> Message-ID: On Thu, 19 Jan 2023 19:00:30 GMT, Afshin Zafari wrote: >> ### Description >> os::allocation_granularity/page_size and friends return signed values >> >> ### Patch >> - Type of `vm_page_size` and `vm_allocation_granularity` members of `OSInfo` class and their wrappers in `os` class changed to `size_t` >> - Initial value of them changed from -1 to 0. >> - In setters, checking for *set only once* condition is updated accordingly (comparing with 0 instead of -1). Also, checking the argument be positive is removed. >> - Equal to 0 (instead of `<= 0` ) is used to check if calling setters failed. >> - All `(size_t)` casting of getters removed. >> - In arithmetic and negation operations, the operand related to the getters casted to `(int)`. Otherwise, the Windows builds complain. >> - Explicitly casted to `(int)` where `jint` needed. >> - In ` align_up(T size, A alignment)`, assignment of variables of type `A` to type `T` (i.e., `T t = (A) a;`) should be safe. `T : size_t` and `A : int` won't compile. Fixed appropriately. >> - `"%d"` format-flags replaced with `SIZE_FORMAT`. >> - Type of `CompilerToVM::Data::vm_page_size` changed to `size_t`. >> >> ### Test >> tier1-5: all green, except an unrelated fail for whom a bug is already created. >> job-id: afshin-8151413-20230117-1255-40910454 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8151413: os::allocation_granularity/page_size and friends return signed values LGTM! ------------- Marked as reviewed by ysr (Reviewer). PR: https://git.openjdk.org/jdk/pull/12091 From haosun at openjdk.org Fri Jan 20 02:09:44 2023 From: haosun at openjdk.org (Hao Sun) Date: Fri, 20 Jan 2023 02:09:44 GMT Subject: RFR: 8300253: Introduce AArch64 nzcv accessors [v2] In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 10:18:53 GMT, Erik ?sterlund wrote: >> Some code, such as verification code, might want to run without changing the state of the system. To do that, it's useful to be able to get and set the nzcv flags. This enhancement aims at adding accessors for that. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Add test test/hotspot/gtest/aarch64/aarch64-asmtest.py line 1462: > 1460: for system_reg in ["fpsr", "dczid_el0", "ctr_el0", "nzcv"]: > 1461: generate (SystemOneRegOp, [ ["msr", system_reg] ]) > 1462: generate (OneRegSystemOp, [ ["mrs", system_reg] ]) Suggestion: for system_reg in ["fpsr", "nzcv"]: generate (SystemOneRegOp, [ ["msr", system_reg] ]) for system_reg in ["fpsr", "dczid_el0", "ctr_el0", "nzcv"]: generate (OneRegSystemOp, [ ["mrs", system_reg] ]) 1. `asmtest.out.h` should be updated as well. Note that it's generated by running `aarch64-asmtest.py` script. 2. There are no instructions to "set/update" `dczid_el0` or `ctr_el0` in `macroAssembler_aarch64.hpp`. Here shows the warnings of running `python2 aarch64-asmtest.py`: aarch64ops.s: Assembler messages: aarch64ops.s:202: Warning: specified register cannot be written to at operand 1 -- `msr dczid_el0,x27' aarch64ops.s:206: Warning: specified register cannot be written to at operand 1 -- `msr ctr_el0,x11' ------------- PR: https://git.openjdk.org/jdk/pull/12038 From dholmes at openjdk.org Fri Jan 20 04:42:32 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 20 Jan 2023 04:42:32 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v8] In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 18:54:08 GMT, Xue-Lei Andrew Fan wrote: >> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. >> >> This patch is trying to find the use of sprintf in hotspot iml and test cases. > > Xue-Lei Andrew Fan has updated the pull request incrementally with two additional commits since the last revision: > > - remove serviceability update and add back forbid of sprintf > - remove serviceability update Nothing further from me. I think this is okay as-is now. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/11935 From dholmes at openjdk.org Fri Jan 20 04:42:34 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 20 Jan 2023 04:42:34 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v5] In-Reply-To: <1ClKpQgCeS1zWMqBwXYSR3Y0LzX_l2-uOHoy_lFDQuQ=.9fb3d52b-0421-4945-860b-e149e5c07a8c@github.com> References: <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com> <1ClKpQgCeS1zWMqBwXYSR3Y0LzX_l2-uOHoy_lFDQuQ=.9fb3d52b-0421-4945-860b-e149e5c07a8c@github.com> Message-ID: On Wed, 18 Jan 2023 19:30:42 GMT, Xue-Lei Andrew Fan wrote: >> src/hotspot/share/utilities/globalDefinitions.hpp line 191: >> >>> 189: FORBID_C_FUNCTION(char* strerror(int), "use os::strerror"); >>> 190: FORBID_C_FUNCTION(char* strtok(char*, const char*), "use strtok_r"); >>> 191: FORBID_C_FUNCTION(int sprintf(char*, const char*, ...), "use os::snprintf"); >> >> I have to wonder whether this actually works too. Perhaps @kbarrett can comment? > > I am not confident with it. Maybe it is better to remove this change and consider it later. For the record I tested this standalone and it works fine in a C++ program. ------------- PR: https://git.openjdk.org/jdk/pull/11935 From dholmes at openjdk.org Fri Jan 20 04:52:28 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 20 Jan 2023 04:52:28 GMT Subject: RFR: 8300682: InstanceKlassMiscStatus is a bad name [v2] In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 22:22:44 GMT, Coleen Phillimore wrote: >> This patch is to simply rename InstanceKlassMiscStatus to InstanceKlassFlags. This matches the naming for upcoming Field changes that add a FieldFlags class. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix include guards. Seems fine. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12106 From mdoerr at openjdk.org Fri Jan 20 04:59:31 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 20 Jan 2023 04:59:31 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v5] In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 09:13:42 GMT, Fredrik Bredberg wrote: >> Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. >> Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. >> Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > Updated after review. Thanks! Your update and the PPC64 parts LGTM. ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.org/jdk/pull/11902 From fyang at openjdk.org Fri Jan 20 05:06:28 2023 From: fyang at openjdk.org (Fei Yang) Date: Fri, 20 Jan 2023 05:06:28 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v5] In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 09:13:42 GMT, Fredrik Bredberg wrote: >> Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. >> Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. >> Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > Updated after review. The RISC-V specific changes looks good. Thanks. ------------- Marked as reviewed by fyang (Reviewer). PR: https://git.openjdk.org/jdk/pull/11902 From dholmes at openjdk.org Fri Jan 20 06:31:27 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 20 Jan 2023 06:31:27 GMT Subject: RFR: JDK-8300582: Introduce interface for unaligned memory accesses [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 21:42:58 GMT, Justin King wrote: >> Introduce interface for unaligned memory accesses `UnalignedAccess`, consolidate the byte swapping implementation to `byteswap`, and switch to a generic implementation of `Bytes`. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Update comment to be correct > > Signed-off-by: Justin King src/hotspot/share/utilities/bytes.hpp line 2: > 1: /* > 2: * Copyright (c) 2014, 2019, 2023, Oracle and/or its affiliates. All rights reserved. Oracle copyrights only have two years max - the 2019 should become 2023 ------------- PR: https://git.openjdk.org/jdk/pull/12078 From dholmes at openjdk.org Fri Jan 20 06:34:34 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 20 Jan 2023 06:34:34 GMT Subject: RFR: JDK-8300582: Introduce interface for unaligned memory accesses [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 21:42:58 GMT, Justin King wrote: >> Introduce interface for unaligned memory accesses `UnalignedAccess`, consolidate the byte swapping implementation to `byteswap`, and switch to a generic implementation of `Bytes`. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Update comment to be correct > > Signed-off-by: Justin King src/hotspot/share/utilities/byteswap.hpp line 61: > 59: #include > 60: > 61: #if defined(_MSC_VER) I'd rather see OS specific header files to do all this than pollute what is supposed to be shared code with all this OS specific stuff. ------------- PR: https://git.openjdk.org/jdk/pull/12078 From dholmes at openjdk.org Fri Jan 20 06:37:27 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 20 Jan 2023 06:37:27 GMT Subject: RFR: JDK-8300582: Introduce interface for unaligned memory accesses [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 21:42:58 GMT, Justin King wrote: >> Introduce interface for unaligned memory accesses `UnalignedAccess`, consolidate the byte swapping implementation to `byteswap`, and switch to a generic implementation of `Bytes`. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Update comment to be correct > > Signed-off-by: Justin King I don't mind seeing some better code sharing in the "byte" stuff, but simply deleting all the platform specific files and then adding a tonne of platform ifdefs to what should be the shared code, has gone too far IMO. Also I think the byte stuff should be separated out from the unaligned memory access interface. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/12078 From stuefe at openjdk.org Fri Jan 20 08:54:27 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 20 Jan 2023 08:54:27 GMT Subject: RFR: JDK-8300266: Detect Virtualization on Linux aarch64 In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 13:27:24 GMT, Matthias Baesken wrote: > Currently we detect virtualization on Linux x86_64 (cpuid call) and Linux ppc64le ; the result is afterwards used e.g. in hs_err and JFR output. > > On Linux aarch64 the detection is missing, this should be added. > One option would be to look at /sys/devices/virtual/dmi/id/product_name and related files , at least KVM and VMWare can be detected using these files. Hi Matthias, - can you give an example of such a line? I assume it won't overflow the 500 bytes, right? - Does it have to live inside CPU/aarch? Would be better in the linux_aarch branch - People start using `nullptr` instead of `NULL` now in earnest, might be better to use that instead. Cheers, Thomas ------------- PR: https://git.openjdk.org/jdk/pull/12071 From duke at openjdk.org Fri Jan 20 09:28:58 2023 From: duke at openjdk.org (Afshin Zafari) Date: Fri, 20 Jan 2023 09:28:58 GMT Subject: RFR: 8151413: os::allocation_granularity/page_size and friends return signed values [v4] In-Reply-To: References: Message-ID: > ### Description > os::allocation_granularity/page_size and friends return signed values > > ### Patch > - Type of `vm_page_size` and `vm_allocation_granularity` members of `OSInfo` class and their wrappers in `os` class changed to `size_t` > - Initial value of them changed from -1 to 0. > - In setters, checking for *set only once* condition is updated accordingly (comparing with 0 instead of -1). Also, checking the argument be positive is removed. > - Equal to 0 (instead of `<= 0` ) is used to check if calling setters failed. > - All `(size_t)` casting of getters removed. > - In arithmetic and negation operations, the operand related to the getters casted to `(int)`. Otherwise, the Windows builds complain. > - Explicitly casted to `(int)` where `jint` needed. > - In ` align_up(T size, A alignment)`, assignment of variables of type `A` to type `T` (i.e., `T t = (A) a;`) should be safe. `T : size_t` and `A : int` won't compile. Fixed appropriately. > - `"%d"` format-flags replaced with `SIZE_FORMAT`. > - Type of `CompilerToVM::Data::vm_page_size` changed to `size_t`. > > ### Test > tier1-5: all green, except an unrelated fail for whom a bug is already created. > job-id: afshin-8151413-20230117-1255-40910454 Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: 8151413: os::allocation_granularity/page_size and friends return signed values ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12091/files - new: https://git.openjdk.org/jdk/pull/12091/files/7b9c0361..ec3e4129 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12091&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12091&range=02-03 Stats: 55 lines in 54 files changed: 0 ins; 0 del; 55 mod Patch: https://git.openjdk.org/jdk/pull/12091.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12091/head:pull/12091 PR: https://git.openjdk.org/jdk/pull/12091 From aph at openjdk.org Fri Jan 20 09:30:37 2023 From: aph at openjdk.org (Andrew Haley) Date: Fri, 20 Jan 2023 09:30:37 GMT Subject: RFR: JDK-8300582: Introduce interface for unaligned memory accesses [v2] In-Reply-To: References: Message-ID: On Fri, 20 Jan 2023 06:31:53 GMT, David Holmes wrote: > I'd rather see OS specific header files to do all this than pollute what is supposed to be shared code with all this OS specific stuff. Definitely. ------------- PR: https://git.openjdk.org/jdk/pull/12078 From duke at openjdk.org Fri Jan 20 09:34:17 2023 From: duke at openjdk.org (Afshin Zafari) Date: Fri, 20 Jan 2023 09:34:17 GMT Subject: RFR: 8151413: os::allocation_granularity/page_size and friends return signed values [v5] In-Reply-To: References: Message-ID: > ### Description > os::allocation_granularity/page_size and friends return signed values > > ### Patch > - Type of `vm_page_size` and `vm_allocation_granularity` members of `OSInfo` class and their wrappers in `os` class changed to `size_t` > - Initial value of them changed from -1 to 0. > - In setters, checking for *set only once* condition is updated accordingly (comparing with 0 instead of -1). Also, checking the argument be positive is removed. > - Equal to 0 (instead of `<= 0` ) is used to check if calling setters failed. > - All `(size_t)` casting of getters removed. > - In arithmetic and negation operations, the operand related to the getters casted to `(int)`. Otherwise, the Windows builds complain. > - Explicitly casted to `(int)` where `jint` needed. > - In ` align_up(T size, A alignment)`, assignment of variables of type `A` to type `T` (i.e., `T t = (A) a;`) should be safe. `T : size_t` and `A : int` won't compile. Fixed appropriately. > - `"%d"` format-flags replaced with `SIZE_FORMAT`. > - Type of `CompilerToVM::Data::vm_page_size` changed to `size_t`. > > ### Test > tier1-5: all green, except an unrelated fail for whom a bug is already created. > job-id: afshin-8151413-20230117-1255-40910454 Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: 8151413: os::allocation_granularity/page_size and friends return signed values ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12091/files - new: https://git.openjdk.org/jdk/pull/12091/files/ec3e4129..2a2a22b3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12091&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12091&range=03-04 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12091.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12091/head:pull/12091 PR: https://git.openjdk.org/jdk/pull/12091 From stuefe at openjdk.org Fri Jan 20 09:38:41 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 20 Jan 2023 09:38:41 GMT Subject: RFR: JDK-8294266: Add a way to pre-touch java thread stacks [v4] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 10:16:58 GMT, Thomas Stuefe wrote: >> When doing performance- and footprint analysis, `AlwaysPreTouch` option is very handy for reducing noise. It would be good to have a similar option for pre-touching thread stacks. In addition to reducing noise, it can serve as worst-case test for thread costs, as well as a test for NMT regressions. >> >> Patch adds a new diagnostic switch, `AlwaysPreTouchStacks`, as a companion switch to `AlwaysPreTouch`. Touching is super-simple using `alloca()`. Also, regression test. >> >> Examples: >> >> NMT, thread stacks, 10000 Threads, default: >> >> >> - Thread (reserved=10332400KB, committed=331828KB) >> (thread #10021) >> (stack: reserved=10301560KB, committed=300988KB) >> (malloc=19101KB #60755) >> (arena=11739KB #20037) >> >> >> NMT, thread stacks, 10000 Threads, +AlwaysPreTouchStacks: >> >> >> - Thread (reserved=10332400KB, committed=10284360KB) >> (thread #10021) >> (stack: reserved=10301560KB, committed=10253520KB) >> (malloc=19101KB #60755) >> (arena=11739KB #20037) > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > test changes, comment change not yet bot ------------- PR: https://git.openjdk.org/jdk/pull/10403 From duke at openjdk.org Fri Jan 20 09:41:28 2023 From: duke at openjdk.org (Afshin Zafari) Date: Fri, 20 Jan 2023 09:41:28 GMT Subject: RFR: 8151413: os::allocation_granularity/page_size and friends return signed values [v6] In-Reply-To: References: Message-ID: > ### Description > os::allocation_granularity/page_size and friends return signed values > > ### Patch > - Type of `vm_page_size` and `vm_allocation_granularity` members of `OSInfo` class and their wrappers in `os` class changed to `size_t` > - Initial value of them changed from -1 to 0. > - In setters, checking for *set only once* condition is updated accordingly (comparing with 0 instead of -1). Also, checking the argument be positive is removed. > - Equal to 0 (instead of `<= 0` ) is used to check if calling setters failed. > - All `(size_t)` casting of getters removed. > - In arithmetic and negation operations, the operand related to the getters casted to `(int)`. Otherwise, the Windows builds complain. > - Explicitly casted to `(int)` where `jint` needed. > - In ` align_up(T size, A alignment)`, assignment of variables of type `A` to type `T` (i.e., `T t = (A) a;`) should be safe. `T : size_t` and `A : int` won't compile. Fixed appropriately. > - `"%d"` format-flags replaced with `SIZE_FORMAT`. > - Type of `CompilerToVM::Data::vm_page_size` changed to `size_t`. > > ### Test > tier1-5: all green, except an unrelated fail for whom a bug is already created. > job-id: afshin-8151413-20230117-1255-40910454 Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge 'master' - 8151413: os::allocation_granularity/page_size and friends return signed values - 8151413: os::allocation_granularity/page_size and friends return signed values - 8151413: os::allocation_granularity/page_size and friends return signed values - 8151413: os::allocation_granularity/page_size and friends return signed values - 8151413: os::allocation_granularity/page_size and friends return signed values ------------- Changes: https://git.openjdk.org/jdk/pull/12091/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12091&range=05 Stats: 188 lines in 66 files changed: 7 ins; 5 del; 176 mod Patch: https://git.openjdk.org/jdk/pull/12091.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12091/head:pull/12091 PR: https://git.openjdk.org/jdk/pull/12091 From stuefe at openjdk.org Fri Jan 20 10:14:29 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 20 Jan 2023 10:14:29 GMT Subject: RFR: 8296469: Instrument VMError::report with reentrant iteration step for register and stack printing [v3] In-Reply-To: References: Message-ID: On Tue, 20 Dec 2022 14:56:04 GMT, Axel Boldt-Christmas wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix whitespace > > Sorry for the late reply. Felt no need to push anything related to this into 20. > >> > Added some limitations on reentry of a reentrant step. It will now break the inner loop if: >> > ``` >> > * It is the fourth time reentering this step >> > >> > * It is the eight time reentering any reentrant step >> > >> > * The stack headroom is less than 64K >> > >> > * A timeout has been issued >> > ``` >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > The post loop logic of a reentrant step is given another timeout window. Currently all it does is make sure there are line breaks after the step output, but I imagine this can be useful incase some reentrant step logic is used where the loop builds up some data structure and the post logic prints it. >> > All of the limit constants are just picked rather ad-hoc. Would be nice to have some extra feedback on this. >> >> I think the approach is better, but I'm not a big fan of the broadened os interface and the fact that error-handling-specifics now leak into the os interface. >> > > I rewrote the code so the os interface is simply: > ```c++ > static void print_register_info(outputStream* st, int n, const void* context); > static int printable_register_count(); > > It simply allows querying for how many printable registers there are and asking it to print a register's content on an outputStream given a context. I do not believe that any error handling specifics leaks into the interface, if anything it is more agnostic interface now. The previous `print_register_info` was written to output data which fits in with hs_err printing. This approach just prints one register's info followed by a newline. > >> How about letting the print function fill in an opaque continuation object instead? Something like: >> >> ``` >> // Print register information; optionally re-startable. If (*continuation_info) is null, >> // register printing starts with the first register, otherwise beyond whatever point >> // it had been interrupted before. >> void os::print_register_info(const ucontext_t* context, outputStream* st, void** continuation_info); >> ``` >> >> `continuation_info` can have any shape or form the platform-specific implementation wants. It does not have to be visible or known on the outside. It can exist as a struct only in the os_xxx.cpp file. Or, the platform could just hide an integer in the pointer and use it as restart point. >> >> The standard `os::print_register_info(const ucontext_t*, outputStream*)` can then be implemented with a dummy continuation info that does nothing: >> >> ``` >> os::print_register_info(const ucontext_t* c, outputStream* st) { >> void* info; >> os_print_register_info(c, st, &info); >> } >> ``` >> >> If that is too C-ish for you, there can be a C++ equivalent via runtime polymorphy. In any case, the charm would be that you can re-start register printing without having to know specific implementation details. You just hand in the continuation object. In a very primitive form, without the need for further STEP macros, that could even look like this: >> >> ``` >> void* print_reg_continuation_info = nullptr; >> ... >> STEP(print_register_info_attempt_1) >> { os::print_register_info(context, st, &print_reg_continuation_info); } >> STEP(print_register_info_attempt_2) >> { os::print_register_info(context, st, &print_reg_continuation_info); } >> STEP(print_register_info_attempt_3) >> { os::print_register_info(context, st, &print_reg_continuation_info); } >> ``` >> >> (for this simple approach to work, os::print_register_info() would have recognize a completed printing by the content of continuation info). >> >> In theory, we could use a similar pattern for call stack printing too. >> > > The problem I see with this approach is that if the storage of the continuation must either be dynamic and managed or static and global. Both I do not think fit with error reporting. Dynamic has too many side effects and will be unstable. If the storage lives statically inside the os object file then we have a global state and the `os::print_register_info` will be locked to the error printing or some mechanism has to be added to manage the global state of the program if the `os::os::print_register_info` is to be used from any other location. It is possible to create some construct which can at least hold any platform specific construct and have the storage be inside `vmError`, but this solution is often ugly and hard to make work correctly with the C++ object model. > > Maybe there are different opinions here, but I think such an approach should be avoided as it is harder to reason about. > I think that having a reentrant step with previously mentioned semantics is easier to reason about and read than having repeated code with some externally managed state. > >> As a side note, I have not been idle since print_register_info() not working bugs me too. I found that many reasons for it not working are caused by only a few bugs. oopDesc::print_on() could do a lot more error checking before printing Klass* for instance. And we also could do more error checking when printing object array elements. I have a patch open, but won't make it before JDK 20 freeze, and probably not before my holidays either. If someone else wants to do it, that would be fine with me too. >> >> Cheers, Thomas > > Sounds good. I will continue to monitor the progress on vmError. Will mostly be focusing on ZGC related issues for the coming months. But will be happy to review any PRs that improve the he_err printing. Hi @xmas92, > > > How about letting the print function fill in an opaque continuation object instead? Something like: > > ``` > > // Print register information; optionally re-startable. If (*continuation_info) is null, > > // register printing starts with the first register, otherwise beyond whatever point > > // it had been interrupted before. > > void os::print_register_info(const ucontext_t* context, outputStream* st, void** continuation_info); > > ``` > > > > `continuation_info` can have any shape or form the platform-specific implementation wants. It does not have to be visible or known on the outside. It can exist as a struct only in the os_xxx.cpp file. Or, the platform could just hide an integer in the pointer and use it as restart point. > > The standard `os::print_register_info(const ucontext_t*, outputStream*)` can then be implemented with a dummy continuation info that does nothing: > > ``` > > os::print_register_info(const ucontext_t* c, outputStream* st) { > > void* info; > > os_print_register_info(c, st, &info); > > } > > ``` > > > > If that is too C-ish for you, there can be a C++ equivalent via runtime polymorphy. In any case, the charm would be that you can re-start register printing without having to know specific implementation details. You just hand in the continuation object. In a very primitive form, without the need for further STEP macros, that could even look like this: > > ``` > > void* print_reg_continuation_info = nullptr; > > ... > > STEP(print_register_info_attempt_1) > > { os::print_register_info(context, st, &print_reg_continuation_info); } > > STEP(print_register_info_attempt_2) > > { os::print_register_info(context, st, &print_reg_continuation_info); } > > STEP(print_register_info_attempt_3) > > { os::print_register_info(context, st, &print_reg_continuation_info); } > > ``` > > (for this simple approach to work, os::print_register_info() would have recognize a completed printing by the content of continuation info). > > In theory, we could use a similar pattern for call stack printing too. > > The problem I see with this approach is that if the storage of the continuation must either be dynamic and managed or static and global. Both I do not think fit with error reporting. Dynamic has too many side effects and will be unstable. If the storage lives statically inside the os object file then we have a global state and the `os::print_register_info` will be locked to the error printing or some mechanism has to be added to manage the global state of the program if the `os::os::print_register_info` is to be used from any other location. Is this about the variable size of the object? In its simplest form, the approach could be done with a word-sized datum that fits into a void*, no additional memory needed. You can put the void* directly on the stack. In fact, we could even just pass an int, or a long, and declare this as continuation point which the implementation should interprete as it sees fit. On most platforms, that would correspond to the register number. Similar to what you do now. os::print_register_info(const ucontext_t* c, outputStream* st, int& continuation_point) { // .. start printing at register number conti_point + 1 } and os::print_register_info(const ucontext_t* c, outputStream* st) { int conti_point = 0; print_register_info(c, st, conti_point); } You could hide those behind a typedef or a class for nicer aesthetics: typedef int continuation_point_t; static const continuation_point_t INIT_POINT = 0; or class ContinuationPoint { int _v; ContinuationPoint() : _v(0) {} int raw_value() ... void increment() ... } This would be a pragmatic approach that also translates well to printing callstacks, the other thing we want with more robustness. > It is possible to create some construct which can at least hold any platform specific construct and have the storage be inside `vmError`, but this solution is often ugly and hard to make work correctly with the C++ object model. > > Maybe there are different opinions here, but I think such an approach should be avoided as it is harder to reason about. I think that having a reentrant step with previously mentioned semantics is easier to reason about and read than having repeated code with some externally managed state. I disagree with that. I find the `REENTRANT_STEP_IF` logic difficult to parse compared to the old solution. To me, it is also not clear how STEP timeouts are handled. Backporting fixes across such an intrusive patch would be painful. Another (minor) point would be that you now expose printing individual registers and the number of registers. This means that this exposes the fact the semantic info that a context contains n register prints. But maybe we want to print additional information? Leave out some groups of registers, print some only conditionally etc? I would be more comfortable with an opaque conti info which the platform can interprete as it wants. Cheers, Thomas ------------- PR: https://git.openjdk.org/jdk/pull/11017 From rehn at openjdk.org Fri Jan 20 10:43:32 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 20 Jan 2023 10:43:32 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v4] In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 17:34:53 GMT, Andrew Haley wrote: >> Fredrik Bredberg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Merge branch 'master' into relativize-locals-JDK-8299795_2023-01-09 >> - Added references to JDK-8300197 >> - Updated some copyright dates. >> - Changed copyright date to 2023 >> - 8299795: Relativize locals in interpreter frames > >> Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. > > Please explain for the record the purpose of this patch. Neither the PR nor the Jira issue explain. I presume it's something to do with making the mounting and unmounting of interpreter frames easier, but this must be said somewhere. @theRealAph are you planning to provide additional feedback, or can it be shipped? ------------- PR: https://git.openjdk.org/jdk/pull/11902 From stuefe at openjdk.org Fri Jan 20 10:53:31 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 20 Jan 2023 10:53:31 GMT Subject: RFR: 8296469: Instrument VMError::report with reentrant iteration step for register and stack printing [v4] In-Reply-To: References: Message-ID: On Tue, 20 Dec 2022 14:59:55 GMT, Axel Boldt-Christmas wrote: >> Add reentrant step logic to VMError::report with an inner loop which enable the logic to recover at every step of the iteration. >> >> Before this change, if printing one register/stack position crashes then no more registers/stack positions will be printed. >> >> After this change even if the VM is unstable and some registers print_location crashes the hs_err printing will recover and keep attempting to print the rest of the registers or stack values. >> >> Enables the following >> ```C++ >> REENTRANT_STEP_IF("printing register info", _verbose && _context && _thread && Universe::is_fully_initialized()) >> os::print_register_info_header(st, _context); >> >> REENTRANT_LOOP_START(os::print_nth_register_info_max_index()) >> // decode register contents if possible >> ResourceMark rm(_thread); >> os::print_nth_register_info(st, REENTRANT_ITERATION_STEP, _context); >> REENTRANT_LOOP_END >> >> st->cr(); >> >> >> Testing: tier 1 and compiled Linux-x64/aarch64, MacOS-x64/aarch64, Windows x64 and cross-compiled Linux-x86/riscv/arm/ppc/s390x (GHA and some local) > > Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Restructure os::print_register_info interface > - Code syle and line length > - Merge Fix > - Merge remote-tracking branch 'upstream_jdk/master' into vmerror_report_register_stack_reentrant > - Fix whitespace > - Add reentrant reentry limits > - Add os::print_register_info_header > - VMError::report reentrant for register and stack print Side note, if others disagree with me and think this is the way to go, I won't hold up the patch. ------------- PR: https://git.openjdk.org/jdk/pull/11017 From mbaesken at openjdk.org Fri Jan 20 10:55:50 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 20 Jan 2023 10:55:50 GMT Subject: RFR: JDK-8300266: Detect Virtualization on Linux aarch64 [v2] In-Reply-To: References: Message-ID: > Currently we detect virtualization on Linux x86_64 (cpuid call) and Linux ppc64le ; the result is afterwards used e.g. in hs_err and JFR output. > > On Linux aarch64 the detection is missing, this should be added. > One option would be to look at /sys/devices/virtual/dmi/id/product_name and related files , at least KVM and VMWare can be detected using these files. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: switch from NULL ot nullptr ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12071/files - new: https://git.openjdk.org/jdk/pull/12071/files/35c45cb1..5770114e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12071&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12071&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12071.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12071/head:pull/12071 PR: https://git.openjdk.org/jdk/pull/12071 From mbaesken at openjdk.org Fri Jan 20 10:58:31 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 20 Jan 2023 10:58:31 GMT Subject: RFR: JDK-8300266: Detect Virtualization on Linux aarch64 [v2] In-Reply-To: References: Message-ID: On Fri, 20 Jan 2023 10:55:50 GMT, Matthias Baesken wrote: >> Currently we detect virtualization on Linux x86_64 (cpuid call) and Linux ppc64le ; the result is afterwards used e.g. in hs_err and JFR output. >> >> On Linux aarch64 the detection is missing, this should be added. >> One option would be to look at /sys/devices/virtual/dmi/id/product_name and related files , at least KVM and VMWare can be detected using these files. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > switch from NULL ot nullptr Hi Thomas, thanks for the comments. I switched to nullptr. The lines look like this ------------- PR: https://git.openjdk.org/jdk/pull/12071 From bulasevich at openjdk.org Fri Jan 20 11:02:28 2023 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Fri, 20 Jan 2023 11:02:28 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v4] In-Reply-To: References: Message-ID: <2Mijs6e9YpQ81_KD6W3aE9elAb30Tb343mnWuMNZSS8=.cf10dd9a-2907-4928-9004-a974264b58fe@github.com> On Tue, 17 Jan 2023 08:57:35 GMT, Fredrik Bredberg wrote: > Hi @bulasevich, can you verify that this PR works on Arm32? ARM32 part LGTM. Test results are fine. Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/11902 From aboldtch at openjdk.org Fri Jan 20 11:24:26 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 20 Jan 2023 11:24:26 GMT Subject: RFR: 8296469: Instrument VMError::report with reentrant iteration step for register and stack printing [v3] In-Reply-To: References: Message-ID: On Fri, 20 Jan 2023 10:11:54 GMT, Thomas Stuefe wrote: > Is this about the variable size of the object? In its simplest form, the approach could be done with a word-sized datum that fits into a void*, no additional memory needed. You can put the void* directly on the stack. > > In fact, we could even just pass an int, or a long, and declare this as continuation point which the implementation should interprete as it sees fit. On most platforms, that would correspond to the register number. Similar to what you do now. > > ``` > os::print_register_info(const ucontext_t* c, outputStream* st, int& continuation_point) { > // .. start printing at register number conti_point + 1 > } > ``` > > and > > ``` > os::print_register_info(const ucontext_t* c, outputStream* st) { > int conti_point = 0; > print_register_info(c, st, conti_point); > } > ``` > > You could hide those behind a typedef or a class for nicer aesthetics: > > ``` > typedef int continuation_point_t; > static const continuation_point_t INIT_POINT = 0; > ``` > > or > > ``` > class ContinuationPoint { > int _v; > ContinuationPoint() : _v(0) {} > int raw_value() ... > void increment() ... > } > ``` > > This would be a pragmatic approach that also translates well to printing callstacks, the other thing we want with more robustness. > I like the pragmatic approach with `os::print_register_info(const ucontext_t* c, outputStream* st, int& continuation_point)` more than `void*`. I will look into how this approach might look with callstacks as well. > I disagree with that. I find the `REENTRANT_STEP_IF` logic difficult to parse compared to the old solution. To me, it is also not clear how STEP timeouts are handled. Backporting fixes across such an intrusive patch would be painful. Fair enough. I generally dislike code duplication. Maybe just adding a multiple STEPs with some continuation logic will more easily please all parties (including future backporters). However it does lose the feature that it currently disables retrying based on stack depth, and number of global reentry failures. Can always add it explicitly to the repeated STEPs, a little verbose and in my own opinion a little harder to understand. > Side note, if others disagree with me and think this is the way to go, I won't hold up the patch. If the repeated STEPs and continuation logic produces less friction I am all for it. In the end the result that is most valuable is improved hs_err files. And that would be a nice step in that direction. ------------- PR: https://git.openjdk.org/jdk/pull/11017 From rehn at openjdk.org Fri Jan 20 11:36:32 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 20 Jan 2023 11:36:32 GMT Subject: RFR: JDK-8300651: Replace NULL with nullptr in share/runtime/ In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 12:27:23 GMT, Johan Sj?len wrote: > Do the conversion in the share/runtime/ sub-directory and all of its files. Thank you! ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.org/jdk/pull/12094 From sgehwolf at openjdk.org Fri Jan 20 12:59:26 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 20 Jan 2023 12:59:26 GMT Subject: RFR: 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values [v2] In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 17:24:57 GMT, Severin Gehwolf wrote: >> Please review this refactoring of a container test. It now uses WhiteBox to retrieve the host values it asserts for. In terms of functionality this is basically a no-op except for the now more precise assertion on systems with swap accounting disabled at the kernel level. >> >> *Testing* >> - [x] Container tests on Linux x86_64 cgv1 and cgv2 >> - [x] Container tests on Linux x86_64 cgv1 and cgv2 on systems with swapaccount=0 >> - [x] GHA in progress >> >> Thoughts? > > Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values GHA test failures seem unrelated. ------------- PR: https://git.openjdk.org/jdk/pull/12097 From coleenp at openjdk.org Fri Jan 20 13:23:38 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 20 Jan 2023 13:23:38 GMT Subject: RFR: 8300682: InstanceKlassMiscStatus is a bad name [v2] In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 22:22:44 GMT, Coleen Phillimore wrote: >> This patch is to simply rename InstanceKlassMiscStatus to InstanceKlassFlags. This matches the naming for upcoming Field changes that add a FieldFlags class. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix include guards. Thanks Fred and David. ------------- PR: https://git.openjdk.org/jdk/pull/12106 From coleenp at openjdk.org Fri Jan 20 13:23:41 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 20 Jan 2023 13:23:41 GMT Subject: Integrated: 8300682: InstanceKlassMiscStatus is a bad name In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 21:50:46 GMT, Coleen Phillimore wrote: > This patch is to simply rename InstanceKlassMiscStatus to InstanceKlassFlags. This matches the naming for upcoming Field changes that add a FieldFlags class. > Tested with tier1-4. This pull request has now been integrated. Changeset: 4562b402 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/4562b402fbfedbc3b531b19bf55638b00973b680 Stats: 183 lines in 6 files changed: 69 ins; 69 del; 45 mod 8300682: InstanceKlassMiscStatus is a bad name Reviewed-by: fparain, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/12106 From stuefe at openjdk.org Fri Jan 20 13:37:28 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 20 Jan 2023 13:37:28 GMT Subject: RFR: JDK-8300266: Detect Virtualization on Linux aarch64 [v2] In-Reply-To: References: Message-ID: On Fri, 20 Jan 2023 10:55:50 GMT, Matthias Baesken wrote: >> Currently we detect virtualization on Linux x86_64 (cpuid call) and Linux ppc64le ; the result is afterwards used e.g. in hs_err and JFR output. >> >> On Linux aarch64 the detection is missing, this should be added. >> One option would be to look at /sys/devices/virtual/dmi/id/product_name and related files , at least KVM and VMWare can be detected using these files. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > switch from NULL ot nullptr LGTM ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/12071 From lucy at openjdk.org Fri Jan 20 14:37:28 2023 From: lucy at openjdk.org (Lutz Schmidt) Date: Fri, 20 Jan 2023 14:37:28 GMT Subject: RFR: JDK-8300266: Detect Virtualization on Linux aarch64 [v2] In-Reply-To: References: Message-ID: <4Dq-xKOo8pgagZmrI2QlNJKaasuodn4CMO8seidlWr8=.754eeb19-140d-4311-8298-843d0e735346@github.com> On Fri, 20 Jan 2023 10:55:50 GMT, Matthias Baesken wrote: >> Currently we detect virtualization on Linux x86_64 (cpuid call) and Linux ppc64le ; the result is afterwards used e.g. in hs_err and JFR output. >> >> On Linux aarch64 the detection is missing, this should be added. >> One option would be to look at /sys/devices/virtual/dmi/id/product_name and related files , at least KVM and VMWare can be detected using these files. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > switch from NULL ot nullptr Looks good to me. ------------- Marked as reviewed by lucy (Reviewer). PR: https://git.openjdk.org/jdk/pull/12071 From jcking at openjdk.org Fri Jan 20 14:39:40 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 20 Jan 2023 14:39:40 GMT Subject: RFR: JDK-8300582: Introduce interface for unaligned memory accesses [v3] In-Reply-To: References: Message-ID: > Introduce interface for unaligned memory accesses `UnalignedAccess`, consolidate the byte swapping implementation to `byteswap`, and switch to a generic implementation of `Bytes`. Justin King has updated the pull request incrementally with one additional commit since the last revision: Simplify byteswap implementation Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12078/files - new: https://git.openjdk.org/jdk/pull/12078/files/b181ce9f..2c4d91eb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12078&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12078&range=01-02 Stats: 200 lines in 1 file changed: 114 ins; 46 del; 40 mod Patch: https://git.openjdk.org/jdk/pull/12078.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12078/head:pull/12078 PR: https://git.openjdk.org/jdk/pull/12078 From jcking at openjdk.org Fri Jan 20 14:39:41 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 20 Jan 2023 14:39:41 GMT Subject: RFR: JDK-8300582: Introduce interface for unaligned memory accesses [v2] In-Reply-To: References: Message-ID: <3A10qxki5JDDUU3_Ahe0OXlTSSyA8DXFTpJBknwLdrg=.e8111478-9cc3-4c7c-bd59-04dc674edd08@github.com> On Fri, 20 Jan 2023 06:34:34 GMT, David Holmes wrote: > I don't mind seeing some better code sharing in the "byte" stuff, but simply deleting all the platform specific files and then adding a tonne of platform ifdefs to what should be the shared code, has gone too far IMO. Okay, I realized after that all of the supported platforms use GCC/Clang, MSVC, or xlC. So we do not need the platform-specific headers. `byteswap` implementation is now more simple and follows the approach for `count_{leading,trailing}_zeros.hpp`. > Also I think the byte stuff should be separated out from the unaligned memory access interface. Thanks. I'll create a separate issue to consolidate the `byteswap` implementation and then re-base ontop of that when it is in. ------------- PR: https://git.openjdk.org/jdk/pull/12078 From jcking at openjdk.org Fri Jan 20 15:03:03 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 20 Jan 2023 15:03:03 GMT Subject: RFR: JDK-8300582: Introduce interface for unaligned memory accesses [v4] In-Reply-To: References: Message-ID: > Introduce interface for unaligned memory accesses `UnalignedAccess`, consolidate the byte swapping implementation to `byteswap`, and switch to a generic implementation of `Bytes`. Justin King has updated the pull request incrementally with two additional commits since the last revision: - Fix typo Signed-off-by: Justin King - Fix compilation Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12078/files - new: https://git.openjdk.org/jdk/pull/12078/files/2c4d91eb..793c7718 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12078&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12078&range=02-03 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12078.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12078/head:pull/12078 PR: https://git.openjdk.org/jdk/pull/12078 From jcking at openjdk.org Fri Jan 20 15:03:05 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 20 Jan 2023 15:03:05 GMT Subject: RFR: JDK-8300582: Introduce interface for unaligned memory accesses [v3] In-Reply-To: References: Message-ID: <_EDILEwCflUwXMBiVF9WGWcqEJUoNjdHAG-dJAWChFc=.6e0bfe1e-c17c-443a-be54-719fa2f838a7@github.com> On Fri, 20 Jan 2023 14:39:40 GMT, Justin King wrote: >> Introduce interface for unaligned memory accesses `UnalignedAccess`, consolidate the byte swapping implementation to `byteswap`, and switch to a generic implementation of `Bytes`. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Simplify byteswap implementation > > Signed-off-by: Justin King https://github.com/openjdk/jdk/pull/12114 for `byteswap`. ------------- PR: https://git.openjdk.org/jdk/pull/12078 From jcking at openjdk.org Fri Jan 20 15:03:23 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 20 Jan 2023 15:03:23 GMT Subject: RFR: JDK-8300783: Consolidate byteswap implementations Message-ID: Deduplicate byte swapping implementations by consolidating them into `utilities/byteswap.hpp`, following `std::byteswap` introduced in C++23. Further simplification of `Bytes` will follow in https://github.com/openjdk/jdk/pull/12078. ------------- Commit messages: - Fix typo - Consolidate byteswap implementations Changes: https://git.openjdk.org/jdk/pull/12114/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12114&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300783 Stats: 1051 lines in 21 files changed: 295 ins; 735 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/12114.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12114/head:pull/12114 PR: https://git.openjdk.org/jdk/pull/12114 From jcking at openjdk.org Fri Jan 20 15:11:51 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 20 Jan 2023 15:11:51 GMT Subject: RFR: JDK-8300582: Introduce interface for unaligned memory accesses [v5] In-Reply-To: References: Message-ID: > Introduce interface for unaligned memory accesses `UnalignedAccess`, consolidate the byte swapping implementation to `byteswap`, and switch to a generic implementation of `Bytes`. Justin King has updated the pull request incrementally with three additional commits since the last revision: - Fix template specialization Signed-off-by: Justin King - Fix static_assert for Microsoft Visual Studio Signed-off-by: Justin King - Remove final from ByteswapFallbackImpl Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12078/files - new: https://git.openjdk.org/jdk/pull/12078/files/793c7718..2e7ddd42 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12078&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12078&range=03-04 Stats: 42 lines in 1 file changed: 22 ins; 15 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/12078.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12078/head:pull/12078 PR: https://git.openjdk.org/jdk/pull/12078 From jcking at openjdk.org Fri Jan 20 15:13:53 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 20 Jan 2023 15:13:53 GMT Subject: RFR: JDK-8300783: Consolidate byteswap implementations [v2] In-Reply-To: References: Message-ID: > Deduplicate byte swapping implementations by consolidating them into `utilities/byteswap.hpp`, following `std::byteswap` introduced in C++23. Further simplification of `Bytes` will follow in https://github.com/openjdk/jdk/pull/12078. Justin King has updated the pull request incrementally with four additional commits since the last revision: - Consolidate more byte swapping Signed-off-by: Justin King - Fix template specialization Signed-off-by: Justin King - Fix static_assert for Microsoft Visual Studio Signed-off-by: Justin King - Remove final from ByteswapFallbackImpl Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12114/files - new: https://git.openjdk.org/jdk/pull/12114/files/2994a734..592d4f67 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12114&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12114&range=00-01 Stats: 71 lines in 2 files changed: 23 ins; 42 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/12114.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12114/head:pull/12114 PR: https://git.openjdk.org/jdk/pull/12114 From jcking at openjdk.org Fri Jan 20 15:17:54 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 20 Jan 2023 15:17:54 GMT Subject: RFR: JDK-8300582: Introduce interface for unaligned memory accesses [v2] In-Reply-To: References: Message-ID: On Fri, 20 Jan 2023 09:27:48 GMT, Andrew Haley wrote: >> src/hotspot/share/utilities/byteswap.hpp line 61: >> >>> 59: #include >>> 60: >>> 61: #if defined(_MSC_VER) >> >> I'd rather see OS specific header files to do all this than pollute what is supposed to be shared code with all this OS specific stuff. > >> I'd rather see OS specific header files to do all this than pollute what is supposed to be shared code with all this OS specific stuff. > > Definitely. Doubling back to this thread, I have now removed all the OS-specific stuff as I mentioned elsewhere. It was unnecessarily pedantic on my part to include it, considering all those platforms use GCC/Clang, MSVC, or XL C/C++. ------------- PR: https://git.openjdk.org/jdk/pull/12078 From jcking at openjdk.org Fri Jan 20 15:31:23 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 20 Jan 2023 15:31:23 GMT Subject: RFR: JDK-8300582: Introduce interface for unaligned memory accesses [v6] In-Reply-To: References: Message-ID: <5WND3nzWEpdHJ134m5T1Nbhfl2JvVoi7hYI-8Nu54u0=.a2ee53b5-40f0-47aa-9e20-5c36fbaa086d@github.com> > Introduce interface for unaligned memory accesses `UnalignedAccess`, consolidate the byte swapping implementation to `byteswap`, and switch to a generic implementation of `Bytes`. Justin King has updated the pull request incrementally with one additional commit since the last revision: Synchronize changes from other PR Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12078/files - new: https://git.openjdk.org/jdk/pull/12078/files/2e7ddd42..e2c5eba1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12078&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12078&range=04-05 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/12078.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12078/head:pull/12078 PR: https://git.openjdk.org/jdk/pull/12078 From jcking at openjdk.org Fri Jan 20 15:31:20 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 20 Jan 2023 15:31:20 GMT Subject: RFR: JDK-8300783: Consolidate byteswap implementations [v3] In-Reply-To: References: Message-ID: > Deduplicate byte swapping implementations by consolidating them into `utilities/byteswap.hpp`, following `std::byteswap` introduced in C++23. Further simplification of `Bytes` will follow in https://github.com/openjdk/jdk/pull/12078. Justin King has updated the pull request incrementally with two additional commits since the last revision: - Update comment to reflect previous commit change Signed-off-by: Justin King - Use __bulitin_bswap for GCC in debug builds Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12114/files - new: https://git.openjdk.org/jdk/pull/12114/files/592d4f67..36839937 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12114&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12114&range=01-02 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/12114.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12114/head:pull/12114 PR: https://git.openjdk.org/jdk/pull/12114 From jcking at openjdk.org Fri Jan 20 16:05:10 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 20 Jan 2023 16:05:10 GMT Subject: RFR: JDK-8300582: Introduce interface for unaligned memory accesses [v7] In-Reply-To: References: Message-ID: > Introduce interface for unaligned memory accesses `UnalignedAccess`, consolidate the byte swapping implementation to `byteswap`, and switch to a generic implementation of `Bytes`. Justin King has updated the pull request incrementally with one additional commit since the last revision: Fix Bytes::swap implementation to only swap on little endian Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12078/files - new: https://git.openjdk.org/jdk/pull/12078/files/e2c5eba1..6d20e943 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12078&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12078&range=05-06 Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/12078.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12078/head:pull/12078 PR: https://git.openjdk.org/jdk/pull/12078 From sgehwolf at openjdk.org Fri Jan 20 16:06:13 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 20 Jan 2023 16:06:13 GMT Subject: RFR: 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values [v2] In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 17:24:57 GMT, Severin Gehwolf wrote: >> Please review this refactoring of a container test. It now uses WhiteBox to retrieve the host values it asserts for. In terms of functionality this is basically a no-op except for the now more precise assertion on systems with swap accounting disabled at the kernel level. >> >> *Testing* >> - [x] Container tests on Linux x86_64 cgv1 and cgv2 >> - [x] Container tests on Linux x86_64 cgv1 and cgv2 on systems with swapaccount=0 >> - [x] GHA in progress >> >> Thoughts? > > Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision: > > 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values @MBaesken Hi! Could you please help review this as you've touched this area a bit? Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/12097 From jcking at openjdk.org Fri Jan 20 16:20:03 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 20 Jan 2023 16:20:03 GMT Subject: RFR: JDK-8300582: Introduce interface for unaligned memory accesses [v8] In-Reply-To: References: Message-ID: > Introduce interface for unaligned memory accesses `UnalignedAccess`, consolidate the byte swapping implementation to `byteswap`, and switch to a generic implementation of `Bytes`. Justin King has updated the pull request incrementally with one additional commit since the last revision: More static_assert, support oddly aligned types, and update style Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12078/files - new: https://git.openjdk.org/jdk/pull/12078/files/6d20e943..5e74e0a1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12078&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12078&range=06-07 Stats: 71 lines in 1 file changed: 29 ins; 18 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/12078.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12078/head:pull/12078 PR: https://git.openjdk.org/jdk/pull/12078 From bpb at openjdk.org Fri Jan 20 17:26:23 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 20 Jan 2023 17:26:23 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v17] In-Reply-To: References: Message-ID: > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8299684: Allocate buffer of fixed size unity in illegalCapacities() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11873/files - new: https://git.openjdk.org/jdk/pull/11873/files/040374bc..3b1eef25 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11873&range=15-16 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11873.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11873/head:pull/11873 PR: https://git.openjdk.org/jdk/pull/11873 From bpb at openjdk.org Fri Jan 20 17:26:25 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 20 Jan 2023 17:26:25 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v16] In-Reply-To: References: <_Q4DQU03y9ghePhsOBkypY4umDdG4ZWDYTwMQB879-M=.4a6bcaa3-78fd-45dc-8a7a-a63a6bba8e9c@github.com> <_9HNX36UyNqea-82du1juKCEGv5T8StcAGScA-T8S-Y=.baec0d25-e7b0-495a-a840-b8d5486c569f@github.com> Message-ID: On Thu, 19 Jan 2023 07:53:15 GMT, Alan Bateman wrote: >> test/jdk/java/nio/jni/NewDirectByteBuffer.java line 130: >> >>> 128: void illegalCapacities(long capacity) { >>> 129: assertThrows(IllegalArgumentException.class, () -> { >>> 130: long addr = UNSAFE.allocateMemory(capacity); >> >> How is `allocateMemory` going to respond to these illegal capacity requests? >> >> If we expect `newDirectByteBuffer` to throw then can't we use a dummy buffer value as it will never be used? > >> How is `allocateMemory` going to respond to these illegal capacity requests? >> >> If we expect `newDirectByteBuffer` to throw then can't we use a dummy buffer value as it will never be used? > > For illegalCapacities it should call allocateMemory with some fixed value, say 1, not capacity. Surprised the allocateMemory isn't failing for the test inputs. Changed allocation size to `1` in `illegalCapacities` in 3b1eef25b53dbeb36e4b3a8d6c279a5e0f5a5ae3. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From ccheung at openjdk.org Fri Jan 20 17:33:36 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 20 Jan 2023 17:33:36 GMT Subject: RFR: 8151413: os::allocation_granularity/page_size and friends return signed values [v6] In-Reply-To: References: Message-ID: On Fri, 20 Jan 2023 09:41:28 GMT, Afshin Zafari wrote: >> ### Description >> os::allocation_granularity/page_size and friends return signed values >> >> ### Patch >> - Type of `vm_page_size` and `vm_allocation_granularity` members of `OSInfo` class and their wrappers in `os` class changed to `size_t` >> - Initial value of them changed from -1 to 0. >> - In setters, checking for *set only once* condition is updated accordingly (comparing with 0 instead of -1). Also, checking the argument be positive is removed. >> - Equal to 0 (instead of `<= 0` ) is used to check if calling setters failed. >> - All `(size_t)` casting of getters removed. >> - In arithmetic and negation operations, the operand related to the getters casted to `(int)`. Otherwise, the Windows builds complain. >> - Explicitly casted to `(int)` where `jint` needed. >> - In ` align_up(T size, A alignment)`, assignment of variables of type `A` to type `T` (i.e., `T t = (A) a;`) should be safe. `T : size_t` and `A : int` won't compile. Fixed appropriately. >> - `"%d"` format-flags replaced with `SIZE_FORMAT`. >> - Type of `CompilerToVM::Data::vm_page_size` changed to `size_t`. >> >> ### Test >> tier1-5: all green, except an unrelated fail for whom a bug is already created. >> job-id: afshin-8151413-20230117-1255-40910454 > > Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge 'master' > - 8151413: os::allocation_granularity/page_size and friends return signed values > - 8151413: os::allocation_granularity/page_size and friends return signed values > - 8151413: os::allocation_granularity/page_size and friends return signed values > - 8151413: os::allocation_granularity/page_size and friends return signed values > - 8151413: os::allocation_granularity/page_size and friends return signed values Looks good except for a few copyright issues. src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 2: > 1: /* > 2: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. I'm not sure if we need to add this line for such a small change in the file. src/hotspot/share/runtime/osInfo.hpp line 2: > 1: /* > 2: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. You need to preserve the original year. It should be `2022, 2023,` test/hotspot/gtest/utilities/test_globalDefinitions.cpp line 2: > 1: /* > 2: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. Same as above, need to preserve the original year. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.org/jdk/pull/12091 From xuelei at openjdk.org Fri Jan 20 18:22:34 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 20 Jan 2023 18:22:34 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 In-Reply-To: References: <7NTMxoOgPK0vqq-XGKI350AKnIjnA8_OYKzZLhLMLOc=.cd43cc7d-eff3-4046-989a-98173ee98500@github.com> Message-ID: On Fri, 13 Jan 2023 08:00:55 GMT, Serguei Spitsyn wrote: >>> > I'm also curious: some of the sprintfs are C2 (src/hotspot/share/opto) - are your builds including C2? If so, why are you not running into the issue for those files? >>> >>> I'm new to hotspot. Do you know how could I enable C2? Thanks! >> >> Never mind, I got it from configuration help message (use --with-jvm-features=compiler2). > > @XueleiFan Could you, please, do not integrate until more cases with the same problem are fixed? @sspitsyn I'm going to integrate the changeset. Did you have further comment or need more time? ------------- PR: https://git.openjdk.org/jdk/pull/11935 From xuelei at openjdk.org Fri Jan 20 18:22:36 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 20 Jan 2023 18:22:36 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v8] In-Reply-To: References: Message-ID: On Fri, 20 Jan 2023 04:39:13 GMT, David Holmes wrote: > Nothing further from me. I think this is okay as-is now. Thanks. @dholmes-ora Thank you for the review! ------------- PR: https://git.openjdk.org/jdk/pull/11935 From alanb at openjdk.org Fri Jan 20 20:01:47 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 20 Jan 2023 20:01:47 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v17] In-Reply-To: References: Message-ID: On Fri, 20 Jan 2023 17:26:23 GMT, Brian Burkhalter wrote: >> Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299684: Allocate buffer of fixed size unity in illegalCapacities() Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11873 From never at openjdk.org Fri Jan 20 21:16:43 2023 From: never at openjdk.org (Tom Rodriguez) Date: Fri, 20 Jan 2023 21:16:43 GMT Subject: RFR: JDK-8299229: Allow UseZGC with JVMCI and enable nmethod entry barrier support [v3] In-Reply-To: References: Message-ID: <2uGd3ZRgjaRNt7_aytVc2C1sn44whfdbDAnLyPUEl_Y=.472f6fe4-05a0-40ed-be40-dfdbdb42f8dd@github.com> > This exposes the required ZGC values to JVMCI and adds support for nmethod entry barriers. The ZGC support is straightforward but the nmethod entry barrier required some reworking to fit better into JVMCI usage. I also removed the epoch based barrier since it was no longer used with simplified the assumptions on the JVMCI side. There is also a minor loom related fix to support post call nops included. I could move that into a separate PR if that would be preferred. Tom Rodriguez has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Replace NULL with nullptr in new code - Merge branch 'master' into tkr-zgc - Review fixes - Allow UseZGC with JVMCI and enable nmethod entry barrier support ------------- Changes: https://git.openjdk.org/jdk/pull/11996/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11996&range=02 Stats: 526 lines in 26 files changed: 337 ins; 66 del; 123 mod Patch: https://git.openjdk.org/jdk/pull/11996.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11996/head:pull/11996 PR: https://git.openjdk.org/jdk/pull/11996 From never at openjdk.org Fri Jan 20 21:19:18 2023 From: never at openjdk.org (Tom Rodriguez) Date: Fri, 20 Jan 2023 21:19:18 GMT Subject: RFR: JDK-8299229: Allow UseZGC with JVMCI and enable nmethod entry barrier support [v2] In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 21:23:36 GMT, Erik ?sterlund wrote: >> Tom Rodriguez has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: >> >> Allow UseZGC with JVMCI and enable nmethod entry barrier support > > src/hotspot/share/jvmci/jvmciCodeInstaller.cpp line 732: > >> 730: >> 731: if (UseZGC && _nmethod_entry_patch_offset == -1) { >> 732: // ZGC requires the use of entry barriers for correctness > > Note that G1 also requires nmethod entry barriers for correctness. We've been happily running without them for a long time which is why we're just now getting around to supporting them. Are we sitting on a ticking time bomb? I do want to make them required as of 21 but maybe we could defer that to a future commit once my Graal changes to support the entry barriers has landed? ------------- PR: https://git.openjdk.org/jdk/pull/11996 From tsteele at openjdk.org Fri Jan 20 23:16:05 2023 From: tsteele at openjdk.org (Tyler Steele) Date: Fri, 20 Jan 2023 23:16:05 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v4] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 18:10:47 GMT, Justin King wrote: > This leaves at least AIX as a potential problem. @backwaterred, does the AIX libc malloc() still exclusively use the data segment? Does free'd memory still stick to the process? I agree with @coleenp that AIX seems to still use the data segment and sbrk for dynamic memory allocation. I am not sure about memory sticking to the process. With these changes I see several of the gtests failing on AIX. [==========] 58 tests from 6 test cases ran. (3718 ms total) [ PASSED ] 53 tests. [ FAILED ] 5 tests, listed below: [ FAILED ] os.safefetchN_negative_vm [ FAILED ] os.safefetch32_negative_vm [ FAILED ] os.safefetchN_negative_current_null_vm [ FAILED ] os.safefetch32_negative_current_null_vm [ FAILED ] os.safefetch_negative_at_safepoint_vm I can experiment with the disclaim option as well. ------------- PR: https://git.openjdk.org/jdk/pull/11931 From coleenp at openjdk.org Fri Jan 20 23:36:06 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 20 Jan 2023 23:36:06 GMT Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable [v6] In-Reply-To: References: Message-ID: <6-3WZ7T5i_hbiXOMbckovv_omp4_L1vBYr4Ai8s_pA4=.5637471f-7b2d-4915-a80e-8595759d9413@github.com> On Thu, 12 Jan 2023 12:56:51 GMT, Leo Korinth wrote: >> I am replacing the old hash table with ResourceHashtable. In the process I am also removing the redundant `_length` field. By removing the `_length` field, a lot of asserts can be removed as the length will trivially match the length of the underlying table. >> >> I would like to have feedback on the addition of `unlink_destruct(Function&& should_remove)`. I added it because I prefer to use a functor object that can be used by lambdas instead of an iterator object. However, I did add code to "destruct" resource objects when they are removed instead of just letting them be to reflect that we use `delete` on c-heap objects. Maybe I should remove this "improvement" and then maybe implement the function by calling the existing unlink? > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > revert copyright year after changes There are further cleanups to do for this. ------------- Changes requested by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/11675 From sviswanathan at openjdk.org Fri Jan 20 23:57:03 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Fri, 20 Jan 2023 23:57:03 GMT Subject: RFR: JDK-8300584: Accelerate AVX-512 CRC32C for small buffers [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 23:10:12 GMT, Scott Gibbons wrote: >> Use AVX2 code for CRC32C for small buffers in the AVX-512 path. Breakeven buffer size between the two algorithms is on the order of 384 bytes. >> >> **Performance numbers for previous:** >> >> Benchmark (count) Mode Cnt Score Error Units >> TestCRC32C.testCRC32CUpdate 64 thrpt 4 66974.957 ? 8.872 ops/ms >> TestCRC32C.testCRC32CUpdate 128 thrpt 4 44224.810 ? 11.801 ops/ms >> TestCRC32C.testCRC32CUpdate 256 thrpt 4 63997.611 ? 173.577 ops/ms >> TestCRC32C.testCRC32CUpdate 512 thrpt 4 56068.683 ? 269.582 ops/ms >> TestCRC32C.testCRC32CUpdate 2048 thrpt 4 27048.098 ? 87.350 ops/ms >> TestCRC32C.testCRC32CUpdate 16384 thrpt 4 4066.736 ? 10.318 ops/ms >> TestCRC32C.testCRC32CUpdate 65536 thrpt 4 1040.754 ? 6.419 ops/ms >> >> >> **Performance numbers for this version:** >> >> Benchmark (count) Mode Cnt Score Error Units >> TestCRC32C.testCRC32CUpdate 64 thrpt 3 161659.326 ? 74.974 ops/ms >> TestCRC32C.testCRC32CUpdate 128 thrpt 3 88456.935 ? 11.940 ops/ms >> TestCRC32C.testCRC32CUpdate 256 thrpt 3 73254.993 ? 5.004 ops/ms >> TestCRC32C.testCRC32CUpdate 512 thrpt 3 56508.541 ? 298.229 ops/ms >> TestCRC32C.testCRC32CUpdate 2048 thrpt 3 26701.995 ? 31.369 ops/ms >> TestCRC32C.testCRC32CUpdate 16384 thrpt 3 4110.819 ? 4.618 ops/ms >> TestCRC32C.testCRC32CUpdate 65536 thrpt 3 1045.821 ? 2.037 ops/ms > > Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Incorporate review comments Looks good to me as well. ------------- Marked as reviewed by sviswanathan (Reviewer). PR: https://git.openjdk.org/jdk/pull/12079 From duke at openjdk.org Sat Jan 21 00:17:09 2023 From: duke at openjdk.org (Scott Gibbons) Date: Sat, 21 Jan 2023 00:17:09 GMT Subject: Integrated: JDK-8300584: Accelerate AVX-512 CRC32C for small buffers In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 19:21:58 GMT, Scott Gibbons wrote: > Use AVX2 code for CRC32C for small buffers in the AVX-512 path. Breakeven buffer size between the two algorithms is on the order of 384 bytes. > > **Performance numbers for previous:** > > Benchmark (count) Mode Cnt Score Error Units > TestCRC32C.testCRC32CUpdate 64 thrpt 4 66974.957 ? 8.872 ops/ms > TestCRC32C.testCRC32CUpdate 128 thrpt 4 44224.810 ? 11.801 ops/ms > TestCRC32C.testCRC32CUpdate 256 thrpt 4 63997.611 ? 173.577 ops/ms > TestCRC32C.testCRC32CUpdate 512 thrpt 4 56068.683 ? 269.582 ops/ms > TestCRC32C.testCRC32CUpdate 2048 thrpt 4 27048.098 ? 87.350 ops/ms > TestCRC32C.testCRC32CUpdate 16384 thrpt 4 4066.736 ? 10.318 ops/ms > TestCRC32C.testCRC32CUpdate 65536 thrpt 4 1040.754 ? 6.419 ops/ms > > > **Performance numbers for this version:** > > Benchmark (count) Mode Cnt Score Error Units > TestCRC32C.testCRC32CUpdate 64 thrpt 3 161659.326 ? 74.974 ops/ms > TestCRC32C.testCRC32CUpdate 128 thrpt 3 88456.935 ? 11.940 ops/ms > TestCRC32C.testCRC32CUpdate 256 thrpt 3 73254.993 ? 5.004 ops/ms > TestCRC32C.testCRC32CUpdate 512 thrpt 3 56508.541 ? 298.229 ops/ms > TestCRC32C.testCRC32CUpdate 2048 thrpt 3 26701.995 ? 31.369 ops/ms > TestCRC32C.testCRC32CUpdate 16384 thrpt 3 4110.819 ? 4.618 ops/ms > TestCRC32C.testCRC32CUpdate 65536 thrpt 3 1045.821 ? 2.037 ops/ms This pull request has now been integrated. Changeset: 7c2f77a4 Author: Scott Gibbons Committer: Sandhya Viswanathan URL: https://git.openjdk.org/jdk/commit/7c2f77a42293eb79829fce99bfce82e89a5df6d7 Stats: 23 lines in 1 file changed: 12 ins; 0 del; 11 mod 8300584: Accelerate AVX-512 CRC32C for small buffers Reviewed-by: kvn, sviswanathan ------------- PR: https://git.openjdk.org/jdk/pull/12079 From duke at openjdk.org Sat Jan 21 00:50:43 2023 From: duke at openjdk.org (Scott Gibbons) Date: Sat, 21 Jan 2023 00:50:43 GMT Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 Message-ID: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms. Encode performance: **Old:** Benchmark (maxNumBytes) Mode Cnt Score Error Units Base64Encode.testBase64Encode 1024 thrpt 3 4309.439 ? 2.632 ops/ms **New:** Benchmark (maxNumBytes) Mode Cnt Score Error Units Base64Encode.testBase64Encode 1024 thrpt 3 24211.397 ? 102.026 ops/ms Decode performance: **Old:** Benchmark (errorIndex) (lineSize) (maxNumBytes) Mode Cnt Score Error Units Base64Decode.testBase64Decode 144 4 1024 thrpt 3 3961.768 ? 93.409 ops/ms **New:** Benchmark (errorIndex) (lineSize) (maxNumBytes) Mode Cnt Score Error Units Base64Decode.testBase64Decode 144 4 1024 thrpt 3 14738.051 ? 24.383 ops/ms ------------- Commit messages: - Remove whitespace - Fix wrong register usage - Working version of Base64 decode with AVX2 (4x perf improvement). No URL support - Merge branch 'Base64-AVX2' of https://github.com/asgibbons/jdk into Base64-AVX2 - Merge branch 'openjdk:master' into Base64-AVX2 - Intermediate AVX2 for decode - Fix various AVX support function invocations to get Base64 generated for AVX2 Changes: https://git.openjdk.org/jdk/pull/12126/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300808 Stats: 150 lines in 7 files changed: 134 ins; 3 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/12126.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12126/head:pull/12126 PR: https://git.openjdk.org/jdk/pull/12126 From kbarrett at openjdk.org Sat Jan 21 14:55:03 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 21 Jan 2023 14:55:03 GMT Subject: RFR: JDK-8300260: Remove metaprogramming/isSame.hpp [v3] In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 17:15:41 GMT, Justin King wrote: >> Code cleanup of pre-C++11 implementations. > > Justin King has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' into remove-is-same > - Revert back from std::is_void to std::is_same > > Signed-off-by: Justin King > - Remove metaprogramming/isSame.hpp > > Signed-off-by: Justin King Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/12040 From jcking at openjdk.org Sat Jan 21 15:13:08 2023 From: jcking at openjdk.org (Justin King) Date: Sat, 21 Jan 2023 15:13:08 GMT Subject: Integrated: JDK-8300260: Remove metaprogramming/isSame.hpp In-Reply-To: References: Message-ID: <5HNf1Tqa3l2Y-j4nbwDY92kgo4YT3ZFzCV_ucFoeEQ0=.0a6de118-9b37-48e4-9451-669b719f3274@github.com> On Tue, 17 Jan 2023 14:07:54 GMT, Justin King wrote: > Code cleanup of pre-C++11 implementations. This pull request has now been integrated. Changeset: c8dd7583 Author: Justin King Committer: Kim Barrett URL: https://git.openjdk.org/jdk/commit/c8dd7583a92082bcd2a4dfd5429889e7f0a44050 Stats: 111 lines in 7 files changed: 2 ins; 93 del; 16 mod 8300260: Remove metaprogramming/isSame.hpp Reviewed-by: tschatzl, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/12040 From duke at openjdk.org Sat Jan 21 15:47:06 2023 From: duke at openjdk.org (Afshin Zafari) Date: Sat, 21 Jan 2023 15:47:06 GMT Subject: RFR: 8151413: os::allocation_granularity/page_size and friends return signed values [v6] In-Reply-To: References: Message-ID: On Fri, 20 Jan 2023 17:27:17 GMT, Calvin Cheung wrote: >> Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Merge 'master' >> - 8151413: os::allocation_granularity/page_size and friends return signed values >> - 8151413: os::allocation_granularity/page_size and friends return signed values >> - 8151413: os::allocation_granularity/page_size and friends return signed values >> - 8151413: os::allocation_granularity/page_size and friends return signed values >> - 8151413: os::allocation_granularity/page_size and friends return signed values > > src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 2: > >> 1: /* >> 2: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. > > I'm not sure if we need to add this line for such a small change in the file. This line is result of the merge with master (and it was a conflict). ------------- PR: https://git.openjdk.org/jdk/pull/12091 From duke at openjdk.org Sat Jan 21 16:05:25 2023 From: duke at openjdk.org (Afshin Zafari) Date: Sat, 21 Jan 2023 16:05:25 GMT Subject: RFR: 8151413: os::allocation_granularity/page_size and friends return signed values [v7] In-Reply-To: References: Message-ID: > ### Description > os::allocation_granularity/page_size and friends return signed values > > ### Patch > - Type of `vm_page_size` and `vm_allocation_granularity` members of `OSInfo` class and their wrappers in `os` class changed to `size_t` > - Initial value of them changed from -1 to 0. > - In setters, checking for *set only once* condition is updated accordingly (comparing with 0 instead of -1). Also, checking the argument be positive is removed. > - Equal to 0 (instead of `<= 0` ) is used to check if calling setters failed. > - All `(size_t)` casting of getters removed. > - In arithmetic and negation operations, the operand related to the getters casted to `(int)`. Otherwise, the Windows builds complain. > - Explicitly casted to `(int)` where `jint` needed. > - In ` align_up(T size, A alignment)`, assignment of variables of type `A` to type `T` (i.e., `T t = (A) a;`) should be safe. `T : size_t` and `A : int` won't compile. Fixed appropriately. > - `"%d"` format-flags replaced with `SIZE_FORMAT`. > - Type of `CompilerToVM::Data::vm_page_size` changed to `size_t`. > > ### Test > tier1-5: all green, except an unrelated fail for whom a bug is already created. > job-id: afshin-8151413-20230117-1255-40910454 Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: 8151413: os::allocation_granularity/page_size and friends return signed values ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12091/files - new: https://git.openjdk.org/jdk/pull/12091/files/2c707069..b91290bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12091&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12091&range=05-06 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12091.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12091/head:pull/12091 PR: https://git.openjdk.org/jdk/pull/12091 From jcking at openjdk.org Sat Jan 21 17:50:28 2023 From: jcking at openjdk.org (Justin King) Date: Sat, 21 Jan 2023 17:50:28 GMT Subject: RFR: JDK-8300783: Consolidate byteswap implementations [v4] In-Reply-To: References: Message-ID: > Deduplicate byte swapping implementations by consolidating them into `utilities/byteswap.hpp`, following `std::byteswap` introduced in C++23. Further simplification of `Bytes` will follow in https://github.com/openjdk/jdk/pull/12078. Justin King has updated the pull request incrementally with one additional commit since the last revision: Fix mistake in MSVC implementation Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12114/files - new: https://git.openjdk.org/jdk/pull/12114/files/36839937..ef87529d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12114&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12114&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12114.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12114/head:pull/12114 PR: https://git.openjdk.org/jdk/pull/12114 From jcking at openjdk.org Sat Jan 21 17:50:37 2023 From: jcking at openjdk.org (Justin King) Date: Sat, 21 Jan 2023 17:50:37 GMT Subject: RFR: JDK-8300582: Introduce interface for unaligned memory accesses [v9] In-Reply-To: References: Message-ID: > Introduce interface for unaligned memory accesses `UnalignedAccess`, consolidate the byte swapping implementation to `byteswap`, and switch to a generic implementation of `Bytes`. Justin King has updated the pull request incrementally with one additional commit since the last revision: Fix mistake in MSVC implementation Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12078/files - new: https://git.openjdk.org/jdk/pull/12078/files/5e74e0a1..06f1b481 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12078&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12078&range=07-08 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12078.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12078/head:pull/12078 PR: https://git.openjdk.org/jdk/pull/12078 From jcking at openjdk.org Sat Jan 21 18:04:41 2023 From: jcking at openjdk.org (Justin King) Date: Sat, 21 Jan 2023 18:04:41 GMT Subject: RFR: JDK-8300265: Remove metaprogramming/isSigned.hpp In-Reply-To: <5FdmclkgEZHyCgDKZvz2MZd0OyCCE2_oOLxZj8K9Ojs=.51b51fae-08c0-4bd1-be6f-f4b55cd72efd@github.com> References: <5FdmclkgEZHyCgDKZvz2MZd0OyCCE2_oOLxZj8K9Ojs=.51b51fae-08c0-4bd1-be6f-f4b55cd72efd@github.com> Message-ID: <1n9wYQnJZnR0P1_g10UkmlPZ7Qsr7FpwAkBQGztv2zs=.6dcad7aa-8d76-43a2-a8eb-38d6f116499d@github.com> On Tue, 17 Jan 2023 14:29:41 GMT, Justin King wrote: > Code cleanup of pre-C++11 implementations. Merged against master to resolve the conflict. VS Code merging interface was odd, but I believe I fixed it correctly. It decided to leave the file empty instead of deleting it. ------------- PR: https://git.openjdk.org/jdk/pull/12042 From jcking at openjdk.org Sat Jan 21 18:04:41 2023 From: jcking at openjdk.org (Justin King) Date: Sat, 21 Jan 2023 18:04:41 GMT Subject: RFR: JDK-8300265: Remove metaprogramming/isSigned.hpp [v2] In-Reply-To: <5FdmclkgEZHyCgDKZvz2MZd0OyCCE2_oOLxZj8K9Ojs=.51b51fae-08c0-4bd1-be6f-f4b55cd72efd@github.com> References: <5FdmclkgEZHyCgDKZvz2MZd0OyCCE2_oOLxZj8K9Ojs=.51b51fae-08c0-4bd1-be6f-f4b55cd72efd@github.com> Message-ID: <3grqTKjd8Fjh7YK-6OeYhnXCihKsZeP_BX6Ll5jfnNI=.f259d30c-5f0a-4b58-a836-94d8d86a68d6@github.com> > Code cleanup of pre-C++11 implementations. Justin King has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - VS Code merged wierdly Signed-off-by: Justin King - Merge remote-tracking branch 'upstream/master' into remove-is-signed - Remove metaprogramming/isSigned.hpp Signed-off-by: Justin King ------------- Changes: https://git.openjdk.org/jdk/pull/12042/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12042&range=01 Stats: 104 lines in 6 files changed: 3 ins; 90 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/12042.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12042/head:pull/12042 PR: https://git.openjdk.org/jdk/pull/12042 From jcking at openjdk.org Sat Jan 21 18:21:26 2023 From: jcking at openjdk.org (Justin King) Date: Sat, 21 Jan 2023 18:21:26 GMT Subject: RFR: JDK-8300783: Consolidate byteswap implementations [v5] In-Reply-To: References: Message-ID: > Deduplicate byte swapping implementations by consolidating them into `utilities/byteswap.hpp`, following `std::byteswap` introduced in C++23. Further simplification of `Bytes` will follow in https://github.com/openjdk/jdk/pull/12078. Justin King has updated the pull request incrementally with one additional commit since the last revision: Add XL C/C++ builtins Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12114/files - new: https://git.openjdk.org/jdk/pull/12114/files/ef87529d..9986ce35 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12114&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12114&range=03-04 Stats: 61 lines in 1 file changed: 58 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12114.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12114/head:pull/12114 PR: https://git.openjdk.org/jdk/pull/12114 From jcking at openjdk.org Sat Jan 21 18:21:38 2023 From: jcking at openjdk.org (Justin King) Date: Sat, 21 Jan 2023 18:21:38 GMT Subject: RFR: JDK-8300582: Introduce interface for unaligned memory accesses [v10] In-Reply-To: References: Message-ID: <0Ya_IR1LrXf5hfSfKDgip0n0tNNgPAgmQuXtzIozwVk=.f23ee645-4365-455a-a912-f3c23f5fda4e@github.com> > Introduce interface for unaligned memory accesses `UnalignedAccess`, consolidate the byte swapping implementation to `byteswap`, and switch to a generic implementation of `Bytes`. Justin King has updated the pull request incrementally with one additional commit since the last revision: Add XL C/C++ builtins Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12078/files - new: https://git.openjdk.org/jdk/pull/12078/files/06f1b481..31ac3bac Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12078&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12078&range=08-09 Stats: 61 lines in 1 file changed: 58 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12078.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12078/head:pull/12078 PR: https://git.openjdk.org/jdk/pull/12078 From duke at openjdk.org Sun Jan 22 11:41:05 2023 From: duke at openjdk.org (Alexandr Miloslavskiy) Date: Sun, 22 Jan 2023 11:41:05 GMT Subject: RFR: 8296469: Instrument VMError::report with reentrant iteration step for register and stack printing [v4] In-Reply-To: References: Message-ID: On Tue, 20 Dec 2022 14:59:55 GMT, Axel Boldt-Christmas wrote: >> Add reentrant step logic to VMError::report with an inner loop which enable the logic to recover at every step of the iteration. >> >> Before this change, if printing one register/stack position crashes then no more registers/stack positions will be printed. >> >> After this change even if the VM is unstable and some registers print_location crashes the hs_err printing will recover and keep attempting to print the rest of the registers or stack values. >> >> Enables the following >> ```C++ >> REENTRANT_STEP_IF("printing register info", _verbose && _context && _thread && Universe::is_fully_initialized()) >> os::print_register_info_header(st, _context); >> >> REENTRANT_LOOP_START(os::print_nth_register_info_max_index()) >> // decode register contents if possible >> ResourceMark rm(_thread); >> os::print_nth_register_info(st, REENTRANT_ITERATION_STEP, _context); >> REENTRANT_LOOP_END >> >> st->cr(); >> >> >> Testing: tier 1 and compiled Linux-x64/aarch64, MacOS-x64/aarch64, Windows x64 and cross-compiled Linux-x86/riscv/arm/ppc/s390x (GHA and some local) > > Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Restructure os::print_register_info interface > - Code syle and line length > - Merge Fix > - Merge remote-tracking branch 'upstream_jdk/master' into vmerror_report_register_stack_reentrant > - Fix whitespace > - Add reentrant reentry limits > - Add os::print_register_info_header > - VMError::report reentrant for register and stack print I'm studying JVM crashes for our product, which involves heavy JNI usage. In 26% of all JVM crash reports we received, string `error occurred during error reporting` is present. 6% if I exclude all crashes where some kind of corrupted state is present (GC crashes, compiler crashes, low memory). I investigated a few of these, and the most common reason for `error occurred during error reporting` is when a register contains `0x0000'0000'ffff'ffff` on Linux. The more generalized problem is when register/stack value points into `---p` memory region. Here are some examples, trimmed down and formatted for clarity: R9 =0x0000'0000'ffff'ffff R9 = [error occurred during error reporting (printing register info), id 0xb, SIGSEGV (0xb) at pc=0x00007ff26665f970] Dynamic libraries: 0'9000'0000-1'0000'0000 ---p 00000000 00:00 0 R10=0x0000'0000'd30f'12af R10= [error occurred during error reporting (printing register info), id 0xb, SIGSEGV (0xb) at pc=0x00007fe0891df970] Dynamic libraries: 0'c6f0'0000-1'0000'0000 ---p 00000000 00:00 0 R8 =0x0000'0000'ffff'ffff R8 = [error occurred during error reporting (printing register info), id 0xc0000005, EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007fffcf583046] My conclusions are: 1. The problem occurs often 2. Many, but not all, of these are rather trivial to fix by making value printing more robust. For example, when pointer value corresponds to `---p` memory region, there's definitely nothing else to print. It sounds reasonable to me to follow both paths at once - make code more robust where easily possible, and don't let one failed print prevent the other prints. ------------- PR: https://git.openjdk.org/jdk/pull/11017 From duke at openjdk.org Sun Jan 22 11:47:01 2023 From: duke at openjdk.org (Alexandr Miloslavskiy) Date: Sun, 22 Jan 2023 11:47:01 GMT Subject: RFR: 8296469: Instrument VMError::report with reentrant iteration step for register and stack printing [v4] In-Reply-To: References: Message-ID: On Sun, 22 Jan 2023 11:30:57 GMT, Alexandr Miloslavskiy wrote: > pointer value corresponds to ---p memory region Just to clarify a bit more, this could happen whenever a register contains some kind of 32-bit integer that is not even a pointer. Some examples include: * Unix timestamps * RGB pixel colors * Error codes such as -2 (`0xffff'fffe`) ------------- PR: https://git.openjdk.org/jdk/pull/11017 From kbarrett at openjdk.org Sun Jan 22 20:44:05 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 22 Jan 2023 20:44:05 GMT Subject: RFR: JDK-8300080: offset_of for GCC/Clang exhibits undefined behavior and is not always a compile-time constant [v4] In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 16:06:44 GMT, Justin King wrote: >> The implementation of `offset_of` for GCC/Clang only deals with types are aligned to 16 bytes or less, if they are more, such as `zCollectedHeap` the behavior is undefined. UBSan also suggests that `offset_of` is not always a compile time constant, as the stack trace came from the dynamic loader during library loading. This patch changes `offset_of` to use `offsetof` and disables the warning `invalid-offsetof` for the JVM. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Move attribute on lambda to correct location > > Signed-off-by: Justin King Looks good. src/hotspot/share/utilities/globalDefinitions_gcc.hpp line 142: > 140: > 141: // GCC/Clang warns about applying offsetof() to types that are not standard layout or calculating > 142: // offset directly when base address is NULL. Technically using offsetof() on non-standard layout is suggest s/Technically using/Using/ src/hotspot/share/utilities/globalDefinitions_gcc.hpp line 152: > 150: char* c = (char*)(void*)&dummyObj->field; \ > 151: return (size_t)(c - space); \ > 152: }()) The xlc version of this macro is the same as the old (before JDK-8294902) one from here, with a comment saying it is the same as the gcc version. Clearly that's no longer true. Either that one should also be updated or the comment updated. That's probably something for the aix-ppc port maintainers to decide. There ought to be a followup bug report for it though. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/11978 From kbarrett at openjdk.org Sun Jan 22 21:06:03 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 22 Jan 2023 21:06:03 GMT Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof [v3] In-Reply-To: <1hEloz4xpYz6Ofo_RItjyhbSYfv8OY_f11SSvCgFjL8=.8c3d3051-54fb-4436-be68-7b493ddb6af5@github.com> References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com> <1VvY0OUOTV6QoOICCC7D-bossOFuNcElgxJwOK0ATcg=.4d805893-07a4-4c0c-b9c0-82a2ee3be0cf@github.com> <1hEloz4xpYz6Ofo_RItjyhbSYfv8OY_f11SSvCgFjL8=.8c3d3051-54fb-4436-be68-7b493ddb6af5@github.com> Message-ID: On Tue, 17 Jan 2023 09:05:00 GMT, Xin Liu wrote: > > > What is the use-case for permitting use of `alignof`? Usually we don't add such permits without some use-case in mind. > > > [...] > > > I'm not opposed to permitting the use of `alignof`, but wondering why we might need it. > > > > > > Responding to myself, I've found a usage category where `alignof` would be appropriate. We have various places where we are aligning a pointer to the size of some type, where it would be more appropriate to align to the alignment of that type. See, for example, `Message::calc_size()` (logging/logAsyncWriter.hpp), which uses `sizeof(void*)` where it seems like it should be using `alignof(Message)`. > > Alignment of 'sizeof(void*)' here is a performance hint. We would like to see the address of next Message is aligned of pointer size. It eases the load instruction of 'Message::_output'. It's more effective to load from the aligned address. > > ``` > static constexpr size_t calc_size(size_t message_len) { > return align_up(sizeof(Message) + message_len + 1, sizeof(void*)); > } > ``` > > In this context, alignof(Message) is correct but a little bit wasteful. How is it wasteful? I think alignof(Message) is exactly what should be used, since the calculation is used to determine the positioning of the start of a Message object in memory. Given the current definition of Message the two are probably the same, but that's kind of accidental. ------------- PR: https://git.openjdk.org/jdk/pull/11761 From kbarrett at openjdk.org Sun Jan 22 21:24:07 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 22 Jan 2023 21:24:07 GMT Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof [v5] In-Reply-To: References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com> Message-ID: On Wed, 4 Jan 2023 13:23:08 GMT, Julian Waters wrote: >> The alignof operator was added by C++11. It returns the alignment for the given type. Various metaprogramming usages exist, in particular when using std::aligned_storage. Use of this operator should be permitted in HotSpot code. > > 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 ten additional commits since the last revision: > > - Hopefully final change > - Merge remote-tracking branch 'upstream/master' into alignof > - > - Merge remote-tracking branch 'upstream/master' into alignof > - Make section more brief > - Merge remote-tracking branch 'upstream/master' into alignof > - More Descriptive Version > - Merge remote-tracking branch 'upstream/master' into alignof > - HotSpot Style Guide should permit use of alignof Changes requested by kbarrett (Reviewer). doc/hotspot-style.md line 578: > 576: * `#include ` to use `std::nullptr_t` and `std::max_align_t`. > 577: > 578: Certain restrictions apply to the inclusion of ``. There are no restrictions on the inclusion of . Rather, there are restrictions on the use of the declarations provided by . doc/hotspot-style.md line 580: > 578: Certain restrictions apply to the inclusion of ``. > 579: > 580: * The `alignof` operator should always be preferred over `std::alignment_of<>`. I would really like to avoid "prefer" here. Even though "always preferred" has the right meaning, I've always thought that was a clumsy turn of phrase, unconditionalizing a conditional. Also "prefer over" read oddly to to me. It seems to be a less commonly used American English usage, with "prefer to" being more common. (And "prefer to" seems exclusively used in British English, with "prefer over" not being a thing in that dialect.) "Use the `alignof` operator rather than `std::alignment_of`." ------------- PR: https://git.openjdk.org/jdk/pull/11761 From dholmes at openjdk.org Sun Jan 22 22:18:06 2023 From: dholmes at openjdk.org (David Holmes) Date: Sun, 22 Jan 2023 22:18:06 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v8] In-Reply-To: References: Message-ID: <-dUevC7v-TgLD27ARVcoKTVMbxjBN5WAYxRjFqoNwxE=.0ebafba6-465d-48c9-b823-402c70a28d95@github.com> On Fri, 20 Jan 2023 18:20:10 GMT, Xue-Lei Andrew Fan wrote: >> Nothing further from me. I think this is okay as-is now. Thanks. > >> Nothing further from me. I think this is okay as-is now. Thanks. > > @dholmes-ora Thank you for the review! @XueleiFan You need two reviews before integrating a Hotspot change - thanks. ------------- PR: https://git.openjdk.org/jdk/pull/11935 From dholmes at openjdk.org Sun Jan 22 22:21:08 2023 From: dholmes at openjdk.org (David Holmes) Date: Sun, 22 Jan 2023 22:21:08 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v17] In-Reply-To: References: Message-ID: <_um7aUkLXTtU4kDpDy9l6Z_Pdn3ls7-KPAjzpzlZAVE=.df3935e3-f11d-452b-83cf-52e15a09c669@github.com> On Fri, 20 Jan 2023 17:26:23 GMT, Brian Burkhalter wrote: >> Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299684: Allocate buffer of fixed size unity in illegalCapacities() Nothing further from me. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/11873 From dholmes at openjdk.org Sun Jan 22 22:44:01 2023 From: dholmes at openjdk.org (David Holmes) Date: Sun, 22 Jan 2023 22:44:01 GMT Subject: RFR: JDK-8300266: Detect Virtualization on Linux aarch64 [v2] In-Reply-To: References: Message-ID: On Fri, 20 Jan 2023 10:55:50 GMT, Matthias Baesken wrote: >> Currently we detect virtualization on Linux x86_64 (cpuid call) and Linux ppc64le ; the result is afterwards used e.g. in hs_err and JFR output. >> >> On Linux aarch64 the detection is missing, this should be added. >> One option would be to look at /sys/devices/virtual/dmi/id/product_name and related files , at least KVM and VMWare can be detected using these files. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > switch from NULL ot nullptr Looks to me like these should all be moved to vm_version_.cpp. New RFE? ------------- PR: https://git.openjdk.org/jdk/pull/12071 From dholmes at openjdk.org Mon Jan 23 01:25:09 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 23 Jan 2023 01:25:09 GMT Subject: RFR: JDK-8300651: Replace NULL with nullptr in share/runtime/ In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 12:27:23 GMT, Johan Sj?len wrote: > Do the conversion in the share/runtime/ sub-directory and all of its files. Looks good but a few cases where nullptr should be null in comments for consistency with surrounding changes if nothing else. Thanks. src/hotspot/share/runtime/handshake.cpp line 706: > 704: > 705: bool HandshakeState::suspend_with_handshake() { > 706: assert(_handshakee->threadObj() != nullptr, "cannot suspend with a nullptr threadObj"); Use "null" in the message please. src/hotspot/share/runtime/java.cpp line 672: > 670: // first and here. Any future calls to EXCEPTION_MARK requires > 671: // that no pending exceptions exist. > 672: JavaThread* THREAD = JavaThread::current(); // can't be nullptr Change to null please src/hotspot/share/runtime/javaCalls.cpp line 98: > 96: _thread->set_active_handles(new_handles); // install new handle block and reset Java frame linkage > 97: > 98: assert (_thread->thread_state() != _thread_in_native, "cannot set native pc to null"); FYI this assertion message seems wrong and in fact the assertion is redundant so I'm removing it in https://github.com/openjdk/jdk/pull/12134. src/hotspot/share/runtime/mutexLocker.cpp line 175: > 173: void assert_locked_or_safepoint(const Mutex* lock) { > 174: // check if this thread owns the lock (common case) > 175: assert(lock != nullptr, "Need non-nullptr lock"); null for consistency src/hotspot/share/runtime/os.hpp line 300: > 298: // Fill in buffer with current local time as an ISO-8601 string. > 299: // E.g., YYYY-MM-DDThh:mm:ss.mmm+zzzz. > 300: // Returns buffer, or nullptr if it failed. Should be "null" to be consistent with L294 src/hotspot/share/runtime/sharedRuntime.cpp line 2141: > 2139: // at the end of it. If we happen to see that null then we can skip trying > 2140: // to patch. If we hit the window where the callee has a c2i in the > 2141: // from_compiled_entry and the nullptr isn't present yet then we lose the race null for consistency src/hotspot/share/runtime/threadSMR.hpp line 350: > 348: public: > 349: JavaThreadIterator(ThreadsList *list) : _list(list), _index(0) { > 350: assert(list != nullptr, "ThreadsList must not be nullptr."); null src/hotspot/share/runtime/vmStructs.hpp line 115: > 113: > 114: // The last entry is identified over in the serviceability agent by > 115: // the fact that it has a nullptr typeName null for consistency ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12094 From ccheung at openjdk.org Mon Jan 23 05:08:06 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Mon, 23 Jan 2023 05:08:06 GMT Subject: RFR: 8151413: os::allocation_granularity/page_size and friends return signed values [v7] In-Reply-To: References: Message-ID: On Sat, 21 Jan 2023 16:05:25 GMT, Afshin Zafari wrote: >> ### Description >> os::allocation_granularity/page_size and friends return signed values >> >> ### Patch >> - Type of `vm_page_size` and `vm_allocation_granularity` members of `OSInfo` class and their wrappers in `os` class changed to `size_t` >> - Initial value of them changed from -1 to 0. >> - In setters, checking for *set only once* condition is updated accordingly (comparing with 0 instead of -1). Also, checking the argument be positive is removed. >> - Equal to 0 (instead of `<= 0` ) is used to check if calling setters failed. >> - All `(size_t)` casting of getters removed. >> - In arithmetic and negation operations, the operand related to the getters casted to `(int)`. Otherwise, the Windows builds complain. >> - Explicitly casted to `(int)` where `jint` needed. >> - In ` align_up(T size, A alignment)`, assignment of variables of type `A` to type `T` (i.e., `T t = (A) a;`) should be safe. `T : size_t` and `A : int` won't compile. Fixed appropriately. >> - `"%d"` format-flags replaced with `SIZE_FORMAT`. >> - Type of `CompilerToVM::Data::vm_page_size` changed to `size_t`. >> >> ### Test >> tier1-5: all green, except an unrelated fail for whom a bug is already created. >> job-id: afshin-8151413-20230117-1255-40910454 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8151413: os::allocation_granularity/page_size and friends return signed values src/hotspot/share/runtime/osInfo.cpp line 2: > 1: /* > 2: * Copyright (c) 1997, 2022, 2023, Oracle and/or its affiliates. All rights reserved. You can drop the `2022,` in the above. ------------- PR: https://git.openjdk.org/jdk/pull/12091 From dholmes at openjdk.org Mon Jan 23 08:01:42 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 23 Jan 2023 08:01:42 GMT Subject: RFR: 8286775: Remove identical per-compiler definitions of unsigned integral types Message-ID: Trivial update to share the common typedef's. Testing: - Oracle tier 1 - 5 builds - GHA (TBD) Thanks. ------------- Commit messages: - 8286775: Remove identical per-compiler definitions of unsigned integral jtypes Changes: https://git.openjdk.org/jdk/pull/12136/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12136&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8286775 Stats: 32 lines in 4 files changed: 8 ins; 24 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12136.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12136/head:pull/12136 PR: https://git.openjdk.org/jdk/pull/12136 From rehn at openjdk.org Mon Jan 23 08:45:03 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Mon, 23 Jan 2023 08:45:03 GMT Subject: RFR: JDK-8300651: Replace NULL with nullptr in share/runtime/ In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 01:22:20 GMT, David Holmes wrote: > Looks good but a few cases where nullptr should be null in comments for consistency with surrounding changes if nothing else. Yes, good. The terminology used by posix is: "null pointer", so using lower case null I think is good. ------------- PR: https://git.openjdk.org/jdk/pull/12094 From duke at openjdk.org Mon Jan 23 09:22:11 2023 From: duke at openjdk.org (Afshin Zafari) Date: Mon, 23 Jan 2023 09:22:11 GMT Subject: RFR: 8151413: os::allocation_granularity/page_size and friends return signed values [v8] In-Reply-To: References: Message-ID: > ### Description > os::allocation_granularity/page_size and friends return signed values > > ### Patch > - Type of `vm_page_size` and `vm_allocation_granularity` members of `OSInfo` class and their wrappers in `os` class changed to `size_t` > - Initial value of them changed from -1 to 0. > - In setters, checking for *set only once* condition is updated accordingly (comparing with 0 instead of -1). Also, checking the argument be positive is removed. > - Equal to 0 (instead of `<= 0` ) is used to check if calling setters failed. > - All `(size_t)` casting of getters removed. > - In arithmetic and negation operations, the operand related to the getters casted to `(int)`. Otherwise, the Windows builds complain. > - Explicitly casted to `(int)` where `jint` needed. > - In ` align_up(T size, A alignment)`, assignment of variables of type `A` to type `T` (i.e., `T t = (A) a;`) should be safe. `T : size_t` and `A : int` won't compile. Fixed appropriately. > - `"%d"` format-flags replaced with `SIZE_FORMAT`. > - Type of `CompilerToVM::Data::vm_page_size` changed to `size_t`. > > ### Test > tier1-5: all green, except an unrelated fail for whom a bug is already created. > job-id: afshin-8151413-20230117-1255-40910454 Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: 8151413: os::allocation_granularity/page_size and friends return signed values ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12091/files - new: https://git.openjdk.org/jdk/pull/12091/files/b91290bc..2f58d7e1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12091&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12091&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12091.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12091/head:pull/12091 PR: https://git.openjdk.org/jdk/pull/12091 From mdoerr at openjdk.org Mon Jan 23 09:27:06 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 23 Jan 2023 09:27:06 GMT Subject: RFR: 8299817: [s390] AES-CTR mode intrinsic fails with multiple short update() calls In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 14:29:34 GMT, Lutz Schmidt wrote: > This PR addresses an issue in the AES-CTR mode intrinsic on s390. When a message is ciphered in multiple, small (< 16 bytes) segments, the result is incorrect. > > This is not just a band-aid fix. The issue was taken as a chance to restructure the code. though still complicated, It is now easier to read and (hopefully) understand. > > Except for the new jetreg test, the changes are purely s390. There are no side effects on other platforms. Issue-specific tests pass. Other tests are in progress. I will update this PR once they are complete. > > **Reviews and comments are very much appreciated.** > > @backwaterred could you please run some "official" s390 tests? Thanks. test/hotspot/jtreg/compiler/codegen/aes/Test8299817.java line 4: > 2: * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved. > 3: * Copyright (c) 2022 SAP SE. All rights reserved. > 4: * ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. Wrong Copyright header! Please also update the Copyright years. ------------- PR: https://git.openjdk.org/jdk/pull/11967 From jwaters at openjdk.org Mon Jan 23 09:47:09 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 23 Jan 2023 09:47:09 GMT Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof [v5] In-Reply-To: References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com> Message-ID: <_FBlfpPA9Q1KUYz-_5UZL_6TDWJlS3h6dtKMkwHiRtY=.4e80ea23-c557-413d-87f3-a5b301b5b14c@github.com> On Sun, 22 Jan 2023 21:10:21 GMT, Kim Barrett wrote: >> 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 ten additional commits since the last revision: >> >> - Hopefully final change >> - Merge remote-tracking branch 'upstream/master' into alignof >> - >> - Merge remote-tracking branch 'upstream/master' into alignof >> - Make section more brief >> - Merge remote-tracking branch 'upstream/master' into alignof >> - More Descriptive Version >> - Merge remote-tracking branch 'upstream/master' into alignof >> - HotSpot Style Guide should permit use of alignof > > doc/hotspot-style.md line 578: > >> 576: * `#include ` to use `std::nullptr_t` and `std::max_align_t`. >> 577: >> 578: Certain restrictions apply to the inclusion of ``. > > There are no restrictions on the inclusion of . Rather, there are restrictions on the > use of the declarations provided by . Will do, thanks > doc/hotspot-style.md line 580: > >> 578: Certain restrictions apply to the inclusion of ``. >> 579: >> 580: * The `alignof` operator should always be preferred over `std::alignment_of<>`. > > I would really like to avoid "prefer" here. Even though "always preferred" has > the right meaning, I've always thought that was a clumsy turn of phrase, > unconditionalizing a conditional. Also "prefer over" read oddly to to me. It > seems to be a less commonly used American English usage, with "prefer to" > being more common. (And "prefer to" seems exclusively used in British English, > with "prefer over" not being a thing in that dialect.) > > "Use the `alignof` operator rather than `std::alignment_of`." Changes have been made, sorry for the hassle ------------- PR: https://git.openjdk.org/jdk/pull/11761 From jwaters at openjdk.org Mon Jan 23 09:52:29 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 23 Jan 2023 09:52:29 GMT Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof [v6] In-Reply-To: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com> References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com> Message-ID: > The alignof operator was added by C++11. It returns the alignment for the given type. Various metaprogramming usages exist, in particular when using std::aligned_storage. Use of this operator should be permitted in HotSpot code. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Further Changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11761/files - new: https://git.openjdk.org/jdk/pull/11761/files/f3fa278c..29d73366 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11761&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11761&range=04-05 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11761.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11761/head:pull/11761 PR: https://git.openjdk.org/jdk/pull/11761 From kbarrett at openjdk.org Mon Jan 23 10:02:17 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 23 Jan 2023 10:02:17 GMT Subject: RFR: JDK-8299688: Adopt C++14 compatible std::bit_cast introduced in C++20 [v4] In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 16:19:51 GMT, Justin King wrote: >> Adopts a C++14 compatible implementation of [std::bit_cast](https://en.cppreference.com/w/cpp/numeric/bit_cast). >> >> `PrimitiveConversions::cast` is refactored into `bit_cast` and extended to support all compatible types. Additionally it makes use of `__builtin_bit_cast` when available, which is strictly well defined compared to fallback approaches which are sometimes lurking in undefined behavior territory. >> >> Lastly some legacy casting is updated to use `bit_cast` in `utilities/globalDefinitions.hpp`. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Remove addressof as nobody should be overloading operator& > > Signed-off-by: Justin King std::bit_cast covers cases beyond what's covered by PrimitiveConversions::cast. Trying to be compatible means we should be covering those additional cases, which this change is doing. However, it's not obvious those additional cases are useful to us. The additional constraints for PrimitiveConversions::cast also simplify the implementation (and testing). Indeed, there are some conversions provided by std::bit_cast and this change that I think I would prefer to actively not support. The pointer to pointer case is an example. I don't want such potentially dangerous casts "hidden" by using bit_cast. I'd very much prefer explicit static_cast or reinterpret_cast as appropriate. (I'm ambivalent about the integer<->pointer casts provided by PrimitiveConversions::cast, now thinking they were probaby a mistake.) And using bit_casts between pointers and floating point types? Yuck! At some point when we support C++20 we can consider globally replacing PrimitiveConversions::cast with std::bit_cast, but I'm not convinced this interim replacement should be done. Given the less restrictive conversions supported by std::bit_cast I'm not even entirely sure I'd want to do such a renaming. I know in the past I've suggested that as a possibility, but having now looked at the new function more carefully, I'm not so sure. src/hotspot/share/services/heapDumper.cpp line 1011: > 1009: return to; > 1010: } > 1011: I didn't know about this. The two uses should have been using PrimitiveConversions::cast rather than adding this. src/hotspot/share/utilities/bitCast.hpp line 41: > 39: // Trivial implementation when To and From are the same. > 40: template ::value)> > 41: constexpr To bit_cast(const From& from) { This is missing the tivially copiable requirement for std::bit_cast. Also, it seems like the is_same SFINAE should not be needed here. Why not just template ::value)> constexpr T bit_cast(const T& value) { return value; } src/hotspot/share/utilities/bitCast.hpp line 46: > 44: > 45: // From and To are integrals of the same size. We can simply static_cast without changing the bit > 46: // representation. The PrimitiveConversions version has a longer comment providing more justification for this implementation. Please retain that. src/hotspot/share/utilities/bitCast.hpp line 54: > 52: constexpr To bit_cast(const From& from) { > 53: #if HAS_BUILTIN(__builtin_bit_cast) && !defined(__APPLE__) > 54: return __builtin_bit_cast(To, from); Throughout, I see no good reason to uglify the code with platform-specific conditional code when the portable version is just fine. And then the supporting infrastructure to define that macro isn't needed. The `!defined(__APPLE__)` makes this seem particularly problematic. Is the new `HAS_BUILTIN` just broken? Or is `__builtin_bit_cast` broken for Macs? Or what? src/hotspot/share/utilities/bitCast.hpp line 63: > 61: template 62: ENABLE_IF(sizeof(To) == sizeof(From) && > 63: !std::is_same::value && No need for this, since an integral type and an enum type are by definition different. Similarly for the overload for the other direction. src/hotspot/share/utilities/bitCast.hpp line 191: > 189: return __builtin_bit_cast(To, from); > 190: #else > 191: // Most modern compilers will produce optimal code for memcpy. This comment is at odds with the comment in the preceding integer<->float conversion. I think the comment there is correct and this one is not. src/hotspot/share/utilities/bitCast.hpp line 192: > 190: #else > 191: // Most modern compilers will produce optimal code for memcpy. > 192: To to; This default constructs To, which is potentially problematic, and is also an extra requirement. I do see the corresponding restriction in the enabling constraints, but that isn't part of the Standard function's contract. The problem can be avoided, but since I'm not sure we should be making this change at all... src/hotspot/share/utilities/globalDefinitions.hpp line 28: > 26: #define SHARE_UTILITIES_GLOBALDEFINITIONS_HPP > 27: > 28: #include "utilities/bitCast.hpp" I think including bitCast here is problematic. globalDefinitions is included nearly everywhere, while bitcasting is only needed in a few. There is also a high risk of circular include dependencies when adding anything to this file's include list. It looks like this addition happens to work today, but... And as noted elsewhere, I'm not sure some of the changes being made here to use bit_cast should be made anyway. And if they should, perhaps the relevant code ought to be split out of this file. src/hotspot/share/utilities/globalDefinitions.hpp line 669: > 667: inline jlong jlong_cast (jdouble x) { return bit_cast(x); } > 668: inline julong julong_cast (jdouble x) { return bit_cast(x); } > 669: inline jdouble jdouble_cast (jlong x) { return bit_cast(x); } I think the changes to the jXXX_cast's should not be made. Instead, I think these should be eliminated and the relatively few uses should be changed to use PrimitiveConversions::cast / bit_cast directly. These functions have potentially unintended and problematic implicit conversions of the arguments. Such a change should have it's own PR. There's already a bug related to this: https://bugs.openjdk.org/browse/JDK-8297539 ------------- PR: https://git.openjdk.org/jdk/pull/11865 From kbarrett at openjdk.org Mon Jan 23 10:02:21 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 23 Jan 2023 10:02:21 GMT Subject: RFR: JDK-8299688: Adopt C++14 compatible std::bit_cast introduced in C++20 [v4] In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 07:44:10 GMT, Kim Barrett wrote: >> Justin King has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove addressof as nobody should be overloading operator& >> >> Signed-off-by: Justin King > > src/hotspot/share/utilities/bitCast.hpp line 41: > >> 39: // Trivial implementation when To and From are the same. >> 40: template ::value)> >> 41: constexpr To bit_cast(const From& from) { > > This is missing the tivially copiable requirement for std::bit_cast. Also, it seems like the is_same > SFINAE should not be needed here. Why not just > > template ::value)> > constexpr T bit_cast(const T& value) { > return value; > } The need for this overload to match the Standard specification is one of the reasons why I had refrained from doing something like this change. This overload's existence (slightly) complicates others by requiring an additional `!std::is_same` constraint. Since such a nop conversion hasn't arisen in our code (yet), there isn't currently a need for this. I also don't see any tests for it. ------------- PR: https://git.openjdk.org/jdk/pull/11865 From kbarrett at openjdk.org Mon Jan 23 10:09:04 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 23 Jan 2023 10:09:04 GMT Subject: RFR: 8286775: Remove identical per-compiler definitions of unsigned integral types In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 07:42:29 GMT, David Holmes wrote: > Trivial update to share the common typedef's. > > Testing: > - Oracle tier 1 - 5 builds > - GHA (TBD) > > Thanks. Looks good. Or you can take my suggestion and change from typedefs to type aliases. src/hotspot/share/utilities/globalDefinitions.hpp line 534: > 532: typedef uint16_t jushort; > 533: typedef uint32_t juint; > 534: typedef uint64_t julong; Suggest `using jubyte = uint8_t;` ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/12136 From kbarrett at openjdk.org Mon Jan 23 10:17:13 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 23 Jan 2023 10:17:13 GMT Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof [v6] In-Reply-To: References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com> Message-ID: <_PQgMSbDp6vCHD8sBrhaazfuqSgxb0gsVZN8dDFZZ0w=.32440e3d-4c8d-42fb-aa25-ad11537b90df@github.com> On Mon, 23 Jan 2023 09:52:29 GMT, Julian Waters wrote: >> The alignof operator was added by C++11. It returns the alignment for the given type. Various metaprogramming usages exist, in particular when using std::aligned_storage. Use of this operator should be permitted in HotSpot code. > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Further Changes Changes requested by kbarrett (Reviewer). doc/hotspot-style.md line 580: > 578: Certain restrictions apply to the declarations provided by ``. > 579: > 580: * The `alignof` operator should be utilized rather than `std::alignment_of<>`. s/utilized/used/ https://scientistseessquirrel.wordpress.com/2019/04/16/for-the-love-of-all-that-is-holy-stop-writing-utilize/ :) ------------- PR: https://git.openjdk.org/jdk/pull/11761 From kbarrett at openjdk.org Mon Jan 23 10:21:19 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 23 Jan 2023 10:21:19 GMT Subject: RFR: JDK-8300265: Remove metaprogramming/isSigned.hpp [v2] In-Reply-To: <3grqTKjd8Fjh7YK-6OeYhnXCihKsZeP_BX6Ll5jfnNI=.f259d30c-5f0a-4b58-a836-94d8d86a68d6@github.com> References: <5FdmclkgEZHyCgDKZvz2MZd0OyCCE2_oOLxZj8K9Ojs=.51b51fae-08c0-4bd1-be6f-f4b55cd72efd@github.com> <3grqTKjd8Fjh7YK-6OeYhnXCihKsZeP_BX6Ll5jfnNI=.f259d30c-5f0a-4b58-a836-94d8d86a68d6@github.com> Message-ID: On Sat, 21 Jan 2023 18:04:41 GMT, Justin King wrote: >> Code cleanup of pre-C++11 implementations. > > Justin King has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - VS Code merged wierdly > > Signed-off-by: Justin King > - Merge remote-tracking branch 'upstream/master' into remove-is-signed > - Remove metaprogramming/isSigned.hpp > > Signed-off-by: Justin King I think this is waiting for a new `integrate` command after the changes to deal with the merge conflict, to be followed by sponsorship. ------------- PR: https://git.openjdk.org/jdk/pull/12042 From eosterlund at openjdk.org Mon Jan 23 10:22:30 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 23 Jan 2023 10:22:30 GMT Subject: RFR: 8300253: Introduce AArch64 nzcv accessors [v3] In-Reply-To: References: Message-ID: > Some code, such as verification code, might want to run without changing the state of the system. To do that, it's useful to be able to get and set the nzcv flags. This enhancement aims at adding accessors for that. Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: Fix test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12038/files - new: https://git.openjdk.org/jdk/pull/12038/files/6dbd9871..fdae4a44 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12038&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12038&range=01-02 Stats: 908 lines in 2 files changed: 22 ins; 0 del; 886 mod Patch: https://git.openjdk.org/jdk/pull/12038.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12038/head:pull/12038 PR: https://git.openjdk.org/jdk/pull/12038 From eosterlund at openjdk.org Mon Jan 23 10:22:34 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 23 Jan 2023 10:22:34 GMT Subject: RFR: 8300253: Introduce AArch64 nzcv accessors [v2] In-Reply-To: References: Message-ID: On Fri, 20 Jan 2023 02:06:29 GMT, Hao Sun wrote: >> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: >> >> Add test > > test/hotspot/gtest/aarch64/aarch64-asmtest.py line 1462: > >> 1460: for system_reg in ["fpsr", "dczid_el0", "ctr_el0", "nzcv"]: >> 1461: generate (SystemOneRegOp, [ ["msr", system_reg] ]) >> 1462: generate (OneRegSystemOp, [ ["mrs", system_reg] ]) > > Suggestion: > > for system_reg in ["fpsr", "nzcv"]: > generate (SystemOneRegOp, [ ["msr", system_reg] ]) > > for system_reg in ["fpsr", "dczid_el0", "ctr_el0", "nzcv"]: > generate (OneRegSystemOp, [ ["mrs", system_reg] ]) > > > 1. `asmtest.out.h` should be updated as well. Note that it's generated by running `aarch64-asmtest.py` script. > 2. There are no instructions to "set/update" `dczid_el0` or `ctr_el0` in `macroAssembler_aarch64.hpp`. Here shows the warnings of running `python2 aarch64-asmtest.py`: > > aarch64ops.s: Assembler messages: > aarch64ops.s:202: Warning: specified register cannot be written to at operand 1 -- `msr dczid_el0,x27' > aarch64ops.s:206: Warning: specified register cannot be written to at operand 1 -- `msr ctr_el0,x11' Oops. I fixed the test and added the generated code as suggested. ------------- PR: https://git.openjdk.org/jdk/pull/12038 From duke at openjdk.org Mon Jan 23 10:53:13 2023 From: duke at openjdk.org (Fredrik Bredberg) Date: Mon, 23 Jan 2023 10:53:13 GMT Subject: Integrated: 8299795: Relativize locals in interpreter frames In-Reply-To: References: Message-ID: On Mon, 9 Jan 2023 10:30:06 GMT, Fredrik Bredberg wrote: > Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. > Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. > Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. This pull request has now been integrated. Changeset: f307e8c6 Author: Fredrik Bredberg Committer: Robbin Ehn URL: https://git.openjdk.org/jdk/commit/f307e8c667895c302e916124751456a5443353ce Stats: 224 lines in 40 files changed: 105 ins; 17 del; 102 mod 8299795: Relativize locals in interpreter frames Reviewed-by: coleenp, rehn, pchilanomate, mdoerr, fyang ------------- PR: https://git.openjdk.org/jdk/pull/11902 From jwaters at openjdk.org Mon Jan 23 11:05:11 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 23 Jan 2023 11:05:11 GMT Subject: RFR: JDK-8299688: Adopt C++14 compatible std::bit_cast introduced in C++20 [v4] In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 07:41:38 GMT, Kim Barrett wrote: >> Justin King has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove addressof as nobody should be overloading operator& >> >> Signed-off-by: Justin King > > src/hotspot/share/utilities/bitCast.hpp line 54: > >> 52: constexpr To bit_cast(const From& from) { >> 53: #if HAS_BUILTIN(__builtin_bit_cast) && !defined(__APPLE__) >> 54: return __builtin_bit_cast(To, from); > > Throughout, I see no good reason to uglify the code with platform-specific conditional code > when the portable version is just fine. And then the supporting infrastructure to define that > macro isn't needed. The `!defined(__APPLE__)` makes this seem particularly problematic. > Is the new `HAS_BUILTIN` just broken? Or is `__builtin_bit_cast` broken for Macs? Or what? I also don't like the direct call to __builtins either, gcc to my knowledge automatically replaces the appropriate builtins when optimization is specified ------------- PR: https://git.openjdk.org/jdk/pull/11865 From lkorinth at openjdk.org Mon Jan 23 11:24:32 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 23 Jan 2023 11:24:32 GMT Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable [v7] In-Reply-To: References: Message-ID: > I am replacing the old hash table with ResourceHashtable. In the process I am also removing the redundant `_length` field. By removing the `_length` field, a lot of asserts can be removed as the length will trivially match the length of the underlying table. > > I would like to have feedback on the addition of `unlink_destruct(Function&& should_remove)`. I added it because I prefer to use a functor object that can be used by lambdas instead of an iterator object. However, I did add code to "destruct" resource objects when they are removed instead of just letting them be to reflect that we use `delete` on c-heap objects. Maybe I should remove this "improvement" and then maybe implement the function by calling the existing unlink? Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: code_roots_list_contains is now locked, but we have problems with add() during nmethods_do ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11675/files - new: https://git.openjdk.org/jdk/pull/11675/files/a58ef05d..0ed0c851 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11675&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11675&range=05-06 Stats: 10 lines in 3 files changed: 9 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11675.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11675/head:pull/11675 PR: https://git.openjdk.org/jdk/pull/11675 From lkorinth at openjdk.org Mon Jan 23 11:29:09 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 23 Jan 2023 11:29:09 GMT Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable [v7] In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 11:24:32 GMT, Leo Korinth wrote: >> I am replacing the old hash table with ResourceHashtable. In the process I am also removing the redundant `_length` field. By removing the `_length` field, a lot of asserts can be removed as the length will trivially match the length of the underlying table. >> >> I would like to have feedback on the addition of `unlink_destruct(Function&& should_remove)`. I added it because I prefer to use a functor object that can be used by lambdas instead of an iterator object. However, I did add code to "destruct" resource objects when they are removed instead of just letting them be to reflect that we use `delete` on c-heap objects. Maybe I should remove this "improvement" and then maybe implement the function by calling the existing unlink? > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > code_roots_list_contains is now locked, but we have problems with add() during nmethods_do `code_roots_list_contains` is used in `assert`s, `gurantee`s and in heap verification code only. Make it locked so that we do not have to think about correctness as it will not affect production code (at least if we remove the `guarantee`). I also added new asserts that does fire when we do `add` to a hash table that we iterate in another thread. So we have at least one problem left that might possibly be fixed by iterating on a copy, looking into that now. ------------- PR: https://git.openjdk.org/jdk/pull/11675 From redestad at openjdk.org Mon Jan 23 12:02:11 2023 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 23 Jan 2023 12:02:11 GMT Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 In-Reply-To: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com> References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com> Message-ID: <3Kob2b4bJvwjTq240lCC9l5cj05WBtR2TfRbfdrlym4=.e4480f00-f43a-4c30-a1d6-655cfee241cc@github.com> On Sat, 21 Jan 2023 00:15:10 GMT, Scott Gibbons wrote: > Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms. > > Encode performance: > **Old:** > > Benchmark (maxNumBytes) Mode Cnt Score Error Units > Base64Encode.testBase64Encode 1024 thrpt 3 4309.439 ? 2.632 ops/ms > > > **New:** > > Benchmark (maxNumBytes) Mode Cnt Score Error Units > Base64Encode.testBase64Encode 1024 thrpt 3 24211.397 ? 102.026 ops/ms > > > Decode performance: > **Old:** > > Benchmark (errorIndex) (lineSize) (maxNumBytes) Mode Cnt Score Error Units > Base64Decode.testBase64Decode 144 4 1024 thrpt 3 3961.768 ? 93.409 ops/ms > > **New:** > Benchmark (errorIndex) (lineSize) (maxNumBytes) Mode Cnt Score Error Units > Base64Decode.testBase64Decode 144 4 1024 thrpt 3 14738.051 ? 24.383 ops/ms src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2661: > 2659: __ vpbroadcastq(xmm4, Address(r13, 0), Assembler::AVX_256bit); > 2660: __ vmovdqu(xmm11, Address(r13, 0x28)); > 2661: __ vpbroadcastb(xmm10, Address(r13, 0), Assembler::AVX_256bit); Sorry in advance since I'm probably reading this wrong: the data that `r13` is pointing to appears to be a repeated byte pattern (`0x2f2f2f...`), does this mean this `vpbroadcastb` and the `vpbroadcastq` above end up filling up their respective registers with the exact same bits? If so, and since neither of them is mutated in the code below, then perhaps this can be simplified a bit. ------------- PR: https://git.openjdk.org/jdk/pull/12126 From smonteith at openjdk.org Mon Jan 23 14:22:37 2023 From: smonteith at openjdk.org (Stuart Monteith) Date: Mon, 23 Jan 2023 14:22:37 GMT Subject: RFR: 8300253: Introduce AArch64 nzcv accessors [v3] In-Reply-To: References: Message-ID: <3wjJjNRUvLr73C5IVkUOTxdjnvYvEwHKw87ziYAvcsg=.05edd4d3-72fe-4075-9aa2-40c52f4a0dc4@github.com> On Mon, 23 Jan 2023 10:22:30 GMT, Erik ?sterlund wrote: >> Some code, such as verification code, might want to run without changing the state of the system. To do that, it's useful to be able to get and set the nzcv flags. This enhancement aims at adding accessors for that. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Fix test I tried it out, and it looks good to me. ------------- PR: https://git.openjdk.org/jdk/pull/12038 From aboldtch at openjdk.org Mon Jan 23 14:29:05 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 23 Jan 2023 14:29:05 GMT Subject: RFR: 8296469: Instrument VMError::report with reentrant iteration step for register and stack printing [v5] In-Reply-To: References: Message-ID: > Add reentrant step logic to VMError::report with an inner loop which enable the logic to recover at every step of the iteration. > > Before this change, if printing one register/stack position crashes then no more registers/stack positions will be printed. > > After this change even if the VM is unstable and some registers print_location crashes the hs_err printing will recover and keep attempting to print the rest of the registers or stack values. > > Enables the following > ```C++ > REENTRANT_STEP_IF("printing register info", _verbose && _context && _thread && Universe::is_fully_initialized()) > os::print_register_info_header(st, _context); > > REENTRANT_LOOP_START(os::print_nth_register_info_max_index()) > // decode register contents if possible > ResourceMark rm(_thread); > os::print_nth_register_info(st, REENTRANT_ITERATION_STEP, _context); > REENTRANT_LOOP_END > > st->cr(); > > > Testing: tier 1 and compiled Linux-x64/aarch64, MacOS-x64/aarch64, Windows x64 and cross-compiled Linux-x86/riscv/arm/ppc/s390x (GHA and some local) Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Copyright - Rework logic and use continuation state for reattempts - Merge remote-tracking branch 'upstream_jdk/master' into vmerror_report_register_stack_reentrant - Restructure os::print_register_info interface - Code syle and line length - Merge Fix - Merge remote-tracking branch 'upstream_jdk/master' into vmerror_report_register_stack_reentrant - Fix whitespace - Add reentrant reentry limits - Add os::print_register_info_header - ... and 1 more: https://git.openjdk.org/jdk/compare/45e4e009...33da9b2a ------------- Changes: https://git.openjdk.org/jdk/pull/11017/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11017&range=04 Stats: 515 lines in 17 files changed: 192 ins; 79 del; 244 mod Patch: https://git.openjdk.org/jdk/pull/11017.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11017/head:pull/11017 PR: https://git.openjdk.org/jdk/pull/11017 From aboldtch at openjdk.org Mon Jan 23 14:29:09 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 23 Jan 2023 14:29:09 GMT Subject: RFR: 8296469: Instrument VMError::report with reentrant iteration step for register and stack printing [v4] In-Reply-To: References: Message-ID: On Tue, 20 Dec 2022 14:59:55 GMT, Axel Boldt-Christmas wrote: >> Add reentrant step logic to VMError::report with an inner loop which enable the logic to recover at every step of the iteration. >> >> Before this change, if printing one register/stack position crashes then no more registers/stack positions will be printed. >> >> After this change even if the VM is unstable and some registers print_location crashes the hs_err printing will recover and keep attempting to print the rest of the registers or stack values. >> >> Enables the following >> ```C++ >> REENTRANT_STEP_IF("printing register info", _verbose && _context && _thread && Universe::is_fully_initialized()) >> os::print_register_info_header(st, _context); >> >> REENTRANT_LOOP_START(os::print_nth_register_info_max_index()) >> // decode register contents if possible >> ResourceMark rm(_thread); >> os::print_nth_register_info(st, REENTRANT_ITERATION_STEP, _context); >> REENTRANT_LOOP_END >> >> st->cr(); >> >> >> Testing: tier 1 and compiled Linux-x64/aarch64, MacOS-x64/aarch64, Windows x64 and cross-compiled Linux-x86/riscv/arm/ppc/s390x (GHA and some local) > > Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Restructure os::print_register_info interface > - Code syle and line length > - Merge Fix > - Merge remote-tracking branch 'upstream_jdk/master' into vmerror_report_register_stack_reentrant > - Fix whitespace > - Add reentrant reentry limits > - Add os::print_register_info_header > - VMError::report reentrant for register and stack print Reimplemented the logic with separate `REATTEMPT` steps. Also added this logic to the call stack printing. I kept the stack depth logic to not reattempt steps if there is low headroom. And the print location (both stack and registers) are seen as one step with respect to timeout, that is reattempts will not `record_step_start_time`. But the call stack printing reattempt will (it was explicitly stated in JBS that if normal printing with source info times out it should still print without). I remove the new test. Will rewrite tests for this using the `HsErrFileUtils`. But wanted to get your feedback @tstuefe on the new approach. ------------- PR: https://git.openjdk.org/jdk/pull/11017 From aboldtch at openjdk.org Mon Jan 23 14:32:55 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 23 Jan 2023 14:32:55 GMT Subject: RFR: 8296469: Instrument VMError::report with reentrant iteration step for register and stack printing [v6] In-Reply-To: References: Message-ID: > Add reentrant step logic to VMError::report with an inner loop which enable the logic to recover at every step of the iteration. > > Before this change, if printing one register/stack position crashes then no more registers/stack positions will be printed. > > After this change even if the VM is unstable and some registers print_location crashes the hs_err printing will recover and keep attempting to print the rest of the registers or stack values. > > Enables the following > ```C++ > REENTRANT_STEP_IF("printing register info", _verbose && _context && _thread && Universe::is_fully_initialized()) > os::print_register_info_header(st, _context); > > REENTRANT_LOOP_START(os::print_nth_register_info_max_index()) > // decode register contents if possible > ResourceMark rm(_thread); > os::print_nth_register_info(st, REENTRANT_ITERATION_STEP, _context); > REENTRANT_LOOP_END > > st->cr(); > > > Testing: tier 1 and compiled Linux-x64/aarch64, MacOS-x64/aarch64, Windows x64 and cross-compiled Linux-x86/riscv/arm/ppc/s390x (GHA and some local) Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Missed variable rename ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11017/files - new: https://git.openjdk.org/jdk/pull/11017/files/33da9b2a..22996e4a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11017&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11017&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11017.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11017/head:pull/11017 PR: https://git.openjdk.org/jdk/pull/11017 From aboldtch at openjdk.org Mon Jan 23 14:43:43 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 23 Jan 2023 14:43:43 GMT Subject: RFR: 8296469: Instrument VMError::report with reentrant iteration step for register and stack printing [v7] In-Reply-To: References: Message-ID: <3ak0aUzyPlZbrF8mXRquGWsbt16xEDzNDB8qN0Z1sF8=.da62caa2-baad-4fee-8ad5-5844a1440378@github.com> > Add reentrant step logic to VMError::report with an inner loop which enable the logic to recover at every step of the iteration. > > Before this change, if printing one register/stack position crashes then no more registers/stack positions will be printed. > > After this change even if the VM is unstable and some registers print_location crashes the hs_err printing will recover and keep attempting to print the rest of the registers or stack values. > > Enables the following > ```C++ > REENTRANT_STEP_IF("printing register info", _verbose && _context && _thread && Universe::is_fully_initialized()) > os::print_register_info_header(st, _context); > > REENTRANT_LOOP_START(os::print_nth_register_info_max_index()) > // decode register contents if possible > ResourceMark rm(_thread); > os::print_nth_register_info(st, REENTRANT_ITERATION_STEP, _context); > REENTRANT_LOOP_END > > st->cr(); > > > Testing: tier 1 and compiled Linux-x64/aarch64, MacOS-x64/aarch64, Windows x64 and cross-compiled Linux-x86/riscv/arm/ppc/s390x (GHA and some local) Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Fix and strengthen print_stack_location ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11017/files - new: https://git.openjdk.org/jdk/pull/11017/files/22996e4a..f60860d8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11017&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11017&range=05-06 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11017.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11017/head:pull/11017 PR: https://git.openjdk.org/jdk/pull/11017 From jcking at openjdk.org Mon Jan 23 15:54:07 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 23 Jan 2023 15:54:07 GMT Subject: RFR: JDK-8299688: Adopt C++14 compatible std::bit_cast introduced in C++20 [v5] In-Reply-To: References: Message-ID: <4pfTnkIRT_1AyyzOTm___x3rhcH0AXSVb6CKxd-_YuU=.e88853d6-61c1-43ef-b903-b411bfda4dbc@github.com> > Adopts a C++14 compatible implementation of [std::bit_cast](https://en.cppreference.com/w/cpp/numeric/bit_cast). > > `PrimitiveConversions::cast` is refactored into `bit_cast` and extended to support all compatible types. Additionally it makes use of `__builtin_bit_cast` when available, which is strictly well defined compared to fallback approaches which are sometimes lurking in undefined behavior territory. > > Lastly some legacy casting is updated to use `bit_cast` in `utilities/globalDefinitions.hpp`. Justin King has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: - Merge remote-tracking branch 'upstream/master' into bit-cast - Restrict supported use cases Signed-off-by: Justin King - Restrict supported use cases Signed-off-by: Justin King - Remove addressof as nobody should be overloading operator& Signed-off-by: Justin King - Sort includes and fix macro indentation Signed-off-by: Justin King - Apple Clang thinks __builtin_bit_cast is present when its not Signed-off-by: Justin King - Correctly handle const/volatile pointers Signed-off-by: Justin King - Use __builtin_bit_cast when available for every specialization of bit_cast Signed-off-by: Justin King - Minor cleanup Signed-off-by: Justin King - Ensure operator& overloading is ignored Signed-off-by: Justin King - ... and 8 more: https://git.openjdk.org/jdk/compare/c8dd7583...07648dd9 ------------- Changes: https://git.openjdk.org/jdk/pull/11865/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11865&range=04 Stats: 587 lines in 19 files changed: 299 ins; 235 del; 53 mod Patch: https://git.openjdk.org/jdk/pull/11865.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11865/head:pull/11865 PR: https://git.openjdk.org/jdk/pull/11865 From jcking at openjdk.org Mon Jan 23 16:02:09 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 23 Jan 2023 16:02:09 GMT Subject: RFR: JDK-8299688: Adopt C++14 compatible std::bit_cast introduced in C++20 [v6] In-Reply-To: References: Message-ID: > Adopts a C++14 compatible implementation of [std::bit_cast](https://en.cppreference.com/w/cpp/numeric/bit_cast). > > `PrimitiveConversions::cast` is refactored into `bit_cast` and extended to support all compatible types. Additionally it makes use of `__builtin_bit_cast` when available, which is strictly well defined compared to fallback approaches which are sometimes lurking in undefined behavior territory. > > Lastly some legacy casting is updated to use `bit_cast` in `utilities/globalDefinitions.hpp`. Justin King has updated the pull request incrementally with one additional commit since the last revision: Rollback changes to globalDefinitions.hpp Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11865/files - new: https://git.openjdk.org/jdk/pull/11865/files/07648dd9..b9fed0f2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11865&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11865&range=04-05 Stats: 26 lines in 1 file changed: 11 ins; 1 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/11865.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11865/head:pull/11865 PR: https://git.openjdk.org/jdk/pull/11865 From jcking at openjdk.org Mon Jan 23 16:14:02 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 23 Jan 2023 16:14:02 GMT Subject: Integrated: JDK-8300265: Remove metaprogramming/isSigned.hpp In-Reply-To: <5FdmclkgEZHyCgDKZvz2MZd0OyCCE2_oOLxZj8K9Ojs=.51b51fae-08c0-4bd1-be6f-f4b55cd72efd@github.com> References: <5FdmclkgEZHyCgDKZvz2MZd0OyCCE2_oOLxZj8K9Ojs=.51b51fae-08c0-4bd1-be6f-f4b55cd72efd@github.com> Message-ID: <1YvLijVqHjwzoqJiOSWNs4Wl2brpv0i_fYu2eTtG-FU=.e097797c-8db4-4342-939e-bbebf0a7cb25@github.com> On Tue, 17 Jan 2023 14:29:41 GMT, Justin King wrote: > Code cleanup of pre-C++11 implementations. This pull request has now been integrated. Changeset: 03a9a88e Author: Justin King Committer: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/03a9a88efbb68537e24b7de28c5b81d6cd8fdb04 Stats: 104 lines in 6 files changed: 3 ins; 90 del; 11 mod 8300265: Remove metaprogramming/isSigned.hpp Reviewed-by: kbarrett, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/12042 From qamai at openjdk.org Mon Jan 23 16:34:52 2023 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 23 Jan 2023 16:34:52 GMT Subject: RFR: 8286775: Remove identical per-compiler definitions of unsigned integral types In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 07:42:29 GMT, David Holmes wrote: > Trivial update to share the common typedef's. > > Testing: > - Oracle tier 1 - 5 builds > - GHA (TBD) > > Thanks. Can we do `using jubyte = std::make_unsigned::type`? Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/12136 From rkennke at openjdk.org Mon Jan 23 16:58:19 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 23 Jan 2023 16:58:19 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v14] In-Reply-To: References: Message-ID: > See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details. > > Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements. > > Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16. > > Testing: > - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390) > - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390) > - [x] tier1 (x86_64, x86_32, aarch64, riscv) > - [x] tier2 (x86_64, aarch64, riscv) > - [x] tier3 (x86_64, riscv) Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Remove unused method ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11044/files - new: https://git.openjdk.org/jdk/pull/11044/files/85317ab5..e40d5947 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=12-13 Stats: 9 lines in 1 file changed: 0 ins; 9 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11044.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11044/head:pull/11044 PR: https://git.openjdk.org/jdk/pull/11044 From ccheung at openjdk.org Mon Jan 23 17:14:46 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Mon, 23 Jan 2023 17:14:46 GMT Subject: RFR: 8151413: os::allocation_granularity/page_size and friends return signed values [v8] In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 09:22:11 GMT, Afshin Zafari wrote: >> ### Description >> os::allocation_granularity/page_size and friends return signed values >> >> ### Patch >> - Type of `vm_page_size` and `vm_allocation_granularity` members of `OSInfo` class and their wrappers in `os` class changed to `size_t` >> - Initial value of them changed from -1 to 0. >> - In setters, checking for *set only once* condition is updated accordingly (comparing with 0 instead of -1). Also, checking the argument be positive is removed. >> - Equal to 0 (instead of `<= 0` ) is used to check if calling setters failed. >> - All `(size_t)` casting of getters removed. >> - In arithmetic and negation operations, the operand related to the getters casted to `(int)`. Otherwise, the Windows builds complain. >> - Explicitly casted to `(int)` where `jint` needed. >> - In ` align_up(T size, A alignment)`, assignment of variables of type `A` to type `T` (i.e., `T t = (A) a;`) should be safe. `T : size_t` and `A : int` won't compile. Fixed appropriately. >> - `"%d"` format-flags replaced with `SIZE_FORMAT`. >> - Type of `CompilerToVM::Data::vm_page_size` changed to `size_t`. >> >> ### Test >> tier1-5: all green, except an unrelated fail for whom a bug is already created. >> job-id: afshin-8151413-20230117-1255-40910454 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8151413: os::allocation_granularity/page_size and friends return signed values Marked as reviewed by ccheung (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12091 From bpb at openjdk.org Mon Jan 23 17:22:39 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 23 Jan 2023 17:22:39 GMT Subject: Integrated: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly In-Reply-To: References: Message-ID: On Thu, 5 Jan 2023 22:25:19 GMT, Brian Burkhalter wrote: > Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. This pull request has now been integrated. Changeset: a56598f5 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/a56598f5a534cc9223367e7faa8433ea38661db9 Stats: 221 lines in 5 files changed: 212 ins; 3 del; 6 mod 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly Reviewed-by: dholmes, alanb ------------- PR: https://git.openjdk.org/jdk/pull/11873 From jcking at openjdk.org Mon Jan 23 17:32:00 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 23 Jan 2023 17:32:00 GMT Subject: RFR: JDK-8299688: Adopt C++14 compatible std::bit_cast introduced in C++20 [v7] In-Reply-To: References: Message-ID: > Adopts a C++14 compatible implementation of [std::bit_cast](https://en.cppreference.com/w/cpp/numeric/bit_cast). > > `PrimitiveConversions::cast` is refactored into `bit_cast` and extended to support all compatible types. Additionally it makes use of `__builtin_bit_cast` when available, which is strictly well defined compared to fallback approaches which are sometimes lurking in undefined behavior territory. > > Lastly some legacy casting is updated to use `bit_cast` in `utilities/globalDefinitions.hpp`. Justin King has updated the pull request incrementally with two additional commits since the last revision: - ALWAYSINLINE Signed-off-by: Justin King - Fix pointer casts Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11865/files - new: https://git.openjdk.org/jdk/pull/11865/files/b9fed0f2..9f245c9d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11865&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11865&range=05-06 Stats: 13 lines in 1 file changed: 1 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/11865.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11865/head:pull/11865 PR: https://git.openjdk.org/jdk/pull/11865 From duke at openjdk.org Mon Jan 23 18:16:37 2023 From: duke at openjdk.org (Scott Gibbons) Date: Mon, 23 Jan 2023 18:16:37 GMT Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 In-Reply-To: <3Kob2b4bJvwjTq240lCC9l5cj05WBtR2TfRbfdrlym4=.e4480f00-f43a-4c30-a1d6-655cfee241cc@github.com> References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com> <3Kob2b4bJvwjTq240lCC9l5cj05WBtR2TfRbfdrlym4=.e4480f00-f43a-4c30-a1d6-655cfee241cc@github.com> Message-ID: <4rPVZHCmgHP0h1TPuFriSOPqZ94jkoe2Q8MSfEUfF20=.e74257d0-c428-426e-98d6-78278b41c82f@github.com> On Mon, 23 Jan 2023 11:58:58 GMT, Claes Redestad wrote: >> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms. >> >> Encode performance: >> **Old:** >> >> Benchmark (maxNumBytes) Mode Cnt Score Error Units >> Base64Encode.testBase64Encode 1024 thrpt 3 4309.439 ? 2.632 ops/ms >> >> >> **New:** >> >> Benchmark (maxNumBytes) Mode Cnt Score Error Units >> Base64Encode.testBase64Encode 1024 thrpt 3 24211.397 ? 102.026 ops/ms >> >> >> Decode performance: >> **Old:** >> >> Benchmark (errorIndex) (lineSize) (maxNumBytes) Mode Cnt Score Error Units >> Base64Decode.testBase64Decode 144 4 1024 thrpt 3 3961.768 ? 93.409 ops/ms >> >> **New:** >> Benchmark (errorIndex) (lineSize) (maxNumBytes) Mode Cnt Score Error Units >> Base64Decode.testBase64Decode 144 4 1024 thrpt 3 14738.051 ? 24.383 ops/ms > > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2661: > >> 2659: __ vpbroadcastq(xmm4, Address(r13, 0), Assembler::AVX_256bit); >> 2660: __ vmovdqu(xmm11, Address(r13, 0x28)); >> 2661: __ vpbroadcastb(xmm10, Address(r13, 0), Assembler::AVX_256bit); > > Sorry in advance since I'm probably reading this wrong: the data that `r13` is pointing to appears to be a repeated byte pattern (`0x2f2f2f...`), does this mean this `vpbroadcastb` and the `vpbroadcastq` above end up filling up their respective registers with the exact same bits? If so, and since neither of them is mutated in the code below, then perhaps this can be simplified a bit. You're reading it correctly - this is redundant and could be handled differently, as the same value is being loaded into ymm4 and ymm10. I don't think there will be any significant performance gain either way. This was done in this manner to allow easier transition to URL acceleration when it is implemented, as URLs require handling '-' and '_' instead of '+' and '/' ('/' = 0x2f). ------------- PR: https://git.openjdk.org/jdk/pull/12126 From eosterlund at openjdk.org Mon Jan 23 18:23:27 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 23 Jan 2023 18:23:27 GMT Subject: RFR: 8300253: Introduce AArch64 nzcv accessors [v3] In-Reply-To: <3wjJjNRUvLr73C5IVkUOTxdjnvYvEwHKw87ziYAvcsg=.05edd4d3-72fe-4075-9aa2-40c52f4a0dc4@github.com> References: <3wjJjNRUvLr73C5IVkUOTxdjnvYvEwHKw87ziYAvcsg=.05edd4d3-72fe-4075-9aa2-40c52f4a0dc4@github.com> Message-ID: On Mon, 23 Jan 2023 14:19:43 GMT, Stuart Monteith wrote: > I tried it out, and it looks good to me. Thanks for the review! ------------- PR: https://git.openjdk.org/jdk/pull/12038 From jcking at openjdk.org Mon Jan 23 18:32:52 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 23 Jan 2023 18:32:52 GMT Subject: RFR: JDK-8300910: Remove metaprogramming/integralConstant.hpp Message-ID: Code cleanup of pre-C++11 implementations. ------------- Commit messages: - Remove metaprogramming/integralConstant.hpp Changes: https://git.openjdk.org/jdk/pull/12149/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12149&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300910 Stats: 109 lines in 8 files changed: 10 ins; 64 del; 35 mod Patch: https://git.openjdk.org/jdk/pull/12149.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12149/head:pull/12149 PR: https://git.openjdk.org/jdk/pull/12149 From jcking at openjdk.org Mon Jan 23 19:10:52 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 23 Jan 2023 19:10:52 GMT Subject: RFR: JDK-8299688: Adopt C++14 compatible std::bit_cast introduced in C++20 [v4] In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 08:05:54 GMT, Kim Barrett wrote: >> src/hotspot/share/utilities/bitCast.hpp line 41: >> >>> 39: // Trivial implementation when To and From are the same. >>> 40: template ::value)> >>> 41: constexpr To bit_cast(const From& from) { >> >> This is missing the tivially copiable requirement for std::bit_cast. Also, it seems like the is_same >> SFINAE should not be needed here. Why not just >> >> template ::value)> >> constexpr T bit_cast(const T& value) { >> return value; >> } > > The need for this overload to match the Standard specification is one of the reasons why I had refrained > from doing something like this change. This overload's existence (slightly) complicates others by requiring > an additional `!std::is_same` constraint. Since such a nop conversion hasn't arisen in our code > (yet), there isn't currently a need for this. I also don't see any tests for it. I removed the is_same. It technically isn't needed to conform. I also decided to not conform to the full standard and restrict uses based on the existing PrimitiveConversions::cast restrictions. ------------- PR: https://git.openjdk.org/jdk/pull/11865 From jcking at openjdk.org Mon Jan 23 19:10:50 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 23 Jan 2023 19:10:50 GMT Subject: RFR: JDK-8299688: Adopt C++14 compatible std::bit_cast introduced in C++20 [v8] In-Reply-To: References: Message-ID: > Adopts a C++14 compatible implementation of [std::bit_cast](https://en.cppreference.com/w/cpp/numeric/bit_cast). > > `PrimitiveConversions::cast` is refactored into `bit_cast` and extended to support all compatible types. Additionally it makes use of `__builtin_bit_cast` when available, which is strictly well defined compared to fallback approaches which are sometimes lurking in undefined behavior territory. > > Lastly some legacy casting is updated to use `bit_cast` in `utilities/globalDefinitions.hpp`. Justin King has updated the pull request incrementally with two additional commits since the last revision: - Documentation updates Signed-off-by: Justin King - Restore comment regarding integral casting Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11865/files - new: https://git.openjdk.org/jdk/pull/11865/files/9f245c9d..73b87d29 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11865&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11865&range=06-07 Stats: 14 lines in 1 file changed: 9 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11865.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11865/head:pull/11865 PR: https://git.openjdk.org/jdk/pull/11865 From jcking at openjdk.org Mon Jan 23 19:11:02 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 23 Jan 2023 19:11:02 GMT Subject: RFR: JDK-8299688: Adopt C++14 compatible std::bit_cast introduced in C++20 [v4] In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 07:42:40 GMT, Kim Barrett wrote: >> Justin King has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove addressof as nobody should be overloading operator& >> >> Signed-off-by: Justin King > > src/hotspot/share/utilities/bitCast.hpp line 46: > >> 44: >> 45: // From and To are integrals of the same size. We can simply static_cast without changing the bit >> 46: // representation. > > The PrimitiveConversions version has a longer comment providing more justification for this implementation. > Please retain that. Restored the comment. > src/hotspot/share/utilities/bitCast.hpp line 63: > >> 61: template > 62: ENABLE_IF(sizeof(To) == sizeof(From) && >> 63: !std::is_same::value && > > No need for this, since an integral type and an enum type are by definition different. Similarly for the > overload for the other direction. Done. > src/hotspot/share/utilities/bitCast.hpp line 191: > >> 189: return __builtin_bit_cast(To, from); >> 190: #else >> 191: // Most modern compilers will produce optimal code for memcpy. > > This comment is at odds with the comment in the preceding integer<->float conversion. I think the > comment there is correct and this one is not. Believed I fixed this. > src/hotspot/share/utilities/bitCast.hpp line 192: > >> 190: #else >> 191: // Most modern compilers will produce optimal code for memcpy. >> 192: To to; > > This default constructs To, which is potentially problematic, and is also an extra requirement. I do see > the corresponding restriction in the enabling constraints, but that isn't part of the Standard function's > contract. The problem can be avoided, but since I'm not sure we should be making this change at all... Removed the requirement, since I am strictly only supported what PrimitiveConversions::cast supported for now. > src/hotspot/share/utilities/globalDefinitions.hpp line 28: > >> 26: #define SHARE_UTILITIES_GLOBALDEFINITIONS_HPP >> 27: >> 28: #include "utilities/bitCast.hpp" > > I think including bitCast here is problematic. globalDefinitions is included nearly everywhere, while > bitcasting is only needed in a few. There is also a high risk of circular include dependencies when > adding anything to this file's include list. It looks like this addition happens to work today, but... > And as noted elsewhere, I'm not sure some of the changes being made here to use bit_cast should > be made anyway. And if they should, perhaps the relevant code ought to be split out of this file. Reverted changes to globalDefinitions.hpp. > src/hotspot/share/utilities/globalDefinitions.hpp line 669: > >> 667: inline jlong jlong_cast (jdouble x) { return bit_cast(x); } >> 668: inline julong julong_cast (jdouble x) { return bit_cast(x); } >> 669: inline jdouble jdouble_cast (jlong x) { return bit_cast(x); } > > I think the changes to the jXXX_cast's should not be made. Instead, I think these should be eliminated > and the relatively few uses should be changed to use PrimitiveConversions::cast / bit_cast directly. > These functions have potentially unintended and problematic implicit conversions of the arguments. > Such a change should have it's own PR. There's already a bug related to this: > https://bugs.openjdk.org/browse/JDK-8297539 Reverted changes to globalDefinitions.hpp. ------------- PR: https://git.openjdk.org/jdk/pull/11865 From jcking at openjdk.org Mon Jan 23 19:11:07 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 23 Jan 2023 19:11:07 GMT Subject: RFR: JDK-8299688: Adopt C++14 compatible std::bit_cast introduced in C++20 [v4] In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 11:01:48 GMT, Julian Waters wrote: >> src/hotspot/share/utilities/bitCast.hpp line 54: >> >>> 52: constexpr To bit_cast(const From& from) { >>> 53: #if HAS_BUILTIN(__builtin_bit_cast) && !defined(__APPLE__) >>> 54: return __builtin_bit_cast(To, from); >> >> Throughout, I see no good reason to uglify the code with platform-specific conditional code >> when the portable version is just fine. And then the supporting infrastructure to define that >> macro isn't needed. The `!defined(__APPLE__)` makes this seem particularly problematic. >> Is the new `HAS_BUILTIN` just broken? Or is `__builtin_bit_cast` broken for Macs? Or what? > > I also don't like the direct call to __builtins either, gcc to my knowledge automatically replaces the appropriate builtins when optimization is specified Apple Clang seemed to have a bug with the version we are using in GHA. I bumped them to 12.5.1 and the error disappeared. `__builtin_bit_cast` is used to implement std::bit_cast for Clang/GCC. It is purely a compiler construct IIRC and has no runtime function equivalent. It's always replaced with machine code for performing a byte-wise copy and ensures no shenanigans occur. Additionally std::bit_cast is the only way to convert between floating point and integral without invoking undefined behavior, though the union trick does currently work. The other option is std::memcpy. ------------- PR: https://git.openjdk.org/jdk/pull/11865 From kbarrett at openjdk.org Mon Jan 23 19:47:15 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 23 Jan 2023 19:47:15 GMT Subject: RFR: JDK-8300910: Remove metaprogramming/integralConstant.hpp In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 18:10:58 GMT, Justin King wrote: > Code cleanup of pre-C++11 implementations. Looks good. I'm surprised there aren't any occurrences in gtests, but apparently there aren't. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/12149 From eosterlund at openjdk.org Mon Jan 23 20:25:59 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 23 Jan 2023 20:25:59 GMT Subject: RFR: JDK-8299229: Allow UseZGC with JVMCI and enable nmethod entry barrier support [v3] In-Reply-To: <2uGd3ZRgjaRNt7_aytVc2C1sn44whfdbDAnLyPUEl_Y=.472f6fe4-05a0-40ed-be40-dfdbdb42f8dd@github.com> References: <2uGd3ZRgjaRNt7_aytVc2C1sn44whfdbDAnLyPUEl_Y=.472f6fe4-05a0-40ed-be40-dfdbdb42f8dd@github.com> Message-ID: <4AZcn88MF_6i6ZMOQ_UdHGe3DtNt7_OuSr0dzKxUc4E=.c0e0f7b5-8c00-4352-9a6c-516f3556cd7e@github.com> On Fri, 20 Jan 2023 21:16:43 GMT, Tom Rodriguez wrote: >> This exposes the required ZGC values to JVMCI and adds support for nmethod entry barriers. The ZGC support is straightforward but the nmethod entry barrier required some reworking to fit better into JVMCI usage. I also removed the epoch based barrier since it was no longer used with simplified the assumptions on the JVMCI side. There is also a minor loom related fix to support post call nops included. I could move that into a separate PR if that would be preferred. > > Tom Rodriguez has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Replace NULL with nullptr in new code > - Merge branch 'master' into tkr-zgc > - Review fixes > - Allow UseZGC with JVMCI and enable nmethod entry barrier support I think synchronization code is needed for accessing metadata from MDOs. And extra care around the extra data section. Stale metadata needs to be filtered, if the metadata is unloading. I don't see any code for that in this patch, so I have to assume it's missing. ------------- PR: https://git.openjdk.org/jdk/pull/11996 From never at openjdk.org Mon Jan 23 20:34:00 2023 From: never at openjdk.org (Tom Rodriguez) Date: Mon, 23 Jan 2023 20:34:00 GMT Subject: RFR: JDK-8299229: Allow UseZGC with JVMCI and enable nmethod entry barrier support [v4] In-Reply-To: References: Message-ID: <82zglGU9YCuc-BEAUVJ09xlmEt68DDSqGQ-090Wok20=.92ca342e-7d87-45d2-a23c-e9f4702b2572@github.com> > This exposes the required ZGC values to JVMCI and adds support for nmethod entry barriers. The ZGC support is straightforward but the nmethod entry barrier required some reworking to fit better into JVMCI usage. I also removed the epoch based barrier since it was no longer used with simplified the assumptions on the JVMCI side. There is also a minor loom related fix to support post call nops included. I could move that into a separate PR if that would be preferred. Tom Rodriguez has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Handle concurrent unloading - Merge branch 'master' into tkr-zgc - Add missing declaration - Replace NULL with nullptr in new code - Merge branch 'master' into tkr-zgc - Review fixes - Allow UseZGC with JVMCI and enable nmethod entry barrier support ------------- Changes: https://git.openjdk.org/jdk/pull/11996/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11996&range=03 Stats: 538 lines in 27 files changed: 349 ins; 66 del; 123 mod Patch: https://git.openjdk.org/jdk/pull/11996.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11996/head:pull/11996 PR: https://git.openjdk.org/jdk/pull/11996 From never at openjdk.org Mon Jan 23 20:37:45 2023 From: never at openjdk.org (Tom Rodriguez) Date: Mon, 23 Jan 2023 20:37:45 GMT Subject: RFR: JDK-8299229: Allow UseZGC with JVMCI and enable nmethod entry barrier support [v4] In-Reply-To: <82zglGU9YCuc-BEAUVJ09xlmEt68DDSqGQ-090Wok20=.92ca342e-7d87-45d2-a23c-e9f4702b2572@github.com> References: <82zglGU9YCuc-BEAUVJ09xlmEt68DDSqGQ-090Wok20=.92ca342e-7d87-45d2-a23c-e9f4702b2572@github.com> Message-ID: On Mon, 23 Jan 2023 20:34:00 GMT, Tom Rodriguez wrote: >> This exposes the required ZGC values to JVMCI and adds support for nmethod entry barriers. The ZGC support is straightforward but the nmethod entry barrier required some reworking to fit better into JVMCI usage. I also removed the epoch based barrier since it was no longer used with simplified the assumptions on the JVMCI side. There is also a minor loom related fix to support post call nops included. I could move that into a separate PR if that would be preferred. > > Tom Rodriguez has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Handle concurrent unloading > - Merge branch 'master' into tkr-zgc > - Add missing declaration > - Replace NULL with nullptr in new code > - Merge branch 'master' into tkr-zgc > - Review fixes > - Allow UseZGC with JVMCI and enable nmethod entry barrier support Sorry I've got too many branches in flight. Yes I hadn't included the is_loader_alive changes which mirror what's being done in the various CI translate methods that process the same information. I've push those changes. I'm not sure what locking you're talking about though as I don't see any obvious locking in the reading of this data in the CI. There is some locking of the extra_data_lock which mainly seems to be guarding against safepoints during this processing. There are no safepoints between the reading and the check so I'm not sure we need that. ------------- PR: https://git.openjdk.org/jdk/pull/11996 From redestad at openjdk.org Mon Jan 23 21:00:06 2023 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 23 Jan 2023 21:00:06 GMT Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 In-Reply-To: <4rPVZHCmgHP0h1TPuFriSOPqZ94jkoe2Q8MSfEUfF20=.e74257d0-c428-426e-98d6-78278b41c82f@github.com> References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com> <3Kob2b4bJvwjTq240lCC9l5cj05WBtR2TfRbfdrlym4=.e4480f00-f43a-4c30-a1d6-655cfee241cc@github.com> <4rPVZHCmgHP0h1TPuFriSOPqZ94jkoe2Q8MSfEUfF20=.e74257d0-c428-426e-98d6-78278b41c82f@github.com> Message-ID: On Mon, 23 Jan 2023 18:14:16 GMT, Scott Gibbons wrote: >> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2661: >> >>> 2659: __ vpbroadcastq(xmm4, Address(r13, 0), Assembler::AVX_256bit); >>> 2660: __ vmovdqu(xmm11, Address(r13, 0x28)); >>> 2661: __ vpbroadcastb(xmm10, Address(r13, 0), Assembler::AVX_256bit); >> >> Sorry in advance since I'm probably reading this wrong: the data that `r13` is pointing to appears to be a repeated byte pattern (`0x2f2f2f...`), does this mean this `vpbroadcastb` and the `vpbroadcastq` above end up filling up their respective registers with the exact same bits? If so, and since neither of them is mutated in the code below, then perhaps this can be simplified a bit. > > You're reading it correctly - this is redundant and could be handled differently, as the same value is being loaded into ymm4 and ymm10. I don't think there will be any significant performance gain either way. This was done in this manner to allow easier transition to URL acceleration when it is implemented, as URLs require handling '-' and '_' instead of '+' and '/' ('/' = 0x2f). I was mainly curious if there was some obscure detail or difference that eluded me. It wouldn't be the first time! As it's outside of the loop you're probably right about it not being very important to overall performance, though we should be mindful of setup overheads of transitioning into AVX code. Especially since inputs likely are skewed towards the smallest applicable lengths. I think it would be prudent to run and check the microbenchmark with values near the AVX2 threshold, such as `maxNumBytes = 48`. If you choose to keep the code as-is would you mind documenting the rationale behind the redundancy? (Is there WIP on more generalized URL acceleration that could be referenced?) ------------- PR: https://git.openjdk.org/jdk/pull/12126 From eosterlund at openjdk.org Mon Jan 23 21:40:10 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 23 Jan 2023 21:40:10 GMT Subject: RFR: JDK-8299229: Allow UseZGC with JVMCI and enable nmethod entry barrier support [v4] In-Reply-To: <82zglGU9YCuc-BEAUVJ09xlmEt68DDSqGQ-090Wok20=.92ca342e-7d87-45d2-a23c-e9f4702b2572@github.com> References: <82zglGU9YCuc-BEAUVJ09xlmEt68DDSqGQ-090Wok20=.92ca342e-7d87-45d2-a23c-e9f4702b2572@github.com> Message-ID: <6MuBr46NbiPKOCDhKpfUjPV9i1dByUlHu-kyGiqjLDc=.5a25636e-d9da-4e24-9531-2ce74e523718@github.com> On Mon, 23 Jan 2023 20:34:00 GMT, Tom Rodriguez wrote: >> This exposes the required ZGC values to JVMCI and adds support for nmethod entry barriers. The ZGC support is straightforward but the nmethod entry barrier required some reworking to fit better into JVMCI usage. I also removed the epoch based barrier since it was no longer used with simplified the assumptions on the JVMCI side. There is also a minor loom related fix to support post call nops included. I could move that into a separate PR if that would be preferred. > > Tom Rodriguez has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Handle concurrent unloading > - Merge branch 'master' into tkr-zgc > - Add missing declaration > - Replace NULL with nullptr in new code > - Merge branch 'master' into tkr-zgc > - Review fixes > - Allow UseZGC with JVMCI and enable nmethod entry barrier support There are speculative trap entries in the extra data section of the MDOs. Rows with stale metadata must be removed by the GC during class unloading. This used to be done in safepoints only, but with concurrent class unloading this is done while holding the extra_data_lock of the MDO. So naturally, for this to be sound, any reader that traverses these rows must hold the same lock (cf. https://github.com/openjdk/jdk/commit/f08eeac278b0785c0bdff0bddf46b66f65822357). ------------- PR: https://git.openjdk.org/jdk/pull/11996 From dholmes at openjdk.org Mon Jan 23 21:53:05 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 23 Jan 2023 21:53:05 GMT Subject: RFR: 8286775: Remove identical per-compiler definitions of unsigned integral jtypes In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 07:42:29 GMT, David Holmes wrote: > Trivial update to share the common typedef's. > > Testing: > - Oracle tier 1 - 5 builds > - GHA (TBD) > > Thanks. It is not obvious to me that either `using` or `std::make_unsigned` are permitted to be used under current hotspot style guidelines ?? What is the advantage/difference between `using` and `typedef`? ------------- PR: https://git.openjdk.org/jdk/pull/12136 From duke at openjdk.org Mon Jan 23 21:53:29 2023 From: duke at openjdk.org (Scott Gibbons) Date: Mon, 23 Jan 2023 21:53:29 GMT Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v2] In-Reply-To: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com> References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com> Message-ID: > Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms. > > Encode performance: > **Old:** > > Benchmark (maxNumBytes) Mode Cnt Score Error Units > Base64Encode.testBase64Encode 1024 thrpt 3 4309.439 ? 2.632 ops/ms > > > **New:** > > Benchmark (maxNumBytes) Mode Cnt Score Error Units > Base64Encode.testBase64Encode 1024 thrpt 3 24211.397 ? 102.026 ops/ms > > > Decode performance: > **Old:** > > Benchmark (errorIndex) (lineSize) (maxNumBytes) Mode Cnt Score Error Units > Base64Decode.testBase64Decode 144 4 1024 thrpt 3 3961.768 ? 93.409 ops/ms > > **New:** > Benchmark (errorIndex) (lineSize) (maxNumBytes) Mode Cnt Score Error Units > Base64Decode.testBase64Decode 144 4 1024 thrpt 3 14738.051 ? 24.383 ops/ms Scott Gibbons 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: - Merge branch 'openjdk:master' into Base64-AVX2 - Remove whitespace - Fix wrong register usage - Working version of Base64 decode with AVX2 (4x perf improvement). No URL support - Merge branch 'Base64-AVX2' of https://github.com/asgibbons/jdk into Base64-AVX2 - Merge branch 'openjdk:master' into Base64-AVX2 - Intermediate AVX2 for decode - Fix various AVX support function invocations to get Base64 generated for AVX2 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12126/files - new: https://git.openjdk.org/jdk/pull/12126/files/9cfa6bbd..0f4b9c88 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=00-01 Stats: 4398 lines in 281 files changed: 2042 ins; 692 del; 1664 mod Patch: https://git.openjdk.org/jdk/pull/12126.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12126/head:pull/12126 PR: https://git.openjdk.org/jdk/pull/12126 From dholmes at openjdk.org Mon Jan 23 22:11:03 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 23 Jan 2023 22:11:03 GMT Subject: RFR: 8286775: Remove identical per-compiler definitions of unsigned integral jtypes In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 07:42:29 GMT, David Holmes wrote: > Trivial update to share the common typedef's. > > Testing: > - Oracle tier 1 - 5 builds > - GHA (TBD) > > Thanks. Also it looks odd to start using `using` with all those other typedefs in there. Maybe we should have a separate RFE to switch from typedef to `using` if it is somehow better? ------------- PR: https://git.openjdk.org/jdk/pull/12136 From duke at openjdk.org Mon Jan 23 22:40:21 2023 From: duke at openjdk.org (Scott Gibbons) Date: Mon, 23 Jan 2023 22:40:21 GMT Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v3] In-Reply-To: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com> References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com> Message-ID: > Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms. > > Encode performance: > **Old:** > > Benchmark (maxNumBytes) Mode Cnt Score Error Units > Base64Encode.testBase64Encode 1024 thrpt 3 4309.439 ? 2.632 ops/ms > > > **New:** > > Benchmark (maxNumBytes) Mode Cnt Score Error Units > Base64Encode.testBase64Encode 1024 thrpt 3 24211.397 ? 102.026 ops/ms > > > Decode performance: > **Old:** > > Benchmark (errorIndex) (lineSize) (maxNumBytes) Mode Cnt Score Error Units > Base64Decode.testBase64Decode 144 4 1024 thrpt 3 3961.768 ? 93.409 ops/ms > > **New:** > Benchmark (errorIndex) (lineSize) (maxNumBytes) Mode Cnt Score Error Units > Base64Decode.testBase64Decode 144 4 1024 thrpt 3 14738.051 ? 24.383 ops/ms Scott Gibbons has updated the pull request incrementally with two additional commits since the last revision: - Merge branch 'Base64-AVX2' of https://github.com/asgibbons/jdk into Base64-AVX2 - Address review comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12126/files - new: https://git.openjdk.org/jdk/pull/12126/files/0f4b9c88..c776d90f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=01-02 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12126.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12126/head:pull/12126 PR: https://git.openjdk.org/jdk/pull/12126 From coleenp at openjdk.org Mon Jan 23 23:06:03 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 23 Jan 2023 23:06:03 GMT Subject: RFR: 8286775: Remove identical per-compiler definitions of unsigned integral jtypes In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 07:42:29 GMT, David Holmes wrote: > Trivial update to share the common typedef's. > > Testing: > - Oracle tier 1 - 5 builds > - GHA (TBD) > > Thanks. I was thinking the same thing - with all the typedefs in that file, especially below, having type aliases is going to be confusing. Maybe file an RFE to change them all? I have to admit I hadn't noticed that u1, u2 etc were typedef'ed to jubyte etc. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/12136 From dholmes at openjdk.org Tue Jan 24 00:25:14 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 24 Jan 2023 00:25:14 GMT Subject: RFR: 8286775: Remove identical per-compiler definitions of unsigned integral jtypes In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 07:42:29 GMT, David Holmes wrote: > Trivial update to share the common typedef's. > > Testing: > - Oracle tier 1 - 5 builds > - GHA (TBD) > > Thanks. I tested the `using jubyte = std::make_unsigned::type` version and it caused problems. macOS: open/src/hotspot/share/services/diagnosticArgument.cpp:315:45: error: format specifies type 'unsigned long long *' but the argument has type 'u8 *' (aka 'unsigned long *') [-Werror,-Wformat] int res = sscanf(str, UINT64_FORMAT "%c", &_value._val, &_value._multiplier); and Windows: c:\sb\prod\1674512381\workspace\open\src\hotspot\share\jfr\recorder\checkpoint\jfrCheckpointManager.cpp(472): error C2664: 'size_t write_thread_checkpoint_payloads(JfrChunkWriter &,const u1 *,size_t,u4 &)': cannot convert argument 4 from 'uint32_t' to 'u4 &' so I'm guessing the `using` directive establishes a different namespace for these types and they aren't considered to match the standard ones - even if the same size and signedness. As Kim and Coleen both approved this as-is I will integrate this simple cleanup version and leave conversion from typedef to a future RFE if that is deemed desirable. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/12136 From iklam at openjdk.org Tue Jan 24 00:25:21 2023 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 24 Jan 2023 00:25:21 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v17] In-Reply-To: References: Message-ID: On Fri, 20 Jan 2023 17:26:23 GMT, Brian Burkhalter wrote: >> Remove cast in `JNI::NewDirectByteBuffer`of `long` capacity to `int`, modify the constructor in question to accept a `long` capacity, and verify in the constructor that the capacity does not overflow `int` range, throwing IAE If it does. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8299684: Allocate buffer of fixed size unity in illegalCapacities() This PR is causing causing x86 build failures in GitHub actions. I filed https://bugs.openjdk.org/browse/JDK-8300942 ------------- PR: https://git.openjdk.org/jdk/pull/11873 From dholmes at openjdk.org Tue Jan 24 00:25:16 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 24 Jan 2023 00:25:16 GMT Subject: Integrated: 8286775: Remove identical per-compiler definitions of unsigned integral jtypes In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 07:42:29 GMT, David Holmes wrote: > Trivial update to share the common typedef's. > > Testing: > - Oracle tier 1 - 5 builds > - GHA (TBD) > > Thanks. This pull request has now been integrated. Changeset: 77a50105 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/77a50105f0c4a4cb7286dda13c633f1e69295210 Stats: 32 lines in 4 files changed: 8 ins; 24 del; 0 mod 8286775: Remove identical per-compiler definitions of unsigned integral jtypes Reviewed-by: kbarrett, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/12136 From never at openjdk.org Tue Jan 24 00:59:09 2023 From: never at openjdk.org (Tom Rodriguez) Date: Tue, 24 Jan 2023 00:59:09 GMT Subject: RFR: JDK-8299229: Allow UseZGC with JVMCI and enable nmethod entry barrier support [v4] In-Reply-To: <82zglGU9YCuc-BEAUVJ09xlmEt68DDSqGQ-090Wok20=.92ca342e-7d87-45d2-a23c-e9f4702b2572@github.com> References: <82zglGU9YCuc-BEAUVJ09xlmEt68DDSqGQ-090Wok20=.92ca342e-7d87-45d2-a23c-e9f4702b2572@github.com> Message-ID: On Mon, 23 Jan 2023 20:34:00 GMT, Tom Rodriguez wrote: >> This exposes the required ZGC values to JVMCI and adds support for nmethod entry barriers. The ZGC support is straightforward but the nmethod entry barrier required some reworking to fit better into JVMCI usage. I also removed the epoch based barrier since it was no longer used with simplified the assumptions on the JVMCI side. There is also a minor loom related fix to support post call nops included. I could move that into a separate PR if that would be preferred. > > Tom Rodriguez has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Handle concurrent unloading > - Merge branch 'master' into tkr-zgc > - Add missing declaration > - Replace NULL with nullptr in new code > - Merge branch 'master' into tkr-zgc > - Review fixes > - Allow UseZGC with JVMCI and enable nmethod entry barrier support Type profiles are never read from the extra data section by JVMCI and speculative_trap_data_tag isn't exposed at all. Exception seen flags are the only thing we search for in the extra data section and I'm not even sure why that's done. See https://github.com/tkrodriguez/jdk/blob/tkr-zgc/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotProfilingInfo.java#L144 and https://github.com/tkrodriguez/jdk/blob/tkr-zgc/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotProfilingInfo.java#L113. I could adjust the logic to simply disallow reads of Klass* from the extra data section until such a day as we actually need to support it. ------------- PR: https://git.openjdk.org/jdk/pull/11996 From bpb at openjdk.org Tue Jan 24 02:44:16 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 24 Jan 2023 02:44:16 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v17] In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 00:22:20 GMT, Ioi Lam wrote: > This PR is causing causing x86 build failures in GitHub actions. I filed https://bugs.openjdk.org/browse/JDK-8300942 PR #12157 has been created to address this problem. ------------- PR: https://git.openjdk.org/jdk/pull/11873 From dholmes at openjdk.org Tue Jan 24 06:54:14 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 24 Jan 2023 06:54:14 GMT Subject: RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v14] In-Reply-To: References: <1b3G5rQeMqfO1YyuB1oOylhjz6s0Un-pwDaXrZYZAt8=.e22dc3f0-621e-43fc-b3b8-651bfdcb6a2b@github.com> Message-ID: On Wed, 18 Jan 2023 16:54:45 GMT, Brian Burkhalter wrote: >> test/jdk/java/nio/jni/libNewDirectByteBuffer.c line 49: >> >>> 47: (JNIEnv *env, jclass cls, jobject buf) >>> 48: { >>> 49: return (jlong)(*env)->GetDirectBufferAddress(env, buf); >> >> The cast to jlong should be okay for 64-bit. For 32-bit then it will likely need a double cast, as in ((jlong)(int)( .. )) but maybe okay for now as you've restricted the test to 64-bit. > > Leaving it as-is for now. FTR this was the wrong choice as the test is still built on 32-bit (and fails to compile). ------------- PR: https://git.openjdk.org/jdk/pull/11873 From dholmes at openjdk.org Tue Jan 24 07:18:04 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 24 Jan 2023 07:18:04 GMT Subject: RFR: JDK-8300783: Consolidate byteswap implementations [v5] In-Reply-To: References: Message-ID: On Sat, 21 Jan 2023 18:21:26 GMT, Justin King wrote: >> Deduplicate byte swapping implementations by consolidating them into `utilities/byteswap.hpp`, following `std::byteswap` introduced in C++23. Further simplification of `Bytes` will follow in https://github.com/openjdk/jdk/pull/12078. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Add XL C/C++ builtins > > Signed-off-by: Justin King Looking like a good cleanup but can we not put the `swap_uN` definitions in `byteswap.hpp` so we don't repeat then for each platform? Thanks. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12114 From xliu at openjdk.org Tue Jan 24 07:45:04 2023 From: xliu at openjdk.org (Xin Liu) Date: Tue, 24 Jan 2023 07:45:04 GMT Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof [v3] In-Reply-To: References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com> <1VvY0OUOTV6QoOICCC7D-bossOFuNcElgxJwOK0ATcg=.4d805893-07a4-4c0c-b9c0-82a2ee3be0cf@github.com> <1hEloz4xpYz6Ofo_RItjyhbSYfv8OY_f11SSvCgFjL8=.8c3d3051-54fb-4436-be68-7b493ddb6af5@github.com> Message-ID: <1vFS7xsbqeW1z1TrrnwCuHCwfMbD54xglwPZP0kwNMc=.a495a2c5-501c-4151-bc7c-590b5c05b5fd@github.com> On Sun, 22 Jan 2023 21:03:27 GMT, Kim Barrett wrote: >>> > What is the use-case for permitting use of `alignof`? Usually we don't add such permits without some use-case in mind. >>> > [...] >>> > I'm not opposed to permitting the use of `alignof`, but wondering why we might need it. >>> >>> Responding to myself, I've found a usage category where `alignof` would be appropriate. We have various places where we are aligning a pointer to the size of some type, where it would be more appropriate to align to the alignment of that type. See, for example, `Message::calc_size()` (logging/logAsyncWriter.hpp), which uses `sizeof(void*)` where it seems like it should be using `alignof(Message)`. >> >> Alignment of 'sizeof(void*)' here is a performance hint. We would like to see the address of next Message is aligned of pointer size. It eases the load instruction of 'Message::_output'. It's more effective to load from the aligned address. >> >> >> static constexpr size_t calc_size(size_t message_len) { >> return align_up(sizeof(Message) + message_len + 1, sizeof(void*)); >> } >> >> >> In this context, alignof(Message) is correct but a little bit wasteful. > >> > > What is the use-case for permitting use of `alignof`? Usually we don't add such permits without some use-case in mind. >> > > [...] >> > > I'm not opposed to permitting the use of `alignof`, but wondering why we might need it. >> > >> > >> > Responding to myself, I've found a usage category where `alignof` would be appropriate. We have various places where we are aligning a pointer to the size of some type, where it would be more appropriate to align to the alignment of that type. See, for example, `Message::calc_size()` (logging/logAsyncWriter.hpp), which uses `sizeof(void*)` where it seems like it should be using `alignof(Message)`. >> >> Alignment of 'sizeof(void*)' here is a performance hint. We would like to see the address of next Message is aligned of pointer size. It eases the load instruction of 'Message::_output'. It's more effective to load from the aligned address. >> >> ``` >> static constexpr size_t calc_size(size_t message_len) { >> return align_up(sizeof(Message) + message_len + 1, sizeof(void*)); >> } >> ``` >> >> In this context, alignof(Message) is correct but a little bit wasteful. > > How is it wasteful? I think alignof(Message) is exactly what should be used, since the calculation is used > to determine the positioning of the start of a Message object in memory. Given the current definition of > Message the two are probably the same, but that's kind of accidental. hi, @kimbarrett Currently, sizeof(Message) is 64. Message is just a header. The real payload is Message + a '\0'-terminated c-str and pads. You are right about the purpose of 'calc_size()', but we don't load 'Message" as an object. We only load its fields individually. eg. *(message->_output). That's why I think it's good enough to align to the pointer size. Let's assume the log string is empty ''. calc_size(0) returns 72 now, so the next Message starts at buffer+72. *_output is still aligned load. If we alignof(Message), it starts with buffer+128. that takes 63 bytes to pad. thanks, --lx ------------- PR: https://git.openjdk.org/jdk/pull/11761 From mbaesken at openjdk.org Tue Jan 24 08:08:10 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 24 Jan 2023 08:08:10 GMT Subject: RFR: JDK-8300266: Detect Virtualization on Linux aarch64 [v2] In-Reply-To: References: Message-ID: On Sun, 22 Jan 2023 22:40:53 GMT, David Holmes wrote: > Looks to me like these should all be moved to vm_version_.cpp. New RFE? Hi David, this could indeed be a follow-up cleanup change. Lutz/Thomas, thanks for the reviews. ------------- PR: https://git.openjdk.org/jdk/pull/12071 From mbaesken at openjdk.org Tue Jan 24 08:08:12 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 24 Jan 2023 08:08:12 GMT Subject: Integrated: JDK-8300266: Detect Virtualization on Linux aarch64 In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 13:27:24 GMT, Matthias Baesken wrote: > Currently we detect virtualization on Linux x86_64 (cpuid call) and Linux ppc64le ; the result is afterwards used e.g. in hs_err and JFR output. > > On Linux aarch64 the detection is missing, this should be added. > One option would be to look at /sys/devices/virtual/dmi/id/product_name and related files , at least KVM and VMWare can be detected using these files. This pull request has now been integrated. Changeset: 544c16e0 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/544c16e0bdd4335b2624158fd1f6521984aa5079 Stats: 39 lines in 2 files changed: 39 ins; 0 del; 0 mod 8300266: Detect Virtualization on Linux aarch64 Reviewed-by: stuefe, lucy ------------- PR: https://git.openjdk.org/jdk/pull/12071 From stuefe at openjdk.org Tue Jan 24 08:14:31 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 24 Jan 2023 08:14:31 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v4] In-Reply-To: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> Message-ID: <_khJTogN_LFzv_VSMdncQeFf9zyMDgWGaiPRTuuXVl0=.2dad11d6-cc4e-46de-ad11-7bb607e8900e@github.com> > Rework NMT `MallocLimit` to make it more useful for native OOM analysis. Also remove `MallocMaxTestWords`, which had been mostly redundant with NMT (for background, see JDK-8293292). > > > ### Background > > Some months ago we had [JDK-8291919](https://bugs.openjdk.org/browse/JDK-8291919), a compiler regression that caused compiler arenas to grow boundlessly. Process was usually OOM-killed before we could take a look, so this was difficult to analyze. > > To improve analysis options, we added NMT *malloc limits* with [JDK-8291878](https://bugs.openjdk.org/browse/JDK-8291878). Malloc limits let us set one or multiple limits to malloc load. Surpassing a limit causes the VM to stop with a fatal error in the allocation function, giving us a hs-err file and a core right at the point that (probably) causes the leak. This makes error analysis a lot simpler, and is also valuable for regression-testing footprint usage. > > Some people wished for a way to not end with a fatal error but to mimic a native OOM (causing os::malloc to return NULL). This would allow us to test resilience in the face of native OOMs, among other things. > > ### Patch > > - Expands the `MallocLimit` option syntax, allowing for an "oom mode" that mimics an oom: > > > > Global form: > -XX:MallocLimit=[:] > Category-specific form: > -XX:MallocLimit=:[:][,:[:] ...] > Examples: > -XX:MallocLimit=3g > -XX:MallocLimit=3g:oom > -XX:MallocLimit=compiler:200m:oom > > > - moves parsing of `-XX:MallocLimit` out of arguments.cpp into `mallocLimit.hpp/cpp`, and rewrites it. > > - changes when limits are checked. Before, the limits were checked *after* the allocation that caused the threshold overflow. Now we check beforehand. > > - removes `MallocMaxTestWords`, replacing its uses with `MallocLimit` > > - adds new gtests and new jtreg tests > > - removes a bunch of jtreg tests which are now better served by the new gtests. > > - gives us more precise error messages upon reaching a limit. For example: > > before: > > # fatal error: MallocLimit: category "Compiler" reached limit (size: 20997680, limit: 20971520) > > > now: > > # fatal error: MallocLimit: reached category "Compiler" limit (triggering allocation size: 1920B, allocated so far: 20505K, limit: 20480K) Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Revert strchrnul ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11371/files - new: https://git.openjdk.org/jdk/pull/11371/files/3eb86536..c0d9dc85 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11371&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11371&range=02-03 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11371.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11371/head:pull/11371 PR: https://git.openjdk.org/jdk/pull/11371 From mbaesken at openjdk.org Tue Jan 24 08:51:06 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 24 Jan 2023 08:51:06 GMT Subject: RFR: 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values [v2] In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 17:24:57 GMT, Severin Gehwolf wrote: >> Please review this refactoring of a container test. It now uses WhiteBox to retrieve the host values it asserts for. In terms of functionality this is basically a no-op except for the now more precise assertion on systems with swap accounting disabled at the kernel level. >> >> *Testing* >> - [x] Container tests on Linux x86_64 cgv1 and cgv2 >> - [x] Container tests on Linux x86_64 cgv1 and cgv2 on systems with swapaccount=0 >> - [x] GHA in progress >> >> Thoughts? > > Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision: > > 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values Hi Severin, what do you think about renaming the methods to WB_HostPhysicalMemory / WB_HostPhysicalSwap to make it even more clear that the host values are meant ? On Linux we have values `_physical_memory = (julong)sysconf(_SC_PHYS_PAGES) * (julong)sysconf(_SC_PAGESIZE);` and `julong os::physical_memory()` from os_linux.cpp (including OSContainer::memory_limit_in_bytes()) so these could be 2 different values . And please adjust the COPYRIGHT years to 2023. ------------- PR: https://git.openjdk.org/jdk/pull/12097 From jwaters at openjdk.org Tue Jan 24 09:21:37 2023 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 24 Jan 2023 09:21:37 GMT Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof [v7] In-Reply-To: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com> References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com> Message-ID: > The alignof operator was added by C++11. It returns the alignment for the given type. Various metaprogramming usages exist, in particular when using std::aligned_storage. Use of this operator should be permitted in HotSpot code. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Oof ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11761/files - new: https://git.openjdk.org/jdk/pull/11761/files/29d73366..03e1e763 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11761&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11761&range=05-06 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11761.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11761/head:pull/11761 PR: https://git.openjdk.org/jdk/pull/11761 From jwaters at openjdk.org Tue Jan 24 09:21:39 2023 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 24 Jan 2023 09:21:39 GMT Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof [v6] In-Reply-To: <_PQgMSbDp6vCHD8sBrhaazfuqSgxb0gsVZN8dDFZZ0w=.32440e3d-4c8d-42fb-aa25-ad11537b90df@github.com> References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com> <_PQgMSbDp6vCHD8sBrhaazfuqSgxb0gsVZN8dDFZZ0w=.32440e3d-4c8d-42fb-aa25-ad11537b90df@github.com> Message-ID: On Mon, 23 Jan 2023 10:13:30 GMT, Kim Barrett wrote: >> Julian Waters has updated the pull request incrementally with one additional commit since the last revision: >> >> Further Changes > > doc/hotspot-style.md line 580: > >> 578: Certain restrictions apply to the declarations provided by ``. >> 579: >> 580: * The `alignof` operator should be utilized rather than `std::alignment_of<>`. > > s/utilized/used/ > https://scientistseessquirrel.wordpress.com/2019/04/16/for-the-love-of-all-that-is-holy-stop-writing-utilize/ > :) And here I was thinking this would sound more professional :P Speaking of which, could I include a condensed and shortened version of this part from our discussion above? I've left it out in the meantime but just wanted to ask in case > std::alignment_of<> could be used in advanced metaprogramming contexts involving higher order metafunctions. We don't do that sort of thing much at all in HotSpot. If someone finds a place where std::alignment_of<> might be better, we can revisit its status. ------------- PR: https://git.openjdk.org/jdk/pull/11761 From stuefe at openjdk.org Tue Jan 24 09:43:35 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 24 Jan 2023 09:43:35 GMT Subject: RFR: JDK-8293114: GC should trim the native heap [v5] In-Reply-To: <23KpPM4oPV6F1nz3g5CvIqvuX-ANcsMH4GuVNXjR-Lw=.b8d0fa2d-bb85-4899-8e21-f68ea64b988d@github.com> References: <23KpPM4oPV6F1nz3g5CvIqvuX-ANcsMH4GuVNXjR-Lw=.b8d0fa2d-bb85-4899-8e21-f68ea64b988d@github.com> Message-ID: > This RFE adds the option to auto-trim the Glibc heap as part of the GC cycle. If the VM process suffered high temporary malloc spikes (regardless whether from JVM- or user code), this could recover significant amounts of memory. > > We discussed this a year ago [1], but the item got pushed to the bottom of my work pile, therefore it took longer than I thought. > > ### Motivation > > The Glibc allocator is reluctant to return memory to the OS, much more so than other allocators. Temporary malloc spikes often carry over as permanent RSS increase. > > Note that C-heap retention is difficult to observe. Since it is freed memory, it won't show up in NMT, it is just a part of private RSS. > > Theoretically, retained memory is not lost since it will be reused by future mallocs. Retaining memory is therefore a bet on the future behavior of the app. The allocator bets on the application needing memory in the near future, and to satisfy that need via malloc. > > But an app's malloc load can fluctuate wildly, with temporary spikes and long idle periods. And if the app rolls its own custom allocators atop of mmap, as hotspot does, a lot of that memory cannot be reused even though it counts toward its memory footprint. > > To help, Glibc exports an API to trim the C-heap: `malloc_trim(3)`. With JDK 18 [2], SAP contributed a new jcmd command to *manually* trim the C-heap on Linux. This RFE adds a complementary way to trim automatically. > > #### Is this even a problem? > > Do we have high malloc spikes in the JVM process? We assume that malloc load from hotspot is usually low since hotspot typically clusters allocations into custom areas - metaspace, code heap, arenas. > > But arenas are subject to Glibc mem retention too. I was surprised by that since I assumed 32k arena chunks were too big to be subject of Glibc retention. But I saw in experiments that high arena peaks often cause lasting RSS increase. > > And of course, both hotspot and JDK do a lot of finer-granular mallocs outside of custom allocators. > > But many cases of high memory retention in Glibc I have seen in third-party JNI code. Libraries allocate large buffers via malloc as temporary buffers. In fact, since we introduced the jcmd "System.trim_native_heap", some of our customers started to call this command periodically in scripts to counter these issues. > > Therefore I think while high malloc spikes are atypical for a JVM process, they can happen. Having a way to auto-trim the native heap makes sense. > > ### When should we trim? > > We want to trim when we know there is a lull in malloc activity coming. But we have no knowledge of the future. > > We could build a heuristic based on malloc frequency. But on closer inspection that is difficult. We cannot use NMT, since NMT has no complete picture (only knows hotspot) and is usually disabled in production anyway. The only way to get *all* mallocs would be to use Glibc malloc hooks. We have done so in desperate cases at SAP, but Glibc removed malloc hooks in 2.35. It would be a messy solution anyway; best to avoid it. > > The next best thing is synchronizing with the larger C-heap users in the VM: compiler and GC. But compiler turns out not to be such a problem, since the compiler uses arenas, and arena chunks are buffered in a free pool with a five-second delay. That means compiler activity that happens in bursts, like at VM startup, will just shuffle arena chunks around from/to the arena free pool, never bothering to call malloc or free. > > That leaves the GC, which was also the experts' recommendation in last year's discussion [1]. Most GCs do uncommit, and trimming the native heap fits well into this. And we want to time the trim to not get into the way of a GC. Plus, integrating trims into the GC cycle lets us reuse GC logging and timing, thereby making RSS changes caused by trim-native visible to the analyst. > > > ### How it works: > > Patch adds new options (experimental for now, and shared among all GCs): > > > -XX:+GCTrimNativeHeap > -XX:GCTrimNativeHeapInterval= (defaults to 60) > > > `GCTrimNativeHeap` is off by default. If enabled, it will cause the VM to trim the native heap on full GCs as well as periodically. The period is defined by `GCTrimNativeHeapInterval`. Periodic trimming can be completely switched off with `GCTrimNativeHeapInterval=0`; in that case, we will only trim on full GCs. > > ### Examples: > > This is an artificial test that causes two high malloc spikes with long idle periods. Observe how RSS recovers with trim but stays up without trim. The trim interval was set to 15 seconds for the test, and no GC was invoked here; this is periodic trimming. > > ![alloc-test](http://cr.openjdk.java.net/~stuefe/other/autotrim/rss-all-collectors.png) > > (See here for parameters: [run script](http://cr.openjdk.java.net/~stuefe/other/autotrim/run-all.sh) ) > > Spring pet clinic boots up, then idles. Once with, once without trim, with the trim interval at 60 seconds default. Of course, if it were actually doing something instead of idling, trim effects would be smaller. But the point of trimming is to recover memory in idle periods. > > ![petclinic bootup](http://cr.openjdk.java.net/~stuefe/other/autotrim/spring-petclinic-rss-with-and-without-trim.png)) > > (See here for parameters: [run script](http://cr.openjdk.java.net/~stuefe/other/autotrim/run-petclinic-boot.sh) ) > > > > ### Implementation > > One problem I faced when implementing this was that trimming was non-interruptable. GCs usually split the uncommit work into smaller portions, which is impossible for `malloc_trim()`. > > So very slow trims could introduce longer GC pauses. I did not want this, therefore I implemented two ways to trim: > 1) GCs can opt to trim asynchronously. In that case, a `NativeTrimmer` thread runs on behalf of the GC and takes care of all trimming. The GC just nudges the `NativeTrimmer` at the end of its GC cycle, but the trim itself runs concurrently. > 2) GCs can do the trim inside their own thread, synchronously. It will have to wait until the trim is done. > > (1) has the advantage of giving us periodic trims even without GC activity (Shenandoah does this out of the box). > > #### Serial > > Serial does the trimming synchronously as part of a full GC, and only then. I did not want to spawn a separate thread for the SerialGC. Therefore Serial is the only GC that does not offer periodic trimming, it just trims on full GC. > > #### Parallel, G1, Z > > All of them do the trimming asynchronously via `NativeTrimmer`. They schedule the native trim at the end of a full collection. They also pause the trimming at the beginning of a cycle to not trim during GCs. > > #### Shenandoah > > Shenandoah does the trimming synchronously in its service thread, similar to how it handles uncommits. Since the service thread already runs concurrently and continuously, it can do periodic trimming; no need to spin a new thread. And this way we can reuse the Shenandoah timing classes. > > ### Patch details > > - adds three new functions to the `os` namespace: > - `os::trim_native_heap()` implementing trim > - `os::can_trim_native_heap()` and `os::should_trim_native_heap()` to return whether platform supports trimming resp. whether the platform considers trimming to be useful. > - replaces implementation of the cmd "System.trim_native_heap" with the new `os::trim_native_heap` > - provides a new wrapper function wrapping the tedious `mallinfo()` vs `mallinfo2()` business: `os::Linux::get_mallinfo()` > - adds a GC-shared utility class, `GCTrimNative`, that takes care of trimming and GC-logging and houses the `NativeTrimmer` thread class. > - adds a regression test > > > ### Tests > > Tested older Glibc (2.31), and newer Glibc (2.35) (`mallinfo()` vs` mallinfo2()`), on Linux x64. > > The rest of the tests will be done by GHA and in our SAP nightlies. > > > ### Remarks > > #### How about other allocators? > > I have seen this retention problem mainly with the Glibc and the AIX libc. Muslc returns memory more eagerly to the OS. I also tested with jemalloc and found it also reclaims more aggressively, therefore I don't think MacOS or BSD are affected that much by retention either. > > #### Trim costs? > > Trim-native is a tradeoff between memory and performance. We pay > - The cost to do the trim depends on how much is trimmed. Time ranges on my machine between < 1ms for no-op trims, to ~800ms for 32GB trims. > - The cost for re-acquiring the memory, should the memory be needed again, is the second cost factor. > > #### Predicting malloc_trim effects? > > `ShenandoahUncommit` avoids uncommits if they are not necessary, thus avoiding work and gc log spamming. I liked that and tried to follow that example. Tried to devise a way to predict the effect trim could have based on allocator info from mallinfo(3). That was quite frustrating since the documentation was confusing and I had to do a lot of experimenting. In the end, I came up with a heuristic to prevent obviously pointless trim attempts; see `os::should_trim_native_heap()`. I am not completely happy with it. > > #### glibc.malloc.trim_threshold? > > glibc has a tunable that looks like it could influence the willingness of Glibc to return memory to the OS, the "trim_threshold". In practice, I could not get it to do anything useful. Regardless of the setting, it never seemed to influence the trimming behavior. Even if it would work, I'm not sure we'd want to use that, since by doing malloc_trim manually we can space out the trims as we see fit, instead of paying the trim price for free(3). > > > - [1] https://mail.openjdk.org/pipermail/hotspot-dev/2021-August/054323.html > - [2] https://bugs.openjdk.org/browse/JDK-8269345 Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - merge-master-with-fixes - Fix merge errors - merge - Merge branch 'master' into JDK-8293114-GC-trim-native - Merge branch 'master' into JDK-8293114-GC-trim-native - Make test more fault tolerant - Merge branch 'master' into JDK-8293114-GC-trim-native - reduce test runtime on slow hardware - make tests more stable on slow hardware - wip - ... and 3 more: https://git.openjdk.org/jdk/compare/544c16e0...1b477185 ------------- Changes: https://git.openjdk.org/jdk/pull/10085/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10085&range=04 Stats: 923 lines in 22 files changed: 920 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10085.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10085/head:pull/10085 PR: https://git.openjdk.org/jdk/pull/10085 From tschatzl at openjdk.org Tue Jan 24 11:42:10 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 24 Jan 2023 11:42:10 GMT Subject: RFR: JDK-8300910: Remove metaprogramming/integralConstant.hpp In-Reply-To: References: Message-ID: <2rSg67x6BWASx8dsH4ckUm9t3iRWDQq333Kh_MOHCvI=.0a3fc49d-a5e0-43aa-af66-2ad51e377fcc@github.com> On Mon, 23 Jan 2023 18:10:58 GMT, Justin King wrote: > Code cleanup of pre-C++11 implementations. Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12149 From jcking at openjdk.org Tue Jan 24 11:42:10 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 24 Jan 2023 11:42:10 GMT Subject: Integrated: JDK-8300910: Remove metaprogramming/integralConstant.hpp In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 18:10:58 GMT, Justin King wrote: > Code cleanup of pre-C++11 implementations. This pull request has now been integrated. Changeset: 048705c0 Author: Justin King Committer: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/048705c04967d106dedc09a4cf2325a3b46ef4e7 Stats: 109 lines in 8 files changed: 10 ins; 64 del; 35 mod 8300910: Remove metaprogramming/integralConstant.hpp Reviewed-by: kbarrett, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/12149 From lkorinth at openjdk.org Tue Jan 24 13:36:45 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 24 Jan 2023 13:36:45 GMT Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable [v8] In-Reply-To: References: Message-ID: > I am replacing the old hash table with ResourceHashtable. In the process I am also removing the redundant `_length` field. By removing the `_length` field, a lot of asserts can be removed as the length will trivially match the length of the underlying table. > > I would like to have feedback on the addition of `unlink_destruct(Function&& should_remove)`. I added it because I prefer to use a functor object that can be used by lambdas instead of an iterator object. However, I did add code to "destruct" resource objects when they are removed instead of just letting them be to reflect that we use `delete` on c-heap objects. Maybe I should remove this "improvement" and then maybe implement the function by calling the existing unlink? Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: Remove the purge list and use the resizing of the resource hash table. Add asserts ensuring that we do not mutatet a hash table while we iterate over it. Renaming .*g1CodeCacheRemSet.?pp -> .*g1CodeRootSet.?pp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11675/files - new: https://git.openjdk.org/jdk/pull/11675/files/0ed0c851..0d4436ad Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11675&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11675&range=06-07 Stats: 795 lines in 15 files changed: 307 ins; 476 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/11675.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11675/head:pull/11675 PR: https://git.openjdk.org/jdk/pull/11675 From coleenp at openjdk.org Tue Jan 24 13:58:09 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 24 Jan 2023 13:58:09 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v14] In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 16:58:19 GMT, Roman Kennke wrote: >> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details. >> >> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements. >> >> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16. >> >> Testing: >> - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] tier1 (x86_64, x86_32, aarch64, riscv) >> - [x] tier2 (x86_64, aarch64, riscv) >> - [x] tier3 (x86_64, riscv) > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused method The linux-x64 product build complains about uncalled filler_array_min_size(). a3b95b83d456/workspace/open/src/hotspot/share/gc/shared/collectedHeap.hpp:209:24: error: inline function 'static size_t CollectedHeap::filler_array_min_size()' used but never defined [-Werror] [2023-01-23T20:38:03,126Z] 209 | static inline size_t filler_array_min_size(); [2023-01-23T20:38:03,126Z] | ^~~~~~~~~~~~~~~~~~~~~ [2023-01-23T20:38:03,970Z] cc1plus: all warnings being treated as errors ------------- PR: https://git.openjdk.org/jdk/pull/11044 From coleenp at openjdk.org Tue Jan 24 14:26:12 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 24 Jan 2023 14:26:12 GMT Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable [v8] In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 13:36:45 GMT, Leo Korinth wrote: >> I am replacing the old hash table with ResourceHashtable. In the process I am also removing the redundant `_length` field. By removing the `_length` field, a lot of asserts can be removed as the length will trivially match the length of the underlying table. >> >> I would like to have feedback on the addition of `unlink_destruct(Function&& should_remove)`. I added it because I prefer to use a functor object that can be used by lambdas instead of an iterator object. However, I did add code to "destruct" resource objects when they are removed instead of just letting them be to reflect that we use `delete` on c-heap objects. Maybe I should remove this "improvement" and then maybe implement the function by calling the existing unlink? > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > Remove the purge list and use the resizing of the resource hash > table. > > Add asserts ensuring that we do not mutatet a hash table while we > iterate over it. Renaming .*g1CodeCacheRemSet.?pp -> .*g1CodeRootSet.?pp This looks really good! A couple of include file cleanups needed. src/hotspot/share/gc/g1/g1CodeRootSet.cpp line 36: > 34: #include "runtime/atomic.hpp" > 35: #include "services/memTracker.hpp" > 36: #include "utilities/hashtable.inline.hpp" Need to remove this include since it's no longer used. Also, I don't see memTracker used either. is stack.inline.hpp used ? src/hotspot/share/gc/g1/g1CodeRootSet.hpp line 30: > 28: #include "utilities/globalDefinitions.hpp" > 29: > 30: #include "code/codeCache.hpp" is codeCache.hpp used by the header file? src/hotspot/share/gc/g1/g1CodeRootSet.hpp line 35: > 33: #include "utilities/resourceHash.hpp" > 34: > 35: class CleanCallback; Do you need this forward declaration since it's in the .cpp file before the caller? src/hotspot/share/gc/g1/heapRegionRemSet.cpp line 124: > 122: BOOL_TO_STR(_m.owned_by_self()), BOOL_TO_STR(Thread::current()->is_VM_thread())); > 123: > 124: if (!_code_roots.contains(nm)) { // with this test, we can assert that we do not modify the hash table while iterating over it But you have the assert in 'add' too, so put_if_absent is more efficient than calling contains first. ------------- Changes requested by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/11675 From coleenp at openjdk.org Tue Jan 24 14:29:10 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 24 Jan 2023 14:29:10 GMT Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable [v6] In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 16:34:47 GMT, Coleen Phillimore wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> revert copyright year after changes > > src/hotspot/share/utilities/resourceHash.hpp line 302: > >> 300: table_size() * sizeof(Node*) + >> 301: number_of_entries() * sizeof(Node); >> 302: } > > Thank you Leo and Ioi. This was a good suggested change. Yes, this looks right to me. ------------- PR: https://git.openjdk.org/jdk/pull/11675 From sgehwolf at openjdk.org Tue Jan 24 14:30:33 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 24 Jan 2023 14:30:33 GMT Subject: RFR: 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values [v3] In-Reply-To: References: Message-ID: > Please review this refactoring of a container test. It now uses WhiteBox to retrieve the host values it asserts for. In terms of functionality this is basically a no-op except for the now more precise assertion on systems with swap accounting disabled at the kernel level. > > *Testing* > - [x] Container tests on Linux x86_64 cgv1 and cgv2 > - [x] Container tests on Linux x86_64 cgv1 and cgv2 on systems with swapaccount=0 > - [x] GHA in progress > > Thoughts? Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Rename to hostPhysicalMemory/Swap ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12097/files - new: https://git.openjdk.org/jdk/pull/12097/files/2f8225e5..06ab3d80 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12097&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12097&range=01-02 Stats: 8 lines in 3 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/12097.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12097/head:pull/12097 PR: https://git.openjdk.org/jdk/pull/12097 From sgehwolf at openjdk.org Tue Jan 24 14:34:35 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 24 Jan 2023 14:34:35 GMT Subject: RFR: 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values [v4] In-Reply-To: References: Message-ID: > Please review this refactoring of a container test. It now uses WhiteBox to retrieve the host values it asserts for. In terms of functionality this is basically a no-op except for the now more precise assertion on systems with swap accounting disabled at the kernel level. > > *Testing* > - [x] Container tests on Linux x86_64 cgv1 and cgv2 > - [x] Container tests on Linux x86_64 cgv1 and cgv2 on systems with swapaccount=0 > - [x] GHA in progress > > Thoughts? Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Update copyright year to 2023 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12097/files - new: https://git.openjdk.org/jdk/pull/12097/files/06ab3d80..9d72dbae Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12097&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12097&range=02-03 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12097.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12097/head:pull/12097 PR: https://git.openjdk.org/jdk/pull/12097 From sgehwolf at openjdk.org Tue Jan 24 14:39:07 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 24 Jan 2023 14:39:07 GMT Subject: RFR: 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values [v2] In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 08:48:13 GMT, Matthias Baesken wrote: >> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision: >> >> 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values > > Hi Severin, what do you think about renaming the methods to WB_HostPhysicalMemory / WB_HostPhysicalSwap to make it even more clear that the host values are meant ? On Linux we have values > `_physical_memory = (julong)sysconf(_SC_PHYS_PAGES) * (julong)sysconf(_SC_PAGESIZE);` > and > `julong os::physical_memory()` from os_linux.cpp (including OSContainer::memory_limit_in_bytes()) so these could be 2 different values . > > And please adjust the COPYRIGHT years to 2023. @MBaesken Thanks for the review! > what do you think about renaming the methods to WB_HostPhysicalMemory / WB_HostPhysicalSwap to make it even more clear that the host values are meant? Sure, done. > On Linux we have values `_physical_memory = (julong)sysconf(_SC_PHYS_PAGES) * (julong)sysconf(_SC_PAGESIZE);` and `julong os::physical_memory()` from os_linux.cpp (including OSContainer::memory_limit_in_bytes()) so these could be 2 different values . Yes. `os::Linux::physical_memory()` returns the host physical memory. Added with [JDK-8293200](https://bugs.openjdk.org/browse/JDK-8293200). `os::physical_memory()` returns the container memory (if run with a limit). In this case we want the former. > And please adjust the COPYRIGHT years to 2023. Done. ------------- PR: https://git.openjdk.org/jdk/pull/12097 From lkorinth at openjdk.org Tue Jan 24 14:42:12 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 24 Jan 2023 14:42:12 GMT Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable [v8] In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 14:15:33 GMT, Coleen Phillimore wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove the purge list and use the resizing of the resource hash >> table. >> >> Add asserts ensuring that we do not mutatet a hash table while we >> iterate over it. Renaming .*g1CodeCacheRemSet.?pp -> .*g1CodeRootSet.?pp > > src/hotspot/share/gc/g1/heapRegionRemSet.cpp line 124: > >> 122: BOOL_TO_STR(_m.owned_by_self()), BOOL_TO_STR(Thread::current()->is_VM_thread())); >> 123: >> 124: if (!_code_roots.contains(nm)) { // with this test, we can assert that we do not modify the hash table while iterating over it > > But you have the assert in 'add' too, so put_if_absent is more efficient than calling contains first. When we have an evacuation failure, the code will add an nmethod that is already present. If I guard in `add_code_root_locked`, evacuation failures will not reach the assert in `G1CodeRootSet::add`. Another way to do it is to to do the `contains` within the assert and then somewhat optimising the release build. Would you prefer that? ------------- PR: https://git.openjdk.org/jdk/pull/11675 From rkennke at openjdk.org Tue Jan 24 14:48:26 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 24 Jan 2023 14:48:26 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v15] In-Reply-To: References: Message-ID: > See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details. > > Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements. > > Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16. > > Testing: > - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390) > - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390) > - [x] tier1 (x86_64, x86_32, aarch64, riscv) > - [x] tier2 (x86_64, aarch64, riscv) > - [x] tier3 (x86_64, riscv) Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Move filler_array_min_size() into inline header file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11044/files - new: https://git.openjdk.org/jdk/pull/11044/files/e40d5947..fb9f18ea Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=13-14 Stats: 10 lines in 2 files changed: 5 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11044.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11044/head:pull/11044 PR: https://git.openjdk.org/jdk/pull/11044 From mbaesken at openjdk.org Tue Jan 24 15:11:08 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 24 Jan 2023 15:11:08 GMT Subject: RFR: 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values [v4] In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 14:34:35 GMT, Severin Gehwolf wrote: >> Please review this refactoring of a container test. It now uses WhiteBox to retrieve the host values it asserts for. In terms of functionality this is basically a no-op except for the now more precise assertion on systems with swap accounting disabled at the kernel level. >> >> *Testing* >> - [x] Container tests on Linux x86_64 cgv1 and cgv2 >> - [x] Container tests on Linux x86_64 cgv1 and cgv2 on systems with swapaccount=0 >> - [x] GHA in progress >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year to 2023 LGTM ------------- Marked as reviewed by mbaesken (Reviewer). PR: https://git.openjdk.org/jdk/pull/12097 From xuelei at openjdk.org Tue Jan 24 15:33:07 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Tue, 24 Jan 2023 15:33:07 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v8] In-Reply-To: References: Message-ID: On Fri, 20 Jan 2023 18:20:10 GMT, Xue-Lei Andrew Fan wrote: >> Nothing further from me. I think this is okay as-is now. Thanks. > >> Nothing further from me. I think this is okay as-is now. Thanks. > > @dholmes-ora Thank you for the review! > @XueleiFan You need two reviews before integrating a Hotspot change - thanks. May I get one more reviewer for this PR? Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/11935 From duke at openjdk.org Tue Jan 24 15:56:29 2023 From: duke at openjdk.org (Scott Gibbons) Date: Tue, 24 Jan 2023 15:56:29 GMT Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v4] In-Reply-To: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com> References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com> Message-ID: > Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms. > > Encode performance: > **Old:** > > Benchmark (maxNumBytes) Mode Cnt Score Error Units > Base64Encode.testBase64Encode 1024 thrpt 3 4309.439 ? 2.632 ops/ms > > > **New:** > > Benchmark (maxNumBytes) Mode Cnt Score Error Units > Base64Encode.testBase64Encode 1024 thrpt 3 24211.397 ? 102.026 ops/ms > > > Decode performance: > **Old:** > > Benchmark (errorIndex) (lineSize) (maxNumBytes) Mode Cnt Score Error Units > Base64Decode.testBase64Decode 144 4 1024 thrpt 3 3961.768 ? 93.409 ops/ms > > **New:** > Benchmark (errorIndex) (lineSize) (maxNumBytes) Mode Cnt Score Error Units > Base64Decode.testBase64Decode 144 4 1024 thrpt 3 14738.051 ? 24.383 ops/ms Scott Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: - Merge branch 'openjdk:master' into Base64-AVX2 - Merge branch 'Base64-AVX2' of https://github.com/asgibbons/jdk into Base64-AVX2 - Merge branch 'openjdk:master' into Base64-AVX2 - Address review comment - Remove whitespace - Fix wrong register usage - Working version of Base64 decode with AVX2 (4x perf improvement). No URL support - Merge branch 'Base64-AVX2' of https://github.com/asgibbons/jdk into Base64-AVX2 - Merge branch 'openjdk:master' into Base64-AVX2 - Intermediate AVX2 for decode - ... and 1 more: https://git.openjdk.org/jdk/compare/74411fed...f9140f40 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12126/files - new: https://git.openjdk.org/jdk/pull/12126/files/c776d90f..f9140f40 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=02-03 Stats: 471 lines in 76 files changed: 123 ins; 121 del; 227 mod Patch: https://git.openjdk.org/jdk/pull/12126.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12126/head:pull/12126 PR: https://git.openjdk.org/jdk/pull/12126 From jcking at openjdk.org Tue Jan 24 16:02:23 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 24 Jan 2023 16:02:23 GMT Subject: RFR: JDK-8300783: Consolidate byteswap implementations [v6] In-Reply-To: References: Message-ID: > Deduplicate byte swapping implementations by consolidating them into `utilities/byteswap.hpp`, following `std::byteswap` introduced in C++23. Further simplification of `Bytes` will follow in https://github.com/openjdk/jdk/pull/12078. Justin King has updated the pull request incrementally with one additional commit since the last revision: Cleanup Bytes::swap_uN Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12114/files - new: https://git.openjdk.org/jdk/pull/12114/files/9986ce35..4e98d704 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12114&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12114&range=04-05 Stats: 118 lines in 9 files changed: 5 ins; 88 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/12114.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12114/head:pull/12114 PR: https://git.openjdk.org/jdk/pull/12114 From jcking at openjdk.org Tue Jan 24 16:02:26 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 24 Jan 2023 16:02:26 GMT Subject: RFR: JDK-8300783: Consolidate byteswap implementations [v5] In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 07:15:48 GMT, David Holmes wrote: > Looking like a good cleanup but can we not put the `swap_uN` definitions in `byteswap.hpp` so we don't repeat then for each platform? Thanks. Okay, looks like there is a single user of `Bytes::swap_uN` outside of Bytes, some code in JFR. I directly updated them to use `byteswap` and removed `Bytes::swap_uN` all together. ------------- PR: https://git.openjdk.org/jdk/pull/12114 From kbarrett at openjdk.org Tue Jan 24 16:06:18 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 24 Jan 2023 16:06:18 GMT Subject: RFR: 8286775: Remove identical per-compiler definitions of unsigned integral jtypes In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 07:42:29 GMT, David Holmes wrote: > Trivial update to share the common typedef's. > > Testing: > - Oracle tier 1 - 5 builds > - GHA (TBD) > > Thanks. `using` declarations are intended to be permitted by the Style Guide. (I know what I intended when I wrote the relevant part.) It seems that's ambiguous though. The Style Guide has this: * Template aliases (n2258) That paper also introduced the term "alias declaration", for a non-templated `using` type declaration. So the Style Guide should probably say "Alias declarations and template aliases". `using Foo = xxx` is equivalent to `typedef xxx Foo`. The former can be easier to read, as it's easier to find the identifier being declared, esp. when the `xxx` part is long and complex and perhaps even multi-line. But I understand the consistency with surrounding code argument. `std::make_unsigned` is in , which we're allowed to use. But I don't think it's really helpful in this case for readability. We know what the representation for these is, since the signed types are defined by the Java language. Also, the compilation failures are a result of using `std::make_unsigned`. I'm not feeling like digging into exactly why. ------------- PR: https://git.openjdk.org/jdk/pull/12136 From jcking at openjdk.org Tue Jan 24 16:08:34 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 24 Jan 2023 16:08:34 GMT Subject: RFR: JDK-8300783: Consolidate byteswap implementations [v7] In-Reply-To: References: Message-ID: > Deduplicate byte swapping implementations by consolidating them into `utilities/byteswap.hpp`, following `std::byteswap` introduced in C++23. Further simplification of `Bytes` will follow in https://github.com/openjdk/jdk/pull/12078. Justin King has updated the pull request incrementally with one additional commit since the last revision: Add missing static_cast to XL C/C++ implementation Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12114/files - new: https://git.openjdk.org/jdk/pull/12114/files/4e98d704..428520cc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12114&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12114&range=05-06 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12114.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12114/head:pull/12114 PR: https://git.openjdk.org/jdk/pull/12114 From jcking at openjdk.org Tue Jan 24 16:14:22 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 24 Jan 2023 16:14:22 GMT Subject: RFR: JDK-8300783: Consolidate byteswap implementations [v8] In-Reply-To: References: Message-ID: > Deduplicate byte swapping implementations by consolidating them into `utilities/byteswap.hpp`, following `std::byteswap` introduced in C++23. Further simplification of `Bytes` will follow in https://github.com/openjdk/jdk/pull/12078. 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/12114/files - new: https://git.openjdk.org/jdk/pull/12114/files/428520cc..f6996e1a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12114&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12114&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12114.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12114/head:pull/12114 PR: https://git.openjdk.org/jdk/pull/12114 From coleenp at openjdk.org Tue Jan 24 16:26:06 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 24 Jan 2023 16:26:06 GMT Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable [v8] In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 14:38:49 GMT, Leo Korinth wrote: >> src/hotspot/share/gc/g1/heapRegionRemSet.cpp line 124: >> >>> 122: BOOL_TO_STR(_m.owned_by_self()), BOOL_TO_STR(Thread::current()->is_VM_thread())); >>> 123: >>> 124: if (!_code_roots.contains(nm)) { // with this test, we can assert that we do not modify the hash table while iterating over it >> >> But you have the assert in 'add' too, so put_if_absent is more efficient than calling contains first. > > When we have an evacuation failure, the code will add an nmethod that is already present. If I guard in `add_code_root_locked`, evacuation failures will not reach the assert in `G1CodeRootSet::add`. Another way to do it is to to do the `contains` within the assert and then somewhat optimising the release build. Would you prefer that? Oh, I see. contains() does not have the assert. Ok, this makes sense. ------------- PR: https://git.openjdk.org/jdk/pull/11675 From aboldtch at openjdk.org Tue Jan 24 16:28:19 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 24 Jan 2023 16:28:19 GMT Subject: RFR: 8296469: Instrument VMError::report with reentrant iteration step for register and stack printing [v8] In-Reply-To: References: Message-ID: > Add reentrant step logic to VMError::report with an inner loop which enable the logic to recover at every step of the iteration. > > Before this change, if printing one register/stack position crashes then no more registers/stack positions will be printed. > > After this change even if the VM is unstable and some registers print_location crashes the hs_err printing will recover and keep attempting to print the rest of the registers or stack values. > > Enables the following > ```C++ > REENTRANT_STEP_IF("printing register info", _verbose && _context && _thread && Universe::is_fully_initialized()) > os::print_register_info_header(st, _context); > > REENTRANT_LOOP_START(os::print_nth_register_info_max_index()) > // decode register contents if possible > ResourceMark rm(_thread); > os::print_nth_register_info(st, REENTRANT_ITERATION_STEP, _context); > REENTRANT_LOOP_END > > st->cr(); > > > Testing: tier 1 and compiled Linux-x64/aarch64, MacOS-x64/aarch64, Windows x64 and cross-compiled Linux-x86/riscv/arm/ppc/s390x (GHA and some local) Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Add test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11017/files - new: https://git.openjdk.org/jdk/pull/11017/files/f60860d8..13a8d66a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11017&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11017&range=06-07 Stats: 169 lines in 4 files changed: 169 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11017.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11017/head:pull/11017 PR: https://git.openjdk.org/jdk/pull/11017 From lkorinth at openjdk.org Tue Jan 24 16:49:07 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 24 Jan 2023 16:49:07 GMT Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable [v8] In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 14:11:56 GMT, Coleen Phillimore wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove the purge list and use the resizing of the resource hash >> table. >> >> Add asserts ensuring that we do not mutatet a hash table while we >> iterate over it. Renaming .*g1CodeCacheRemSet.?pp -> .*g1CodeRootSet.?pp > > src/hotspot/share/gc/g1/g1CodeRootSet.cpp line 36: > >> 34: #include "runtime/atomic.hpp" >> 35: #include "services/memTracker.hpp" >> 36: #include "utilities/hashtable.inline.hpp" > > Need to remove this include since it's no longer used. Also, I don't see memTracker used either. is stack.inline.hpp used ? I will cleanup `#include`s and `class` lists ------------- PR: https://git.openjdk.org/jdk/pull/11675 From gziemski at openjdk.org Tue Jan 24 17:50:07 2023 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 24 Jan 2023 17:50:07 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v4] In-Reply-To: <_khJTogN_LFzv_VSMdncQeFf9zyMDgWGaiPRTuuXVl0=.2dad11d6-cc4e-46de-ad11-7bb607e8900e@github.com> References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> <_khJTogN_LFzv_VSMdncQeFf9zyMDgWGaiPRTuuXVl0=.2dad11d6-cc4e-46de-ad11-7bb607e8900e@github.com> Message-ID: On Tue, 24 Jan 2023 08:14:31 GMT, Thomas Stuefe wrote: >> Rework NMT `MallocLimit` to make it more useful for native OOM analysis. Also remove `MallocMaxTestWords`, which had been mostly redundant with NMT (for background, see JDK-8293292). >> >> >> ### Background >> >> Some months ago we had [JDK-8291919](https://bugs.openjdk.org/browse/JDK-8291919), a compiler regression that caused compiler arenas to grow boundlessly. Process was usually OOM-killed before we could take a look, so this was difficult to analyze. >> >> To improve analysis options, we added NMT *malloc limits* with [JDK-8291878](https://bugs.openjdk.org/browse/JDK-8291878). Malloc limits let us set one or multiple limits to malloc load. Surpassing a limit causes the VM to stop with a fatal error in the allocation function, giving us a hs-err file and a core right at the point that (probably) causes the leak. This makes error analysis a lot simpler, and is also valuable for regression-testing footprint usage. >> >> Some people wished for a way to not end with a fatal error but to mimic a native OOM (causing os::malloc to return NULL). This would allow us to test resilience in the face of native OOMs, among other things. >> >> ### Patch >> >> - Expands the `MallocLimit` option syntax, allowing for an "oom mode" that mimics an oom: >> >> >> >> Global form: >> -XX:MallocLimit=[:] >> Category-specific form: >> -XX:MallocLimit=:[:][,:[:] ...] >> Examples: >> -XX:MallocLimit=3g >> -XX:MallocLimit=3g:oom >> -XX:MallocLimit=compiler:200m:oom >> >> >> - moves parsing of `-XX:MallocLimit` out of arguments.cpp into `mallocLimit.hpp/cpp`, and rewrites it. >> >> - changes when limits are checked. Before, the limits were checked *after* the allocation that caused the threshold overflow. Now we check beforehand. >> >> - removes `MallocMaxTestWords`, replacing its uses with `MallocLimit` >> >> - adds new gtests and new jtreg tests >> >> - removes a bunch of jtreg tests which are now better served by the new gtests. >> >> - gives us more precise error messages upon reaching a limit. For example: >> >> before: >> >> # fatal error: MallocLimit: category "Compiler" reached limit (size: 20997680, limit: 20971520) >> >> >> now: >> >> # fatal error: MallocLimit: reached category "Compiler" limit (triggering allocation size: 1920B, allocated so far: 20505K, limit: 20480K) > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Revert strchrnul Still reviewing, just wanted to share this potential issue right away... src/hotspot/share/runtime/os.cpp line 707: > 705: > 706: // Observe MallocLimit > 707: if (size > old_size && MemTracker::check_exceeds_limit(size - old_size, memflags)) { Can we make it a bit easier to parse by rewriting it as: ` if ((size > old_size) && MemTracker::check_exceeds_limit(size - old_size, memflags)) {` To me personally that is easier to read. I see a bigger issue here, however. In the worse case scenario where the os is unable to expand the memory chunk in place, it will need to allocate `size` bytes in a new region, so the total **potential** resources from the os point of view is `size+old_size` bytes. Shouldn't we assume this worse case and test for that? I'd rather get some false positives that miss a single true positive... And if that were the case we wouldn't need to check for `(size > old_size) ` and we should have just: ` if (MemTracker::check_exceeds_limit(size + old_size, memflags)) {` with a comment explaining this choice. ------------- Changes requested by gziemski (Committer). PR: https://git.openjdk.org/jdk/pull/11371 From lkorinth at openjdk.org Tue Jan 24 18:10:28 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 24 Jan 2023 18:10:28 GMT Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable [v9] In-Reply-To: References: Message-ID: <2xUY7y3kF6YO2My6uvipv58tebTszxyPcMDn1jJ1h1E=.59ecf091-637e-4a1a-ba5e-746ac5ed8f22@github.com> > I am replacing the old hash table with ResourceHashtable. In the process I am also removing the redundant `_length` field. By removing the `_length` field, a lot of asserts can be removed as the length will trivially match the length of the underlying table. > > I would like to have feedback on the addition of `unlink_destruct(Function&& should_remove)`. I added it because I prefer to use a functor object that can be used by lambdas instead of an iterator object. However, I did add code to "destruct" resource objects when they are removed instead of just letting them be to reflect that we use `delete` on c-heap objects. Maybe I should remove this "improvement" and then maybe implement the function by calling the existing unlink? Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: include cleanups, test fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11675/files - new: https://git.openjdk.org/jdk/pull/11675/files/0d4436ad..ec36d732 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11675&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11675&range=07-08 Stats: 20 lines in 5 files changed: 2 ins; 17 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11675.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11675/head:pull/11675 PR: https://git.openjdk.org/jdk/pull/11675 From shade at openjdk.org Tue Jan 24 18:34:24 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 24 Jan 2023 18:34:24 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v15] In-Reply-To: References: Message-ID: <-oqaGCDF75UbtgkKVwsOE9F8-WQ48xCV6GxiN4ZbOxc=.e5042b09-8786-4b44-9929-4d6703303e63@github.com> On Tue, 24 Jan 2023 14:48:26 GMT, Roman Kennke wrote: >> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details. >> >> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements. >> >> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16. >> >> Testing: >> - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] tier1 (x86_64, x86_32, aarch64, riscv) >> - [x] tier2 (x86_64, aarch64, riscv) >> - [x] tier3 (x86_64, riscv) > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Move filler_array_min_size() into inline header file Cursory review follows. src/hotspot/share/gc/shared/collectedHeap.cpp line 417: > 415: void CollectedHeap::zap_filler_array_with(HeapWord* start, size_t words, juint value) { > 416: int payload_start = arrayOopDesc::base_offset_in_bytes(T_INT); > 417: if (!is_aligned(payload_start, BytesPerWord)) { So, this should also be `..., HeapWordSize` to match the post-correction assert, or do I miss some other intent? src/hotspot/share/gc/shared/collectedHeap.inline.hpp line 50: > 48: > 49: inline size_t CollectedHeap::filler_array_min_size() { > 50: size_t aligned_header_size_words = heap_word_size(arrayOopDesc::base_offset_in_bytes(T_INT)); Why this is called `aligned_*`? Looks like it becomes aligned only after the `align_object_size`? src/hotspot/share/oops/arrayKlass.cpp line 128: > 126: > 127: objArrayOop ArrayKlass::allocate_arrayArray(int n, int length, TRAPS) { > 128: check_array_allocation_length(length, arrayOopDesc::max_array_length(element_type()), CHECK_NULL); Wait, why? This method allocates the array of the "this"-typed arrays, I think. I.e. if `this` is `int[]`, then `element_type()` is `int`, and then `allocate_arrayArray(y, len)` allocates `int[length][]`, and we still need to check `length` against `max_array_length(T_ARRAY)`? Which is also why we do `objArrayOopDesc::object_size` at the very next line. src/hotspot/share/oops/arrayOop.hpp line 95: > 93: return (int)(element_type_should_be_aligned(type) > 94: ? align_up(hs, BytesPerLong) > 95: : hs); Style: you can write this in one line, I think. src/hotspot/share/oops/objArrayOop.hpp line 75: > 73: // This returns the object size in HeapWords. > 74: size_t asz = (size_t)length * heapOopSize; > 75: size_t size_words = align_up(base_offset_in_bytes() + asz, HeapWordSize) / HeapWordSize; Is this `heap_word_size`? src/hotspot/share/opto/runtime.cpp line 312: > 310: BasicType elem_type = TypeArrayKlass::cast(array_type)->element_type(); > 311: size_t hs_bytes = arrayOopDesc::base_offset_in_bytes(elem_type); > 312: assert(is_aligned(hs_bytes, BytesPerInt), "must be 4 byte aligned"); This assert is misplaced, should be in the `if` block below? Otherwise checking for HeapWordSize alignment after assert-checking for BytesPerInt seems rather odd: the check is guaranteed to pass if assert does not fire. test/hotspot/gtest/oops/test_arrayOop.cpp line 100: > 98: EXPECT_EQ(arrayOopDesc::base_offset_in_bytes(T_OBJECT), 16); > 99: EXPECT_EQ(arrayOopDesc::base_offset_in_bytes(T_ARRAY), 16); > 100: } These branches are the same; merge them? It makes sense that `T_OBJECT`/`T_ARRAY` base offset does not depend on `UseCompressedOops` under `+UseCompressedClassPointers`. test/hotspot/jtreg/runtime/FieldLayout/ArrayBaseOffsets.java line 2: > 1: /* > 2: * Copyright (C2 2022, Amazon.com Inc. or its affiliates. All Rights Reserved. Typo: `(C2` test/hotspot/jtreg/runtime/FieldLayout/ArrayBaseOffsets.java line 25: > 23: > 24: /* > 25: * @test id=with-coop-no-ccp `with-coops-no-ccp` to match the ID style in this and other tests? test/hotspot/jtreg/runtime/FieldLayout/ArrayBaseOffsets.java line 40: > 38: */ > 39: /* > 40: * @test id=no-coop-no-ccp `no-coops-no-ccp` to match the ID style in this and other tests? test/hotspot/jtreg/runtime/FieldLayout/ArrayBaseOffsets.java line 98: > 96: Asserts.assertEquals(unsafe.arrayBaseOffset(float[].class), intOffset, "Misplaced float array base"); > 97: Asserts.assertEquals(unsafe.arrayBaseOffset(double[].class), longOffset, "Misplaced double array base"); > 98: boolean narrowOops = System.getProperty("java.vm.compressedOopsMode") != null || It feels a bit weird to sense `-XX:-UseCompressedClassPointers` (and thus rely on test command line), but poll the system property here. Suggestion: do two `static final`-s, `COOP` and `CCP`, and then define them in `static` initializer. test/hotspot/jtreg/runtime/FieldLayout/ArrayBaseOffsets.java line 100: > 98: boolean narrowOops = System.getProperty("java.vm.compressedOopsMode") != null || > 99: !Platform.is64bit(); > 100: int expected_objary_offset = narrowOops ? intOffset : longOffset; Not a Java style for identifier, should be `expectedObjArrOffset`. ------------- PR: https://git.openjdk.org/jdk/pull/11044 From shade at openjdk.org Tue Jan 24 18:34:27 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 24 Jan 2023 18:34:27 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v11] In-Reply-To: References: <0oSGAyFe1v4NSMKc-zmIKOm9KIchWhj7TSOf4qGpM78=.f9ea7cd7-e60f-40ae-a003-c935a5400d2f@github.com> Message-ID: On Thu, 19 Jan 2023 13:29:13 GMT, Stefan Karlsson wrote: >> I think that heap_word_size() aligns up: >> inline size_t heap_word_size(size_t byte_size) { >> return (byte_size + (HeapWordSize-1)) >> LogHeapWordSize; >> } >> which makes obj_memory_range() ok as it is? I agree that it is not great, but it seems to be used only by check_for_bad_heap_word_value(), and for that purpose it is ok? Not 100% sure. > > You are right that it aligns up. I agree that it's not 100% clear that check_for_bad_heap_word_value is correct. Similar thing applies to `filler_array_min_size` hunk above? Although there it is masked by "larger" `align_object_size`. ------------- PR: https://git.openjdk.org/jdk/pull/11044 From coleenp at openjdk.org Tue Jan 24 18:47:09 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 24 Jan 2023 18:47:09 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v15] In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 14:48:26 GMT, Roman Kennke wrote: >> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details. >> >> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements. >> >> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16. >> >> Testing: >> - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] tier1 (x86_64, x86_32, aarch64, riscv) >> - [x] tier2 (x86_64, aarch64, riscv) >> - [x] tier3 (x86_64, riscv) > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Move filler_array_min_size() into inline header file Removing the header_size() functions is a nice improvement, imo. I reviewed the arrayOop changes. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/11044 From coleenp at openjdk.org Tue Jan 24 18:52:08 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 24 Jan 2023 18:52:08 GMT Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable [v9] In-Reply-To: <2xUY7y3kF6YO2My6uvipv58tebTszxyPcMDn1jJ1h1E=.59ecf091-637e-4a1a-ba5e-746ac5ed8f22@github.com> References: <2xUY7y3kF6YO2My6uvipv58tebTszxyPcMDn1jJ1h1E=.59ecf091-637e-4a1a-ba5e-746ac5ed8f22@github.com> Message-ID: On Tue, 24 Jan 2023 18:10:28 GMT, Leo Korinth wrote: >> I am replacing the old hash table with ResourceHashtable. In the process I am also removing the redundant `_length` field. By removing the `_length` field, a lot of asserts can be removed as the length will trivially match the length of the underlying table. >> >> I would like to have feedback on the addition of `unlink_destruct(Function&& should_remove)`. I added it because I prefer to use a functor object that can be used by lambdas instead of an iterator object. However, I did add code to "destruct" resource objects when they are removed instead of just letting them be to reflect that we use `delete` on c-heap objects. Maybe I should remove this "improvement" and then maybe implement the function by calling the existing unlink? > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > include cleanups, test fix Good, thank you for the cleanups and switching to the better Hashtable. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/11675 From lkorinth at openjdk.org Tue Jan 24 19:35:13 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 24 Jan 2023 19:35:13 GMT Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable [v8] In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 14:12:26 GMT, Coleen Phillimore wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove the purge list and use the resizing of the resource hash >> table. >> >> Add asserts ensuring that we do not mutatet a hash table while we >> iterate over it. Renaming .*g1CodeCacheRemSet.?pp -> .*g1CodeRootSet.?pp > > src/hotspot/share/gc/g1/g1CodeRootSet.hpp line 30: > >> 28: #include "utilities/globalDefinitions.hpp" >> 29: >> 30: #include "code/codeCache.hpp" > > is codeCache.hpp used by the header file? It defines `CodeBlobClosure` who's class forward declaration I removed. ------------- PR: https://git.openjdk.org/jdk/pull/11675 From jsjolen at openjdk.org Tue Jan 24 20:38:07 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 24 Jan 2023 20:38:07 GMT Subject: RFR: JDK-8300651: Replace NULL with nullptr in share/runtime/ In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 00:31:21 GMT, David Holmes wrote: >> Do the conversion in the share/runtime/ sub-directory and all of its files. > > src/hotspot/share/runtime/javaCalls.cpp line 98: > >> 96: _thread->set_active_handles(new_handles); // install new handle block and reset Java frame linkage >> 97: >> 98: assert (_thread->thread_state() != _thread_in_native, "cannot set native pc to null"); > > FYI this assertion message seems wrong and in fact the assertion is redundant so I'm removing it in https://github.com/openjdk/jdk/pull/12134. OK, deleting it to ensure it doesn't accidentally get pushed back in. ------------- PR: https://git.openjdk.org/jdk/pull/12094 From jsjolen at openjdk.org Tue Jan 24 20:45:19 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 24 Jan 2023 20:45:19 GMT Subject: RFR: JDK-8300651: Replace NULL with nullptr in share/runtime/ [v2] In-Reply-To: References: Message-ID: > Do the conversion in the share/runtime/ sub-directory and all of its files. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: More manual fixes from DHolmes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12094/files - new: https://git.openjdk.org/jdk/pull/12094/files/64d2c224..f71c64b7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12094&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12094&range=00-01 Stats: 9 lines in 8 files changed: 0 ins; 2 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/12094.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12094/head:pull/12094 PR: https://git.openjdk.org/jdk/pull/12094 From gziemski at openjdk.org Tue Jan 24 21:10:09 2023 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 24 Jan 2023 21:10:09 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v4] In-Reply-To: <_khJTogN_LFzv_VSMdncQeFf9zyMDgWGaiPRTuuXVl0=.2dad11d6-cc4e-46de-ad11-7bb607e8900e@github.com> References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> <_khJTogN_LFzv_VSMdncQeFf9zyMDgWGaiPRTuuXVl0=.2dad11d6-cc4e-46de-ad11-7bb607e8900e@github.com> Message-ID: On Tue, 24 Jan 2023 08:14:31 GMT, Thomas Stuefe wrote: >> Rework NMT `MallocLimit` to make it more useful for native OOM analysis. Also remove `MallocMaxTestWords`, which had been mostly redundant with NMT (for background, see JDK-8293292). >> >> >> ### Background >> >> Some months ago we had [JDK-8291919](https://bugs.openjdk.org/browse/JDK-8291919), a compiler regression that caused compiler arenas to grow boundlessly. Process was usually OOM-killed before we could take a look, so this was difficult to analyze. >> >> To improve analysis options, we added NMT *malloc limits* with [JDK-8291878](https://bugs.openjdk.org/browse/JDK-8291878). Malloc limits let us set one or multiple limits to malloc load. Surpassing a limit causes the VM to stop with a fatal error in the allocation function, giving us a hs-err file and a core right at the point that (probably) causes the leak. This makes error analysis a lot simpler, and is also valuable for regression-testing footprint usage. >> >> Some people wished for a way to not end with a fatal error but to mimic a native OOM (causing os::malloc to return NULL). This would allow us to test resilience in the face of native OOMs, among other things. >> >> ### Patch >> >> - Expands the `MallocLimit` option syntax, allowing for an "oom mode" that mimics an oom: >> >> >> >> Global form: >> -XX:MallocLimit=[:] >> Category-specific form: >> -XX:MallocLimit=:[:][,:[:] ...] >> Examples: >> -XX:MallocLimit=3g >> -XX:MallocLimit=3g:oom >> -XX:MallocLimit=compiler:200m:oom >> >> >> - moves parsing of `-XX:MallocLimit` out of arguments.cpp into `mallocLimit.hpp/cpp`, and rewrites it. >> >> - changes when limits are checked. Before, the limits were checked *after* the allocation that caused the threshold overflow. Now we check beforehand. >> >> - removes `MallocMaxTestWords`, replacing its uses with `MallocLimit` >> >> - adds new gtests and new jtreg tests >> >> - removes a bunch of jtreg tests which are now better served by the new gtests. >> >> - gives us more precise error messages upon reaching a limit. For example: >> >> before: >> >> # fatal error: MallocLimit: category "Compiler" reached limit (size: 20997680, limit: 20971520) >> >> >> now: >> >> # fatal error: MallocLimit: reached category "Compiler" limit (triggering allocation size: 1920B, allocated so far: 20505K, limit: 20480K) > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Revert strchrnul Made more progress on the review today, tomorrow I have the parser to review and java tests... src/hotspot/share/runtime/globals.hpp line 1344: > 1342: "Number of exits until ZombieALot kicks in") \ > 1343: \ > 1344: product(ccstr, MallocLimit, nullptr, DIAGNOSTIC, \ Pre-existing, but I wish this flag was named `NMTMallocLimit`, not `MallocLimit`. src/hotspot/share/services/mallocTracker.inline.hpp line 35: > 33: #include "utilities/vmError.hpp" > 34: > 35: static inline bool suppress_limit_handling() { Why did we bother to wrap `VMError::is_error_reported()` into `suppress_limit_handling()`? Are you anticipating more exclusions here in the future? src/hotspot/share/services/mallocTracker.inline.hpp line 56: > 54: size_t so_far = as_snapshot()->total(); > 55: if ((so_far + s) > l->sz) { // hit the limit > 56: if (!suppress_limit_handling()) { I would prefer to see `suppress_limit_handling()` checked inside `total_limit_reached()`, same for `category_limit_reached()`. This way we would force those APIs to always obey the suppression without having to bother to add `suppress_limit_handling()`, they could call `VMError::is_error_reported()` directly. ------------- Changes requested by gziemski (Committer). PR: https://git.openjdk.org/jdk/pull/11371 From lkorinth at openjdk.org Tue Jan 24 21:59:44 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 24 Jan 2023 21:59:44 GMT Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable [v10] In-Reply-To: References: Message-ID: <1mczFcGXMJ-easbrP5X6Lz4dFHhMWs0zIOSb1eHtfmw=.741c639d-232c-434e-b88d-9457de2c51ce@github.com> > I am replacing the old hash table with ResourceHashtable. In the process I am also removing the redundant `_length` field. By removing the `_length` field, a lot of asserts can be removed as the length will trivially match the length of the underlying table. > > I would like to have feedback on the addition of `unlink_destruct(Function&& should_remove)`. I added it because I prefer to use a functor object that can be used by lambdas instead of an iterator object. However, I did add code to "destruct" resource objects when they are removed instead of just letting them be to reflect that we use `delete` on c-heap objects. Maybe I should remove this "improvement" and then maybe implement the function by calling the existing unlink? Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - Merge branch '_master_jdk' into _8292170 - include cleanups, test fix - Remove the purge list and use the resizing of the resource hash table. Add asserts ensuring that we do not mutatet a hash table while we iterate over it. Renaming .*g1CodeCacheRemSet.?pp -> .*g1CodeRootSet.?pp - code_roots_list_contains is now locked, but we have problems with add() during nmethods_do - revert copyright year after changes - add mem_size() method to resourceHash.hpp - can not use contains in combination with add without a lock - remove specialized hash - inline g1CodeRootSetTable.hpp - remove unused template - ... and 3 more: https://git.openjdk.org/jdk/compare/b678e700...6e1832a2 ------------- Changes: https://git.openjdk.org/jdk/pull/11675/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11675&range=09 Stats: 899 lines in 18 files changed: 301 ins; 585 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/11675.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11675/head:pull/11675 PR: https://git.openjdk.org/jdk/pull/11675 From dholmes at openjdk.org Tue Jan 24 22:12:12 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 24 Jan 2023 22:12:12 GMT Subject: RFR: 8286775: Remove identical per-compiler definitions of unsigned integral jtypes In-Reply-To: References: Message-ID: <8fJidcd4bzZW5heKa6pZNNsS9RZrACfZWNyf_toJmE8=.d1fc7849-6c1a-4f9d-953d-c1a5d5ea4c17@github.com> On Tue, 24 Jan 2023 16:03:24 GMT, Kim Barrett wrote: >> Trivial update to share the common typedef's. >> >> Testing: >> - Oracle tier 1 - 5 builds >> - GHA (TBD) >> >> Thanks. > > `using` declarations are intended to be permitted by the Style Guide. (I know > what I intended when I wrote the relevant part.) It seems that's ambiguous > though. The Style Guide has this: > > * Template aliases (n2258) > > That paper also introduced the term "alias declaration", for a non-templated > `using` type declaration. So the Style Guide should probably say "Alias > declarations and template aliases". > > `using Foo = xxx` is equivalent to `typedef xxx Foo`. The former can be easier > to read, as it's easier to find the identifier being declared, esp. when the > `xxx` part is long and complex and perhaps even multi-line. > > But I understand the consistency with surrounding code argument. > > `std::make_unsigned` is in , which we're allowed to use. But I > don't think it's really helpful in this case for readability. We know what the > representation for these is, since the signed types are defined by the Java > language. > > Also, the compilation failures are a result of using `std::make_unsigned`. > I'm not feeling like digging into exactly why. Thanks for the additional explanations @kimbarrett ! ------------- PR: https://git.openjdk.org/jdk/pull/12136 From jsjolen at openjdk.org Tue Jan 24 22:44:46 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 24 Jan 2023 22:44:46 GMT Subject: RFR: JDK-8300241: Replace NULL with nullptr in share/classfile/ Message-ID: Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/classfile/. 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! ------------- Commit messages: - Replace NULL with nullptr in share/classfile/ Changes: https://git.openjdk.org/jdk/pull/12030/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12030&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300241 Stats: 1837 lines in 63 files changed: 0 ins; 0 del; 1837 mod Patch: https://git.openjdk.org/jdk/pull/12030.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12030/head:pull/12030 PR: https://git.openjdk.org/jdk/pull/12030 From jsjolen at openjdk.org Tue Jan 24 22:44:59 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 24 Jan 2023 22:44:59 GMT Subject: RFR: JDK-8300241: Replace NULL with nullptr in share/classfile/ In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 11:13:22 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/classfile/. 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! Found some manual fix ups. Hi, I'm opening this up for review. It builds on my machine and I'm sending it off for tier1 testing. I haven't fixed my comments yet. src/hotspot/share/classfile/classFileParser.cpp line 796: > 794: // of table since we don't expect Symbol*'s to move. > 795: static bool put_after_lookup(const Symbol* name, const Symbol* sig, NameSigHash** table) { > 796: assert(name != nullptr, "name in constant pool is nullptr"); Change to null in string! src/hotspot/share/classfile/classFileParser.cpp line 895: > 893: const InstanceKlass* const k = _local_interfaces->at(index); > 894: name = k->name(); > 895: // If no duplicates, add (name, null) in hashtable interface_names. Maybe nullptr better here? src/hotspot/share/classfile/javaClasses.cpp line 4287: > 4285: java_lang_Class::print_signature(rt, st); > 4286: } else { > 4287: st->print("nullptr"); print "null" src/hotspot/share/classfile/javaClasses.cpp line 4475: > 4473: > 4474: ClassLoaderData* java_lang_ClassLoader::loader_data_acquire(oop loader) { > 4475: assert(loader != nullptr, "loader must not be nullptr"); Fix nullptr in string src/hotspot/share/classfile/javaClasses.cpp line 4481: > 4479: > 4480: ClassLoaderData* java_lang_ClassLoader::loader_data(oop loader) { > 4481: assert(loader != nullptr, "loader must not be nullptr"); Fix nullptr in string src/hotspot/share/classfile/javaClasses.cpp line 4487: > 4485: > 4486: void java_lang_ClassLoader::release_set_loader_data(oop loader, ClassLoaderData* new_data) { > 4487: assert(loader != nullptr, "loader must not be nullptr"); Fix nullptr in string src/hotspot/share/classfile/klassFactory.hpp line 56: > 54: * > 55: * On broken invariants and/or runtime errors the returned value will be > 56: * nullptr (or a nullptr handle) and the caller *might* now have a pending exception. Fix nullptr in comments. src/hotspot/share/classfile/modules.cpp line 62: > 60: > 61: static bool verify_package_name(const char* package_name, int len) { > 62: assert(package_name != nullptr, "Package name derived from non-null jstring can't be nullptr"); Fix nullptr in string src/hotspot/share/classfile/modules.cpp line 441: > 439: ls.print("define_module(): creation of module: %s, version: %s, location: %s, ", > 440: module_name, version_symbol != nullptr ? version_symbol->as_C_string() : "nullptr", > 441: location_symbol != nullptr ? location_symbol->as_C_string() : "nullptr"); Fix nullptr in string src/hotspot/share/classfile/modules.cpp line 702: > 700: package_entry->name()->as_C_string(), > 701: from_module_entry->name()->as_C_string(), > 702: to_module_entry == nullptr ? "nullptr" : Fix nullptr in string src/hotspot/share/classfile/modules.cpp line 808: > 806: assert(h_loader.is_null() || java_lang_ClassLoader::is_subclass(h_loader->klass()), > 807: "Class loader is not a subclass of java.lang.ClassLoader"); > 808: assert(package_name != nullptr, "the package_name should not be nullptr"); Fix nullptr in string src/hotspot/share/classfile/resolutionErrors.cpp line 67: > 65: { > 66: assert_locked_or_safepoint(SystemDictionary_lock); > 67: assert(!pool.is_null() && error != nullptr, "adding nullptr obj"); Fix nullptr in string src/hotspot/share/classfile/resolutionErrors.cpp line 79: > 77: { > 78: assert_locked_or_safepoint(SystemDictionary_lock); > 79: assert(!pool.is_null() && message != nullptr, "adding nullptr obj"); Fix nullptr in string src/hotspot/share/classfile/systemDictionary.cpp line 521: > 519: "Only called when enabling legacy parallel class loading logic " > 520: "for non-parallel capable class loaders"); > 521: assert(lockObject() != nullptr, "lockObject must be non-nullptr"); Fix nullptr in string src/hotspot/share/classfile/verificationType.cpp line 194: > 192: } else { > 193: st->print_cr("nullptr"); > 194: } Fix nullptr in string src/hotspot/share/classfile/verifier.cpp line 2839: > 2837: // Found the entry for the signature's verification types in the hash table. > 2838: mth_sig_verif_types = *mth_sig_verif_types_ptr; > 2839: assert(mth_sig_verif_types != nullptr, "Unexpected nullptr sig_as_verification_types value"); Fix nullptr in string ------------- PR: https://git.openjdk.org/jdk/pull/12030 From coleenp at openjdk.org Tue Jan 24 22:50:03 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 24 Jan 2023 22:50:03 GMT Subject: RFR: JDK-8300241: Replace NULL with nullptr in share/classfile/ In-Reply-To: References: Message-ID: <1cx2krtg3WjAP5Ky_T2SIHbu6JP3FeO9fgfBHVd-kqg=.e5656617-cbcf-4d94-b930-e7e553527079@github.com> On Tue, 17 Jan 2023 11:13:22 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/classfile/. 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! I didn't see any other places that needed changing. src/hotspot/share/classfile/verifier.cpp line 2839: > 2837: // Found the entry for the signature's verification types in the hash table. > 2838: mth_sig_verif_types = *mth_sig_verif_types_ptr; > 2839: assert(mth_sig_verif_types != nullptr, "Unexpected nullptr sig_as_verification_types value"); Suggestion: assert(mth_sig_verif_types != nullptr, "Unexpected null sig_as_verification_types value"); ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/12030 From coleenp at openjdk.org Tue Jan 24 22:56:09 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 24 Jan 2023 22:56:09 GMT Subject: RFR: JDK-8300241: Replace NULL with nullptr in share/classfile/ In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 22:28:01 GMT, Johan Sj?len wrote: >> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/classfile/. 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! > > src/hotspot/share/classfile/classFileParser.cpp line 796: > >> 794: // of table since we don't expect Symbol*'s to move. >> 795: static bool put_after_lookup(const Symbol* name, const Symbol* sig, NameSigHash** table) { >> 796: assert(name != nullptr, "name in constant pool is nullptr"); > > Change to null in string! Suggestion: assert(name != nullptr, "name in constant pool is null"); > src/hotspot/share/classfile/classFileParser.cpp line 895: > >> 893: const InstanceKlass* const k = _local_interfaces->at(index); >> 894: name = k->name(); >> 895: // If no duplicates, add (name, null) in hashtable interface_names. > > Maybe nullptr better here? Suggestion: // If no duplicates, add (name, nullptr) in hashtable interface_names. > src/hotspot/share/classfile/javaClasses.cpp line 4475: > >> 4473: >> 4474: ClassLoaderData* java_lang_ClassLoader::loader_data_acquire(oop loader) { >> 4475: assert(loader != nullptr, "loader must not be nullptr"); > > Fix nullptr in string Suggestion: assert(loader != nullptr, "loader must not be null"); > src/hotspot/share/classfile/javaClasses.cpp line 4481: > >> 4479: >> 4480: ClassLoaderData* java_lang_ClassLoader::loader_data(oop loader) { >> 4481: assert(loader != nullptr, "loader must not be nullptr"); > > Fix nullptr in string Suggestion: assert(loader != nullptr, "loader must not be null"); > src/hotspot/share/classfile/javaClasses.cpp line 4487: > >> 4485: >> 4486: void java_lang_ClassLoader::release_set_loader_data(oop loader, ClassLoaderData* new_data) { >> 4487: assert(loader != nullptr, "loader must not be nullptr"); > > Fix nullptr in string Suggestion: assert(loader != nullptr, "loader must not be null"); > src/hotspot/share/classfile/modules.cpp line 62: > >> 60: >> 61: static bool verify_package_name(const char* package_name, int len) { >> 62: assert(package_name != nullptr, "Package name derived from non-null jstring can't be nullptr"); > > Fix nullptr in string Suggestion: assert(package_name != nullptr, "Package name derived from non-null jstring can't be null"); ------------- PR: https://git.openjdk.org/jdk/pull/12030 From kbarrett at openjdk.org Tue Jan 24 23:26:08 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 24 Jan 2023 23:26:08 GMT Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof [v3] In-Reply-To: <1vFS7xsbqeW1z1TrrnwCuHCwfMbD54xglwPZP0kwNMc=.a495a2c5-501c-4151-bc7c-590b5c05b5fd@github.com> References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com> <1VvY0OUOTV6QoOICCC7D-bossOFuNcElgxJwOK0ATcg=.4d805893-07a4-4c0c-b9c0-82a2ee3be0cf@github.com> <1hEloz4xpYz6Ofo_RItjyhbSYfv8OY_f11SSvCgFjL8=.8c3d3051-54fb-4436-be68-7b493ddb6af5@github.com> <1vFS7xsbqeW1z1TrrnwCuHCwfMbD54xglwPZP0kwNMc=.a495a2c5-501c-4151-bc7c-590b5c05b5fd@github.com> Message-ID: <6XauuplEHiyDoz21XH5fWW66JN31ldZ5rTv9qyizgLU=.dde4c07e-1fa7-469d-b5a7-2b8f16e9bc50@github.com> On Tue, 24 Jan 2023 07:42:20 GMT, Xin Liu wrote: > Currently, sizeof(Message) is 64. Message is just a header. The real payload is Message + a '\0'-terminated c-str and pads. > > You are right about the purpose of 'calc_size()', but we don't load 'Message" as an object. We only load its fields individually. eg. *(message->_output). That's why I think it's good enough to align to the pointer size. In order to access through an object, the object must be correctly aligned for its type, else UB. > Let's assume the log string is empty ''. calc_size(0) returns 72 now, so the next Message starts at buffer+72. *_output is still aligned load. If we alignof(Message), it starts with buffer+128. that takes 63 bytes to pad. Agreed that calc_size(0) is 72 currently. But disagree about the value if using alignof(Message) instead of sizeof(void*) in that calculation. Using alignof(Message) will also return 72. Maybe you are misremembering what alignof returns? ------------- PR: https://git.openjdk.org/jdk/pull/11761 From dholmes at openjdk.org Wed Jan 25 01:33:05 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 25 Jan 2023 01:33:05 GMT Subject: RFR: JDK-8300783: Consolidate byteswap implementations [v8] In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 16:14:22 GMT, Justin King wrote: >> Deduplicate byte swapping implementations by consolidating them into `utilities/byteswap.hpp`, following `std::byteswap` introduced in C++23. Further simplification of `Bytes` will follow in https://github.com/openjdk/jdk/pull/12078. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Update comment > > Signed-off-by: Justin King Cleanup/consolidation looks really good. Have to wonder if we can go further with `get_Java_u2` etc, in a next step? The actual byteswap stuff seems okay but not really my area and compiler specific actions are not something I'm at all familiar with. I will grab this and run through our CI. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/12114 From dholmes at openjdk.org Wed Jan 25 01:42:03 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 25 Jan 2023 01:42:03 GMT Subject: RFR: JDK-8300241: Replace NULL with nullptr in share/classfile/ In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 11:13:22 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/classfile/. 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! I will wait for the update before reviewing :) ------------- PR: https://git.openjdk.org/jdk/pull/12030 From dholmes at openjdk.org Wed Jan 25 01:52:03 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 25 Jan 2023 01:52:03 GMT Subject: RFR: JDK-8300651: Replace NULL with nullptr in share/runtime/ [v2] In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 20:45:19 GMT, Johan Sj?len wrote: >> Do the conversion in the share/runtime/ sub-directory and all of its files. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > More manual fixes from DHolmes Looks good! Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12094 From mikael at openjdk.org Wed Jan 25 02:08:05 2023 From: mikael at openjdk.org (Mikael Vidstedt) Date: Wed, 25 Jan 2023 02:08:05 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v8] In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 18:54:08 GMT, Xue-Lei Andrew Fan wrote: >> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. >> >> This patch is trying to find the use of sprintf in hotspot iml and test cases. > > Xue-Lei Andrew Fan has updated the pull request incrementally with two additional commits since the last revision: > > - remove serviceability update and add back forbid of sprintf > - remove serviceability update Looks good, thank you for doing this! ------------- Marked as reviewed by mikael (Reviewer). PR: https://git.openjdk.org/jdk/pull/11935 From duke at openjdk.org Wed Jan 25 02:20:12 2023 From: duke at openjdk.org (Scott Gibbons) Date: Wed, 25 Jan 2023 02:20:12 GMT Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v5] In-Reply-To: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com> References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com> Message-ID: > Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms. > > Encode performance: > **Old:** > > Benchmark (maxNumBytes) Mode Cnt Score Error Units > Base64Encode.testBase64Encode 1024 thrpt 3 4309.439 ? 2.632 ops/ms > > > **New:** > > Benchmark (maxNumBytes) Mode Cnt Score Error Units > Base64Encode.testBase64Encode 1024 thrpt 3 24211.397 ? 102.026 ops/ms > > > Decode performance: > **Old:** > > Benchmark (errorIndex) (lineSize) (maxNumBytes) Mode Cnt Score Error Units > Base64Decode.testBase64Decode 144 4 1024 thrpt 3 3961.768 ? 93.409 ops/ms > > **New:** > Benchmark (errorIndex) (lineSize) (maxNumBytes) Mode Cnt Score Error Units > Base64Decode.testBase64Decode 144 4 1024 thrpt 3 14738.051 ? 24.383 ops/ms Scott Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: - Merge branch 'openjdk:master' into Base64-AVX2 - Merge branch 'openjdk:master' into Base64-AVX2 - Merge branch 'Base64-AVX2' of https://github.com/asgibbons/jdk into Base64-AVX2 - Merge branch 'openjdk:master' into Base64-AVX2 - Address review comment - Remove whitespace - Fix wrong register usage - Working version of Base64 decode with AVX2 (4x perf improvement). No URL support - Merge branch 'Base64-AVX2' of https://github.com/asgibbons/jdk into Base64-AVX2 - Merge branch 'openjdk:master' into Base64-AVX2 - ... and 2 more: https://git.openjdk.org/jdk/compare/7714f4ce...98728555 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12126/files - new: https://git.openjdk.org/jdk/pull/12126/files/f9140f40..98728555 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=03-04 Stats: 585 lines in 17 files changed: 93 ins; 440 del; 52 mod Patch: https://git.openjdk.org/jdk/pull/12126.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12126/head:pull/12126 PR: https://git.openjdk.org/jdk/pull/12126 From fyang at openjdk.org Wed Jan 25 04:57:49 2023 From: fyang at openjdk.org (Fei Yang) Date: Wed, 25 Jan 2023 04:57:49 GMT Subject: RFR: 8301036: RISC-V: Factor out functions baseOffset & baseOffset32 from MacroAssembler Message-ID: The functions baseOffset & baseOffset32 from MacroAssembler on RISC-V accept an Address with base_plus_offset mode. They check the range of the offset, add it and base and put the result in a destination register. This duplicates the work of function MacroAssembler::la. We could refactor this part putting the logic of Address legitimization into MacroAssembler::la and use this function instead. Testing: - [x] Bootcycle (release & fastdebug) - [x] Tier1-4 (release) - [x] Benchmarks: SPECjbb2015 (release) ------------- Commit messages: - 8301036: RISC-V: Factor out functions baseOffset & baseOffset32 from MacroAssembler Changes: https://git.openjdk.org/jdk/pull/12177/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12177&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301036 Stats: 65 lines in 3 files changed: 16 ins; 31 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/12177.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12177/head:pull/12177 PR: https://git.openjdk.org/jdk/pull/12177 From fyang at openjdk.org Wed Jan 25 05:50:42 2023 From: fyang at openjdk.org (Fei Yang) Date: Wed, 25 Jan 2023 05:50:42 GMT Subject: RFR: 8300463: Build failure on Windows 32 after JDK-8296401 Message-ID: This issue also triggers when building slowdebug on linux-aarch64 with GCC-9.4.0. Given that std::numeric_limits::max() returns positive integer number and size_t is an unsigned type, I guess it's safe to do simple static_cast here both on 32-bit and 64-bit platfoms. Slowdebug on linux-aarch64 builds fine with this fix. ------------- Commit messages: - 8300463: Build failure on Windows 32 after JDK-8296401 Changes: https://git.openjdk.org/jdk/pull/12178/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12178&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300463 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12178.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12178/head:pull/12178 PR: https://git.openjdk.org/jdk/pull/12178 From stuefe at openjdk.org Wed Jan 25 06:29:10 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 25 Jan 2023 06:29:10 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v4] In-Reply-To: References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> <_khJTogN_LFzv_VSMdncQeFf9zyMDgWGaiPRTuuXVl0=.2dad11d6-cc4e-46de-ad11-7bb607e8900e@github.com> Message-ID: On Tue, 24 Jan 2023 20:53:54 GMT, Gerard Ziemski wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert strchrnul > > src/hotspot/share/runtime/globals.hpp line 1344: > >> 1342: "Number of exits until ZombieALot kicks in") \ >> 1343: \ >> 1344: product(ccstr, MallocLimit, nullptr, DIAGNOSTIC, \ > > Pre-existing, but I wish this flag was named `NMTMallocLimit`, not `MallocLimit`. I prefer MallocLimit, short and snappy. And the fact that NMT is supervising the limit is an implementation detail. It used to be different with MallocMaxTestWords and may be different in the future. > Can we make it a bit easier to parse by rewriting it as: > > ` if ((size > old_size) && MemTracker::check_exceeds_limit(size - old_size, memflags)) {` > > To me personally that is easier to read. > Sure > I see a bigger issue here, however. In the worst case scenario, where the os is unable to expand the memory chunk in place, it will need to allocate `size` bytes in a new region, so the total **potential** resources from the os point of view is `size+old_size` bytes for that particular allocation. Shouldn't we assume this worst case and test for that? I.e. > > ` if ((size > old_size) && MemTracker::check_exceeds_limit(size, memflags)) {` > > We would need a comment here explaining this choice if we make this change. > > I'd rather get some false positives that miss a single true positive... Nah, no need to overthink this. If you try to predict how much memory your malloc causes your process to allocate, it gets very fuzzy very quickly: Below are at least two allocating layers (libc and the kernel's vm manager). Both of them balance memory and CPU footprint and allocation speed. No libc or kernel is the same, too. Each layer below you may return cached or partly cached memory and apply an often sizable overhead to what you are allocating. So our mallocs and frees have only a very indirect effect on RSS. And we don't even see all mallocs here, just the ones from libjvm. Therefore it is best to limit the meaning of MallocLimit to "limit to how much hotspot is allowed to allocate". That is also the most useful. For limiting the memory of a process, different os-side tools exist (cgroup limits, ulimit, etc). > Why did we bother to wrap `VMError::is_error_reported()` into `suppress_limit_handling()`? > Because during error handling, code may malloc() too (bad practice, but it can happen). If it does, I don't want circular assertions to fire; I want a clean, complete hs-err file. > Are you anticipating more exclusions here in the future? None I can think of. ------------- PR: https://git.openjdk.org/jdk/pull/11371 From stuefe at openjdk.org Wed Jan 25 06:57:04 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 25 Jan 2023 06:57:04 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v4] In-Reply-To: References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> <_khJTogN_LFzv_VSMdncQeFf9zyMDgWGaiPRTuuXVl0=.2dad11d6-cc4e-46de-ad11-7bb607e8900e@github.com> Message-ID: On Tue, 24 Jan 2023 21:07:38 GMT, Gerard Ziemski wrote: > Made more progress on the review today, tomorrow I have the parser to review and java tests... Thanks for your review work! I'll wait for your full review before continuing. > I would prefer to see `suppress_limit_handling()` checked inside `total_limit_reached()`, same for `category_limit_reached()`. This way we would force those APIs to always obey the suppression without having to bother to add `suppress_limit_handling()`, they could call `VMError::is_error_reported()` directly. Note that `total_limit_reached()` and `category_limit_reached()` are private APIs. If we move `suppress_limit_handling()` into `total_limit_reached()`, `total_limit_reached()` would need to report it back to `MallocMemorySummary::check_exceeds_limit` since its processed there too, it affects the return code. So `total_limit_reached()` cannot be void anymore, and gets somewhat more complex. I prefer it this way, tbh. ------------- PR: https://git.openjdk.org/jdk/pull/11371 From stuefe at openjdk.org Wed Jan 25 09:54:57 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 25 Jan 2023 09:54:57 GMT Subject: RFR: JDK-8293114: GC should trim the native heap [v6] In-Reply-To: <23KpPM4oPV6F1nz3g5CvIqvuX-ANcsMH4GuVNXjR-Lw=.b8d0fa2d-bb85-4899-8e21-f68ea64b988d@github.com> References: <23KpPM4oPV6F1nz3g5CvIqvuX-ANcsMH4GuVNXjR-Lw=.b8d0fa2d-bb85-4899-8e21-f68ea64b988d@github.com> Message-ID: <-lr_UX1cgOgqAjVDJEJVxoyFVGVQkckPf3dk0kJylEw=.7c71a2c7-5ea9-4c90-90c3-d145c35a2166@github.com> > This RFE adds the option to auto-trim the Glibc heap as part of the GC cycle. If the VM process suffered high temporary malloc spikes (regardless whether from JVM- or user code), this could recover significant amounts of memory. > > We discussed this a year ago [1], but the item got pushed to the bottom of my work pile, therefore it took longer than I thought. > > ### Motivation > > The Glibc allocator is reluctant to return memory to the OS, much more so than other allocators. Temporary malloc spikes often carry over as permanent RSS increase. > > Note that C-heap retention is difficult to observe. Since it is freed memory, it won't show up in NMT, it is just a part of private RSS. > > Theoretically, retained memory is not lost since it will be reused by future mallocs. Retaining memory is therefore a bet on the future behavior of the app. The allocator bets on the application needing memory in the near future, and to satisfy that need via malloc. > > But an app's malloc load can fluctuate wildly, with temporary spikes and long idle periods. And if the app rolls its own custom allocators atop of mmap, as hotspot does, a lot of that memory cannot be reused even though it counts toward its memory footprint. > > To help, Glibc exports an API to trim the C-heap: `malloc_trim(3)`. With JDK 18 [2], SAP contributed a new jcmd command to *manually* trim the C-heap on Linux. This RFE adds a complementary way to trim automatically. > > #### Is this even a problem? > > Do we have high malloc spikes in the JVM process? We assume that malloc load from hotspot is usually low since hotspot typically clusters allocations into custom areas - metaspace, code heap, arenas. > > But arenas are subject to Glibc mem retention too. I was surprised by that since I assumed 32k arena chunks were too big to be subject of Glibc retention. But I saw in experiments that high arena peaks often cause lasting RSS increase. > > And of course, both hotspot and JDK do a lot of finer-granular mallocs outside of custom allocators. > > But many cases of high memory retention in Glibc I have seen in third-party JNI code. Libraries allocate large buffers via malloc as temporary buffers. In fact, since we introduced the jcmd "System.trim_native_heap", some of our customers started to call this command periodically in scripts to counter these issues. > > Therefore I think while high malloc spikes are atypical for a JVM process, they can happen. Having a way to auto-trim the native heap makes sense. > > ### When should we trim? > > We want to trim when we know there is a lull in malloc activity coming. But we have no knowledge of the future. > > We could build a heuristic based on malloc frequency. But on closer inspection that is difficult. We cannot use NMT, since NMT has no complete picture (only knows hotspot) and is usually disabled in production anyway. The only way to get *all* mallocs would be to use Glibc malloc hooks. We have done so in desperate cases at SAP, but Glibc removed malloc hooks in 2.35. It would be a messy solution anyway; best to avoid it. > > The next best thing is synchronizing with the larger C-heap users in the VM: compiler and GC. But compiler turns out not to be such a problem, since the compiler uses arenas, and arena chunks are buffered in a free pool with a five-second delay. That means compiler activity that happens in bursts, like at VM startup, will just shuffle arena chunks around from/to the arena free pool, never bothering to call malloc or free. > > That leaves the GC, which was also the experts' recommendation in last year's discussion [1]. Most GCs do uncommit, and trimming the native heap fits well into this. And we want to time the trim to not get into the way of a GC. Plus, integrating trims into the GC cycle lets us reuse GC logging and timing, thereby making RSS changes caused by trim-native visible to the analyst. > > > ### How it works: > > Patch adds new options (experimental for now, and shared among all GCs): > > > -XX:+GCTrimNativeHeap > -XX:GCTrimNativeHeapInterval= (defaults to 60) > > > `GCTrimNativeHeap` is off by default. If enabled, it will cause the VM to trim the native heap on full GCs as well as periodically. The period is defined by `GCTrimNativeHeapInterval`. Periodic trimming can be completely switched off with `GCTrimNativeHeapInterval=0`; in that case, we will only trim on full GCs. > > ### Examples: > > This is an artificial test that causes two high malloc spikes with long idle periods. Observe how RSS recovers with trim but stays up without trim. The trim interval was set to 15 seconds for the test, and no GC was invoked here; this is periodic trimming. > > ![alloc-test](http://cr.openjdk.java.net/~stuefe/other/autotrim/rss-all-collectors.png) > > (See here for parameters: [run script](http://cr.openjdk.java.net/~stuefe/other/autotrim/run-all.sh) ) > > Spring pet clinic boots up, then idles. Once with, once without trim, with the trim interval at 60 seconds default. Of course, if it were actually doing something instead of idling, trim effects would be smaller. But the point of trimming is to recover memory in idle periods. > > ![petclinic bootup](http://cr.openjdk.java.net/~stuefe/other/autotrim/spring-petclinic-rss-with-and-without-trim.png)) > > (See here for parameters: [run script](http://cr.openjdk.java.net/~stuefe/other/autotrim/run-petclinic-boot.sh) ) > > > > ### Implementation > > One problem I faced when implementing this was that trimming was non-interruptable. GCs usually split the uncommit work into smaller portions, which is impossible for `malloc_trim()`. > > So very slow trims could introduce longer GC pauses. I did not want this, therefore I implemented two ways to trim: > 1) GCs can opt to trim asynchronously. In that case, a `NativeTrimmer` thread runs on behalf of the GC and takes care of all trimming. The GC just nudges the `NativeTrimmer` at the end of its GC cycle, but the trim itself runs concurrently. > 2) GCs can do the trim inside their own thread, synchronously. It will have to wait until the trim is done. > > (1) has the advantage of giving us periodic trims even without GC activity (Shenandoah does this out of the box). > > #### Serial > > Serial does the trimming synchronously as part of a full GC, and only then. I did not want to spawn a separate thread for the SerialGC. Therefore Serial is the only GC that does not offer periodic trimming, it just trims on full GC. > > #### Parallel, G1, Z > > All of them do the trimming asynchronously via `NativeTrimmer`. They schedule the native trim at the end of a full collection. They also pause the trimming at the beginning of a cycle to not trim during GCs. > > #### Shenandoah > > Shenandoah does the trimming synchronously in its service thread, similar to how it handles uncommits. Since the service thread already runs concurrently and continuously, it can do periodic trimming; no need to spin a new thread. And this way we can reuse the Shenandoah timing classes. > > ### Patch details > > - adds three new functions to the `os` namespace: > - `os::trim_native_heap()` implementing trim > - `os::can_trim_native_heap()` and `os::should_trim_native_heap()` to return whether platform supports trimming resp. whether the platform considers trimming to be useful. > - replaces implementation of the cmd "System.trim_native_heap" with the new `os::trim_native_heap` > - provides a new wrapper function wrapping the tedious `mallinfo()` vs `mallinfo2()` business: `os::Linux::get_mallinfo()` > - adds a GC-shared utility class, `GCTrimNative`, that takes care of trimming and GC-logging and houses the `NativeTrimmer` thread class. > - adds a regression test > > > ### Tests > > Tested older Glibc (2.31), and newer Glibc (2.35) (`mallinfo()` vs` mallinfo2()`), on Linux x64. > > The rest of the tests will be done by GHA and in our SAP nightlies. > > > ### Remarks > > #### How about other allocators? > > I have seen this retention problem mainly with the Glibc and the AIX libc. Muslc returns memory more eagerly to the OS. I also tested with jemalloc and found it also reclaims more aggressively, therefore I don't think MacOS or BSD are affected that much by retention either. > > #### Trim costs? > > Trim-native is a tradeoff between memory and performance. We pay > - The cost to do the trim depends on how much is trimmed. Time ranges on my machine between < 1ms for no-op trims, to ~800ms for 32GB trims. > - The cost for re-acquiring the memory, should the memory be needed again, is the second cost factor. > > #### Predicting malloc_trim effects? > > `ShenandoahUncommit` avoids uncommits if they are not necessary, thus avoiding work and gc log spamming. I liked that and tried to follow that example. Tried to devise a way to predict the effect trim could have based on allocator info from mallinfo(3). That was quite frustrating since the documentation was confusing and I had to do a lot of experimenting. In the end, I came up with a heuristic to prevent obviously pointless trim attempts; see `os::should_trim_native_heap()`. I am not completely happy with it. > > #### glibc.malloc.trim_threshold? > > glibc has a tunable that looks like it could influence the willingness of Glibc to return memory to the OS, the "trim_threshold". In practice, I could not get it to do anything useful. Regardless of the setting, it never seemed to influence the trimming behavior. Even if it would work, I'm not sure we'd want to use that, since by doing malloc_trim manually we can space out the trims as we see fit, instead of paying the trim price for free(3). > > > - [1] https://mail.openjdk.org/pipermail/hotspot-dev/2021-August/054323.html > - [2] https://bugs.openjdk.org/browse/JDK-8269345 Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - make tests for ppc more lenient - Merge - merge-master-with-fixes - Fix merge errors - merge - Merge branch 'master' into JDK-8293114-GC-trim-native - Merge branch 'master' into JDK-8293114-GC-trim-native - Make test more fault tolerant - Merge branch 'master' into JDK-8293114-GC-trim-native - reduce test runtime on slow hardware - ... and 5 more: https://git.openjdk.org/jdk/compare/b2071f79...a8ae8a2e ------------- Changes: https://git.openjdk.org/jdk/pull/10085/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10085&range=05 Stats: 930 lines in 22 files changed: 927 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10085.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10085/head:pull/10085 PR: https://git.openjdk.org/jdk/pull/10085 From lkorinth at openjdk.org Wed Jan 25 10:15:08 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 25 Jan 2023 10:15:08 GMT Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable [v10] In-Reply-To: <1mczFcGXMJ-easbrP5X6Lz4dFHhMWs0zIOSb1eHtfmw=.741c639d-232c-434e-b88d-9457de2c51ce@github.com> References: <1mczFcGXMJ-easbrP5X6Lz4dFHhMWs0zIOSb1eHtfmw=.741c639d-232c-434e-b88d-9457de2c51ce@github.com> Message-ID: On Tue, 24 Jan 2023 21:59:44 GMT, Leo Korinth wrote: >> I am replacing the old hash table with ResourceHashtable. In the process I am also removing the redundant `_length` field. By removing the `_length` field, a lot of asserts can be removed as the length will trivially match the length of the underlying table. >> >> I would like to have feedback on the addition of `unlink_destruct(Function&& should_remove)`. I added it because I prefer to use a functor object that can be used by lambdas instead of an iterator object. However, I did add code to "destruct" resource objects when they are removed instead of just letting them be to reflect that we use `delete` on c-heap objects. Maybe I should remove this "improvement" and then maybe implement the function by calling the existing unlink? > > Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: > > - Merge branch '_master_jdk' into _8292170 > - include cleanups, test fix > - Remove the purge list and use the resizing of the resource hash > table. > > Add asserts ensuring that we do not mutatet a hash table while we > iterate over it. Renaming .*g1CodeCacheRemSet.?pp -> .*g1CodeRootSet.?pp > - code_roots_list_contains is now locked, but we have problems with add() during nmethods_do > - revert copyright year after changes > - add mem_size() method to resourceHash.hpp > - can not use contains in combination with add without a lock > - remove specialized hash > - inline g1CodeRootSetTable.hpp > - remove unused template > - ... and 3 more: https://git.openjdk.org/jdk/compare/b678e700...6e1832a2 tier1-5 passes. @iklam and @walulyai, can you take a look at my changes? I have removed the extra table class, now doing everything in G1CodeRootSet. Therefore I also renamed the files to `g1CodeRootSet.?xx`. I have also added asserts ensuring that we do not mutate the table when we iterate over it. I also removed all logic related to the purge list as we are now doing the resizing using the resizable hash table logic. I think this is ready to be integrated. ------------- PR: https://git.openjdk.org/jdk/pull/11675 From sgehwolf at openjdk.org Wed Jan 25 10:27:18 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 25 Jan 2023 10:27:18 GMT Subject: Integrated: 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 13:57:57 GMT, Severin Gehwolf wrote: > Please review this refactoring of a container test. It now uses WhiteBox to retrieve the host values it asserts for. In terms of functionality this is basically a no-op except for the now more precise assertion on systems with swap accounting disabled at the kernel level. > > *Testing* > - [x] Container tests on Linux x86_64 cgv1 and cgv2 > - [x] Container tests on Linux x86_64 cgv1 and cgv2 on systems with swapaccount=0 > - [x] GHA in progress > > Thoughts? This pull request has now been integrated. Changeset: 3c61d5aa Author: Severin Gehwolf URL: https://git.openjdk.org/jdk/commit/3c61d5aa48606dab2d2c639d5f0a56313476917d Stats: 47 lines in 3 files changed: 27 ins; 1 del; 19 mod 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values Reviewed-by: mbaesken ------------- PR: https://git.openjdk.org/jdk/pull/12097 From jsjolen at openjdk.org Wed Jan 25 10:33:22 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 25 Jan 2023 10:33:22 GMT Subject: RFR: JDK-8300651: Replace NULL with nullptr in share/runtime/ [v2] In-Reply-To: References: Message-ID: <6kjhS4NwgLDAINbFfZsIlFh21SiBtLFPNQEeSvG4Oxc=.8e2764e5-7184-4051-9ba7-f9ddbc9a16d5@github.com> On Tue, 24 Jan 2023 20:45:19 GMT, Johan Sj?len wrote: >> Do the conversion in the share/runtime/ sub-directory and all of its files. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > More manual fixes from DHolmes Passes tier1. ------------- PR: https://git.openjdk.org/jdk/pull/12094 From jsjolen at openjdk.org Wed Jan 25 10:33:25 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 25 Jan 2023 10:33:25 GMT Subject: Integrated: JDK-8300651: Replace NULL with nullptr in share/runtime/ In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 12:27:23 GMT, Johan Sj?len wrote: > Do the conversion in the share/runtime/ sub-directory and all of its files. This pull request has now been integrated. Changeset: 71107f46 Author: Johan Sj?len URL: https://git.openjdk.org/jdk/commit/71107f4648d8f31a7bcc0aa5202ef46230df583f Stats: 2067 lines in 112 files changed: 0 ins; 0 del; 2067 mod 8300651: Replace NULL with nullptr in share/runtime/ Reviewed-by: rehn, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/12094 From jsjolen at openjdk.org Wed Jan 25 11:59:40 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 25 Jan 2023 11:59:40 GMT Subject: RFR: JDK-8301069: Replace NULL with nullptr in share/libadt/ Message-ID: Do the conversion in the share/libadt/ sub-directory and all of its files. ------------- Commit messages: - Fix comment alignment - Replace NULL with nullptr in share/libadt/ Changes: https://git.openjdk.org/jdk/pull/12184/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12184&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301069 Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/12184.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12184/head:pull/12184 PR: https://git.openjdk.org/jdk/pull/12184 From thartmann at openjdk.org Wed Jan 25 12:05:00 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 25 Jan 2023 12:05:00 GMT Subject: RFR: 8301063: Remove dead code from GrowableArray Message-ID: <3DLZGb6mDxMXam1-o-jdlIKkCCuicMfmz_dwVpuVBJs=.ff3f662f-939a-4155-8478-b758be6ba2f7@github.com> While looking for a method to truncate a GrowableArray, I noticed that there are both `trunc_to` and `truncate_to` while the behavior of the latter is confusing. Since it's unused, I propose to remove it (together with `data_size_in_bytes` which is also unused). The `truncate_to` and `truncate_from` methods were added by [JDK-8271515](https://bugs.openjdk.org/browse/JDK-8271515) and were unused right from the beginning. `data_size_in_bytes` was introduced by [JDK-8254231](https://bugs.openjdk.org/browse/JDK-8254231) and became unused after [JDK-8283689](https://bugs.openjdk.org/browse/JDK-8283689). Thanks, Tobias ------------- Commit messages: - 8301063: Remove dead code from GrowableArray Changes: https://git.openjdk.org/jdk/pull/12191/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12191&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301063 Stats: 15 lines in 1 file changed: 0 ins; 15 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12191.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12191/head:pull/12191 PR: https://git.openjdk.org/jdk/pull/12191 From jsjolen at openjdk.org Wed Jan 25 12:27:55 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 25 Jan 2023 12:27:55 GMT Subject: RFR: JDK-8300241: Replace NULL with nullptr in share/classfile/ [v2] In-Reply-To: References: Message-ID: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/classfile/. 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 with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge remote-tracking branch 'origin/master' into JDK-8300241 - Manual fixes - Replace NULL with nullptr in share/classfile/ ------------- Changes: https://git.openjdk.org/jdk/pull/12030/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12030&range=01 Stats: 1836 lines in 63 files changed: 0 ins; 0 del; 1836 mod Patch: https://git.openjdk.org/jdk/pull/12030.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12030/head:pull/12030 PR: https://git.openjdk.org/jdk/pull/12030 From jsjolen at openjdk.org Wed Jan 25 12:27:56 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 25 Jan 2023 12:27:56 GMT Subject: RFR: JDK-8300241: Replace NULL with nullptr in share/classfile/ [v2] In-Reply-To: <1cx2krtg3WjAP5Ky_T2SIHbu6JP3FeO9fgfBHVd-kqg=.e5656617-cbcf-4d94-b930-e7e553527079@github.com> References: <1cx2krtg3WjAP5Ky_T2SIHbu6JP3FeO9fgfBHVd-kqg=.e5656617-cbcf-4d94-b930-e7e553527079@github.com> Message-ID: On Tue, 24 Jan 2023 22:47:24 GMT, Coleen Phillimore wrote: >> Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - Merge remote-tracking branch 'origin/master' into JDK-8300241 >> - Manual fixes >> - Replace NULL with nullptr in share/classfile/ > > I didn't see any other places that needed changing. Hi @coleenp , I didn't click your suggested changes as they seem to be creating single commits for each change! ------------- PR: https://git.openjdk.org/jdk/pull/12030 From chagedorn at openjdk.org Wed Jan 25 12:33:04 2023 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Wed, 25 Jan 2023 12:33:04 GMT Subject: RFR: 8301063: Remove dead code from GrowableArray In-Reply-To: <3DLZGb6mDxMXam1-o-jdlIKkCCuicMfmz_dwVpuVBJs=.ff3f662f-939a-4155-8478-b758be6ba2f7@github.com> References: <3DLZGb6mDxMXam1-o-jdlIKkCCuicMfmz_dwVpuVBJs=.ff3f662f-939a-4155-8478-b758be6ba2f7@github.com> Message-ID: On Wed, 25 Jan 2023 11:55:26 GMT, Tobias Hartmann wrote: > While looking for a method to truncate a GrowableArray, I noticed that there are both `trunc_to` and `truncate_to` while the behavior of the latter is confusing. Since it's unused, I propose to remove it (together with `data_size_in_bytes` which is also unused). The `truncate_to` and `truncate_from` methods were added by [JDK-8271515](https://bugs.openjdk.org/browse/JDK-8271515) and were unused right from the beginning. `data_size_in_bytes` was introduced by [JDK-8254231](https://bugs.openjdk.org/browse/JDK-8254231) and became unused after [JDK-8283689](https://bugs.openjdk.org/browse/JDK-8283689). > > Thanks, > Tobias Looks good and trivial. ------------- Marked as reviewed by chagedorn (Reviewer). PR: https://git.openjdk.org/jdk/pull/12191 From dholmes at openjdk.org Wed Jan 25 12:34:05 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 25 Jan 2023 12:34:05 GMT Subject: RFR: JDK-8300783: Consolidate byteswap implementations [v8] In-Reply-To: References: Message-ID: <4T6ba7HVAkPmaau2WD3FRRyOlmEz7MDX5nz2UM-rfms=.58f59fc2-6030-4d9f-914f-5f37df4fb95e@github.com> On Tue, 24 Jan 2023 16:14:22 GMT, Justin King wrote: >> Deduplicate byte swapping implementations by consolidating them into `utilities/byteswap.hpp`, following `std::byteswap` introduced in C++23. Further simplification of `Bytes` will follow in https://github.com/openjdk/jdk/pull/12078. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Update comment > > Signed-off-by: Justin King CI run was fine wrt these changes. ------------- PR: https://git.openjdk.org/jdk/pull/12114 From iwalulya at openjdk.org Wed Jan 25 13:57:15 2023 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 25 Jan 2023 13:57:15 GMT Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable [v10] In-Reply-To: <1mczFcGXMJ-easbrP5X6Lz4dFHhMWs0zIOSb1eHtfmw=.741c639d-232c-434e-b88d-9457de2c51ce@github.com> References: <1mczFcGXMJ-easbrP5X6Lz4dFHhMWs0zIOSb1eHtfmw=.741c639d-232c-434e-b88d-9457de2c51ce@github.com> Message-ID: On Tue, 24 Jan 2023 21:59:44 GMT, Leo Korinth wrote: >> I am replacing the old hash table with ResourceHashtable. In the process I am also removing the redundant `_length` field. By removing the `_length` field, a lot of asserts can be removed as the length will trivially match the length of the underlying table. >> >> I would like to have feedback on the addition of `unlink_destruct(Function&& should_remove)`. I added it because I prefer to use a functor object that can be used by lambdas instead of an iterator object. However, I did add code to "destruct" resource objects when they are removed instead of just letting them be to reflect that we use `delete` on c-heap objects. Maybe I should remove this "improvement" and then maybe implement the function by calling the existing unlink? > > Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: > > - Merge branch '_master_jdk' into _8292170 > - include cleanups, test fix > - Remove the purge list and use the resizing of the resource hash > table. > > Add asserts ensuring that we do not mutatet a hash table while we > iterate over it. Renaming .*g1CodeCacheRemSet.?pp -> .*g1CodeRootSet.?pp > - code_roots_list_contains is now locked, but we have problems with add() during nmethods_do > - revert copyright year after changes > - add mem_size() method to resourceHash.hpp > - can not use contains in combination with add without a lock > - remove specialized hash > - inline g1CodeRootSetTable.hpp > - remove unused template > - ... and 3 more: https://git.openjdk.org/jdk/compare/b678e700...6e1832a2 Lgtm! ------------- Marked as reviewed by iwalulya (Reviewer). PR: https://git.openjdk.org/jdk/pull/11675 From aboldtch at openjdk.org Wed Jan 25 14:03:49 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 25 Jan 2023 14:03:49 GMT Subject: RFR: 8301088: oopDesc::print_on should consistently use a trailing newline Message-ID: [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161) added special printing when `oopDesc` contains `badHeapWordVal` or `badMetaWordVal`. However these two cases do not print a trailing newline. The previous behaviour was to always use a trailing newline. Propose making this consistent with `*klass::oop_print_on` and `InstanceStackChunkKlass::print_chunk`, that both uses a trailing newline. This new behaviour messes up some printing code, e.g. can be seen in print_location when printing hs_err files which assumes that it always prints a trailing newline. ------------- Commit messages: - oopDesc::print_on should consistently use a trailing newline Changes: https://git.openjdk.org/jdk/pull/12195/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12195&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301088 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/12195.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12195/head:pull/12195 PR: https://git.openjdk.org/jdk/pull/12195 From coleenp at openjdk.org Wed Jan 25 14:13:08 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 25 Jan 2023 14:13:08 GMT Subject: RFR: JDK-8300241: Replace NULL with nullptr in share/classfile/ [v2] In-Reply-To: <1cx2krtg3WjAP5Ky_T2SIHbu6JP3FeO9fgfBHVd-kqg=.e5656617-cbcf-4d94-b930-e7e553527079@github.com> References: <1cx2krtg3WjAP5Ky_T2SIHbu6JP3FeO9fgfBHVd-kqg=.e5656617-cbcf-4d94-b930-e7e553527079@github.com> Message-ID: On Tue, 24 Jan 2023 22:47:24 GMT, Coleen Phillimore wrote: >> Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - Merge remote-tracking branch 'origin/master' into JDK-8300241 >> - Manual fixes >> - Replace NULL with nullptr in share/classfile/ > > I didn't see any other places that needed changing. > Hi @coleenp , I didn't click your suggested changes as they seem to be creating single commits for each change! I think they have to be all or nothing to work, but it might be a good way to review these. ------------- PR: https://git.openjdk.org/jdk/pull/12030 From jcking at openjdk.org Wed Jan 25 14:22:03 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 25 Jan 2023 14:22:03 GMT Subject: RFR: JDK-8300783: Consolidate byteswap implementations [v8] In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 01:30:25 GMT, David Holmes wrote: > Have to wonder if we can go further with `get_Java_u2` etc, in a next step? Probably. We can visit that in https://github.com/openjdk/jdk/pull/12078 after this one. We might be able to do something like `LittleEndian` and `BigEndian` where each has `store`, `store_unaligned`, `load`, and `load_unaligned`. `LittleEndian` would convert native to little endian for store and do the inverse for load. `BigEndian` would do the same for big endian. In cases where they are the same to native, its a noop. uint32_t* aligned_ptr = /* */; void* unaligned_ptr = /* */; BigEndian::store(aligned_ptr, 1); BigEndian::load(aligned_ptr); BigEndian::store_unaligned(unaligned_ptr, 1); BigEndian::load_unaligned(unaligned_ptr); Maybe. Just a thought. ------------- PR: https://git.openjdk.org/jdk/pull/12114 From jsjolen at openjdk.org Wed Jan 25 14:35:06 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 25 Jan 2023 14:35:06 GMT Subject: RFR: JDK-8301069: Replace NULL with nullptr in share/libadt/ In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 11:45:35 GMT, Johan Sj?len wrote: > Do the conversion in the share/libadt/ sub-directory and all of its files. I consider this a trivial review. I'd appreciate it if the reviewer concurs so that I can merge it with only 1 reviewer. ------------- PR: https://git.openjdk.org/jdk/pull/12184 From jsjolen at openjdk.org Wed Jan 25 14:48:38 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 25 Jan 2023 14:48:38 GMT Subject: RFR: JDK-8300241: Replace NULL with nullptr in share/classfile/ [v2] In-Reply-To: References: Message-ID: <2lBR76uTfH6hREkFw5AAZYsf6HDvPPHAgykiazC5nl4=.8f9a6784-774a-4d13-a1ac-1994e2f5c274@github.com> On Wed, 25 Jan 2023 12:27:55 GMT, Johan Sj?len wrote: >> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/classfile/. 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 with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge remote-tracking branch 'origin/master' into JDK-8300241 > - Manual fixes > - Replace NULL with nullptr in share/classfile/ Passes tier1. ------------- PR: https://git.openjdk.org/jdk/pull/12030 From jsjolen at openjdk.org Wed Jan 25 15:17:56 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 25 Jan 2023 15:17:56 GMT Subject: RFR: JDK-8301070: Replace NULL with nullptr in share/memory/ Message-ID: Do the conversion in the share/memory/ sub-directory and all of its files. ------------- Commit messages: - Fix manual issue - Replace NULL with nullptr in share/memory/ Changes: https://git.openjdk.org/jdk/pull/12185/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12185&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301070 Stats: 678 lines in 65 files changed: 0 ins; 0 del; 678 mod Patch: https://git.openjdk.org/jdk/pull/12185.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12185/head:pull/12185 PR: https://git.openjdk.org/jdk/pull/12185 From jsjolen at openjdk.org Wed Jan 25 15:18:00 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 25 Jan 2023 15:18:00 GMT Subject: RFR: JDK-8301070: Replace NULL with nullptr in share/memory/ In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 11:45:47 GMT, Johan Sj?len wrote: > Do the conversion in the share/memory/ sub-directory and all of its files. Found one manual fix src/hotspot/share/memory/heap.cpp line 666: > 664: /** > 665: * Search freelist for an entry on the list with the best fit. > 666: * @return nullptr, if no one was found null ------------- PR: https://git.openjdk.org/jdk/pull/12185 From jsjolen at openjdk.org Wed Jan 25 15:18:59 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 25 Jan 2023 15:18:59 GMT Subject: RFR: JDK-8301077: Replace NULL with nullptr in share/services/ Message-ID: Do the conversion in the share/services/ sub-directory and all of its files. ------------- Commit messages: - Manual fixes - Replace NULL with nullptr in share/services/ Changes: https://git.openjdk.org/jdk/pull/12189/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12189&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301077 Stats: 856 lines in 44 files changed: 0 ins; 0 del; 856 mod Patch: https://git.openjdk.org/jdk/pull/12189.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12189/head:pull/12189 PR: https://git.openjdk.org/jdk/pull/12189 From jsjolen at openjdk.org Wed Jan 25 15:19:10 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 25 Jan 2023 15:19:10 GMT Subject: RFR: JDK-8301077: Replace NULL with nullptr in share/services/ In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 11:47:18 GMT, Johan Sj?len wrote: > Do the conversion in the share/services/ sub-directory and all of its files. Found some things to manually fix. src/hotspot/share/services/attachListener.cpp line 368: > 366: { "printflag", print_flag }, > 367: { "jcmd", jcmd }, > 368: { nullptr, nullptr } Align src/hotspot/share/services/classLoadingService.cpp line 51: > 49: int len = 0; \ > 50: Symbol* name = (clss)->name(); \ > 51: if (name != nullptr) { \ Align src/hotspot/share/services/diagnosticFramework.cpp line 40: > 38: : _cmd(line), _cmd_len(0), _args(nullptr), _args_len(0) > 39: { > 40: assert(line != nullptr, "Command line string should not be nullptr"); String src/hotspot/share/services/heapDumper.cpp line 793: > 791: void allocate_internal_buffer() { > 792: assert(_buffer_queue != nullptr, "Internal buffer queue is not ready when allocate internal buffer"); > 793: assert(_buffer == nullptr && _buffer_base == nullptr, "current buffer must be nullptr before allocate"); String src/hotspot/share/services/heapDumper.cpp line 1293: > 1291: // creates HPROF_GC_CLASS_DUMP record for the given array class > 1292: void DumperSupport::dump_array_class(AbstractDumpWriter* writer, Klass* k) { > 1293: InstanceKlass* ik = nullptr; // bottom class for object arrays, null for primitive type arrays string src/hotspot/share/services/memReporter.cpp line 384: > 382: > 383: void MemDetailReporter::report_virtual_memory_region(const ReservedMemoryRegion* reserved_rgn) { > 384: assert(reserved_rgn != nullptr, "nullptr pointer"); string src/hotspot/share/services/memReporter.cpp line 820: > 818: outputStream* out = output(); > 819: > 820: assert(stack != nullptr, "nullptr stack"); string src/hotspot/share/services/memTracker.hpp line 98: > 96: static inline void* record_malloc(void* mem_base, size_t size, MEMFLAGS flag, > 97: const NativeCallStack& stack) { > 98: assert(mem_base != nullptr, "caller should handle nullptr"); String src/hotspot/share/services/memTracker.hpp line 108: > 106: static inline void* record_free(void* memblock) { > 107: // Never turned on > 108: assert(memblock != nullptr, "caller should handle nullptr"); String ------------- PR: https://git.openjdk.org/jdk/pull/12189 From tschatzl at openjdk.org Wed Jan 25 15:34:39 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 25 Jan 2023 15:34:39 GMT Subject: RFR: 8221785: Let possibly_parallel_threads_do cover the same threads as threads_do Message-ID: Hi all, can I have reviews for this change that makes `Threads::possibly_parallel_threads_do` iterate over the same set of threads as `threads_do` to have parity? I.e. over all java and non-java threads. Originally this CR has been created to make a new method that keeps iterating only over java threads and the VM thread, but it's a bit weird to have both variants as the overhead of the extra threads is negligible and otherwise just confusing. So I made `Threads::possibly_parallel_threads_do` iterate over all threads; all uses support that afaict, also all uses correctly change the claim token (mostly in the enclosing `StrongRootsScope`). This allows some minimally better hiding of the token mechanism. One other reason for not doing this in the first place (as in [JDK-8221102](https://bugs.openjdk.org/browse/JDK-8221102), or as discussed [here](https://mail.openjdk.org/pipermail/hotspot-dev/2019-April/037541.html)) has been the fear that there would be a problem with threads being created during iteration and the (common) call to 'Threads::assert_all_threads_claimed`. However all calls so far are during a safepoint, and none seem to create new threads. I suggest to defer looking at this problem when it is important. Moreover I need that functionality is required for (JDK-8211104)[https://bugs.openjdk.org/browse/JDK-8211104]. :) Testing: tier1-4, gha Thanks, Thomas ------------- Commit messages: - Replace existing manual claiming with possibly_parallel_threads_do calls - initial version, just making possibly_parallel_threads_do cover the same threads as threads_do Changes: https://git.openjdk.org/jdk/pull/12201/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12201&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8221785 Stats: 55 lines in 7 files changed: 16 ins; 8 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/12201.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12201/head:pull/12201 PR: https://git.openjdk.org/jdk/pull/12201 From thartmann at openjdk.org Wed Jan 25 15:39:21 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 25 Jan 2023 15:39:21 GMT Subject: RFR: 8301063: Remove dead code from GrowableArray In-Reply-To: <3DLZGb6mDxMXam1-o-jdlIKkCCuicMfmz_dwVpuVBJs=.ff3f662f-939a-4155-8478-b758be6ba2f7@github.com> References: <3DLZGb6mDxMXam1-o-jdlIKkCCuicMfmz_dwVpuVBJs=.ff3f662f-939a-4155-8478-b758be6ba2f7@github.com> Message-ID: <18qVwB2Oq1GErYCyFwarQe7dyaHF9OIUxM5r-NII6w8=.aaae5361-74b3-41ab-b41c-23960e7aa415@github.com> On Wed, 25 Jan 2023 11:55:26 GMT, Tobias Hartmann wrote: > While looking for a method to truncate a GrowableArray, I noticed that there are both `trunc_to` and `truncate_to` while the behavior of the latter is confusing. Since it's unused, I propose to remove it (together with `data_size_in_bytes` which is also unused). The `truncate_to` and `truncate_from` methods were added by [JDK-8271515](https://bugs.openjdk.org/browse/JDK-8271515) and were unused right from the beginning. `data_size_in_bytes` was introduced by [JDK-8254231](https://bugs.openjdk.org/browse/JDK-8254231) and became unused after [JDK-8283689](https://bugs.openjdk.org/browse/JDK-8283689). > > Thanks, > Tobias Thanks for the review, Christian! ------------- PR: https://git.openjdk.org/jdk/pull/12191 From xuelei at openjdk.org Wed Jan 25 15:43:16 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 25 Jan 2023 15:43:16 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v8] In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 02:05:31 GMT, Mikael Vidstedt wrote: > Looks good, thank you for doing this! @vidmik Thank you! ------------- PR: https://git.openjdk.org/jdk/pull/11935 From xuelei at openjdk.org Wed Jan 25 15:47:52 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 25 Jan 2023 15:47:52 GMT Subject: Integrated: 8299635: Hotspot update for deprecated sprintf in Xcode 14 In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 06:26:18 GMT, Xue-Lei Andrew Fan wrote: > The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. > > This patch is trying to find the use of sprintf in hotspot iml and test cases. This pull request has now been integrated. Changeset: e80b5ea4 Author: Xue-Lei Andrew Fan URL: https://git.openjdk.org/jdk/commit/e80b5ea448c715519d14e238321ceb5ec40b37f4 Stats: 109 lines in 40 files changed: 4 ins; 2 del; 103 mod 8299635: Hotspot update for deprecated sprintf in Xcode 14 Reviewed-by: dholmes, mikael ------------- PR: https://git.openjdk.org/jdk/pull/11935 From jcking at openjdk.org Wed Jan 25 15:52:34 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 25 Jan 2023 15:52:34 GMT Subject: RFR: JDK-8300783: Consolidate byteswap implementations [v9] In-Reply-To: References: Message-ID: > Deduplicate byte swapping implementations by consolidating them into `utilities/byteswap.hpp`, following `std::byteswap` introduced in C++23. Further simplification of `Bytes` will follow in https://github.com/openjdk/jdk/pull/12078. Justin King has updated the pull request incrementally with one additional commit since the last revision: Consolidate more byteswap implementations and upgrade bit reversal Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12114/files - new: https://git.openjdk.org/jdk/pull/12114/files/f6996e1a..56e5c235 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12114&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12114&range=07-08 Stats: 196 lines in 3 files changed: 97 ins; 25 del; 74 mod Patch: https://git.openjdk.org/jdk/pull/12114.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12114/head:pull/12114 PR: https://git.openjdk.org/jdk/pull/12114 From jcking at openjdk.org Wed Jan 25 15:52:38 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 25 Jan 2023 15:52:38 GMT Subject: RFR: JDK-8300783: Consolidate byteswap implementations [v8] In-Reply-To: <4T6ba7HVAkPmaau2WD3FRRyOlmEz7MDX5nz2UM-rfms=.58f59fc2-6030-4d9f-914f-5f37df4fb95e@github.com> References: <4T6ba7HVAkPmaau2WD3FRRyOlmEz7MDX5nz2UM-rfms=.58f59fc2-6030-4d9f-914f-5f37df4fb95e@github.com> Message-ID: <1n4CfPBA1lwtDjzXyhPt214JxgIaiRjYWGFbRqOPZME=.fa3fd409-2617-4c2a-917b-788e000f82a0@github.com> On Wed, 25 Jan 2023 12:31:11 GMT, David Holmes wrote: >> Justin King has updated the pull request incrementally with one additional commit since the last revision: >> >> Update comment >> >> Signed-off-by: Justin King > > CI run was fine wrt these changes. @dholmes-ora I found more duplicate byteswap implementations. One in `src/hotspot/cpu/ppc/stubRoutines_ppc_64.cpp` and another in `utilities/moveBits.hpp`. `utilities/moveBits.hpp` is now just bit reversal, as none of the other functions are called anywhere. It should probably be renamed... I also upgraded `utilities/moveBits.hpp` to use `__builtin_bitreverse` from Clang when available. I am not aware of MSVC or XLC having a bit reversal intrinsic. ------------- PR: https://git.openjdk.org/jdk/pull/12114 From jcking at openjdk.org Wed Jan 25 15:58:53 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 25 Jan 2023 15:58:53 GMT Subject: RFR: JDK-8300783: Consolidate byteswap implementations [v10] In-Reply-To: References: Message-ID: > Deduplicate byte swapping implementations by consolidating them into `utilities/byteswap.hpp`, following `std::byteswap` introduced in C++23. Further simplification of `Bytes` will follow in https://github.com/openjdk/jdk/pull/12078. 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 16 additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into byteswap - Be restrict on requiring 1, 2, 4, or 8 byte integers Signed-off-by: Justin King - Consolidate more byteswap implementations and upgrade bit reversal Signed-off-by: Justin King - Update comment Signed-off-by: Justin King - Add missing static_cast to XL C/C++ implementation Signed-off-by: Justin King - Cleanup Bytes::swap_uN Signed-off-by: Justin King - Add XL C/C++ builtins Signed-off-by: Justin King - Fix mistake in MSVC implementation Signed-off-by: Justin King - Update comment to reflect previous commit change Signed-off-by: Justin King - Use __bulitin_bswap for GCC in debug builds Signed-off-by: Justin King - ... and 6 more: https://git.openjdk.org/jdk/compare/051995b8...3b9decfa ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12114/files - new: https://git.openjdk.org/jdk/pull/12114/files/56e5c235..3b9decfa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12114&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12114&range=08-09 Stats: 22873 lines in 944 files changed: 9818 ins; 3924 del; 9131 mod Patch: https://git.openjdk.org/jdk/pull/12114.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12114/head:pull/12114 PR: https://git.openjdk.org/jdk/pull/12114 From coleenp at openjdk.org Wed Jan 25 16:03:28 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 25 Jan 2023 16:03:28 GMT Subject: RFR: 8300913: ZGC: assert(to_addr != 0) failed: Should be forwarded Message-ID: We thought we didn't need the keep-alive call but we do for heap walking. Tested with failing test case locally, and tier1-4 in progress. ------------- Commit messages: - 8300913: ZGC: assert(to_addr != 0) failed: Should be forwarded Changes: https://git.openjdk.org/jdk/pull/12202/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12202&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300913 Stats: 14 lines in 2 files changed: 5 ins; 8 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12202.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12202/head:pull/12202 PR: https://git.openjdk.org/jdk/pull/12202 From jsjolen at openjdk.org Wed Jan 25 16:19:58 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 25 Jan 2023 16:19:58 GMT Subject: RFR: JDK-8301077: Replace NULL with nullptr in share/services/ In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 11:47:18 GMT, Johan Sj?len wrote: > Do the conversion in the share/services/ sub-directory and all of its files. Passes tier1. ------------- PR: https://git.openjdk.org/jdk/pull/12189 From jsjolen at openjdk.org Wed Jan 25 16:20:01 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 25 Jan 2023 16:20:01 GMT Subject: RFR: JDK-8301070: Replace NULL with nullptr in share/memory/ In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 11:45:47 GMT, Johan Sj?len wrote: > Do the conversion in the share/memory/ sub-directory and all of its files. Passes tier1. ------------- PR: https://git.openjdk.org/jdk/pull/12185 From eosterlund at openjdk.org Wed Jan 25 16:33:59 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 25 Jan 2023 16:33:59 GMT Subject: RFR: 8300913: ZGC: assert(to_addr != 0) failed: Should be forwarded In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 15:56:49 GMT, Coleen Phillimore wrote: > We thought we didn't need the keep-alive call but we do for heap walking. > Tested with failing test case locally, and tier1-4 in progress. Looks good! ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.org/jdk/pull/12202 From dcubed at openjdk.org Wed Jan 25 17:19:30 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 25 Jan 2023 17:19:30 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v4] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 20:10:21 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Renaissance >> >> >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Revert UseFastLocking to default to off This PR is currently baselined on jdk-21+6-289. ------------- PR: https://git.openjdk.org/jdk/pull/10907 From kvn at openjdk.org Wed Jan 25 17:20:25 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 25 Jan 2023 17:20:25 GMT Subject: RFR: 8301063: Remove dead code from GrowableArray In-Reply-To: <3DLZGb6mDxMXam1-o-jdlIKkCCuicMfmz_dwVpuVBJs=.ff3f662f-939a-4155-8478-b758be6ba2f7@github.com> References: <3DLZGb6mDxMXam1-o-jdlIKkCCuicMfmz_dwVpuVBJs=.ff3f662f-939a-4155-8478-b758be6ba2f7@github.com> Message-ID: On Wed, 25 Jan 2023 11:55:26 GMT, Tobias Hartmann wrote: > While looking for a method to truncate a GrowableArray, I noticed that there are both `trunc_to` and `truncate_to` while the behavior of the latter is confusing. Since it's unused, I propose to remove it (together with `data_size_in_bytes` which is also unused). The `truncate_to` and `truncate_from` methods were added by [JDK-8271515](https://bugs.openjdk.org/browse/JDK-8271515) and were unused right from the beginning. `data_size_in_bytes` was introduced by [JDK-8254231](https://bugs.openjdk.org/browse/JDK-8254231) and became unused after [JDK-8283689](https://bugs.openjdk.org/browse/JDK-8283689). > > Thanks, > Tobias Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/12191 From kvn at openjdk.org Wed Jan 25 17:23:10 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 25 Jan 2023 17:23:10 GMT Subject: RFR: JDK-8301069: Replace NULL with nullptr in share/libadt/ In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 11:45:35 GMT, Johan Sj?len wrote: > Do the conversion in the share/libadt/ sub-directory and all of its files. Good and trivial. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/12184 From gziemski at openjdk.org Wed Jan 25 17:38:06 2023 From: gziemski at openjdk.org (Gerard Ziemski) Date: Wed, 25 Jan 2023 17:38:06 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v4] In-Reply-To: References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> <_khJTogN_LFzv_VSMdncQeFf9zyMDgWGaiPRTuuXVl0=.2dad11d6-cc4e-46de-ad11-7bb607e8900e@github.com> Message-ID: On Wed, 25 Jan 2023 06:22:47 GMT, Thomas Stuefe wrote: >> src/hotspot/share/runtime/os.cpp line 707: >> >>> 705: >>> 706: // Observe MallocLimit >>> 707: if (size > old_size && MemTracker::check_exceeds_limit(size - old_size, memflags)) { >> >> Can we make it a bit easier to parse by rewriting it as: >> >> ` if ((size > old_size) && MemTracker::check_exceeds_limit(size - old_size, memflags)) {` >> >> To me personally that is easier to read. >> >> I see a bigger issue here, however. In the worst case scenario, where the os is unable to expand the memory chunk in place, it will need to allocate `size` bytes in a new region, so the total **potential** resources from the os point of view is `size+old_size` bytes for that particular allocation. Shouldn't we assume this worst case and test for that? I.e. >> >> ` if ((size > old_size) && MemTracker::check_exceeds_limit(size, memflags)) {` >> >> We would need a comment here explaining this choice if we make this change. >> >> I'd rather get some false positives that miss a single true positive... > >> Can we make it a bit easier to parse by rewriting it as: >> >> ` if ((size > old_size) && MemTracker::check_exceeds_limit(size - old_size, memflags)) {` >> >> To me personally that is easier to read. >> > > Sure > >> I see a bigger issue here, however. In the worst case scenario, where the os is unable to expand the memory chunk in place, it will need to allocate `size` bytes in a new region, so the total **potential** resources from the os point of view is `size+old_size` bytes for that particular allocation. Shouldn't we assume this worst case and test for that? I.e. >> >> ` if ((size > old_size) && MemTracker::check_exceeds_limit(size, memflags)) {` >> >> We would need a comment here explaining this choice if we make this change. >> >> I'd rather get some false positives that miss a single true positive... > > Nah, no need to overthink this. > > If you try to predict how much memory your malloc causes your process to allocate, it gets very fuzzy very quickly: > > Below are at least two allocating layers (libc and the kernel's vm manager). Both of them balance memory and CPU footprint and allocation speed. No libc or kernel is the same, too. Each layer below you may return cached or partly cached memory and apply an often sizable overhead to what you are allocating. So our mallocs and frees have only a very indirect effect on RSS. And we don't even see all mallocs here, just the ones from libjvm. > > Therefore it is best to limit the meaning of MallocLimit to "limit to how much hotspot is allowed to allocate". That is also the most useful. For limiting the memory of a process, different os-side tools exist (cgroup limits, ulimit, etc). The entire point of this effort is to catch elusive OOM errors. You even moved the check for the memory requirements before we actually request it, from the current way where we check the limit only after we acquire new memory. Isn't assuming the worst case scenario, where realloc(), might allocate new memory first, in the same vein as that and we are just being cautious, to catch those hard to reproduce bugs? This cases might not occur very often, granted, but why not catch them if we can? Aren't there any platforms where we run Java where realloc() is implemented in terms of malloc() and memcpy()? ------------- PR: https://git.openjdk.org/jdk/pull/11371 From gziemski at openjdk.org Wed Jan 25 17:40:48 2023 From: gziemski at openjdk.org (Gerard Ziemski) Date: Wed, 25 Jan 2023 17:40:48 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v4] In-Reply-To: References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> <_khJTogN_LFzv_VSMdncQeFf9zyMDgWGaiPRTuuXVl0=.2dad11d6-cc4e-46de-ad11-7bb607e8900e@github.com> Message-ID: On Wed, 25 Jan 2023 06:26:42 GMT, Thomas Stuefe wrote: >> src/hotspot/share/services/mallocTracker.inline.hpp line 35: >> >>> 33: #include "utilities/vmError.hpp" >>> 34: >>> 35: static inline bool suppress_limit_handling() { >> >> Why did we bother to wrap `VMError::is_error_reported()` into `suppress_limit_handling()`? >> >> Are you anticipating more exclusions here in the future? > >> Why did we bother to wrap `VMError::is_error_reported()` into `suppress_limit_handling()`? >> > > Because during error handling, code may malloc() too (bad practice, but it can happen). If it does, I don't want circular assertions to fire; I want a clean, complete hs-err file. > >> Are you anticipating more exclusions here in the future? > > None I can think of. That explains why we want to call `VMError::is_error_reported()` sure, but not why we wrapped it in `suppress_limit_handling()` SPI, unless I am missing something? ------------- PR: https://git.openjdk.org/jdk/pull/11371 From jcking at openjdk.org Wed Jan 25 17:41:13 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 25 Jan 2023 17:41:13 GMT Subject: RFR: JDK-8300783: Consolidate byteswap implementations [v11] In-Reply-To: References: Message-ID: <3uBeKIc_YXtM7PyyL1s8JOi-dQRpFGYEVNM1taKHtFI=.db1a5667-94f2-4456-867c-a0701b794210@github.com> > Deduplicate byte swapping implementations by consolidating them into `utilities/byteswap.hpp`, following `std::byteswap` introduced in C++23. Further simplification of `Bytes` will follow in https://github.com/openjdk/jdk/pull/12078. Justin King has updated the pull request incrementally with one additional commit since the last revision: Fix test Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12114/files - new: https://git.openjdk.org/jdk/pull/12114/files/3b9decfa..d43b9f10 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12114&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12114&range=09-10 Stats: 34 lines in 1 file changed: 0 ins; 5 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/12114.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12114/head:pull/12114 PR: https://git.openjdk.org/jdk/pull/12114 From gziemski at openjdk.org Wed Jan 25 17:44:47 2023 From: gziemski at openjdk.org (Gerard Ziemski) Date: Wed, 25 Jan 2023 17:44:47 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v4] In-Reply-To: References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> <_khJTogN_LFzv_VSMdncQeFf9zyMDgWGaiPRTuuXVl0=.2dad11d6-cc4e-46de-ad11-7bb607e8900e@github.com> Message-ID: On Wed, 25 Jan 2023 06:51:04 GMT, Thomas Stuefe wrote: >> src/hotspot/share/services/mallocTracker.inline.hpp line 56: >> >>> 54: size_t so_far = as_snapshot()->total(); >>> 55: if ((so_far + s) > l->sz) { // hit the limit >>> 56: if (!suppress_limit_handling()) { >> >> I would prefer to see `suppress_limit_handling()` checked inside `total_limit_reached()`, same for `category_limit_reached()`. This way we would force those APIs to always obey the suppression without having to bother to add `suppress_limit_handling()`, they could call `VMError::is_error_reported()` directly. > >> I would prefer to see `suppress_limit_handling()` checked inside `total_limit_reached()`, same for `category_limit_reached()`. This way we would force those APIs to always obey the suppression without having to bother to add `suppress_limit_handling()`, they could call `VMError::is_error_reported()` directly. > > Note that `total_limit_reached()` and `category_limit_reached()` are private APIs. > > If we move `suppress_limit_handling()` into `total_limit_reached()`, `total_limit_reached()` would need to report it back to `MallocMemorySummary::check_exceeds_limit` since its processed there too, it affects the return code. So `total_limit_reached()` cannot be void anymore, and gets somewhat more complex. I prefer it this way, tbh. I'm not following. If we get rid of `suppress_limit_handling()` SPI, and do: bool MallocMemorySummary::total_limit_reached(size_t s, size_t so_far, const malloclimit* limit) { if (VMError::is_error_reported()) { return false; } #define FORMATTED \ "MallocLimit: reached global limit (triggering allocation size: " PROPERFMT ", allocated so far: " PROPERFMT ", limit: " PROPERFMT ") ", \ PROPERFMTARGS(s), PROPERFMTARGS(so_far), PROPERFMTARGS(limit->sz) if (limit->mode == MallocLimitMode::trigger_fatal) { fatal(FORMATTED); } else { log_warning(nmt)(FORMATTED); } #undef FORMATTED return true; } bool MallocMemorySummary::category_limit_reached(MEMFLAGS f, size_t s, size_t so_far, const malloclimit* limit) { if (VMError::is_error_reported()) { return false; } #define FORMATTED \ "MallocLimit: reached category "%s" limit (triggering allocation size: " PROPERFMT ", allocated so far: " PROPERFMT ", limit: " PROPERFMT ") ", \ NMTUtil::flag_to_enum_name(f), PROPERFMTARGS(s), PROPERFMTARGS(so_far), PROPERFMTARGS(limit->sz) if (limit->mode == MallocLimitMode::trigger_fatal) { fatal(FORMATTED); } else { log_warning(nmt)(FORMATTED); } #undef FORMATTED return true; } then we can simply have: // Returns true if allocating s bytes on f would trigger either global or the category limit inline bool MallocMemorySummary::check_exceeds_limit(size_t s, MEMFLAGS f) { // Note: checks are ordered to have as little impact as possible on the standard code path, // when MallocLimit is unset, resp. it is set but we have reached no limit yet. // Somewhat expensive are: // - as_snapshot()->total(), total malloc load (requires iteration over arena types) // - VMError::is_error_reported() is a load from a volatile. if (MallocLimitHandler::have_limit()) { // Global Limit ? const malloclimit* l = MallocLimitHandler::global_limit(); if (l->sz > 0) { size_t so_far = as_snapshot()->total(); if ((so_far + s) > l->sz) { // hit the limit if (total_limit_reached(s, so_far, l)) { return true; } } } else { // Category Limit ? l = MallocLimitHandler::category_limit(f); if (l->sz > 0) { const MallocMemory* mm = as_snapshot()->by_type(f); size_t so_far = mm->malloc_size() + mm->arena_size(); if ((so_far + s) > l->sz) { if (category_limit_reached(f, s, so_far, l)) { return true; } } } } } return false; } Doesn't that work? ------------- PR: https://git.openjdk.org/jdk/pull/11371 From cjplummer at openjdk.org Wed Jan 25 18:32:51 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 25 Jan 2023 18:32:51 GMT Subject: RFR: JDK-8301077: Replace NULL with nullptr in share/services/ In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 11:47:18 GMT, Johan Sj?len wrote: > Do the conversion in the share/services/ sub-directory and all of its files. Changes requested by cjplummer (Reviewer). src/hotspot/share/services/heapDumper.cpp line 1850: > 1848: > 1849: void prepare_parallel_dump(uint num_total) { > 1850: assert (_dumper_controller == nullptr, "dumper controller must be nullptr"); The string should say "null", not "nullptr". src/hotspot/share/services/mallocTracker.hpp line 332: > 330: > 331: static inline MallocHeader* malloc_header(void *memblock) { > 332: assert(memblock != nullptr, "nullptr pointer"); String should say "null", not "nullptr" src/hotspot/share/services/mallocTracker.hpp line 336: > 334: } > 335: static inline const MallocHeader* malloc_header(const void *memblock) { > 336: assert(memblock != nullptr, "nullptr pointer"); String should say "null", not "nullptr" src/hotspot/share/services/management.cpp line 1646: > 1644: typeArrayHandle times) { > 1645: assert(names() != nullptr, "names was nullptr"); > 1646: assert(times() != nullptr, "times was nullptr"); String should say "null", not "nullptr" src/hotspot/share/services/management.cpp line 1660: > 1658: void ThreadTimesClosure::do_thread(Thread* thread) { > 1659: assert(Threads_lock->owned_by_self(), "Must hold Threads_lock"); > 1660: assert(thread != nullptr, "thread was nullptr"); String should say "null", not "nullptr" src/hotspot/share/services/threadService.cpp line 224: > 222: // FIXME: JVMTI should call this function > 223: Handle ThreadService::get_current_contended_monitor(JavaThread* thread) { > 224: assert(thread != nullptr, "should be non-nullptr"); String should say "null", not "nullptr" ------------- PR: https://git.openjdk.org/jdk/pull/12189 From thartmann at openjdk.org Wed Jan 25 19:17:45 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 25 Jan 2023 19:17:45 GMT Subject: RFR: 8301063: Remove dead code from GrowableArray In-Reply-To: <3DLZGb6mDxMXam1-o-jdlIKkCCuicMfmz_dwVpuVBJs=.ff3f662f-939a-4155-8478-b758be6ba2f7@github.com> References: <3DLZGb6mDxMXam1-o-jdlIKkCCuicMfmz_dwVpuVBJs=.ff3f662f-939a-4155-8478-b758be6ba2f7@github.com> Message-ID: On Wed, 25 Jan 2023 11:55:26 GMT, Tobias Hartmann wrote: > While looking for a method to truncate a GrowableArray, I noticed that there are both `trunc_to` and `truncate_to` while the behavior of the latter is confusing. Since it's unused, I propose to remove it (together with `data_size_in_bytes` which is also unused). The `truncate_to` and `truncate_from` methods were added by [JDK-8271515](https://bugs.openjdk.org/browse/JDK-8271515) and were unused right from the beginning. `data_size_in_bytes` was introduced by [JDK-8254231](https://bugs.openjdk.org/browse/JDK-8254231) and became unused after [JDK-8283689](https://bugs.openjdk.org/browse/JDK-8283689). > > Thanks, > Tobias Thanks, Vladimir. ------------- PR: https://git.openjdk.org/jdk/pull/12191 From iklam at openjdk.org Wed Jan 25 20:19:51 2023 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 25 Jan 2023 20:19:51 GMT Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable [v10] In-Reply-To: <1mczFcGXMJ-easbrP5X6Lz4dFHhMWs0zIOSb1eHtfmw=.741c639d-232c-434e-b88d-9457de2c51ce@github.com> References: <1mczFcGXMJ-easbrP5X6Lz4dFHhMWs0zIOSb1eHtfmw=.741c639d-232c-434e-b88d-9457de2c51ce@github.com> Message-ID: <8kyBQTaQ2C-OWX_t03AQ7Zjvl7h1brCLeGoALigNNH0=.67b68755-6b19-42ba-a6ba-f00e8e888c6c@github.com> On Tue, 24 Jan 2023 21:59:44 GMT, Leo Korinth wrote: >> I am replacing the old hash table with ResourceHashtable. In the process I am also removing the redundant `_length` field. By removing the `_length` field, a lot of asserts can be removed as the length will trivially match the length of the underlying table. >> >> I would like to have feedback on the addition of `unlink_destruct(Function&& should_remove)`. I added it because I prefer to use a functor object that can be used by lambdas instead of an iterator object. However, I did add code to "destruct" resource objects when they are removed instead of just letting them be to reflect that we use `delete` on c-heap objects. Maybe I should remove this "improvement" and then maybe implement the function by calling the existing unlink? > > Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: > > - Merge branch '_master_jdk' into _8292170 > - include cleanups, test fix > - Remove the purge list and use the resizing of the resource hash > table. > > Add asserts ensuring that we do not mutatet a hash table while we > iterate over it. Renaming .*g1CodeCacheRemSet.?pp -> .*g1CodeRootSet.?pp > - code_roots_list_contains is now locked, but we have problems with add() during nmethods_do > - revert copyright year after changes > - add mem_size() method to resourceHash.hpp > - can not use contains in combination with add without a lock > - remove specialized hash > - inline g1CodeRootSetTable.hpp > - remove unused template > - ... and 3 more: https://git.openjdk.org/jdk/compare/b678e700...6e1832a2 LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.org/jdk/pull/11675 From luhenry at openjdk.org Wed Jan 25 20:21:48 2023 From: luhenry at openjdk.org (Ludovic Henry) Date: Wed, 25 Jan 2023 20:21:48 GMT Subject: RFR: 8301036: RISC-V: Factor out functions baseOffset & baseOffset32 from MacroAssembler In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 04:50:40 GMT, Fei Yang wrote: > The functions baseOffset & baseOffset32 from MacroAssembler on RISC-V receive an Address in base_plus_offset mode. They check the range of the offset, add it and base and put the result in a destination register. This duplicates function MacroAssembler::la in functionality. We could refactor this part putting the logic of Address legitimization into MacroAssembler::la and use this function instead. > > Testing: > - [x] Bootcycle (release & fastdebug) > - [x] Tier1-4 (release) > - [x] Benchmarks: SPECjbb2015 (release) src/hotspot/cpu/riscv/interp_masm_riscv.cpp line 263: > 261: int bcp_offset, > 262: size_t index_size) { > 263: assert(cache != tmp, "should be different registers"); It could be worth replacing with `assert_different_registers` src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 2394: > 2392: > 2393: assert(Rd != noreg, "expecting a register"); > 2394: guarantee(Rd != base, "should be different registers"); Why not `assert`? ------------- PR: https://git.openjdk.org/jdk/pull/12177 From gziemski at openjdk.org Wed Jan 25 20:31:48 2023 From: gziemski at openjdk.org (Gerard Ziemski) Date: Wed, 25 Jan 2023 20:31:48 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v4] In-Reply-To: <_khJTogN_LFzv_VSMdncQeFf9zyMDgWGaiPRTuuXVl0=.2dad11d6-cc4e-46de-ad11-7bb607e8900e@github.com> References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> <_khJTogN_LFzv_VSMdncQeFf9zyMDgWGaiPRTuuXVl0=.2dad11d6-cc4e-46de-ad11-7bb607e8900e@github.com> Message-ID: On Tue, 24 Jan 2023 08:14:31 GMT, Thomas Stuefe wrote: >> Rework NMT `MallocLimit` to make it more useful for native OOM analysis. Also remove `MallocMaxTestWords`, which had been mostly redundant with NMT (for background, see JDK-8293292). >> >> >> ### Background >> >> Some months ago we had [JDK-8291919](https://bugs.openjdk.org/browse/JDK-8291919), a compiler regression that caused compiler arenas to grow boundlessly. Process was usually OOM-killed before we could take a look, so this was difficult to analyze. >> >> To improve analysis options, we added NMT *malloc limits* with [JDK-8291878](https://bugs.openjdk.org/browse/JDK-8291878). Malloc limits let us set one or multiple limits to malloc load. Surpassing a limit causes the VM to stop with a fatal error in the allocation function, giving us a hs-err file and a core right at the point that (probably) causes the leak. This makes error analysis a lot simpler, and is also valuable for regression-testing footprint usage. >> >> Some people wished for a way to not end with a fatal error but to mimic a native OOM (causing os::malloc to return NULL). This would allow us to test resilience in the face of native OOMs, among other things. >> >> ### Patch >> >> - Expands the `MallocLimit` option syntax, allowing for an "oom mode" that mimics an oom: >> >> >> >> Global form: >> -XX:MallocLimit=[:] >> Category-specific form: >> -XX:MallocLimit=:[:][,:[:] ...] >> Examples: >> -XX:MallocLimit=3g >> -XX:MallocLimit=3g:oom >> -XX:MallocLimit=compiler:200m:oom >> >> >> - moves parsing of `-XX:MallocLimit` out of arguments.cpp into `mallocLimit.hpp/cpp`, and rewrites it. >> >> - changes when limits are checked. Before, the limits were checked *after* the allocation that caused the threshold overflow. Now we check beforehand. >> >> - removes `MallocMaxTestWords`, replacing its uses with `MallocLimit` >> >> - adds new gtests and new jtreg tests >> >> - removes a bunch of jtreg tests which are now better served by the new gtests. >> >> - gives us more precise error messages upon reaching a limit. For example: >> >> before: >> >> # fatal error: MallocLimit: category "Compiler" reached limit (size: 20997680, limit: 20971520) >> >> >> now: >> >> # fatal error: MallocLimit: reached category "Compiler" limit (triggering allocation size: 1920B, allocated so far: 20505K, limit: 20480K) > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Revert strchrnul More feedback... src/hotspot/share/services/mallocLimit.cpp line 150: > 148: } > 149: } > 150: } I am not crazy about: static const char* flagnames[] = { "fatal", "oom" }; which requires that we position the strings in `flagnames` in a way that matches `MallocLimitMode` enum values: enum class MallocLimitMode { trigger_fatal = 0, trigger_oom = 1 }; Could we do instead: void MallocLimitSet::print_on(outputStream* st) const { if (_glob.sz > 0) { st->print_cr("MallocLimit: total limit: " PROPERFMT " (%s)", PROPERFMTARGS(_glob.sz), MallocLimitSet::limit_name(_glob.mode)); } else { for (int i = 0; i < mt_number_of_types; i++) { if (_cat[i].sz > 0) { st->print_cr("MallocLimit: category "%s" limit: " PROPERFMT " (%s)", NMTUtil::flag_to_enum_name(NMTUtil::index_to_flag(i)), PROPERFMTARGS(_cat[i].sz), MallocLimitSet::limit_name(_cat[i].mode)); } } } } and add new API to `MallocLimitSet`: static const char* const limit_name(MallocLimitMode l) { return (l==MallocLimitMode::trigger_fatal)?"fatal":"oom"; } This way we also avoid the `(int)` casting from the `enum`. We could also potentially use `MallocLimitSet::limit_name()` in `match_mode_flag()` instead of hardcoding "oom" and "fatal" ------------- Changes requested by gziemski (Committer). PR: https://git.openjdk.org/jdk/pull/11371 From luhenry at openjdk.org Thu Jan 26 01:53:07 2023 From: luhenry at openjdk.org (Ludovic Henry) Date: Thu, 26 Jan 2023 01:53:07 GMT Subject: RFR: 8295382: Implement SHA-256 Intrinsic on RISC-V Message-ID: <1JWd-CDS_jpIDtfu7HJAVmvViShKzVTrCOxDVBZ9GSo=.904a8e56-794c-43d6-8448-de2a1a856f33@github.com> This has been tested with patches currently being submitted to QEMU to add support for Zvkb and Zvknha extensions. The documentation for the Vector Crypto extension's instructions is available at https://github.com/riscv/riscv-crypto/tree/master/doc/vector/insns ------------- Commit messages: - 8295382: Implement SHA-256 Intrinsic on RISC-V Changes: https://git.openjdk.org/jdk/pull/12208/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12208&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8295382 Stats: 536 lines in 5 files changed: 530 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/12208.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12208/head:pull/12208 PR: https://git.openjdk.org/jdk/pull/12208 From fyang at openjdk.org Thu Jan 26 03:37:46 2023 From: fyang at openjdk.org (Fei Yang) Date: Thu, 26 Jan 2023 03:37:46 GMT Subject: RFR: 8301036: RISC-V: Factor out functions baseOffset & baseOffset32 from MacroAssembler [v2] In-Reply-To: References: Message-ID: > The functions baseOffset & baseOffset32 from MacroAssembler on RISC-V receive an Address in base_plus_offset mode. They check the range of the offset, add it and base and put the result in a destination register. This duplicates function MacroAssembler::la in functionality. We could refactor this part putting the logic of Address legitimization into MacroAssembler::la and use this function instead. > > Testing: > - [x] Bootcycle (release & fastdebug) > - [x] Tier1-4 (release) > - [x] Benchmarks: SPECjbb2015 (release) Fei Yang 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: - Comment - Merge branch 'master' into JDK-8301036 - 8301036: RISC-V: Factor out functions baseOffset & baseOffset32 from MacroAssembler ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12177/files - new: https://git.openjdk.org/jdk/pull/12177/files/d1803d33..c617b7f8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12177&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12177&range=00-01 Stats: 9971 lines in 363 files changed: 3283 ins; 2129 del; 4559 mod Patch: https://git.openjdk.org/jdk/pull/12177.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12177/head:pull/12177 PR: https://git.openjdk.org/jdk/pull/12177 From fyang at openjdk.org Thu Jan 26 03:37:47 2023 From: fyang at openjdk.org (Fei Yang) Date: Thu, 26 Jan 2023 03:37:47 GMT Subject: RFR: 8301036: RISC-V: Factor out functions baseOffset & baseOffset32 from MacroAssembler [v2] In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 20:18:38 GMT, Ludovic Henry wrote: >> Fei Yang 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: >> >> - Comment >> - Merge branch 'master' into JDK-8301036 >> - 8301036: RISC-V: Factor out functions baseOffset & baseOffset32 from MacroAssembler > > src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 2394: > >> 2392: >> 2393: assert(Rd != noreg, "expecting a register"); >> 2394: guarantee(Rd != base, "should be different registers"); > > Why not `assert`? Fixed. These two lines come from the original MacroAssembler::baseOffset32. I think assert_different_registers will also do here. ------------- PR: https://git.openjdk.org/jdk/pull/12177 From fyang at openjdk.org Thu Jan 26 04:37:16 2023 From: fyang at openjdk.org (Fei Yang) Date: Thu, 26 Jan 2023 04:37:16 GMT Subject: RFR: 8295382: Implement SHA-256 Intrinsic on RISC-V In-Reply-To: <1JWd-CDS_jpIDtfu7HJAVmvViShKzVTrCOxDVBZ9GSo=.904a8e56-794c-43d6-8448-de2a1a856f33@github.com> References: <1JWd-CDS_jpIDtfu7HJAVmvViShKzVTrCOxDVBZ9GSo=.904a8e56-794c-43d6-8448-de2a1a856f33@github.com> Message-ID: On Thu, 26 Jan 2023 01:47:10 GMT, Ludovic Henry wrote: > This has been tested with patches currently being submitted to QEMU to add support for Zvkb and Zvknha extensions. > > The documentation for the Vector Crypto extension's instructions is available at https://github.com/riscv/riscv-crypto/tree/master/doc/vector/insns But looks like this extension is still in draft status? We should only consider using RISC-V extensions that are at least in the ratified status. Extensions in draft status are expected to change before ratification. ------------- PR: https://git.openjdk.org/jdk/pull/12208 From vkempik at openjdk.org Thu Jan 26 05:48:16 2023 From: vkempik at openjdk.org (Vladimir Kempik) Date: Thu, 26 Jan 2023 05:48:16 GMT Subject: RFR: 8295382: Implement SHA-256 Intrinsic on RISC-V In-Reply-To: References: <1JWd-CDS_jpIDtfu7HJAVmvViShKzVTrCOxDVBZ9GSo=.904a8e56-794c-43d6-8448-de2a1a856f33@github.com> Message-ID: <_x_E2nnxFN7Z2fZUu3-SABSZaJBnHvrk3D5tcKlrjBA=.ac4060b4-d475-4748-8e52-7905600ca024@github.com> On Thu, 26 Jan 2023 04:33:17 GMT, Fei Yang wrote: > But looks like this extension is still in draft status? We should only consider using RISC-V extensions that are at least in the ratified status. Extensions in draft status are expected to change before ratification. I agree with @RealFYang. This is good and needed patch, just a little too early. ------------- PR: https://git.openjdk.org/jdk/pull/12208 From thartmann at openjdk.org Thu Jan 26 07:02:33 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 26 Jan 2023 07:02:33 GMT Subject: Integrated: 8301063: Remove dead code from GrowableArray In-Reply-To: <3DLZGb6mDxMXam1-o-jdlIKkCCuicMfmz_dwVpuVBJs=.ff3f662f-939a-4155-8478-b758be6ba2f7@github.com> References: <3DLZGb6mDxMXam1-o-jdlIKkCCuicMfmz_dwVpuVBJs=.ff3f662f-939a-4155-8478-b758be6ba2f7@github.com> Message-ID: <7czSz3LTN93oZCfO32QXchJcLpVQnIFYydC6rXyyp-Q=.d2c76c69-e933-40bc-8d62-1f30a9d81548@github.com> On Wed, 25 Jan 2023 11:55:26 GMT, Tobias Hartmann wrote: > While looking for a method to truncate a GrowableArray, I noticed that there are both `trunc_to` and `truncate_to` while the behavior of the latter is confusing. Since it's unused, I propose to remove it (together with `data_size_in_bytes` which is also unused). The `truncate_to` and `truncate_from` methods were added by [JDK-8271515](https://bugs.openjdk.org/browse/JDK-8271515) and were unused right from the beginning. `data_size_in_bytes` was introduced by [JDK-8254231](https://bugs.openjdk.org/browse/JDK-8254231) and became unused after [JDK-8283689](https://bugs.openjdk.org/browse/JDK-8283689). > > Thanks, > Tobias This pull request has now been integrated. Changeset: 252621d4 Author: Tobias Hartmann URL: https://git.openjdk.org/jdk/commit/252621d4e0c656b160bf41cbf413fb7c7ee1daaf Stats: 15 lines in 1 file changed: 0 ins; 15 del; 0 mod 8301063: Remove dead code from GrowableArray Reviewed-by: chagedorn, kvn ------------- PR: https://git.openjdk.org/jdk/pull/12191 From stuefe at openjdk.org Thu Jan 26 07:33:49 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 26 Jan 2023 07:33:49 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v4] In-Reply-To: References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> <_khJTogN_LFzv_VSMdncQeFf9zyMDgWGaiPRTuuXVl0=.2dad11d6-cc4e-46de-ad11-7bb607e8900e@github.com> Message-ID: On Wed, 25 Jan 2023 17:35:43 GMT, Gerard Ziemski wrote: > The entire point of this effort is to catch elusive OOM errors. You even moved the check for the memory limits before we actually allocate the memory, from the current way where we check the limit only after we acquire new memory. > > Isn't assuming the worst case scenario, where realloc(), might allocate new memory first, in the same vein as that and we are just being cautious, to catch those hard to reproduce bugs? > > Basically we are saying that if the OS had to allocate new memory on top of the old one and doing so would exceed the limit we would like to know about it. Will it happen often? No? Will it happen during the lifetime of a memory intensive process? Most likely yes. > > These cases might not occur very often, granted, but why not catch them if we can? > > Aren't there any platforms where we run Java where realloc() is implemented in terms of malloc() and memcpy()? I think its just wrong. False positives are not helpful. 1) its semantically wrong. The malloc limit shall triggers when our global or category-specific malloc load exceeds a given threshold. Be it either the malloc that just happened (old version) or the malloc that we are about to do (new version). But I don't want the mechanism to second-guess what I'm telling it and proactively trigger alerts. Example: I set 10m as limit and have a 5MB buffer. Expanding this buffer to 5.5 MB should not trigger any alert. I don't want false positives, they are not helpful. 2) You try to predict an OOM kill caused by a malloc event, right? For that to work the prediction must be at least somewhat correct. But you only have very limited knowledge. Some examples: - The allocation request is fulfilled from cached memory. No new memory needed at all. The smaller the allocation the more likely this is, and if the libc uses sbrk exclusively, this is very likely. - The libc always has overhead per allocation. E.g. glibc, at the very least, ~40ish bytes. Should I account for this? With many fine-grained allocations this can have an enourmous impact. But overhead depends on a number of factors, and every libc is different. - The allocation request is large and the libc decides to mmap it (not all do). So we allocate in page granularity. Should I now adjust my prediction for page size? What page size? The libc may still reuse already mapped memory though. Or the underlying kernel vm may do that. - The realloc is done by a new thread, and the libc uses thread-specific memory pools. A new memory pool is created. Is this memory committed immediately (e.g. older glibcs) or committed on demand? Depending on the answer, we may see a large bump in RSS or none at all. Depends on libc and libc version. - The realloc is large and cannot be enlarged in place. But I could think of several ways of enlarging such an allocation out-of-place without needing memory * 2. If even I can think of those, libc devs probably do too. So, these examples show that an allocation may not move the needle at all or may move the needle much farther than you think. Trying to guess this just makes the code complex and causes false positives that are difficult to argue about. All without having any real benefit. ------------- PR: https://git.openjdk.org/jdk/pull/11371 From tschatzl at openjdk.org Thu Jan 26 09:01:29 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 26 Jan 2023 09:01:29 GMT Subject: RFR: 8301088: oopDesc::print_on should consistently use a trailing newline In-Reply-To: References: Message-ID: <-OYELefuGSs2_jy8wVbj0pEVeoIrelm5O6TgpouCSjw=.0ec8e91d-b3bb-4b8c-abce-21bec2ff8c77@github.com> On Wed, 25 Jan 2023 13:56:08 GMT, Axel Boldt-Christmas wrote: > [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161) added special printing when `oopDesc` contains `badHeapWordVal` or `badMetaWordVal`. However these two cases do not print a trailing newline. The previous behaviour was to always use a trailing newline. > > Propose making this consistent with `*klass::oop_print_on` and `InstanceStackChunkKlass::print_chunk`, that both uses a trailing newline. > > This new behaviour messes up some printing code, e.g. can be seen in print_location when printing hs_err files which assumes that it always prints a trailing newline. lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.org/jdk/pull/12195 From stefank at openjdk.org Thu Jan 26 09:41:31 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 26 Jan 2023 09:41:31 GMT Subject: RFR: JDK-8301070: Replace NULL with nullptr in share/memory/ In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 11:45:47 GMT, Johan Sj?len wrote: > Do the conversion in the share/memory/ sub-directory and all of its files. Marked as reviewed by stefank (Reviewer). src/hotspot/share/memory/guardedMemory.hpp line 196: > 194: */ > 195: void* wrap_with_guards(void* base_ptr, size_t user_size, const void* tag = nullptr) { > 196: assert(base_ptr != nullptr, "Attempt to wrap nullptr with memory guard"); wrap nullptr => wrap null? src/hotspot/share/memory/guardedMemory.hpp line 229: > 227: * Return the general purpose tag. > 228: * > 229: * @return the general purpose tag, defaults to nullptr. nullptr => null? src/hotspot/share/memory/guardedMemory.hpp line 306: > 304: * @param tag optional general purpose tag (see GuardedMemory::get_tag()) > 305: * > 306: * @return guarded wrapped memory pointer to the user area, or nullptr if OOM. nullptr => null? ------------- PR: https://git.openjdk.org/jdk/pull/12185 From stuefe at openjdk.org Thu Jan 26 09:55:49 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 26 Jan 2023 09:55:49 GMT Subject: RFR: JDK-8301070: Replace NULL with nullptr in share/memory/ In-Reply-To: References: Message-ID: <0aCQc0pJSXBfXOhQScn8rnaC_dlDZV_sGYbvILnhDvY=.f16bfcbe-dc56-448d-8de1-ead0f3322f77@github.com> On Wed, 25 Jan 2023 11:45:47 GMT, Johan Sj?len wrote: > Do the conversion in the share/memory/ sub-directory and all of its files. Metaspace changes are good. src/hotspot/share/memory/metaspace/blockTree.hpp line 228: > 226: DEBUG_ONLY(check_node(insertion_point);) > 227: if (n->_word_size == insertion_point->_word_size) { > 228: add_to_list(n, insertion_point); // parent stays null in this case. Small nit. Do we have a unified naming scheme for comments? "null" reads like a java null. I prefer keeping NULL in comments. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/12185 From xliu at openjdk.org Thu Jan 26 10:13:14 2023 From: xliu at openjdk.org (Xin Liu) Date: Thu, 26 Jan 2023 10:13:14 GMT Subject: RFR: 8301136: Improve unlink() and unlink_all() of ResourceHashtableBase Message-ID: 1. Apply the same idea of JDK-8300184 to unlink(). 2. Because ResourceHashtableBase doesn't support copy constructor and copy assignment, client of it has to purge all elements first. We would like provide a specialized version called 'unlink_all()'. We don't need to update each node's _next in this case. We only nullify all buckets. We also use unlink_all() in destructor. Despite this isn't the optimal code for a destructor, we reduce maintenance cost. ------------- Commit messages: - 8301136: Improve unlink() and unlink_all() of ResourceHashtableBase Changes: https://git.openjdk.org/jdk/pull/12213/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12213&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301136 Stats: 81 lines in 2 files changed: 67 ins; 10 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/12213.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12213/head:pull/12213 PR: https://git.openjdk.org/jdk/pull/12213 From lkorinth at openjdk.org Thu Jan 26 10:35:52 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 26 Jan 2023 10:35:52 GMT Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable [v10] In-Reply-To: <1mczFcGXMJ-easbrP5X6Lz4dFHhMWs0zIOSb1eHtfmw=.741c639d-232c-434e-b88d-9457de2c51ce@github.com> References: <1mczFcGXMJ-easbrP5X6Lz4dFHhMWs0zIOSb1eHtfmw=.741c639d-232c-434e-b88d-9457de2c51ce@github.com> Message-ID: <4IdDiJKmiJZOsNR_Z-3aSuuUZ3WvWfL7ryLgb6vXi6I=.24ea7577-a94f-4232-a3bf-c338a4158465@github.com> On Tue, 24 Jan 2023 21:59:44 GMT, Leo Korinth wrote: >> I am replacing the old hash table with ResourceHashtable. In the process I am also removing the redundant `_length` field. By removing the `_length` field, a lot of asserts can be removed as the length will trivially match the length of the underlying table. >> >> I would like to have feedback on the addition of `unlink_destruct(Function&& should_remove)`. I added it because I prefer to use a functor object that can be used by lambdas instead of an iterator object. However, I did add code to "destruct" resource objects when they are removed instead of just letting them be to reflect that we use `delete` on c-heap objects. Maybe I should remove this "improvement" and then maybe implement the function by calling the existing unlink? > > Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: > > - Merge branch '_master_jdk' into _8292170 > - include cleanups, test fix > - Remove the purge list and use the resizing of the resource hash > table. > > Add asserts ensuring that we do not mutatet a hash table while we > iterate over it. Renaming .*g1CodeCacheRemSet.?pp -> .*g1CodeRootSet.?pp > - code_roots_list_contains is now locked, but we have problems with add() during nmethods_do > - revert copyright year after changes > - add mem_size() method to resourceHash.hpp > - can not use contains in combination with add without a lock > - remove specialized hash > - inline g1CodeRootSetTable.hpp > - remove unused template > - ... and 3 more: https://git.openjdk.org/jdk/compare/b678e700...6e1832a2 Many thanks for the review work Ivan, Ioi and Coleen!!! ------------- PR: https://git.openjdk.org/jdk/pull/11675 From lkorinth at openjdk.org Thu Jan 26 10:35:52 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 26 Jan 2023 10:35:52 GMT Subject: Integrated: 8292170: Convert CodeRootSetTable to use ResourceHashtable In-Reply-To: References: Message-ID: On Wed, 14 Dec 2022 13:45:51 GMT, Leo Korinth wrote: > I am replacing the old hash table with ResourceHashtable. In the process I am also removing the redundant `_length` field. By removing the `_length` field, a lot of asserts can be removed as the length will trivially match the length of the underlying table. > > I would like to have feedback on the addition of `unlink_destruct(Function&& should_remove)`. I added it because I prefer to use a functor object that can be used by lambdas instead of an iterator object. However, I did add code to "destruct" resource objects when they are removed instead of just letting them be to reflect that we use `delete` on c-heap objects. Maybe I should remove this "improvement" and then maybe implement the function by calling the existing unlink? This pull request has now been integrated. Changeset: 30cb305d Author: Leo Korinth URL: https://git.openjdk.org/jdk/commit/30cb305dc1e717b6b7a1dc157638118ae913a61d Stats: 899 lines in 18 files changed: 301 ins; 585 del; 13 mod 8292170: Convert CodeRootSetTable to use ResourceHashtable Reviewed-by: coleenp, iwalulya, iklam ------------- PR: https://git.openjdk.org/jdk/pull/11675 From jsjolen at openjdk.org Thu Jan 26 10:51:52 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 26 Jan 2023 10:51:52 GMT Subject: Integrated: JDK-8301069: Replace NULL with nullptr in share/libadt/ In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 11:45:35 GMT, Johan Sj?len wrote: > Do the conversion in the share/libadt/ sub-directory and all of its files. This pull request has now been integrated. Changeset: b0376a5f Author: Johan Sj?len URL: https://git.openjdk.org/jdk/commit/b0376a5f4421fb58c0feeddfce2c2083314e400c Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod 8301069: Replace NULL with nullptr in share/libadt/ Reviewed-by: kvn ------------- PR: https://git.openjdk.org/jdk/pull/12184 From iwalulya at openjdk.org Thu Jan 26 11:07:36 2023 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 26 Jan 2023 11:07:36 GMT Subject: RFR: 8221785: Let possibly_parallel_threads_do cover the same threads as threads_do In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 15:26:50 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that makes `Threads::possibly_parallel_threads_do` iterate over the same set of threads as `threads_do` to have parity? I.e. over all java and non-java threads. > > Originally this CR has been created to make a new method that keeps iterating only over java threads and the VM thread, but it's a bit weird to have both variants as the overhead of the extra threads is negligible and otherwise just confusing. > > So I made `Threads::possibly_parallel_threads_do` iterate over all threads; all uses support that afaict, also all uses correctly change the claim token (mostly in the enclosing `StrongRootsScope`). > > This allows some minimally better hiding of the token mechanism. > > One other reason for not doing this in the first place (as in [JDK-8221102](https://bugs.openjdk.org/browse/JDK-8221102), or as discussed [here](https://mail.openjdk.org/pipermail/hotspot-dev/2019-April/037541.html)) has been the fear that there would be a problem with threads being created during iteration and the (common) call to 'Threads::assert_all_threads_claimed`. However all calls so far are during a safepoint, and none seem to create new threads. I suggest to defer looking at this problem when it is important. > > Moreover I need that functionality is required for (JDK-8211104)[https://bugs.openjdk.org/browse/JDK-8211104]. :) > > Testing: tier1-4, gha > > Thanks, > Thomas Lgtm! ------------- Marked as reviewed by iwalulya (Reviewer). PR: https://git.openjdk.org/jdk/pull/12201 From rkennke at openjdk.org Thu Jan 26 12:34:18 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 26 Jan 2023 12:34:18 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v5] In-Reply-To: References: Message-ID: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Renaissance > > > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 86 commits: - Merge branch 'master' into JDK-8291556-v2 - Revert UseFastLocking to default to off - Change log message inflate(locked) -> inflate(has_locker) - Properly set ZF on anon-check path; avoid some conditional branches - Use testb when testing for anon owner in fast-path - Merge branch 'master' into JDK-8291555-v2 - In x86_32 C2 fast_lock(), CAS thread directly, instead of CASing stack-pointer and then storing thread - x86 part of optimization to check for anon owner - Optimize the check-for-anon-owner fast-path - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2 - ... and 76 more: https://git.openjdk.org/jdk/compare/da80e7a4...784b361c ------------- Changes: https://git.openjdk.org/jdk/pull/10907/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=04 Stats: 1936 lines in 74 files changed: 1219 ins; 94 del; 623 mod Patch: https://git.openjdk.org/jdk/pull/10907.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10907/head:pull/10907 PR: https://git.openjdk.org/jdk/pull/10907 From coleenp at openjdk.org Thu Jan 26 12:57:18 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 26 Jan 2023 12:57:18 GMT Subject: RFR: 8301088: oopDesc::print_on should consistently use a trailing newline In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 13:56:08 GMT, Axel Boldt-Christmas wrote: > [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161) added special printing when `oopDesc` contains `badHeapWordVal` or `badMetaWordVal`. However these two cases do not print a trailing newline. The previous behaviour was to always use a trailing newline. > > Propose making this consistent with `*klass::oop_print_on` and `InstanceStackChunkKlass::print_chunk`, that both uses a trailing newline. > > This new behaviour messes up some printing code, e.g. can be seen in print_location when printing hs_err files which assumes that it always prints a trailing newline. Ok. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/12195 From rehn at openjdk.org Thu Jan 26 13:07:26 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 26 Jan 2023 13:07:26 GMT Subject: RFR: 8300913: ZGC: assert(to_addr != 0) failed: Should be forwarded In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 15:56:49 GMT, Coleen Phillimore wrote: > We thought we didn't need the keep-alive call but we do for heap walking. > Tested with failing test case locally, and tier1-4 in progress. Thanks! ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.org/jdk/pull/12202 From coleenp at openjdk.org Thu Jan 26 13:07:27 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 26 Jan 2023 13:07:27 GMT Subject: RFR: 8300913: ZGC: assert(to_addr != 0) failed: Should be forwarded In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 15:56:49 GMT, Coleen Phillimore wrote: > We thought we didn't need the keep-alive call but we do for heap walking. > Tested with failing test case locally, and tier1-4 in progress. Thanks Erik and Robbin! ------------- PR: https://git.openjdk.org/jdk/pull/12202 From coleenp at openjdk.org Thu Jan 26 13:07:28 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 26 Jan 2023 13:07:28 GMT Subject: Integrated: 8300913: ZGC: assert(to_addr != 0) failed: Should be forwarded In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 15:56:49 GMT, Coleen Phillimore wrote: > We thought we didn't need the keep-alive call but we do for heap walking. > Tested with failing test case locally, and tier1-4 in progress. This pull request has now been integrated. Changeset: 3f633814 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/3f6338146e9d4103ca427986d61af9c23c9651fd Stats: 14 lines in 2 files changed: 5 ins; 8 del; 1 mod 8300913: ZGC: assert(to_addr != 0) failed: Should be forwarded Reviewed-by: eosterlund, rehn ------------- PR: https://git.openjdk.org/jdk/pull/12202 From mbaesken at openjdk.org Thu Jan 26 13:30:07 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 26 Jan 2023 13:30:07 GMT Subject: RFR: JDK-8301050: Detect Xen Virtualization on Linux aarch64 Message-ID: <7EBbyNeCuZPMBzTN8MpQlHnCzJ2myxa5xQh2MfAEKmo=.0a4f74e2-7dd9-4b79-a78b-6bd66380534b@github.com> With https://bugs.openjdk.org/browse/JDK-8300266 KVM and VMWare virtualization detection has been added; this should be enhanced by Xen detection. However it seems that for Xen we should look at other file system locations compared to the other virtualizations. more /sys/hypervisor/type xen seems to be available there. ------------- Commit messages: - JDK-8301050 Changes: https://git.openjdk.org/jdk/pull/12217/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12217&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301050 Stats: 29 lines in 1 file changed: 17 ins; 6 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/12217.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12217/head:pull/12217 PR: https://git.openjdk.org/jdk/pull/12217 From coleenp at openjdk.org Thu Jan 26 13:30:56 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 26 Jan 2023 13:30:56 GMT Subject: RFR: 8301123: Enable Symbol refcounting underflow checks in PRODUCT Message-ID: Enabling refcounting underflow detection in product would have helped with debugging [JDK-8278965](https://bugs.openjdk.org/browse/JDK-8278965). We'd rather have this assert for customers than the subsequent memory corruption. Tested with tier1-4, 7, 8 with linux-x64 product. ------------- Commit messages: - 8301123: Enable Symbol refcounting underflow checks in PRODUCT Changes: https://git.openjdk.org/jdk/pull/12218/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12218&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301123 Stats: 14 lines in 2 files changed: 7 ins; 6 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12218.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12218/head:pull/12218 PR: https://git.openjdk.org/jdk/pull/12218 From rehn at openjdk.org Thu Jan 26 13:48:19 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 26 Jan 2023 13:48:19 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v4] In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 12:09:27 GMT, Roman Kennke wrote: > > I always change the flags in code for the reasons David state and I can't forget to add any flags. > > (Test batch is stilling running, no failures except MonitorInflationTest.java) > > Ok, right. > > I just re-ran tier1-3 with the flag changed in code, on aarch64 and x86_64 without regressions. Will run tier4 overnight. I did a bigger batch of testing, there were some ThreadMXBean failures with wrong state. I'll investigate, otherwise passed. ------------- PR: https://git.openjdk.org/jdk/pull/10907 From coleenp at openjdk.org Thu Jan 26 14:05:19 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 26 Jan 2023 14:05:19 GMT Subject: RFR: 8221785: Let possibly_parallel_threads_do cover the same threads as threads_do In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 15:26:50 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that makes `Threads::possibly_parallel_threads_do` iterate over the same set of threads as `threads_do` to have parity? I.e. over all java and non-java threads. > > Originally this CR has been created to make a new method that keeps iterating only over java threads and the VM thread, but it's a bit weird to have both variants as the overhead of the extra threads is negligible and otherwise just confusing. > > So I made `Threads::possibly_parallel_threads_do` iterate over all threads; all uses support that afaict, also all uses correctly change the claim token (mostly in the enclosing `StrongRootsScope`). > > This allows some minimally better hiding of the token mechanism. > > One other reason for not doing this in the first place (as in [JDK-8221102](https://bugs.openjdk.org/browse/JDK-8221102), or as discussed [here](https://mail.openjdk.org/pipermail/hotspot-dev/2019-April/037541.html)) has been the fear that there would be a problem with threads being created during iteration and the (common) call to 'Threads::assert_all_threads_claimed`. However all calls so far are during a safepoint, and none seem to create new threads. I suggest to defer looking at this problem when it is important. > > Moreover I need that functionality is required for (JDK-8211104)[https://bugs.openjdk.org/browse/JDK-8211104]. :) > > Testing: tier1-4, gha > > Thanks, > Thomas Thank you for picking this up. src/hotspot/share/runtime/threads.cpp line 267: > 265: if (current->claim_threads_do(is_par, claim_token)) { > 266: tc->do_thread(current); > 267: } If I understand correctly, if this is only OK in a safepoint, can you add the safepoint assert here? ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/12201 From jsjolen at openjdk.org Thu Jan 26 15:02:54 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 26 Jan 2023 15:02:54 GMT Subject: RFR: JDK-8301077: Replace NULL with nullptr in share/services/ [v2] In-Reply-To: References: Message-ID: <_X0IZpW-Kd8SmMSgkUR9XvwYxKuqer65A6i6GjCYhyM=.8c0fe68f-ca64-4acb-a80e-e043758f0c5b@github.com> > Do the conversion in the share/services/ sub-directory and all of its files. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: plummercj's fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12189/files - new: https://git.openjdk.org/jdk/pull/12189/files/d2b39efa..64eae876 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12189&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12189&range=00-01 Stats: 7 lines in 4 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/12189.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12189/head:pull/12189 PR: https://git.openjdk.org/jdk/pull/12189 From jsjolen at openjdk.org Thu Jan 26 15:02:57 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 26 Jan 2023 15:02:57 GMT Subject: RFR: JDK-8301077: Replace NULL with nullptr in share/services/ [v2] In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 18:30:00 GMT, Chris Plummer wrote: >> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: >> >> plummercj's fixes > > Changes requested by cjplummer (Reviewer). Thanks @plummercj , I've pushed your fixes. ------------- PR: https://git.openjdk.org/jdk/pull/12189 From jsjolen at openjdk.org Thu Jan 26 15:08:40 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 26 Jan 2023 15:08:40 GMT Subject: RFR: JDK-8301070: Replace NULL with nullptr in share/memory/ [v2] In-Reply-To: References: Message-ID: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/memory/. 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: Fix stefank's comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12185/files - new: https://git.openjdk.org/jdk/pull/12185/files/def9b5f3..1b09b9a7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12185&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12185&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12185.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12185/head:pull/12185 PR: https://git.openjdk.org/jdk/pull/12185 From jsjolen at openjdk.org Thu Jan 26 15:08:42 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 26 Jan 2023 15:08:42 GMT Subject: RFR: JDK-8301070: Replace NULL with nullptr in share/memory/ [v2] In-Reply-To: <0aCQc0pJSXBfXOhQScn8rnaC_dlDZV_sGYbvILnhDvY=.f16bfcbe-dc56-448d-8de1-ead0f3322f77@github.com> References: <0aCQc0pJSXBfXOhQScn8rnaC_dlDZV_sGYbvILnhDvY=.f16bfcbe-dc56-448d-8de1-ead0f3322f77@github.com> Message-ID: On Thu, 26 Jan 2023 09:48:06 GMT, Thomas Stuefe wrote: >Small nit. Do we have a unified naming scheme for comments? Yeah, I forgot to update the PR message with all of the info. If you check now you can see what's been decided upon. The discussions can be found in previous PRs, I can link to them if you're curious. >"null" reads like a java null. I prefer keeping NULL in comments. That's true, but this probably can be inferred from context which one is meant quite easily? I'd be more keen on explicitly saying that something is a Java null. ------------- PR: https://git.openjdk.org/jdk/pull/12185 From jsjolen at openjdk.org Thu Jan 26 15:08:42 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 26 Jan 2023 15:08:42 GMT Subject: RFR: JDK-8301070: Replace NULL with nullptr in share/memory/ [v2] In-Reply-To: References: <0aCQc0pJSXBfXOhQScn8rnaC_dlDZV_sGYbvILnhDvY=.f16bfcbe-dc56-448d-8de1-ead0f3322f77@github.com> Message-ID: On Thu, 26 Jan 2023 15:04:06 GMT, Johan Sj?len wrote: >> src/hotspot/share/memory/metaspace/blockTree.hpp line 228: >> >>> 226: DEBUG_ONLY(check_node(insertion_point);) >>> 227: if (n->_word_size == insertion_point->_word_size) { >>> 228: add_to_list(n, insertion_point); // parent stays null in this case. >> >> Small nit. Do we have a unified naming scheme for comments? >> >> "null" reads like a java null. I prefer keeping NULL in comments. > >>Small nit. Do we have a unified naming scheme for comments? > > Yeah, I forgot to update the PR message with all of the info. If you check now you can see what's been decided upon. The discussions can be found in previous PRs, I can link to them if you're curious. > >>"null" reads like a java null. I prefer keeping NULL in comments. > > That's true, but this probably can be inferred from context which one is meant quite easily? I'd be more keen on explicitly saying that something is a Java null. FWIW, from fixing these reviews I've never seen us referring to a Java null when we meant a C++ nullptr. ------------- PR: https://git.openjdk.org/jdk/pull/12185 From ayang at openjdk.org Thu Jan 26 15:15:11 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 26 Jan 2023 15:15:11 GMT Subject: RFR: 8301164: Remove unused ResourceStack class Message-ID: <80ICW8phtXGNC9-EOHnWC47wsKIAvVOFhI8zkysVhRA=.158a9b74-e0f6-475c-8b18-2c3b5938a23f@github.com> Trivial removing dead code. ------------- Commit messages: - trivial Changes: https://git.openjdk.org/jdk/pull/12221/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12221&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301164 Stats: 33 lines in 2 files changed: 0 ins; 33 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12221.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12221/head:pull/12221 PR: https://git.openjdk.org/jdk/pull/12221 From eosterlund at openjdk.org Thu Jan 26 15:18:20 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 26 Jan 2023 15:18:20 GMT Subject: RFR: 8300253: Introduce AArch64 nzcv accessors [v3] In-Reply-To: References: Message-ID: <5c369SKnfznd6Cp9jMLoWM6GRU1tX4i9oFpt-6krpwA=.1b787a53-6c9e-4e75-a983-c0c6f36fb985@github.com> On Mon, 23 Jan 2023 10:22:30 GMT, Erik ?sterlund wrote: >> Some code, such as verification code, might want to run without changing the state of the system. To do that, it's useful to be able to get and set the nzcv flags. This enhancement aims at adding accessors for that. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Fix test Any more takers? ------------- PR: https://git.openjdk.org/jdk/pull/12038 From dchuyko at openjdk.org Thu Jan 26 15:37:18 2023 From: dchuyko at openjdk.org (Dmitry Chuyko) Date: Thu, 26 Jan 2023 15:37:18 GMT Subject: RFR: 8300669: AArch64: Table based tails processing and wider stores for Arrays.fill() intrinsic Message-ID: This is a new AArch64 implementation of existing (1-4-byte element) stubs that are called in C2-compiled code for array fill patterns and Arrays.fill(). Main variant of existing algorithm: [Short arrays (< 8 bytes): fill by element and exit]; // ... [align base to 8 bytes]; // ... // fill_words head_len = (cnt & 14) / 2; switch (head_len) { do { cnt -= 16; stp; case 7: stp; case 6: stp; // ... case 1: stp; case 0: base += 8*16; } while (cnt); } [(over)write a tail < 8 bytes]; Even in good case, only 16-byte GPR (STP) stores are used, and there is a jump for every 8 stores. There is always extra work to be done for misaligned targets, which especially affects small to medium lengths. The new implementation generates fill implementation for every length up to a certain threshold (160-byte length). These implementations form a table where you jump when the remaining target length is suitable. For each table entry (target length), we can have no branches and use the most number of widest possible stores that best fit the detected CPU model. Currently it is SIMD STPQ for Neoverse N2 and GPR STP for the rest. The choice is made after benchmarking and is controlled by the new UseSIMDForArrayFill flag in AArch64. Main variant of the new algorithm (see mode detailed description in comments): [align data at 16 bytes]; while(cnt_bytes > 128) { [store 128 bytes]; cnt_bytes -= 128; } [store tail of 0..127 bytes]; Both existing and proposed implementations specifically handle zero fill case (see comments about ZVA). New implementation contains a path for very small arrays that can be cut to further improve more generic case (added to avoid regressions). The check added in https://bugs.openjdk.org/browse/JDK-8298720 in StubGenerator is removed as it is a stub code being generated. For the selected threshold, the increase in code size is within 8 KB. New test TestArraysFill is added to intrinsics jtreg tests. It calls optimized versions of 2-arg and 4-arg Arrays.fill() for different data types, lengths and patterns. The target data is checked to be filled with the required value, the surrounding data is checked to be intact. Existing test/micro/org/openjdk/bench/java/util/ArraysFill.java benchmark was used only initially. There are many cases and data lengths to cover. A modified version of the benchmark is attached [1] to the RFE, but not included in the change as it takes too long to complete all valuable variants. Resulting performance data are listed in the spreadsheet [2] attache to the RFE. Target processors were Graviton 3, Graviton 2, TaiShan, A72 and A53. Latest data from Altra is not included but the picture there was similar to Graviton 2 in all experiments. There is a range of target lengths with various enhancement numbers. Interesting lengths are within table implementation threshold and close to them (stepped), small lengths (all) and long lengths (1 point, they look similar). Over this voluntary selection: - No major regressions were found. - Geomean improvement: 11-33% - Median improvement: 10-48% Testing: tier1, tier2 and the new test on fastdebug aarch64 and x86. [1] https://bugs.openjdk.org/secure/attachment/102426/ArraysFill.java [2] https://bugs.openjdk.org/secure/attachment/102427/arrays-fill.ods ------------- Commit messages: - Table based arrays_fill stub implementation for aarch64 Changes: https://git.openjdk.org/jdk/pull/12222/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12222&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300669 Stats: 927 lines in 7 files changed: 725 ins; 144 del; 58 mod Patch: https://git.openjdk.org/jdk/pull/12222.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12222/head:pull/12222 PR: https://git.openjdk.org/jdk/pull/12222 From dchuyko at openjdk.org Thu Jan 26 15:40:49 2023 From: dchuyko at openjdk.org (Dmitry Chuyko) Date: Thu, 26 Jan 2023 15:40:49 GMT Subject: RFR: 8300669: AArch64: Table based tails processing and wider stores for Arrays.fill() intrinsic [v2] In-Reply-To: References: Message-ID: > This is a new AArch64 implementation of existing (1-4-byte element) stubs that are called in C2-compiled code for array fill patterns and Arrays.fill(). > > Main variant of existing algorithm: > > > [Short arrays (< 8 bytes): fill by element and exit]; > // ... > [align base to 8 bytes]; > // ... > // fill_words > head_len = (cnt & 14) / 2; > switch (head_len) { > do { > cnt -= 16; > stp; > case 7: > stp; > case 6: > stp; > // ... > case 1: > stp; > case 0: > base += 8*16; > } while (cnt); > } > [(over)write a tail < 8 bytes]; > > > Even in good case, only 16-byte GPR (STP) stores are used, and there is a jump for every 8 stores. There is always extra work to be done for misaligned targets, which especially affects small to medium lengths. > > The new implementation generates fill implementation for every length up to a certain threshold (160-byte length). These implementations form a table where you jump when the remaining target length is suitable. > > For each table entry (target length), we can have no branches and use the most number of widest possible stores that best fit the detected CPU model. Currently it is SIMD STPQ for Neoverse N2 and GPR STP for the rest. The choice is made after benchmarking and is controlled by the new UseSIMDForArrayFill flag in AArch64. > > Main variant of the new algorithm (see mode detailed description in comments): > > > [align data at 16 bytes]; > while(cnt_bytes > 128) { > [store 128 bytes]; > cnt_bytes -= 128; > } > [store tail of 0..127 bytes]; > > > > Both existing and proposed implementations specifically handle zero fill case (see comments about ZVA). New implementation contains a path for very small arrays that can be cut to further improve more generic case (added to avoid regressions). > > The check added in https://bugs.openjdk.org/browse/JDK-8298720 in StubGenerator is removed as it is a stub code being generated. For the selected threshold, the increase in code size is within 8 KB. > > New test TestArraysFill is added to intrinsics jtreg tests. It calls optimized versions of 2-arg and 4-arg Arrays.fill() for different data types, lengths and patterns. The target data is checked to be filled with the required value, the surrounding data is checked to be intact. > > Existing test/micro/org/openjdk/bench/java/util/ArraysFill.java benchmark was used only initially. There are many cases and data lengths to cover. A modified version of the benchmark is attached [1] to the RFE, but not included in the change as it takes too long to complete all valuable variants. > > Resulting performance data are listed in the spreadsheet [2] attache to the RFE. Target processors were Graviton 3, Graviton 2, TaiShan, A72 and A53. Latest data from Altra is not included but the picture there was similar to Graviton 2 in all experiments. There is a range of target lengths with various enhancement numbers. Interesting lengths are within table implementation threshold and close to them (stepped), small lengths (all) and long lengths (1 point, they look similar). Over this voluntary selection: > > - No major regressions were found. > - Geomean improvement: 11-33% > - Median improvement: 10-48% > > Testing: tier1, tier2 and the new test on fastdebug aarch64 and x86. > > [1] https://bugs.openjdk.org/secure/attachment/102426/ArraysFill.java > [2] https://bugs.openjdk.org/secure/attachment/102427/arrays-fill.ods Dmitry Chuyko has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8300669 - Table based arrays_fill stub implementation for aarch64 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12222/files - new: https://git.openjdk.org/jdk/pull/12222/files/c23d29e0..e7567f36 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12222&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12222&range=00-01 Stats: 40 lines in 2 files changed: 7 ins; 26 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/12222.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12222/head:pull/12222 PR: https://git.openjdk.org/jdk/pull/12222 From gziemski at openjdk.org Thu Jan 26 15:43:21 2023 From: gziemski at openjdk.org (Gerard Ziemski) Date: Thu, 26 Jan 2023 15:43:21 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v4] In-Reply-To: References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> <_khJTogN_LFzv_VSMdncQeFf9zyMDgWGaiPRTuuXVl0=.2dad11d6-cc4e-46de-ad11-7bb607e8900e@github.com> Message-ID: On Thu, 26 Jan 2023 07:31:01 GMT, Thomas Stuefe wrote: >> The entire point of this effort is to catch elusive OOM errors. You even moved the check for the memory limits before we actually allocate the memory, from the current way where we check the limit only after we acquire new memory. >> >> Isn't assuming the worst case scenario, where realloc(), might allocate new memory first, in the same vein as that and we are just being cautious, to catch those hard to reproduce bugs? >> >> Basically we are saying that if the OS had to allocate new memory on top of the old one and doing so would exceed the limit we would like to know about it. Will it happen often? No? Will it happen during the lifetime of a memory intensive process? Most likely yes. >> >> These cases might not occur very often, granted, but why not catch them if we can? >> >> Aren't there any platforms where we run Java where realloc() is implemented in terms of malloc() and memcpy()? > >> The entire point of this effort is to catch elusive OOM errors. You even moved the check for the memory limits before we actually allocate the memory, from the current way where we check the limit only after we acquire new memory. >> >> Isn't assuming the worst case scenario, where realloc(), might allocate new memory first, in the same vein as that and we are just being cautious, to catch those hard to reproduce bugs? >> >> Basically we are saying that if the OS had to allocate new memory on top of the old one and doing so would exceed the limit we would like to know about it. Will it happen often? No? Will it happen during the lifetime of a memory intensive process? Most likely yes. >> >> These cases might not occur very often, granted, but why not catch them if we can? >> >> Aren't there any platforms where we run Java where realloc() is implemented in terms of malloc() and memcpy()? > > I think its just wrong. False positives are not helpful. > > 1) its semantically wrong. The malloc limit shall triggers when our global or category-specific malloc load exceeds a given threshold. Be it either the malloc that just happened (old version) or the malloc that we are about to do (new version). But I don't want the mechanism to second-guess what I'm telling it and proactively trigger alerts. Example: I set 10m as limit and have a 5MB buffer. Expanding this buffer to 5.5 MB should not trigger any alert. I don't want false positives, they are not helpful. > > 2) You try to predict an OOM kill caused by a malloc event, right? For that to work the prediction must be at least somewhat correct. But you only have very limited knowledge. Some examples: > - The allocation request is fulfilled from cached memory. No new memory needed at all. The smaller the allocation the more likely this is, and if the libc uses sbrk exclusively, this is very likely. > - The libc always has overhead per allocation. E.g. glibc, at the very least, ~40ish bytes. Should I account for this? With many fine-grained allocations this can have an enourmous impact. But overhead depends on a number of factors, and every libc is different. > - The allocation request is large and the libc decides to mmap it (not all do). So we allocate in page granularity. Should I now adjust my prediction for page size? What page size? The libc may still reuse already mapped memory though. Or the underlying kernel vm may do that. > - The realloc is done by a new thread, and the libc uses thread-specific memory pools. A new memory pool is created. Is this memory committed immediately (e.g. older glibcs) or committed on demand? Depending on the answer, we may see a large bump in RSS or none at all. Depends on libc and libc version. > - The realloc is large and cannot be enlarged in place. But I could think of several ways of enlarging such an allocation out-of-place without needing memory * 2. If even I can think of those, libc devs probably do too. > > So, these examples show that an allocation may not move the needle at all or may move the needle much farther than you think. Trying to guess this just makes the code complex and causes false positives that are difficult to argue about. All without having any real benefit. Thank you for taking the time to explain. I'm worrying about those hard to pin mysterious issues that we have plenty of that possibly could be related to memory pressure, but I understand your point of view and will defer to you (even if there is a 5% of this that continues to bother me). ------------- PR: https://git.openjdk.org/jdk/pull/11371 From tschatzl at openjdk.org Thu Jan 26 15:43:51 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 26 Jan 2023 15:43:51 GMT Subject: RFR: 8221785: Let possibly_parallel_threads_do cover the same threads as threads_do [v2] In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 11:05:07 GMT, Ivan Walulya wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> coleenp review > > Lgtm! Thanks @walulyai @coleenp for your reviews ------------- PR: https://git.openjdk.org/jdk/pull/12201 From tschatzl at openjdk.org Thu Jan 26 15:43:54 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 26 Jan 2023 15:43:54 GMT Subject: Integrated: 8221785: Let possibly_parallel_threads_do cover the same threads as threads_do In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 15:26:50 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that makes `Threads::possibly_parallel_threads_do` iterate over the same set of threads as `threads_do` to have parity? I.e. over all java and non-java threads. > > Originally this CR has been created to make a new method that keeps iterating only over java threads and the VM thread, but it's a bit weird to have both variants as the overhead of the extra threads is negligible and otherwise just confusing. > > So I made `Threads::possibly_parallel_threads_do` iterate over all threads; all uses support that afaict, also all uses correctly change the claim token (mostly in the enclosing `StrongRootsScope`). > > This allows some minimally better hiding of the token mechanism. > > One other reason for not doing this in the first place (as in [JDK-8221102](https://bugs.openjdk.org/browse/JDK-8221102), or as discussed [here](https://mail.openjdk.org/pipermail/hotspot-dev/2019-April/037541.html)) has been the fear that there would be a problem with threads being created during iteration and the (common) call to 'Threads::assert_all_threads_claimed`. However all calls so far are during a safepoint, and none seem to create new threads. I suggest to defer looking at this problem when it is important. > > Moreover I need that functionality is required for (JDK-8211104)[https://bugs.openjdk.org/browse/JDK-8211104]. :) > > Testing: tier1-4, gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 315398c2 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/315398c2450e47d9cdb7fac944e35ba6a6aef221 Stats: 57 lines in 7 files changed: 18 ins; 8 del; 31 mod 8221785: Let possibly_parallel_threads_do cover the same threads as threads_do Reviewed-by: iwalulya, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/12201 From tschatzl at openjdk.org Thu Jan 26 15:43:53 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 26 Jan 2023 15:43:53 GMT Subject: RFR: 8221785: Let possibly_parallel_threads_do cover the same threads as threads_do [v2] In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 14:02:20 GMT, Coleen Phillimore wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> coleenp review > > src/hotspot/share/runtime/threads.cpp line 267: > >> 265: if (current->claim_threads_do(is_par, claim_token)) { >> 266: tc->do_thread(current); >> 267: } > > If I understand correctly, if this is only OK in a safepoint, can you add the safepoint assert here? Done. Another tier1-3 is almost done, also did local testing of Shenandoah tests to see whether there is any issue, none found. ------------- PR: https://git.openjdk.org/jdk/pull/12201 From tschatzl at openjdk.org Thu Jan 26 15:43:49 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 26 Jan 2023 15:43:49 GMT Subject: RFR: 8221785: Let possibly_parallel_threads_do cover the same threads as threads_do [v2] In-Reply-To: References: Message-ID: <2s6ZNHboTwZGUYl11kjjq14SZb0VIIRpiVXK17g_7tY=.c12f9676-60e5-4379-87f4-2de17d09f4ad@github.com> > Hi all, > > can I have reviews for this change that makes `Threads::possibly_parallel_threads_do` iterate over the same set of threads as `threads_do` to have parity? I.e. over all java and non-java threads. > > Originally this CR has been created to make a new method that keeps iterating only over java threads and the VM thread, but it's a bit weird to have both variants as the overhead of the extra threads is negligible and otherwise just confusing. > > So I made `Threads::possibly_parallel_threads_do` iterate over all threads; all uses support that afaict, also all uses correctly change the claim token (mostly in the enclosing `StrongRootsScope`). > > This allows some minimally better hiding of the token mechanism. > > One other reason for not doing this in the first place (as in [JDK-8221102](https://bugs.openjdk.org/browse/JDK-8221102), or as discussed [here](https://mail.openjdk.org/pipermail/hotspot-dev/2019-April/037541.html)) has been the fear that there would be a problem with threads being created during iteration and the (common) call to 'Threads::assert_all_threads_claimed`. However all calls so far are during a safepoint, and none seem to create new threads. I suggest to defer looking at this problem when it is important. > > Moreover I need that functionality is required for (JDK-8211104)[https://bugs.openjdk.org/browse/JDK-8211104]. :) > > Testing: tier1-4, gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: coleenp review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12201/files - new: https://git.openjdk.org/jdk/pull/12201/files/34e67f56..1d4458ff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12201&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12201&range=00-01 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12201.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12201/head:pull/12201 PR: https://git.openjdk.org/jdk/pull/12201 From luhenry at openjdk.org Thu Jan 26 15:56:17 2023 From: luhenry at openjdk.org (Ludovic Henry) Date: Thu, 26 Jan 2023 15:56:17 GMT Subject: RFR: 8295382: Implement SHA-256 Intrinsic on RISC-V In-Reply-To: <1JWd-CDS_jpIDtfu7HJAVmvViShKzVTrCOxDVBZ9GSo=.904a8e56-794c-43d6-8448-de2a1a856f33@github.com> References: <1JWd-CDS_jpIDtfu7HJAVmvViShKzVTrCOxDVBZ9GSo=.904a8e56-794c-43d6-8448-de2a1a856f33@github.com> Message-ID: On Thu, 26 Jan 2023 01:47:10 GMT, Ludovic Henry wrote: > This has been tested with patches currently being submitted to QEMU to add support for Zvkb and Zvknha extensions. > > The documentation for the Vector Crypto extension's instructions is available at https://github.com/riscv/riscv-crypto/tree/master/doc/vector/insns Agreed that it's still draft. It's getting really close to being ratified (the 45 days period was triggered between December and early January) and there is no expected changes. Happy to let this PR sit idle until it's fully ratified. I've prepared patches for SHA-512 as well, and currently working on AES instrinsics. Also, this is targeting vector crypto but not scalar crypto. We should support both given vector crypto is targeting larger machines. ------------- PR: https://git.openjdk.org/jdk/pull/12208 From eosterlund at openjdk.org Thu Jan 26 15:58:04 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 26 Jan 2023 15:58:04 GMT Subject: RFR: 8301047: Clean up type unsafe uses of oop from compiler code Message-ID: In an ideal world, when you have an oop, its contents should also be an oop. It happens, however, that we have other forms of pointers sometimes, used with the oop type, in some compiler code. We should clean that up. ------------- Commit messages: - 8301047: Clean up type unsafe uses of oop from compiler code Changes: https://git.openjdk.org/jdk/pull/12223/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12223&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301047 Stats: 19 lines in 5 files changed: 1 ins; 1 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/12223.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12223/head:pull/12223 PR: https://git.openjdk.org/jdk/pull/12223 From coleenp at openjdk.org Thu Jan 26 16:05:18 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 26 Jan 2023 16:05:18 GMT Subject: RFR: 8301164: Remove unused ResourceStack class In-Reply-To: <80ICW8phtXGNC9-EOHnWC47wsKIAvVOFhI8zkysVhRA=.158a9b74-e0f6-475c-8b18-2c3b5938a23f@github.com> References: <80ICW8phtXGNC9-EOHnWC47wsKIAvVOFhI8zkysVhRA=.158a9b74-e0f6-475c-8b18-2c3b5938a23f@github.com> Message-ID: <9QRSCcV_zENo_TFmb5HwaIvbTgFb_oD4N2mLLx7zsPk=.ece08da0-76c4-4220-a6af-ac60cf6194ba@github.com> On Thu, 26 Jan 2023 15:06:27 GMT, Albert Mingkun Yang wrote: > Trivial removing dead code. Looks good + trivial. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/12221 From jsjolen at openjdk.org Thu Jan 26 16:31:14 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 26 Jan 2023 16:31:14 GMT Subject: RFR: JDK-8301072: Replace NULL with nullptr in share/oops/ Message-ID: Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/oops/. 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! ------------- Commit messages: - FIX! - Manual fixes - Fix nullptr - Replace NULL with nullptr in share/oops/ Changes: https://git.openjdk.org/jdk/pull/12186/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12186&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301072 Stats: 1077 lines in 56 files changed: 0 ins; 0 del; 1077 mod Patch: https://git.openjdk.org/jdk/pull/12186.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12186/head:pull/12186 PR: https://git.openjdk.org/jdk/pull/12186 From jsjolen at openjdk.org Thu Jan 26 16:31:20 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 26 Jan 2023 16:31:20 GMT Subject: RFR: JDK-8301072: Replace NULL with nullptr in share/oops/ In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 11:46:23 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/oops/. 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! Found some manual fixes Passes tier1. src/hotspot/share/oops/annotations.cpp line 84: > 82: it->push(&_fields_annotations); > 83: it->push(&_class_type_annotations); > 84: it->push(&_fields_type_annotations); // FIXME: need a test case where _fields_type_annotations != null nullptr src/hotspot/share/oops/instanceKlass.cpp line 114: > 112: #define DTRACE_CLASSINIT_PROBE(type, thread_type) \ > 113: { \ > 114: char* data = nullptr; \ align src/hotspot/share/oops/method.cpp line 1617: > 1615: > 1616: vmSymbolID Method::klass_id_for_intrinsics(const Klass* holder) { > 1617: // if loader is not the default loader (i.e., != null), we can't know the intrinsics non-null ------------- PR: https://git.openjdk.org/jdk/pull/12186 From jsjolen at openjdk.org Thu Jan 26 16:31:23 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 26 Jan 2023 16:31:23 GMT Subject: RFR: JDK-8301076: Replace NULL with nullptr in share/prims/ In-Reply-To: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> References: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> Message-ID: <7AClZZSVSDx2-mMev-jjguFL3ARBT1UtXQGtKcBNs_I=.ddb55903-fb21-4f39-b888-45784cfc1159@github.com> On Wed, 25 Jan 2023 11:47:05 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/prims/. 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! Passes tier1. src/hotspot/share/prims/jni.cpp line 2234: > 2232: if (s_value != nullptr) { > 2233: size_t length = java_lang_String::utf8_length(java_string, s_value); > 2234: /* JNI Specification states return nullptr on OOM */ null src/hotspot/share/prims/jni.cpp line 2420: > 2418: *isCopy = JNI_FALSE; \ > 2419: } \ > 2420: /* Empty array: legal but useless, can't return nullptr. \ null src/hotspot/share/prims/jni.cpp line 2425: > 2423: result = (ElementType*)get_bad_address(); \ > 2424: } else { \ > 2425: /* JNI Specification states return nullptr on OOM */ \ null src/hotspot/share/prims/jni.cpp line 2839: > 2837: int s_len = java_lang_String::length(s, s_value); > 2838: ret = NEW_C_HEAP_ARRAY_RETURN_NULL(jchar, s_len + 1, mtInternal); // add one for zero termination > 2839: /* JNI Specification states return nullptr on OOM */ null src/hotspot/share/prims/jniCheck.cpp line 95: > 93: result_type JNICALL header { \ > 94: Thread* cur = Thread::current_or_null(); \ > 95: if (cur == nullptr || !cur->is_Java_thread()) { \ align src/hotspot/share/prims/jniCheck.cpp line 935: > 933: va_list args; \ > 934: IN_VM( \ > 935: jniCheck::validate_call(thr, nullptr, methodID, obj); \ align src/hotspot/share/prims/jniCheck.cpp line 953: > 951: functionEnter(thr); \ > 952: IN_VM(\ > 953: jniCheck::validate_call(thr, nullptr, methodID, obj); \ align src/hotspot/share/prims/jniCheck.cpp line 969: > 967: functionEnter(thr); \ > 968: IN_VM( \ > 969: jniCheck::validate_call(thr, nullptr, methodID, obj); \ align ------------- PR: https://git.openjdk.org/jdk/pull/12188 From jsjolen at openjdk.org Thu Jan 26 16:31:11 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 26 Jan 2023 16:31:11 GMT Subject: RFR: JDK-8301076: Replace NULL with nullptr in share/prims/ Message-ID: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/prims/. 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! ------------- Commit messages: - Fixes - nullptr_CHECK -> NULL_CHECK - Replace NULL with nullptr in share/prims/ Changes: https://git.openjdk.org/jdk/pull/12188/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12188&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301076 Stats: 2040 lines in 47 files changed: 0 ins; 0 del; 2040 mod Patch: https://git.openjdk.org/jdk/pull/12188.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12188/head:pull/12188 PR: https://git.openjdk.org/jdk/pull/12188 From jsjolen at openjdk.org Thu Jan 26 16:31:26 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 26 Jan 2023 16:31:26 GMT Subject: RFR: JDK-8301076: Replace NULL with nullptr in share/prims/ In-Reply-To: <7AClZZSVSDx2-mMev-jjguFL3ARBT1UtXQGtKcBNs_I=.ddb55903-fb21-4f39-b888-45784cfc1159@github.com> References: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> <7AClZZSVSDx2-mMev-jjguFL3ARBT1UtXQGtKcBNs_I=.ddb55903-fb21-4f39-b888-45784cfc1159@github.com> Message-ID: <1H7b0XMLwl92eWr13mS-7612t_VeVUHfBsL8o909cok=.1302aa16-4c65-43d2-ae75-baa45c32f0a5@github.com> On Thu, 26 Jan 2023 16:11:14 GMT, Johan Sj?len wrote: >> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/prims/. 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! > > src/hotspot/share/prims/jniCheck.cpp line 935: > >> 933: va_list args; \ >> 934: IN_VM( \ >> 935: jniCheck::validate_call(thr, nullptr, methodID, obj); \ > > align Not aligned from start, not fixing. > src/hotspot/share/prims/jniCheck.cpp line 953: > >> 951: functionEnter(thr); \ >> 952: IN_VM(\ >> 953: jniCheck::validate_call(thr, nullptr, methodID, obj); \ > > align Not aligned from start, not fixing. > src/hotspot/share/prims/jniCheck.cpp line 969: > >> 967: functionEnter(thr); \ >> 968: IN_VM( \ >> 969: jniCheck::validate_call(thr, nullptr, methodID, obj); \ > > align Not aligned from start, not fixing. ------------- PR: https://git.openjdk.org/jdk/pull/12188 From jsjolen at openjdk.org Thu Jan 26 16:33:32 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 26 Jan 2023 16:33:32 GMT Subject: Integrated: JDK-8301070: Replace NULL with nullptr in share/memory/ In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 11:45:47 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/memory/. 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: d98a323a Author: Johan Sj?len URL: https://git.openjdk.org/jdk/commit/d98a323a8b972c17a066c597a81b164681ad5589 Stats: 678 lines in 65 files changed: 0 ins; 0 del; 678 mod 8301070: Replace NULL with nullptr in share/memory/ Reviewed-by: stefank, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/12185 From dchuyko at openjdk.org Thu Jan 26 16:54:41 2023 From: dchuyko at openjdk.org (Dmitry Chuyko) Date: Thu, 26 Jan 2023 16:54:41 GMT Subject: RFR: 8300669: AArch64: Table based tails processing and wider stores for Arrays.fill() intrinsic [v3] In-Reply-To: References: Message-ID: > This is a new AArch64 implementation of existing (1-4-byte element) stubs that are called in C2-compiled code for array fill patterns and Arrays.fill(). > > Main variant of existing algorithm: > > > [Short arrays (< 8 bytes): fill by element and exit]; > // ... > [align base to 8 bytes]; > // ... > // fill_words > head_len = (cnt & 14) / 2; > switch (head_len) { > do { > cnt -= 16; > stp; > case 7: > stp; > case 6: > stp; > // ... > case 1: > stp; > case 0: > base += 8*16; > } while (cnt); > } > [(over)write a tail < 8 bytes]; > > > Even in good case, only 16-byte GPR (STP) stores are used, and there is a jump for every 8 stores. There is always extra work to be done for misaligned targets, which especially affects small to medium lengths. > > The new implementation generates fill implementation for every length up to a certain threshold (160-byte length). These implementations form a table where you jump when the remaining target length is suitable. > > For each table entry (target length), we can have no branches and use the most number of widest possible stores that best fit the detected CPU model. Currently it is SIMD STPQ for Neoverse N2 and GPR STP for the rest. The choice is made after benchmarking and is controlled by the new UseSIMDForArrayFill flag in AArch64. > > Main variant of the new algorithm (see mode detailed description in comments): > > > [align data at 16 bytes]; > while(cnt_bytes > 128) { > [store 128 bytes]; > cnt_bytes -= 128; > } > [store tail of 0..127 bytes]; > > > > Both existing and proposed implementations specifically handle zero fill case (see comments about ZVA). New implementation contains a path for very small arrays that can be cut to further improve more generic case (added to avoid regressions). > > The check added in https://bugs.openjdk.org/browse/JDK-8298720 in StubGenerator is removed as it is a stub code being generated. For the selected threshold, the increase in code size is within 8 KB. > > New test TestArraysFill is added to intrinsics jtreg tests. It calls optimized versions of 2-arg and 4-arg Arrays.fill() for different data types, lengths and patterns. The target data is checked to be filled with the required value, the surrounding data is checked to be intact. > > Existing test/micro/org/openjdk/bench/java/util/ArraysFill.java benchmark was used only initially. There are many cases and data lengths to cover. A modified version of the benchmark is attached [1] to the RFE, but not included in the change as it takes too long to complete all valuable variants. > > Resulting performance data are listed in the spreadsheet [2] attache to the RFE. Target processors were Graviton 3, Graviton 2, TaiShan, A72 and A53. Latest data from Altra is not included but the picture there was similar to Graviton 2 in all experiments. There is a range of target lengths with various enhancement numbers. Interesting lengths are within table implementation threshold and close to them (stepped), small lengths (all) and long lengths (1 point, they look similar). Over this voluntary selection: > > - No major regressions were found. > - Geomean improvement: 11-33% > - Median improvement: 10-48% > > Testing: tier1, tier2 and the new test on fastdebug aarch64 and x86. > > [1] https://bugs.openjdk.org/secure/attachment/102426/ArraysFill.java > [2] https://bugs.openjdk.org/secure/attachment/102427/arrays-fill.ods Dmitry Chuyko has updated the pull request incrementally with one additional commit since the last revision: Fixed compilation on win/mac ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12222/files - new: https://git.openjdk.org/jdk/pull/12222/files/e7567f36..680bede8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12222&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12222&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12222.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12222/head:pull/12222 PR: https://git.openjdk.org/jdk/pull/12222 From dchuyko at openjdk.org Thu Jan 26 16:59:44 2023 From: dchuyko at openjdk.org (Dmitry Chuyko) Date: Thu, 26 Jan 2023 16:59:44 GMT Subject: RFR: 8300669: AArch64: Table based tails processing and wider stores for Arrays.fill() intrinsic [v4] In-Reply-To: References: Message-ID: > This is a new AArch64 implementation of existing (1-4-byte element) stubs that are called in C2-compiled code for array fill patterns and Arrays.fill(). > > Main variant of existing algorithm: > > > [Short arrays (< 8 bytes): fill by element and exit]; > // ... > [align base to 8 bytes]; > // ... > // fill_words > head_len = (cnt & 14) / 2; > switch (head_len) { > do { > cnt -= 16; > stp; > case 7: > stp; > case 6: > stp; > // ... > case 1: > stp; > case 0: > base += 8*16; > } while (cnt); > } > [(over)write a tail < 8 bytes]; > > > Even in good case, only 16-byte GPR (STP) stores are used, and there is a jump for every 8 stores. There is always extra work to be done for misaligned targets, which especially affects small to medium lengths. > > The new implementation generates fill implementation for every length up to a certain threshold (160-byte length). These implementations form a table where you jump when the remaining target length is suitable. > > For each table entry (target length), we can have no branches and use the most number of widest possible stores that best fit the detected CPU model. Currently it is SIMD STPQ for Neoverse N2 and GPR STP for the rest. The choice is made after benchmarking and is controlled by the new UseSIMDForArrayFill flag in AArch64. > > Main variant of the new algorithm (see mode detailed description in comments): > > > [align data at 16 bytes]; > while(cnt_bytes > 128) { > [store 128 bytes]; > cnt_bytes -= 128; > } > [store tail of 0..127 bytes]; > > > > Both existing and proposed implementations specifically handle zero fill case (see comments about ZVA). New implementation contains a path for very small arrays that can be cut to further improve more generic case (added to avoid regressions). > > The check added in https://bugs.openjdk.org/browse/JDK-8298720 in StubGenerator is removed as it is a stub code being generated. For the selected threshold, the increase in code size is within 8 KB. > > New test TestArraysFill is added to intrinsics jtreg tests. It calls optimized versions of 2-arg and 4-arg Arrays.fill() for different data types, lengths and patterns. The target data is checked to be filled with the required value, the surrounding data is checked to be intact. > > Existing test/micro/org/openjdk/bench/java/util/ArraysFill.java benchmark was used only initially. There are many cases and data lengths to cover. A modified version of the benchmark is attached [1] to the RFE, but not included in the change as it takes too long to complete all valuable variants. > > Resulting performance data are listed in the spreadsheet [2] attache to the RFE. Target processors were Graviton 3, Graviton 2, TaiShan, A72 and A53. Latest data from Altra is not included but the picture there was similar to Graviton 2 in all experiments. There is a range of target lengths with various enhancement numbers. Interesting lengths are within table implementation threshold and close to them (stepped), small lengths (all) and long lengths (1 point, they look similar). Over this voluntary selection: > > - No major regressions were found. > - Geomean improvement: 11-33% > - Median improvement: 10-48% > > Testing: tier1, tier2 and the new test on fastdebug aarch64 and x86. > > [1] https://bugs.openjdk.org/secure/attachment/102426/ArraysFill.java > [2] https://bugs.openjdk.org/secure/attachment/102427/arrays-fill.ods Dmitry Chuyko has updated the pull request incrementally with one additional commit since the last revision: Wording about alignment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12222/files - new: https://git.openjdk.org/jdk/pull/12222/files/680bede8..9b8164e7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12222&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12222&range=02-03 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/12222.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12222/head:pull/12222 PR: https://git.openjdk.org/jdk/pull/12222 From dchuyko at openjdk.org Thu Jan 26 17:12:00 2023 From: dchuyko at openjdk.org (Dmitry Chuyko) Date: Thu, 26 Jan 2023 17:12:00 GMT Subject: RFR: 8300669: AArch64: Table based tails processing and wider stores for Arrays.fill() intrinsic [v5] In-Reply-To: References: Message-ID: > This is a new AArch64 implementation of existing (1-4-byte element) stubs that are called in C2-compiled code for array fill patterns and Arrays.fill(). > > Main variant of existing algorithm: > > > [Short arrays (< 8 bytes): fill by element and exit]; > // ... > [align base to 8 bytes]; > // ... > // fill_words > head_len = (cnt & 14) / 2; > switch (head_len) { > do { > cnt -= 16; > stp; > case 7: > stp; > case 6: > stp; > // ... > case 1: > stp; > case 0: > base += 8*16; > } while (cnt); > } > [(over)write a tail < 8 bytes]; > > > Even in good case, only 16-byte GPR (STP) stores are used, and there is a jump for every 8 stores. There is always extra work to be done for misaligned targets, which especially affects small to medium lengths. > > The new implementation generates fill implementation for every length up to a certain threshold (160-byte length). These implementations form a table where you jump when the remaining target length is suitable. > > For each table entry (target length), we can have no branches and use the most number of widest possible stores that best fit the detected CPU model. Currently it is SIMD STPQ for Neoverse N2 and GPR STP for the rest. The choice is made after benchmarking and is controlled by the new UseSIMDForArrayFill flag in AArch64. > > Main variant of the new algorithm (see mode detailed description in comments): > > > [align data at 16 bytes]; > while(cnt_bytes > 128) { > [store 128 bytes]; > cnt_bytes -= 128; > } > [store tail of 0..127 bytes]; > > > > Both existing and proposed implementations specifically handle zero fill case (see comments about ZVA). New implementation contains a path for very small arrays that can be cut to further improve more generic case (added to avoid regressions). > > The check added in https://bugs.openjdk.org/browse/JDK-8298720 in StubGenerator is removed as it is a stub code being generated. For the selected threshold, the increase in code size is within 8 KB. > > New test TestArraysFill is added to intrinsics jtreg tests. It calls optimized versions of 2-arg and 4-arg Arrays.fill() for different data types, lengths and patterns. The target data is checked to be filled with the required value, the surrounding data is checked to be intact. > > Existing test/micro/org/openjdk/bench/java/util/ArraysFill.java benchmark was used only initially. There are many cases and data lengths to cover. A modified version of the benchmark is attached [1] to the RFE, but not included in the change as it takes too long to complete all valuable variants. > > Resulting performance data are listed in the spreadsheet [2] attache to the RFE. Target processors were Graviton 3, Graviton 2, TaiShan, A72 and A53. Latest data from Altra is not included but the picture there was similar to Graviton 2 in all experiments. There is a range of target lengths with various enhancement numbers. Interesting lengths are within table implementation threshold and close to them (stepped), small lengths (all) and long lengths (1 point, they look similar). Over this voluntary selection: > > - No major regressions were found. > - Geomean improvement: 11-33% > - Median improvement: 10-48% > > Testing: tier1, tier2 and the new test on fastdebug aarch64 and x86. > > [1] https://bugs.openjdk.org/secure/attachment/102426/ArraysFill.java > [2] https://bugs.openjdk.org/secure/attachment/102427/arrays-fill.ods Dmitry Chuyko has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8300669 - Wording about alignment - Fixed compilation on win/mac - Merge branch 'openjdk:master' into JDK-8300669 - Table based arrays_fill stub implementation for aarch64 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12222/files - new: https://git.openjdk.org/jdk/pull/12222/files/9b8164e7..cac1f282 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12222&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12222&range=03-04 Stats: 735 lines in 72 files changed: 18 ins; 8 del; 709 mod Patch: https://git.openjdk.org/jdk/pull/12222.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12222/head:pull/12222 PR: https://git.openjdk.org/jdk/pull/12222 From xliu at openjdk.org Thu Jan 26 17:14:42 2023 From: xliu at openjdk.org (Xin Liu) Date: Thu, 26 Jan 2023 17:14:42 GMT Subject: RFR: 8301136: Improve unlink() and unlink_all() of ResourceHashtableBase [v2] In-Reply-To: References: Message-ID: > 1. Apply the same idea of JDK-8300184 to unlink(). > 2. Because ResourceHashtableBase doesn't support copy constructor and copy assignment, client of it has to purge all elements first. We would like provide a specialized version called 'unlink_all()'. > We don't need to update each node's _next in this case. We only nullify all buckets. We also use unlink_all() in destructor. Despite this isn't the optimal code for a destructor, we reduce maintenance cost. Xin Liu has updated the pull request incrementally with one additional commit since the last revision: Quit early if cnt is zero. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12213/files - new: https://git.openjdk.org/jdk/pull/12213/files/709a7c2c..749ee745 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12213&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12213&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12213.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12213/head:pull/12213 PR: https://git.openjdk.org/jdk/pull/12213 From luhenry at openjdk.org Thu Jan 26 17:19:21 2023 From: luhenry at openjdk.org (Ludovic Henry) Date: Thu, 26 Jan 2023 17:19:21 GMT Subject: RFR: 8301036: RISC-V: Factor out functions baseOffset & baseOffset32 from MacroAssembler [v2] In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 03:37:46 GMT, Fei Yang wrote: >> On RISC-V, functions baseOffset & baseOffset32 from MacroAssembler receive an Address in base_plus_offset mode. These two functions check the range of the offset, add it and base and put the result in a destination register. This duplicates function MacroAssembler::la in functionality. We could refactor this part moving the logic of Address legitimization into MacroAssembler::la and use this function instead. >> >> Testing: >> - [x] Bootcycle (release & fastdebug) >> - [x] Tier1-4 (release) >> - [x] Benchmarks: SPECjbb2015 (release) > > Fei Yang 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: > > - Comment > - Merge branch 'master' into JDK-8301036 > - 8301036: RISC-V: Factor out functions baseOffset & baseOffset32 from MacroAssembler Marked as reviewed by luhenry (Committer). src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 2394: > 2392: > 2393: assert(Rd != noreg, "expecting a register"); > 2394: assert_different_registers(Rd, base); You can also do `assert_different_registers(Rd, base, noreg);` to cut down on the checks, except if `base` can be a `noreg`. ------------- PR: https://git.openjdk.org/jdk/pull/12177 From iklam at openjdk.org Thu Jan 26 17:25:17 2023 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 26 Jan 2023 17:25:17 GMT Subject: RFR: 8301136: Improve unlink() and unlink_all() of ResourceHashtableBase [v2] In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 17:14:42 GMT, Xin Liu wrote: >> 1. Apply the same idea of JDK-8300184 to unlink(). >> 2. Because ResourceHashtableBase doesn't support copy constructor and copy assignment, client of it has to purge all elements first. We would like provide a specialized version called 'unlink_all()'. >> We don't need to update each node's _next in this case. We only nullify all buckets. We also use unlink_all() in destructor. Despite this isn't the optimal code for a destructor, we reduce maintenance cost. > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > Quit early if cnt is zero. Changes requested by iklam (Reviewer). src/hotspot/share/utilities/resourceHash.hpp line 282: > 280: > 281: while (_number_of_entries > 0 && bucket < bucket_at(sz)) { > 282: Node* node = *bucket; Instead of having two loops for unlinking, I would suggest using the same pattern as iterate/iterate_all so you can share the same loop for the different APIs. This will also allow you to use C++ Lambda for unlinking. ------------- PR: https://git.openjdk.org/jdk/pull/12213 From gziemski at openjdk.org Thu Jan 26 17:28:23 2023 From: gziemski at openjdk.org (Gerard Ziemski) Date: Thu, 26 Jan 2023 17:28:23 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v4] In-Reply-To: References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> <_khJTogN_LFzv_VSMdncQeFf9zyMDgWGaiPRTuuXVl0=.2dad11d6-cc4e-46de-ad11-7bb607e8900e@github.com> Message-ID: On Wed, 25 Jan 2023 06:24:31 GMT, Thomas Stuefe wrote: >> src/hotspot/share/runtime/globals.hpp line 1344: >> >>> 1342: "Number of exits until ZombieALot kicks in") \ >>> 1343: \ >>> 1344: product(ccstr, MallocLimit, nullptr, DIAGNOSTIC, \ >> >> Pre-existing, but I wish this flag was named `NMTMallocLimit`, not `MallocLimit`. > > I prefer MallocLimit, short and snappy. And the fact that NMT is supervising the limit is an implementation detail. It used to be different with MallocMaxTestWords and may be different in the future. Still, you named the test file `test/hotspot/gtest/nmt/test_nmt_malloclimit.cpp`, not `test/hotspot/gtest/nmt/test_malloclimit.cpp` :-) ------------- PR: https://git.openjdk.org/jdk/pull/11371 From dchuyko at openjdk.org Thu Jan 26 17:29:45 2023 From: dchuyko at openjdk.org (Dmitry Chuyko) Date: Thu, 26 Jan 2023 17:29:45 GMT Subject: RFR: 8300669: AArch64: Table based tails processing and wider stores for Arrays.fill() intrinsic [v6] In-Reply-To: References: Message-ID: > This is a new AArch64 implementation of existing (1-4-byte element) stubs that are called in C2-compiled code for array fill patterns and Arrays.fill(). > > Main variant of existing algorithm: > > > [Short arrays (< 8 bytes): fill by element and exit]; > // ... > [align base to 8 bytes]; > // ... > // fill_words > head_len = (cnt & 14) / 2; > switch (head_len) { > do { > cnt -= 16; > stp; > case 7: > stp; > case 6: > stp; > // ... > case 1: > stp; > case 0: > base += 8*16; > } while (cnt); > } > [(over)write a tail < 8 bytes]; > > > Even in good case, only 16-byte GPR (STP) stores are used, and there is a jump for every 8 stores. There is always extra work to be done for misaligned targets, which especially affects small to medium lengths. > > The new implementation generates fill implementation for every length up to a certain threshold (160-byte length). These implementations form a table where you jump when the remaining target length is suitable. > > For each table entry (target length), we can have no branches and use the most number of widest possible stores that best fit the detected CPU model. Currently it is SIMD STPQ for Neoverse N2 and GPR STP for the rest. The choice is made after benchmarking and is controlled by the new UseSIMDForArrayFill flag in AArch64. > > Main variant of the new algorithm (see mode detailed description in comments): > > > [align data at 16 bytes]; > while(cnt_bytes > 128) { > [store 128 bytes]; > cnt_bytes -= 128; > } > [store tail of 0..127 bytes]; > > > > Both existing and proposed implementations specifically handle zero fill case (see comments about ZVA). New implementation contains a path for very small arrays that can be cut to further improve more generic case (added to avoid regressions). > > The check added in https://bugs.openjdk.org/browse/JDK-8298720 in StubGenerator is removed as it is a stub code being generated. For the selected threshold, the increase in code size is within 8 KB. > > New test TestArraysFill is added to intrinsics jtreg tests. It calls optimized versions of 2-arg and 4-arg Arrays.fill() for different data types, lengths and patterns. The target data is checked to be filled with the required value, the surrounding data is checked to be intact. > > Existing test/micro/org/openjdk/bench/java/util/ArraysFill.java benchmark was used only initially. There are many cases and data lengths to cover. A modified version of the benchmark is attached [1] to the RFE, but not included in the change as it takes too long to complete all valuable variants. > > Resulting performance data are listed in the spreadsheet [2] attache to the RFE. Target processors were Graviton 3, Graviton 2, TaiShan, A72 and A53. Latest data from Altra is not included but the picture there was similar to Graviton 2 in all experiments. There is a range of target lengths with various enhancement numbers. Interesting lengths are within table implementation threshold and close to them (stepped), small lengths (all) and long lengths (1 point, they look similar). Over this voluntary selection: > > - No major regressions were found. > - Geomean improvement: 11-33% > - Median improvement: 10-48% > > Testing: tier1, tier2 and the new test on fastdebug aarch64 and x86. > > [1] https://bugs.openjdk.org/secure/attachment/102426/ArraysFill.java > [2] https://bugs.openjdk.org/secure/attachment/102427/arrays-fill.ods Dmitry Chuyko has updated the pull request incrementally with one additional commit since the last revision: Var in test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12222/files - new: https://git.openjdk.org/jdk/pull/12222/files/cac1f282..6e5ff006 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12222&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12222&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12222.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12222/head:pull/12222 PR: https://git.openjdk.org/jdk/pull/12222 From gziemski at openjdk.org Thu Jan 26 17:36:20 2023 From: gziemski at openjdk.org (Gerard Ziemski) Date: Thu, 26 Jan 2023 17:36:20 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v4] In-Reply-To: <_khJTogN_LFzv_VSMdncQeFf9zyMDgWGaiPRTuuXVl0=.2dad11d6-cc4e-46de-ad11-7bb607e8900e@github.com> References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> <_khJTogN_LFzv_VSMdncQeFf9zyMDgWGaiPRTuuXVl0=.2dad11d6-cc4e-46de-ad11-7bb607e8900e@github.com> Message-ID: <0gBM_DNhRfjJq_Yvj5YgNuffkOKp3xsMhD2DdTPcVlE=.8b249d12-de55-4396-8c4a-b14f5c4aea5d@github.com> On Tue, 24 Jan 2023 08:14:31 GMT, Thomas Stuefe wrote: >> Rework NMT `MallocLimit` to make it more useful for native OOM analysis. Also remove `MallocMaxTestWords`, which had been mostly redundant with NMT (for background, see JDK-8293292). >> >> >> ### Background >> >> Some months ago we had [JDK-8291919](https://bugs.openjdk.org/browse/JDK-8291919), a compiler regression that caused compiler arenas to grow boundlessly. Process was usually OOM-killed before we could take a look, so this was difficult to analyze. >> >> To improve analysis options, we added NMT *malloc limits* with [JDK-8291878](https://bugs.openjdk.org/browse/JDK-8291878). Malloc limits let us set one or multiple limits to malloc load. Surpassing a limit causes the VM to stop with a fatal error in the allocation function, giving us a hs-err file and a core right at the point that (probably) causes the leak. This makes error analysis a lot simpler, and is also valuable for regression-testing footprint usage. >> >> Some people wished for a way to not end with a fatal error but to mimic a native OOM (causing os::malloc to return NULL). This would allow us to test resilience in the face of native OOMs, among other things. >> >> ### Patch >> >> - Expands the `MallocLimit` option syntax, allowing for an "oom mode" that mimics an oom: >> >> >> >> Global form: >> -XX:MallocLimit=[:] >> Category-specific form: >> -XX:MallocLimit=:[:][,:[:] ...] >> Examples: >> -XX:MallocLimit=3g >> -XX:MallocLimit=3g:oom >> -XX:MallocLimit=compiler:200m:oom >> >> >> - moves parsing of `-XX:MallocLimit` out of arguments.cpp into `mallocLimit.hpp/cpp`, and rewrites it. >> >> - changes when limits are checked. Before, the limits were checked *after* the allocation that caused the threshold overflow. Now we check beforehand. >> >> - removes `MallocMaxTestWords`, replacing its uses with `MallocLimit` >> >> - adds new gtests and new jtreg tests >> >> - removes a bunch of jtreg tests which are now better served by the new gtests. >> >> - gives us more precise error messages upon reaching a limit. For example: >> >> before: >> >> # fatal error: MallocLimit: category "Compiler" reached limit (size: 20997680, limit: 20971520) >> >> >> now: >> >> # fatal error: MallocLimit: reached category "Compiler" limit (triggering allocation size: 1920B, allocated so far: 20505K, limit: 20480K) > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Revert strchrnul The rest looks good to me. This is a really nice feature, thank you for doing this! ------------- PR: https://git.openjdk.org/jdk/pull/11371 From aph at openjdk.org Thu Jan 26 17:50:19 2023 From: aph at openjdk.org (Andrew Haley) Date: Thu, 26 Jan 2023 17:50:19 GMT Subject: RFR: 8300253: Introduce AArch64 nzcv accessors [v3] In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 10:22:30 GMT, Erik ?sterlund wrote: >> Some code, such as verification code, might want to run without changing the state of the system. To do that, it's useful to be able to get and set the nzcv flags. This enhancement aims at adding accessors for that. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Fix test OK. ------------- Marked as reviewed by aph (Reviewer). PR: https://git.openjdk.org/jdk/pull/12038 From eosterlund at openjdk.org Thu Jan 26 17:55:19 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 26 Jan 2023 17:55:19 GMT Subject: RFR: 8300253: Introduce AArch64 nzcv accessors [v3] In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 17:47:23 GMT, Andrew Haley wrote: > OK. Thanks for the review! ------------- PR: https://git.openjdk.org/jdk/pull/12038 From aph at openjdk.org Thu Jan 26 18:16:20 2023 From: aph at openjdk.org (Andrew Haley) Date: Thu, 26 Jan 2023 18:16:20 GMT Subject: RFR: 8300669: AArch64: Table based tails processing and wider stores for Arrays.fill() intrinsic [v6] In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 17:29:45 GMT, Dmitry Chuyko wrote: >> This is a new AArch64 implementation of existing (1-4-byte element) stubs that are called in C2-compiled code for array fill patterns and Arrays.fill(). >> >> Main variant of existing algorithm: >> >> >> [Short arrays (< 8 bytes): fill by element and exit]; >> // ... >> [align base to 8 bytes]; >> // ... >> // fill_words >> head_len = (cnt & 14) / 2; >> switch (head_len) { >> do { >> cnt -= 16; >> stp; >> case 7: >> stp; >> case 6: >> stp; >> // ... >> case 1: >> stp; >> case 0: >> base += 8*16; >> } while (cnt); >> } >> [(over)write a tail < 8 bytes]; >> >> >> Even in good case, only 16-byte GPR (STP) stores are used, and there is a jump for every 8 stores. There is always extra work to be done for misaligned targets, which especially affects small to medium lengths. >> >> The new implementation generates fill implementation for every length up to a certain threshold (160-byte length). These implementations form a table where you jump when the remaining target length is suitable. >> >> For each table entry (target length), we can have no branches and use the most number of widest possible stores that best fit the detected CPU model. Currently it is SIMD STPQ for Neoverse N2 and GPR STP for the rest. The choice is made after benchmarking and is controlled by the new UseSIMDForArrayFill flag in AArch64. >> >> Main variant of the new algorithm (see mode detailed description in comments): >> >> >> [align data at 16 bytes]; >> while(cnt_bytes > 128) { >> [store 128 bytes]; >> cnt_bytes -= 128; >> } >> [store tail of 0..127 bytes]; >> >> >> >> Both existing and proposed implementations specifically handle zero fill case (see comments about ZVA). New implementation contains a path for very small arrays that can be cut to further improve more generic case (added to avoid regressions). >> >> The check added in https://bugs.openjdk.org/browse/JDK-8298720 in StubGenerator is removed as it is a stub code being generated. For the selected threshold, the increase in code size is within 8 KB. >> >> New test TestArraysFill is added to intrinsics jtreg tests. It calls optimized versions of 2-arg and 4-arg Arrays.fill() for different data types, lengths and patterns. The target data is checked to be filled with the required value, the surrounding data is checked to be intact. >> >> Existing test/micro/org/openjdk/bench/java/util/ArraysFill.java benchmark was used only initially. There are many cases and data lengths to cover. A modified version of the benchmark is attached [1] to the RFE, but not included in the change as it takes too long to complete all valuable variants. >> >> Resulting performance data are listed in the spreadsheet [2] attache to the RFE. Target processors were Graviton 3, Graviton 2, TaiShan, A72 and A53. Latest data from Altra is not included but the picture there was similar to Graviton 2 in all experiments. There is a range of target lengths with various enhancement numbers. Interesting lengths are within table implementation threshold and close to them (stepped), small lengths (all) and long lengths (1 point, they look similar). Over this voluntary selection: >> >> - No major regressions were found. >> - Geomean improvement: 11-33% >> - Median improvement: 10-48% >> >> Testing: tier1, tier2 and the new test on fastdebug aarch64 and x86. >> >> [1] https://bugs.openjdk.org/secure/attachment/102426/ArraysFill.java >> [2] https://bugs.openjdk.org/secure/attachment/102427/arrays-fill.ods > > Dmitry Chuyko has updated the pull request incrementally with one additional commit since the last revision: > > Var in test I don't think we should integrate this. It doesn't deliver enough to justify such a complicated change. The worst part of it is that, with separate code for each length of copy, we have something that looks good in benchmarks, but it occupies more instruction cache that could be used for other things. I would not be surprised if, when integrated into an application with high icache pressure, it didn't make things worse. Also, it's a lot of complicated code, with only a small gain even on a specially-designed benchmark. No. ------------- PR: https://git.openjdk.org/jdk/pull/12222 From kvn at openjdk.org Thu Jan 26 19:48:16 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 26 Jan 2023 19:48:16 GMT Subject: RFR: 8301047: Clean up type unsafe uses of oop from compiler code In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 15:45:06 GMT, Erik ?sterlund wrote: > In an ideal world, when you have an oop, its contents should also be an oop. It happens, however, that we have other forms of pointers sometimes, used with the oop type, in some compiler code. We should clean that up. Looks reasonable. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/12223 From eosterlund at openjdk.org Thu Jan 26 20:25:17 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 26 Jan 2023 20:25:17 GMT Subject: RFR: 8301047: Clean up type unsafe uses of oop from compiler code In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 19:45:31 GMT, Vladimir Kozlov wrote: >> In an ideal world, when you have an oop, its contents should also be an oop. It happens, however, that we have other forms of pointers sometimes, used with the oop type, in some compiler code. We should clean that up. > > Looks reasonable. Thanks for the review @vnkozlov! ------------- PR: https://git.openjdk.org/jdk/pull/12223 From xliu at openjdk.org Thu Jan 26 20:30:22 2023 From: xliu at openjdk.org (Xin Liu) Date: Thu, 26 Jan 2023 20:30:22 GMT Subject: RFR: 8301136: Improve unlink() and unlink_all() of ResourceHashtableBase [v2] In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 17:22:24 GMT, Ioi Lam wrote: >> Xin Liu has updated the pull request incrementally with one additional commit since the last revision: >> >> Quit early if cnt is zero. > > src/hotspot/share/utilities/resourceHash.hpp line 282: > >> 280: >> 281: while (_number_of_entries > 0 && bucket < bucket_at(sz)) { >> 282: Node* node = *bucket; > > Instead of having two loops for unlinking, I would suggest using the same pattern as iterate/iterate_all so you can share the same loop for the different APIs. This will also allow you to use C++ Lambda for unlinking. hi, Lam Are you suggesting to use lambda+iterate() to implement unlink_all()? If we use `bucket` and `node` captured by the lambda, I think it's possible. However, I think the resultant code is much less readable. Is it worth it? thanks, --lx ------------- PR: https://git.openjdk.org/jdk/pull/12213 From iklam at openjdk.org Thu Jan 26 20:54:17 2023 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 26 Jan 2023 20:54:17 GMT Subject: RFR: 8301136: Improve unlink() and unlink_all() of ResourceHashtableBase [v2] In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 20:27:28 GMT, Xin Liu wrote: >> src/hotspot/share/utilities/resourceHash.hpp line 282: >> >>> 280: >>> 281: while (_number_of_entries > 0 && bucket < bucket_at(sz)) { >>> 282: Node* node = *bucket; >> >> Instead of having two loops for unlinking, I would suggest using the same pattern as iterate/iterate_all so you can share the same loop for the different APIs. This will also allow you to use C++ Lambda for unlinking. > > hi, Lam > Are you suggesting to use lambda+iterate() to implement unlink_all()? If we use `bucket` and `node` captured by the lambda, I think it's possible. However, I think the resultant code is much less readable. Is it worth it? > > thanks, > --lx I mean we should implement a basic version of unlink() like this template void unlink(Function function) const { ... } Then `unlink_all` and `template void unlink(ITER* iter)` can call into the above template. ------------- PR: https://git.openjdk.org/jdk/pull/12213 From dcubed at openjdk.org Thu Jan 26 22:52:19 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 26 Jan 2023 22:52:19 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v5] In-Reply-To: References: Message-ID: <8rlBFtD2u34qhm_YUrdTR7mNcRDR2n7XVMRnUUFYUOA=.4ed35f18-e017-48ef-a2a2-9ead17595a11@github.com> On Thu, 26 Jan 2023 12:34:18 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Renaissance >> >> >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 86 commits: > > - Merge branch 'master' into JDK-8291556-v2 > - Revert UseFastLocking to default to off > - Change log message inflate(locked) -> inflate(has_locker) > - Properly set ZF on anon-check path; avoid some conditional branches > - Use testb when testing for anon owner in fast-path > - Merge branch 'master' into JDK-8291555-v2 > - In x86_32 C2 fast_lock(), CAS thread directly, instead of CASing stack-pointer and then storing thread > - x86 part of optimization to check for anon owner > - Optimize the check-for-anon-owner fast-path > - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2 > - ... and 76 more: https://git.openjdk.org/jdk/compare/da80e7a4...784b361c This PR is currently baselined on jdk-21+8-485. Now I get to see what happens to the comments that I'm in the process of making... :-) ------------- PR: https://git.openjdk.org/jdk/pull/10907 From cjplummer at openjdk.org Fri Jan 27 01:49:19 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 27 Jan 2023 01:49:19 GMT Subject: RFR: JDK-8301077: Replace NULL with nullptr in share/services/ [v2] In-Reply-To: <_X0IZpW-Kd8SmMSgkUR9XvwYxKuqer65A6i6GjCYhyM=.8c0fe68f-ca64-4acb-a80e-e043758f0c5b@github.com> References: <_X0IZpW-Kd8SmMSgkUR9XvwYxKuqer65A6i6GjCYhyM=.8c0fe68f-ca64-4acb-a80e-e043758f0c5b@github.com> Message-ID: On Thu, 26 Jan 2023 15:02:54 GMT, Johan Sj?len wrote: >> Do the conversion in the share/services/ sub-directory and all of its files. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > plummercj's fixes Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12189 From fyang at openjdk.org Fri Jan 27 02:11:26 2023 From: fyang at openjdk.org (Fei Yang) Date: Fri, 27 Jan 2023 02:11:26 GMT Subject: RFR: 8295382: Implement SHA-256 Intrinsic on RISC-V In-Reply-To: References: <1JWd-CDS_jpIDtfu7HJAVmvViShKzVTrCOxDVBZ9GSo=.904a8e56-794c-43d6-8448-de2a1a856f33@github.com> Message-ID: On Thu, 26 Jan 2023 15:53:13 GMT, Ludovic Henry wrote: >> This has been tested with patches currently being submitted to QEMU to add support for Zvkb and Zvknha extensions. >> >> The documentation for the Vector Crypto extension's instructions is available at https://github.com/riscv/riscv-crypto/tree/master/doc/vector/insns > > Agreed that it's still draft. It's getting really close to being ratified (the 45 days period was triggered between December and early January) and there is no expected changes. Happy to let this PR sit idle until it's fully ratified. > > I've prepared patches for SHA-512 as well, and currently working on AES instrinsics. > > Also, this is targeting vector crypto but not scalar crypto. We should support both given vector crypto is targeting larger machines. @luhenry : Hi, that's great to hear! I am happy to take another look once it's ratified. Also, thanks for sharing your work update! ------------- PR: https://git.openjdk.org/jdk/pull/12208 From dholmes at openjdk.org Fri Jan 27 02:31:17 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 27 Jan 2023 02:31:17 GMT Subject: RFR: JDK-8300783: Consolidate byteswap implementations [v11] In-Reply-To: <3uBeKIc_YXtM7PyyL1s8JOi-dQRpFGYEVNM1taKHtFI=.db1a5667-94f2-4456-867c-a0701b794210@github.com> References: <3uBeKIc_YXtM7PyyL1s8JOi-dQRpFGYEVNM1taKHtFI=.db1a5667-94f2-4456-867c-a0701b794210@github.com> Message-ID: On Wed, 25 Jan 2023 17:41:13 GMT, Justin King wrote: >> Deduplicate byte swapping implementations by consolidating them into `utilities/byteswap.hpp`, following `std::byteswap` introduced in C++23. Further simplification of `Bytes` will follow in https://github.com/openjdk/jdk/pull/12078. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Fix test > > Signed-off-by: Justin King test/hotspot/gtest/opto/test_moveBits.cpp line 42: > 40: ASSERT_EQ(reverse_bits((T)-1), (T)-1); > 41: ASSERT_EQ(byteswap((T)0), (T)0); > 42: ASSERT_EQ(byteswap((T)-1), (T)-1); This isn't testing moveBits any more so doesn't belong here. test/hotspot/gtest/opto/test_moveBits.cpp line 58: > 56: ASSERT_EQ((T)~reverse_bits((T)~mask), revm1|revm2) << STUFF; > 57: ASSERT_EQ(byteswap(mask), rbym1|rbym2) << STUFF; > 58: ASSERT_EQ((T)~byteswap((T)~mask), rbym1|rbym2) << STUFF; Ditto - doesn't belong here. ------------- PR: https://git.openjdk.org/jdk/pull/12114 From fyang at openjdk.org Fri Jan 27 02:38:59 2023 From: fyang at openjdk.org (Fei Yang) Date: Fri, 27 Jan 2023 02:38:59 GMT Subject: RFR: 8301036: RISC-V: Factor out functions baseOffset & baseOffset32 from MacroAssembler [v3] In-Reply-To: References: Message-ID: > On RISC-V, functions baseOffset & baseOffset32 from MacroAssembler receive an Address in base_plus_offset mode. These two functions check the range of the offset, add it and base and put the result in a destination register. This duplicates function MacroAssembler::la in functionality. We could refactor this part moving the logic of Address legitimization into MacroAssembler::la and use this function instead. > > Testing: > - [x] Bootcycle (release & fastdebug) > - [x] Tier1-4 (release) > - [x] Benchmarks: SPECjbb2015 (release) Fei Yang 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: - Fix - Merge branch 'master' into JDK-8301036 - Comment - Merge branch 'master' into JDK-8301036 - 8301036: RISC-V: Factor out functions baseOffset & baseOffset32 from MacroAssembler ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12177/files - new: https://git.openjdk.org/jdk/pull/12177/files/c617b7f8..ff5de19c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12177&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12177&range=01-02 Stats: 3512 lines in 160 files changed: 1209 ins; 1045 del; 1258 mod Patch: https://git.openjdk.org/jdk/pull/12177.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12177/head:pull/12177 PR: https://git.openjdk.org/jdk/pull/12177 From fjiang at openjdk.org Fri Jan 27 03:34:20 2023 From: fjiang at openjdk.org (Feilong Jiang) Date: Fri, 27 Jan 2023 03:34:20 GMT Subject: RFR: 8301036: RISC-V: Factor out functions baseOffset & baseOffset32 from MacroAssembler [v3] In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 02:38:59 GMT, Fei Yang wrote: >> On RISC-V, functions baseOffset & baseOffset32 from MacroAssembler receive an Address in base_plus_offset mode. These two functions check the range of the offset, add it and base and put the result in a destination register. This duplicates function MacroAssembler::la in functionality. We could refactor this part moving the logic of Address legitimization into MacroAssembler::la and use this function instead. >> >> Testing: >> - [x] Bootcycle (release & fastdebug) >> - [x] Tier1-4 (release) >> - [x] Benchmarks: SPECjbb2015 (release) > > Fei Yang 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: > > - Fix > - Merge branch 'master' into JDK-8301036 > - Comment > - Merge branch 'master' into JDK-8301036 > - 8301036: RISC-V: Factor out functions baseOffset & baseOffset32 from MacroAssembler Marked as reviewed by fjiang (Author). ------------- PR: https://git.openjdk.org/jdk/pull/12177 From lmesnik at openjdk.org Fri Jan 27 05:12:53 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 27 Jan 2023 05:12:53 GMT Subject: RFR: 8298979: Remove duplicated serviceability/jvmti/thread/GetAllThreads/allthr01/allthr01.java Message-ID: <7N18GctUO6Kt5_VJe5lJBV-ga-jZv-z9vtnh99dKHZo=.390887cd-5af8-4a61-bd2c-b4b5f74353e8@github.com> PR adds fix "8284027: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/ is failing" to new test and remove duplication. ------------- Commit messages: - cp - fix Changes: https://git.openjdk.org/jdk/pull/12240/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12240&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298979 Stats: 856 lines in 11 files changed: 45 ins; 782 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/12240.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12240/head:pull/12240 PR: https://git.openjdk.org/jdk/pull/12240 From lmesnik at openjdk.org Fri Jan 27 05:20:28 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 27 Jan 2023 05:20:28 GMT Subject: RFR: 8298979: Remove duplicated serviceability/jvmti/thread/GetAllThreads/allthr01/allthr01.java [v2] In-Reply-To: <7N18GctUO6Kt5_VJe5lJBV-ga-jZv-z9vtnh99dKHZo=.390887cd-5af8-4a61-bd2c-b4b5f74353e8@github.com> References: <7N18GctUO6Kt5_VJe5lJBV-ga-jZv-z9vtnh99dKHZo=.390887cd-5af8-4a61-bd2c-b4b5f74353e8@github.com> Message-ID: > PR adds fix "8284027: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/ is failing" to new test and remove duplication. Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: - cleanup - used get_thread_name ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12240/files - new: https://git.openjdk.org/jdk/pull/12240/files/661a6082..01479d0d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12240&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12240&range=00-01 Stats: 26 lines in 1 file changed: 1 ins; 15 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/12240.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12240/head:pull/12240 PR: https://git.openjdk.org/jdk/pull/12240 From stuefe at openjdk.org Fri Jan 27 06:15:21 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 27 Jan 2023 06:15:21 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v4] In-Reply-To: References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> <_khJTogN_LFzv_VSMdncQeFf9zyMDgWGaiPRTuuXVl0=.2dad11d6-cc4e-46de-ad11-7bb607e8900e@github.com> Message-ID: On Thu, 26 Jan 2023 15:40:39 GMT, Gerard Ziemski wrote: >>> The entire point of this effort is to catch elusive OOM errors. You even moved the check for the memory limits before we actually allocate the memory, from the current way where we check the limit only after we acquire new memory. >>> >>> Isn't assuming the worst case scenario, where realloc(), might allocate new memory first, in the same vein as that and we are just being cautious, to catch those hard to reproduce bugs? >>> >>> Basically we are saying that if the OS had to allocate new memory on top of the old one and doing so would exceed the limit we would like to know about it. Will it happen often? No? Will it happen during the lifetime of a memory intensive process? Most likely yes. >>> >>> These cases might not occur very often, granted, but why not catch them if we can? >>> >>> Aren't there any platforms where we run Java where realloc() is implemented in terms of malloc() and memcpy()? >> >> I think its just wrong. False positives are not helpful. >> >> 1) its semantically wrong. The malloc limit shall triggers when our global or category-specific malloc load exceeds a given threshold. Be it either the malloc that just happened (old version) or the malloc that we are about to do (new version). But I don't want the mechanism to second-guess what I'm telling it and proactively trigger alerts. Example: I set 10m as limit and have a 5MB buffer. Expanding this buffer to 5.5 MB should not trigger any alert. I don't want false positives, they are not helpful. >> >> 2) You try to predict an OOM kill caused by a malloc event, right? For that to work the prediction must be at least somewhat correct. But you only have very limited knowledge. Some examples: >> - The allocation request is fulfilled from cached memory. No new memory needed at all. The smaller the allocation the more likely this is, and if the libc uses sbrk exclusively, this is very likely. >> - The libc always has overhead per allocation. E.g. glibc, at the very least, ~40ish bytes. Should I account for this? With many fine-grained allocations this can have an enourmous impact. But overhead depends on a number of factors, and every libc is different. >> - The allocation request is large and the libc decides to mmap it (not all do). So we allocate in page granularity. Should I now adjust my prediction for page size? What page size? The libc may still reuse already mapped memory though. Or the underlying kernel vm may do that. >> - The realloc is done by a new thread, and the libc uses thread-specific memory pools. A new memory pool is created. Is this memory committed immediately (e.g. older glibcs) or committed on demand? Depending on the answer, we may see a large bump in RSS or none at all. Depends on libc and libc version. >> - The realloc is large and cannot be enlarged in place. But I could think of several ways of enlarging such an allocation out-of-place without needing memory * 2. If even I can think of those, libc devs probably do too. >> >> So, these examples show that an allocation may not move the needle at all or may move the needle much farther than you think. Trying to guess this just makes the code complex and causes false positives that are difficult to argue about. All without having any real benefit. > > Thank you for taking the time to explain. > > I'm worrying about those hard to pin mysterious issues that we have plenty of that possibly could be related to memory pressure, but I understand your point of view and will defer to you (even if there is a 5% of this that continues to bother me). I understand. This is not the tool to solve all that, but it can help. There are other tools. At SAP, we added something called "High Memory Reports", the ability to automatically generate customizable reports when certain memory thresholds are reached [1]. In addition to that, we have our SapMachine Vitals [2], which are awesome - basically like a little inbuilt pidstat but with a lot more information. For instance, it tells you the history of c-heap allocations (both from the JVM view and from the libc's view). Would love to see this in OpenJDK, but have zero hopes of doing so - tried to get the Vitals in years ago but hit a wall of resistance from JFR people. [1] https://github.com/SAP/SapMachine/wiki/SapMachine-High-Memory-Reports [2] https://github.com/SAP/SapMachine/wiki/SapMachine-Vitals ------------- PR: https://git.openjdk.org/jdk/pull/11371 From stuefe at openjdk.org Fri Jan 27 06:20:19 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 27 Jan 2023 06:20:19 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v4] In-Reply-To: References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> <_khJTogN_LFzv_VSMdncQeFf9zyMDgWGaiPRTuuXVl0=.2dad11d6-cc4e-46de-ad11-7bb607e8900e@github.com> Message-ID: On Thu, 26 Jan 2023 17:25:26 GMT, Gerard Ziemski wrote: >> I prefer MallocLimit, short and snappy. And the fact that NMT is supervising the limit is an implementation detail. It used to be different with MallocMaxTestWords and may be different in the future. > > Still, you named the test file `test/hotspot/gtest/nmt/test_nmt_malloclimit.cpp`, not `test/hotspot/gtest/nmt/test_malloclimit.cpp` :-) I'm not perfect :-) honestly, I just like short, easy to remember and to talk about command line names. I dislike the JVM tradition of long camel-cased names a bit. >>> Why did we bother to wrap `VMError::is_error_reported()` into `suppress_limit_handling()`? >>> >> >> Because during error handling, code may malloc() too (bad practice, but it can happen). If it does, I don't want circular assertions to fire; I want a clean, complete hs-err file. >> >>> Are you anticipating more exclusions here in the future? >> >> None I can think of. > > That explains why we want to call `VMError::is_error_reported()` sure, but not why we wrapped it in `suppress_limit_handling()` SPI, unless I am missing something? Oh okay. This was mostly a documentation thing. I can remove the wrapper. ------------- PR: https://git.openjdk.org/jdk/pull/11371 From stuefe at openjdk.org Fri Jan 27 06:29:20 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 27 Jan 2023 06:29:20 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v4] In-Reply-To: References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> <_khJTogN_LFzv_VSMdncQeFf9zyMDgWGaiPRTuuXVl0=.2dad11d6-cc4e-46de-ad11-7bb607e8900e@github.com> Message-ID: On Wed, 25 Jan 2023 17:41:41 GMT, Gerard Ziemski wrote: >>> I would prefer to see `suppress_limit_handling()` checked inside `total_limit_reached()`, same for `category_limit_reached()`. This way we would force those APIs to always obey the suppression without having to bother to add `suppress_limit_handling()`, they could call `VMError::is_error_reported()` directly. >> >> Note that `total_limit_reached()` and `category_limit_reached()` are private APIs. >> >> If we move `suppress_limit_handling()` into `total_limit_reached()`, `total_limit_reached()` would need to report it back to `MallocMemorySummary::check_exceeds_limit` since its processed there too, it affects the return code. So `total_limit_reached()` cannot be void anymore, and gets somewhat more complex. I prefer it this way, tbh. > > I'm not following. > > If we get rid of `suppress_limit_handling()` SPI, and do: > > > bool MallocMemorySummary::total_limit_reached(size_t s, size_t so_far, const malloclimit* limit) { > if (VMError::is_error_reported()) { > return false; > } > > #define FORMATTED \ > "MallocLimit: reached global limit (triggering allocation size: " PROPERFMT ", allocated so far: " PROPERFMT ", limit: " PROPERFMT ") ", \ > PROPERFMTARGS(s), PROPERFMTARGS(so_far), PROPERFMTARGS(limit->sz) > > if (limit->mode == MallocLimitMode::trigger_fatal) { > fatal(FORMATTED); > } else { > log_warning(nmt)(FORMATTED); > } > > #undef FORMATTED > > return true; > } > > bool MallocMemorySummary::category_limit_reached(MEMFLAGS f, size_t s, size_t so_far, const malloclimit* limit) { > if (VMError::is_error_reported()) { > return false; > } > > #define FORMATTED \ > "MallocLimit: reached category "%s" limit (triggering allocation size: " PROPERFMT ", allocated so far: " PROPERFMT ", limit: " PROPERFMT ") ", \ > NMTUtil::flag_to_enum_name(f), PROPERFMTARGS(s), PROPERFMTARGS(so_far), PROPERFMTARGS(limit->sz) > > if (limit->mode == MallocLimitMode::trigger_fatal) { > fatal(FORMATTED); > } else { > log_warning(nmt)(FORMATTED); > } > > #undef FORMATTED > > return true; > } > > > > then we can simply have: > > > // Returns true if allocating s bytes on f would trigger either global or the category limit > inline bool MallocMemorySummary::check_exceeds_limit(size_t s, MEMFLAGS f) { > > // Note: checks are ordered to have as little impact as possible on the standard code path, > // when MallocLimit is unset, resp. it is set but we have reached no limit yet. > // Somewhat expensive are: > // - as_snapshot()->total(), total malloc load (requires iteration over arena types) > // - VMError::is_error_reported() is a load from a volatile. > if (MallocLimitHandler::have_limit()) { > > // Global Limit ? > const malloclimit* l = MallocLimitHandler::global_limit(); > if (l->sz > 0) { > size_t so_far = as_snapshot()->total(); > if ((so_far + s) > l->sz) { // hit the limit > if (total_limit_reached(s, so_far, l)) { > return true; > } > } > } else { > // Category Limit ? > l = MallocLimitHandler::category_limit(f); > if (l->sz > 0) { > const MallocMemory* mm = as_snapshot()->by_type(f); > size_t so_far = mm->malloc_size() + mm->arena_size(); > if ((so_far + s) > l->sz) { > if (category_limit_reached(f, s, so_far, l)) { > return true; > } > } > } > } > } > > return false; > } > > > > Doesn't that work? Yes, you are right, its better. Can remove vmError.hpp dependency from the header too. ------------- PR: https://git.openjdk.org/jdk/pull/11371 From xliu at openjdk.org Fri Jan 27 07:02:30 2023 From: xliu at openjdk.org (Xin Liu) Date: Fri, 27 Jan 2023 07:02:30 GMT Subject: RFR: 8301136: Improve unlink() and unlink_all() of ResourceHashtableBase [v3] In-Reply-To: References: Message-ID: > 1. Apply the same idea of JDK-8300184 to unlink(). > 2. Because ResourceHashtableBase doesn't support copy constructor and copy assignment, client of it has to purge all elements first. We would like provide a specialized version called 'unlink_all()'. > We don't need to update each node's _next in this case. We only nullify all buckets. We also use unlink_all() in destructor. Despite this isn't the optimal code for a destructor, we reduce maintenance cost. Xin Liu has updated the pull request incrementally with one additional commit since the last revision: Add a template for unlink(), unlink_all() and dtor. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12213/files - new: https://git.openjdk.org/jdk/pull/12213/files/749ee745..2fa173c4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12213&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12213&range=01-02 Stats: 82 lines in 1 file changed: 38 ins; 32 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/12213.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12213/head:pull/12213 PR: https://git.openjdk.org/jdk/pull/12213 From stuefe at openjdk.org Fri Jan 27 07:07:28 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 27 Jan 2023 07:07:28 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v5] In-Reply-To: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> Message-ID: > Rework NMT `MallocLimit` to make it more useful for native OOM analysis. Also remove `MallocMaxTestWords`, which had been mostly redundant with NMT (for background, see JDK-8293292). > > > ### Background > > Some months ago we had [JDK-8291919](https://bugs.openjdk.org/browse/JDK-8291919), a compiler regression that caused compiler arenas to grow boundlessly. Process was usually OOM-killed before we could take a look, so this was difficult to analyze. > > To improve analysis options, we added NMT *malloc limits* with [JDK-8291878](https://bugs.openjdk.org/browse/JDK-8291878). Malloc limits let us set one or multiple limits to malloc load. Surpassing a limit causes the VM to stop with a fatal error in the allocation function, giving us a hs-err file and a core right at the point that (probably) causes the leak. This makes error analysis a lot simpler, and is also valuable for regression-testing footprint usage. > > Some people wished for a way to not end with a fatal error but to mimic a native OOM (causing os::malloc to return NULL). This would allow us to test resilience in the face of native OOMs, among other things. > > ### Patch > > - Expands the `MallocLimit` option syntax, allowing for an "oom mode" that mimics an oom: > > > > Global form: > -XX:MallocLimit=[:] > Category-specific form: > -XX:MallocLimit=:[:][,:[:] ...] > Examples: > -XX:MallocLimit=3g > -XX:MallocLimit=3g:oom > -XX:MallocLimit=compiler:200m:oom > > > - moves parsing of `-XX:MallocLimit` out of arguments.cpp into `mallocLimit.hpp/cpp`, and rewrites it. > > - changes when limits are checked. Before, the limits were checked *after* the allocation that caused the threshold overflow. Now we check beforehand. > > - removes `MallocMaxTestWords`, replacing its uses with `MallocLimit` > > - adds new gtests and new jtreg tests > > - removes a bunch of jtreg tests which are now better served by the new gtests. > > - gives us more precise error messages upon reaching a limit. For example: > > before: > > # fatal error: MallocLimit: category "Compiler" reached limit (size: 20997680, limit: 20971520) > > > now: > > # fatal error: MallocLimit: reached category "Compiler" limit (triggering allocation size: 1920B, allocated so far: 20505K, limit: 20480K) Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Feedback Gerard ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11371/files - new: https://git.openjdk.org/jdk/pull/11371/files/c0d9dc85..9bbe3246 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11371&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11371&range=03-04 Stats: 60 lines in 5 files changed: 32 ins; 15 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/11371.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11371/head:pull/11371 PR: https://git.openjdk.org/jdk/pull/11371 From stuefe at openjdk.org Fri Jan 27 07:07:31 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 27 Jan 2023 07:07:31 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v4] In-Reply-To: <0gBM_DNhRfjJq_Yvj5YgNuffkOKp3xsMhD2DdTPcVlE=.8b249d12-de55-4396-8c4a-b14f5c4aea5d@github.com> References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> <_khJTogN_LFzv_VSMdncQeFf9zyMDgWGaiPRTuuXVl0=.2dad11d6-cc4e-46de-ad11-7bb607e8900e@github.com> <0gBM_DNhRfjJq_Yvj5YgNuffkOKp3xsMhD2DdTPcVlE=.8b249d12-de55-4396-8c4a-b14f5c4aea5d@github.com> Message-ID: On Thu, 26 Jan 2023 17:33:26 GMT, Gerard Ziemski wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert strchrnul > > The rest looks good to me. > > This is a really nice feature, thank you for doing this! Hi @gerard-ziemski, thanks for your review! Could you take a look at the final version? > src/hotspot/share/services/mallocLimit.cpp line 150: > >> 148: } >> 149: } >> 150: } > > I am not crazy about: > > > static const char* flagnames[] = { "fatal", "oom" }; > > > which requires that we position the strings in `flagnames` in a way that matches `MallocLimitMode` enum values: > > > enum class MallocLimitMode { > trigger_fatal = 0, > trigger_oom = 1 > }; > > > Could we do instead: > > > void MallocLimitSet::print_on(outputStream* st) const { > if (_glob.sz > 0) { > st->print_cr("MallocLimit: total limit: " PROPERFMT " (%s)", > PROPERFMTARGS(_glob.sz), MallocLimitSet::limit_name(_glob.mode)); > } else { > for (int i = 0; i < mt_number_of_types; i++) { > if (_cat[i].sz > 0) { > st->print_cr("MallocLimit: category "%s" limit: " PROPERFMT " (%s)", > NMTUtil::flag_to_enum_name(NMTUtil::index_to_flag(i)), > PROPERFMTARGS(_cat[i].sz), MallocLimitSet::limit_name(_cat[i].mode)); > } > } > } > } > > > and add new API to `MallocLimitSet`: > > > static const char* const limit_name(MallocLimitMode l) { return (l==MallocLimitMode::trigger_fatal)?"fatal":"oom"; } > > > This way we also avoid the `(int)` casting from the `enum`. > > We could also potentially use `MallocLimitSet::limit_name()` in `match_mode_flag()` instead of hardcoding "oom" and "fatal" Okay, minus the exposure of the API. Its not needed outside of this file. ------------- PR: https://git.openjdk.org/jdk/pull/11371 From eosterlund at openjdk.org Fri Jan 27 08:12:23 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 27 Jan 2023 08:12:23 GMT Subject: Integrated: 8300253: Introduce AArch64 nzcv accessors In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 13:47:26 GMT, Erik ?sterlund wrote: > Some code, such as verification code, might want to run without changing the state of the system. To do that, it's useful to be able to get and set the nzcv flags. This enhancement aims at adding accessors for that. This pull request has now been integrated. Changeset: 6e4710bc Author: Erik ?sterlund URL: https://git.openjdk.org/jdk/commit/6e4710bc830a9c324fa71feab2f8442bf72453fa Stats: 980 lines in 3 files changed: 95 ins; 0 del; 885 mod 8300253: Introduce AArch64 nzcv accessors Reviewed-by: aph, smonteith ------------- PR: https://git.openjdk.org/jdk/pull/12038 From ayang at openjdk.org Fri Jan 27 08:17:24 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 27 Jan 2023 08:17:24 GMT Subject: RFR: 8301164: Remove unused ResourceStack class In-Reply-To: <80ICW8phtXGNC9-EOHnWC47wsKIAvVOFhI8zkysVhRA=.158a9b74-e0f6-475c-8b18-2c3b5938a23f@github.com> References: <80ICW8phtXGNC9-EOHnWC47wsKIAvVOFhI8zkysVhRA=.158a9b74-e0f6-475c-8b18-2c3b5938a23f@github.com> Message-ID: On Thu, 26 Jan 2023 15:06:27 GMT, Albert Mingkun Yang wrote: > Trivial removing dead code. Thanks for the review. ------------- PR: https://git.openjdk.org/jdk/pull/12221 From ayang at openjdk.org Fri Jan 27 08:17:24 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 27 Jan 2023 08:17:24 GMT Subject: Integrated: 8301164: Remove unused ResourceStack class In-Reply-To: <80ICW8phtXGNC9-EOHnWC47wsKIAvVOFhI8zkysVhRA=.158a9b74-e0f6-475c-8b18-2c3b5938a23f@github.com> References: <80ICW8phtXGNC9-EOHnWC47wsKIAvVOFhI8zkysVhRA=.158a9b74-e0f6-475c-8b18-2c3b5938a23f@github.com> Message-ID: On Thu, 26 Jan 2023 15:06:27 GMT, Albert Mingkun Yang wrote: > Trivial removing dead code. This pull request has now been integrated. Changeset: f7da09c3 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/f7da09c34918eea434c82af22b1da1f2a5b35f35 Stats: 33 lines in 2 files changed: 0 ins; 33 del; 0 mod 8301164: Remove unused ResourceStack class Reviewed-by: coleenp ------------- PR: https://git.openjdk.org/jdk/pull/12221 From stuefe at openjdk.org Fri Jan 27 09:46:57 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 27 Jan 2023 09:46:57 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v6] In-Reply-To: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> Message-ID: > Rework NMT `MallocLimit` to make it more useful for native OOM analysis. Also remove `MallocMaxTestWords`, which had been mostly redundant with NMT (for background, see JDK-8293292). > > > ### Background > > Some months ago we had [JDK-8291919](https://bugs.openjdk.org/browse/JDK-8291919), a compiler regression that caused compiler arenas to grow boundlessly. Process was usually OOM-killed before we could take a look, so this was difficult to analyze. > > To improve analysis options, we added NMT *malloc limits* with [JDK-8291878](https://bugs.openjdk.org/browse/JDK-8291878). Malloc limits let us set one or multiple limits to malloc load. Surpassing a limit causes the VM to stop with a fatal error in the allocation function, giving us a hs-err file and a core right at the point that (probably) causes the leak. This makes error analysis a lot simpler, and is also valuable for regression-testing footprint usage. > > Some people wished for a way to not end with a fatal error but to mimic a native OOM (causing os::malloc to return NULL). This would allow us to test resilience in the face of native OOMs, among other things. > > ### Patch > > - Expands the `MallocLimit` option syntax, allowing for an "oom mode" that mimics an oom: > > > > Global form: > -XX:MallocLimit=[:] > Category-specific form: > -XX:MallocLimit=:[:][,:[:] ...] > Examples: > -XX:MallocLimit=3g > -XX:MallocLimit=3g:oom > -XX:MallocLimit=compiler:200m:oom > > > - moves parsing of `-XX:MallocLimit` out of arguments.cpp into `mallocLimit.hpp/cpp`, and rewrites it. > > - changes when limits are checked. Before, the limits were checked *after* the allocation that caused the threshold overflow. Now we check beforehand. > > - removes `MallocMaxTestWords`, replacing its uses with `MallocLimit` > > - adds new gtests and new jtreg tests > > - removes a bunch of jtreg tests which are now better served by the new gtests. > > - gives us more precise error messages upon reaching a limit. For example: > > before: > > # fatal error: MallocLimit: category "Compiler" reached limit (size: 20997680, limit: 20971520) > > > now: > > # fatal error: MallocLimit: reached category "Compiler" limit (triggering allocation size: 1920B, allocated so far: 20505K, limit: 20480K) Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Merge; fix conflicts - Feedback Gerard - Revert strchrnul - Copyrights - Feedback Johan - Merge - Merge branch 'master' into JDK-8293313-NMT-fake-oom - MallocLimit ------------- Changes: https://git.openjdk.org/jdk/pull/11371/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11371&range=05 Stats: 1012 lines in 21 files changed: 653 ins; 256 del; 103 mod Patch: https://git.openjdk.org/jdk/pull/11371.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11371/head:pull/11371 PR: https://git.openjdk.org/jdk/pull/11371 From fjiang at openjdk.org Fri Jan 27 09:50:01 2023 From: fjiang at openjdk.org (Feilong Jiang) Date: Fri, 27 Jan 2023 09:50:01 GMT Subject: RFR: 8301067: RISC-V: better error message when reporting unsupported satp modes Message-ID: Add more detailed information to the error log when reporting unsupported stap modes. Currently, RISC-V port only supports up to sv48. ------------- Commit messages: - add more information when reporting unsuppoted satp modes Changes: https://git.openjdk.org/jdk/pull/12247/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12247&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301067 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12247.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12247/head:pull/12247 PR: https://git.openjdk.org/jdk/pull/12247 From kbarrett at openjdk.org Fri Jan 27 10:42:17 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 27 Jan 2023 10:42:17 GMT Subject: RFR: 8300463: Build failure on Windows 32 after JDK-8296401 In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 05:43:52 GMT, Fei Yang wrote: > This issue also triggers when building slowdebug on linux-aarch64 with GCC-9.4.0. Given that std::numeric_limits::max() returns positive integer number and size_t is an unsigned type, I guess it's safe to do simple static_cast here both on 32-bit and 64-bit platfoms. Slowdebug on linux-aarch64 builds fine with this fix. src/hotspot/share/utilities/concurrentHashTable.inline.hpp line 1000: > 998: ndel[dels] = rem_n; > 999: } else { > 1000: guarantee(dels < static_cast(std::numeric_limits::max()), Does the problem go away if this uses `INT_MAX` instead? ------------- PR: https://git.openjdk.org/jdk/pull/12178 From stefank at openjdk.org Fri Jan 27 10:57:19 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 27 Jan 2023 10:57:19 GMT Subject: RFR: 8301047: Clean up type unsafe uses of oop from compiler code In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 15:45:06 GMT, Erik ?sterlund wrote: > In an ideal world, when you have an oop, its contents should also be an oop. It happens, however, that we have other forms of pointers sometimes, used with the oop type, in some compiler code. We should clean that up. Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12223 From stefank at openjdk.org Fri Jan 27 11:36:32 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 27 Jan 2023 11:36:32 GMT Subject: RFR: JDK-8301072: Replace NULL with nullptr in share/oops/ In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 11:46:23 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/oops/. 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! Changes requested by stefank (Reviewer). src/hotspot/share/oops/compressedOops.inline.hpp line 63: > 61: > 62: inline oop CompressedOops::decode(narrowOop v) { > 63: return is_null(v) ? (oop)nullptr : decode_not_null(v); Seems like we should be able to remove the `(oop)` cast after this change. src/hotspot/share/oops/compressedOops.inline.hpp line 140: > 138: > 139: inline Klass* CompressedKlassPointers::decode(narrowKlass v) { > 140: return is_null(v) ? (Klass*)nullptr : decode_not_null(v); Seems like we should be able to remove the `(Klass*)` cast after this change. src/hotspot/share/oops/constantPool.hpp line 189: > 187: Symbol* generic_signature() const { > 188: return (_generic_signature_index == 0) ? > 189: (Symbol*)nullptr : symbol_at(_generic_signature_index); Remove cast? src/hotspot/share/oops/constantPool.hpp line 197: > 195: Symbol* source_file_name() const { > 196: return (_source_file_name_index == 0) ? > 197: (Symbol*)nullptr : symbol_at(_source_file_name_index); Remove cast? src/hotspot/share/oops/generateOopMap.cpp line 677: > 675: #define ALLOC_RESOURCE_ARRAY(var, type, count) \ > 676: var = NEW_RESOURCE_ARRAY_RETURN_NULL(type, count); \ > 677: if (var == nullptr) { \ Could you fix the alignment of the backslashes? src/hotspot/share/oops/instanceKlass.cpp line 2166: > 2164: if (jmeths == nullptr || // no cache yet > 2165: length <= idnum || // cache is too short > 2166: id == nullptr) { // cache doesn't contain entry Comments seems to be misaligned now. src/hotspot/share/oops/instanceKlass.cpp line 2259: > 2257: > 2258: if (jmeths == nullptr || // no cache yet > 2259: (length = (size_t)jmeths[0]) <= idnum) { // cache is too short Alignment of comments src/hotspot/share/oops/instanceKlass.cpp line 2318: > 2316: if (jmeths != NULL && // If there is a cache > 2317: (length = (size_t)jmeths[0]) > idnum) { // and if it is long enough, > 2318: id = jmeths[idnum+1]; // Look up the id (may be NULL) Alignment of comments src/hotspot/share/oops/klass.cpp line 433: > 431: if (super == NULL) return; // special case: class Object > 432: assert((!super->is_interface() // interfaces cannot be supers > 433: && (super->superklass() == NULL || !is_interface())), Alignment of comments src/hotspot/share/oops/method.hpp line 167: > 165: > 166: // generics support > 167: Symbol* generic_signature() const { int idx = generic_signature_index(); return ((idx != 0) ? constants()->symbol_at(idx) : (Symbol*)nullptr); } Remove cast? src/hotspot/share/oops/oopHandle.inline.hpp line 34: > 32: > 33: inline oop OopHandle::resolve() const { > 34: return (_obj == nullptr) ? (oop)nullptr : NativeAccess<>::oop_load(_obj); Remove cast? src/hotspot/share/oops/oopHandle.inline.hpp line 38: > 36: > 37: inline oop OopHandle::peek() const { > 38: return (_obj == nullptr) ? (oop)nullptr : NativeAccess::oop_load(_obj); Remove cast? src/hotspot/share/oops/oopHandle.inline.hpp line 53: > 51: if (_obj != nullptr) { > 52: // Clear the OopHandle first > 53: NativeAccess<>::oop_store(_obj, (oop)nullptr); Remove cast? src/hotspot/share/oops/weakHandle.cpp line 54: > 52: // Clear the WeakHandle. For race in creating ClassLoaderData, we can release this > 53: // WeakHandle before it is cleared by GC. > 54: NativeAccess::oop_store(_obj, (oop)nullptr); Remove cast? ------------- PR: https://git.openjdk.org/jdk/pull/12186 From adinn at openjdk.org Fri Jan 27 11:38:18 2023 From: adinn at openjdk.org (Andrew Dinn) Date: Fri, 27 Jan 2023 11:38:18 GMT Subject: RFR: 8300669: AArch64: Table based tails processing and wider stores for Arrays.fill() intrinsic [v6] In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 18:13:31 GMT, Andrew Haley wrote: > The worst part of it is that, with separate code for each length of copy, we have something that looks good in benchmarks, but it occupies more instruction cache that could be used for other things. I would not be surprised if, when integrated into an application with high icache pressure, it didn't make things worse. Those are definitely important points. This is a lot more instruction cache than with the status quo dedicated to a stub that addresses one specific need. Also, as you say, this has the potential to noticeably increase cache pressure. A counter-argument to that might be that an application doing a lot of array fills may well be filling arrays of the same size or from a limited range of sizes (even if those sizes varied from app to app). But that's not always going to be true. Stepping back a bit from that critique I'm prompted to ask what is motivating this change. What evidence is there that we need this solution, or any, in preference to the one we already have? > Also, it's a lot of complicated code, with only a small gain even on a specially-designed benchmark. That's another important point that underlines the need for a compelling answer to the question of motivation, preferably an answer which also offers reason to believe the benchmark results will translate to similar gains in a real app. ------------- PR: https://git.openjdk.org/jdk/pull/12222 From fyang at openjdk.org Fri Jan 27 12:43:39 2023 From: fyang at openjdk.org (Fei Yang) Date: Fri, 27 Jan 2023 12:43:39 GMT Subject: RFR: 8300463: Build failure on Windows 32 after JDK-8296401 [v2] In-Reply-To: References: Message-ID: > This issue also triggers when building slowdebug on linux-aarch64 with GCC-9.4.0. Given that std::numeric_limits::max() returns positive integer number and size_t is an unsigned type, I guess it's safe to do simple static_cast here both on 32-bit and 64-bit platfoms. Slowdebug on linux-aarch64 builds fine with this fix. Fei Yang has updated the pull request incrementally with one additional commit since the last revision: Comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12178/files - new: https://git.openjdk.org/jdk/pull/12178/files/f76cb7ef..14190118 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12178&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12178&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12178.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12178/head:pull/12178 PR: https://git.openjdk.org/jdk/pull/12178 From fyang at openjdk.org Fri Jan 27 12:43:43 2023 From: fyang at openjdk.org (Fei Yang) Date: Fri, 27 Jan 2023 12:43:43 GMT Subject: RFR: 8300463: Build failure on Windows 32 after JDK-8296401 [v2] In-Reply-To: References: Message-ID: <6RNyAfRJYbR_BfMjwdSZkMCBRMOu7ZQTKGNWTZcDxog=.5decebfa-8ef6-4132-b23d-16127cc068b5@github.com> On Fri, 27 Jan 2023 10:39:56 GMT, Kim Barrett wrote: >> Fei Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> Comment > > src/hotspot/share/utilities/concurrentHashTable.inline.hpp line 1000: > >> 998: ndel[dels] = rem_n; >> 999: } else { >> 1000: guarantee(dels < static_cast(std::numeric_limits::max()), > > Does the problem go away if this uses `INT_MAX` instead? Verified on linux-aarch64 that this also fixes this issue. I searched the hotspot shared code and witnessed similar usages. I guess it's better to align with those cases. Fixed. ------------- PR: https://git.openjdk.org/jdk/pull/12178 From jsjolen at openjdk.org Fri Jan 27 13:42:43 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 27 Jan 2023 13:42:43 GMT Subject: RFR: JDK-8301072: Replace NULL with nullptr in share/oops/ [v2] In-Reply-To: References: Message-ID: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/oops/. 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: Do stefank's fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12186/files - new: https://git.openjdk.org/jdk/pull/12186/files/7a7db987..9d9fdfc7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12186&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12186&range=00-01 Stats: 17 lines in 8 files changed: 0 ins; 0 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/12186.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12186/head:pull/12186 PR: https://git.openjdk.org/jdk/pull/12186 From jsjolen at openjdk.org Fri Jan 27 13:42:46 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 27 Jan 2023 13:42:46 GMT Subject: RFR: JDK-8301072: Replace NULL with nullptr in share/oops/ In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 11:46:23 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/oops/. 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! Thanks Stefan, added your fixes. ------------- PR: https://git.openjdk.org/jdk/pull/12186 From coleenp at openjdk.org Fri Jan 27 13:49:23 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 27 Jan 2023 13:49:23 GMT Subject: RFR: 8301136: Improve unlink() and unlink_all() of ResourceHashtableBase [v3] In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 07:02:30 GMT, Xin Liu wrote: >> 1. Apply the same idea of JDK-8300184 to unlink(). >> 2. Because ResourceHashtableBase doesn't support copy assignment, client of it has to purge all elements first when it needs to assign it. We would like provide a specialized version called 'unlink_all()'. We don't need to update each node's _next in this case. We only nullify all buckets. >> 3. This patch also provides a specialized version of unlink_all() for destructor. We don't even update buckets. it's dead anyway. > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > Add a template for unlink(), unlink_all() and dtor. Changes requested by coleenp (Reviewer). src/hotspot/share/utilities/resourceHash.hpp line 282: > 280: template > 281: void unlink(ITER* iter) { > 282: auto wrapper = [&](Node* const node, Node**& ptr) { I wanted unlink to be lambda enabled, not an unlink_impl. Can you just make unlink_all be something that provides a "return true" lambda and call unlink with that? test/hotspot/gtest/utilities/test_resourceHash.cpp line 339: > 337: } > 338: > 339: TEST_VM_F(SimpleResourceHashtableDeleteTest, simle_unlink_all) { Missing a 'p' in the method name. ------------- PR: https://git.openjdk.org/jdk/pull/12213 From coleenp at openjdk.org Fri Jan 27 13:49:25 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 27 Jan 2023 13:49:25 GMT Subject: RFR: 8301136: Improve unlink() and unlink_all() of ResourceHashtableBase [v3] In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 13:45:05 GMT, Coleen Phillimore wrote: >> Xin Liu has updated the pull request incrementally with one additional commit since the last revision: >> >> Add a template for unlink(), unlink_all() and dtor. > > src/hotspot/share/utilities/resourceHash.hpp line 282: > >> 280: template >> 281: void unlink(ITER* iter) { >> 282: auto wrapper = [&](Node* const node, Node**& ptr) { > > I wanted unlink to be lambda enabled, not an unlink_impl. Can you just make unlink_all be something that provides a "return true" lambda and call unlink with that? Or rather, first have a patch to add unlink that takes a lambda and convert the uses to that. I don't see the motivation for this change. ------------- PR: https://git.openjdk.org/jdk/pull/12213 From jsjolen at openjdk.org Fri Jan 27 13:59:11 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 27 Jan 2023 13:59:11 GMT Subject: RFR: JDK-8301224: Replace NULL with nullptr in share/gc/shared/ Message-ID: Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/gc/shared/. 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! ------------- Commit messages: - Fix - Fix - Merge remote-tracking branch 'origin/master' into JDK-8301224 - Replace NULL with nullptr in share/gc/shared/ Changes: https://git.openjdk.org/jdk/pull/12249/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12249&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301224 Stats: 612 lines in 89 files changed: 0 ins; 0 del; 612 mod Patch: https://git.openjdk.org/jdk/pull/12249.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12249/head:pull/12249 PR: https://git.openjdk.org/jdk/pull/12249 From kbarrett at openjdk.org Fri Jan 27 13:59:17 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 27 Jan 2023 13:59:17 GMT Subject: RFR: 8300463: Build failure on Windows 32 after JDK-8296401 [v2] In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 12:43:39 GMT, Fei Yang wrote: >> This issue also triggers when building slowdebug on linux-aarch64 with GCC-9.4.0. Given that std::numeric_limits::max() returns positive integer number and size_t is an unsigned type, I guess it's safe to do simple static_cast here both on 32-bit and 64-bit platfoms. Slowdebug on linux-aarch64 builds fine with this fix. > > Fei Yang has updated the pull request incrementally with one additional commit since the last revision: > > Comment Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/12178 From jsjolen at openjdk.org Fri Jan 27 13:59:13 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 27 Jan 2023 13:59:13 GMT Subject: RFR: JDK-8301224: Replace NULL with nullptr in share/gc/shared/ In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 10:06:26 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/gc/shared/. 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! Found only one issue. src/hotspot/share/gc/shared/c2/barrierSetC2.cpp line 366: > 364: Node* adr = _addr.node(); > 365: if (!needs_cpu_membar() && adr_type->isa_instptr()) { > 366: assert(adr_type->meet(TypePtr::nullptr_PTR) != adr_type->remove_speculative(), "should be not null"); NULL_PTR ------------- PR: https://git.openjdk.org/jdk/pull/12249 From fparain at openjdk.org Fri Jan 27 14:01:26 2023 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 27 Jan 2023 14:01:26 GMT Subject: RFR: 8301123: Enable Symbol refcounting underflow checks in PRODUCT In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 13:24:42 GMT, Coleen Phillimore wrote: > Enabling refcounting underflow detection in product would have helped with debugging [JDK-8278965](https://bugs.openjdk.org/browse/JDK-8278965). We'd rather have this assert for customers than the subsequent memory corruption. > Tested with tier1-4, 7, 8 with linux-x64 product. Looks good to me. ------------- Marked as reviewed by fparain (Committer). PR: https://git.openjdk.org/jdk/pull/12218 From jwaters at openjdk.org Fri Jan 27 14:02:05 2023 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 27 Jan 2023 14:02:05 GMT Subject: RFR: 8301244: Replace legacy pragma implementations in HotSpot Message-ID: HotSpot has a few legacy implementations of pragmas in some of its macros, they should be cleaned up and instead use a shared new PRAGMA macro available to all platforms ------------- Commit messages: - compilerWarnings_gcc.hpp - compilerWarnings_visCPP.hpp - Introduce PRAGMA Changes: https://git.openjdk.org/jdk/pull/12255/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12255&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301244 Stats: 10 lines in 3 files changed: 4 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/12255.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12255/head:pull/12255 PR: https://git.openjdk.org/jdk/pull/12255 From eosterlund at openjdk.org Fri Jan 27 14:06:22 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 27 Jan 2023 14:06:22 GMT Subject: RFR: 8301047: Clean up type unsafe uses of oop from compiler code In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 10:54:16 GMT, Stefan Karlsson wrote: >> In an ideal world, when you have an oop, its contents should also be an oop. It happens, however, that we have other forms of pointers sometimes, used with the oop type, in some compiler code. We should clean that up. > > Marked as reviewed by stefank (Reviewer). Thanks for the review, @stefank! ------------- PR: https://git.openjdk.org/jdk/pull/12223 From coleenp at openjdk.org Fri Jan 27 14:07:29 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 27 Jan 2023 14:07:29 GMT Subject: RFR: JDK-8301077: Replace NULL with nullptr in share/services/ [v2] In-Reply-To: <_X0IZpW-Kd8SmMSgkUR9XvwYxKuqer65A6i6GjCYhyM=.8c0fe68f-ca64-4acb-a80e-e043758f0c5b@github.com> References: <_X0IZpW-Kd8SmMSgkUR9XvwYxKuqer65A6i6GjCYhyM=.8c0fe68f-ca64-4acb-a80e-e043758f0c5b@github.com> Message-ID: On Thu, 26 Jan 2023 15:02:54 GMT, Johan Sj?len wrote: >> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/services/. 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: > > plummercj's fixes Marked as reviewed by coleenp (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12189 From coleenp at openjdk.org Fri Jan 27 14:12:21 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 27 Jan 2023 14:12:21 GMT Subject: RFR: JDK-8301072: Replace NULL with nullptr in share/oops/ [v2] In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 13:42:43 GMT, Johan Sj?len wrote: >> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/oops/. 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: > > Do stefank's fixes Besides the casts that you may or may not be able to remove, this looks fine. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/12186 From stefank at openjdk.org Fri Jan 27 14:28:16 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 27 Jan 2023 14:28:16 GMT Subject: RFR: JDK-8301224: Replace NULL with nullptr in share/gc/shared/ In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 10:06:26 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/gc/shared/. 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! Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12249 From stefank at openjdk.org Fri Jan 27 14:29:22 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 27 Jan 2023 14:29:22 GMT Subject: RFR: JDK-8301072: Replace NULL with nullptr in share/oops/ [v2] In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 13:42:43 GMT, Johan Sj?len wrote: >> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/oops/. 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: > > Do stefank's fixes Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12186 From iklam at openjdk.org Fri Jan 27 14:49:17 2023 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 27 Jan 2023 14:49:17 GMT Subject: RFR: 8301123: Enable Symbol refcounting underflow checks in PRODUCT In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 13:24:42 GMT, Coleen Phillimore wrote: > Enabling refcounting underflow detection in product would have helped with debugging [JDK-8278965](https://bugs.openjdk.org/browse/JDK-8278965). We'd rather have this assert for customers than the subsequent memory corruption. > Tested with tier1-4, 7, 8 with linux-x64 product. LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.org/jdk/pull/12218 From coleenp at openjdk.org Fri Jan 27 14:59:27 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 27 Jan 2023 14:59:27 GMT Subject: RFR: 8301123: Enable Symbol refcounting underflow checks in PRODUCT In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 13:24:42 GMT, Coleen Phillimore wrote: > Enabling refcounting underflow detection in product would have helped with debugging [JDK-8278965](https://bugs.openjdk.org/browse/JDK-8278965). We'd rather have this assert for customers than the subsequent memory corruption. > Tested with tier1-4, 7, 8 with linux-x64 product. Thanks Fred and Ioi! ------------- PR: https://git.openjdk.org/jdk/pull/12218 From coleenp at openjdk.org Fri Jan 27 14:59:27 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 27 Jan 2023 14:59:27 GMT Subject: Integrated: 8301123: Enable Symbol refcounting underflow checks in PRODUCT In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 13:24:42 GMT, Coleen Phillimore wrote: > Enabling refcounting underflow detection in product would have helped with debugging [JDK-8278965](https://bugs.openjdk.org/browse/JDK-8278965). We'd rather have this assert for customers than the subsequent memory corruption. > Tested with tier1-4, 7, 8 with linux-x64 product. This pull request has now been integrated. Changeset: fccf8189 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/fccf818972f15bc4f69ce9566b5cd4b7e7777107 Stats: 14 lines in 2 files changed: 7 ins; 6 del; 1 mod 8301123: Enable Symbol refcounting underflow checks in PRODUCT Reviewed-by: fparain, iklam ------------- PR: https://git.openjdk.org/jdk/pull/12218 From rkennke at openjdk.org Fri Jan 27 15:00:58 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 27 Jan 2023 15:00:58 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v16] In-Reply-To: References: Message-ID: > See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details. > > Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements. > > Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16. > > Testing: > - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390) > - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390) > - [x] tier1 (x86_64, x86_32, aarch64, riscv) > - [x] tier2 (x86_64, aarch64, riscv) > - [x] tier3 (x86_64, riscv) Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Avoid overflow on 32 bit builds. Check double-word alignment in C2 new-array runtime ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11044/files - new: https://git.openjdk.org/jdk/pull/11044/files/fb9f18ea..f31995e3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=14-15 Stats: 9 lines in 2 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/11044.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11044/head:pull/11044 PR: https://git.openjdk.org/jdk/pull/11044 From iklam at openjdk.org Fri Jan 27 15:09:19 2023 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 27 Jan 2023 15:09:19 GMT Subject: RFR: JDK-8300241: Replace NULL with nullptr in share/classfile/ [v2] In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 12:27:55 GMT, Johan Sj?len wrote: >> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/classfile/. 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 with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge remote-tracking branch 'origin/master' into JDK-8300241 > - Manual fixes > - Replace NULL with nullptr in share/classfile/ Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12030 From jsjolen at openjdk.org Fri Jan 27 15:46:31 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 27 Jan 2023 15:46:31 GMT Subject: RFR: JDK-8301077: Replace NULL with nullptr in share/services/ [v2] In-Reply-To: <_X0IZpW-Kd8SmMSgkUR9XvwYxKuqer65A6i6GjCYhyM=.8c0fe68f-ca64-4acb-a80e-e043758f0c5b@github.com> References: <_X0IZpW-Kd8SmMSgkUR9XvwYxKuqer65A6i6GjCYhyM=.8c0fe68f-ca64-4acb-a80e-e043758f0c5b@github.com> Message-ID: On Thu, 26 Jan 2023 15:02:54 GMT, Johan Sj?len wrote: >> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/services/. 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: > > plummercj's fixes Still passes tier1! ------------- PR: https://git.openjdk.org/jdk/pull/12189 From jsjolen at openjdk.org Fri Jan 27 15:46:34 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 27 Jan 2023 15:46:34 GMT Subject: Integrated: JDK-8301077: Replace NULL with nullptr in share/services/ In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 11:47:18 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/services/. 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: 5c1ec826 Author: Johan Sj?len URL: https://git.openjdk.org/jdk/commit/5c1ec82656323872c4628026662fe5b62e7a61e3 Stats: 856 lines in 44 files changed: 0 ins; 0 del; 856 mod 8301077: Replace NULL with nullptr in share/services/ Reviewed-by: cjplummer, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/12189 From jsjolen at openjdk.org Fri Jan 27 15:49:21 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 27 Jan 2023 15:49:21 GMT Subject: RFR: JDK-8301224: Replace NULL with nullptr in share/gc/shared/ In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 10:06:26 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/gc/shared/. 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! Passes tier1. ------------- PR: https://git.openjdk.org/jdk/pull/12249 From eosterlund at openjdk.org Fri Jan 27 15:52:54 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 27 Jan 2023 15:52:54 GMT Subject: RFR: 8301248: InstanceRefKlass::trace_reference_gc Message-ID: The InstanceRefKlass::trace_reference_gc function is called when using oop_iterate on a reference object. Since oop_iterate is a general iterator that can be used for anything, including verification code, it would be desirable for this code to not have subtle side effects. We currently apply load barriers which "fix" pointers in the heap. As a result, verification code that was meant to detect bugs, can end up fixing and hiding the bug. This CR aims to address this by limiting the logging to addresses, and not following them. ------------- Commit messages: - 8301248: InstanceRefKlass::trace_reference_gc Changes: https://git.openjdk.org/jdk/pull/12258/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12258&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301248 Stats: 18 lines in 1 file changed: 6 ins; 2 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/12258.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12258/head:pull/12258 PR: https://git.openjdk.org/jdk/pull/12258 From jsjolen at openjdk.org Fri Jan 27 16:18:26 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 27 Jan 2023 16:18:26 GMT Subject: Integrated: JDK-8300241: Replace NULL with nullptr in share/classfile/ In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 11:13:22 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/classfile/. 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: 49ff5208 Author: Johan Sj?len URL: https://git.openjdk.org/jdk/commit/49ff52087be8b95cbf369518281312ecc9d83618 Stats: 1836 lines in 63 files changed: 0 ins; 0 del; 1836 mod 8300241: Replace NULL with nullptr in share/classfile/ Reviewed-by: coleenp, iklam ------------- PR: https://git.openjdk.org/jdk/pull/12030 From rkennke at openjdk.org Fri Jan 27 16:33:47 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 27 Jan 2023 16:33:47 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v17] In-Reply-To: References: Message-ID: > See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details. > > Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements. > > Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16. > > Testing: > - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390) > - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390) > - [x] tier1 (x86_64, x86_32, aarch64, riscv) > - [x] tier2 (x86_64, aarch64, riscv) > - [x] tier3 (x86_64, riscv) Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Use uint64_t ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11044/files - new: https://git.openjdk.org/jdk/pull/11044/files/f31995e3..629fcecd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=15-16 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/11044.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11044/head:pull/11044 PR: https://git.openjdk.org/jdk/pull/11044 From jcking at openjdk.org Fri Jan 27 17:00:58 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 27 Jan 2023 17:00:58 GMT Subject: RFR: JDK-8300783: Consolidate byteswap implementations [v12] In-Reply-To: References: Message-ID: > Deduplicate byte swapping implementations by consolidating them into `utilities/byteswap.hpp`, following `std::byteswap` introduced in C++23. Further simplification of `Bytes` will follow in https://github.com/openjdk/jdk/pull/12078. Justin King has updated the pull request incrementally with four additional commits since the last revision: - Update copyright Signed-off-by: Justin King - Add missing include Signed-off-by: Justin King - Remove unused include Signed-off-by: Justin King - Reorganize tests Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12114/files - new: https://git.openjdk.org/jdk/pull/12114/files/d43b9f10..139c4205 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12114&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12114&range=10-11 Stats: 254 lines in 3 files changed: 152 ins; 102 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12114.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12114/head:pull/12114 PR: https://git.openjdk.org/jdk/pull/12114 From jcking at openjdk.org Fri Jan 27 17:01:00 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 27 Jan 2023 17:01:00 GMT Subject: RFR: JDK-8300783: Consolidate byteswap implementations [v11] In-Reply-To: References: <3uBeKIc_YXtM7PyyL1s8JOi-dQRpFGYEVNM1taKHtFI=.db1a5667-94f2-4456-867c-a0701b794210@github.com> Message-ID: On Fri, 27 Jan 2023 02:27:54 GMT, David Holmes wrote: >> Justin King has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix test >> >> Signed-off-by: Justin King > > test/hotspot/gtest/opto/test_moveBits.cpp line 42: > >> 40: ASSERT_EQ(reverse_bits((T)-1), (T)-1); >> 41: ASSERT_EQ(byteswap((T)0), (T)0); >> 42: ASSERT_EQ(byteswap((T)-1), (T)-1); > > This isn't testing moveBits any more so doesn't belong here. Moved test_moveBits.cpp to be in utilities and split out byteswap tests into their own file. > test/hotspot/gtest/opto/test_moveBits.cpp line 58: > >> 56: ASSERT_EQ((T)~reverse_bits((T)~mask), revm1|revm2) << STUFF; >> 57: ASSERT_EQ(byteswap(mask), rbym1|rbym2) << STUFF; >> 58: ASSERT_EQ((T)~byteswap((T)~mask), rbym1|rbym2) << STUFF; > > Ditto - doesn't belong here. Done. ------------- PR: https://git.openjdk.org/jdk/pull/12114 From coleenp at openjdk.org Fri Jan 27 17:15:28 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 27 Jan 2023 17:15:28 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v17] In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 16:33:47 GMT, Roman Kennke wrote: >> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details. >> >> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements. >> >> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16. >> >> Testing: >> - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] tier1 (x86_64, x86_32, aarch64, riscv) >> - [x] tier2 (x86_64, aarch64, riscv) >> - [x] tier3 (x86_64, riscv) > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Use uint64_t I'm following occurrences of header_size() in the code because that might be where we have assumptions about where the payload for oops starts. Ignoring the occurrences from metadata, there is one unused one in instanceOop.hpp, not related to your change that I think should be removed. The one OopDesc::header_size() is used by min_dummy_object_size and min_fill_size in CollectedHeap. These usages look okay to me but if they were rewritten to use heap_word_size(), maybe that would be better. I ran tier1-8 on this for linux-x64-debug with no failures. ------------- PR: https://git.openjdk.org/jdk/pull/11044 From gziemski at openjdk.org Fri Jan 27 17:31:32 2023 From: gziemski at openjdk.org (Gerard Ziemski) Date: Fri, 27 Jan 2023 17:31:32 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v6] In-Reply-To: References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> Message-ID: On Fri, 27 Jan 2023 09:46:57 GMT, Thomas Stuefe wrote: >> Rework NMT `MallocLimit` to make it more useful for native OOM analysis. Also remove `MallocMaxTestWords`, which had been mostly redundant with NMT (for background, see JDK-8293292). >> >> >> ### Background >> >> Some months ago we had [JDK-8291919](https://bugs.openjdk.org/browse/JDK-8291919), a compiler regression that caused compiler arenas to grow boundlessly. Process was usually OOM-killed before we could take a look, so this was difficult to analyze. >> >> To improve analysis options, we added NMT *malloc limits* with [JDK-8291878](https://bugs.openjdk.org/browse/JDK-8291878). Malloc limits let us set one or multiple limits to malloc load. Surpassing a limit causes the VM to stop with a fatal error in the allocation function, giving us a hs-err file and a core right at the point that (probably) causes the leak. This makes error analysis a lot simpler, and is also valuable for regression-testing footprint usage. >> >> Some people wished for a way to not end with a fatal error but to mimic a native OOM (causing os::malloc to return NULL). This would allow us to test resilience in the face of native OOMs, among other things. >> >> ### Patch >> >> - Expands the `MallocLimit` option syntax, allowing for an "oom mode" that mimics an oom: >> >> >> >> Global form: >> -XX:MallocLimit=[:] >> Category-specific form: >> -XX:MallocLimit=:[:][,:[:] ...] >> Examples: >> -XX:MallocLimit=3g >> -XX:MallocLimit=3g:oom >> -XX:MallocLimit=compiler:200m:oom >> >> >> - moves parsing of `-XX:MallocLimit` out of arguments.cpp into `mallocLimit.hpp/cpp`, and rewrites it. >> >> - changes when limits are checked. Before, the limits were checked *after* the allocation that caused the threshold overflow. Now we check beforehand. >> >> - removes `MallocMaxTestWords`, replacing its uses with `MallocLimit` >> >> - adds new gtests and new jtreg tests >> >> - removes a bunch of jtreg tests which are now better served by the new gtests. >> >> - gives us more precise error messages upon reaching a limit. For example: >> >> before: >> >> # fatal error: MallocLimit: category "Compiler" reached limit (size: 20997680, limit: 20971520) >> >> >> now: >> >> # fatal error: MallocLimit: reached category "Compiler" limit (triggering allocation size: 1920B, allocated so far: 20505K, limit: 20480K) > > Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge; fix conflicts > - Feedback Gerard > - Revert strchrnul > - Copyrights > - Feedback Johan > - Merge > - Merge branch 'master' into JDK-8293313-NMT-fake-oom > - MallocLimit Looks good! Thank you for your work! ------------- Marked as reviewed by gziemski (Committer). PR: https://git.openjdk.org/jdk/pull/11371 From xliu at openjdk.org Fri Jan 27 17:36:17 2023 From: xliu at openjdk.org (Xin Liu) Date: Fri, 27 Jan 2023 17:36:17 GMT Subject: RFR: 8301136: Improve unlink() and unlink_all() of ResourceHashtableBase [v3] In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 13:46:31 GMT, Coleen Phillimore wrote: >> src/hotspot/share/utilities/resourceHash.hpp line 282: >> >>> 280: template >>> 281: void unlink(ITER* iter) { >>> 282: auto wrapper = [&](Node* const node, Node**& ptr) { >> >> I wanted unlink to be lambda enabled, not an unlink_impl. Can you just make unlink_all be something that provides a "return true" lambda and call unlink with that? > > Or rather, first have a patch to add unlink that takes a lambda and convert the uses to that. I don't see the motivation for this change. hi, @coleenp My primary goal is 'unlink_all()'. I can create a Simple Iterator and use unlink() to implement that, but it would be sub-optimal(eg. [jvmtiTagMapTable::clear](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/jvmtiTagMapTable.cpp#L71)). When I roll it, I just realize that there are common logic among unlink(), unlink_all() and dtor. 'unlink_impl' is a template. It's not an API here. We can provide a lambda version of 'unlink()' in a new JBS issue, but I don't think we need to replace it with unlink(Iter*) completely. Functor and Lambda have different advantages. Functor is more formal and can be stateful. eg. `PurgeUnloadedConstraints` is big and deserve indents and comments. 'ResolutionErrorDeleteIterate' captures 'ConstantPool* p' for do_entry(). Can we do this is a separate JBS? ------------- PR: https://git.openjdk.org/jdk/pull/12213 From stuefe at openjdk.org Fri Jan 27 18:02:24 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 27 Jan 2023 18:02:24 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v6] In-Reply-To: References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> Message-ID: On Fri, 27 Jan 2023 09:46:57 GMT, Thomas Stuefe wrote: >> Rework NMT `MallocLimit` to make it more useful for native OOM analysis. Also remove `MallocMaxTestWords`, which had been mostly redundant with NMT (for background, see JDK-8293292). >> >> >> ### Background >> >> Some months ago we had [JDK-8291919](https://bugs.openjdk.org/browse/JDK-8291919), a compiler regression that caused compiler arenas to grow boundlessly. Process was usually OOM-killed before we could take a look, so this was difficult to analyze. >> >> To improve analysis options, we added NMT *malloc limits* with [JDK-8291878](https://bugs.openjdk.org/browse/JDK-8291878). Malloc limits let us set one or multiple limits to malloc load. Surpassing a limit causes the VM to stop with a fatal error in the allocation function, giving us a hs-err file and a core right at the point that (probably) causes the leak. This makes error analysis a lot simpler, and is also valuable for regression-testing footprint usage. >> >> Some people wished for a way to not end with a fatal error but to mimic a native OOM (causing os::malloc to return NULL). This would allow us to test resilience in the face of native OOMs, among other things. >> >> ### Patch >> >> - Expands the `MallocLimit` option syntax, allowing for an "oom mode" that mimics an oom: >> >> >> >> Global form: >> -XX:MallocLimit=[:] >> Category-specific form: >> -XX:MallocLimit=:[:][,:[:] ...] >> Examples: >> -XX:MallocLimit=3g >> -XX:MallocLimit=3g:oom >> -XX:MallocLimit=compiler:200m:oom >> >> >> - moves parsing of `-XX:MallocLimit` out of arguments.cpp into `mallocLimit.hpp/cpp`, and rewrites it. >> >> - changes when limits are checked. Before, the limits were checked *after* the allocation that caused the threshold overflow. Now we check beforehand. >> >> - removes `MallocMaxTestWords`, replacing its uses with `MallocLimit` >> >> - adds new gtests and new jtreg tests >> >> - removes a bunch of jtreg tests which are now better served by the new gtests. >> >> - gives us more precise error messages upon reaching a limit. For example: >> >> before: >> >> # fatal error: MallocLimit: category "Compiler" reached limit (size: 20997680, limit: 20971520) >> >> >> now: >> >> # fatal error: MallocLimit: reached category "Compiler" limit (triggering allocation size: 1920B, allocated so far: 20505K, limit: 20480K) > > Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge; fix conflicts > - Feedback Gerard > - Revert strchrnul > - Copyrights > - Feedback Johan > - Merge > - Merge branch 'master' into JDK-8293313-NMT-fake-oom > - MallocLimit Thanks, Gerard! @jdksjolen are you fine with the updated version? ------------- PR: https://git.openjdk.org/jdk/pull/11371 From rkennke at openjdk.org Fri Jan 27 18:28:17 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 27 Jan 2023 18:28:17 GMT Subject: RFR: 8301248: Less side effects in InstanceRefKlass::trace_reference_gc In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 15:42:05 GMT, Erik ?sterlund wrote: > The InstanceRefKlass::trace_reference_gc function is called when using oop_iterate on a reference object. Since oop_iterate is a general iterator that can be used for anything, including verification code, it would be desirable for this code to not have subtle side effects. We currently apply load barriers which "fix" pointers in the heap. As a result, verification code that was meant to detect bugs, can end up fixing and hiding the bug. This CR aims to address this by limiting the logging to addresses, and not following them. Changes look reasonable to me. If I remember correctly, there have been issues with this code and Shenandoah in the past, but I don't quite remember what it was. Maybe it was the fact that barriers have been used there (because of ZGC?), and Shenandoah barriers did not like that? Not sure. Quite likely no longer an issue - at least I don't see how it could be -, but maybe run 'make test TEST=hotspot_gc_shenandoah' to be extra sure? ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.org/jdk/pull/12258 From duke at openjdk.org Fri Jan 27 18:31:50 2023 From: duke at openjdk.org (Scott Gibbons) Date: Fri, 27 Jan 2023 18:31:50 GMT Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v6] In-Reply-To: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com> References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com> Message-ID: <0oERFNuGS7s0R-naHhheLiPGTQvo7jHbTtR47LGOSE8=.1401d6bb-7095-425d-ad45-83fbed127c3c@github.com> > Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms. > > Encode performance: > **Old:** > > Benchmark (maxNumBytes) Mode Cnt Score Error Units > Base64Encode.testBase64Encode 1024 thrpt 3 4309.439 ? 2.632 ops/ms > > > **New:** > > Benchmark (maxNumBytes) Mode Cnt Score Error Units > Base64Encode.testBase64Encode 1024 thrpt 3 24211.397 ? 102.026 ops/ms > > > Decode performance: > **Old:** > > Benchmark (errorIndex) (lineSize) (maxNumBytes) Mode Cnt Score Error Units > Base64Decode.testBase64Decode 144 4 1024 thrpt 3 3961.768 ? 93.409 ops/ms > > **New:** > Benchmark (errorIndex) (lineSize) (maxNumBytes) Mode Cnt Score Error Units > Base64Decode.testBase64Decode 144 4 1024 thrpt 3 14738.051 ? 24.383 ops/ms Scott Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision: - Merge branch 'openjdk:master' into Base64-AVX2 - Merge branch 'openjdk:master' into Base64-AVX2 - Merge branch 'openjdk:master' into Base64-AVX2 - Merge branch 'Base64-AVX2' of https://github.com/asgibbons/jdk into Base64-AVX2 - Merge branch 'openjdk:master' into Base64-AVX2 - Address review comment - Remove whitespace - Fix wrong register usage - Working version of Base64 decode with AVX2 (4x perf improvement). No URL support - Merge branch 'Base64-AVX2' of https://github.com/asgibbons/jdk into Base64-AVX2 - ... and 3 more: https://git.openjdk.org/jdk/compare/ad44dd9d...3e66f7be ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12126/files - new: https://git.openjdk.org/jdk/pull/12126/files/98728555..3e66f7be Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=04-05 Stats: 18402 lines in 710 files changed: 4705 ins; 3233 del; 10464 mod Patch: https://git.openjdk.org/jdk/pull/12126.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12126/head:pull/12126 PR: https://git.openjdk.org/jdk/pull/12126 From iklam at openjdk.org Fri Jan 27 18:42:17 2023 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 27 Jan 2023 18:42:17 GMT Subject: RFR: 8301136: Improve unlink() and unlink_all() of ResourceHashtableBase [v3] In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 17:33:13 GMT, Xin Liu wrote: >> Or rather, first have a patch to add unlink that takes a lambda and convert the uses to that. I don't see the motivation for this change. > > hi, @coleenp > > My primary goal is 'unlink_all()'. I can create a Simple Iterator and use unlink() to implement that, but it would be sub-optimal(eg. [jvmtiTagMapTable::clear](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/jvmtiTagMapTable.cpp#L71)). When I roll it, I just realize that there are common logic among unlink(), unlink_all() and dtor. 'unlink_impl' is a template. It's not an API here. > > We can provide a lambda version of 'unlink()' in a new JBS issue, but I don't think we need to replace it with unlink(Iter*) completely. Functor and Lambda have different advantages. Functor is more formal and can be stateful. eg. > `PurgeUnloadedConstraints` is big and deserve indents and comments. 'ResolutionErrorDeleteIterate' captures 'ConstantPool* p' for do_entry(). Can we do this is a separate JBS? My request is to make the unlink APIs use the same design pattern as the iterate APIs. You should be able to use either lambda or a function object for doing the unlink. There should be no performance penalty either way because the C++ compiler can optimize all the noise out. ------------- PR: https://git.openjdk.org/jdk/pull/12213 From xliu at openjdk.org Fri Jan 27 19:27:43 2023 From: xliu at openjdk.org (Xin Liu) Date: Fri, 27 Jan 2023 19:27:43 GMT Subject: RFR: 8301136: Improve unlink() and unlink_all() of ResourceHashtableBase [v4] In-Reply-To: References: Message-ID: > 1. Apply the same idea of JDK-8300184 to unlink(). > 2. Because ResourceHashtableBase doesn't support copy assignment, client of it has to purge all elements first when it needs to assign it. We would like provide a specialized version called 'unlink_all()'. We don't need to update each node's _next in this case. We only nullify all buckets. > 3. This patch also provides a specialized version of unlink_all() for destructor. We don't even update buckets. it's dead anyway. Xin Liu has updated the pull request incrementally with one additional commit since the last revision: Use unlink_all() in JvmtiTagMapTable::clear. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12213/files - new: https://git.openjdk.org/jdk/pull/12213/files/2fa173c4..0e003bab Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12213&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12213&range=02-03 Stats: 13 lines in 2 files changed: 0 ins; 11 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12213.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12213/head:pull/12213 PR: https://git.openjdk.org/jdk/pull/12213 From stefank at openjdk.org Fri Jan 27 19:31:16 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 27 Jan 2023 19:31:16 GMT Subject: RFR: 8301248: Less side effects in InstanceRefKlass::trace_reference_gc In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 15:42:05 GMT, Erik ?sterlund wrote: > The InstanceRefKlass::trace_reference_gc function is called when using oop_iterate on a reference object. Since oop_iterate is a general iterator that can be used for anything, including verification code, it would be desirable for this code to not have subtle side effects. We currently apply load barriers which "fix" pointers in the heap. As a result, verification code that was meant to detect bugs, can end up fixing and hiding the bug. This CR aims to address this by limiting the logging to addresses, and not following them. Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12258 From eosterlund at openjdk.org Fri Jan 27 19:41:19 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 27 Jan 2023 19:41:19 GMT Subject: RFR: 8301248: Less side effects in InstanceRefKlass::trace_reference_gc In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 18:25:55 GMT, Roman Kennke wrote: >> The InstanceRefKlass::trace_reference_gc function is called when using oop_iterate on a reference object. Since oop_iterate is a general iterator that can be used for anything, including verification code, it would be desirable for this code to not have subtle side effects. We currently apply load barriers which "fix" pointers in the heap. As a result, verification code that was meant to detect bugs, can end up fixing and hiding the bug. This CR aims to address this by limiting the logging to addresses, and not following them. > > Changes look reasonable to me. If I remember correctly, there have been issues with this code and Shenandoah in the past, but I don't quite remember what it was. Maybe it was the fact that barriers have been used there (because of ZGC?), and Shenandoah barriers did not like that? Not sure. Quite likely no longer an issue - at least I don't see how it could be -, but maybe run 'make test TEST=hotspot_gc_shenandoah' to be extra sure? Thanks for the review @rkennke and @stefank! And yeah IIRC the Shenandoah issue had something to do with load barrier triggering relocation, and the new object being after TAMS, messing up some reference processing code as some referent then became live while it should have been dead really. ------------- PR: https://git.openjdk.org/jdk/pull/12258 From amenkov at openjdk.org Fri Jan 27 20:46:17 2023 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 27 Jan 2023 20:46:17 GMT Subject: RFR: JDK-8301076: Replace NULL with nullptr in share/prims/ In-Reply-To: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> References: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> Message-ID: <1Q1fwnHYAz969STCOnR9otQ7QUJhxgeLzSEuWXQCjEk=.062759a8-2658-47bb-9ef9-ce7d02e9d309@github.com> On Wed, 25 Jan 2023 11:47:05 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/prims/. 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! src/hotspot/share/prims/jvmtiImpl.hpp line 553: > 551: > 552: // Utility macro that checks for null pointers: > 553: #NULL nullptr_CHECK(X, Y) if ((X) == nullptr) { return (Y); } causes compilation error ------------- PR: https://git.openjdk.org/jdk/pull/12188 From redestad at openjdk.org Fri Jan 27 22:24:23 2023 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 27 Jan 2023 22:24:23 GMT Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v6] In-Reply-To: <0oERFNuGS7s0R-naHhheLiPGTQvo7jHbTtR47LGOSE8=.1401d6bb-7095-425d-ad45-83fbed127c3c@github.com> References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com> <0oERFNuGS7s0R-naHhheLiPGTQvo7jHbTtR47LGOSE8=.1401d6bb-7095-425d-ad45-83fbed127c3c@github.com> Message-ID: On Fri, 27 Jan 2023 18:31:50 GMT, Scott Gibbons wrote: >> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms. >> >> Encode performance: >> **Old:** >> >> Benchmark (maxNumBytes) Mode Cnt Score Error Units >> Base64Encode.testBase64Encode 1024 thrpt 3 4309.439 ? 2.632 ops/ms >> >> >> **New:** >> >> Benchmark (maxNumBytes) Mode Cnt Score Error Units >> Base64Encode.testBase64Encode 1024 thrpt 3 24211.397 ? 102.026 ops/ms >> >> >> Decode performance: >> **Old:** >> >> Benchmark (errorIndex) (lineSize) (maxNumBytes) Mode Cnt Score Error Units >> Base64Decode.testBase64Decode 144 4 1024 thrpt 3 3961.768 ? 93.409 ops/ms >> >> **New:** >> Benchmark (errorIndex) (lineSize) (maxNumBytes) Mode Cnt Score Error Units >> Base64Decode.testBase64Decode 144 4 1024 thrpt 3 14738.051 ? 24.383 ops/ms > > Scott Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision: > > - Merge branch 'openjdk:master' into Base64-AVX2 > - Merge branch 'openjdk:master' into Base64-AVX2 > - Merge branch 'openjdk:master' into Base64-AVX2 > - Merge branch 'Base64-AVX2' of https://github.com/asgibbons/jdk into Base64-AVX2 > - Merge branch 'openjdk:master' into Base64-AVX2 > - Address review comment > - Remove whitespace > - Fix wrong register usage > - Working version of Base64 decode with AVX2 (4x perf improvement). No URL support > - Merge branch 'Base64-AVX2' of https://github.com/asgibbons/jdk into Base64-AVX2 > - ... and 3 more: https://git.openjdk.org/jdk/compare/50dc1196...3e66f7be src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2159: > 2157: } > 2158: > 2159: address StubGenerator::base64_AVX2_tables_addr() { A casual reader might wonder why there's 3 other avx2-tables and then this, so for readability it'd be nice to add "decode" to the name of this new table. src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2643: > 2641: // Handle isURL / MIME?!?! r12 is used for length calculation (from out) > 2642: // > 2643: // rbx is out, r12 is saved out, rdx is size, rsi is src It seems that on windows `r12` is in use, see line 2323. GHA seem to be having some trouble finishing Windows testing on time - could there be some issue here? src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2647: > 2645: //////////////////////////////////////////// > 2646: > 2647: // *************** NEEDS TO BE FIXED ************ While it's fine to leave implementation of `getMimeDecoder` and `getUrlDecoder` for a follow-up, I think these comments needs to be cleaned up. E.g. a follow-up RFE filed and referenced. src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2651: > 2649: __ jcc(Assembler::notZero, L_tailProc); > 2650: > 2651: __ cmpl(length, 44); Perform `length` checks first to avoid unnecessary branches on small inputs? Ideal might be to move this length check up just before the `_cmpl(length, 128)` in the AVX-512 block, so that if `AVX=3` short inputs branch directly to the scalar tail procedure without jumping around. This might also apply to the encode stub, though that's pre-existing. src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2673: > 2671: __ vmovdqu(xmm13, Address(r13, 0xc8)); > 2672: __ vmovdqu(xmm12, Address(r13, 0x08)); > 2673: __ jmp(L_enterLoop); This got me curious (sorry!) and maybe there's something going on here that I'm not getting... But why have you split the loop apart and jump into the middle of it? It'd seem not doing this would be more straightforward, with no difference semantically and one less jump? (align32 should just translate to a narrow nop instruction, if anything) ------------- PR: https://git.openjdk.org/jdk/pull/12126 From redestad at openjdk.org Fri Jan 27 22:24:25 2023 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 27 Jan 2023 22:24:25 GMT Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v6] In-Reply-To: References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com> <0oERFNuGS7s0R-naHhheLiPGTQvo7jHbTtR47LGOSE8=.1401d6bb-7095-425d-ad45-83fbed127c3c@github.com> Message-ID: On Fri, 27 Jan 2023 21:36:29 GMT, Claes Redestad wrote: >> Scott Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into Base64-AVX2 >> - Merge branch 'openjdk:master' into Base64-AVX2 >> - Merge branch 'openjdk:master' into Base64-AVX2 >> - Merge branch 'Base64-AVX2' of https://github.com/asgibbons/jdk into Base64-AVX2 >> - Merge branch 'openjdk:master' into Base64-AVX2 >> - Address review comment >> - Remove whitespace >> - Fix wrong register usage >> - Working version of Base64 decode with AVX2 (4x perf improvement). No URL support >> - Merge branch 'Base64-AVX2' of https://github.com/asgibbons/jdk into Base64-AVX2 >> - ... and 3 more: https://git.openjdk.org/jdk/compare/50dc1196...3e66f7be > > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2643: > >> 2641: // Handle isURL / MIME?!?! r12 is used for length calculation (from out) >> 2642: // >> 2643: // rbx is out, r12 is saved out, rdx is size, rsi is src > > It seems that on windows `r12` is in use, see line 2323. GHA seem to be having some trouble finishing Windows testing on time - could there be some issue here? Nevermind, you're not using r12 and GHA Windows testing is green now. ------------- PR: https://git.openjdk.org/jdk/pull/12126 From xliu at openjdk.org Fri Jan 27 23:16:52 2023 From: xliu at openjdk.org (Xin Liu) Date: Fri, 27 Jan 2023 23:16:52 GMT Subject: RFR: 8301136: Improve unlink() and unlink_all() of ResourceHashtableBase [v5] In-Reply-To: References: Message-ID: > 1. Apply the same idea of JDK-8300184 to unlink(). > 2. Because ResourceHashtableBase doesn't support copy assignment, client of it has to purge all elements first when it needs to assign it. We would like provide a specialized version called 'unlink_all()'. We don't need to update each node's _next in this case. We only nullify all buckets. > 3. This patch also provides a specialized version of unlink_all() for destructor. We don't even update buckets. it's dead anyway. Xin Liu has updated the pull request incrementally with one additional commit since the last revision: Add lambda API unlink(Function f) per reviewers' request. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12213/files - new: https://git.openjdk.org/jdk/pull/12213/files/0e003bab..086750e4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12213&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12213&range=03-04 Stats: 56 lines in 2 files changed: 55 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12213.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12213/head:pull/12213 PR: https://git.openjdk.org/jdk/pull/12213 From xliu at openjdk.org Fri Jan 27 23:20:18 2023 From: xliu at openjdk.org (Xin Liu) Date: Fri, 27 Jan 2023 23:20:18 GMT Subject: RFR: 8301136: Improve unlink() and unlink_all() of ResourceHashtableBase [v2] In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 20:51:36 GMT, Ioi Lam wrote: >> hi, Lam >> Are you suggesting to use lambda+iterate() to implement unlink_all()? If we use `bucket` and `node` captured by the lambda, I think it's possible. However, I think the resultant code is much less readable. Is it worth it? >> >> thanks, >> --lx > > I mean we should implement a basic version of unlink() like this > > > template > void unlink(Function function) const { ... } > > > Then `unlink_all` and `template void unlink(ITER* iter)` can call into the above template. hi, @iklam @coleenp, I added `unlink(Function f)` per your request. Could you take a look? ------------- PR: https://git.openjdk.org/jdk/pull/12213 From dcubed at openjdk.org Fri Jan 27 23:31:21 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 27 Jan 2023 23:31:21 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v5] In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 12:34:18 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Renaissance >> >> >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 86 commits: > > - Merge branch 'master' into JDK-8291556-v2 > - Revert UseFastLocking to default to off > - Change log message inflate(locked) -> inflate(has_locker) > - Properly set ZF on anon-check path; avoid some conditional branches > - Use testb when testing for anon owner in fast-path > - Merge branch 'master' into JDK-8291555-v2 > - In x86_32 C2 fast_lock(), CAS thread directly, instead of CASing stack-pointer and then storing thread > - x86 part of optimization to check for anon owner > - Optimize the check-for-anon-owner fast-path > - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2 > - ... and 76 more: https://git.openjdk.org/jdk/compare/da80e7a4...784b361c This is a partial review of this PR. I've only reviewed the following files so far: src/hotspot/share/oops/markWord.hpp src/hotspot/share/oops/oop.cpp src/hotspot/share/runtime/javaThread.hpp src/hotspot/share/runtime/lockStack.cpp src/hotspot/share/runtime/lockStack.cpp src/hotspot/share/runtime/objectMonitor.cpp src/hotspot/share/runtime/synchronizer.cpp src/hotspot/share/runtime/thread.cpp src/hotspot/share/runtime/threads.cpp src/hotspot/share/runtime/threads.hpp I've also created a patch with editorial changes. Please see: https://github.com/openjdk/jdk/pull/12271 src/hotspot/share/runtime/synchronizer.cpp line 1301: > 1299: // We could always eliminate polling by parking the thread on some auxiliary list. > 1300: // NOTE: We need to check UseFastLocking here, because with fast-locking, the header > 1301: // may legitimately be zero: cleared lock-bits and all upper header bits zero. The `markWord::INFLATING()` value was picked to be zero because the header could never be zero except for the inflating case. With fast-locking, in the locked case with no hashcode, the header can be all zeros. Hmmm... gotta mull on that one... fast-locking does not use the `markWord::INFLATING()`, but that protocol exists with the stack-locking implementation to prevent races. Here's the gory comment from the "Case stack-locked" portion of `ObjectSynchronizer::inflate()`: // We've successfully installed INFLATING (0) into the mark-word. // This is the only case where 0 will appear in a mark-word. // Only the singular thread that successfully swings the mark-word // to 0 can perform (or more precisely, complete) inflation. // // Why do we CAS a 0 into the mark-word instead of just CASing the // mark-word from the stack-locked value directly to the new inflated state? // Consider what happens when a thread unlocks a stack-locked object. // It attempts to use CAS to swing the displaced header value from the // on-stack BasicLock back into the object header. Recall also that the // header value (hash code, etc) can reside in (a) the object header, or // (b) a displaced header associated with the stack-lock, or (c) a displaced // header in an ObjectMonitor. The inflate() routine must copy the header // value from the BasicLock on the owner's stack to the ObjectMonitor, all // the while preserving the hashCode stability invariants. If the owner // decides to release the lock while the value is 0, the unlock will fail // and control will eventually pass from slow_exit() to inflate. The owner // will then spin, waiting for the 0 value to disappear. Put another way, // the 0 causes the owner to stall if the owner happens to try to // drop the lock (restoring the header from the BasicLock to the object) // while inflation is in-progress. This protocol avoids races that might // would otherwise permit hashCode values to change or "flicker" for an object. // Critically, while object->mark is 0 mark.displaced_mark_helper() is stable. // 0 serves as a "BUSY" inflate-in-progress indicator. So how does fast-locking avoid hashCode value flickering for an object when there are races between exiting an monitor and inflation? With fast-locking the owner of the monitor does not stall due to an INFLATING value being present in the header so the owner thread will race with the inflating thread. However, unlike with stack-locking, the owner thread in fast-locking is not restoring a saved header value from the BasicLock to the object's header; it is simply changing the `locked_value` to the `unlocked_value` in the lower two bits. If there's a hashCode in the header, then that hashCode remains untouched. The other callers of `read_stable_mark()`: `ObjectSynchronizer::FastHashCode()` - Does not need to stall in `read_stable_mark()` due to a racing inflation because the hashCode value will either be found in the header or in the ObjectMonitor and it will be the same value in both locations. `ObjectSynchronizer::current_thread_holds_lock()` - Does not need to stall in `read_stable_mark()` due to a racing inflation because the current thread either owns the lock or it does not and that state cannot change while the current thread is executing this function. `ObjectSynchronizer::get_lock_owner()` - I think this function does need to stall in `read_stable_mark()` due to a racing inflation. If the calling thread in this case gets a header value where `mark.is_fast_locked() == true`, then it will search the ThreadsList for the thread that has the object on its lock stack. If thread that's inflating the lock is the owner of the lock, then it will remove the object from its lock stack after it has changed the owner in the ObjectMonitor to itself. If that happens before the `get_lock_owner()` calling thread reaches the owning thread in its ThreadsList search, then the `get_lock_owner()` calling thread won't find the owner of the lock. If the `get_lock_owner()` calling thread happens to "know" that the lock is supposed to be owned by _someone_, then the inconsistency could be detected. It might even be possible to write a test to detect this. I'll mull on that a bit... `ObjectSynchronizer::inflate()` - Only calls read_stable_mark() when stack-locking is in use and the `INFLATING()` value is seen. Otherwise, `object->mark_acquire()` is used for the read of the header at the top of the `inflate()` loop and all the code that updates the object's mark use `cas_set_mark()` to only change the object's mark when the current value matches the expected current value. Otherwise, we loop around and try again. src/hotspot/share/runtime/synchronizer.cpp line 1336: > 1334: // Success! Return inflated monitor. > 1335: if (own) { > 1336: assert(current->is_Java_thread(), "must be: checked in is_lock_owned()"); `is_lock_owned()` currently does this: static bool is_lock_owned(Thread* thread, oop obj) { assert(UseFastLocking, "only call this with fast-locking enabled"); return thread->is_Java_thread() ? reinterpret_cast(thread)->lock_stack().contains(obj) : false; } so I would not say "checked in is_locked_owned()" since `is_locked_owned()` does not enforce that the caller is a JavaThread. ------------- Changes requested by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/10907 From dcubed at openjdk.org Fri Jan 27 23:31:26 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 27 Jan 2023 23:31:26 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v4] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 20:10:21 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Renaissance >> >> >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Revert UseFastLocking to default to off src/hotspot/share/oops/markWord.hpp line 183: > 181: } > 182: markWord set_fast_locked() const { > 183: return markWord(value() & ~lock_mask_in_place); Perhaps add a comment above L183: // Clear the lock_mask_in_place bits to set locked_value: src/hotspot/share/runtime/lockStack.cpp line 34: > 32: > 33: LockStack::LockStack() : > 34: _base(UseFastLocking && !UseHeavyMonitors ? NEW_C_HEAP_ARRAY(oop, INITIAL_CAPACITY, mtSynchronizer) : NULL), Okay so `UseFastLocking && UseHeavyMonitors`, then we don't need the lock stack. src/hotspot/share/runtime/lockStack.inline.hpp line 81: > 79: } > 80: } > 81: validate("post-contains"); You only do the `validate("post-contains")` call when `false` is returned. Why not also validate for the `true` branch? src/hotspot/share/runtime/objectMonitor.cpp line 1141: > 1139: assert(_recursions == 0, "invariant"); > 1140: set_owner_from_BasicLock(cur, current); // Convert from BasicLock* to Thread*. > 1141: _recursions = 0; Hmmm... fast-locking also has two different ways that a thread can own an ObjectMonitor: 1) owner == thread* and 2) owner == anonymous and lock on the owning thread's lock stack. If `UseFastLocking` is enabled and `ObjectMonitor::exit()` is called by a thread that owns the ObjectMonitor in the secondary way, then this code will fail the assert on L1158 in non-product bits. There needs to be check to see if the current thread owns the fast-lock and then update the owner in the ObjectMonitor after asserting about recursions and resetting recursions to 0. src/hotspot/share/runtime/synchronizer.cpp line 568: > 566: monitor->set_owner_from_anonymous(current); > 567: monitor->exit(current); > 568: } Hmmm... We're in `ObjectSynchronizer::exit()` so we should be the owner of the ObjectMonitor so I'm not yet sure what "Another thread beat us" means. XXX ------------- PR: https://git.openjdk.org/jdk/pull/10907 From xliu at openjdk.org Sat Jan 28 00:06:18 2023 From: xliu at openjdk.org (Xin Liu) Date: Sat, 28 Jan 2023 00:06:18 GMT Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof [v3] In-Reply-To: <6XauuplEHiyDoz21XH5fWW66JN31ldZ5rTv9qyizgLU=.dde4c07e-1fa7-469d-b5a7-2b8f16e9bc50@github.com> References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com> <1VvY0OUOTV6QoOICCC7D-bossOFuNcElgxJwOK0ATcg=.4d805893-07a4-4c0c-b9c0-82a2ee3be0cf@github.com> <1hEloz4xpYz6Ofo_RItjyhbSYfv8OY_f11SSvCgFjL8=.8c3d3051-54fb-4436-be68-7b493ddb6af5@github.com> <1vFS7xsbqeW1z1TrrnwCuHCwfMbD54xglwPZP0kwNMc=.a495a2c5-501c-4151-bc7c-590b5c05b5fd@github.com> <6XauuplEHiyDoz21XH5fWW66JN31ldZ5rTv9qyizgLU=.dde4c07e-1fa7-469d-b5a7-2b8f16e9bc50@github.com> Message-ID: <9dsr0Sptq5SecHkc1jZLzas3_rBdlEHwhJgo4VjBnTU=.2f7b4377-f62a-4214-abbb-8479ccc73a41@github.com> On Tue, 24 Jan 2023 23:23:24 GMT, Kim Barrett wrote: > In order to access through an object, the object must be correctly aligned for its type, else UB. hi, @kimbarrett, Thanks you for letting me know `alignof`. I know the concept of 'nature alignment'. an object is aligned to its size. The rule is enforced by C/C++ compiler. Is it really UB if I violate it? In this case, sizeof(Message) is 64. I don't think we have to put an instance of Message at an address which can be divided by 64. In particular, Message is POD. We would like to have compact 'buffer'. ------------- PR: https://git.openjdk.org/jdk/pull/11761 From iklam at openjdk.org Sat Jan 28 01:54:20 2023 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 28 Jan 2023 01:54:20 GMT Subject: RFR: 8301136: Improve unlink() and unlink_all() of ResourceHashtableBase [v5] In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 23:16:52 GMT, Xin Liu wrote: >> 1. Apply the same idea of JDK-8300184 to unlink(). >> 2. Because ResourceHashtableBase doesn't support copy assignment, client of it has to purge all elements first when it needs to assign it. We would like provide a specialized version called 'unlink_all()'. We don't need to update each node's _next in this case. We only nullify all buckets. >> 3. This patch also provides a specialized version of unlink_all() for destructor. We don't even update buckets. it's dead anyway. > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > Add lambda API unlink(Function f) per reviewers' request. I've looked at the last version ([086750e](https://github.com/openjdk/jdk/pull/12213/commits/086750e46a4abb7115c2ff0ea49801c17df3981e)) in detail and I can understand why your implementation for `unlink` is so much more complex than `iterate`. The fundamental reason is sometimes we allow special clean up of the value (the old `unlink` API), while other times we don't (the destructor, and the new `iterate_all` API). I think we need to rewrite ResourceHashtable to allow automatic and safe disposal of both the keys and the values. I've filed [JDK-8301296](https://bugs.openjdk.org/browse/JDK-8301296). I would suggest putting this PR on hold until we come up with a new design that addresses the above issue. ------------- PR: https://git.openjdk.org/jdk/pull/12213 From yadongwang at openjdk.org Sat Jan 28 02:20:27 2023 From: yadongwang at openjdk.org (Yadong Wang) Date: Sat, 28 Jan 2023 02:20:27 GMT Subject: Integrated: 8299844: RISC-V: Implement _onSpinWait intrinsic In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 09:52:40 GMT, Yadong Wang wrote: > Implement _onSpinWait() intrinsic for RISC-V, and it can be implemented by using PAUSE instruction from Zihintpause Extension, which is ratified and a mandatory extension of RVA22U64 (https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#rva22u64-mandatory-extensions). > Software can use the PAUSE instruction to reduce energy consumption while executing spinwait > code sequences (https://github.com/riscv/riscv-isa-manual/blob/master/src/zihintpause.tex). > > Add a test case of test/hotspot/jtreg/compiler/onSpinWait/TestOnSpinWaitRISCV64.java, passed on QEMU. This pull request has now been integrated. Changeset: af564e46 Author: Yadong Wang Committer: Fei Yang URL: https://git.openjdk.org/jdk/commit/af564e46b006fcd57ec7391cd1438b3b9311b1d6 Stats: 133 lines in 8 files changed: 120 ins; 0 del; 13 mod 8299844: RISC-V: Implement _onSpinWait intrinsic Reviewed-by: fjiang, fyang, luhenry ------------- PR: https://git.openjdk.org/jdk/pull/11921 From fyang at openjdk.org Sat Jan 28 02:58:16 2023 From: fyang at openjdk.org (Fei Yang) Date: Sat, 28 Jan 2023 02:58:16 GMT Subject: RFR: 8301067: RISC-V: better error message when reporting unsupported satp modes In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 09:39:46 GMT, Feilong Jiang wrote: > Add more detailed information to the error log when reporting unsupported stap modes. > Currently, RISC-V port only supports up to sv48. Don't forget to update the copyright years. ------------- PR: https://git.openjdk.org/jdk/pull/12247 From fjiang at openjdk.org Sat Jan 28 03:14:47 2023 From: fjiang at openjdk.org (Feilong Jiang) Date: Sat, 28 Jan 2023 03:14:47 GMT Subject: RFR: 8301067: RISC-V: better error message when reporting unsupported satp modes [v2] In-Reply-To: References: Message-ID: <2NahsNo8EI8V_CDlWLJFn_JXFGeok8dFPwHg-gn7egc=.a6be71e9-58e5-4260-8328-f7f153da733f@github.com> > Add more detailed information to the error log when reporting unsupported stap modes. > Currently, RISC-V port only supports up to sv48. Feilong Jiang 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 better_error_info - add more information when reporting unsuppoted satp modes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12247/files - new: https://git.openjdk.org/jdk/pull/12247/files/8fa7d999..6224eaef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12247&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12247&range=00-01 Stats: 5608 lines in 302 files changed: 891 ins; 156 del; 4561 mod Patch: https://git.openjdk.org/jdk/pull/12247.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12247/head:pull/12247 PR: https://git.openjdk.org/jdk/pull/12247 From fjiang at openjdk.org Sat Jan 28 03:17:16 2023 From: fjiang at openjdk.org (Feilong Jiang) Date: Sat, 28 Jan 2023 03:17:16 GMT Subject: RFR: 8301067: RISC-V: better error message when reporting unsupported satp modes [v2] In-Reply-To: References: Message-ID: On Sat, 28 Jan 2023 02:55:30 GMT, Fei Yang wrote: > Don't forget to update the copyright years. I have merged master and now the copyright looks updated. ------------- PR: https://git.openjdk.org/jdk/pull/12247 From fyang at openjdk.org Sat Jan 28 03:32:18 2023 From: fyang at openjdk.org (Fei Yang) Date: Sat, 28 Jan 2023 03:32:18 GMT Subject: RFR: 8301067: RISC-V: better error message when reporting unsupported satp modes [v2] In-Reply-To: <2NahsNo8EI8V_CDlWLJFn_JXFGeok8dFPwHg-gn7egc=.a6be71e9-58e5-4260-8328-f7f153da733f@github.com> References: <2NahsNo8EI8V_CDlWLJFn_JXFGeok8dFPwHg-gn7egc=.a6be71e9-58e5-4260-8328-f7f153da733f@github.com> Message-ID: On Sat, 28 Jan 2023 03:14:47 GMT, Feilong Jiang wrote: >> Add more detailed information to the error log when reporting unsupported stap modes. >> Currently, RISC-V port only supports up to sv48. > > Feilong Jiang 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 better_error_info > - add more information when reporting unsuppoted satp modes Marked as reviewed by fyang (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12247 From stuefe at openjdk.org Sat Jan 28 06:37:01 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 28 Jan 2023 06:37:01 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v7] In-Reply-To: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> Message-ID: > Rework NMT `MallocLimit` to make it more useful for native OOM analysis. Also remove `MallocMaxTestWords`, which had been mostly redundant with NMT (for background, see JDK-8293292). > > > ### Background > > Some months ago we had [JDK-8291919](https://bugs.openjdk.org/browse/JDK-8291919), a compiler regression that caused compiler arenas to grow boundlessly. Process was usually OOM-killed before we could take a look, so this was difficult to analyze. > > To improve analysis options, we added NMT *malloc limits* with [JDK-8291878](https://bugs.openjdk.org/browse/JDK-8291878). Malloc limits let us set one or multiple limits to malloc load. Surpassing a limit causes the VM to stop with a fatal error in the allocation function, giving us a hs-err file and a core right at the point that (probably) causes the leak. This makes error analysis a lot simpler, and is also valuable for regression-testing footprint usage. > > Some people wished for a way to not end with a fatal error but to mimic a native OOM (causing os::malloc to return NULL). This would allow us to test resilience in the face of native OOMs, among other things. > > ### Patch > > - Expands the `MallocLimit` option syntax, allowing for an "oom mode" that mimics an oom: > > > > Global form: > -XX:MallocLimit=[:] > Category-specific form: > -XX:MallocLimit=:[:][,:[:] ...] > Examples: > -XX:MallocLimit=3g > -XX:MallocLimit=3g:oom > -XX:MallocLimit=compiler:200m:oom > > > - moves parsing of `-XX:MallocLimit` out of arguments.cpp into `mallocLimit.hpp/cpp`, and rewrites it. > > - changes when limits are checked. Before, the limits were checked *after* the allocation that caused the threshold overflow. Now we check beforehand. > > - removes `MallocMaxTestWords`, replacing its uses with `MallocLimit` > > - adds new gtests and new jtreg tests > > - removes a bunch of jtreg tests which are now better served by the new gtests. > > - gives us more precise error messages upon reaching a limit. For example: > > before: > > # fatal error: MallocLimit: category "Compiler" reached limit (size: 20997680, limit: 20971520) > > > now: > > # fatal error: MallocLimit: reached category "Compiler" limit (triggering allocation size: 1920B, allocated so far: 20505K, limit: 20480K) Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - merge and fix conflicts - Merge; fix conflicts - Feedback Gerard - Revert strchrnul - Copyrights - Feedback Johan - Merge - Merge branch 'master' into JDK-8293313-NMT-fake-oom - MallocLimit ------------- Changes: https://git.openjdk.org/jdk/pull/11371/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11371&range=06 Stats: 1010 lines in 21 files changed: 653 ins; 257 del; 100 mod Patch: https://git.openjdk.org/jdk/pull/11371.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11371/head:pull/11371 PR: https://git.openjdk.org/jdk/pull/11371 From kbarrett at openjdk.org Sat Jan 28 12:48:17 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 28 Jan 2023 12:48:17 GMT Subject: RFR: 8301244: Replace legacy pragma implementations in HotSpot In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 13:40:20 GMT, Julian Waters wrote: > HotSpot has a few legacy implementations of pragmas in some of its macros, they should be cleaned up and instead use a shared new PRAGMA macro available to all platforms Sorry, but I'm not seeing the benefit of making this change. The new shared PRAGMA macro even seems like a negative to me. If there were more kinds of pragmas we were defining for GCC-style compilers then I would probably support a GCC-specific stringizing support macro, but I don't see any benefit to forcing the VS platform to stringize. src/hotspot/share/utilities/macros.hpp line 33: > 31: // For when Pragmas need to be reliably nested in macros. Also handles > 32: // quotation marks, so use sites are not required to pass string literals > 33: #define PRAGMA(str) _Pragma(#str) This shouldn't be here. A file could include only compilerWarnings.hpp and not this file, and not be able to use pragma macros provided by compilerWarnings.hpp. ------------- PR: https://git.openjdk.org/jdk/pull/12255 From kbarrett at openjdk.org Sat Jan 28 13:16:16 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 28 Jan 2023 13:16:16 GMT Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof [v3] In-Reply-To: <9dsr0Sptq5SecHkc1jZLzas3_rBdlEHwhJgo4VjBnTU=.2f7b4377-f62a-4214-abbb-8479ccc73a41@github.com> References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com> <1VvY0OUOTV6QoOICCC7D-bossOFuNcElgxJwOK0ATcg=.4d805893-07a4-4c0c-b9c0-82a2ee3be0cf@github.com> <1hEloz4xpYz6Ofo_RItjyhbSYfv8OY_f11SSvCgFjL8=.8c3d3051-54fb-4436-be68-7b493ddb6af5@github.com> <1vFS7xsbqeW1z1TrrnwCuHCwfMbD54xglwPZP0kwNMc=.a495a2c5-501c-4151-bc7c-590b5c05b5fd@github.com> <6XauuplEHiyDoz21XH5fWW66JN31ldZ5rTv9qyizgLU=.dde4c07e-1fa7-469d-b5a7-2b8f16e9bc50@github.com> <9dsr0Sptq5SecHkc1jZLzas3_rBdlEHwhJgo4VjBnTU=.2f7b4377-f62a-4214-abbb-8479ccc73a41@github.com> Message-ID: On Sat, 28 Jan 2023 00:03:41 GMT, Xin Liu wrote: > > In order to access through an object, the object must be correctly aligned for its type, else UB. > > hi, @kimbarrett, Thanks you for letting me know `alignof`. > > I know the concept of 'nature alignment'. an object is aligned to its size. The rule is enforced by C/C++ compiler. Is it really UB if I violate it? > > In this case, sizeof(Message) is 64. I don't think we have to put an instance of Message at an address which can be divided by 64. In particular, Message is POD. We would like to have compact 'buffer'. Objects are not aligned to their size. Alignment and size are independent properties of a type. The alignment of fundamental types is determined by ABI and processor constraints. It's common for fundamental types to have alignment requirements equal to their size. Compound types generally (barring use of `alignas` specifiers and maybe other corner cases I'm forgetting) have the maximum alignment of their components, to ensure the components are properly aligned. This may result in the compiler adding padding between class members. And yes, misaligned accesses are UB. BTW, `Message` is not POD. It might be standard-layout (I haven't checked). ------------- PR: https://git.openjdk.org/jdk/pull/11761 From jwaters at openjdk.org Sat Jan 28 13:23:25 2023 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 28 Jan 2023 13:23:25 GMT Subject: RFR: 8301244: Replace legacy pragma implementations in HotSpot [v2] In-Reply-To: References: Message-ID: <5Ui-gGX6jgoF14dhXE_-GcPIOWjzUEZw9hAWYx8Sq4o=.1c0494f6-ad18-45b8-a192-dd874193877c@github.com> > HotSpot has a few legacy implementations of pragmas in some of its macros, they should be cleaned up and instead use a shared new PRAGMA macro available to all platforms Julian Waters has updated the pull request incrementally with two additional commits since the last revision: - Rename to PRAGMA for gcc - Revert macros.hpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12255/files - new: https://git.openjdk.org/jdk/pull/12255/files/f2734f65..2e5e6a8f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12255&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12255&range=00-01 Stats: 7 lines in 2 files changed: 3 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12255.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12255/head:pull/12255 PR: https://git.openjdk.org/jdk/pull/12255 From kbarrett at openjdk.org Sat Jan 28 13:30:18 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 28 Jan 2023 13:30:18 GMT Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof [v6] In-Reply-To: References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com> <_PQgMSbDp6vCHD8sBrhaazfuqSgxb0gsVZN8dDFZZ0w=.32440e3d-4c8d-42fb-aa25-ad11537b90df@github.com> Message-ID: On Tue, 24 Jan 2023 09:16:53 GMT, Julian Waters wrote: >> doc/hotspot-style.md line 580: >> >>> 578: Certain restrictions apply to the declarations provided by ``. >>> 579: >>> 580: * The `alignof` operator should be utilized rather than `std::alignment_of<>`. >> >> s/utilized/used/ >> https://scientistseessquirrel.wordpress.com/2019/04/16/for-the-love-of-all-that-is-holy-stop-writing-utilize/ >> :) > > And here I was thinking this would sound more professional :P > > Speaking of which, could I include a condensed and shortened version of this part from our discussion above? I've left it out in the meantime but just wanted to ask in case >> std::alignment_of<> could be used in advanced metaprogramming contexts > involving higher order metafunctions. We don't do that sort of thing much at > all in HotSpot. If someone finds a place where std::alignment_of<> might be > better, we can revisit its status. I don't think that's needed. We already have a blanket statement regarding violations: "Failure to follow these guidelines may lead to discussion during code reviews, if not outright rejection of a change." Anyone attempting to add such code is presumably capable of defending it. ------------- PR: https://git.openjdk.org/jdk/pull/11761 From jwaters at openjdk.org Sat Jan 28 13:31:22 2023 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 28 Jan 2023 13:31:22 GMT Subject: RFR: 8301244: Replace legacy pragma implementations in HotSpot [v3] In-Reply-To: References: Message-ID: > HotSpot has a few legacy implementations of pragmas in some of its macros in compilerWarnings.hpp, they should be cleaned up and use a more modern approach. Rename PRAGMA macro in compilerWarnings_gcc.hpp as well since it can be used for more than just compiler warnings Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Reorder ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12255/files - new: https://git.openjdk.org/jdk/pull/12255/files/2e5e6a8f..84a79add Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12255&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12255&range=01-02 Stats: 7 lines in 1 file changed: 5 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12255.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12255/head:pull/12255 PR: https://git.openjdk.org/jdk/pull/12255 From jwaters at openjdk.org Sat Jan 28 13:35:11 2023 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 28 Jan 2023 13:35:11 GMT Subject: RFR: 8301244: Replace legacy pragma implementations in HotSpot [v4] In-Reply-To: References: Message-ID: > HotSpot has a few legacy implementations of pragmas in some of its macros in compilerWarnings.hpp, they should be cleaned up and use a more modern approach. Rename PRAGMA macro in compilerWarnings_gcc.hpp as well since it can be used for more than just compiler warnings Julian Waters has updated the pull request incrementally with two additional commits since the last revision: - I'm stupid v2 - I'm stupid ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12255/files - new: https://git.openjdk.org/jdk/pull/12255/files/84a79add..1c8d6f22 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12255&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12255&range=02-03 Stats: 4 lines in 2 files changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12255.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12255/head:pull/12255 PR: https://git.openjdk.org/jdk/pull/12255 From duke at openjdk.org Sat Jan 28 18:38:58 2023 From: duke at openjdk.org (Afshin Zafari) Date: Sat, 28 Jan 2023 18:38:58 GMT Subject: RFR: 8267935: Replace BasicHashtable and Hashtable Message-ID: ### Description Hashtable class to be replaced with ResourceHashtable class in all source code. ### Patch The only instance was `#include "hashtable.hpp"` in `jvmtiTagMapTable.cpp` and removed. The corresponding files (`hashtable.hpp`, `hashtable.inline.hpp` and `hashtable.cpp`) are removed too. ### Test mach5 tier1 all platforms. ------------- Commit messages: - 8267935: Replace BasicHashtable and Hashtable Changes: https://git.openjdk.org/jdk/pull/12275/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12275&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8267935 Stats: 596 lines in 4 files changed: 0 ins; 596 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12275.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12275/head:pull/12275 PR: https://git.openjdk.org/jdk/pull/12275 From kbarrett at openjdk.org Sat Jan 28 19:31:25 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 28 Jan 2023 19:31:25 GMT Subject: RFR: JDK-8301224: Replace NULL with nullptr in share/gc/shared/ In-Reply-To: References: Message-ID: <5KxAlk13OfIEAaaKYxkgNkKBfDfEcqeR7KiquckDqWQ=.7b18cf48-32a9-4b2f-bec5-3ba770ca0926@github.com> On Fri, 27 Jan 2023 10:06:26 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/gc/shared/. 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! There are a number of changes to something like `*p == null` that I think should either be `*p == nullptr` or `*p is null`. src/hotspot/share/gc/shared/c1/barrierSetC1.cpp line 227: > 225: // > 226: // if (offset == java_lang_ref_Reference::referent_offset()) { > 227: // if (src != null) { This "null" in a comment really should be "nullptr". src/hotspot/share/gc/shared/generationCounters.cpp line 70: > 68: VirtualSpace* v) > 69: : _virtual_space(v) { > 70: assert(v != nullptr, "don't call this constructor if v == null"); nullptr here src/hotspot/share/gc/shared/oopStorage.hpp line 102: > 100: > 101: // Locks _allocation_mutex. > 102: // precondition: ptr != null. nullptr here src/hotspot/share/gc/shared/oopStorage.hpp line 107: > 105: // Allocates and returns a new entry. Returns null if memory allocation > 106: // failed. Locks _allocation_mutex. > 107: // postcondition: result == null or *result == null. nullptr here src/hotspot/share/gc/shared/oopStorage.hpp line 123: > 121: // postcondition: result <= min(size, bulk_allocate_limit). > 122: // postcondition: ptrs[i] is an allocated entry for i in [0, result). > 123: // postcondition: *ptrs[i] == null for i in [0, result). nullptr here src/hotspot/share/gc/shared/oopStorage.hpp line 128: > 126: // Deallocates ptr. No locking. > 127: // precondition: ptr is a valid allocated entry. > 128: // precondition: *ptr == null. nullptr here src/hotspot/share/gc/shared/oopStorage.hpp line 134: > 132: // release(oop*). Best if ptrs is sorted by address. No locking. > 133: // precondition: All elements of ptrs are valid allocated entries. > 134: // precondition: *ptrs[i] == null, for i in [0,size). nullptr here src/hotspot/share/gc/shared/oopStorage.hpp line 158: > 156: // convertible to bool. > 157: // > 158: // For weak_oops_do, if *p == null then neither is_alive nor closure will be nullptr here src/hotspot/share/gc/shared/oopStorageParState.hpp line 127: > 125: // is convertible to bool. > 126: // > 127: // If *p == null then neither is_alive nor cl will be invoked for p. nullptr here, or "*p is null". ------------- Changes requested by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/12249 From kbarrett at openjdk.org Sun Jan 29 00:10:26 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 29 Jan 2023 00:10:26 GMT Subject: RFR: JDK-8301076: Replace NULL with nullptr in share/prims/ In-Reply-To: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> References: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> Message-ID: On Wed, 25 Jan 2023 11:47:05 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/prims/. 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! Changes requested by kbarrett (Reviewer). src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 151: > 149: } > 150: > 151: // Use _thread_saved if cthread is detached from JavaThread (_thread == null). s/null/nullptr/ or s/==/is/ src/hotspot/share/prims/jvmtiImpl.cpp line 125: > 123: GrowableElement *e1 = (GrowableElement *) v; > 124: assert(e1 != nullptr, "e1 != null"); > 125: assert(e2 != nullptr, "e2 != null"); s/null/nullptr/ ? src/hotspot/share/prims/jvmtiImpl.cpp line 162: > 160: GrowableElement* GrowableCache::at(int index) { > 161: GrowableElement *e = (GrowableElement *) _elements->at(index); > 162: assert(e != nullptr, "e != null"); s/null/nullptr/ ? src/hotspot/share/prims/jvmtiImpl.cpp line 180: > 178: void GrowableCache::remove (int index) { > 179: GrowableElement *e = _elements->at(index); > 180: assert(e != nullptr, "e != null"); s/null/nullptr/ ? src/hotspot/share/prims/jvmtiImpl.cpp line 412: > 410: if (_jvmti_breakpoints != nullptr) return (*_jvmti_breakpoints); > 411: _jvmti_breakpoints = new JvmtiBreakpoints(listener_fun); > 412: assert(_jvmti_breakpoints != nullptr, "_jvmti_breakpoints != null"); s/null/nullptr/ ? src/hotspot/share/prims/jvmtiImpl.cpp line 418: > 416: void JvmtiCurrentBreakpoints::listener_fun(void *this_obj, address *cache) { > 417: JvmtiBreakpoints *this_jvmti = (JvmtiBreakpoints *) this_obj; > 418: assert(this_jvmti != nullptr, "this_jvmti != null"); s/null/nullptr/ ? src/hotspot/share/prims/methodHandles.cpp line 1024: > 1022: #define VALUE_COMMA(scope,value) scope::value, > 1023: static const int con_values[con_value_count+1] = { EACH_NAMED_CON(VALUE_COMMA, IGNORE_REQ) 0 }; > 1024: #define STRING_nullptr(scope,value) #value "\0" Should not be changed. src/hotspot/share/prims/methodHandles.cpp line 1025: > 1023: static const int con_values[con_value_count+1] = { EACH_NAMED_CON(VALUE_COMMA, IGNORE_REQ) 0 }; > 1024: #define STRING_nullptr(scope,value) #value "\0" > 1025: static const char con_names[] = { EACH_NAMED_CON(STRING_nullptr, IGNORE_REQ) }; Should not be changed. src/hotspot/share/prims/methodHandles.cpp line 1046: > 1044: #undef ONE_PLUS > 1045: #undef VALUE_COMMA > 1046: #undef STRING_nullptr Should not be changed. src/hotspot/share/prims/upcallLinker.cpp line 100: > 98: > 99: // For the profiler, the last_Java_frame information in thread must always be in > 100: // legal state. We have no last Java frame if last_Java_sp == null so s/null/nullptr/ ? ------------- PR: https://git.openjdk.org/jdk/pull/12188 From jwaters at openjdk.org Sun Jan 29 04:52:26 2023 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 29 Jan 2023 04:52:26 GMT Subject: RFR: 8301244: Replace legacy pragma implementations in HotSpot's compilerWarnings.hpp [v5] In-Reply-To: References: Message-ID: > HotSpot has a few legacy implementations of pragmas in some of its macros in compilerWarnings.hpp, they should be cleaned up and use a more modern approach. Rename PRAGMA macro in compilerWarnings_gcc.hpp as well since it can be used for more than just compiler warnings Julian Waters has updated the pull request incrementally with two additional commits since the last revision: - Remove VISCPP PRAGMA - Remove PRAGMA ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12255/files - new: https://git.openjdk.org/jdk/pull/12255/files/1c8d6f22..dae01b07 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12255&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12255&range=03-04 Stats: 6 lines in 2 files changed: 0 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/12255.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12255/head:pull/12255 PR: https://git.openjdk.org/jdk/pull/12255 From jwaters at openjdk.org Sun Jan 29 06:31:14 2023 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 29 Jan 2023 06:31:14 GMT Subject: RFR: 8301244: Replace legacy pragma implementations in HotSpot's compilerWarnings.hpp [v6] In-Reply-To: References: Message-ID: > HotSpot has a few legacy implementations of pragmas in some of its macros in compilerWarnings.hpp, they should be cleaned up and use a more modern approach. Rename PRAGMA macro in compilerWarnings_gcc.hpp as well since it can be used for more than just compiler warnings Julian Waters has updated the pull request incrementally with one additional commit since the last revision: PRAGMA_UTIL ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12255/files - new: https://git.openjdk.org/jdk/pull/12255/files/dae01b07..25984854 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12255&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12255&range=04-05 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12255.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12255/head:pull/12255 PR: https://git.openjdk.org/jdk/pull/12255 From jwaters at openjdk.org Sun Jan 29 06:38:19 2023 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 29 Jan 2023 06:38:19 GMT Subject: RFR: 8301244: Replace legacy pragma implementations in HotSpot's compilerWarnings.hpp [v7] In-Reply-To: References: Message-ID: > HotSpot has a few legacy implementations of pragmas in some of its macros in compilerWarnings.hpp, they should be cleaned up and use a more modern approach. Rename PRAGMA macro in compilerWarnings_gcc.hpp as well since it can be used for more than just compiler warnings Julian Waters has updated the pull request incrementally with one additional commit since the last revision: compilerWarnings_gcc.hpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12255/files - new: https://git.openjdk.org/jdk/pull/12255/files/25984854..de049888 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12255&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12255&range=05-06 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12255.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12255/head:pull/12255 PR: https://git.openjdk.org/jdk/pull/12255 From jwaters at openjdk.org Sun Jan 29 06:40:17 2023 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 29 Jan 2023 06:40:17 GMT Subject: RFR: 8301244: Replace legacy pragma implementations in HotSpot's compilerWarnings.hpp [v6] In-Reply-To: References: Message-ID: On Sun, 29 Jan 2023 06:31:14 GMT, Julian Waters wrote: >> HotSpot has a few legacy implementations of pragmas in some of its macros in compilerWarnings.hpp, they should be cleaned up and use a more modern approach. Rename PRAGMA macro in compilerWarnings_gcc.hpp as well since it can be used for more than just compiler warnings > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > PRAGMA_UTIL I'll just leave the pragmas to compilerWarnings.hpp then. Out of curiosity, do we have pragmas anywhere else in HotSpot other than for these warnings? ------------- PR: https://git.openjdk.org/jdk/pull/12255 From iklam at openjdk.org Sun Jan 29 06:44:16 2023 From: iklam at openjdk.org (Ioi Lam) Date: Sun, 29 Jan 2023 06:44:16 GMT Subject: RFR: 8301136: Improve unlink() and unlink_all() of ResourceHashtableBase [v5] In-Reply-To: References: Message-ID: <9GAFUt_y36yObC0oOhzxNC05Y8Ja_fkUPxvhZCuFSPY=.255df6aa-d417-4277-9799-a9208e758158@github.com> On Fri, 27 Jan 2023 23:16:52 GMT, Xin Liu wrote: >> 1. Apply the same idea of JDK-8300184 to unlink(). >> 2. Because ResourceHashtableBase doesn't support copy assignment, client of it has to purge all elements first when it needs to assign it. We would like provide a specialized version called 'unlink_all()'. We don't need to update each node's _next in this case. We only nullify all buckets. >> 3. This patch also provides a specialized version of unlink_all() for destructor. We don't even update buckets. it's dead anyway. > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > Add lambda API unlink(Function f) per reviewers' request. I updated [JDK-8301296](https://bugs.openjdk.org/browse/JDK-8301296) to clarify the problems with the current ResourceHashtable design and my proposal for fixing them. I think the above proposed fixes shouldn't block the progress of this PR, which is just an optimization that maintains the current behavior. So let's continue the discussions here. There are two parts of this PR: [1] For the optimization (counting the number of entries and exit the loop early), do you have any performance data that shows this is beneficial? For this optimization to be beneficial, we must have two conditions -- (a) the table is too large so it's likely to have many unused entries, and (b) the hash function is bad so most of the unused entries are at the end of the table. For (a), maybe it's better to change the table to ResizeableResourceHashtable? For (b), maybe you can also print out the occupancy of the table in your traces like this one (in your earlier PR https://github.com/openjdk/jdk/pull/12016) [12.824s][debug][hashtables] table_size = 109, break at 68 If we have many entries (e.g., 40) but they all pack to the front end of the table, that means we have a bad hash function. [2] As I suggested earlier, we should consolidate the code to use a single unlink loop, so you can apply this counting optimization in a single place. I am not quite sure why you would need the following in your "wrapper" functions: if (clean) { *ptr = node->_next; } else { ptr = &(node->_next); } and if (node->_next == nullptr) { // nullify the bucket when reach the end of linked list. *ptr = nullptr; } I wrote a version of the consolidated loop that's much simpler. It also aligns with the old code so the diff is more readable: https://github.com/openjdk/jdk/compare/master...iklam:jdk:8301136-resource-hash-unlink-all-suggestion Note that I have both `unlink_all()` and `unlink_all(Function function)`, that's because the current API allows the user function to do two things (a) check if the entry should be freed, (b) perform special clean up on the entry. So if you want to free all entries but need to perform special clean up, you'd call `unlink_all(Function function)`. ------------- PR: https://git.openjdk.org/jdk/pull/12213 From jwaters at openjdk.org Sun Jan 29 06:45:15 2023 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 29 Jan 2023 06:45:15 GMT Subject: RFR: 8301244: Replace legacy pragma implementations in HotSpot's compilerWarnings.hpp [v7] In-Reply-To: References: Message-ID: On Sun, 29 Jan 2023 06:38:19 GMT, Julian Waters wrote: >> HotSpot has a few legacy implementations of pragmas in some of its macros in compilerWarnings.hpp, they should be cleaned up and use a more modern approach. Rename PRAGMA macro in compilerWarnings_gcc.hpp as well since it can be used for more than just compiler warnings > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > compilerWarnings_gcc.hpp Never mind, I just checked and we always use the #pragma directive whenever declaring a pragma directly, so this isn't relevant to general pragma usage in HotSpot. Sorry! ------------- PR: https://git.openjdk.org/jdk/pull/12255 From jwaters at openjdk.org Sun Jan 29 06:52:21 2023 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 29 Jan 2023 06:52:21 GMT Subject: RFR: 8301244: Replace legacy pragma implementations in HotSpot's compilerWarnings.hpp [v7] In-Reply-To: References: Message-ID: On Sat, 28 Jan 2023 12:30:56 GMT, Kim Barrett wrote: >> Julian Waters has updated the pull request incrementally with one additional commit since the last revision: >> >> compilerWarnings_gcc.hpp > > src/hotspot/share/utilities/macros.hpp line 33: > >> 31: // For when Pragmas need to be reliably nested in macros. Also handles >> 32: // quotation marks, so use sites are not required to pass string literals >> 33: #define PRAGMA(str) _Pragma(#str) > > This shouldn't be here. A file could include only compilerWarnings.hpp and not this file, and not be able to use pragma macros provided by compilerWarnings.hpp. @kimbarrett compilerWarnings.hpp does include macros.hpp before the compiler specific macros, so this shouldn't be an issue ------------- PR: https://git.openjdk.org/jdk/pull/12255 From kbarrett at openjdk.org Sun Jan 29 21:15:15 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 29 Jan 2023 21:15:15 GMT Subject: RFR: 8301244: Replace legacy pragma implementations in HotSpot's compilerWarnings.hpp [v7] In-Reply-To: References: Message-ID: On Sun, 29 Jan 2023 06:38:19 GMT, Julian Waters wrote: >> HotSpot has a few legacy implementations of pragmas in some of its macros in compilerWarnings.hpp, they should be cleaned up and use a more modern approach. Rename PRAGMA macro in compilerWarnings_gcc.hpp as well since it can be used for more than just compiler warnings > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > compilerWarnings_gcc.hpp Describing MSVC `__pragma` as "legacy" is questionable. MSVC documentation describes it as an extension, and it seems unlikely to ever go away. So all this change really does is make the MS compiler work a little harder (stringize the token sequence, then retokenize it) in order to avoid an MS-specific extension in MS-specific code. Plus the cost of a new helper macro. I had wondered if there might be some benefit related to control of macro expansion, but there's not (see the definition of _Pragma). While exploring that question I discovered a difference in behavior between MSVC and gcc. MSVC macro expands the pragma tokens, while gcc does not. So I don't think this change should be made. ------------- PR: https://git.openjdk.org/jdk/pull/12255 From dholmes at openjdk.org Sun Jan 29 23:07:20 2023 From: dholmes at openjdk.org (David Holmes) Date: Sun, 29 Jan 2023 23:07:20 GMT Subject: RFR: JDK-8301072: Replace NULL with nullptr in share/oops/ [v2] In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 13:42:43 GMT, Johan Sj?len wrote: >> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/oops/. 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: > > Do stefank's fixes Looks good. Thanks! src/hotspot/share/oops/method.hpp line 794: > 792: > 793: // Use checked_resolve_jmethod_id() in situations where the caller > 794: // should provide a valid jmethodID, but might not. null is returned Nit: Null (as it starts a sentence) src/hotspot/share/oops/oop.hpp line 263: > 261: // Like "forward_to", but inserts the forwarding pointer atomically. > 262: // Exactly one thread succeeds in inserting the forwarding pointer, and > 263: // this call returns "null" for that thread; any other thread has the Nit: null should not be in quotes ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12186 From jwaters at openjdk.org Mon Jan 30 03:26:16 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 30 Jan 2023 03:26:16 GMT Subject: RFR: 8301244: Replace legacy pragma implementations in HotSpot's compilerWarnings.hpp [v7] In-Reply-To: References: Message-ID: On Sun, 29 Jan 2023 06:38:19 GMT, Julian Waters wrote: >> HotSpot has a few legacy implementations of pragmas in some of its macros in compilerWarnings.hpp, they should be cleaned up and use a more modern approach. Rename PRAGMA macro in compilerWarnings_gcc.hpp as well since it can be used for more than just compiler warnings > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > compilerWarnings_gcc.hpp I've looked through the macros again and I disagree that it would force the Visual C++ compiler to always stringize pragmas, the new `PRAGMA` macro isn't meant to replace the typical #pragma declarations, but rather as a quick and platform independent utility to embed pragmas inside other macros, with otherwise identical behaviour as the direct usage of the #pragma directive. Prior to this gcc had the same declaration but only for expanding the disabled warnings macro in compilerWarnings_gcc.hpp, which, at least to me, seems too limited of a usage scope when it can be useful in more situations than just as a warning support macro. Adding to this, avoidance of the Visual C++ extension isn't a goal, but merely a side effect since it would just be unnecessarily messy and add clutter to differentiate the implementations in macros.hpp when one that fits all platforms can be easily attained. Additionally, the extra work this requires from Visual C++ is minimal enough that this should not be much of an issue when it comes to build performance (embedded pragmas aren't really used carelessly in HotSpot either, alleviating the issue even more). Expansion of the macro by Visual C++ is actually a bug to my knowledge, which has since been fixed quite some time ago. Other than that, _Pragma is actually pretty much identical to __pragma in Visual C++, so the expected behaviour wouldn't change with this patch. (Also, this helps [JDK-8288293](https://bugs.openjdk.org/browse/JDK-8288293), which aims to allow plugging different compilers, where the compiler for Windows may not necessarily be Visual C++) I admit that I could have worded the change title much better than I did though :P ------------- PR: https://git.openjdk.org/jdk/pull/12255 From aboldtch at openjdk.org Mon Jan 30 07:17:23 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 30 Jan 2023 07:17:23 GMT Subject: Integrated: 8301088: oopDesc::print_on should consistently use a trailing newline In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 13:56:08 GMT, Axel Boldt-Christmas wrote: > [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161) added special printing when `oopDesc` contains `badHeapWordVal` or `badMetaWordVal`. However these two cases do not print a trailing newline. The previous behaviour was to always use a trailing newline. > > Propose making this consistent with `*klass::oop_print_on` and `InstanceStackChunkKlass::print_chunk`, that both uses a trailing newline. > > This new behaviour messes up some printing code, e.g. can be seen in print_location when printing hs_err files which assumes that it always prints a trailing newline. This pull request has now been integrated. Changeset: 4bd3f0a0 Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/4bd3f0a0d5f0ad314cd4e7a68851c2db9100df67 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod 8301088: oopDesc::print_on should consistently use a trailing newline Reviewed-by: tschatzl, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/12195 From stuefe at openjdk.org Mon Jan 30 08:36:26 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 30 Jan 2023 08:36:26 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v2] In-Reply-To: References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> Message-ID: On Mon, 16 Jan 2023 14:31:04 GMT, Johan Sj?len wrote: >> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8293313-NMT-fake-oom >> - MallocLimit > > This looks good. I've added some nits for style and a couple of comments concerning style which aren't nits. Logic wise, easy to follow and straight forward code, I could find nothing to complain about. @jdksjolen are you fine with the updated version? I would like to integrate this. This has been cooking in our test systems for about 3 months now, so I think it is well-tested. ------------- PR: https://git.openjdk.org/jdk/pull/11371 From jsjolen at openjdk.org Mon Jan 30 09:17:20 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 30 Jan 2023 09:17:20 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v7] In-Reply-To: References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> Message-ID: On Sat, 28 Jan 2023 06:37:01 GMT, Thomas Stuefe wrote: >> Rework NMT `MallocLimit` to make it more useful for native OOM analysis. Also remove `MallocMaxTestWords`, which had been mostly redundant with NMT (for background, see JDK-8293292). >> >> >> ### Background >> >> Some months ago we had [JDK-8291919](https://bugs.openjdk.org/browse/JDK-8291919), a compiler regression that caused compiler arenas to grow boundlessly. Process was usually OOM-killed before we could take a look, so this was difficult to analyze. >> >> To improve analysis options, we added NMT *malloc limits* with [JDK-8291878](https://bugs.openjdk.org/browse/JDK-8291878). Malloc limits let us set one or multiple limits to malloc load. Surpassing a limit causes the VM to stop with a fatal error in the allocation function, giving us a hs-err file and a core right at the point that (probably) causes the leak. This makes error analysis a lot simpler, and is also valuable for regression-testing footprint usage. >> >> Some people wished for a way to not end with a fatal error but to mimic a native OOM (causing os::malloc to return NULL). This would allow us to test resilience in the face of native OOMs, among other things. >> >> ### Patch >> >> - Expands the `MallocLimit` option syntax, allowing for an "oom mode" that mimics an oom: >> >> >> >> Global form: >> -XX:MallocLimit=[:] >> Category-specific form: >> -XX:MallocLimit=:[:][,:[:] ...] >> Examples: >> -XX:MallocLimit=3g >> -XX:MallocLimit=3g:oom >> -XX:MallocLimit=compiler:200m:oom >> >> >> - moves parsing of `-XX:MallocLimit` out of arguments.cpp into `mallocLimit.hpp/cpp`, and rewrites it. >> >> - changes when limits are checked. Before, the limits were checked *after* the allocation that caused the threshold overflow. Now we check beforehand. >> >> - removes `MallocMaxTestWords`, replacing its uses with `MallocLimit` >> >> - adds new gtests and new jtreg tests >> >> - removes a bunch of jtreg tests which are now better served by the new gtests. >> >> - gives us more precise error messages upon reaching a limit. For example: >> >> before: >> >> # fatal error: MallocLimit: category "Compiler" reached limit (size: 20997680, limit: 20971520) >> >> >> now: >> >> # fatal error: MallocLimit: reached category "Compiler" limit (triggering allocation size: 1920B, allocated so far: 20505K, limit: 20480K) > > Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - merge and fix conflicts > - Merge; fix conflicts > - Feedback Gerard > - Revert strchrnul > - Copyrights > - Feedback Johan > - Merge > - Merge branch 'master' into JDK-8293313-NMT-fake-oom > - MallocLimit Hi @tstuefe , thanks for the extra ping. Yes, this looks good! ------------- Marked as reviewed by jsjolen (Committer). PR: https://git.openjdk.org/jdk/pull/11371 From jsjolen at openjdk.org Mon Jan 30 09:24:37 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 30 Jan 2023 09:24:37 GMT Subject: RFR: JDK-8301224: Replace NULL with nullptr in share/gc/shared/ [v2] In-Reply-To: References: Message-ID: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/gc/shared/. 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: Fix kimbarrett's suggestions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12249/files - new: https://git.openjdk.org/jdk/pull/12249/files/5369babe..64b6ba01 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12249&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12249&range=00-01 Stats: 9 lines in 4 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/12249.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12249/head:pull/12249 PR: https://git.openjdk.org/jdk/pull/12249 From jsjolen at openjdk.org Mon Jan 30 09:24:38 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 30 Jan 2023 09:24:38 GMT Subject: RFR: JDK-8301224: Replace NULL with nullptr in share/gc/shared/ In-Reply-To: References: Message-ID: <0iGy9lLki6PP6NcweKtZakwHfPhV6kYqmZ_3PNdtrhc=.ff318176-58a5-4e7b-8ab0-f45383641d0d@github.com> On Fri, 27 Jan 2023 10:06:26 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/gc/shared/. 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! Hi Kim, thanks, I've pushed your suggested changes. ------------- PR: https://git.openjdk.org/jdk/pull/12249 From jsjolen at openjdk.org Mon Jan 30 09:26:25 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 30 Jan 2023 09:26:25 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v7] In-Reply-To: References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> Message-ID: On Sat, 28 Jan 2023 06:37:01 GMT, Thomas Stuefe wrote: >> Rework NMT `MallocLimit` to make it more useful for native OOM analysis. Also remove `MallocMaxTestWords`, which had been mostly redundant with NMT (for background, see JDK-8293292). >> >> >> ### Background >> >> Some months ago we had [JDK-8291919](https://bugs.openjdk.org/browse/JDK-8291919), a compiler regression that caused compiler arenas to grow boundlessly. Process was usually OOM-killed before we could take a look, so this was difficult to analyze. >> >> To improve analysis options, we added NMT *malloc limits* with [JDK-8291878](https://bugs.openjdk.org/browse/JDK-8291878). Malloc limits let us set one or multiple limits to malloc load. Surpassing a limit causes the VM to stop with a fatal error in the allocation function, giving us a hs-err file and a core right at the point that (probably) causes the leak. This makes error analysis a lot simpler, and is also valuable for regression-testing footprint usage. >> >> Some people wished for a way to not end with a fatal error but to mimic a native OOM (causing os::malloc to return NULL). This would allow us to test resilience in the face of native OOMs, among other things. >> >> ### Patch >> >> - Expands the `MallocLimit` option syntax, allowing for an "oom mode" that mimics an oom: >> >> >> >> Global form: >> -XX:MallocLimit=[:] >> Category-specific form: >> -XX:MallocLimit=:[:][,:[:] ...] >> Examples: >> -XX:MallocLimit=3g >> -XX:MallocLimit=3g:oom >> -XX:MallocLimit=compiler:200m:oom >> >> >> - moves parsing of `-XX:MallocLimit` out of arguments.cpp into `mallocLimit.hpp/cpp`, and rewrites it. >> >> - changes when limits are checked. Before, the limits were checked *after* the allocation that caused the threshold overflow. Now we check beforehand. >> >> - removes `MallocMaxTestWords`, replacing its uses with `MallocLimit` >> >> - adds new gtests and new jtreg tests >> >> - removes a bunch of jtreg tests which are now better served by the new gtests. >> >> - gives us more precise error messages upon reaching a limit. For example: >> >> before: >> >> # fatal error: MallocLimit: category "Compiler" reached limit (size: 20997680, limit: 20971520) >> >> >> now: >> >> # fatal error: MallocLimit: reached category "Compiler" limit (triggering allocation size: 1920B, allocated so far: 20505K, limit: 20480K) > > Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - merge and fix conflicts > - Merge; fix conflicts > - Feedback Gerard > - Revert strchrnul > - Copyrights > - Feedback Johan > - Merge > - Merge branch 'master' into JDK-8293313-NMT-fake-oom > - MallocLimit Sorry, could you please convert the NULLs into nullptr :)? ------------- PR: https://git.openjdk.org/jdk/pull/11371 From jsjolen at openjdk.org Mon Jan 30 09:30:36 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 30 Jan 2023 09:30:36 GMT Subject: RFR: JDK-8301076: Replace NULL with nullptr in share/prims/ [v2] In-Reply-To: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> References: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> Message-ID: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/prims/. 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: FIx suggested changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12188/files - new: https://git.openjdk.org/jdk/pull/12188/files/aac5b946..b1ff44d7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12188&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12188&range=00-01 Stats: 12 lines in 5 files changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/12188.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12188/head:pull/12188 PR: https://git.openjdk.org/jdk/pull/12188 From jsjolen at openjdk.org Mon Jan 30 09:30:38 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 30 Jan 2023 09:30:38 GMT Subject: RFR: JDK-8301076: Replace NULL with nullptr in share/prims/ In-Reply-To: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> References: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> Message-ID: <7iCZZEs6MIekJQzYFwKnT9eylLVxklFRXQNRa5ayRRQ=.b56fa4c0-9bcb-4e9b-92a7-09358db04790@github.com> On Wed, 25 Jan 2023 11:47:05 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/prims/. 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! Thanks for these review comments, I've fixed your suggestions. I must've accidentally submitted a different branch for tier1 testing, as this doesn't compile. ------------- PR: https://git.openjdk.org/jdk/pull/12188 From rkennke at openjdk.org Mon Jan 30 09:31:24 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 30 Jan 2023 09:31:24 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v4] In-Reply-To: References: Message-ID: <9Igt64_77kxr7GRMRYTJcLFKCsTSQ5zwRPqMhRoJGxo=.0fba3c59-18a7-4621-a4b5-253f499921de@github.com> On Wed, 25 Jan 2023 17:42:23 GMT, Daniel D. Daugherty wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert UseFastLocking to default to off > > src/hotspot/share/runtime/objectMonitor.cpp line 1141: > >> 1139: assert(_recursions == 0, "invariant"); >> 1140: set_owner_from_BasicLock(cur, current); // Convert from BasicLock* to Thread*. >> 1141: _recursions = 0; > > Hmmm... fast-locking also has two different ways that a thread can own an > ObjectMonitor: 1) owner == thread* and 2) owner == anonymous and lock on > the owning thread's lock stack. > > If `UseFastLocking` is enabled and `ObjectMonitor::exit()` is called by a thread that > owns the ObjectMonitor in the secondary way, then this code will fail the assert on > L1158 in non-product bits. There needs to be check to see if the current thread owns > the fast-lock and then update the owner in the ObjectMonitor after asserting about > recursions and resetting recursions to 0. With fast-locking, OM::exit() must not be called as long as the owner is ANONYMOUS. The protocol is the following: - T1 fast-locks object O - T2 attempts to lock object O, observes that it is already locked and inflates with ANONYMOUS owner, because it doesn't know who owns the monitor. It then gets in line to acquire the monitor. - When T1 exits, it observes the monitor being owned by ANONYMOUS, and sets the owner to itself, and calls OM::exit(), thereby performing the regular hand-over to T2. - That check for ANONYMOUS owner also needs to be done in the C2 fast-path, and when that happens, it calls into runtime to do the necessary hand-over. ------------- PR: https://git.openjdk.org/jdk/pull/10907 From duke at openjdk.org Mon Jan 30 09:40:58 2023 From: duke at openjdk.org (Amit Kumar) Date: Mon, 30 Jan 2023 09:40:58 GMT Subject: RFR: 8298413: [s390] CPUInfoTest fails due to uppercase feature string Message-ID: <4jGO8wNNTB7LMAY7Hob6Pbkei8t4S37-pr8lBsbJkc8=.4d1c0296-bcc9-41ca-8275-e5d247c78e53@github.com> CPUInfoTest.java is failing on s390 due to an incorrect feature string. Feature Vector Enhancement is shown as VEnh2 instead of venh2. Beside that out-of-support date/(tbd) was not being included even if it was present there so this issue is also addressed by this fix. ------------- Commit messages: - fixes CPUInfoTest.java on s390 Changes: https://git.openjdk.org/jdk/pull/12286/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12286&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298413 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/12286.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12286/head:pull/12286 PR: https://git.openjdk.org/jdk/pull/12286 From rkennke at openjdk.org Mon Jan 30 09:43:26 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 30 Jan 2023 09:43:26 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v6] In-Reply-To: References: Message-ID: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Renaissance > > > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: 8291555-dcubed-editorial-1 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10907/files - new: https://git.openjdk.org/jdk/pull/10907/files/784b361c..77c8a820 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=04-05 Stats: 116 lines in 4 files changed: 51 ins; 21 del; 44 mod Patch: https://git.openjdk.org/jdk/pull/10907.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10907/head:pull/10907 PR: https://git.openjdk.org/jdk/pull/10907 From rehn at openjdk.org Mon Jan 30 09:59:06 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Mon, 30 Jan 2023 09:59:06 GMT Subject: RFR: 8301337: Remove unused os::_polling_page Message-ID: Hi, please consider removing the unused field _polling_page in os. Built tested many platforms + t1. ------------- Commit messages: - 8301337: Remove unused os::_polling_page Changes: https://git.openjdk.org/jdk/pull/12287/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12287&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301337 Stats: 10 lines in 4 files changed: 0 ins; 10 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12287.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12287/head:pull/12287 PR: https://git.openjdk.org/jdk/pull/12287 From eosterlund at openjdk.org Mon Jan 30 10:31:28 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 30 Jan 2023 10:31:28 GMT Subject: Integrated: 8301047: Clean up type unsafe uses of oop from compiler code In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 15:45:06 GMT, Erik ?sterlund wrote: > In an ideal world, when you have an oop, its contents should also be an oop. It happens, however, that we have other forms of pointers sometimes, used with the oop type, in some compiler code. We should clean that up. This pull request has now been integrated. Changeset: cee4bd3e Author: Erik ?sterlund URL: https://git.openjdk.org/jdk/commit/cee4bd3ee610492aaa96cb0c5fcf2c32a1c12e2e Stats: 19 lines in 5 files changed: 1 ins; 1 del; 17 mod 8301047: Clean up type unsafe uses of oop from compiler code Co-authored-by: Axel Boldt-Christmas Co-authored-by: Stefan Karlsson Reviewed-by: kvn, stefank ------------- PR: https://git.openjdk.org/jdk/pull/12223 From eosterlund at openjdk.org Mon Jan 30 10:33:24 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 30 Jan 2023 10:33:24 GMT Subject: Integrated: 8301248: Less side effects in InstanceRefKlass::trace_reference_gc In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 15:42:05 GMT, Erik ?sterlund wrote: > The InstanceRefKlass::trace_reference_gc function is called when using oop_iterate on a reference object. Since oop_iterate is a general iterator that can be used for anything, including verification code, it would be desirable for this code to not have subtle side effects. We currently apply load barriers which "fix" pointers in the heap. As a result, verification code that was meant to detect bugs, can end up fixing and hiding the bug. This CR aims to address this by limiting the logging to addresses, and not following them. This pull request has now been integrated. Changeset: c672ed16 Author: Erik ?sterlund URL: https://git.openjdk.org/jdk/commit/c672ed16f363d9c92ccefe2e64a96e0a60a49588 Stats: 18 lines in 1 file changed: 6 ins; 2 del; 10 mod 8301248: Less side effects in InstanceRefKlass::trace_reference_gc Co-authored-by: Stefan Karlsson Co-authored-by: Axel Boldt-Christmas Reviewed-by: rkennke, stefank ------------- PR: https://git.openjdk.org/jdk/pull/12258 From shade at openjdk.org Mon Jan 30 10:37:19 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 30 Jan 2023 10:37:19 GMT Subject: RFR: 8301036: RISC-V: Factor out functions baseOffset & baseOffset32 from MacroAssembler [v3] In-Reply-To: References: Message-ID: <-q_wDegbcS6a7ago1wrAX7HrJNeFaimDywKjSEdVm_I=.02ce4e5c-8504-46e0-ace3-39f989c22751@github.com> On Fri, 27 Jan 2023 02:38:59 GMT, Fei Yang wrote: >> On RISC-V, functions baseOffset & baseOffset32 from MacroAssembler receive an Address in base_plus_offset mode. These two functions check the range of the offset, add it and base and put the result in a destination register. This duplicates function MacroAssembler::la in functionality. We could refactor this part moving the logic of Address legitimization into MacroAssembler::la and use this function instead. >> >> Testing: >> - [x] Bootcycle (release & fastdebug) >> - [x] Tier1-4 (release) >> - [x] Benchmarks: SPECjbb2015 (release) > > Fei Yang 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: > > - Fix > - Merge branch 'master' into JDK-8301036 > - Comment > - Merge branch 'master' into JDK-8301036 > - 8301036: RISC-V: Factor out functions baseOffset & baseOffset32 from MacroAssembler Looks fine. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/12177 From rkennke at openjdk.org Mon Jan 30 11:10:27 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 30 Jan 2023 11:10:27 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v5] In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 19:33:16 GMT, Daniel D. Daugherty wrote: >> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 86 commits: >> >> - Merge branch 'master' into JDK-8291556-v2 >> - Revert UseFastLocking to default to off >> - Change log message inflate(locked) -> inflate(has_locker) >> - Properly set ZF on anon-check path; avoid some conditional branches >> - Use testb when testing for anon owner in fast-path >> - Merge branch 'master' into JDK-8291555-v2 >> - In x86_32 C2 fast_lock(), CAS thread directly, instead of CASing stack-pointer and then storing thread >> - x86 part of optimization to check for anon owner >> - Optimize the check-for-anon-owner fast-path >> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2 >> - ... and 76 more: https://git.openjdk.org/jdk/compare/da80e7a4...784b361c > > src/hotspot/share/runtime/synchronizer.cpp line 1301: > >> 1299: // We could always eliminate polling by parking the thread on some auxiliary list. >> 1300: // NOTE: We need to check UseFastLocking here, because with fast-locking, the header >> 1301: // may legitimately be zero: cleared lock-bits and all upper header bits zero. > > The `markWord::INFLATING()` value was picked to be zero because the header could never > be zero except for the inflating case. With fast-locking, in the locked case with no hashcode, > the header can be all zeros. Hmmm... gotta mull on that one... > > fast-locking does not use the `markWord::INFLATING()`, but that protocol exists with the > stack-locking implementation to prevent races. Here's the gory comment from the > "Case stack-locked" portion of `ObjectSynchronizer::inflate()`: > > > // We've successfully installed INFLATING (0) into the mark-word. > // This is the only case where 0 will appear in a mark-word. > // Only the singular thread that successfully swings the mark-word > // to 0 can perform (or more precisely, complete) inflation. > // > // Why do we CAS a 0 into the mark-word instead of just CASing the > // mark-word from the stack-locked value directly to the new inflated state? > // Consider what happens when a thread unlocks a stack-locked object. > // It attempts to use CAS to swing the displaced header value from the > // on-stack BasicLock back into the object header. Recall also that the > // header value (hash code, etc) can reside in (a) the object header, or > // (b) a displaced header associated with the stack-lock, or (c) a displaced > // header in an ObjectMonitor. The inflate() routine must copy the header > // value from the BasicLock on the owner's stack to the ObjectMonitor, all > // the while preserving the hashCode stability invariants. If the owner > // decides to release the lock while the value is 0, the unlock will fail > // and control will eventually pass from slow_exit() to inflate. The owner > // will then spin, waiting for the 0 value to disappear. Put another way, > // the 0 causes the owner to stall if the owner happens to try to > // drop the lock (restoring the header from the BasicLock to the object) > // while inflation is in-progress. This protocol avoids races that might > // would otherwise permit hashCode values to change or "flicker" for an object. > // Critically, while object->mark is 0 mark.displaced_mark_helper() is stable. > // 0 serves as a "BUSY" inflate-in-progress indicator. > > > So how does fast-locking avoid hashCode value flickering for an object > when there are races between exiting an monitor and inflation? With > fast-locking the owner of the monitor does not stall due to an INFLATING > value being present in the header so the owner thread will race with the > inflating thread. However, unlike with stack-locking, the owner thread in > fast-locking is not restoring a saved header value from the BasicLock to > the object's header; it is simply changing the `locked_value` to the > `unlocked_value` in the lower two bits. If there's a hashCode in the header, > then that hashCode remains untouched. > > The other callers of `read_stable_mark()`: > > `ObjectSynchronizer::FastHashCode()` - Does not need to stall in `read_stable_mark()` > due to a racing inflation because the hashCode value will either be found in the header > or in the ObjectMonitor and it will be the same value in both locations. > > `ObjectSynchronizer::current_thread_holds_lock()` - Does not need to stall in > `read_stable_mark()` due to a racing inflation because the current thread > either owns the lock or it does not and that state cannot change while the > current thread is executing this function. > > `ObjectSynchronizer::get_lock_owner()` - I think this function does need to stall > in `read_stable_mark()` due to a racing inflation. If the calling thread in this > case gets a header value where `mark.is_fast_locked() == true`, then it will > search the ThreadsList for the thread that has the object on its lock stack. > If thread that's inflating the lock is the owner of the lock, then it will remove > the object from its lock stack after it has changed the owner in the ObjectMonitor > to itself. If that happens before the `get_lock_owner()` calling thread reaches > the owning thread in its ThreadsList search, then the `get_lock_owner()` calling > thread won't find the owner of the lock. > > If the `get_lock_owner()` calling thread happens to "know" that the lock is > supposed to be owned by _someone_, then the inconsistency could be detected. > It might even be possible to write a test to detect this. I'll mull on that a bit... > > `ObjectSynchronizer::inflate()` - Only calls read_stable_mark() when stack-locking > is in use and the `INFLATING()` value is seen. > > Otherwise, `object->mark_acquire()` is used for the read of the header at the top > of the `inflate()` loop and all the code that updates the object's mark use > `cas_set_mark()` to only change the object's mark when the current value matches > the expected current value. Otherwise, we loop around and try again. I don't think hashCode could flicker: the hashcode is store either in the header OR in the OM, but never in both. Except during inflation, in which case the CAS will ensure that the hash-code is stable (if it changes from 0 to N, then the CAS will fail and inflation will try again. An aside: With fast-locking we will be able to install and access the i-hash without inflation. However, in this case we *do* need to ensure that the i-hash will not flicker: In the case of an inflated monitor, we would have to install the i-hash into the OM displaced header, but this creates a race: meanwhile the OM could be deflated, and another thread could observe a 0 hash, and install a new i-hash into the real header. An easy way out would be to generate the i-hash from the object address, which doesn't change between safepoints. Regarding `get_lock_owner()`, there is a deeper problem IMO: The only caller of this method that is not guaranteed to be at a safepoint is `jmm_GetThreadInfo()` in `management.cpp`. However, this is not really safe to begin with: threads would always race to enter and exit monitors (no matter if they are stack-locked, fast-locked or monitor-locked). Therefore the lock-owner reported there cannot be more than informational. If we want this to be reliable, we should query the lock ownerships at safepoint only, in which case the problem that you describes dispappears. For the time being, I think we may report null lock owner there, pretty much like we could currently do with stack-locked or monitor-locked objects. Please correct me if I am wrong. ------------- PR: https://git.openjdk.org/jdk/pull/10907 From ayang at openjdk.org Mon Jan 30 11:11:59 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 30 Jan 2023 11:11:59 GMT Subject: RFR: 8301340: Make DirtyCardToOopClosure stack-allocated Message-ID: Simple change from resource-allocated to stack-allocated for a closure. Test: hotspot_gc ------------- Commit messages: - dirty-card-closure Changes: https://git.openjdk.org/jdk/pull/12291/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12291&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301340 Stats: 21 lines in 4 files changed: 0 ins; 18 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12291.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12291/head:pull/12291 PR: https://git.openjdk.org/jdk/pull/12291 From jsjolen at openjdk.org Mon Jan 30 11:13:57 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 30 Jan 2023 11:13:57 GMT Subject: RFR: JDK-8301072: Replace NULL with nullptr in share/oops/ [v3] In-Reply-To: References: Message-ID: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/oops/. 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: dholmes comments fixed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12186/files - new: https://git.openjdk.org/jdk/pull/12186/files/9d9fdfc7..10346493 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12186&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12186&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12186.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12186/head:pull/12186 PR: https://git.openjdk.org/jdk/pull/12186 From stefank at openjdk.org Mon Jan 30 11:36:17 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 30 Jan 2023 11:36:17 GMT Subject: RFR: 8301340: Make DirtyCardToOopClosure stack-allocated In-Reply-To: References: Message-ID: On Mon, 30 Jan 2023 11:03:54 GMT, Albert Mingkun Yang wrote: > Simple change from resource-allocated to stack-allocated for a closure. > > Test: hotspot_gc Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12291 From lucy at openjdk.org Mon Jan 30 12:26:57 2023 From: lucy at openjdk.org (Lutz Schmidt) Date: Mon, 30 Jan 2023 12:26:57 GMT Subject: RFR: 8299817: [s390] AES-CTR mode intrinsic fails with multiple short update() calls [v2] In-Reply-To: References: Message-ID: > This PR addresses an issue in the AES-CTR mode intrinsic on s390. When a message is ciphered in multiple, small (< 16 bytes) segments, the result is incorrect. > > This is not just a band-aid fix. The issue was taken as a chance to restructure the code. though still complicated, It is now easier to read and (hopefully) understand. > > Except for the new jetreg test, the changes are purely s390. There are no side effects on other platforms. Issue-specific tests pass. Other tests are in progress. I will update this PR once they are complete. > > **Reviews and comments are very much appreciated.** > > @backwaterred could you please run some "official" s390 tests? Thanks. Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision: 8299817: Update copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11967/files - new: https://git.openjdk.org/jdk/pull/11967/files/7af2c3db..33722f27 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11967&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11967&range=00-01 Stats: 29 lines in 5 files changed: 1 ins; 0 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/11967.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11967/head:pull/11967 PR: https://git.openjdk.org/jdk/pull/11967 From lucy at openjdk.org Mon Jan 30 12:26:57 2023 From: lucy at openjdk.org (Lutz Schmidt) Date: Mon, 30 Jan 2023 12:26:57 GMT Subject: RFR: 8299817: [s390] AES-CTR mode intrinsic fails with multiple short update() calls [v2] In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 09:23:54 GMT, Martin Doerr wrote: >> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision: >> >> 8299817: Update copyright > > test/hotspot/jtreg/compiler/codegen/aes/Test8299817.java line 4: > >> 2: * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved. >> 3: * Copyright (c) 2022 SAP SE. All rights reserved. >> 4: * ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. > > Wrong Copyright header! Please also update the Copyright years. Sorry for the delay. Copyright is fixed. ------------- PR: https://git.openjdk.org/jdk/pull/11967 From fyang at openjdk.org Mon Jan 30 12:28:26 2023 From: fyang at openjdk.org (Fei Yang) Date: Mon, 30 Jan 2023 12:28:26 GMT Subject: RFR: 8301036: RISC-V: Factor out functions baseOffset & baseOffset32 from MacroAssembler [v3] In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 02:38:59 GMT, Fei Yang wrote: >> On RISC-V, functions baseOffset & baseOffset32 from MacroAssembler receive an Address in base_plus_offset mode. These two functions check the range of the offset, add it and base and put the result in a destination register. This duplicates function MacroAssembler::la in functionality. We could refactor this part moving the logic of Address legitimization into MacroAssembler::la and use this function instead. >> >> Testing: >> - [x] Bootcycle (release & fastdebug) >> - [x] Tier1-4 (release) >> - [x] Benchmarks: SPECjbb2015 (release) > > Fei Yang 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: > > - Fix > - Merge branch 'master' into JDK-8301036 > - Comment > - Merge branch 'master' into JDK-8301036 > - 8301036: RISC-V: Factor out functions baseOffset & baseOffset32 from MacroAssembler Thanks all for the review. I don't think the windows-x64 pre-submit test failure is relevant here. ------------- PR: https://git.openjdk.org/jdk/pull/12177 From fyang at openjdk.org Mon Jan 30 12:28:28 2023 From: fyang at openjdk.org (Fei Yang) Date: Mon, 30 Jan 2023 12:28:28 GMT Subject: Integrated: 8301036: RISC-V: Factor out functions baseOffset & baseOffset32 from MacroAssembler In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 04:50:40 GMT, Fei Yang wrote: > On RISC-V, functions baseOffset & baseOffset32 from MacroAssembler receive an Address in base_plus_offset mode. These two functions check the range of the offset, add it and base and put the result in a destination register. This duplicates function MacroAssembler::la in functionality. We could refactor this part moving the logic of Address legitimization into MacroAssembler::la and use this function instead. > > Testing: > - [x] Bootcycle (release & fastdebug) > - [x] Tier1-4 (release) > - [x] Benchmarks: SPECjbb2015 (release) This pull request has now been integrated. Changeset: ebb84ad7 Author: Fei Yang URL: https://git.openjdk.org/jdk/commit/ebb84ad70d3295d9a429904fcdacdb8ecd1bf434 Stats: 64 lines in 3 files changed: 15 ins; 31 del; 18 mod 8301036: RISC-V: Factor out functions baseOffset & baseOffset32 from MacroAssembler Reviewed-by: luhenry, fjiang, shade ------------- PR: https://git.openjdk.org/jdk/pull/12177 From coleenp at openjdk.org Mon Jan 30 13:58:16 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 30 Jan 2023 13:58:16 GMT Subject: RFR: 8267935: Replace BasicHashtable and Hashtable In-Reply-To: References: Message-ID: On Sat, 28 Jan 2023 18:32:31 GMT, Afshin Zafari wrote: > ### Description > Hashtable class to be replaced with ResourceHashtable class in all source code. > > ### Patch > The only instance was `#include "hashtable.hpp"` in `jvmtiTagMapTable.cpp` and removed. > The corresponding files (`hashtable.hpp`, `hashtable.inline.hpp` and `hashtable.cpp`) are removed too. > > ### Test > mach5 tier1 all platforms. Great! thank you! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/12275 From eosterlund at openjdk.org Mon Jan 30 14:01:19 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 30 Jan 2023 14:01:19 GMT Subject: RFR: JDK-8299229: Allow UseZGC with JVMCI and enable nmethod entry barrier support [v4] In-Reply-To: References: <82zglGU9YCuc-BEAUVJ09xlmEt68DDSqGQ-090Wok20=.92ca342e-7d87-45d2-a23c-e9f4702b2572@github.com> Message-ID: <_JZw9K_uSevpUVawoG7Wk62GbQcrUz-nLSsH-9cQpwc=.6b6689bb-0a16-4459-9e80-8d5e5a84e5ba@github.com> On Tue, 24 Jan 2023 00:55:53 GMT, Tom Rodriguez wrote: > Type profiles are never read from the extra data section by JVMCI and speculative_trap_data_tag isn't exposed at all. Exception seen flags are the only thing we search for in the extra data section and I'm not even sure why that's done. See https://github.com/tkrodriguez/jdk/blob/tkr-zgc/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotProfilingInfo.java#L144 and https://github.com/tkrodriguez/jdk/blob/tkr-zgc/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotProfilingInfo.java#L113. I could adjust the logic to simply disallow reads of Klass* from the extra data section until such a day as we actually need to support it. Concurrent class unloading is going to remove rows from the extra data section under the MDO lock. It looks like said lines are iterated over here: https://github.com/tkrodriguez/jdk/blob/tkr-zgc/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotProfilingInfo.java#L163 I don't think the iteration itself is safe, without holding the lock, as rows are concurrently rearranged. ------------- PR: https://git.openjdk.org/jdk/pull/11996 From stuefe at openjdk.org Mon Jan 30 14:32:50 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 30 Jan 2023 14:32:50 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v8] In-Reply-To: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> Message-ID: > Rework NMT `MallocLimit` to make it more useful for native OOM analysis. Also remove `MallocMaxTestWords`, which had been mostly redundant with NMT (for background, see JDK-8293292). > > > ### Background > > Some months ago we had [JDK-8291919](https://bugs.openjdk.org/browse/JDK-8291919), a compiler regression that caused compiler arenas to grow boundlessly. Process was usually OOM-killed before we could take a look, so this was difficult to analyze. > > To improve analysis options, we added NMT *malloc limits* with [JDK-8291878](https://bugs.openjdk.org/browse/JDK-8291878). Malloc limits let us set one or multiple limits to malloc load. Surpassing a limit causes the VM to stop with a fatal error in the allocation function, giving us a hs-err file and a core right at the point that (probably) causes the leak. This makes error analysis a lot simpler, and is also valuable for regression-testing footprint usage. > > Some people wished for a way to not end with a fatal error but to mimic a native OOM (causing os::malloc to return NULL). This would allow us to test resilience in the face of native OOMs, among other things. > > ### Patch > > - Expands the `MallocLimit` option syntax, allowing for an "oom mode" that mimics an oom: > > > > Global form: > -XX:MallocLimit=[:] > Category-specific form: > -XX:MallocLimit=:[:][,:[:] ...] > Examples: > -XX:MallocLimit=3g > -XX:MallocLimit=3g:oom > -XX:MallocLimit=compiler:200m:oom > > > - moves parsing of `-XX:MallocLimit` out of arguments.cpp into `mallocLimit.hpp/cpp`, and rewrites it. > > - changes when limits are checked. Before, the limits were checked *after* the allocation that caused the threshold overflow. Now we check beforehand. > > - removes `MallocMaxTestWords`, replacing its uses with `MallocLimit` > > - adds new gtests and new jtreg tests > > - removes a bunch of jtreg tests which are now better served by the new gtests. > > - gives us more precise error messages upon reaching a limit. For example: > > before: > > # fatal error: MallocLimit: category "Compiler" reached limit (size: 20997680, limit: 20971520) > > > now: > > # fatal error: MallocLimit: reached category "Compiler" limit (triggering allocation size: 1920B, allocated so far: 20505K, limit: 20480K) Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: nullptr ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11371/files - new: https://git.openjdk.org/jdk/pull/11371/files/5817ac71..e8ee4ff1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11371&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11371&range=06-07 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11371.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11371/head:pull/11371 PR: https://git.openjdk.org/jdk/pull/11371 From stuefe at openjdk.org Mon Jan 30 14:32:50 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 30 Jan 2023 14:32:50 GMT Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v7] In-Reply-To: References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com> Message-ID: On Mon, 30 Jan 2023 09:23:48 GMT, Johan Sj?len wrote: > Sorry, could you please convert the NULLs into nullptr :)? Done. Thanks for the review; I'll wait for the final GHAs, then I'll push ------------- PR: https://git.openjdk.org/jdk/pull/11371 From rkennke at openjdk.org Mon Jan 30 14:33:28 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 30 Jan 2023 14:33:28 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v4] In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 20:02:35 GMT, Daniel D. Daugherty wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert UseFastLocking to default to off > > src/hotspot/share/oops/markWord.hpp line 183: > >> 181: } >> 182: markWord set_fast_locked() const { >> 183: return markWord(value() & ~lock_mask_in_place); > > Perhaps add a comment above L183: > > // Clear the lock_mask_in_place bits to set locked_value: Ok, I'm doing that. > src/hotspot/share/runtime/lockStack.cpp line 34: > >> 32: >> 33: LockStack::LockStack() : >> 34: _base(UseFastLocking && !UseHeavyMonitors ? NEW_C_HEAP_ARRAY(oop, INITIAL_CAPACITY, mtSynchronizer) : NULL), > > Okay so `UseFastLocking && UseHeavyMonitors`, then we don't need the lock stack. Yeah if we do UseHeavyMonitors, we only ever lock using monitors. It probably makes sense to reject the combination of flags? OTOH, -UseFastLocking (currently implicit, using stack-locking) && +UseHeavyMonitors would not complain? Seems odd, too. > src/hotspot/share/runtime/lockStack.inline.hpp line 81: > >> 79: } >> 80: } >> 81: validate("post-contains"); > > You only do the `validate("post-contains")` call when `false` is > returned. Why not also validate for the `true` branch? Good point. I am adding the validate call there, too. > src/hotspot/share/runtime/synchronizer.cpp line 568: > >> 566: monitor->set_owner_from_anonymous(current); >> 567: monitor->exit(current); >> 568: } > > Hmmm... We're in `ObjectSynchronizer::exit()` so we should be the owner of > the ObjectMonitor so I'm not yet sure what "Another thread beat us" means. > > XXX See above. 'another thread beat us' refers to the preceding CAS, which can fail if another thread inflated the monitor. I am rephrasing it to be more clear (hopefully). ------------- PR: https://git.openjdk.org/jdk/pull/10907 From rkennke at openjdk.org Mon Jan 30 14:33:35 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 30 Jan 2023 14:33:35 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v5] In-Reply-To: References: Message-ID: <-ImSJ7DFBeTtKn-R9IJcFE8wreHtVHYxWBv743xPa8s=.6ced1034-d7e1-4e23-a53d-81cbda44361a@github.com> On Fri, 27 Jan 2023 20:50:32 GMT, Daniel D. Daugherty wrote: >> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 86 commits: >> >> - Merge branch 'master' into JDK-8291556-v2 >> - Revert UseFastLocking to default to off >> - Change log message inflate(locked) -> inflate(has_locker) >> - Properly set ZF on anon-check path; avoid some conditional branches >> - Use testb when testing for anon owner in fast-path >> - Merge branch 'master' into JDK-8291555-v2 >> - In x86_32 C2 fast_lock(), CAS thread directly, instead of CASing stack-pointer and then storing thread >> - x86 part of optimization to check for anon owner >> - Optimize the check-for-anon-owner fast-path >> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2 >> - ... and 76 more: https://git.openjdk.org/jdk/compare/da80e7a4...784b361c > > src/hotspot/share/runtime/synchronizer.cpp line 1336: > >> 1334: // Success! Return inflated monitor. >> 1335: if (own) { >> 1336: assert(current->is_Java_thread(), "must be: checked in is_lock_owned()"); > > `is_lock_owned()` currently does this: > > > static bool is_lock_owned(Thread* thread, oop obj) { > assert(UseFastLocking, "only call this with fast-locking enabled"); > return thread->is_Java_thread() ? reinterpret_cast(thread)->lock_stack().contains(obj) : false; > } > > > so I would not say "checked in is_locked_owned()" since `is_locked_owned()` does > not enforce that the caller is a JavaThread. If it's not a Java thread, `is_lock_owned()` returns `false`, and we wouldn't end up in the `if (own)` branch. ------------- PR: https://git.openjdk.org/jdk/pull/10907 From rkennke at openjdk.org Mon Jan 30 14:39:20 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 30 Jan 2023 14:39:20 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v4] In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 13:45:35 GMT, Robbin Ehn wrote: > > > I always change the flags in code for the reasons David state and I can't forget to add any flags. > > > (Test batch is stilling running, no failures except MonitorInflationTest.java) > > > > > > Ok, right. > > I just re-ran tier1-3 with the flag changed in code, on aarch64 and x86_64 without regressions. Will run tier4 overnight. > > I did a bigger batch of testing, there were some ThreadMXBean failures with wrong state. I'll investigate, otherwise passed. Thanks, Robbin, for running the tests. Can you let me know which tests failed, so that I can investigate myself? Thanks, Roman ------------- PR: https://git.openjdk.org/jdk/pull/10907 From rkennke at openjdk.org Mon Jan 30 14:45:55 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 30 Jan 2023 14:45:55 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v7] In-Reply-To: References: Message-ID: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Renaissance > > > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Daniel's suggested changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10907/files - new: https://git.openjdk.org/jdk/pull/10907/files/77c8a820..bbe8c186 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=05-06 Stats: 4 lines in 3 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10907.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10907/head:pull/10907 PR: https://git.openjdk.org/jdk/pull/10907 From jcking at openjdk.org Mon Jan 30 14:48:02 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 30 Jan 2023 14:48:02 GMT Subject: RFR: JDK-8301354: Modernize utilities/breakpoint.hpp Message-ID: Cleanup `utilities/breakpoint.hpp` by utilizing compiler intrinsics when available, or normal signals for AIX/XLC. ------------- Commit messages: - Update missed AIX references - Modernize utilities/breakpoint.hpp Changes: https://git.openjdk.org/jdk/pull/12296/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12296&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301354 Stats: 87 lines in 6 files changed: 38 ins; 42 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/12296.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12296/head:pull/12296 PR: https://git.openjdk.org/jdk/pull/12296 From jcking at openjdk.org Mon Jan 30 15:00:51 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 30 Jan 2023 15:00:51 GMT Subject: RFR: JDK-8301354: Modernize utilities/breakpoint.hpp [v2] In-Reply-To: References: Message-ID: > Cleanup `utilities/breakpoint.hpp` by utilizing compiler intrinsics when available, or normal signals for AIX/XLC. Justin King has updated the pull request incrementally with one additional commit since the last revision: Update GCC to use __builtin_trap as a fallback Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12296/files - new: https://git.openjdk.org/jdk/pull/12296/files/de6daca0..af4bef60 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12296&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12296&range=00-01 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12296.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12296/head:pull/12296 PR: https://git.openjdk.org/jdk/pull/12296 From jcking at openjdk.org Mon Jan 30 15:16:40 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 30 Jan 2023 15:16:40 GMT Subject: RFR: JDK-8301354: Modernize utilities/breakpoint.hpp [v3] In-Reply-To: References: Message-ID: > Cleanup `utilities/breakpoint.hpp` by utilizing compiler intrinsics when available, or normal signals for AIX/XLC. Justin King has updated the pull request incrementally with one additional commit since the last revision: Fix reference to unqualified breakpoint Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12296/files - new: https://git.openjdk.org/jdk/pull/12296/files/af4bef60..1b016ec0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12296&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12296&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12296.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12296/head:pull/12296 PR: https://git.openjdk.org/jdk/pull/12296 From rehn at openjdk.org Mon Jan 30 15:26:17 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Mon, 30 Jan 2023 15:26:17 GMT Subject: RFR: 8267935: Replace BasicHashtable and Hashtable In-Reply-To: References: Message-ID: <8XLr8Mx75HEpUQ54srTKJaA8gwyAIbNhG5qzDQxTvdQ=.edb92989-96a3-42ef-a383-131852f7be65@github.com> On Sat, 28 Jan 2023 18:32:31 GMT, Afshin Zafari wrote: > ### Description > Hashtable class to be replaced with ResourceHashtable class in all source code. > > ### Patch > The only instance was `#include "hashtable.hpp"` in `jvmtiTagMapTable.cpp` and removed. > The corresponding files (`hashtable.hpp`, `hashtable.inline.hpp` and `hashtable.cpp`) are removed too. > > ### Test > mach5 tier1 all platforms. Thank you! ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.org/jdk/pull/12275 From tschatzl at openjdk.org Mon Jan 30 16:23:17 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 30 Jan 2023 16:23:17 GMT Subject: RFR: 8267935: Replace BasicHashtable and Hashtable In-Reply-To: References: Message-ID: On Sat, 28 Jan 2023 18:32:31 GMT, Afshin Zafari wrote: > ### Description > Hashtable class to be replaced with ResourceHashtable class in all source code. > > ### Patch > The only instance was `#include "hashtable.hpp"` in `jvmtiTagMapTable.cpp` and removed. > The corresponding files (`hashtable.hpp`, `hashtable.inline.hpp` and `hashtable.cpp`) are removed too. > > ### Test > mach5 tier1 all platforms. Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12275 From duke at openjdk.org Mon Jan 30 16:26:35 2023 From: duke at openjdk.org (Afshin Zafari) Date: Mon, 30 Jan 2023 16:26:35 GMT Subject: Integrated: 8267935: Replace BasicHashtable and Hashtable In-Reply-To: References: Message-ID: On Sat, 28 Jan 2023 18:32:31 GMT, Afshin Zafari wrote: > ### Description > Hashtable class to be replaced with ResourceHashtable class in all source code. > > ### Patch > The only instance was `#include "hashtable.hpp"` in `jvmtiTagMapTable.cpp` and removed. > The corresponding files (`hashtable.hpp`, `hashtable.inline.hpp` and `hashtable.cpp`) are removed too. > > ### Test > mach5 tier1 all platforms. This pull request has now been integrated. Changeset: f4592b14 Author: Afshin Zafari Committer: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/f4592b1471dff02f4e5e21da00c19b957b0a944b Stats: 596 lines in 4 files changed: 0 ins; 596 del; 0 mod 8267935: Replace BasicHashtable and Hashtable Reviewed-by: coleenp, rehn, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/12275 From kbarrett at openjdk.org Mon Jan 30 16:29:27 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 30 Jan 2023 16:29:27 GMT Subject: RFR: JDK-8301224: Replace NULL with nullptr in share/gc/shared/ [v2] In-Reply-To: References: Message-ID: On Mon, 30 Jan 2023 09:24:37 GMT, Johan Sj?len wrote: >> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/gc/shared/. 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: > > Fix kimbarrett's suggestions Changes requested by kbarrett (Reviewer). src/hotspot/share/gc/shared/oopStorage.hpp line 107: > 105: // Allocates and returns a new entry. Returns null if memory allocation > 106: // failed. Locks _allocation_mutex. > 107: // postcondition: result == null or *result == nullptr. Inconsistent mix of "null" and "nullptr". ------------- PR: https://git.openjdk.org/jdk/pull/12249 From kbarrett at openjdk.org Mon Jan 30 16:32:19 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 30 Jan 2023 16:32:19 GMT Subject: RFR: JDK-8301076: Replace NULL with nullptr in share/prims/ [v2] In-Reply-To: References: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> Message-ID: On Mon, 30 Jan 2023 09:30:36 GMT, Johan Sj?len wrote: >> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/prims/. 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: > > FIx suggested changes Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/12188 From jcking at openjdk.org Mon Jan 30 17:05:17 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 30 Jan 2023 17:05:17 GMT Subject: RFR: JDK-8301354: Modernize utilities/breakpoint.hpp [v3] In-Reply-To: References: Message-ID: On Mon, 30 Jan 2023 15:16:40 GMT, Justin King wrote: >> Cleanup `utilities/breakpoint.hpp` by utilizing compiler intrinsics when available, or normal signals for AIX/XLC. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Fix reference to unqualified breakpoint > > Signed-off-by: Justin King Converting back to draft while I investigate some things. ------------- PR: https://git.openjdk.org/jdk/pull/12296 From jcking at openjdk.org Mon Jan 30 17:09:23 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 30 Jan 2023 17:09:23 GMT Subject: RFR: JDK-8301354: Modernize utilities/breakpoint.hpp [v4] In-Reply-To: References: Message-ID: > Cleanup `utilities/breakpoint.hpp` by utilizing compiler intrinsics when available, or normal signals for AIX/XLC. Justin King has updated the pull request incrementally with one additional commit since the last revision: Fix reference to unqualified breakpoint Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12296/files - new: https://git.openjdk.org/jdk/pull/12296/files/1b016ec0..efa83efe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12296&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12296&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12296.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12296/head:pull/12296 PR: https://git.openjdk.org/jdk/pull/12296 From jsjolen at openjdk.org Mon Jan 30 17:50:46 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 30 Jan 2023 17:50:46 GMT Subject: RFR: JDK-8301072: Replace NULL with nullptr in share/oops/ [v4] In-Reply-To: References: Message-ID: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/oops/. 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: static_cast to oop ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12186/files - new: https://git.openjdk.org/jdk/pull/12186/files/10346493..fd9de511 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12186&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12186&range=02-03 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12186.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12186/head:pull/12186 PR: https://git.openjdk.org/jdk/pull/12186 From never at openjdk.org Mon Jan 30 18:24:20 2023 From: never at openjdk.org (Tom Rodriguez) Date: Mon, 30 Jan 2023 18:24:20 GMT Subject: RFR: JDK-8299229: Allow UseZGC with JVMCI and enable nmethod entry barrier support [v4] In-Reply-To: <82zglGU9YCuc-BEAUVJ09xlmEt68DDSqGQ-090Wok20=.92ca342e-7d87-45d2-a23c-e9f4702b2572@github.com> References: <82zglGU9YCuc-BEAUVJ09xlmEt68DDSqGQ-090Wok20=.92ca342e-7d87-45d2-a23c-e9f4702b2572@github.com> Message-ID: On Mon, 23 Jan 2023 20:34:00 GMT, Tom Rodriguez wrote: >> This exposes the required ZGC values to JVMCI and adds support for nmethod entry barriers. The ZGC support is straightforward but the nmethod entry barrier required some reworking to fit better into JVMCI usage. I also removed the epoch based barrier since it was no longer used with simplified the assumptions on the JVMCI side. There is also a minor loom related fix to support post call nops included. I could move that into a separate PR if that would be preferred. > > Tom Rodriguez has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Handle concurrent unloading > - Merge branch 'master' into tkr-zgc > - Add missing declaration > - Replace NULL with nullptr in new code > - Merge branch 'master' into tkr-zgc > - Review fixes > - Allow UseZGC with JVMCI and enable nmethod entry barrier support I see. MethodData::clean_extra_data repacks the extra data section so it's never safe to operate on that section without holding a lock. So I don't think this affects the safety of these changes since JVMCI never reads types from that section. With +UseJVMCICompiler there will never be speculative_trap_data in that section so it will never be shifted. The only case where that could occur is in Truffle hosted mode where c2 is the JIT but Graal is used for Truffle. This is presumably a long standing issue, assuming that we actually even use that path. I'll investigate when we actually read bits data from that section, if at all, and either remove that path or make it safe. ------------- PR: https://git.openjdk.org/jdk/pull/11996 From jsjolen at openjdk.org Mon Jan 30 18:46:17 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 30 Jan 2023 18:46:17 GMT Subject: RFR: JDK-8301072: Replace NULL with nullptr in share/oops/ [v5] In-Reply-To: References: Message-ID: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/oops/. 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: Regular casts ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12186/files - new: https://git.openjdk.org/jdk/pull/12186/files/fd9de511..f6f0d873 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12186&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12186&range=03-04 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/12186.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12186/head:pull/12186 PR: https://git.openjdk.org/jdk/pull/12186 From jsjolen at openjdk.org Mon Jan 30 18:46:22 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 30 Jan 2023 18:46:22 GMT Subject: RFR: JDK-8301072: Replace NULL with nullptr in share/oops/ [v2] In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 14:26:39 GMT, Stefan Karlsson wrote: >> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: >> >> Do stefank's fixes > > Marked as reviewed by stefank (Reviewer). @stefank , we do need to those `oop` casts. The `NativeAccess<>::oop_store` calls makes sense, `oop_store` is templated so we need to provide the type. We also need the casts in `CompressedOops`, and I don't know why that is. ------------- PR: https://git.openjdk.org/jdk/pull/12186 From xliu at openjdk.org Mon Jan 30 20:54:58 2023 From: xliu at openjdk.org (Xin Liu) Date: Mon, 30 Jan 2023 20:54:58 GMT Subject: RFR: 8301136: Improve unlink() and unlink_all() of ResourceHashtableBase [v5] In-Reply-To: <9GAFUt_y36yObC0oOhzxNC05Y8Ja_fkUPxvhZCuFSPY=.255df6aa-d417-4277-9799-a9208e758158@github.com> References: <9GAFUt_y36yObC0oOhzxNC05Y8Ja_fkUPxvhZCuFSPY=.255df6aa-d417-4277-9799-a9208e758158@github.com> Message-ID: On Sun, 29 Jan 2023 06:41:10 GMT, Ioi Lam wrote: >> Xin Liu has updated the pull request incrementally with one additional commit since the last revision: >> >> Add lambda API unlink(Function f) per reviewers' request. > > I updated [JDK-8301296](https://bugs.openjdk.org/browse/JDK-8301296) to clarify the problems with the current ResourceHashtable design and my proposal for fixing them. > > I think the above proposed fixes shouldn't block the progress of this PR, which is just an optimization that maintains the current behavior. So let's continue the discussions here. > > There are two parts of this PR: > > [1] For the optimization (counting the number of entries and exit the loop early), do you have any performance data that shows this is beneficial? > > For this optimization to be beneficial, we must have two conditions -- (a) the table is too large so it's likely to have many unused entries, and (b) the hash function is bad so most of the unused entries are at the end of the table. > > For (a), maybe it's better to change the table to ResizeableResourceHashtable? > For (b), maybe you can also print out the occupancy of the table in your traces like this one (in your earlier PR https://github.com/openjdk/jdk/pull/12016) > > > [12.824s][debug][hashtables] table_size = 109, break at 68 > > > If we have many entries (e.g., 40) but they all pack to the front end of the table, that means we have a bad hash function. > > [2] As I suggested earlier, we should consolidate the code to use a single unlink loop, so you can apply this counting optimization in a single place. > > I am not quite sure why you would need the following in your "wrapper" functions: > > > if (clean) { > *ptr = node->_next; > } else { > ptr = &(node->_next); > } > > > and > > > if (node->_next == nullptr) { > // nullify the bucket when reach the end of linked list. > *ptr = nullptr; > } > > > I wrote a version of the consolidated loop that's much simpler. It also aligns with the old code so the diff is more readable: > > https://github.com/openjdk/jdk/compare/master...iklam:jdk:8301136-resource-hash-unlink-all-suggestion > > Note that I have both `unlink_all()` and `unlink_all(Function function)`, that's because the current API allows the user function to do two things (a) check if the entry should be freed, (b) perform special clean up on the entry. So if you want to free all entries but need to perform special clean up, you'd call `unlink_all(Function function)`. hi, @iklam `unlink(Function f)` is the general API. It removes a selection of nodes. We don't know who is going to be deleted. To be conservative. we have to meticulously maintain the open-chain. `unlink_all()` knows that all nodes are all gone, so we don't need to maintain linked-list at all. Here is an example that an open-chain consists of 3 nodes. It explains why unlink_all() is better than 3 unlink() in a row. We don't need to maintain intermediate states such as `*ptr = &B`. ![unlink_all_3_nodes](https://user-images.githubusercontent.com/2386768/215590069-fff2584f-55d0-4225-996e-44a2f4f0022f.png) For `unlink_all()`, we need to update *bucket when we are at the last node of the open chain. That's that last step in the figure. if (node->_next == nullptr) { // nullify the bucket when reach the end of linked list. *ptr = nullptr; } The destructor version is even simplfied. Because the object is dead anyway, we just cut out all overhead. ------------- PR: https://git.openjdk.org/jdk/pull/12213 From never at openjdk.org Mon Jan 30 21:06:00 2023 From: never at openjdk.org (Tom Rodriguez) Date: Mon, 30 Jan 2023 21:06:00 GMT Subject: RFR: JDK-8299229: Allow UseZGC with JVMCI and enable nmethod entry barrier support [v4] In-Reply-To: <82zglGU9YCuc-BEAUVJ09xlmEt68DDSqGQ-090Wok20=.92ca342e-7d87-45d2-a23c-e9f4702b2572@github.com> References: <82zglGU9YCuc-BEAUVJ09xlmEt68DDSqGQ-090Wok20=.92ca342e-7d87-45d2-a23c-e9f4702b2572@github.com> Message-ID: On Mon, 23 Jan 2023 20:34:00 GMT, Tom Rodriguez wrote: >> This exposes the required ZGC values to JVMCI and adds support for nmethod entry barriers. The ZGC support is straightforward but the nmethod entry barrier required some reworking to fit better into JVMCI usage. I also removed the epoch based barrier since it was no longer used with simplified the assumptions on the JVMCI side. There is also a minor loom related fix to support post call nops included. I could move that into a separate PR if that would be preferred. > > Tom Rodriguez has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Handle concurrent unloading > - Merge branch 'master' into tkr-zgc > - Add missing declaration > - Replace NULL with nullptr in new code > - Merge branch 'master' into tkr-zgc > - Review fixes > - Allow UseZGC with JVMCI and enable nmethod entry barrier support I don't understand how this concurrent repacking of the extra data is safe in general. If an existing record in the extra data section can move at any time then don't operations on that record have to be performed under the lock? Deoptimization::query_update_method_data may allocate a new record and then use it without caring whether it's in the extra data section or not. There's some similar JVMCI updates of the exception_seen that have the same problem. We're probably less exposed since we don't normally have speculative trap entries that would result in repacking. So it seems to me that every caller of allocate_bci_to_data must be holding the extra_data_lock so it can safely use the data. Am I missing something? ------------- PR: https://git.openjdk.org/jdk/pull/11996 From xliu at openjdk.org Mon Jan 30 21:57:56 2023 From: xliu at openjdk.org (Xin Liu) Date: Mon, 30 Jan 2023 21:57:56 GMT Subject: RFR: 8301136: Improve unlink() and unlink_all() of ResourceHashtableBase [v5] In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 23:16:52 GMT, Xin Liu wrote: >> 1. Apply the same idea of JDK-8300184 to unlink(). >> 2. Because ResourceHashtableBase doesn't support copy assignment, client of it has to purge all elements first when it needs to assign it. We would like provide a specialized version called 'unlink_all()'. We don't need to update each node's _next in this case. We only nullify all buckets. >> 3. This patch also provides a specialized version of unlink_all() for destructor. We don't even update buckets. it's dead anyway. > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > Add lambda API unlink(Function f) per reviewers' request. Performance-wise, I will evaluate hotspot and see if I can find support. thanks. ------------- PR: https://git.openjdk.org/jdk/pull/12213 From mseledtsov at openjdk.org Tue Jan 31 00:11:44 2023 From: mseledtsov at openjdk.org (Mikhailo Seledtsov) Date: Tue, 31 Jan 2023 00:11:44 GMT Subject: RFR: 8294402: Add diagnostic logging to VMProps.checkDockerSupport Message-ID: <_X-xpw_Wz6dtbi5Z6u2b_g68sKSQqX5W_99c0aOXaAY=.a520a70a-66b4-4c51-a57a-388836404541@github.com> Add log() and logToFile() methods to VMProps for diagnostic purposes. ------------- Commit messages: - Minor fixes in printed message - Log to stderr as per discussion - Fixed issues with process out/err redirect - Simplification and refactoring - Draft: redirect container ps child output to log file - More logging for container methods - Allow both absolute and relative path for log file - Add diagnostic logging to at-requires VMProps Changes: https://git.openjdk.org/jdk/pull/12239/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12239&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294402 Stats: 40 lines in 1 file changed: 38 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12239.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12239/head:pull/12239 PR: https://git.openjdk.org/jdk/pull/12239 From fyang at openjdk.org Tue Jan 31 00:14:05 2023 From: fyang at openjdk.org (Fei Yang) Date: Tue, 31 Jan 2023 00:14:05 GMT Subject: RFR: 8300463: Build failure on Windows 32 after JDK-8296401 [v2] In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 13:56:23 GMT, Kim Barrett wrote: >> Fei Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> Comment > > Looks good. @kimbarrett : Thanks for the review! ------------- PR: https://git.openjdk.org/jdk/pull/12178 From fyang at openjdk.org Tue Jan 31 00:14:07 2023 From: fyang at openjdk.org (Fei Yang) Date: Tue, 31 Jan 2023 00:14:07 GMT Subject: Integrated: 8300463: Build failure on Windows 32 after JDK-8296401 In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 05:43:52 GMT, Fei Yang wrote: > This issue also triggers when building slowdebug on linux-aarch64 with GCC-9.4.0. Given that std::numeric_limits::max() returns positive integer number and size_t is an unsigned type, I guess it's safe to do simple static_cast here both on 32-bit and 64-bit platfoms. Slowdebug on linux-aarch64 builds fine with this fix. This pull request has now been integrated. Changeset: aa349244 Author: Fei Yang URL: https://git.openjdk.org/jdk/commit/aa3492442bb89f84c6427ced0bd687d6a10839cf Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8300463: Build failure on Windows 32 after JDK-8296401 Reviewed-by: kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/12178 From dholmes at openjdk.org Tue Jan 31 00:19:28 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 31 Jan 2023 00:19:28 GMT Subject: RFR: 8294402: Add diagnostic logging to VMProps.checkDockerSupport [v2] In-Reply-To: References: <_X-xpw_Wz6dtbi5Z6u2b_g68sKSQqX5W_99c0aOXaAY=.a520a70a-66b4-4c51-a57a-388836404541@github.com> Message-ID: On Tue, 31 Jan 2023 00:14:45 GMT, Mikhailo Seledtsov wrote: >> Add log() and logToFile() methods to VMProps for diagnostic purposes. > > Mikhailo Seledtsov has updated the pull request incrementally with two additional commits since the last revision: > > - Comment about logging to stdout > - Conditionally enable VMProps logging test/jtreg-ext/requires/VMProps.java line 531: > 529: log("checkDockerSupport(): entering"); > 530: ProcessBuilder pb = new ProcessBuilder(Container.ENGINE_COMMAND, "ps"); > 531: redirectOutputToLogFile("checkDockerSupport(): ps", pb, "container-ps"); I was thinking it would be better to see this output in the main log, rather than have to go and find the file later. Where would the file even be found? test/jtreg-ext/requires/VMProps.java line 659: > 657: protected static void log(String msg) { > 658: // By jtreg design stderr produced here will be visible > 659: // in the output of a parent process. Suggest extending the comment: // in the output of a parent process. stdout should not be used for logging as jtreg parses that output directly // and only echoes it in the event of a failure. ------------- PR: https://git.openjdk.org/jdk/pull/12239 From mseledtsov at openjdk.org Tue Jan 31 00:19:28 2023 From: mseledtsov at openjdk.org (Mikhailo Seledtsov) Date: Tue, 31 Jan 2023 00:19:28 GMT Subject: RFR: 8294402: Add diagnostic logging to VMProps.checkDockerSupport [v2] In-Reply-To: <_X-xpw_Wz6dtbi5Z6u2b_g68sKSQqX5W_99c0aOXaAY=.a520a70a-66b4-4c51-a57a-388836404541@github.com> References: <_X-xpw_Wz6dtbi5Z6u2b_g68sKSQqX5W_99c0aOXaAY=.a520a70a-66b4-4c51-a57a-388836404541@github.com> Message-ID: > Add log() and logToFile() methods to VMProps for diagnostic purposes. Mikhailo Seledtsov has updated the pull request incrementally with two additional commits since the last revision: - Comment about logging to stdout - Conditionally enable VMProps logging ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12239/files - new: https://git.openjdk.org/jdk/pull/12239/files/7851e5d4..881a547e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12239&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12239&range=00-01 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12239.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12239/head:pull/12239 PR: https://git.openjdk.org/jdk/pull/12239 From dholmes at openjdk.org Tue Jan 31 00:52:58 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 31 Jan 2023 00:52:58 GMT Subject: RFR: 8301244: Replace legacy pragma implementations in HotSpot's compilerWarnings.hpp [v7] In-Reply-To: References: Message-ID: <7-JCgLLMTzhjozABd6qUL6io-2qyaxO-k_XPUxXPNU0=.9058cd60-370d-4aab-ab57-715a0a24641a@github.com> On Sun, 29 Jan 2023 06:38:19 GMT, Julian Waters wrote: >> HotSpot has a few legacy implementations of pragmas in some of its macros in compilerWarnings.hpp, they should be cleaned up and use a more modern approach. Rename PRAGMA macro in compilerWarnings_gcc.hpp as well since it can be used for more than just compiler warnings > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > compilerWarnings_gcc.hpp Is the intent here to allow `PRAGMA_UTIL` to be used in other code to add pragmas? I'm not seeing how that could work as they would still be compiler specific and if the use is ifdef'd then you don't need the `PRAGMA_UTIL` macro (not a great name). ------------- PR: https://git.openjdk.org/jdk/pull/12255 From mseledtsov at openjdk.org Tue Jan 31 01:07:13 2023 From: mseledtsov at openjdk.org (Mikhailo Seledtsov) Date: Tue, 31 Jan 2023 01:07:13 GMT Subject: RFR: 8294402: Add diagnostic logging to VMProps.checkDockerSupport [v2] In-Reply-To: References: <_X-xpw_Wz6dtbi5Z6u2b_g68sKSQqX5W_99c0aOXaAY=.a520a70a-66b4-4c51-a57a-388836404541@github.com> Message-ID: On Tue, 31 Jan 2023 00:11:11 GMT, David Holmes wrote: >> Mikhailo Seledtsov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Comment about logging to stdout >> - Conditionally enable VMProps logging > > test/jtreg-ext/requires/VMProps.java line 659: > >> 657: protected static void log(String msg) { >> 658: // By jtreg design stderr produced here will be visible >> 659: // in the output of a parent process. > > Suggest extending the comment: > > // in the output of a parent process. stdout should not be used for logging as jtreg parses that output directly > // and only echoes it in the event of a failure. Thanks. Will update the comment. ------------- PR: https://git.openjdk.org/jdk/pull/12239 From dholmes at openjdk.org Tue Jan 31 01:08:01 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 31 Jan 2023 01:08:01 GMT Subject: RFR: JDK-8300783: Consolidate byteswap implementations [v12] In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 17:00:58 GMT, Justin King wrote: >> Deduplicate byte swapping implementations by consolidating them into `utilities/byteswap.hpp`, following `std::byteswap` introduced in C++23. Further simplification of `Bytes` will follow in https://github.com/openjdk/jdk/pull/12078. > > Justin King has updated the pull request incrementally with four additional commits since the last revision: > > - Update copyright > > Signed-off-by: Justin King > - Add missing include > > Signed-off-by: Justin King > - Remove unused include > > Signed-off-by: Justin King > - Reorganize tests > > Signed-off-by: Justin King Updates are fine - thanks. I'll try to get someone to properly review this. test/hotspot/gtest/utilities/test_byteswap.cpp line 2: > 1: /* > 2: * Copyright (c) 2022, 2023, Oracle and/or its affiliates. All rights reserved. As a new file this should only have 2023 copyright year - thanks. ------------- PR: https://git.openjdk.org/jdk/pull/12114 From dholmes at openjdk.org Tue Jan 31 01:13:00 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 31 Jan 2023 01:13:00 GMT Subject: RFR: JDK-8301072: Replace NULL with nullptr in share/oops/ [v5] In-Reply-To: References: Message-ID: On Mon, 30 Jan 2023 18:46:17 GMT, Johan Sj?len wrote: >> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/oops/. 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: > > Regular casts Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12186 From mseledtsov at openjdk.org Tue Jan 31 01:16:59 2023 From: mseledtsov at openjdk.org (Mikhailo Seledtsov) Date: Tue, 31 Jan 2023 01:16:59 GMT Subject: RFR: 8294402: Add diagnostic logging to VMProps.checkDockerSupport [v2] In-Reply-To: References: <_X-xpw_Wz6dtbi5Z6u2b_g68sKSQqX5W_99c0aOXaAY=.a520a70a-66b4-4c51-a57a-388836404541@github.com> Message-ID: On Tue, 31 Jan 2023 00:08:20 GMT, David Holmes wrote: >> Mikhailo Seledtsov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Comment about logging to stdout >> - Conditionally enable VMProps logging > > test/jtreg-ext/requires/VMProps.java line 531: > >> 529: log("checkDockerSupport(): entering"); >> 530: ProcessBuilder pb = new ProcessBuilder(Container.ENGINE_COMMAND, "ps"); >> 531: redirectOutputToLogFile("checkDockerSupport(): ps", pb, "container-ps"); > > I was thinking it would be better to see this output in the main log, rather than have to go and find the file later. Where would the file even be found? Files containing redirected stdout and stderr will be in the jtreg working directory, usually JTwork/scratch/. I tried to keep the code as simple as possible, and found that redirecting the output of a child process to a file is the simplest option. Capturing child process output might involve quite a bit of code, pumping/draining the output to a buffer then printing the buffer out to the main logging method. E.g. see OutputAnalyzer. Also note that we can not simply use test utils library such as output analyzer. Every depended non-core library has to be declared in TEST.ROOT as: requires.extraPropDefns.libs = \ ../../lib/jdk/test/lib/Platform.java \ ../../lib/jdk/test/lib/Container.java I tried to add OutputAnalyzer here, but it does require lot's of dependencies and the list grew large. Let me know if I should do this anyway even if it adds more code to vmprops. ------------- PR: https://git.openjdk.org/jdk/pull/12239 From dholmes at openjdk.org Tue Jan 31 02:26:02 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 31 Jan 2023 02:26:02 GMT Subject: RFR: JDK-8301076: Replace NULL with nullptr in share/prims/ [v2] In-Reply-To: References: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> Message-ID: On Mon, 30 Jan 2023 09:30:36 GMT, Johan Sj?len wrote: >> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/prims/. 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: > > FIx suggested changes A few adjustments but overall looks good. Thanks. src/hotspot/share/prims/jni.cpp line 2166: > 2164: bool is_latin1 = java_lang_String::is_latin1(s); > 2165: buf = NEW_C_HEAP_ARRAY_RETURN_NULL(jchar, s_len + 1, mtInternal); // add one for zero termination > 2166: /* JNI Specification states return nullptr on OOM */ null src/hotspot/share/prims/jvmtiCodeBlobEvents.cpp line 56: > 54: // collector.collect(); > 55: // JvmtiCodeBlobDesc* blob = collector.first(); > 56: // while (blob != null) { nullptr src/hotspot/share/prims/jvmtiEnv.cpp line 581: > 579: > 580: if (event_thread == nullptr) { > 581: // Can be called at Agent_OnLoad() time with event_thread == null nullptr src/hotspot/share/prims/jvmtiEnvBase.hpp line 170: > 168: }; > 169: > 170: // If (thread == null) then return current thread object. nullptr src/hotspot/share/prims/jvmtiEnvBase.hpp line 184: > 182: oop cur_obj = current->jvmti_vthread(); > 183: > 184: // cur_obj == null is true for normal platform threads only nullptr src/hotspot/share/prims/jvmtiEventController.hpp line 214: > 212: > 213: // Use (thread == null) to enable/disable an event globally. > 214: // Use (thread != null) to enable/disable an event for a particular thread. nullptr ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12188 From apangin at openjdk.org Tue Jan 31 02:30:59 2023 From: apangin at openjdk.org (Andrei Pangin) Date: Tue, 31 Jan 2023 02:30:59 GMT Subject: RFR: JDK-8299229: Allow UseZGC with JVMCI and enable nmethod entry barrier support [v4] In-Reply-To: <82zglGU9YCuc-BEAUVJ09xlmEt68DDSqGQ-090Wok20=.92ca342e-7d87-45d2-a23c-e9f4702b2572@github.com> References: <82zglGU9YCuc-BEAUVJ09xlmEt68DDSqGQ-090Wok20=.92ca342e-7d87-45d2-a23c-e9f4702b2572@github.com> Message-ID: On Mon, 23 Jan 2023 20:34:00 GMT, Tom Rodriguez wrote: >> This exposes the required ZGC values to JVMCI and adds support for nmethod entry barriers. The ZGC support is straightforward but the nmethod entry barrier required some reworking to fit better into JVMCI usage. I also removed the epoch based barrier since it was no longer used with simplified the assumptions on the JVMCI side. There is also a minor loom related fix to support post call nops included. I could move that into a separate PR if that would be preferred. > > Tom Rodriguez has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Handle concurrent unloading > - Merge branch 'master' into tkr-zgc > - Add missing declaration > - Replace NULL with nullptr in new code > - Merge branch 'master' into tkr-zgc > - Review fixes > - Allow UseZGC with JVMCI and enable nmethod entry barrier support src/hotspot/share/gc/shared/barrierSetNMethod.cpp line 70: > 68: if (nm->is_native_method() || nm->is_compiled_by_c2() || nm->is_compiled_by_c1()) { > 69: return true; > 70: } I wonder why `is_native_method` automatically implies `supports_entry_barrier == true`. Apparently JVMCI is not supposed to compile native methods (without entry barrier), however, this seems too restrictive to me. Should not we swap the order of the checks? E.g. if (nm->is_compiled_by_jvmci()) { return nm->jvmci_nmethod_data()->has_entry_barrier(); } if (nm->is_native_method() || nm->is_compiled_by_c2() || nm->is_compiled_by_c1()) { return true; } ------------- PR: https://git.openjdk.org/jdk/pull/11996 From dholmes at openjdk.org Tue Jan 31 04:25:58 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 31 Jan 2023 04:25:58 GMT Subject: RFR: JDK-8301354: Modernize utilities/breakpoint.hpp [v4] In-Reply-To: References: Message-ID: On Mon, 30 Jan 2023 17:09:23 GMT, Justin King wrote: >> Cleanup `utilities/breakpoint.hpp` by utilizing compiler intrinsics when available, or normal signals for AIX/XLC. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Fix reference to unqualified breakpoint > > Signed-off-by: Justin King So you are turning something currently OS-specific into something toolchain specific, and I'm not sure that is really correct, or even necessary. src/hotspot/share/utilities/breakpoint.hpp line 2: > 1: /* > 2: * Copyright (c) 2023, Google and/or its affiliates. All rights reserved. Please restore the Oracle copyright with second year updated to 2023. Thanks. src/hotspot/share/utilities/breakpoint.hpp line 60: > 58: #define BREAKPOINT ::raise(SIGTRAP) > 59: > 60: #elif defined(SIGINT) The VM already uses SIGINT to shutdown the VM - raising it here doesn't seem right. ------------- PR: https://git.openjdk.org/jdk/pull/12296 From dholmes at openjdk.org Tue Jan 31 04:37:57 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 31 Jan 2023 04:37:57 GMT Subject: RFR: 8294402: Add diagnostic logging to VMProps.checkDockerSupport [v2] In-Reply-To: References: <_X-xpw_Wz6dtbi5Z6u2b_g68sKSQqX5W_99c0aOXaAY=.a520a70a-66b4-4c51-a57a-388836404541@github.com> Message-ID: On Tue, 31 Jan 2023 01:13:48 GMT, Mikhailo Seledtsov wrote: >> test/jtreg-ext/requires/VMProps.java line 531: >> >>> 529: log("checkDockerSupport(): entering"); >>> 530: ProcessBuilder pb = new ProcessBuilder(Container.ENGINE_COMMAND, "ps"); >>> 531: redirectOutputToLogFile("checkDockerSupport(): ps", pb, "container-ps"); >> >> I was thinking it would be better to see this output in the main log, rather than have to go and find the file later. Where would the file even be found? > > Files containing redirected stdout and stderr will be in the jtreg working directory, usually JTwork/scratch/. > I tried to keep the code as simple as possible, and found that redirecting the output of a child process to a file is the simplest option. Capturing child process output might involve quite a bit of code, pumping/draining the output to a buffer then printing the buffer out to the main logging method. E.g. see OutputAnalyzer. > > Also note that we can not simply use test utils library such as output analyzer. Every depended non-core library has to be declared in TEST.ROOT as: > requires.extraPropDefns.libs = \ > ../../lib/jdk/test/lib/Platform.java \ > ../../lib/jdk/test/lib/Container.java > > I tried to add OutputAnalyzer here, but it does require lot's of dependencies and the list grew large. > > Let me know if I should do this anyway even if it adds more code to vmprops. Granted creating the file is much simpler than capturing the child process output directly, but can we not read the file back in and then include it in the main log? I'm assuming the output of container-ps is going to be quite small. We could also choose to include it only if there appears to have been an error. Though we could always expand on this later if the current simple approach doesn't suffice. ------------- PR: https://git.openjdk.org/jdk/pull/12239 From xliu at openjdk.org Tue Jan 31 04:52:59 2023 From: xliu at openjdk.org (Xin Liu) Date: Tue, 31 Jan 2023 04:52:59 GMT Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof [v3] In-Reply-To: References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com> <1VvY0OUOTV6QoOICCC7D-bossOFuNcElgxJwOK0ATcg=.4d805893-07a4-4c0c-b9c0-82a2ee3be0cf@github.com> <1hEloz4xpYz6Ofo_RItjyhbSYfv8OY_f11SSvCgFjL8=.8c3d3051-54fb-4436-be68-7b493ddb6af5@github.com> <1vFS7xsbqeW1z1TrrnwCuHCwfMbD54xglwPZP0kwNMc=.a495a2c5-501c-4151-bc7c-590b5c05b5fd@github.com> <6XauuplEHiyDoz21XH5fWW66JN31ldZ5rTv9qyizgLU=.dde4c07e-1fa7-469d-b5a7-2b8f16e9bc50@github.com> <9dsr0Sptq5SecHkc1jZLzas3_rBdlEHwhJgo4VjBnTU=.2f7b4377-f62a-4214-abbb-8479ccc73a41@github.com> Message-ID: On Sat, 28 Jan 2023 13:13:16 GMT, Kim Barrett wrote: >>> In order to access through an object, the object must be correctly aligned for its type, else UB. >> >> hi, @kimbarrett, >> Thanks you for letting me know `alignof`. >> >> I know the concept of 'nature alignment'. an object is aligned to its size. The rule is enforced by C/C++ compiler. Is it really UB if I violate it? >> >> In this case, sizeof(Message) is 64. I don't think we have to put an instance of Message at an address which can be divided by 64. In particular, Message is POD. We would like to have compact 'buffer'. > >> > In order to access through an object, the object must be correctly aligned for its type, else UB. >> >> hi, @kimbarrett, Thanks you for letting me know `alignof`. >> >> I know the concept of 'nature alignment'. an object is aligned to its size. The rule is enforced by C/C++ compiler. Is it really UB if I violate it? >> >> In this case, sizeof(Message) is 64. I don't think we have to put an instance of Message at an address which can be divided by 64. In particular, Message is POD. We would like to have compact 'buffer'. > > Objects are not aligned to their size. Alignment and size are independent > properties of a type. The alignment of fundamental types is determined by ABI > and processor constraints. It's common for fundamental types to have alignment > requirements equal to their size. Compound types generally (barring use of > `alignas` specifiers and maybe other corner cases I'm forgetting) have the > maximum alignment of their components, to ensure the components are properly > aligned. This may result in the compiler adding padding between class members. > > And yes, misaligned accesses are UB. > > BTW, `Message` is not POD. It might be standard-layout (I haven't checked). Hi, @kimbarrett Thank you for the explanation. I will look into this issue and track it using a standalone JBS. If gcc/ub-santizer flags "Message" is UB, I plan to give up placement-new and fall back to C-style 'struct'. ------------- PR: https://git.openjdk.org/jdk/pull/11761 From iklam at openjdk.org Tue Jan 31 05:49:35 2023 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 31 Jan 2023 05:49:35 GMT Subject: RFR: 8296344: Remove dependency on G1 for writing the CDS archive heap Message-ID: Goals - Simplify the writing of the CDS archive heap - We no longer need to allocate special "archive regions" during CDS dump time. See all the removed G1 code. - Make it possible to (in a future RFE) write the CDS archive heap using any garbage collector Implementation - the following runs inside a safepoint so heap objects aren't moving - Find all the objects that should be archived - Allocate buffer using a GrowableArray - Copy all "open" objects into the buffer - Copy all "closed" objects into the buffer - Make sure the heap image can be mapped with all possible G1 region sizes: - While copying, add fillers to make sure no object spans across 1MB boundary (minimal G1 region size) - Align the bottom of the "open" and "closed" objects at 1MB boundary - Write the buffer to disk as the image for the archive heap Testing: tiers 1 ~ 5 ------------- Commit messages: - clean up - 8296344: Remove dependency on G1 for writing the CDS archive heap (step 2: no intermediate buffer) - 8296344: Remove dependency on G1 for writing the CDS archive heap (step 1: with buffer copying) Changes: https://git.openjdk.org/jdk/pull/12304/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12304&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296344 Stats: 1925 lines in 26 files changed: 912 ins; 860 del; 153 mod Patch: https://git.openjdk.org/jdk/pull/12304.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12304/head:pull/12304 PR: https://git.openjdk.org/jdk/pull/12304 From yadongwang at openjdk.org Tue Jan 31 06:22:58 2023 From: yadongwang at openjdk.org (Yadong Wang) Date: Tue, 31 Jan 2023 06:22:58 GMT Subject: RFR: 8301067: RISC-V: better error message when reporting unsupported satp modes [v2] In-Reply-To: <2NahsNo8EI8V_CDlWLJFn_JXFGeok8dFPwHg-gn7egc=.a6be71e9-58e5-4260-8328-f7f153da733f@github.com> References: <2NahsNo8EI8V_CDlWLJFn_JXFGeok8dFPwHg-gn7egc=.a6be71e9-58e5-4260-8328-f7f153da733f@github.com> Message-ID: <1ZkfUCnZyqG9YY692dsh9HjnfegK_XewrmTPwiYSDTo=.ad790d90-805c-4f35-a7f9-c8fa2e64fbed@github.com> On Sat, 28 Jan 2023 03:14:47 GMT, Feilong Jiang wrote: >> Add more detailed information to the error log when reporting unsupported stap modes. >> Currently, RISC-V port only supports up to sv48. > > Feilong Jiang 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 better_error_info > - add more information when reporting unsuppoted satp modes lgtm ------------- Marked as reviewed by yadongwang (Author). PR: https://git.openjdk.org/jdk/pull/12247 From fjiang at openjdk.org Tue Jan 31 07:01:03 2023 From: fjiang at openjdk.org (Feilong Jiang) Date: Tue, 31 Jan 2023 07:01:03 GMT Subject: RFR: 8301067: RISC-V: better error message when reporting unsupported satp modes [v2] In-Reply-To: References: <2NahsNo8EI8V_CDlWLJFn_JXFGeok8dFPwHg-gn7egc=.a6be71e9-58e5-4260-8328-f7f153da733f@github.com> Message-ID: <-Y798oqc6LdzHNHo0O-MrewGL7ewO19e5IopWORO7s8=.dd5ef196-3cfc-4b47-be69-823489cb706d@github.com> On Sat, 28 Jan 2023 03:29:44 GMT, Fei Yang wrote: >> Feilong Jiang 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 better_error_info >> - add more information when reporting unsuppoted satp modes > > Marked as reviewed by fyang (Reviewer). @RealFYang @yadongw -- Thanks for the reviews! ------------- PR: https://git.openjdk.org/jdk/pull/12247 From fjiang at openjdk.org Tue Jan 31 07:19:17 2023 From: fjiang at openjdk.org (Feilong Jiang) Date: Tue, 31 Jan 2023 07:19:17 GMT Subject: Integrated: 8301067: RISC-V: better error message when reporting unsupported satp modes In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 09:39:46 GMT, Feilong Jiang wrote: > Add more detailed information to the error log when reporting unsupported stap modes. > Currently, RISC-V port only supports up to sv48. This pull request has now been integrated. Changeset: 633e291c Author: Feilong Jiang Committer: Fei Yang URL: https://git.openjdk.org/jdk/commit/633e291cfc9129ca28643b3a6fcb72294d2ef767 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8301067: RISC-V: better error message when reporting unsupported satp modes Reviewed-by: fyang, yadongwang ------------- PR: https://git.openjdk.org/jdk/pull/12247 From ayang at openjdk.org Tue Jan 31 07:32:42 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 31 Jan 2023 07:32:42 GMT Subject: RFR: 8301446: Remove unused includes of gc/shared/genOopClosures Message-ID: Simple removing unused includes. ------------- Commit messages: - cleanup-genoopclosure-header Changes: https://git.openjdk.org/jdk/pull/12307/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12307&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301446 Stats: 5 lines in 5 files changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12307.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12307/head:pull/12307 PR: https://git.openjdk.org/jdk/pull/12307 From stefank at openjdk.org Tue Jan 31 08:37:57 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 31 Jan 2023 08:37:57 GMT Subject: RFR: 8301446: Remove unused includes of gc/shared/genOopClosures In-Reply-To: References: Message-ID: On Tue, 31 Jan 2023 07:25:05 GMT, Albert Mingkun Yang wrote: > Simple removing unused includes. Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12307 From eosterlund at openjdk.org Tue Jan 31 08:45:59 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 31 Jan 2023 08:45:59 GMT Subject: RFR: JDK-8299229: Allow UseZGC with JVMCI and enable nmethod entry barrier support [v4] In-Reply-To: References: <82zglGU9YCuc-BEAUVJ09xlmEt68DDSqGQ-090Wok20=.92ca342e-7d87-45d2-a23c-e9f4702b2572@github.com> Message-ID: On Mon, 30 Jan 2023 21:03:00 GMT, Tom Rodriguez wrote: > I don't understand how this concurrent repacking of the extra data is safe in general. If an existing record in the extra data section can move at any time then don't operations on that record have to be performed under the lock? Deoptimization::query_update_method_data may allocate a new record and then use it without caring whether it's in the extra data section or not. There's some similar JVMCI updates of the exception_seen that have the same problem. We're probably less exposed since we don't normally have speculative trap entries that would result in repacking. So it seems to me that every caller of allocate_bci_to_data must be holding the extra_data_lock so it can safely use the data. Am I missing something? You are right, Deoptimization::query_update_method_data does looks like it has a bug. You need to either hold the extra_data_lock when using entries from the extra data section, or force cleaning first, so that existing entries won't move around until the next safepoint poll. The ciMethodData performs cleaning in its replica and keeping all of its type alive, making it safe to use, but extra care needs to be taken when using the MDO directly. ------------- PR: https://git.openjdk.org/jdk/pull/11996 From jwaters at openjdk.org Tue Jan 31 09:08:58 2023 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 31 Jan 2023 09:08:58 GMT Subject: RFR: 8301244: Replace legacy pragma implementations in HotSpot's compilerWarnings.hpp [v7] In-Reply-To: References: Message-ID: On Sun, 29 Jan 2023 06:38:19 GMT, Julian Waters wrote: >> HotSpot has a few legacy implementations of pragmas in some of its macros in compilerWarnings.hpp, they should be cleaned up and use a more modern approach. Rename PRAGMA macro in compilerWarnings_gcc.hpp as well since it can be used for more than just compiler warnings > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > compilerWarnings_gcc.hpp The aim was to introduce a way to easily use pragmas inside macro implementations in HotSpot which behave identically to if one had used `#pragma`, regardless of any quirks on any platform/compiler, competing with the regular `#pragma` preprocessor directive is otherwise not the goal of this change. Defining differing pragmas which are compiler specific based on `#ifdef` blocks are a different issue too, all this proposal intends to do is make it easy for defining pragmas inside macros, as mentioned above. The vast majority of the compilers that can be used to compile HotSpot (that is to say, all of them except for Visual C++) don't have an easy way to do this that doesn't involve the hassle of defining one-off helper macros directly where they're used to expand the input to properly feed into `_Pragma` (see compilerWarnings_gcc.hpp for instance). I get that this might sound slightly petty, but I'd prefer if macros defined for the sole purpose of solving a local issue were somewhat kept to a minimum in HotSpot if they could be avoided. This can also be especially helpful in shared code where a one-for-all macro that contains a pragma is needed, where there is much less incentive for deciding on using __pragma or not. Regarding Kim's concerns, I could indeed make the implementation use __pragma if `#ifdef _MSC_VER` is true, but I don't really see the need for doing that, since Visual C++ pretty much treats __pragma and `_Pragma` identically (to the point that they share the same bugs), and doing so would just be extra code which would behave the same I forgot to mention `PRAGMA_UTIL` was just `PRAGMA` earlier on and in macros.hpp, I changed it after hearing Kim's concerns, but now after looking back at it I think I should've kept it for review ------------- PR: https://git.openjdk.org/jdk/pull/12255 From jwaters at openjdk.org Tue Jan 31 09:17:22 2023 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 31 Jan 2023 09:17:22 GMT Subject: RFR: 8301244: Replace legacy pragma implementations in HotSpot's compilerWarnings.hpp [v8] In-Reply-To: References: Message-ID: > HotSpot has a few legacy implementations of pragmas in some of its macros in compilerWarnings.hpp, they should be cleaned up and use a more modern approach. Rename PRAGMA macro in compilerWarnings_gcc.hpp as well since it can be used for more than just compiler warnings Julian Waters has updated the pull request incrementally with four additional commits since the last revision: - gcc - VISCPP - Comment - Re-add PRAGMA ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12255/files - new: https://git.openjdk.org/jdk/pull/12255/files/de049888..8ba0ff35 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12255&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12255&range=06-07 Stats: 11 lines in 3 files changed: 3 ins; 2 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/12255.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12255/head:pull/12255 PR: https://git.openjdk.org/jdk/pull/12255 From stuefe at openjdk.org Tue Jan 31 09:18:01 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 31 Jan 2023 09:18:01 GMT Subject: RFR: JDK-8301354: Modernize utilities/breakpoint.hpp [v4] In-Reply-To: References: Message-ID: On Mon, 30 Jan 2023 17:09:23 GMT, Justin King wrote: >> Cleanup `utilities/breakpoint.hpp` by utilizing compiler intrinsics when available, or normal signals for AIX/XLC. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Fix reference to unqualified breakpoint > > Signed-off-by: Justin King Hi Justin, please note that at least on PPC platforms we use SIGTRAP for implicit null checks; so gcc debug trap won't work as expected. Also, IIUC this changes os::breakpoint() on GCC platforms and AIX from being a manual opt-in to an unconditional trap right? While this is more in sync with what we do on Windows, this behavior has been in there a long time and may confuse people. Finally, there is this worrying info: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84595 where it seems the GCC optimizes everything after a trap away? Can that happen with debugtrap too? ..Thomas ------------- PR: https://git.openjdk.org/jdk/pull/12296 From jwaters at openjdk.org Tue Jan 31 09:21:36 2023 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 31 Jan 2023 09:21:36 GMT Subject: RFR: 8250269: Replace ATTRIBUTE_ALIGNED with alignas [v14] In-Reply-To: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com> References: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com> Message-ID: > 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 13 additional commits since the last revision: - 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 - ATTRIBUTE_ALIGNED(16) - Merge branch 'openjdk:master' into alignas - ... and 3 more: https://git.openjdk.org/jdk/compare/a88000cb...b36f835c ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11431/files - new: https://git.openjdk.org/jdk/pull/11431/files/7792baa5..b36f835c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11431&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11431&range=12-13 Stats: 40974 lines in 2196 files changed: 16048 ins; 6327 del; 18599 mod Patch: https://git.openjdk.org/jdk/pull/11431.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11431/head:pull/11431 PR: https://git.openjdk.org/jdk/pull/11431 From ayang at openjdk.org Tue Jan 31 09:26:52 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 31 Jan 2023 09:26:52 GMT Subject: RFR: 8301465: Remove unnecessary nmethod arming in Full GC of Serial/Parallel Message-ID: Simple removing unnecessary code and adding API documentation. Test: hotspot_gc ------------- Commit messages: - arm-nmethod Changes: https://git.openjdk.org/jdk/pull/12311/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12311&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301465 Stats: 8 lines in 3 files changed: 6 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12311.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12311/head:pull/12311 PR: https://git.openjdk.org/jdk/pull/12311 From jsjolen at openjdk.org Tue Jan 31 09:33:01 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 31 Jan 2023 09:33:01 GMT Subject: RFR: JDK-8301076: Replace NULL with nullptr in share/prims/ [v2] In-Reply-To: References: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> Message-ID: <3zRF1SdYdOEWTkSUPkdwvBNnfpY1KFMnaqDwsbcyTJQ=.ba66944a-bd5c-4afa-8ec9-7ee29d601cdd@github.com> On Mon, 30 Jan 2023 09:30:36 GMT, Johan Sj?len wrote: >> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/prims/. 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: > > FIx suggested changes All tests passing in GHA. @alexmenkov , would you mind approving :)? ------------- PR: https://git.openjdk.org/jdk/pull/12188 From kbarrett at openjdk.org Tue Jan 31 09:42:56 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 31 Jan 2023 09:42:56 GMT Subject: RFR: 8301446: Remove unused includes of gc/shared/genOopClosures In-Reply-To: References: Message-ID: <801o_er6sQNl3B5ELwC-lvc1mlBUCphKmdcRNQgU4yw=.4e188484-1939-4e30-b0eb-1d3da517a11d@github.com> On Tue, 31 Jan 2023 07:25:05 GMT, Albert Mingkun Yang wrote: > Simple removing unused includes. Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/12307 From stefank at openjdk.org Tue Jan 31 09:56:07 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 31 Jan 2023 09:56:07 GMT Subject: RFR: JDK-8301072: Replace NULL with nullptr in share/oops/ [v2] In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 14:26:39 GMT, Stefan Karlsson wrote: >> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: >> >> Do stefank's fixes > > Marked as reviewed by stefank (Reviewer). > @stefank , we do need to those `oop` casts. The `NativeAccess<>::oop_store` calls makes sense, `oop_store` is templated so we need to provide the type. We also need the casts in `CompressedOops`, and I don't know why that is. I took a look at this. And as far as I can see, there's no obvious problem with the oop_store ore CompressedOops changes, but with the NativeAccess<>::oop_load changes. NativeAccess<>::oop_load returns an OopLoadProxy object instead of oop, which causes the following code: inline oop OopHandle::resolve() const { return (_obj == nullptr) ? nullptr : NativeAccess<>::oop_load(_obj); } To use the raw `nullptr` and create an OopLoadProxy, which then crashes because the passed in value is null. We might want to reconsider removing OopLoadProxy, since it isn't the first time it is causing problems for us. I'll think about that in a context of a separate RFE. ------------- PR: https://git.openjdk.org/jdk/pull/12186 From jsjolen at openjdk.org Tue Jan 31 10:11:34 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 31 Jan 2023 10:11:34 GMT Subject: RFR: JDK-8301076: Replace NULL with nullptr in share/prims/ [v3] In-Reply-To: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> References: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> Message-ID: <6569WN92YSqavxcJePbGqc0fwjfJYKKTBByUnUy0Z7A=.8caf7b50-a106-44af-9739-317589d78350@github.com> > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/prims/. 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: Fix dholmes's suggested changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12188/files - new: https://git.openjdk.org/jdk/pull/12188/files/b1ff44d7..c1254818 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12188&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12188&range=01-02 Stats: 7 lines in 5 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/12188.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12188/head:pull/12188 PR: https://git.openjdk.org/jdk/pull/12188 From tschatzl at openjdk.org Tue Jan 31 10:23:58 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 31 Jan 2023 10:23:58 GMT Subject: RFR: 8301465: Remove unnecessary nmethod arming in Full GC of Serial/Parallel In-Reply-To: References: Message-ID: <0EDU-jWBNGm1-FgdQsSJrr1ssmFWl4YQgGtSkDbGtd0=.332b49ca-bb04-409e-a8f5-c6417c55b833@github.com> On Tue, 31 Jan 2023 09:18:08 GMT, Albert Mingkun Yang wrote: > Simple removing unnecessary code and adding API documentation. > > Test: hotspot_gc Changes requested by tschatzl (Reviewer). src/hotspot/share/code/codeCache.cpp line 880: > 878: // nmethods are visited. > 879: // 2. Used at the end of (stw/concurrent) marking so that nmethod::_gc_epoch is > 880: // up-to-date, which provides more accurate estimate of nmethod::is_cold. I would prefer to have general documentation and usage information about a method in the .hpp file. ------------- PR: https://git.openjdk.org/jdk/pull/12311 From jsjolen at openjdk.org Tue Jan 31 10:24:37 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 31 Jan 2023 10:24:37 GMT Subject: RFR: JDK-8301224: Replace NULL with nullptr in share/gc/shared/ [v3] In-Reply-To: References: Message-ID: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/gc/shared/. 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: Another fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12249/files - new: https://git.openjdk.org/jdk/pull/12249/files/64b6ba01..8feb47e2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12249&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12249&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12249.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12249/head:pull/12249 PR: https://git.openjdk.org/jdk/pull/12249 From jsjolen at openjdk.org Tue Jan 31 10:24:40 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 31 Jan 2023 10:24:40 GMT Subject: RFR: JDK-8301224: Replace NULL with nullptr in share/gc/shared/ [v2] In-Reply-To: References: Message-ID: On Mon, 30 Jan 2023 16:21:24 GMT, Kim Barrett wrote: >> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix kimbarrett's suggestions > > src/hotspot/share/gc/shared/oopStorage.hpp line 107: > >> 105: // Allocates and returns a new entry. Returns null if memory allocation >> 106: // failed. Locks _allocation_mutex. >> 107: // postcondition: result == null or *result == nullptr. > > Inconsistent mix of "null" and "nullptr". Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/12249 From jsjolen at openjdk.org Tue Jan 31 10:43:39 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 31 Jan 2023 10:43:39 GMT Subject: RFR: JDK-8301479: Replace NULL with nullptr in os/linux Message-ID: Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory os/linux. 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! ------------- Commit messages: - Fixes - Replace NULL with nullptr in os/linux Changes: https://git.openjdk.org/jdk/pull/12315/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12315&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301479 Stats: 367 lines in 17 files changed: 0 ins; 0 del; 367 mod Patch: https://git.openjdk.org/jdk/pull/12315.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12315/head:pull/12315 PR: https://git.openjdk.org/jdk/pull/12315 From jsjolen at openjdk.org Tue Jan 31 10:43:39 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 31 Jan 2023 10:43:39 GMT Subject: RFR: JDK-8301479: Replace NULL with nullptr in os/linux In-Reply-To: References: Message-ID: <9tYmyr9W5CW2V8Hz1ourD6fENkTQ2Bvj05QYJZZo95A=.8a87e497-907a-4771-8206-ae8864550e13@github.com> On Tue, 31 Jan 2023 10:15:48 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory os/linux. 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! Found some things to fix src/hotspot/os/linux/cgroupSubsystem_linux.hpp line 169: > 167: err = subsystem_file_line_contents(subsystem, \ > 168: filename, \ > 169: nullptr, \ Align src/hotspot/os/linux/cgroupSubsystem_linux.hpp line 187: > 185: err = subsystem_file_line_contents(subsystem, \ > 186: filename, \ > 187: nullptr, \ Align src/hotspot/os/linux/cgroupSubsystem_linux.hpp line 191: > 189: variable); \ > 190: if (err != 0) \ > 191: return (return_type) nullptr; \ Align src/hotspot/os/linux/os_linux.cpp line 2177: > 2175: > 2176: p = OSContainer::cpu_cpuset_memory_nodes(); > 2177: st->print_cr("cpu_memory_nodes: %s", p != null ? p : "not supported"); Glitched out src/hotspot/os/linux/os_linux.cpp line 3312: > 3310: > 3311: // Allocate (using mmap, NO_RESERVE, with small pages) at either a given request address > 3312: // (req_addr != null) or with a given alignment. nullptr src/hotspot/os/linux/os_linux.cpp line 3840: > 3838: > 3839: // Since shmid has been setup with SHM_HUGETLB, shmat will automatically > 3840: // return large page size aligned memory addresses when req_addr == null. nullptr ------------- PR: https://git.openjdk.org/jdk/pull/12315 From rkennke at openjdk.org Tue Jan 31 11:30:03 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 31 Jan 2023 11:30:03 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v15] In-Reply-To: <-oqaGCDF75UbtgkKVwsOE9F8-WQ48xCV6GxiN4ZbOxc=.e5042b09-8786-4b44-9929-4d6703303e63@github.com> References: <-oqaGCDF75UbtgkKVwsOE9F8-WQ48xCV6GxiN4ZbOxc=.e5042b09-8786-4b44-9929-4d6703303e63@github.com> Message-ID: <2MruXbnvZiG38AE_gRBVr-I0Zj2PG4rWfZ_BUGhFQpw=.1beb5829-2bbf-4e01-9f86-76f27f93bc59@github.com> On Tue, 24 Jan 2023 18:22:00 GMT, Aleksey Shipilev wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Move filler_array_min_size() into inline header file > > src/hotspot/share/oops/arrayKlass.cpp line 128: > >> 126: >> 127: objArrayOop ArrayKlass::allocate_arrayArray(int n, int length, TRAPS) { >> 128: check_array_allocation_length(length, arrayOopDesc::max_array_length(element_type()), CHECK_NULL); > > Wait, why? This method allocates the array of the "this"-typed arrays, I think. I.e. if `this` is `int[]`, then `element_type()` is `int`, and then `allocate_arrayArray(y, len)` allocates `int[length][]`, and we still need to check `length` against `max_array_length(T_ARRAY)`? Which is also why we do `objArrayOopDesc::object_size` at the very next line. Right. My bad. ------------- PR: https://git.openjdk.org/jdk/pull/11044 From rkennke at openjdk.org Tue Jan 31 11:34:05 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 31 Jan 2023 11:34:05 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v15] In-Reply-To: <-oqaGCDF75UbtgkKVwsOE9F8-WQ48xCV6GxiN4ZbOxc=.e5042b09-8786-4b44-9929-4d6703303e63@github.com> References: <-oqaGCDF75UbtgkKVwsOE9F8-WQ48xCV6GxiN4ZbOxc=.e5042b09-8786-4b44-9929-4d6703303e63@github.com> Message-ID: <33mXkqcQNVxZA7xZLMUQoJOGRbUJ8zSF3wh2Sg2GWLU=.0a0ec230-203f-427e-a6d1-bdbe76a4d161@github.com> On Tue, 24 Jan 2023 18:29:35 GMT, Aleksey Shipilev wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Move filler_array_min_size() into inline header file > > src/hotspot/share/opto/runtime.cpp line 312: > >> 310: BasicType elem_type = TypeArrayKlass::cast(array_type)->element_type(); >> 311: size_t hs_bytes = arrayOopDesc::base_offset_in_bytes(elem_type); >> 312: assert(is_aligned(hs_bytes, BytesPerInt), "must be 4 byte aligned"); > > This assert is misplaced, should be in the `if` block below? Otherwise checking for HeapWordSize alignment after assert-checking for BytesPerInt seems rather odd: the check is guaranteed to pass if assert does not fire. This assert checks int-alignment of the base offset (in bytes). This is always expected. Subsequently, we check if the base offset is 8-byte aligned, and if it is not, then we make it so. After that correction, we assert 8-byte-alignment. I believe it is correct as it is. ------------- PR: https://git.openjdk.org/jdk/pull/11044 From jsjolen at openjdk.org Tue Jan 31 11:39:55 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 31 Jan 2023 11:39:55 GMT Subject: RFR: JDK-8301481: Replace NULL with nullptr in os/windows In-Reply-To: References: Message-ID: <58uRUQEZmNZaqVerm62wSwcoWK79W8kdhVuZf8Q7Rhs=.ae4eecc9-23d8-4ee3-8d4c-13469a610d66@github.com> On Tue, 31 Jan 2023 10:16:14 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory os/windows. 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! Found some things that need fixing src/hotspot/os/windows/gc/z/zMapper_windows.cpp line 69: > 67: MEM_RESERVE | MEM_RESERVE_PLACEHOLDER, // AllocationType > 68: PAGE_NOACCESS, // PageProtection > 69: nullptr, // ExtendedParameters Align src/hotspot/os/windows/gc/z/zMapper_windows.cpp line 104: > 102: HANDLE const res = ZSyscall::CreateFileMappingW( > 103: INVALID_HANDLE_VALUE, // hFile > 104: NULL, // lpFileMappingAttribute Align src/hotspot/os/windows/gc/z/zMapper_windows.cpp line 136: > 134: file_handle, // FileMapping > 135: GetCurrentProcess(), // ProcessHandle > 136: nullptr, // BaseAddress Align src/hotspot/os/windows/gc/z/zMapper_windows.cpp line 141: > 139: 0, // AllocationType > 140: PAGE_NOACCESS, // PageProtection > 141: nullptr, // ExtendedParameters Align src/hotspot/os/windows/gc/z/zMapper_windows.cpp line 168: > 166: MEM_COMMIT, // AllocationType > 167: PAGE_NOACCESS, // PageProtection > 168: nullptr, // ExtendedParameters Align src/hotspot/os/windows/os_perf_windows.cpp line 674: > 672: * > 673: * @param pdh_artifact_idx the counter index as specified in the registry > 674: * @return localized pdh artifact string if successful, nullptr on failure. null src/hotspot/os/windows/os_perf_windows.cpp line 694: > 692: * Caller needs ResourceMark. > 693: * > 694: * @return the process image string description, nullptr if the call failed. null src/hotspot/os/windows/os_perf_windows.cpp line 787: > 785: * Caller needs ResourceMark; > 786: * > 787: * @return buffer if successful, nullptr on failure. null src/hotspot/os/windows/os_perf_windows.cpp line 804: > 802: nullptr, // instance buffer is null and > 803: &i_size, // pass 0 length in order to get the required size > 804: PERF_DETAIL_WIZARD, // counter detail level check align src/hotspot/os/windows/os_perf_windows.cpp line 820: > 818: PERF_DETAIL_WIZARD, // counter detail level > 819: 0); > 820: return PdhDll::PdhStatusFail(pdhStat) ? nullptr : instances; align src/hotspot/os/windows/windbghelp.cpp line 296: > 294: } > 295: > 296: FOR_ALL_FUNCTIONS(CHECK_AND_PRINT_IF_NULL) fix ------------- PR: https://git.openjdk.org/jdk/pull/12317 From jsjolen at openjdk.org Tue Jan 31 11:39:42 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 31 Jan 2023 11:39:42 GMT Subject: RFR: JDK-8301481: Replace NULL with nullptr in os/windows Message-ID: Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory os/windows. 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! ------------- Commit messages: - Merge branch 'master' into JDK-8301481 - Fixes - Replace NULL with nullptr in os/windows Changes: https://git.openjdk.org/jdk/pull/12317/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12317&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301481 Stats: 652 lines in 21 files changed: 0 ins; 0 del; 652 mod Patch: https://git.openjdk.org/jdk/pull/12317.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12317/head:pull/12317 PR: https://git.openjdk.org/jdk/pull/12317 From jsjolen at openjdk.org Tue Jan 31 11:42:48 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 31 Jan 2023 11:42:48 GMT Subject: RFR: JDK-8301480: Replace NULL with nullptr in os/posix In-Reply-To: References: Message-ID: On Tue, 31 Jan 2023 10:16:00 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory os/posix. 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! Found 1issue src/hotspot/os/posix/perfMemory_posix.cpp line 472: > 470: // this check is added to protect against an observed problem > 471: // with getpwuid_r() on RedHat 9 where getpwuid_r returns 0, > 472: // indicating success, but has p == null. This was observed when nullptr ------------- PR: https://git.openjdk.org/jdk/pull/12316 From jsjolen at openjdk.org Tue Jan 31 11:42:47 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 31 Jan 2023 11:42:47 GMT Subject: RFR: JDK-8301480: Replace NULL with nullptr in os/posix Message-ID: Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory os/posix. 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! ------------- Commit messages: - Fix - Replace NULL with nullptr in os/posix Changes: https://git.openjdk.org/jdk/pull/12316/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12316&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301480 Stats: 210 lines in 11 files changed: 0 ins; 0 del; 210 mod Patch: https://git.openjdk.org/jdk/pull/12316.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12316/head:pull/12316 PR: https://git.openjdk.org/jdk/pull/12316 From rkennke at openjdk.org Tue Jan 31 11:47:24 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 31 Jan 2023 11:47:24 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v18] In-Reply-To: References: Message-ID: > See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details. > > Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements. > > Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16. > > Testing: > - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390) > - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390) > - [x] tier1 (x86_64, x86_32, aarch64, riscv) > - [x] tier2 (x86_64, aarch64, riscv) > - [x] tier3 (x86_64, riscv) Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Alexey's comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11044/files - new: https://git.openjdk.org/jdk/pull/11044/files/629fcecd..bbdecd7a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=16-17 Stats: 45 lines in 7 files changed: 17 ins; 14 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/11044.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11044/head:pull/11044 PR: https://git.openjdk.org/jdk/pull/11044 From jsjolen at openjdk.org Tue Jan 31 12:26:43 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 31 Jan 2023 12:26:43 GMT Subject: RFR: JDK-8301224: Replace NULL with nullptr in share/gc/shared/ [v4] In-Reply-To: References: Message-ID: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/gc/shared/. 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 with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge branch 'master' into JDK-8301224 - Another fix - Fix kimbarrett's suggestions - Fix - Fix - Merge remote-tracking branch 'origin/master' into JDK-8301224 - Replace NULL with nullptr in share/gc/shared/ ------------- Changes: https://git.openjdk.org/jdk/pull/12249/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12249&range=03 Stats: 611 lines in 89 files changed: 0 ins; 0 del; 611 mod Patch: https://git.openjdk.org/jdk/pull/12249.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12249/head:pull/12249 PR: https://git.openjdk.org/jdk/pull/12249 From coleenp at openjdk.org Tue Jan 31 13:56:59 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 31 Jan 2023 13:56:59 GMT Subject: RFR: JDK-8301479: Replace NULL with nullptr in os/linux In-Reply-To: References: Message-ID: On Tue, 31 Jan 2023 10:15:48 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory os/linux. 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! Looks trivial. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/12315 From coleenp at openjdk.org Tue Jan 31 13:58:59 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 31 Jan 2023 13:58:59 GMT Subject: RFR: JDK-8301481: Replace NULL with nullptr in os/windows In-Reply-To: References: Message-ID: On Tue, 31 Jan 2023 10:16:14 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory os/windows. 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! Marked as reviewed by coleenp (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12317 From coleenp at openjdk.org Tue Jan 31 14:07:57 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 31 Jan 2023 14:07:57 GMT Subject: RFR: JDK-8301480: Replace NULL with nullptr in os/posix In-Reply-To: References: Message-ID: On Tue, 31 Jan 2023 10:16:00 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory os/posix. 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! trivially fine. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/12316 From tschatzl at openjdk.org Tue Jan 31 14:22:04 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 31 Jan 2023 14:22:04 GMT Subject: RFR: 8301340: Make DirtyCardToOopClosure stack-allocated In-Reply-To: References: Message-ID: On Mon, 30 Jan 2023 11:03:54 GMT, Albert Mingkun Yang wrote: > Simple change from resource-allocated to stack-allocated for a closure. > > Test: hotspot_gc Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12291 From jsjolen at openjdk.org Tue Jan 31 14:25:09 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 31 Jan 2023 14:25:09 GMT Subject: RFR: JDK-8301224: Replace NULL with nullptr in share/gc/shared/ [v4] In-Reply-To: References: Message-ID: On Tue, 31 Jan 2023 12:26:43 GMT, Johan Sj?len wrote: >> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/gc/shared/. 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 with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge branch 'master' into JDK-8301224 > - Another fix > - Fix kimbarrett's suggestions > - Fix > - Fix > - Merge remote-tracking branch 'origin/master' into JDK-8301224 > - Replace NULL with nullptr in share/gc/shared/ This is still passing tier1, just waiting for approval. ------------- PR: https://git.openjdk.org/jdk/pull/12249 From jsjolen at openjdk.org Tue Jan 31 14:26:29 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 31 Jan 2023 14:26:29 GMT Subject: RFR: JDK-8301076: Replace NULL with nullptr in share/prims/ [v3] In-Reply-To: <6569WN92YSqavxcJePbGqc0fwjfJYKKTBByUnUy0Z7A=.8caf7b50-a106-44af-9739-317589d78350@github.com> References: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> <6569WN92YSqavxcJePbGqc0fwjfJYKKTBByUnUy0Z7A=.8caf7b50-a106-44af-9739-317589d78350@github.com> Message-ID: On Tue, 31 Jan 2023 10:11:34 GMT, Johan Sj?len wrote: >> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/prims/. 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: > > Fix dholmes's suggested changes Tier1 is passing and this has 2 approvals, I'm integrating. Thank you for the reviews. ------------- PR: https://git.openjdk.org/jdk/pull/12188 From jsjolen at openjdk.org Tue Jan 31 14:26:30 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 31 Jan 2023 14:26:30 GMT Subject: Integrated: JDK-8301076: Replace NULL with nullptr in share/prims/ In-Reply-To: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> References: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> Message-ID: On Wed, 25 Jan 2023 11:47:05 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/prims/. 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: b76a52f2 Author: Johan Sj?len URL: https://git.openjdk.org/jdk/commit/b76a52f2104b63e84e5d09f47ce01dd0cb3935d7 Stats: 2037 lines in 47 files changed: 0 ins; 0 del; 2037 mod 8301076: Replace NULL with nullptr in share/prims/ Reviewed-by: kbarrett, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/12188 From jcking at openjdk.org Tue Jan 31 14:37:19 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 31 Jan 2023 14:37:19 GMT Subject: RFR: JDK-8301354: Modernize utilities/breakpoint.hpp [v4] In-Reply-To: References: Message-ID: On Mon, 30 Jan 2023 17:09:23 GMT, Justin King wrote: >> Cleanup `utilities/breakpoint.hpp` by utilizing compiler intrinsics when available, or normal signals for AIX/XLC. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Fix reference to unqualified breakpoint > > Signed-off-by: Justin King I put this back into draft after I realized that I forgot only Clang has `__builtin_debugtrap`, making this non-ideal. Ideally GCC would have that as well. In an ideal world, breakpoint should probably only be present in debug builds and compiled out in release builds. Additionally it should probably be consistent across platforms. But I think that ship has sailed. If GCC ever gets `__builtin_debugtrap` than this would be useful, IIF we make them used during debug builds only and fallback to `breakpoint()` calls for everything else. ------------- PR: https://git.openjdk.org/jdk/pull/12296 From jcking at openjdk.org Tue Jan 31 14:37:21 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 31 Jan 2023 14:37:21 GMT Subject: Withdrawn: JDK-8301354: Modernize utilities/breakpoint.hpp In-Reply-To: References: Message-ID: <5zC5FFWAey7Ggdyj3MNt5gfXPDlbRZwZx3SSHcbp5Fg=.0d858a06-9131-4f47-a70c-2fad54df76ee@github.com> On Mon, 30 Jan 2023 14:40:24 GMT, Justin King wrote: > Cleanup `utilities/breakpoint.hpp` by utilizing compiler intrinsics when available, or normal signals for AIX/XLC. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/12296 From jsjolen at openjdk.org Tue Jan 31 14:41:55 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 31 Jan 2023 14:41:55 GMT Subject: RFR: JDK-8301072: Replace NULL with nullptr in share/oops/ [v6] In-Reply-To: References: Message-ID: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/oops/. 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: Remove unnecessary casts ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12186/files - new: https://git.openjdk.org/jdk/pull/12186/files/f6f0d873..6d23b694 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12186&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12186&range=04-05 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12186.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12186/head:pull/12186 PR: https://git.openjdk.org/jdk/pull/12186 From jsjolen at openjdk.org Tue Jan 31 14:41:56 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 31 Jan 2023 14:41:56 GMT Subject: RFR: JDK-8301072: Replace NULL with nullptr in share/oops/ [v2] In-Reply-To: References: Message-ID: On Tue, 31 Jan 2023 09:53:36 GMT, Stefan Karlsson wrote: > > @stefank , we do need to those `oop` casts. The `NativeAccess<>::oop_store` calls makes sense, `oop_store` is templated so we need to provide the type. We also need the casts in `CompressedOops`, and I don't know why that is. > > I took a look at this. And as far as I can see, there's no obvious problem with the oop_store ore CompressedOops changes, but with the NativeAccess<>::oop_load changes. > > NativeAccess<>::oop_load returns an OopLoadProxy object instead of oop, which causes the following code: > > ``` > inline oop OopHandle::resolve() const { > return (_obj == nullptr) ? nullptr : NativeAccess<>::oop_load(_obj); > } > ``` > > To use the raw `nullptr` and create an OopLoadProxy, which then crashes because the passed in value is null. > > We might want to reconsider removing OopLoadProxy, since it isn't the first time it is causing problems for us. I'll think about that in a context of a separate RFE. Thanks for looking at these. I'm removing the unnecessary casts and keeping the remaining ones. ------------- PR: https://git.openjdk.org/jdk/pull/12186 From dnsimon at openjdk.org Tue Jan 31 15:03:03 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Tue, 31 Jan 2023 15:03:03 GMT Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64 [v25] In-Reply-To: References: Message-ID: <-RReNBa4rbWMG38xuIH_yCfzDDEubd4gU2QsVCdiubM=.0e13582c-f1c8-4e35-a1ce-174a22b86a58@github.com> On Tue, 22 Feb 2022 14:35:19 GMT, Alan Hayward wrote: >> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One >> of its uses is to protect against ROP based attacks. This is done by >> signing the Link Register whenever it is stored on the stack, and >> authenticating the value when it is loaded back from the stack. If an >> attacker were to try to change control flow by editing the stack then >> the authentication check of the Link Register will fail, causing a >> segfault when the function returns. >> >> On a system with PAC enabled, it is expected that all applications will >> be compiled with ROP protection. Fedora 33 and upwards already provide >> this. By compiling for ARMv8.0, GCC and LLVM will only use the set of >> PAC instructions that exist in the NOP space - on hardware without PAC, >> these instructions act as NOPs, allowing backward compatibility for >> negligible performance cost (2 NOPs per non-leaf function). >> >> Hardware is currently limited to the Apple M1 MacBooks. All testing has >> been done within a Fedora Docker image. A run of SpecJVM showed no >> difference to that of noise - which was surprising. >> >> The most important part of this patch is simply compiling using branch >> protection provided by GCC/LLVM. This protects all C++ code from being >> used in ROP attacks, removing all static ROP gadgets from use. >> >> The remainder of the patch adds ROP protection to runtime generated >> code, in both stubs and compiled Java code. Attacks here are much harder >> as ROP gadgets must be found dynamically at runtime. If/when AOT >> compilation is added to JDK, then all stubs and compiled Java will be >> susceptible ROP gadgets being found by static analysis and therefore >> potentially as vulnerable as C++ code. >> >> There are a number of places where the VM changes control flow by >> rewriting the stack or otherwise. I?ve done some analysis as to how >> these could also be used for attacks (which I didn?t want to post here). >> These areas can be protected ensuring the pointers to various stubs and >> entry points are stored in memory as signed pointers. These changes are >> simple to make (they can be reduced to a type change in common code and >> a few addition sign/auth calls in the backend), but there a lot of them >> and the total code change is fairly large. I?m happy to provide a few >> work in progress patches. >> >> In order to match the security benefits of the Apple Arm64e ABI across >> the whole of JDK, then all the changes mentioned above would be >> required. > > Alan Hayward has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: > > - Merge master > - Merge master > - Merge master > - Error on -XX:-PreserveFramePointer -XX:UseBranchProtection=pac-ret > - Add comments to enter calls > - Set PreserveFramePointer if use_rop_protection is set > - Merge enter_subframe into enter > - Review fixups > - Documentation updates > - Update copyrights to 2022 > - ... and 24 more: https://git.openjdk.org/jdk/compare/022d8070...c4e0ee31 src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 413: > 411: } > 412: > 413: if (UseBranchProtection == nullptr || strcmp(UseBranchProtection, "none") == 0) { My understanding is that `UseBranchProtection` requires JIT compiler integration. This is currently missing in Graal. The logic that decides if it should be enabled by default needs to take JVMCI into consideration, much like the call to `JVMCIGlobals::check_jvmci_supported_gc` determines if JVMCI supports the configured GC. Thanks to @gilles-duboscq for alerting me to this change. ------------- PR: https://git.openjdk.org/jdk/pull/6334 From jsjolen at openjdk.org Tue Jan 31 15:07:44 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 31 Jan 2023 15:07:44 GMT Subject: RFR: JDK-8301499: Replace NULL with nullptr in cpu/zero Message-ID: Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory cpu/zero. 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! ------------- Commit messages: - Replace NULL with nullptr in cpu/zero Changes: https://git.openjdk.org/jdk/pull/12327/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12327&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301499 Stats: 147 lines in 24 files changed: 0 ins; 0 del; 147 mod Patch: https://git.openjdk.org/jdk/pull/12327.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12327/head:pull/12327 PR: https://git.openjdk.org/jdk/pull/12327 From jsjolen at openjdk.org Tue Jan 31 15:25:56 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 31 Jan 2023 15:25:56 GMT Subject: RFR: JDK-8301494: Replace NULL with nullptr in cpu/arm Message-ID: Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory cpu/arm. 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! ------------- Commit messages: - Fix issues - Replace NULL with nullptr in cpu/arm Changes: https://git.openjdk.org/jdk/pull/12322/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12322&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301494 Stats: 315 lines in 38 files changed: 0 ins; 0 del; 315 mod Patch: https://git.openjdk.org/jdk/pull/12322.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12322/head:pull/12322 PR: https://git.openjdk.org/jdk/pull/12322 From jsjolen at openjdk.org Tue Jan 31 15:26:01 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 31 Jan 2023 15:26:01 GMT Subject: RFR: JDK-8301494: Replace NULL with nullptr in cpu/arm In-Reply-To: References: Message-ID: On Tue, 31 Jan 2023 11:39:38 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory cpu/arm. 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! Some minor fixes needed. src/hotspot/cpu/arm/interp_masm_arm.cpp line 163: > 161: > 162: ldr(thread_state, Address(Rthread, JavaThread::jvmti_thread_state_offset())); > 163: cbz(thread_state, L); // if (thread->jvmti_thread_state() == null) exit; nullptr src/hotspot/cpu/arm/stubGenerator_arm.cpp line 2656: > 2654: __ b(L_failed, lt); > 2655: > 2656: // if (dst == null) return -1; nullptr src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp line 760: > 758: const int referent_offset = java_lang_ref_Reference::referent_offset(); > 759: > 760: // Check if local 0 != null nullptr src/hotspot/cpu/arm/templateTable_arm.cpp line 4083: > 4081: // result = 0: obj == null or obj is not an instanceof the specified klass > 4082: // result = 1: obj != null and obj is an instanceof the specified klass > 4083: nullptr ------------- PR: https://git.openjdk.org/jdk/pull/12322 From dnsimon at openjdk.org Tue Jan 31 15:31:29 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Tue, 31 Jan 2023 15:31:29 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v38] In-Reply-To: References: Message-ID: On Tue, 6 Dec 2022 21:14:07 GMT, Andrew Haley wrote: >> JEP 429 implementation. > > Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 71 commits: > > - Merge from JDK mainline > - Add comment > - Merge https://github.com/openjdk/jdk into JDK-8286666 > - Feedback from reviewers > - Feedback from reviewers > - Unused variable > - Cleanup > - Cleanup > - Merge branch 'JDK-8286666' of https://github.com/theRealAph/jdk into JDK-8286666 > - Update src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java > > Co-authored-by: Paul Sandoz > - ... and 61 more: https://git.openjdk.org/jdk/compare/2cdc0195...46fa1389 src/hotspot/share/classfile/vmIntrinsics.hpp line 295: > 293: do_name( setScopedValueCache_name, "setScopedValueCache") \ > 294: do_signature(setScopedValueCache_signature, "([Ljava/lang/Object;)V") \ > 295: do_intrinsic(_findScopedValueBindings, java_lang_Thread, findScopedValueBindings_name, void_object_signature, F_SN) \ As far as I can tell, there is not yet an intrinsic implementation for `findScopedValueBindings`. Is this a placeholder for a pending implementation? ------------- PR: https://git.openjdk.org/jdk/pull/10952 From sgehwolf at openjdk.org Tue Jan 31 15:37:20 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 31 Jan 2023 15:37:20 GMT Subject: RFR: JDK-8301479: Replace NULL with nullptr in os/linux In-Reply-To: References: Message-ID: On Tue, 31 Jan 2023 10:15:48 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory os/linux. 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! Looks OK to me. ------------- Marked as reviewed by sgehwolf (Reviewer). PR: https://git.openjdk.org/jdk/pull/12315 From iklam at openjdk.org Tue Jan 31 16:11:13 2023 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 31 Jan 2023 16:11:13 GMT Subject: RFR: 8296344: Remove dependency on G1 for writing the CDS archive heap [v2] In-Reply-To: References: Message-ID: > Goals > > - Simplify the writing of the CDS archive heap > - We no longer need to allocate special "archive regions" during CDS dump time. See all the removed G1 code. > - Make it possible to (in a future RFE) write the CDS archive heap using any garbage collector > > Implementation - the following runs inside a safepoint so heap objects aren't moving > > - Find all the objects that should be archived > - Allocate buffer using a GrowableArray > - Copy all "open" objects into the buffer > - Copy all "closed" objects into the buffer > - Make sure the heap image can be mapped with all possible G1 region sizes: > - While copying, add fillers to make sure no object spans across 1MB boundary (minimal G1 region size) > - Align the bottom of the "open" and "closed" objects at 1MB boundary > - Write the buffer to disk as the image for the archive heap > > Testing: tiers 1 ~ 5 Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: fixed windows and 32-bit builds which do not support archive heap ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12304/files - new: https://git.openjdk.org/jdk/pull/12304/files/c2533374..664fb922 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12304&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12304&range=00-01 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12304.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12304/head:pull/12304 PR: https://git.openjdk.org/jdk/pull/12304 From ayang at openjdk.org Tue Jan 31 16:15:26 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 31 Jan 2023 16:15:26 GMT Subject: RFR: 8301340: Make DirtyCardToOopClosure stack-allocated In-Reply-To: References: Message-ID: On Mon, 30 Jan 2023 11:03:54 GMT, Albert Mingkun Yang wrote: > Simple change from resource-allocated to stack-allocated for a closure. > > Test: hotspot_gc Thanks for the review. ------------- PR: https://git.openjdk.org/jdk/pull/12291 From ayang at openjdk.org Tue Jan 31 16:15:27 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 31 Jan 2023 16:15:27 GMT Subject: Integrated: 8301340: Make DirtyCardToOopClosure stack-allocated In-Reply-To: References: Message-ID: On Mon, 30 Jan 2023 11:03:54 GMT, Albert Mingkun Yang wrote: > Simple change from resource-allocated to stack-allocated for a closure. > > Test: hotspot_gc This pull request has now been integrated. Changeset: 60c535de Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/60c535de49f6140887ab3eaaa7098b22737114a2 Stats: 21 lines in 4 files changed: 0 ins; 18 del; 3 mod 8301340: Make DirtyCardToOopClosure stack-allocated Reviewed-by: stefank, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/12291 From coleenp at openjdk.org Tue Jan 31 17:06:01 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 31 Jan 2023 17:06:01 GMT Subject: RFR: 8301555: Remove constantPoolCacheKlass friend Message-ID: Please review this trivial change. ------------- Commit messages: - 8301555: Remove constantPoolCacheKlass friend Changes: https://git.openjdk.org/jdk/pull/12349/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12349&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301555 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12349.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12349/head:pull/12349 PR: https://git.openjdk.org/jdk/pull/12349 From fparain at openjdk.org Tue Jan 31 17:16:57 2023 From: fparain at openjdk.org (Frederic Parain) Date: Tue, 31 Jan 2023 17:16:57 GMT Subject: RFR: 8301555: Remove constantPoolCacheKlass friend In-Reply-To: References: Message-ID: On Tue, 31 Jan 2023 16:57:46 GMT, Coleen Phillimore wrote: > Please review this trivial change. Marked as reviewed by fparain (Committer). ------------- PR: https://git.openjdk.org/jdk/pull/12349 From kbarrett at openjdk.org Tue Jan 31 17:35:22 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 31 Jan 2023 17:35:22 GMT Subject: RFR: 8301555: Remove constantPoolCacheKlass friend In-Reply-To: References: Message-ID: On Tue, 31 Jan 2023 16:57:46 GMT, Coleen Phillimore wrote: > Please review this trivial change. Looks good, and trivial. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/12349 From kbarrett at openjdk.org Tue Jan 31 18:00:01 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 31 Jan 2023 18:00:01 GMT Subject: RFR: JDK-8301224: Replace NULL with nullptr in share/gc/shared/ [v4] In-Reply-To: References: Message-ID: On Tue, 31 Jan 2023 12:26:43 GMT, Johan Sj?len wrote: >> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/gc/shared/. 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 with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge branch 'master' into JDK-8301224 > - Another fix > - Fix kimbarrett's suggestions > - Fix > - Fix > - Merge remote-tracking branch 'origin/master' into JDK-8301224 > - Replace NULL with nullptr in share/gc/shared/ Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/12249 From coleenp at openjdk.org Tue Jan 31 18:02:40 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 31 Jan 2023 18:02:40 GMT Subject: RFR: 8301555: Remove constantPoolCacheKlass friend In-Reply-To: References: Message-ID: On Tue, 31 Jan 2023 16:57:46 GMT, Coleen Phillimore wrote: > Please review this trivial change. Thanks Fred and Kim. ------------- PR: https://git.openjdk.org/jdk/pull/12349 From kvn at openjdk.org Tue Jan 31 18:07:00 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 31 Jan 2023 18:07:00 GMT Subject: RFR: 8301371: Interpreter store barriers on x86_64 don't have disjoint temp registers In-Reply-To: References: Message-ID: On Tue, 31 Jan 2023 08:08:14 GMT, Erik ?sterlund wrote: > The interpreter store barriers on x86_64 use temp registers that sometimes intersects with registers that are part of the address. Therefore, when clobbering temp registers, the address gets destroyed. This has happened to be okay so far, based on how these registers are used in existing backends, but it doesn't work well for generational ZGC. This CR selects new temp registers that I have verified works for everyone on x86_64. Okay. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/12309 From coleenp at openjdk.org Tue Jan 31 18:09:42 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 31 Jan 2023 18:09:42 GMT Subject: Integrated: 8301555: Remove constantPoolCacheKlass friend In-Reply-To: References: Message-ID: On Tue, 31 Jan 2023 16:57:46 GMT, Coleen Phillimore wrote: > Please review this trivial change. This pull request has now been integrated. Changeset: e1bf4713 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/e1bf4713124cfb3ce325e5f7677be7de0a532d17 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod 8301555: Remove constantPoolCacheKlass friend Reviewed-by: fparain, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/12349 From eosterlund at openjdk.org Tue Jan 31 18:23:36 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 31 Jan 2023 18:23:36 GMT Subject: RFR: 8301371: Interpreter store barriers on x86_64 don't have disjoint temp registers In-Reply-To: References: Message-ID: On Tue, 31 Jan 2023 18:04:33 GMT, Vladimir Kozlov wrote: > Okay. Thanks for the review, @vnkozlov! ------------- PR: https://git.openjdk.org/jdk/pull/12309 From ioi.lam at oracle.com Tue Jan 31 19:23:36 2023 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 31 Jan 2023 11:23:36 -0800 Subject: JVM Flag ergonomics and constraints In-Reply-To: References: Message-ID: <1e05de2b-5f03-7ff2-6a47-176df9046588@oracle.com> CC-ing hotspot-dev for wider discussion. On 1/31/2023 12:43 AM, Thomas St?fe wrote: > Hi Ioi, > > a short question. You did the JVM flag handling revamp, right? > > I recently ran into a weird problem where FLAG_SET_ERGO would not > work, turned out it ends up using the constraint function, which > silently refused to set the argument if the argument violates the > constraint. > > That makes perfect sense, I had an error in my code. But if we set a > flag with ERGO origin, we set it in the JVM, and the JVM should adhere > to constraints, not doing so is a programming error and I would expect > an assert here. The same logic may be applied to other origins too, > e.g. DEFAULT. > Do you think this makes sense? > > BTW I added debug output (setting verbose to true for ERGO), and I see > other flag's ergonomics also getting ignored, which would have to be > fixed too. > > Cheers, Thomas > This problem is also reported in https://bugs.openjdk.org/browse/JDK-8224980 There are proposals for making the debug message more obvious, and/or assert(). Currently we don't have documentation of what the caller of FLAG_SET_ERGO is supposed to do. There are 3 ways to set a flag. The current behavior of the following two ways seems reasonable ?? FLAG_SET_CMDLINE - rejects user input and exit VM ?? FLAG_SET_MGMT??? - return JVMFlag::Error With command-line, the user should inspect the limits for the current environment and restart the app with an appropriate value With FLAG_SET_MGMT, I suppose it's similar -- whoever is using the management API should detect the error and adjust their parameter values (by hand, or programmatically) However, FLAG_SET_ERGO also returns JVMFlag::Error, but I don't see any of our code checking for the return value. So the unwritten convention is that the call must not fail. However, if the specified value is out of range, should we abort the VM, ignore the value, or cap the value? E.g., if the range is 0~100, but you call SET_ERGO with 101, should we cap the value to 100? Perhaps capping would make the ergo code easier to write, especially if the constraint function produces a dynamic range (depending on the machine's RAM size, for example). Without capping, you will need to duplicate (or share) the range detection logic between the ergo setter and the constraint checker. Thanks - Ioi From jcking at openjdk.org Tue Jan 31 20:05:21 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 31 Jan 2023 20:05:21 GMT Subject: RFR: JDK-8300783: Consolidate byteswap implementations [v13] In-Reply-To: References: Message-ID: <4AfWUfBaHKZwVsm6XhCkKc0krgKgWTw1RVI2R1-MdcM=.48008df7-1411-42d6-aeb1-3276f443dfe3@github.com> > Deduplicate byte swapping implementations by consolidating them into `utilities/byteswap.hpp`, following `std::byteswap` introduced in C++23. Further simplification of `Bytes` will follow in https://github.com/openjdk/jdk/pull/12078. Justin King has updated the pull request incrementally with one additional commit since the last revision: Fix copyright Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12114/files - new: https://git.openjdk.org/jdk/pull/12114/files/139c4205..f2ea0038 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12114&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12114&range=11-12 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12114.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12114/head:pull/12114 PR: https://git.openjdk.org/jdk/pull/12114 From jcking at openjdk.org Tue Jan 31 20:05:21 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 31 Jan 2023 20:05:21 GMT Subject: RFR: JDK-8300783: Consolidate byteswap implementations [v12] In-Reply-To: References: Message-ID: On Tue, 31 Jan 2023 01:03:36 GMT, David Holmes wrote: >> Justin King has updated the pull request incrementally with four additional commits since the last revision: >> >> - Update copyright >> >> Signed-off-by: Justin King >> - Add missing include >> >> Signed-off-by: Justin King >> - Remove unused include >> >> Signed-off-by: Justin King >> - Reorganize tests >> >> Signed-off-by: Justin King > > test/hotspot/gtest/utilities/test_byteswap.cpp line 2: > >> 1: /* >> 2: * Copyright (c) 2022, 2023, Oracle and/or its affiliates. All rights reserved. > > As a new file this should only have 2023 copyright year - thanks. Fixed. ------------- PR: https://git.openjdk.org/jdk/pull/12114 From jcking at openjdk.org Tue Jan 31 20:46:35 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 31 Jan 2023 20:46:35 GMT Subject: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot Message-ID: Adds initial LSan (LeakSanitizer) support to Hotspot. This setup has been used to identify multiple leaks so far. It can run most of the test suite except those that rely on testing compressed oops, compressed class pointers, or CDS. It is especially useful when combined with ASan, as LSan can use poisoning information to determine what memory to scan or not to scan, making leak detection more accurate and faster. **Suppressing:** Currently the suppression list is only used to suppress JLI leaks that are known, the rest are done in code. Suppressing needs to identify the source of thet leak. Due to Hotspot's code organization, we would need to suppress `os::malloc` and friends, which would suppress everything. Suppressing in code has the added benefit of being explicit and surviving refactors if methods change. **Caveats:** - `UseCompressedOops` and `UseCompressedClassPointers` are forced to false when LSan is enabled. This is necessary to ensure all pointers to memory which could possible container pointers to malloc memory are property aligned, which is an LSan requirement. - `UseSharedSpaces` and `RequireSharedSpaces` are forced to false when LSan is enabled. CDS caused LSan to report many false positives and I was unable to get to the bottom of this. In the future hopefully this can be removed. - By default ASan enables LSan, however we explicitly disable it unless `--enable-lsan` is given. This is due to the other caveats. It is useful to be able to use ASan without LSan. Using LSan by itself is less likely to be useful and will probably not work, but its still possible currently. - There are a series of tests that are upset due to the above flags being forced false, as they rely on the arguments being supported. In the future ideally these tests would be skipped nicely when LSan is enabled. ------------- Commit messages: - Merge remote-tracking branch 'upstream/master' into lsan - Merge remote-tracking branch 'upstream/master' into lsan - Merge remote-tracking branch 'upstream/master' into lsan - Implement initial LSAN support v2 - Implement initial LSAN support Changes: https://git.openjdk.org/jdk/pull/12229/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12229&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298445 Stats: 314 lines in 23 files changed: 305 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/12229.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12229/head:pull/12229 PR: https://git.openjdk.org/jdk/pull/12229 From erikj at openjdk.org Tue Jan 31 21:54:49 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 31 Jan 2023 21:54:49 GMT Subject: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot In-Reply-To: References: Message-ID: <8T_7kw-HfC0GCK172vicu8Bic_lzaXtODgPmvPVR_8k=.06a82d02-470a-49fe-90b8-dbe81b969a05@github.com> On Thu, 26 Jan 2023 17:33:28 GMT, Justin King wrote: > Adds initial LSan (LeakSanitizer) support to Hotspot. This setup has been used to identify multiple leaks so far. It can run most of the test suite except those that rely on testing compressed oops, compressed class pointers, or CDS. It is especially useful when combined with ASan, as LSan can use poisoning information to determine what memory to scan or not to scan, making leak detection more accurate and faster. > > **Suppressing:** > Currently the suppression list is only used to suppress JLI leaks that are known, the rest are done in code. Suppressing needs to identify the source of thet leak. Due to Hotspot's code organization, we would need to suppress `os::malloc` and friends, which would suppress everything. Suppressing in code has the added benefit of being explicit and surviving refactors if methods change. > > **Caveats:** > - `UseCompressedOops` and `UseCompressedClassPointers` are forced to false when LSan is enabled. This is necessary to ensure all pointers to memory which could possible container pointers to malloc memory are property aligned, which is an LSan requirement. > - `UseSharedSpaces` and `RequireSharedSpaces` are forced to false when LSan is enabled. CDS caused LSan to report many false positives and I was unable to get to the bottom of this. In the future hopefully this can be removed. > - By default ASan enables LSan, however we explicitly disable it unless `--enable-lsan` is given. This is due to the other caveats. It is useful to be able to use ASan without LSan. Using LSan by itself is less likely to be useful and will probably not work, but its still possible currently. > - There are a series of tests that are upset due to the above flags being forced false, as they rely on the arguments being supported. In the future ideally these tests would be skipped nicely when LSan is enabled. Build changes look ok. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.org/jdk/pull/12229 From jrose at openjdk.org Tue Jan 31 21:58:48 2023 From: jrose at openjdk.org (John R Rose) Date: Tue, 31 Jan 2023 21:58:48 GMT Subject: RFR: JDK-8300783: Consolidate byteswap implementations [v13] In-Reply-To: <4AfWUfBaHKZwVsm6XhCkKc0krgKgWTw1RVI2R1-MdcM=.48008df7-1411-42d6-aeb1-3276f443dfe3@github.com> References: <4AfWUfBaHKZwVsm6XhCkKc0krgKgWTw1RVI2R1-MdcM=.48008df7-1411-42d6-aeb1-3276f443dfe3@github.com> Message-ID: On Tue, 31 Jan 2023 20:05:21 GMT, Justin King wrote: >> Deduplicate byte swapping implementations by consolidating them into `utilities/byteswap.hpp`, following `std::byteswap` introduced in C++23. Further simplification of `Bytes` will follow in https://github.com/openjdk/jdk/pull/12078. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright > > Signed-off-by: Justin King I would support folding compress/expand algorithms into moveBits. Please manually check the assembly output of code_quality_reverse_bytes_32 and code_quality_reverse_bytes_64, as suggested by the comments, for each platform you test on, and confirm (with a comment on this PR) that the correct instruction is emitted. I could suggest a microbenchmark (inside the gtest file) that would (with probable accuracy) detect failure of the intrinsic on some platform, by comparing a micro-loop that is suppose to compile with bswap to a micro-loop that uses an irregular ad hoc C expression of similar complexity but no known optimization. Such a thing would bring in its own problems, including false positives (if run frequently, and not manually). But if we were to do it right, perhaps imitating our jmh micro-benchmarks, it might add value, especially if we did the same with a whole raft of intrinsics (compress, multiply-high, etc. etc.). But for the case of bswap I think we will certainly see regressions quickly, and quickly identify the root cause, so a micro-benchmark with pinpoint is not clearly warranted here. IMO. ------------- PR: https://git.openjdk.org/jdk/pull/12114 From duke at openjdk.org Tue Jan 31 22:39:01 2023 From: duke at openjdk.org (duke) Date: Tue, 31 Jan 2023 22:39:01 GMT Subject: Withdrawn: 8291917: Windows - Improve error messages when the C Runtime Libraries or jvm.dll cannot be loaded In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 16:26:19 GMT, Julian Waters wrote: > Please review a small patch for dumping the failure reason when the MSVCRT libraries or the Java Virtual Machine fails to load on Windows, which can provide invaluable insight when debugging related launcher issues. > > See https://bugs.openjdk.org/browse/JDK-8292016 and the related Pull Request for the reason that the existing JLI error reporting utility was not used in this enhancement This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/9749 From jcking at openjdk.org Tue Jan 31 23:32:53 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 31 Jan 2023 23:32:53 GMT Subject: RFR: JDK-8300783: Consolidate byteswap implementations [v13] In-Reply-To: <4AfWUfBaHKZwVsm6XhCkKc0krgKgWTw1RVI2R1-MdcM=.48008df7-1411-42d6-aeb1-3276f443dfe3@github.com> References: <4AfWUfBaHKZwVsm6XhCkKc0krgKgWTw1RVI2R1-MdcM=.48008df7-1411-42d6-aeb1-3276f443dfe3@github.com> Message-ID: On Tue, 31 Jan 2023 20:05:21 GMT, Justin King wrote: >> Deduplicate byte swapping implementations by consolidating them into `utilities/byteswap.hpp`, following `std::byteswap` introduced in C++23. Further simplification of `Bytes` will follow in https://github.com/openjdk/jdk/pull/12078. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright > > Signed-off-by: Justin King GCC/Clang and MSVC generate the single instruction for platforms which have it, otherwise they use the fastest method feasible for the architecture. Compiler-explorer confirms this. GCC will always recognize byteswap-like code, Clang doesn't always. I am not 100% sure of XLC, it should generate a single store instruction. Getting a copy of the old XLC on AIX (not the clang-based one) doesn't seem easy. ------------- PR: https://git.openjdk.org/jdk/pull/12114 From sspitsyn at openjdk.org Tue Jan 31 23:56:51 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 31 Jan 2023 23:56:51 GMT Subject: RFR: 8298979: Remove duplicated serviceability/jvmti/thread/GetAllThreads/allthr01/allthr01.java [v2] In-Reply-To: References: <7N18GctUO6Kt5_VJe5lJBV-ga-jZv-z9vtnh99dKHZo=.390887cd-5af8-4a61-bd2c-b4b5f74353e8@github.com> Message-ID: On Fri, 27 Jan 2023 05:20:28 GMT, Leonid Mesnik wrote: >> PR adds fix "8284027: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/ is failing" to new test and remove duplication. >> >> Test allthr002 ported as >> serviceability/jvmti/negative/GetAllThreadsNullTest/GetAllThreadsNullTest.java > > Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: > > - cleanup > - used get_thread_name The fix looks good to me. It is nice to remove the duplication. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/12240