From tpushkin at openjdk.org Tue Jul 1 07:23:55 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Tue, 1 Jul 2025 07:23:55 GMT Subject: [crac] RFR: 8361124: [CRaC] Move recursive checkpoint test to simengine Message-ID: At the moment of creation this PR includes #239 ? that should be merged first. fc33e85c429536dcc89ff59afed6450bb7562639 is the change of this PR. Makes recursive checkpoint test use `simengine` instead of `pauseengine`. Since that was the only test using `pauseengine`, a separate `PauseEngineTest` is created to test the engine. ------------- Commit messages: - Fix recursive checkpoint test - Make dev engines less confusing Changes: https://git.openjdk.org/crac/pull/240/files Webrev: https://webrevs.openjdk.org/?repo=crac&pr=240&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361124 Stats: 583 lines in 9 files changed: 312 ins; 266 del; 5 mod Patch: https://git.openjdk.org/crac/pull/240.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/240/head:pull/240 PR: https://git.openjdk.org/crac/pull/240 From rvansa at openjdk.org Tue Jul 1 09:00:54 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 1 Jul 2025 09:00:54 GMT Subject: [crac] RFR: 8361090: [CRaC] Make dev engines less confusing In-Reply-To: References: Message-ID: On Mon, 30 Jun 2025 17:21:50 GMT, Timofei Pushkin wrote: > - Makes `pauseengine` Linux-only since it is not fully implemented on MacOS and Windows > - Also moves `criuengine` sources from `unix` to `linux` directory since it only supports Linux anyway > - Makes `simengine` and `pausengine` report errors and status in more details src/java.base/linux/native/pauseengine/pauseengine.c line 68: > 66: fclose(pidfile); > 67: > 68: printf(PAUSEENGINE "pausing the process, restore in another process to unpause it\n"); I would rather see all these logging messages going into `stderr`. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/239#discussion_r2176883220 From rvansa at openjdk.org Tue Jul 1 09:26:11 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 1 Jul 2025 09:26:11 GMT Subject: [crac] RFR: 8361124: [CRaC] Move recursive checkpoint test to simengine In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 07:18:51 GMT, Timofei Pushkin wrote: > At the moment of creation this PR includes #239 ? that should be merged first. fc33e85c429536dcc89ff59afed6450bb7562639 is the change of this PR. > > Makes recursive checkpoint test use `simengine` instead of `pauseengine`. Since that was the only test using `pauseengine`, a separate `PauseEngineTest` is created to test the engine. I don't really like `RecursiveCheckpointTest.exception` being not synchronized at all; could you turn this into a concurrent collection? ------------- PR Review: https://git.openjdk.org/crac/pull/240#pullrequestreview-2974464402 From tpushkin at openjdk.org Tue Jul 1 10:27:51 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Tue, 1 Jul 2025 10:27:51 GMT Subject: [crac] RFR: 8361090: [CRaC] Make dev engines less confusing In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 08:49:29 GMT, Radim Vansa wrote: >> - Makes `pauseengine` Linux-only since it is not fully implemented on MacOS and Windows >> - Also moves `criuengine` sources from `unix` to `linux` directory since it only supports Linux anyway >> - Makes `simengine` and `pausengine` report errors and status in more details > > src/java.base/linux/native/pauseengine/pauseengine.c line 68: > >> 66: fclose(pidfile); >> 67: >> 68: printf(PAUSEENGINE "pausing the process, restore in another process to unpause it\n"); > > I would rather see all these logging messages going into `stderr`. Warp prints its "Checkpoint successful" message to stout IIRC, then this should.go there too since it is essentially the same thing. We can make it disable-able via `-XX:CRaCEngineOptions=args=-quiet` for example. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/239#discussion_r2177144915 From tpushkin at openjdk.org Tue Jul 1 12:47:01 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Tue, 1 Jul 2025 12:47:01 GMT Subject: [crac] RFR: 8361090: [CRaC] Make dev engines less confusing In-Reply-To: References: Message-ID: <0QGjBVl-AbJa2rD-Xn5Uul0m1Pt7KtS1I_KFa-RaH8k=.42c3ed3e-3e7b-4b92-8814-dab71a05e849@github.com> On Tue, 1 Jul 2025 10:24:59 GMT, Timofei Pushkin wrote: >> src/java.base/linux/native/pauseengine/pauseengine.c line 68: >> >>> 66: fclose(pidfile); >>> 67: >>> 68: printf(PAUSEENGINE "pausing the process, restore in another process to unpause it\n"); >> >> I would rather see all these logging messages going into `stderr`. > > Warp prints its "Checkpoint successful" message to stout IIRC, then this should.go there too since it is essentially the same thing. We can make it disable-able via `-XX:CRaCEngineOptions=args=-quiet` for example. NVMD, Warp actually prints to stderr, I was mistaken ------------- PR Review Comment: https://git.openjdk.org/crac/pull/239#discussion_r2177512940 From tpushkin at openjdk.org Tue Jul 1 12:56:56 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Tue, 1 Jul 2025 12:56:56 GMT Subject: [crac] RFR: 8361090: [CRaC] Make dev engines less confusing [v2] In-Reply-To: References: Message-ID: > - Makes `pauseengine` Linux-only since it is not fully implemented on MacOS and Windows > - Also moves `criuengine` sources from `unix` to `linux` directory since it only supports Linux anyway > - Makes `simengine` and `pausengine` report errors and status in more details Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: Log to stderr ------------- Changes: - all: https://git.openjdk.org/crac/pull/239/files - new: https://git.openjdk.org/crac/pull/239/files/e4d6832c..e87556e4 Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=239&range=01 - incr: https://webrevs.openjdk.org/?repo=crac&pr=239&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/crac/pull/239.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/239/head:pull/239 PR: https://git.openjdk.org/crac/pull/239 From tpushkin at openjdk.org Tue Jul 1 15:18:45 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Tue, 1 Jul 2025 15:18:45 GMT Subject: [crac] RFR: 8361124: [CRaC] Move recursive checkpoint test to simengine [v2] In-Reply-To: References: Message-ID: > At the moment of creation this PR includes #239 ? that should be merged first. fc33e85c429536dcc89ff59afed6450bb7562639 is the change of this PR. > > Makes recursive checkpoint test use `simengine` instead of `pauseengine`. Since that was the only test using `pauseengine`, a separate `PauseEngineTest` is created to test the engine. Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: Improve exception handling in recursive C/R test ------------- Changes: - all: https://git.openjdk.org/crac/pull/240/files - new: https://git.openjdk.org/crac/pull/240/files/fc33e85c..d616ee8f Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=240&range=01 - incr: https://webrevs.openjdk.org/?repo=crac&pr=240&range=00-01 Stats: 67 lines in 1 file changed: 17 ins; 31 del; 19 mod Patch: https://git.openjdk.org/crac/pull/240.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/240/head:pull/240 PR: https://git.openjdk.org/crac/pull/240 From rvansa at openjdk.org Wed Jul 2 09:48:15 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Wed, 2 Jul 2025 09:48:15 GMT Subject: [crac] RFR: 8361124: [CRaC] Move recursive checkpoint test to simengine [v2] In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 15:18:45 GMT, Timofei Pushkin wrote: >> At the moment of creation this PR includes #239 ? that should be merged first. fc33e85c429536dcc89ff59afed6450bb7562639 is the change of this PR. >> >> Makes recursive checkpoint test use `simengine` instead of `pauseengine`. Since that was the only test using `pauseengine`, a separate `PauseEngineTest` is created to test the engine. > > Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: > > Improve exception handling in recursive C/R test LGTM, let's just integrate the other PR first. ------------- Marked as reviewed by rvansa (Committer). PR Review: https://git.openjdk.org/crac/pull/240#pullrequestreview-2978489806 From rvansa at openjdk.org Wed Jul 2 09:51:02 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Wed, 2 Jul 2025 09:51:02 GMT Subject: [crac] RFR: 8361090: [CRaC] Make dev engines less confusing [v2] In-Reply-To: References: Message-ID: <5dnZ79l122dCx0f0mKF5vTHovoeD2JCdXmY4s3yb21w=.35d5db6e-b118-44fb-a675-7c1820cd3033@github.com> On Tue, 1 Jul 2025 12:56:56 GMT, Timofei Pushkin wrote: >> - Makes `pauseengine` Linux-only since it is not fully implemented on MacOS and Windows >> - Also moves `criuengine` sources from `unix` to `linux` directory since it only supports Linux anyway >> - Makes `simengine` and `pausengine` report errors and status in more details > > Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: > > Log to stderr Marked as reviewed by rvansa (Committer). ------------- PR Review: https://git.openjdk.org/crac/pull/239#pullrequestreview-2978492569 From tpushkin at openjdk.org Wed Jul 2 09:51:03 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Wed, 2 Jul 2025 09:51:03 GMT Subject: [crac] Integrated: 8361090: [CRaC] Make dev engines less confusing In-Reply-To: References: Message-ID: On Mon, 30 Jun 2025 17:21:50 GMT, Timofei Pushkin wrote: > - Makes `pauseengine` Linux-only since it is not fully implemented on MacOS and Windows > - Also moves `criuengine` sources from `unix` to `linux` directory since it only supports Linux anyway > - Makes `simengine` and `pausengine` report errors and status in more details This pull request has now been integrated. Changeset: f1e3b49d Author: Timofei Pushkin URL: https://git.openjdk.org/crac/commit/f1e3b49d8fdb0cd4eda8631118081e70b13b4db5 Stats: 250 lines in 7 files changed: 120 ins; 125 del; 5 mod 8361090: [CRaC] Make dev engines less confusing Reviewed-by: rvansa ------------- PR: https://git.openjdk.org/crac/pull/239 From tpushkin at openjdk.org Wed Jul 2 09:57:13 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Wed, 2 Jul 2025 09:57:13 GMT Subject: [crac] RFR: 8361124: [CRaC] Move recursive checkpoint test to simengine [v3] In-Reply-To: References: Message-ID: > At the moment of creation this PR includes #239 ? that should be merged first. fc33e85c429536dcc89ff59afed6450bb7562639 is the change of this PR. > > Makes recursive checkpoint test use `simengine` instead of `pauseengine`. Since that was the only test using `pauseengine`, a separate `PauseEngineTest` is created to test the engine. Timofei Pushkin 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 'openjdk-crac/crac' into recursive-cr - Improve exception handling in recursive C/R test - Fix recursive checkpoint test - Make dev engines less confusing ------------- Changes: https://git.openjdk.org/crac/pull/240/files Webrev: https://webrevs.openjdk.org/?repo=crac&pr=240&range=02 Stats: 321 lines in 3 files changed: 179 ins; 142 del; 0 mod Patch: https://git.openjdk.org/crac/pull/240.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/240/head:pull/240 PR: https://git.openjdk.org/crac/pull/240 From rvansa at openjdk.org Wed Jul 2 09:57:13 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Wed, 2 Jul 2025 09:57:13 GMT Subject: [crac] RFR: 8361124: [CRaC] Move recursive checkpoint test to simengine [v3] In-Reply-To: References: Message-ID: <7ruy77-nvaiza_voQVZK6raKJAxHnSAIzBUSLc4MEGE=.11a50ba9-2fa5-43f5-9040-4a92aac04686@github.com> On Wed, 2 Jul 2025 09:54:15 GMT, Timofei Pushkin wrote: >> At the moment of creation this PR includes #239 ? that should be merged first. fc33e85c429536dcc89ff59afed6450bb7562639 is the change of this PR. >> >> Makes recursive checkpoint test use `simengine` instead of `pauseengine`. Since that was the only test using `pauseengine`, a separate `PauseEngineTest` is created to test the engine. > > Timofei Pushkin 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 'openjdk-crac/crac' into recursive-cr > - Improve exception handling in recursive C/R test > - Fix recursive checkpoint test > - Make dev engines less confusing Marked as reviewed by rvansa (Committer). ------------- PR Review: https://git.openjdk.org/crac/pull/240#pullrequestreview-2978513034 From tpushkin at openjdk.org Wed Jul 2 12:26:14 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Wed, 2 Jul 2025 12:26:14 GMT Subject: [crac] Integrated: 8361124: [CRaC] Move recursive checkpoint test to simengine In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 07:18:51 GMT, Timofei Pushkin wrote: > At the moment of creation this PR includes #239 ? that should be merged first. fc33e85c429536dcc89ff59afed6450bb7562639 is the change of this PR. > > Makes recursive checkpoint test use `simengine` instead of `pauseengine`. Since that was the only test using `pauseengine`, a separate `PauseEngineTest` is created to test the engine. This pull request has now been integrated. Changeset: 74dabd26 Author: Timofei Pushkin URL: https://git.openjdk.org/crac/commit/74dabd26c7975657f8dc0b35687cfef637a634e2 Stats: 321 lines in 3 files changed: 179 ins; 142 del; 0 mod 8361124: [CRaC] Move recursive checkpoint test to simengine Reviewed-by: rvansa ------------- PR: https://git.openjdk.org/crac/pull/240 From dcherepanov at openjdk.org Fri Jul 11 17:42:52 2025 From: dcherepanov at openjdk.org (Dmitry Cherepanov) Date: Fri, 11 Jul 2025 17:42:52 GMT Subject: [crac] RFR: Merge jdk:jdk-25+19 Message-ID: After [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) removed Page Cache, the merge updates the original patch for [JDK-8353241](https://bugs.openjdk.org/browse/JDK-8353241) by moving some parts for uncommitting unused memory to Page Allocator. Comparing the test results for the original patch from https://github.com/openjdk/crac/pull/219 > the image is 177 MB with G1 while 215 MB with ZGC (fastdebug build, -Xmx1G) my testing shows 201 MB with G1 and 280 MB with ZGC (fastdebug build, -Xmx1G) I expect this part to be updated further after future merge with [JDK-8356716](https://bugs.openjdk.org/browse/JDK-8356716)
Conflicts commit 0b7dcb74717c57308db4f71dfca60dc3496cf566 (HEAD -> merge-jdk, dmitry-crac/merge-jdk) Merge: 74dabd26c79 a71f621a324 Author: Dmitry Cherepanov Date: Fri Jul 4 18:30:22 2025 +0400 Merge with jdk-25+19 diff --git a/src/hotspot/share/gc/z/zPageAllocator.cpp b/src/hotspot/share/gc/z/zPageAllocator.cpp remerge CONFLICT (content): Merge conflict in src/hotspot/share/gc/z/zPageAllocator.cpp index 813ce39fc74..fa37122cb82 100644 --- a/src/hotspot/share/gc/z/zPageAllocator.cpp +++ b/src/hotspot/share/gc/z/zPageAllocator.cpp @@ -740,7 +740,7 @@ bool ZPartition::claim_capacity(ZMemoryAllocation* allocation) { return true; } -size_t ZPartition::uncommit(uint64_t* timeout) { +size_t ZPartition::uncommit(uint64_t* timeout, uintx delay) { ZArray flushed_vmems; size_t flushed = 0; @@ -754,9 +754,9 @@ size_t ZPartition::uncommit(uint64_t* timeout) { const double time_since_last_commit = std::floor(now - _last_commit); const double time_since_last_uncommit = std::floor(now - _last_uncommit); - if (time_since_last_commit < double(ZUncommitDelay)) { + if (time_since_last_commit < double(delay)) { // We have committed within the delay, stop uncommitting. - *timeout = uint64_t(double(ZUncommitDelay) - time_since_last_commit); + *timeout = uint64_t(double(delay) - time_since_last_commit); return 0; } @@ -769,15 +769,15 @@ size_t ZPartition::uncommit(uint64_t* timeout) { if (limit == 0) { // This may occur if the current max capacity for this partition is 0 - // Set timeout to ZUncommitDelay - *timeout = ZUncommitDelay; + // Set timeout to delay + *timeout = delay; return 0; } - if (time_since_last_uncommit < double(ZUncommitDelay)) { + if (time_since_last_uncommit < double(delay)) { // We are in the uncommit phase const size_t num_uncommits_left = _to_uncommit / limit; - const double time_left = double(ZUncommitDelay) - time_since_last_uncommit; + const double time_left = double(delay) - time_since_last_uncommit; if (time_left < *timeout * num_uncommits_left) { // Running out of time, speed up. uint64_t new_timeout = uint64_t(std::floor(time_left / double(num_uncommits_left + 1))); @@ -789,7 +789,7 @@ size_t ZPartition::uncommit(uint64_t* timeout) { _last_uncommit = now; const size_t split = _to_uncommit / limit + 1; - uint64_t new_timeout = ZUncommitDelay / split; + uint64_t new_timeout = delay / split; *timeout = new_timeout; } @@ -2251,57 +2251,10 @@ void ZPageAllocator::decrease_used(size_t size) { // Update atomically since we have concurrent readers const size_t used = Atomic::sub(&_used, size); -<<<<<<< 74dabd26c79 (8361124: [CRaC] Move recursive checkpoint test to simengine) - // Only decrease the overall used and not the generation used, - // since the allocation failed and generation used wasn't bumped. - decrease_used(allocation->size()); - - size_t freed = 0; - - // Free any allocated/flushed pages - ZListRemoveIterator iter(allocation->pages()); - for (ZPage* page; iter.next(&page);) { - freed += page->size(); - recycle_page(page); - } - - // Adjust capacity and used to reflect the failed capacity increase - const size_t remaining = allocation->size() - freed; - decrease_capacity(remaining, true /* set_max_capacity */); - - // Try satisfy stalled allocations - satisfy_stalled(); -} - -size_t ZPageAllocator::uncommit(uint64_t* timeout, uintx delay) { - // We need to join the suspendible thread set while manipulating capacity and - // used, to make sure GC safepoints will have a consistent view. - ZList pages; - size_t flushed; - - { - SuspendibleThreadSetJoiner sts_joiner; - ZLocker locker(&_lock); - - // Never uncommit below min capacity. We flush out and uncommit chunks at - // a time (~0.8% of the max capacity, but at least one granule and at most - // 256M), in case demand for memory increases while we are uncommitting. - const size_t retain = MAX2(_used, _min_capacity); - const size_t release = _capacity - retain; - const size_t limit = MIN2(align_up(_current_max_capacity >> 7, ZGranuleSize), 256 * M); - const size_t flush = MIN2(release, limit); - - // Flush pages to uncommit - flushed = _cache.flush_for_uncommit(flush, &pages, timeout, delay); - if (flushed == 0) { - // Nothing flushed - return 0; -======= // Update used low for (auto& stats : _collection_stats) { if (used < stats._used_low) { stats._used_low = used; ->>>>>>> a71f621a324 (8353694: Resolved Class/Field/Method CP entries missing from AOT Configuration) } } } @@ -2518,10 +2471,14 @@ void ZPageAllocator::print_on_inner(outputStream* st) const { void ZPageAllocator::uncommit_unused_memory() { uint64_t timeout; size_t flushed, uncommitted = 0; - do { - flushed = uncommit(&timeout, 0); - uncommitted += flushed; - } while (flushed > 0); + ZPartitionIterator iter = partition_iterator(); + for (ZPartition* partition; iter.next(&partition);) { + partition->_cache.reset_min(); + do { + flushed = partition->uncommit(&timeout, 0); + uncommitted += flushed; + } while (flushed > 0); + } if (uncommitted > 0) { EventZUncommit event; log_info(gc, heap)("Uncommitted (cleanup): %zuM(%.0f%%)", diff --git a/src/hotspot/share/gc/z/zPageAllocator.hpp b/src/hotspot/share/gc/z/zPageAllocator.hpp remerge CONFLICT (content): Merge conflict in src/hotspot/share/gc/z/zPageAllocator.hpp index d8dcffe011f..4259f60406f 100644 --- a/src/hotspot/share/gc/z/zPageAllocator.hpp +++ b/src/hotspot/share/gc/z/zPageAllocator.hpp @@ -283,13 +283,11 @@ class ZPageAllocator { void threads_do(ThreadClosure* tc) const; -<<<<<<< 74dabd26c79 (8361124: [CRaC] Move recursive checkpoint test to simengine) - void uncommit_unused_memory(); -======= void print_on(outputStream* st) const; void print_extended_on_error(outputStream* st) const; void print_on_error(outputStream* st) const; ->>>>>>> a71f621a324 (8353694: Resolved Class/Field/Method CP entries missing from AOT Configuration) + + void uncommit_unused_memory(); }; class ZPageAllocatorStats { diff --git a/src/hotspot/share/gc/z/zPageCache.cpp b/src/hotspot/share/gc/z/zPageCache.cpp deleted file mode 100644 remerge CONFLICT (modify/delete): src/hotspot/share/gc/z/zPageCache.cpp deleted in a71f621a324 (8353694: Resolved Class/Field/Method CP entries missing from AOT Configuration) and modified in 74dabd26c79 (8361124: [CRaC] Move recursive checkpoint test to simengine). Version 74dabd26c79 (8361124: [CRaC] Move recursive checkpoint test to simengine) of src/hotspot/share/gc/z/zPageCache.cpp left in tree. index 4d35db5197b..00000000000 --- a/src/hotspot/share/gc/z/zPageCache.cpp +++ /dev/null @@ -1,334 +0,0 @@ -/* - * Copyright (c) 2015, 2025, Oracle and/or its affiliates. All rights reserved. - * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. - * - * This code is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License version 2 only, as - * published by the Free Software Foundation. - * - * This code is distributed in the hope that it will be useful, but WITHOUT - * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or - * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License - * version 2 for more details (a copy is included in the LICENSE file that - * accompanied this code). - * - * You should have received a copy of the GNU General Public License version - * 2 along with this work; if not, write to the Free Software Foundation, - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. - * - * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA - * or visit www.oracle.com if you need additional information or have any - * questions. - */ - -#include "gc/z/zGlobals.hpp" -#include "gc/z/zList.inline.hpp" -#include "gc/z/zNUMA.inline.hpp" -#include "gc/z/zPage.inline.hpp" -#include "gc/z/zPageCache.hpp" -#include "gc/z/zStat.hpp" -#include "gc/z/zValue.inline.hpp" -#include "memory/allocation.hpp" -#include "runtime/globals.hpp" -#include "runtime/os.hpp" - -static const ZStatCounter ZCounterPageCacheHitL1("Memory", "Page Cache Hit L1", ZStatUnitOpsPerSecond); -static const ZStatCounter ZCounterPageCacheHitL2("Memory", "Page Cache Hit L2", ZStatUnitOpsPerSecond); -static const ZStatCounter ZCounterPageCacheHitL3("Memory", "Page Cache Hit L3", ZStatUnitOpsPerSecond); -static const ZStatCounter ZCounterPageCacheMiss("Memory", "Page Cache Miss", ZStatUnitOpsPerSecond); - -class ZPageCacheFlushClosure : public StackObj { - friend class ZPageCache; - -protected: - const size_t _requested; - size_t _flushed; - -public: - ZPageCacheFlushClosure(size_t requested); - virtual bool do_page(const ZPage* page) = 0; -}; - -ZPageCacheFlushClosure::ZPageCacheFlushClosure(size_t requested) - : _requested(requested), - _flushed(0) {} - -ZPageCache::ZPageCache() - : _small(), - _medium(), - _large(), - _last_commit(0) {} - -ZPage* ZPageCache::alloc_small_page() { - const uint32_t numa_id = ZNUMA::id(); - const uint32_t numa_count = ZNUMA::count(); - - // Try NUMA local page cache - ZPage* const l1_page = _small.get(numa_id).remove_first(); - if (l1_page != nullptr) { - ZStatInc(ZCounterPageCacheHitL1); - return l1_page; - } - - // Try NUMA remote page cache(s) - uint32_t remote_numa_id = numa_id + 1; - const uint32_t remote_numa_count = numa_count - 1; - for (uint32_t i = 0; i < remote_numa_count; i++) { - if (remote_numa_id == numa_count) { - remote_numa_id = 0; - } - - ZPage* const l2_page = _small.get(remote_numa_id).remove_first(); - if (l2_page != nullptr) { - ZStatInc(ZCounterPageCacheHitL2); - return l2_page; - } - - remote_numa_id++; - } - - return nullptr; -} - -ZPage* ZPageCache::alloc_medium_page() { - ZPage* const page = _medium.remove_first(); - if (page != nullptr) { - ZStatInc(ZCounterPageCacheHitL1); - return page; - } - - return nullptr; -} - -ZPage* ZPageCache::alloc_large_page(size_t size) { - // Find a page with the right size - ZListIterator iter(&_large); - for (ZPage* page; iter.next(&page);) { - if (size == page->size()) { - // Page found - _large.remove(page); - ZStatInc(ZCounterPageCacheHitL1); - return page; - } - } - - return nullptr; -} - -ZPage* ZPageCache::alloc_oversized_medium_page(size_t size) { - if (size <= ZPageSizeMedium) { - return _medium.remove_first(); - } - - return nullptr; -} - -ZPage* ZPageCache::alloc_oversized_large_page(size_t size) { - // Find a page that is large enough - ZListIterator iter(&_large); - for (ZPage* page; iter.next(&page);) { - if (size <= page->size()) { - // Page found - _large.remove(page); - return page; - } - } - - return nullptr; -} - -ZPage* ZPageCache::alloc_oversized_page(size_t size) { - ZPage* page = alloc_oversized_large_page(size); - if (page == nullptr) { - page = alloc_oversized_medium_page(size); - } - - if (page != nullptr) { - ZStatInc(ZCounterPageCacheHitL3); - } - - return page; -} - -ZPage* ZPageCache::alloc_page(ZPageType type, size_t size) { - ZPage* page; - - // Try allocate exact page - if (type == ZPageType::small) { - page = alloc_small_page(); - } else if (type == ZPageType::medium) { - page = alloc_medium_page(); - } else { - page = alloc_large_page(size); - } - - if (page == nullptr) { - // Try allocate potentially oversized page - ZPage* const oversized = alloc_oversized_page(size); - if (oversized != nullptr) { - if (size < oversized->size()) { - // Split oversized page - page = oversized->split(type, size); - - // Cache remainder - free_page(oversized); - } else { - // Re-type correctly sized page - page = oversized->retype(type); - } - } - } - - if (page == nullptr) { - ZStatInc(ZCounterPageCacheMiss); - } - - return page; -} - -void ZPageCache::free_page(ZPage* page) { - const ZPageType type = page->type(); - if (type == ZPageType::small) { - _small.get(page->numa_id()).insert_first(page); - } else if (type == ZPageType::medium) { - _medium.insert_first(page); - } else { - _large.insert_first(page); - } -} - -bool ZPageCache::flush_list_inner(ZPageCacheFlushClosure* cl, ZList* from, ZList* to) { - ZPage* const page = from->last(); - if (page == nullptr || !cl->do_page(page)) { - // Don't flush page - return false; - } - - // Flush page - from->remove(page); - to->insert_last(page); - return true; -} - -void ZPageCache::flush_list(ZPageCacheFlushClosure* cl, ZList* from, ZList* to) { - while (flush_list_inner(cl, from, to)); -} - -void ZPageCache::flush_per_numa_lists(ZPageCacheFlushClosure* cl, ZPerNUMA >* from, ZList* to) { - const uint32_t numa_count = ZNUMA::count(); - uint32_t numa_done = 0; - uint32_t numa_next = 0; - - // Flush lists round-robin - while (numa_done < numa_count) { - ZList* const numa_list = from->addr(numa_next); - if (++numa_next == numa_count) { - numa_next = 0; - } - - if (flush_list_inner(cl, numa_list, to)) { - // Not done - numa_done = 0; - } else { - // Done - numa_done++; - } - } -} - -void ZPageCache::flush(ZPageCacheFlushClosure* cl, ZList* to) { - // Prefer flushing large, then medium and last small pages - flush_list(cl, &_large, to); - flush_list(cl, &_medium, to); - flush_per_numa_lists(cl, &_small, to); - - if (cl->_flushed > cl->_requested) { - // Overflushed, re-insert part of last page into the cache - const size_t overflushed = cl->_flushed - cl->_requested; - ZPage* const reinsert = to->last()->split(overflushed); - free_page(reinsert); - cl->_flushed -= overflushed; - } -} - -class ZPageCacheFlushForAllocationClosure : public ZPageCacheFlushClosure { -public: - ZPageCacheFlushForAllocationClosure(size_t requested) - : ZPageCacheFlushClosure(requested) {} - - virtual bool do_page(const ZPage* page) { - if (_flushed < _requested) { - // Flush page - _flushed += page->size(); - return true; - } - - // Don't flush page - return false; - } -}; - -void ZPageCache::flush_for_allocation(size_t requested, ZList* to) { - ZPageCacheFlushForAllocationClosure cl(requested); - flush(&cl, to); -} - -class ZPageCacheFlushForUncommitClosure : public ZPageCacheFlushClosure { -private: - const uint64_t _now; - uint64_t* _timeout; - uintx _delay; - -public: - ZPageCacheFlushForUncommitClosure(size_t requested, uint64_t now, uint64_t* timeout, uintx delay) - : ZPageCacheFlushClosure(requested), - _now(now), - _timeout(timeout), - _delay(delay) { - // Set initial timeout - *_timeout = delay; - } - - virtual bool do_page(const ZPage* page) { - const uint64_t expires = page->last_used() + _delay; - if (expires > _now) { - // Don't flush page, record shortest non-expired timeout - *_timeout = MIN2(*_timeout, expires - _now); - return false; - } - - if (_flushed >= _requested) { - // Don't flush page, requested amount flushed - return false; - } - - // Flush page - _flushed += page->size(); - return true; - } -}; - -size_t ZPageCache::flush_for_uncommit(size_t requested, ZList* to, uint64_t* timeout, uintx delay) { - const uint64_t now = (uint64_t)os::elapsedTime(); - const uint64_t expires = _last_commit + delay; - if (expires > now) { - // Delay uncommit, set next timeout - *timeout = expires - now; - return 0; - } - - if (requested == 0) { - // Nothing to flush, set next timeout - *timeout = delay; - return 0; - } - - ZPageCacheFlushForUncommitClosure cl(requested, now, timeout, delay); - flush(&cl, to); - - return cl._flushed; -} - -void ZPageCache::set_last_commit() { - _last_commit = (uint64_t)ceil(os::elapsedTime()); -} diff --git a/src/hotspot/share/gc/z/zPageCache.hpp b/src/hotspot/share/gc/z/zPageCache.hpp deleted file mode 100644 remerge CONFLICT (modify/delete): src/hotspot/share/gc/z/zPageCache.hpp deleted in a71f621a324 (8353694: Resolved Class/Field/Method CP entries missing from AOT Configuration) and modified in 74dabd26c79 (8361124: [CRaC] Move recursive checkpoint test to simengine). Version 74dabd26c79 (8361124: [CRaC] Move recursive checkpoint test to simengine) of src/hotspot/share/gc/z/zPageCache.hpp left in tree. index e36662e387d..00000000000 --- a/src/hotspot/share/gc/z/zPageCache.hpp +++ /dev/null @@ -1,66 +0,0 @@ -/* - * Copyright (c) 2015, 2023, Oracle and/or its affiliates. All rights reserved. - * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. - * - * This code is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License version 2 only, as - * published by the Free Software Foundation. - * - * This code is distributed in the hope that it will be useful, but WITHOUT - * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or - * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License - * version 2 for more details (a copy is included in the LICENSE file that - * accompanied this code). - * - * You should have received a copy of the GNU General Public License version - * 2 along with this work; if not, write to the Free Software Foundation, - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. - * - * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA - * or visit www.oracle.com if you need additional information or have any - * questions. - */ - -#ifndef SHARE_GC_Z_ZPAGECACHE_HPP -#define SHARE_GC_Z_ZPAGECACHE_HPP - -#include "gc/z/zList.hpp" -#include "gc/z/zPage.hpp" -#include "gc/z/zPageType.hpp" -#include "gc/z/zValue.hpp" - -class ZPageCacheFlushClosure; - -class ZPageCache { -private: - ZPerNUMA > _small; - ZList _medium; - ZList _large; - uint64_t _last_commit; - - ZPage* alloc_small_page(); - ZPage* alloc_medium_page(); - ZPage* alloc_large_page(size_t size); - - ZPage* alloc_oversized_medium_page(size_t size); - ZPage* alloc_oversized_large_page(size_t size); - ZPage* alloc_oversized_page(size_t size); - - bool flush_list_inner(ZPageCacheFlushClosure* cl, ZList* from, ZList* to); - void flush_list(ZPageCacheFlushClosure* cl, ZList* from, ZList* to); - void flush_per_numa_lists(ZPageCacheFlushClosure* cl, ZPerNUMA >* from, ZList* to); - void flush(ZPageCacheFlushClosure* cl, ZList* to); - -public: - ZPageCache(); - - ZPage* alloc_page(ZPageType type, size_t size); - void free_page(ZPage* page); - - void flush_for_allocation(size_t requested, ZList* to); - size_t flush_for_uncommit(size_t requested, ZList* to, uint64_t* timeout, uintx delay); - - void set_last_commit(); -}; - -#endif // SHARE_GC_Z_ZPAGECACHE_HPP diff --git a/src/hotspot/share/gc/z/zUncommitter.cpp b/src/hotspot/share/gc/z/zUncommitter.cpp remerge CONFLICT (content): Merge conflict in src/hotspot/share/gc/z/zUncommitter.cpp index 4505c95db1c..6ecbc6e6201 100644 --- a/src/hotspot/share/gc/z/zUncommitter.cpp +++ b/src/hotspot/share/gc/z/zUncommitter.cpp @@ -68,13 +68,8 @@ void ZUncommitter::run_thread() { while (should_continue()) { // Uncommit chunk -<<<<<<< 74dabd26c79 (8361124: [CRaC] Move recursive checkpoint test to simengine) - const size_t flushed = _page_allocator->uncommit(&timeout, ZUncommitDelay); - if (flushed == 0) { -======= - const size_t uncommitted = _partition->uncommit(&timeout); + const size_t uncommitted = _partition->uncommit(&timeout, ZUncommitDelay); if (uncommitted == 0) { ->>>>>>> a71f621a324 (8353694: Resolved Class/Field/Method CP entries missing from AOT Configuration) // Done break; } diff --git a/src/hotspot/share/logging/logAsyncWriter.cpp b/src/hotspot/share/logging/logAsyncWriter.cpp remerge CONFLICT (content): Merge conflict in src/hotspot/share/logging/logAsyncWriter.cpp index ff7c85b5c1d..dd82998a52e 100644 --- a/src/hotspot/share/logging/logAsyncWriter.cpp +++ b/src/hotspot/share/logging/logAsyncWriter.cpp @@ -358,7 +358,6 @@ void AsyncLogWriter::flush() { _instance->_flush_sem.wait(); } } -<<<<<<< 74dabd26c79 (8361124: [CRaC] Move recursive checkpoint test to simengine) void AsyncLogWriter::stop() { _block_async.lock(); @@ -368,29 +367,3 @@ void AsyncLogWriter::stop() { void AsyncLogWriter::resume() { _block_async.unlock(); } - -AsyncLogWriter::BufferUpdater::BufferUpdater(size_t newsize) { - ConsumerLocker clocker; - auto p = AsyncLogWriter::_instance; - - _buf1 = p->_buffer; - _buf2 = p->_buffer_staging; - p->_buffer = new Buffer(newsize); - p->_buffer_staging = new Buffer(newsize); -} - -AsyncLogWriter::BufferUpdater::~BufferUpdater() { - AsyncLogWriter::flush(); - auto p = AsyncLogWriter::_instance; - - { - ConsumerLocker clocker; - - delete p->_buffer; - delete p->_buffer_staging; - p->_buffer = _buf1; - p->_buffer_staging = _buf2; - } -} -======= ->>>>>>> a71f621a324 (8353694: Resolved Class/Field/Method CP entries missing from AOT Configuration) diff --git a/src/hotspot/share/runtime/threads.cpp b/src/hotspot/share/runtime/threads.cpp remerge CONFLICT (content): Merge conflict in src/hotspot/share/runtime/threads.cpp index 38550f61e48..4cfb43f6c01 100644 --- a/src/hotspot/share/runtime/threads.cpp +++ b/src/hotspot/share/runtime/threads.cpp @@ -426,7 +426,6 @@ void Threads::initialize_jsr292_core_classes(TRAPS) { } } -<<<<<<< 74dabd26c79 (8361124: [CRaC] Move recursive checkpoint test to simengine) static jint check_for_restore(JavaVMInitArgs* args) { if (Arguments::is_restore_option_set(args)) { if (!Arguments::parse_options_for_restore(args)) { @@ -435,7 +434,7 @@ static jint check_for_restore(JavaVMInitArgs* args) { } return JNI_OK; } -======= + // One-shot PeriodicTask subclass for reading the release file class ReadReleaseFileTask : public PeriodicTask { public: @@ -448,7 +447,6 @@ class ReadReleaseFileTask : public PeriodicTask { delete this; } }; ->>>>>>> a71f621a324 (8353694: Resolved Class/Field/Method CP entries missing from AOT Configuration) jint Threads::create_vm(JavaVMInitArgs* args, bool* canTryAgain) { extern void JDK_Version_init(); @@ -617,7 +615,6 @@ jint Threads::create_vm(JavaVMInitArgs* args, bool* canTryAgain) { return status; } -<<<<<<< 74dabd26c79 (8361124: [CRaC] Move recursive checkpoint test to simengine) // Output stream module should be already initialized for error reporting during restore. // JDK version should also be intialized. There is lot of initializations needed to read // the current machine's CPUFeatures. @@ -628,11 +625,10 @@ jint Threads::create_vm(JavaVMInitArgs* args, bool* canTryAgain) { return JNI_ERR; } } -======= + // Have the WatcherThread read the release file in the background. ReadReleaseFileTask* read_task = new ReadReleaseFileTask(); read_task->enroll(); ->>>>>>> a71f621a324 (8353694: Resolved Class/Field/Method CP entries missing from AOT Configuration) // Create WatcherThread as soon as we can since we need it in case // of hangs during error reporting.
------------- Commit messages: - Merge with jdk-25+19 - 8353694: Resolved Class/Field/Method CP entries missing from AOT Configuration - 8329887: RISC-V: C2: Support Zvbb Vector And-Not instruction - 8354559: gc/g1/TestAllocationFailure.java doesn't need WB API - 8295651: JFR: 'jfr scrub' should summarize what was removed - 8354471: Assertion failure with -XX:-EnableX86ECoreOpts - 8353589: Open source a few Swing menu-related tests - 8352001: AOT cache should not contain classes injected into built-in class loaders - 8354873: javax/swing/plaf/metal/MetalIconFactory/bug4952462.java failing on CI - 8351603: Change to GCC 14.2.0 for building on Linux at Oracle - ... and 108 more: https://git.openjdk.org/crac/compare/74dabd26...0b7dcb74 The webrevs contain the adjustments done while merging with regards to each parent branch: - crac: https://webrevs.openjdk.org/?repo=crac&pr=242&range=00.0 - jdk:jdk-25+19: https://webrevs.openjdk.org/?repo=crac&pr=242&range=00.1 Changes: https://git.openjdk.org/crac/pull/242/files Stats: 200018 lines in 645 files changed: 23990 ins; 173323 del; 2705 mod Patch: https://git.openjdk.org/crac/pull/242.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/242/head:pull/242 PR: https://git.openjdk.org/crac/pull/242 From tpushkin at openjdk.org Mon Jul 14 07:47:02 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Mon, 14 Jul 2025 07:47:02 GMT Subject: [crac] RFR: Merge jdk:jdk-25+19 In-Reply-To: References: Message-ID: On Fri, 11 Jul 2025 17:36:37 GMT, Dmitry Cherepanov wrote: > After [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) removed Page Cache, the merge updates the original patch for [JDK-8353241](https://bugs.openjdk.org/browse/JDK-8353241) by moving some parts for uncommitting unused memory to Page Allocator. > > Comparing the test results for the original patch from https://github.com/openjdk/crac/pull/219 >> the image is 177 MB with G1 while 215 MB with ZGC (fastdebug build, -Xmx1G) > > my testing shows 201 MB with G1 and 280 MB with ZGC (fastdebug build, -Xmx1G) > > I expect this part to be updated further after future merge with [JDK-8356716](https://bugs.openjdk.org/browse/JDK-8356716) > >
> > Conflicts > > > commit 0b7dcb74717c57308db4f71dfca60dc3496cf566 (HEAD -> merge-jdk, dmitry-crac/merge-jdk) > Merge: 74dabd26c79 a71f621a324 > Author: Dmitry Cherepanov > Date: Fri Jul 4 18:30:22 2025 +0400 > > Merge with jdk-25+19 > > diff --git a/src/hotspot/share/gc/z/zPageAllocator.cpp b/src/hotspot/share/gc/z/zPageAllocator.cpp > remerge CONFLICT (content): Merge conflict in src/hotspot/share/gc/z/zPageAllocator.cpp > index 813ce39fc74..fa37122cb82 100644 > --- a/src/hotspot/share/gc/z/zPageAllocator.cpp > +++ b/src/hotspot/share/gc/z/zPageAllocator.cpp > @@ -740,7 +740,7 @@ bool ZPartition::claim_capacity(ZMemoryAllocation* allocation) { > return true; > } > > -size_t ZPartition::uncommit(uint64_t* timeout) { > +size_t ZPartition::uncommit(uint64_t* timeout, uintx delay) { > ZArray flushed_vmems; > size_t flushed = 0; > > @@ -754,9 +754,9 @@ size_t ZPartition::uncommit(uint64_t* timeout) { > const double time_since_last_commit = std::floor(now - _last_commit); > const double time_since_last_uncommit = std::floor(now - _last_uncommit); > > - if (time_since_last_commit < double(ZUncommitDelay)) { > + if (time_since_last_commit < double(delay)) { > // We have committed within the delay, stop uncommitting. > - *timeout = uint64_t(double(ZUncommitDelay) - time_since_last_commit); > + *timeout = uint64_t(double(delay) - time_since_last_commit); > return 0; > } > > @@ -769,15 +769,15 @@ size_t ZPartition::uncommit(uint64_t* timeout) { > if (limit == 0) { > // This may occur if the current max capacity for this partition is 0 > > - // Set timeout to ZUncommitDelay > - *timeout = ZUncommitDelay; > + // Set timeout to delay > + *timeout = delay; > return 0; > } > > - if (time_since_last_uncommit < double(ZUncommitDelay)) { > + if (time_sin... LGTM, thank you. Checked ZGC+CRIU image size on a Helidon-based benchmark, the old and the new code performs the same for me: w/o CRaC's heap shrinking w/ CRaC's heap shrinking old 3.6 GB 80?100 MB new 3.5 GB 80?85 MB ------------- Marked as reviewed by tpushkin (Committer). PR Review: https://git.openjdk.org/crac/pull/242#pullrequestreview-3015119840 From dcherepanov at openjdk.org Mon Jul 14 08:46:12 2025 From: dcherepanov at openjdk.org (Dmitry Cherepanov) Date: Mon, 14 Jul 2025 08:46:12 GMT Subject: [crac] RFR: Merge jdk:jdk-25+19 In-Reply-To: References: Message-ID: On Fri, 11 Jul 2025 17:36:37 GMT, Dmitry Cherepanov wrote: > After [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) removed Page Cache, the merge updates the original patch for [JDK-8353241](https://bugs.openjdk.org/browse/JDK-8353241) by moving some parts for uncommitting unused memory to Page Allocator. > > Comparing the test results for the original patch from https://github.com/openjdk/crac/pull/219 >> the image is 177 MB with G1 while 215 MB with ZGC (fastdebug build, -Xmx1G) > > my testing shows 201 MB with G1 and 280 MB with ZGC (fastdebug build, -Xmx1G) > > I expect this part to be updated further after future merge with [JDK-8356716](https://bugs.openjdk.org/browse/JDK-8356716) > >
> > Conflicts > > > commit 0b7dcb74717c57308db4f71dfca60dc3496cf566 (HEAD -> merge-jdk, dmitry-crac/merge-jdk) > Merge: 74dabd26c79 a71f621a324 > Author: Dmitry Cherepanov > Date: Fri Jul 4 18:30:22 2025 +0400 > > Merge with jdk-25+19 > > diff --git a/src/hotspot/share/gc/z/zPageAllocator.cpp b/src/hotspot/share/gc/z/zPageAllocator.cpp > remerge CONFLICT (content): Merge conflict in src/hotspot/share/gc/z/zPageAllocator.cpp > index 813ce39fc74..fa37122cb82 100644 > --- a/src/hotspot/share/gc/z/zPageAllocator.cpp > +++ b/src/hotspot/share/gc/z/zPageAllocator.cpp > @@ -740,7 +740,7 @@ bool ZPartition::claim_capacity(ZMemoryAllocation* allocation) { > return true; > } > > -size_t ZPartition::uncommit(uint64_t* timeout) { > +size_t ZPartition::uncommit(uint64_t* timeout, uintx delay) { > ZArray flushed_vmems; > size_t flushed = 0; > > @@ -754,9 +754,9 @@ size_t ZPartition::uncommit(uint64_t* timeout) { > const double time_since_last_commit = std::floor(now - _last_commit); > const double time_since_last_uncommit = std::floor(now - _last_uncommit); > > - if (time_since_last_commit < double(ZUncommitDelay)) { > + if (time_since_last_commit < double(delay)) { > // We have committed within the delay, stop uncommitting. > - *timeout = uint64_t(double(ZUncommitDelay) - time_since_last_commit); > + *timeout = uint64_t(double(delay) - time_since_last_commit); > return 0; > } > > @@ -769,15 +769,15 @@ size_t ZPartition::uncommit(uint64_t* timeout) { > if (limit == 0) { > // This may occur if the current max capacity for this partition is 0 > > - // Set timeout to ZUncommitDelay > - *timeout = ZUncommitDelay; > + // Set timeout to delay > + *timeout = delay; > return 0; > } > > - if (time_since_last_uncommit < double(ZUncommitDelay)) { > + if (time_sin... Thanks for the review ------------- PR Comment: https://git.openjdk.org/crac/pull/242#issuecomment-3068437604 From duke at openjdk.org Mon Jul 14 08:46:12 2025 From: duke at openjdk.org (duke) Date: Mon, 14 Jul 2025 08:46:12 GMT Subject: [crac] RFR: Merge jdk:jdk-25+19 In-Reply-To: References: Message-ID: On Fri, 11 Jul 2025 17:36:37 GMT, Dmitry Cherepanov wrote: > After [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) removed Page Cache, the merge updates the original patch for [JDK-8353241](https://bugs.openjdk.org/browse/JDK-8353241) by moving some parts for uncommitting unused memory to Page Allocator. > > Comparing the test results for the original patch from https://github.com/openjdk/crac/pull/219 >> the image is 177 MB with G1 while 215 MB with ZGC (fastdebug build, -Xmx1G) > > my testing shows 201 MB with G1 and 280 MB with ZGC (fastdebug build, -Xmx1G) > > I expect this part to be updated further after future merge with [JDK-8356716](https://bugs.openjdk.org/browse/JDK-8356716) > >
> > Conflicts > > > commit 0b7dcb74717c57308db4f71dfca60dc3496cf566 (HEAD -> merge-jdk, dmitry-crac/merge-jdk) > Merge: 74dabd26c79 a71f621a324 > Author: Dmitry Cherepanov > Date: Fri Jul 4 18:30:22 2025 +0400 > > Merge with jdk-25+19 > > diff --git a/src/hotspot/share/gc/z/zPageAllocator.cpp b/src/hotspot/share/gc/z/zPageAllocator.cpp > remerge CONFLICT (content): Merge conflict in src/hotspot/share/gc/z/zPageAllocator.cpp > index 813ce39fc74..fa37122cb82 100644 > --- a/src/hotspot/share/gc/z/zPageAllocator.cpp > +++ b/src/hotspot/share/gc/z/zPageAllocator.cpp > @@ -740,7 +740,7 @@ bool ZPartition::claim_capacity(ZMemoryAllocation* allocation) { > return true; > } > > -size_t ZPartition::uncommit(uint64_t* timeout) { > +size_t ZPartition::uncommit(uint64_t* timeout, uintx delay) { > ZArray flushed_vmems; > size_t flushed = 0; > > @@ -754,9 +754,9 @@ size_t ZPartition::uncommit(uint64_t* timeout) { > const double time_since_last_commit = std::floor(now - _last_commit); > const double time_since_last_uncommit = std::floor(now - _last_uncommit); > > - if (time_since_last_commit < double(ZUncommitDelay)) { > + if (time_since_last_commit < double(delay)) { > // We have committed within the delay, stop uncommitting. > - *timeout = uint64_t(double(ZUncommitDelay) - time_since_last_commit); > + *timeout = uint64_t(double(delay) - time_since_last_commit); > return 0; > } > > @@ -769,15 +769,15 @@ size_t ZPartition::uncommit(uint64_t* timeout) { > if (limit == 0) { > // This may occur if the current max capacity for this partition is 0 > > - // Set timeout to ZUncommitDelay > - *timeout = ZUncommitDelay; > + // Set timeout to delay > + *timeout = delay; > return 0; > } > > - if (time_since_last_uncommit < double(ZUncommitDelay)) { > + if (time_sin... @dimitryc Your change (at version 0b7dcb74717c57308db4f71dfca60dc3496cf566) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/crac/pull/242#issuecomment-3068446909 From dcherepanov at openjdk.org Tue Jul 15 06:02:20 2025 From: dcherepanov at openjdk.org (Dmitry Cherepanov) Date: Tue, 15 Jul 2025 06:02:20 GMT Subject: [crac] Integrated: Merge jdk:jdk-25+19 In-Reply-To: References: Message-ID: On Fri, 11 Jul 2025 17:36:37 GMT, Dmitry Cherepanov wrote: > After [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) removed Page Cache, the merge updates the original patch for [JDK-8353241](https://bugs.openjdk.org/browse/JDK-8353241) by moving some parts for uncommitting unused memory to Page Allocator. > > Comparing the test results for the original patch from https://github.com/openjdk/crac/pull/219 >> the image is 177 MB with G1 while 215 MB with ZGC (fastdebug build, -Xmx1G) > > my testing shows 201 MB with G1 and 280 MB with ZGC (fastdebug build, -Xmx1G) > > I expect this part to be updated further after future merge with [JDK-8356716](https://bugs.openjdk.org/browse/JDK-8356716) > >
> > Conflicts > > > commit 0b7dcb74717c57308db4f71dfca60dc3496cf566 (HEAD -> merge-jdk, dmitry-crac/merge-jdk) > Merge: 74dabd26c79 a71f621a324 > Author: Dmitry Cherepanov > Date: Fri Jul 4 18:30:22 2025 +0400 > > Merge with jdk-25+19 > > diff --git a/src/hotspot/share/gc/z/zPageAllocator.cpp b/src/hotspot/share/gc/z/zPageAllocator.cpp > remerge CONFLICT (content): Merge conflict in src/hotspot/share/gc/z/zPageAllocator.cpp > index 813ce39fc74..fa37122cb82 100644 > --- a/src/hotspot/share/gc/z/zPageAllocator.cpp > +++ b/src/hotspot/share/gc/z/zPageAllocator.cpp > @@ -740,7 +740,7 @@ bool ZPartition::claim_capacity(ZMemoryAllocation* allocation) { > return true; > } > > -size_t ZPartition::uncommit(uint64_t* timeout) { > +size_t ZPartition::uncommit(uint64_t* timeout, uintx delay) { > ZArray flushed_vmems; > size_t flushed = 0; > > @@ -754,9 +754,9 @@ size_t ZPartition::uncommit(uint64_t* timeout) { > const double time_since_last_commit = std::floor(now - _last_commit); > const double time_since_last_uncommit = std::floor(now - _last_uncommit); > > - if (time_since_last_commit < double(ZUncommitDelay)) { > + if (time_since_last_commit < double(delay)) { > // We have committed within the delay, stop uncommitting. > - *timeout = uint64_t(double(ZUncommitDelay) - time_since_last_commit); > + *timeout = uint64_t(double(delay) - time_since_last_commit); > return 0; > } > > @@ -769,15 +769,15 @@ size_t ZPartition::uncommit(uint64_t* timeout) { > if (limit == 0) { > // This may occur if the current max capacity for this partition is 0 > > - // Set timeout to ZUncommitDelay > - *timeout = ZUncommitDelay; > + // Set timeout to delay > + *timeout = delay; > return 0; > } > > - if (time_since_last_uncommit < double(ZUncommitDelay)) { > + if (time_sin... This pull request has now been integrated. Changeset: 698225b6 Author: Dmitry Cherepanov Committer: Timofei Pushkin URL: https://git.openjdk.org/crac/commit/698225b65948339acbcfba1c5768fe0f5c90fe77 Stats: 200018 lines in 645 files changed: 23990 ins; 173323 del; 2705 mod Merge jdk:jdk-25+19 Reviewed-by: tpushkin ------------- PR: https://git.openjdk.org/crac/pull/242 From tpushkin at openjdk.org Wed Jul 16 14:03:35 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Wed, 16 Jul 2025 14:03:35 GMT Subject: [crac] RFR: 8362418: [CRaC] Leave unused G1 heap regions committed for C/R Message-ID: <-TiVEuvzgvvuO-I_pKCmNpw4WGsFmbwKqCv29Qyj2ks=.8de100bf-c7f8-4d69-a8ec-1f87fcddbe9f@github.com> See the JBS issue for the problem statement and the suggested approach to fix it. This PR: 1. Implements the approach by expanding G1 heap back after shrinking and uncommitting it: shrink+uncommit makes memory in free regions uncommitted, expand commits it back. 2. Removes `CollectedHeap::finish_collection()` added in #93 because it was only used in G1 to synchronize uncommitting with C/R but now uncommitting is performed synchronously during the CRaC-invoked full GC, i.e. it became redundant. 3. Renames `CollectedHeap::do_cleanup_unused()` to `CollectedHeap::should_cleanup_unused()` because I find the old name unintuitive: it sounds like the method _does_ the actual work while in reality it just returns whether the work _should_ be done. Notes: - If `-XX:+AlwaysPreTouch` is used (not the default) the cleaned-up pages will become OS-reserved again immediately which means that if the C/R engine saves such memory into the image the image size will become larger after this change than it was before. This is OK since it is off by default and some engines can handle pre-touched pages without fully saving them into the image. - G1 heap still gets shrunk during C/R because of the automatic shrinking. But it is less aggressive as before which is enough not to cause immediate full/mixed GCs in my testing. The user can also set `MaxHeapFreeRatio` to a larger value during C/R to reduce the shrinking (or even disable it completely) if needed ? that was not possible before. I used a benchmark based on wrk and Helidon's hello-world example to check if there are any performance gains. On JDK 25+14 I saw a 2?3% improvement for the first after-restore iteration performance (before there was a ~4% regression in last-before-checkpoint iteration vs first-after-restore iteration ? it became ~1.4%) and a 20% start-up speed-up (100ms vs 80ms). However, between 25+14 and 25+18 there has been some change made that improved the baseline performance to roughly the same level, so the improvement brought by my fix became almost unnoticeable on this particular benchmark on JDK 25+18. But in GC logs it is clear that less work is performed on restore so I still believe the change is beneficial:
W/o the change The heap is shrunk from 252MB to 4MB and preparations for mixed GC are performed. Sometimes (but not this time) mixed GCs themselves occur, on 25+14 there were full GCs even. [1752668313926ms] ################# benchmark before C/R start ################# [26.924s][info][gc] GC(121) Pause Young (Normal) (G1 Evacuation Pause) 152M->4M(252M) 0.691ms [27.146s][info][gc] GC(122) Pause Young (Normal) (G1 Evacuation Pause) 152M->4M(252M) 0.676ms [27.368s][info][gc] GC(123) Pause Young (Normal) (G1 Evacuation Pause) 152M->4M(252M) 0.645ms [27.589s][info][gc] GC(124) Pause Young (Normal) (G1 Evacuation Pause) 152M->4M(252M) 0.657ms [27.807s][info][gc] GC(125) Pause Young (Normal) (G1 Evacuation Pause) 152M->4M(252M) 0.678ms [1752668315029ms] ################# benchmark before C/R finish ################# 2025.07.16 14:18:35.218 INFO Starting checkpoint 2025.07.16 14:18:35.221 INFO [0x2bde2f6b] @default socket closed. [28.124s][info][gc] GC(126) Pause Full (System.gc()) 84M->3M(28M) 8.329ms [28.145s][info][gc] GC(127) Pause Full (System.gc()) 4M->3M(14M) 10.228ms [28.165s][info][gc] GC(128) Pause Full (FullGCAlot) 4M->3M(4M) 7.684ms [28.169s][info][crac] Checkpoint ... [28.750s][info][gc ] GC(129) Pause Young (Concurrent Start) (G1 Evacuation Pause) 3M->3M(4M) 5.813ms [28.750s][info][gc ] GC(130) Concurrent Mark Cycle [28.762s][info][gc ] GC(130) Pause Remark 3M->3M(8M) 3.104ms [28.763s][info][gc ] GC(130) Pause Cleanup 3M->3M(8M) 0.007ms [28.763s][info][gc ] GC(130) Concurrent Mark Cycle 13.344ms 2025.07.16 14:18:35.872 INFO [0x3789f1cb] http://0.0.0.0:8080 bound for socket '@default' 2025.07.16 14:18:35.874 INFO Restored all channels in 1 milliseconds. 104 milliseconds since JVM snapshot restore. Java 25-internal-adhoc.timpushkin.crac [1752668315905ms] ################# benchmark after C/R start ################# [28.803s][info][gc ] GC(131) Pause Young (Normal) (G1 Evacuation Pause) 5M->3M(8M) 0.800ms [28.807s][info][gc ] GC(132) Pause Young (Concurrent Start) (G1 Evacuation Pause) 5M->4M(10M) 0.766ms [28.807s][info][gc ] GC(133) Concurrent Mark Cycle [28.810s][info][gc ] GC(133) Pause Remark 4M->4M(10M) 0.684ms [28.810s][info][gc ] GC(133) Pause Cleanup 4M->4M(10M) 0.004ms [28.810s][info][gc ] GC(133) Concurrent Mark Cycle 3.516ms [28.813s][info][gc ] GC(134) Pause Young (Normal) (G1 Evacuation Pause) 6M->4M(10M) 0.516ms [28.816s][info][gc ] GC(135) Pause Young (Normal) (G1 Evacuation Pause) 6M->4M(10M) 0.524ms [28.821s][info][gc ] GC(136) Pause Young (Normal) (G1 Evacuation Pause) 6M->4M(130M) 0.633ms [28.911s][info][gc ] GC(137) Pause Young (Normal) (G1 Evacuation Pause) 80M->4M(130M) 0.720ms [29.013s][info][gc ] GC(138) Pause Young (Normal) (G1 Evacuation Pause) 80M->4M(130M) 0.671ms [29.117s][info][gc ] GC(139) Pause Young (Normal) (G1 Evacuation Pause) 80M->4M(130M) 0.592ms [29.218s][info][gc ] GC(140) Pause Young (Normal) (G1 Evacuation Pause) 80M->4M(130M) 0.702ms [29.322s][info][gc ] GC(141) Pause Young (Normal) (G1 Evacuation Pause) 80M->4M(130M) 0.657ms [29.423s][info][gc ] GC(142) Pause Young (Normal) (G1 Evacuation Pause) 80M->4M(130M) 0.622ms [29.528s][info][gc ] GC(143) Pause Young (Normal) (G1 Evacuation Pause) 80M->4M(130M) 0.654ms [29.632s][info][gc ] GC(144) Pause Young (Normal) (G1 Evacuation Pause) 80M->4M(130M) 0.622ms [29.738s][info][gc ] GC(145) Pause Young (Normal) (G1 Evacuation Pause) 80M->4M(130M) 0.732ms [29.843s][info][gc ] GC(146) Pause Young (Normal) (G1 Evacuation Pause) 80M->4M(130M) 0.647ms [1752668317008ms] ################# benchmark after C/R finish #################
W/o the change + -XX:MaxHeapFreeRatio=100 The heap is shrunk from 252MB to 10MB now but this is not enough to stop mixed GCs from occurring. [1752668979182ms] ################# benchmark before C/R start ################# [26.943s][info][gc] GC(134) Pause Young (Normal) (G1 Evacuation Pause) 152M->4M(252M) 0.693ms [27.144s][info][gc] GC(135) Pause Young (Normal) (G1 Evacuation Pause) 152M->4M(252M) 0.640ms [27.346s][info][gc] GC(136) Pause Young (Normal) (G1 Evacuation Pause) 152M->4M(252M) 0.677ms [27.547s][info][gc] GC(137) Pause Young (Normal) (G1 Evacuation Pause) 152M->4M(252M) 0.663ms [27.746s][info][gc] GC(138) Pause Young (Normal) (G1 Evacuation Pause) 152M->4M(252M) 0.627ms [1752668980284ms] ################# benchmark before C/R finish ################# 2025.07.16 14:29:40.475 INFO Starting checkpoint 2025.07.16 14:29:40.478 INFO [0x2bde2f6b] @default socket closed. [28.121s][info][gc] GC(139) Pause Full (System.gc()) 117M->3M(252M) 7.355ms [28.133s][info][gc] GC(140) Pause Full (System.gc()) 4M->3M(252M) 4.566ms [28.146s][info][gc] GC(141) Pause Full (FullGCAlot) 5M->3M(10M) 4.140ms [28.158s][info][crac] Checkpoint ... [28.570s][info][gc ] GC(142) Pause Young (Concurrent Start) (G1 Evacuation Pause) 3M->3M(10M) 4.823ms [28.570s][info][gc ] GC(143) Concurrent Mark Cycle [28.581s][info][gc ] GC(143) Pause Remark 3M->3M(18M) 2.299ms [28.582s][info][gc ] GC(143) Pause Cleanup 3M->3M(18M) 0.008ms [28.583s][info][gc ] GC(143) Concurrent Mark Cycle 12.906ms 2025.07.16 14:29:40.952 INFO [0x6f7e84d6] http://0.0.0.0:8080 bound for socket '@default' 2025.07.16 14:29:40.953 INFO Restored all channels in 1 milliseconds. 103 milliseconds since JVM snapshot restore. Java 25-internal-adhoc.timpushkin.crac [1752668980986ms] ################# benchmark after C/R start ################# [28.624s][info][gc ] GC(144) Pause Young (Prepare Mixed) (G1 Evacuation Pause) 5M->4M(18M) 0.755ms [28.629s][info][gc ] GC(145) Pause Young (Mixed) (G1 Evacuation Pause) 8M->4M(20M) 0.669ms [28.639s][info][gc ] GC(146) Pause Young (Mixed) (G1 Evacuation Pause) 10M->4M(20M) 2.089ms [28.653s][info][gc ] GC(147) Pause Young (Normal) (G1 Evacuation Pause) 14M->4M(136M) 0.739ms [28.758s][info][gc ] GC(148) Pause Young (Normal) (G1 Evacuation Pause) 82M->4M(136M) 0.600ms [28.866s][info][gc ] GC(149) Pause Young (Normal) (G1 Evacuation Pause) 82M->4M(136M) 0.676ms [28.968s][info][gc ] GC(150) Pause Young (Normal) (G1 Evacuation Pause) 82M->4M(136M) 0.621ms [29.072s][info][gc ] GC(151) Pause Young (Normal) (G1 Evacuation Pause) 82M->4M(136M) 0.689ms [29.177s][info][gc ] GC(152) Pause Young (Normal) (G1 Evacuation Pause) 82M->4M(136M) 0.648ms [29.282s][info][gc ] GC(153) Pause Young (Normal) (G1 Evacuation Pause) 82M->4M(136M) 0.635ms [29.388s][info][gc ] GC(154) Pause Young (Normal) (G1 Evacuation Pause) 82M->4M(136M) 0.608ms [29.494s][info][gc ] GC(155) Pause Young (Normal) (G1 Evacuation Pause) 82M->4M(136M) 0.596ms [29.601s][info][gc ] GC(156) Pause Young (Normal) (G1 Evacuation Pause) 82M->4M(136M) 0.614ms [29.707s][info][gc ] GC(157) Pause Young (Normal) (G1 Evacuation Pause) 82M->4M(136M) 0.633ms [1752668982088ms] ################# benchmark after C/R finish #################
W/ the change The heap is shrunk from 252MB to 14MB, there are no mixed GCs or preparations for them. [1752668544274ms] ################# wrk start ################# [27.010s][info][gc] GC(121) Pause Young (Normal) (G1 Evacuation Pause) 152M->4M(252M) 0.671ms [27.228s][info][gc] GC(122) Pause Young (Normal) (G1 Evacuation Pause) 152M->4M(252M) 0.684ms [27.451s][info][gc] GC(123) Pause Young (Normal) (G1 Evacuation Pause) 152M->4M(252M) 0.636ms [27.672s][info][gc] GC(124) Pause Young (Normal) (G1 Evacuation Pause) 152M->4M(252M) 0.656ms [27.893s][info][gc] GC(125) Pause Young (Normal) (G1 Evacuation Pause) 152M->4M(252M) 0.665ms [1752668545377ms] ################# wrk finish ################# 2025.07.16 14:22:25.567 INFO Starting checkpoint 2025.07.16 14:22:25.572 INFO [0x341b3650] @default socket closed. [28.221s][info][gc] GC(126) Pause Full (System.gc()) 89M->3M(34M) 7.894ms [28.242s][info][gc] GC(127) Pause Full (System.gc()) 4M->3M(14M) 9.701ms [28.262s][info][gc] GC(128) Pause Full (FullGCAlot) 4M->3M(14M) 7.277ms [28.265s][info][crac] Checkpoint ... 2025.07.16 14:22:26.200 INFO [0x0334b7cb] http://0.0.0.0:8080 bound for socket '@default' 2025.07.16 14:22:26.202 INFO Restored all channels in 3 milliseconds. 93 milliseconds since JVM snapshot restore. Java 25-internal-adhoc.timpushkin.crac [1752668546247ms] ################# wrk start ################# [28.902s][info][gc ] GC(129) Pause Young (Normal) (G1 Evacuation Pause) 11M->4M(14M) 1.228ms [28.915s][info][gc ] GC(130) Pause Young (Normal) (G1 Evacuation Pause) 10M->4M(14M) 0.535ms [28.923s][info][gc ] GC(131) Pause Young (Normal) (G1 Evacuation Pause) 10M->4M(14M) 0.579ms [28.932s][info][gc ] GC(132) Pause Young (Normal) (G1 Evacuation Pause) 10M->4M(14M) 0.553ms [28.940s][info][gc ] GC(133) Pause Young (Normal) (G1 Evacuation Pause) 10M->4M(132M) 0.719ms [29.042s][info][gc ] GC(134) Pause Young (Normal) (G1 Evacuation Pause) 80M->4M(132M) 0.669ms [29.146s][info][gc ] GC(135) Pause Young (Normal) (G1 Evacuation Pause) 80M->4M(132M) 0.627ms [29.252s][info][gc ] GC(136) Pause Young (Normal) (G1 Evacuation Pause) 80M->4M(132M) 0.629ms [29.357s][info][gc ] GC(137) Pause Young (Normal) (G1 Evacuation Pause) 80M->4M(132M) 0.675ms [29.460s][info][gc ] GC(138) Pause Young (Normal) (G1 Evacuation Pause) 80M->4M(132M) 0.656ms [29.562s][info][gc ] GC(139) Pause Young (Normal) (G1 Evacuation Pause) 80M->4M(132M) 0.615ms [29.666s][info][gc ] GC(140) Pause Young (Normal) (G1 Evacuation Pause) 80M->4M(132M) 0.618ms [29.772s][info][gc ] GC(141) Pause Young (Normal) (G1 Evacuation Pause) 80M->4M(132M) 0.663ms [29.876s][info][gc ] GC(142) Pause Young (Normal) (G1 Evacuation Pause) 80M->4M(132M) 0.626ms [29.982s][info][gc ] GC(143) Pause Young (Normal) (G1 Evacuation Pause) 80M->4M(132M) 0.643ms [1752668547350ms] ################# wrk finish #################
W/ the change + MaxHeapFreeRatio=100 The heap is not shrunk at all, the amount of GCs before/after C/R is roughly the same. [1752669161441ms] ################# wrk start ################# [26.872s][info][gc] GC(133) Pause Young (Normal) (G1 Evacuation Pause) 152M->4M(252M) 0.666ms [27.068s][info][gc] GC(134) Pause Young (Normal) (G1 Evacuation Pause) 152M->4M(252M) 0.648ms [27.270s][info][gc] GC(135) Pause Young (Normal) (G1 Evacuation Pause) 152M->4M(252M) 0.697ms [27.469s][info][gc] GC(136) Pause Young (Normal) (G1 Evacuation Pause) 152M->4M(252M) 0.687ms [27.666s][info][gc] GC(137) Pause Young (Normal) (G1 Evacuation Pause) 152M->4M(252M) 0.671ms [27.865s][info][gc] GC(138) Pause Young (Normal) (G1 Evacuation Pause) 152M->4M(252M) 0.606ms [1752669162544ms] ################# wrk finish ################# 2025.07.16 14:32:42.733 INFO Starting checkpoint 2025.07.16 14:32:42.736 INFO [0x2bde2f6b] @default socket closed. [28.113s][info][gc] GC(139) Pause Full (System.gc()) 40M->3M(252M) 8.054ms [28.125s][info][gc] GC(140) Pause Full (System.gc()) 4M->3M(252M) 4.707ms [28.146s][info][gc] GC(141) Pause Full (FullGCAlot) 5M->3M(252M) 13.005ms [28.148s][info][crac] Checkpoint ... 2025.07.16 14:32:43.336 INFO [0x0c20af4b] http://0.0.0.0:8080 bound for socket '@default' 2025.07.16 14:32:43.338 INFO Restored all channels in 3 milliseconds. 84 milliseconds since JVM snapshot restore. Java 25-internal-adhoc.timpushkin.crac [1752669163387ms] ################# wrk start ################# [28.966s][info][gc ] GC(142) Pause Young (Normal) (G1 Evacuation Pause) 153M->4M(252M) 1.357ms [29.170s][info][gc ] GC(143) Pause Young (Normal) (G1 Evacuation Pause) 152M->3M(252M) 0.711ms [29.372s][info][gc ] GC(144) Pause Young (Normal) (G1 Evacuation Pause) 151M->3M(252M) 0.699ms [29.573s][info][gc ] GC(145) Pause Young (Normal) (G1 Evacuation Pause) 151M->3M(252M) 0.700ms [29.774s][info][gc ] GC(146) Pause Young (Normal) (G1 Evacuation Pause) 151M->4M(252M) 0.648ms [1752669164490ms] ################# wrk finish #################
------------- Commit messages: - Cleanup memory instead of uncommitting it on G1 Changes: https://git.openjdk.org/crac/pull/243/files Webrev: https://webrevs.openjdk.org/?repo=crac&pr=243&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8362418 Stats: 57 lines in 10 files changed: 28 ins; 24 del; 5 mod Patch: https://git.openjdk.org/crac/pull/243.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/243/head:pull/243 PR: https://git.openjdk.org/crac/pull/243 From dcherepanov at openjdk.org Wed Jul 16 18:18:08 2025 From: dcherepanov at openjdk.org (Dmitry Cherepanov) Date: Wed, 16 Jul 2025 18:18:08 GMT Subject: [crac] RFR: Merge jdk:jdk-25+22 Message-ID: <-n74iFcjrVTdpjcxxri0wOzVLCyPrbN6kfQlsqgnRyI=.4960fb5c-65c1-45f0-8581-7d26196ac83e@github.com> Merge with jdk-25+22 Attaching output of `--diff-merges=remerge`
jdk-25+20 commit 28128cb4e515074ced2dfd4cd371bebe4cdc4dbc Merge: 698225b6594 953eef4f113 Author: Dmitry Cherepanov Date: Tue Jul 15 11:33:36 2025 +0400 Merge with jdk-25+20 diff --git a/src/hotspot/cpu/x86/globals_x86.hpp b/src/hotspot/cpu/x86/globals_x86.hpp remerge CONFLICT (content): Merge conflict in src/hotspot/cpu/x86/globals_x86.hpp index 2d380144da1..103fde55fb3 100644 --- a/src/hotspot/cpu/x86/globals_x86.hpp +++ b/src/hotspot/cpu/x86/globals_x86.hpp @@ -192,7 +192,6 @@ define_pd_global(intx, InitArrayShortSize, 8*BytesPerLong); "Turn off JVM mitigations related to Intel micro code " \ "mitigations for the Intel JCC erratum") \ \ -<<<<<<< 698225b6594 (Merge jdk:jdk-25+19) product(ccstr, CPUFeatures, nullptr, "CPU feature set, " \ "use -XX:CPUFeatures=0xnumber with -XX:CRaCCheckpointTo when you " \ "get an error during -XX:CRaCRestoreFrom on a different machine; " \ @@ -205,18 +204,16 @@ define_pd_global(intx, InitArrayShortSize, 8*BytesPerLong); \ product(bool, IgnoreCPUFeatures, false, RESTORE_SETTABLE | EXPERIMENTAL, \ "Do not refuse to run after -XX:CRaCRestoreFrom finds out some " \ - "CPU features are missing") - -======= + "CPU features are missing") \ + \ product(int, X86ICacheSync, -1, DIAGNOSTIC, \ "Select the X86 ICache sync mechanism: -1 = auto-select; " \ "0 = none (dangerous); 1 = CLFLUSH loop; 2 = CLFLUSHOPT loop; "\ "3 = CLWB loop; 4 = single CPUID; 5 = single SERIALIZE. " \ "Explicitly selected mechanism will fail at startup if " \ "hardware does not support it.") \ - range(-1, 5) \ - \ ->>>>>>> 953eef4f113 (8347337: ZGC: String dedups short-lived strings) + range(-1, 5) + // end of ARCH_FLAGS #endif // CPU_X86_GLOBALS_X86_HPP
Resolved conflicts with [JDK-8353558](https://bugs.openjdk.org/browse/JDK-8353558)
jdk-25+21 commit e1eb43d5964652ba568752f8e743624148c86da2 Merge: 28128cb4e51 e2ae50d877b Author: Dmitry Cherepanov Date: Tue Jul 15 12:09:36 2025 +0400 Merge with jdk-25+21 diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp b/src/hotspot/cpu/x86/vm_version_x86.cpp remerge CONFLICT (content): Merge conflict in src/hotspot/cpu/x86/vm_version_x86.cpp index d701b560b3c..df0a56956e8 100644 --- a/src/hotspot/cpu/x86/vm_version_x86.cpp +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp @@ -1296,16 +1296,12 @@ void VM_Version::get_processor_features_hardware() { _supports_atomic_getset8 = true; _supports_atomic_getadd8 = true; -<<<<<<< 28128cb4e51 (Merge with jdk-25+20) if (ShowCPUFeatures) { tty->print_cr("This machine's CPU features are: -XX:CPUFeatures=" UINT64_FORMAT_X "," UINT64_FORMAT_X, _features, _glibc_features); } } void VM_Version::get_processor_features_hotspot() { -#ifdef _LP64 -======= ->>>>>>> e2ae50d877b (8355569: Some nsk/jdi tests can glean the "main" thread by using the ClassPrepareEvent for the debuggee main class) // OS should support SSE for x64 and hardware should support at least SSE2. if (!VM_Version::supports_sse2()) { if (!FLAG_IS_DEFAULT(CPUFeatures)) @@ -1529,13 +1525,9 @@ void VM_Version::get_processor_features_hotspot() { "(%u cores per cpu, %u threads per core) family %d model %d stepping %d microcode 0x%x", cores_per_cpu(), threads_per_core(), cpu_family(), _model, _stepping, os::cpu_microcode_revision()); -<<<<<<< 28128cb4e51 (Merge with jdk-25+20) - assert(res > 0, "not enough temporary space allocated"); - insert_features_names(buf + res, sizeof(buf) - res); -======= + assert(cpu_info_size > 0, "not enough temporary space allocated"); - insert_features_names(buf + cpu_info_size, sizeof(buf) - cpu_info_size, _features_names); ->>>>>>> e2ae50d877b (8355569: Some nsk/jdi tests can glean the "main" thread by using the ClassPrepareEvent for the debuggee main class) + insert_features_names(buf + cpu_info_size, sizeof(buf) - cpu_info_size); _cpu_info_string = os::strdup(buf); @@ -2624,8 +2616,7 @@ void VM_Version::initialize() { g.generate_detect_virt()); clear_apx_test_state_stub = CAST_TO_FN_PTR(clear_apx_test_state_t, g.clear_apx_test_state()); -<<<<<<< 28128cb4e51 (Merge with jdk-25+20) -#endif + assert( _features == 0, "_features should be zero at startup"); assert(_glibc_features == 0, "_glibc_features should be zero at startup"); get_processor_features_hardware(); @@ -2667,9 +2658,6 @@ void VM_Version::initialize() { #endif get_processor_features_hotspot(); -======= - get_processor_features(); ->>>>>>> e2ae50d877b (8355569: Some nsk/jdi tests can glean the "main" thread by using the ClassPrepareEvent for the debuggee main class) Assembler::precompute_instructions(); diff --git a/src/hotspot/os/linux/os_linux.cpp b/src/hotspot/os/linux/os_linux.cpp remerge CONFLICT (content): Merge conflict in src/hotspot/os/linux/os_linux.cpp index 1c43eef8fb3..8203b17ae72 100644 --- a/src/hotspot/os/linux/os_linux.cpp +++ b/src/hotspot/os/linux/os_linux.cpp @@ -214,13 +214,10 @@ typedef int (*malloc_info_func_t)(int options, FILE *stream); static malloc_info_func_t g_malloc_info = nullptr; #endif // __GLIBC__ -<<<<<<< 28128cb4e51 (Merge with jdk-25+20) static int cached_pid = 0; static int clock_tics_per_sec = 100; -======= ->>>>>>> e2ae50d877b (8355569: Some nsk/jdi tests can glean the "main" thread by using the ClassPrepareEvent for the debuggee main class) // If the VM might have been created on the primordial thread, we need to resolve the // primordial thread stack bounds and check if the current thread might be the // primordial thread in places. If we know that the primordial thread is never used, @@ -4399,12 +4396,9 @@ static void check_pax(void) { // this is called _before_ most of the global arguments have been parsed void os::init(void) { char dummy; // used to get a guess on initial stack address -<<<<<<< 28128cb4e51 (Merge with jdk-25+20) cached_pid = current_process_id(); clock_tics_per_sec = checked_cast(sysconf(_SC_CLK_TCK)); -======= ->>>>>>> e2ae50d877b (8355569: Some nsk/jdi tests can glean the "main" thread by using the ClassPrepareEvent for the debuggee main class) int sys_pg_size = checked_cast(sysconf(_SC_PAGESIZE)); if (sys_pg_size < 0) { fatal("os_linux.cpp: os::init: sysconf failed (%s)", diff --git a/src/hotspot/os/posix/signals_posix.cpp b/src/hotspot/os/posix/signals_posix.cpp remerge CONFLICT (content): Merge conflict in src/hotspot/os/posix/signals_posix.cpp index 931c28c23a4..a0492af3918 100644 --- a/src/hotspot/os/posix/signals_posix.cpp +++ b/src/hotspot/os/posix/signals_posix.cpp @@ -147,13 +147,8 @@ class SavedSignalHandlers { }; -<<<<<<< 28128cb4e51 (Merge with jdk-25+20) -debug_only(static bool signal_sets_initialized = false); -static sigset_t unblocked_sigs, blocked_sigs, vm_sigs, preinstalled_sigs; -======= DEBUG_ONLY(static bool signal_sets_initialized = false); -static sigset_t unblocked_sigs, vm_sigs, preinstalled_sigs; ->>>>>>> e2ae50d877b (8355569: Some nsk/jdi tests can glean the "main" thread by using the ClassPrepareEvent for the debuggee main class) +static sigset_t unblocked_sigs, blocked_sigs, vm_sigs, preinstalled_sigs; // Our own signal handlers should never ever get replaced by a third party one. // To check that, and to aid with diagnostics, store a copy of the handler setup @@ -1552,7 +1547,6 @@ static void signal_sets_init() { if (!ReduceSignalUsage) { sigaddset(&vm_sigs, BREAK_SIGNAL); } -<<<<<<< 28128cb4e51 (Merge with jdk-25+20) sigemptyset(&blocked_sigs); // RESTORE_SIGNAL is used only on Linux, other platform don't send this @@ -1568,10 +1562,7 @@ static void signal_sets_init() { } #endif - debug_only(signal_sets_initialized = true); -======= DEBUG_ONLY(signal_sets_initialized = true); ->>>>>>> e2ae50d877b (8355569: Some nsk/jdi tests can glean the "main" thread by using the ClassPrepareEvent for the debuggee main class) } // These are signals that are unblocked while a thread is running Java. diff --git a/src/hotspot/share/gc/z/zPageAllocator.cpp b/src/hotspot/share/gc/z/zPageAllocator.cpp remerge CONFLICT (content): Merge conflict in src/hotspot/share/gc/z/zPageAllocator.cpp index f109c8b91a9..37e271b43d9 100644 --- a/src/hotspot/share/gc/z/zPageAllocator.cpp +++ b/src/hotspot/share/gc/z/zPageAllocator.cpp @@ -2467,46 +2467,6 @@ void ZPageAllocator::print_cache_extended_on(outputStream* st) const { _lock.unlock(); } -<<<<<<< 28128cb4e51 (Merge with jdk-25+20) - -void ZPageAllocator::print_on_error(outputStream* st) const { - const bool locked = try_lock_on_error(&_lock); - - if (!locked) { - st->print_cr(""); - } - - // Print information even though we have not successfully taken the lock. - // This is thread-safe, but may produce inconsistent results. - print_on_inner(st); - - if (locked) { - _lock.unlock(); - } -} - -void ZPageAllocator::print_on_inner(outputStream* st) const { - // Print total usage - st->print("ZHeap"); - st->fill_to(17); - st->print_cr("used %zuM, capacity %zuM, max capacity %zuM", - used() / M, capacity() / M, max_capacity() / M); - - // Print per-partition - - streamIndentor indentor(st, 1); - - if (_partitions.count() == 1) { - // The summary printing is redundant if we only have one partition - _partitions.get(0).print_cache_on(st); - return; - } - - ZPartitionConstIterator iter = partition_iterator(); - for (const ZPartition* partition; iter.next(&partition);) { - partition->print_on(st); - } -} void ZPageAllocator::uncommit_unused_memory() { uint64_t timeout; @@ -2526,5 +2486,3 @@ void ZPageAllocator::uncommit_unused_memory() { event.commit(uncommitted); } } -======= ->>>>>>> e2ae50d877b (8355569: Some nsk/jdi tests can glean the "main" thread by using the ClassPrepareEvent for the debuggee main class) diff --git a/src/hotspot/share/gc/z/zPageAllocator.hpp b/src/hotspot/share/gc/z/zPageAllocator.hpp remerge CONFLICT (content): Merge conflict in src/hotspot/share/gc/z/zPageAllocator.hpp index 1dc0ba22f0e..02da4daae2d 100644 --- a/src/hotspot/share/gc/z/zPageAllocator.hpp +++ b/src/hotspot/share/gc/z/zPageAllocator.hpp @@ -283,18 +283,12 @@ class ZPageAllocator { void threads_do(ThreadClosure* tc) const; -<<<<<<< 28128cb4e51 (Merge with jdk-25+20) - void print_on(outputStream* st) const; - void print_extended_on_error(outputStream* st) const; - void print_on_error(outputStream* st) const; - void uncommit_unused_memory(); -======= + void print_usage_on(outputStream* st) const; void print_total_usage_on(outputStream* st) const; void print_partition_usage_on(outputStream* st) const; void print_cache_extended_on(outputStream* st) const; ->>>>>>> e2ae50d877b (8355569: Some nsk/jdi tests can glean the "main" thread by using the ClassPrepareEvent for the debuggee main class) }; class ZPageAllocatorStats { diff --git a/src/hotspot/share/runtime/abstract_vm_version.hpp b/src/hotspot/share/runtime/abstract_vm_version.hpp remerge CONFLICT (content): Merge conflict in src/hotspot/share/runtime/abstract_vm_version.hpp index 9e4d8f7e2fd..addd7b4e314 100644 --- a/src/hotspot/share/runtime/abstract_vm_version.hpp +++ b/src/hotspot/share/runtime/abstract_vm_version.hpp @@ -131,14 +131,12 @@ class Abstract_VM_Version: AllStatic { static uint64_t features() { return _features; } static const char* features_string() { return _features_string; } -<<<<<<< 28128cb4e51 (Merge with jdk-25+20) -======= + static const char* cpu_info_string() { return _cpu_info_string; } static void insert_features_names(char* buf, size_t buflen, const char* features_names[]); static const char* extract_features_string(const char* cpu_info_string, size_t cpu_info_string_len, size_t features_offset); ->>>>>>> e2ae50d877b (8355569: Some nsk/jdi tests can glean the "main" thread by using the ClassPrepareEvent for the debuggee main class) static VirtualizationType get_detected_virtualization() { return _detected_virtualization;
Resolved conflicts with [JDK-8353786](https://bugs.openjdk.org/browse/JDK-8353786), [JDK-8354362](https://bugs.openjdk.org/browse/JDK-8354362) and [JDK-8355473](https://bugs.openjdk.org/browse/JDK-8355473)
jdk-25+22 commit 99eb6eacea6888e7da5b3de485586d50c6301376 (HEAD -> merge-jdk, dmitry-crac/merge-jdk) Merge: e1eb43d5964 52a5583d691 Author: Dmitry Cherepanov Date: Tue Jul 15 22:13:09 2025 +0400 Merge with jdk-25+22 diff --git a/src/java.base/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java b/src/java.base/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java remerge CONFLICT (content): Merge conflict in src/java.base/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java index 5404932c145..5865e75d35e 100644 --- a/src/java.base/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java +++ b/src/java.base/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java @@ -75,8 +75,7 @@ abstract class AsynchronousServerSocketChannelImpl AsynchronousServerSocketChannelImpl(AsynchronousChannelGroupImpl group) { super(group.provider()); -<<<<<<< e1eb43d5964 (Merge with jdk-25+21) - this.fd = Net.serverSocket(true); + this.fd = Net.serverSocket(); this.resource = new JDKSocketResource(this) { @Override protected FileDescriptor getFD() { @@ -105,7 +104,7 @@ protected void closeBeforeCheckpoint() throws IOException { @Override protected void reopenAfterRestore() throws IOException { - FileDescriptor newfd = Net.serverSocket(true); + FileDescriptor newfd = Net.serverSocket(); IOUtil.setfdVal(fd, IOUtil.fdVal(newfd)); reopen(); synchronized (stateLock) { @@ -117,9 +116,6 @@ protected void reopenAfterRestore() throws IOException { } } }; -======= - this.fd = Net.serverSocket(); ->>>>>>> 52a5583d691 (8356154: Respecify java.net.Socket constructors that allow creating UDP sockets to throw IllegalArgumentException) } @Override diff --git a/src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java b/src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java remerge CONFLICT (content): Merge conflict in src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java index 4741b3e653b..db2fa94f209 100644 --- a/src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java +++ b/src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java @@ -462,8 +462,8 @@ public void reopenAfterRestore() throws IOException { } synchronized (stateLock) { FileDescriptor fd; - fd = Net.serverSocket(true); - Runnable closer = closerFor(fd, true); + fd = Net.serverSocket(); + Runnable closer = closerFor(fd); IOUtil.setfdVal(NioSocketImpl.this.fd, IOUtil.fdVal(fd)); NioSocketImpl.this.cleaner = CleanerFactory.cleaner().register(NioSocketImpl.this, closer); state = ST_UNCONNECTED; @@ -1220,27 +1220,7 @@ protected void sendUrgentData(int data) throws IOException { /** * Returns an action to close the given file descriptor. */ -<<<<<<< e1eb43d5964 (Merge with jdk-25+21) - private static Runnable closerFor0(FileDescriptor fd, boolean stream) { - if (stream) { - return () -> { - try { - nd.close(fd); - } catch (IOException ioe) { - throw new UncheckedIOException(ioe); - } - }; - } else { - return () -> { - try { - nd.close(fd); - } catch (IOException ioe) { - throw new UncheckedIOException(ioe); - } - }; - } -======= - private static Runnable closerFor(FileDescriptor fd) { + private static Runnable closerFor0(FileDescriptor fd) { return () -> { try { nd.close(fd); @@ -1248,10 +1228,9 @@ private static Runnable closerFor(FileDescriptor fd) { throw new UncheckedIOException(ioe); } }; ->>>>>>> 52a5583d691 (8356154: Respecify java.net.Socket constructors that allow creating UDP sockets to throw IllegalArgumentException) } - private static Runnable closerFor(FileDescriptor fd, boolean stream) { + private static Runnable closerFor(FileDescriptor fd) { // FIXME ensure FileDispatcherImpl's Resource is registered before the closer is used, // otherwise the closer during beforeCheckpoint may be the first one to access @@ -1262,7 +1241,7 @@ private static Runnable closerFor(FileDescriptor fd, boolean stream) { throw new RuntimeException(e); } - return closerFor0(fd, stream); + return closerFor0(fd); } /** diff --git a/src/java.base/share/classes/sun/nio/ch/ServerSocketChannelImpl.java b/src/java.base/share/classes/sun/nio/ch/ServerSocketChannelImpl.java index 27133138aaa..ceff0b1872d 100644 --- a/src/java.base/share/classes/sun/nio/ch/ServerSocketChannelImpl.java +++ b/src/java.base/share/classes/sun/nio/ch/ServerSocketChannelImpl.java @@ -772,7 +772,7 @@ protected void reopenAfterRestore() throws IOException { if (family == UNIX) { newFd = UnixDomainSockets.socket(); } else { - newFd = Net.serverSocket(family, true); + newFd = Net.serverSocket(family); } // We could avoid making fdVal non-final and dup2(...) to the original // value but that could accidentally conflict with another FD created
Resolved conflicts with [JDK-8356154](https://bugs.openjdk.org/browse/JDK-8356154) ------------- Commit messages: - Merge with jdk-25+22 - 8356154: Respecify java.net.Socket constructors that allow creating UDP sockets to throw IllegalArgumentException - 8356407: Part of class verification is skipped in AOT training run - 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer - 8244533: Configure should abort on missing short names in Windows - 8356126: Duplication handling and optimization of CaptureCallState - 8332934: Do loop with continue with subsequent switch leads to incorrect stack maps - 8354461: Update tests to disable streaming output for attach tools - 8351313: VM crashes when AOTMode/AOTCache/AOTConfiguration are empty - 8356318: Unexpected VerifyError in AOT training run - ... and 359 more: https://git.openjdk.org/crac/compare/698225b6...99eb6eac The webrevs contain the adjustments done while merging with regards to each parent branch: - crac: https://webrevs.openjdk.org/?repo=crac&pr=244&range=00.0 - jdk:jdk-25+22: https://webrevs.openjdk.org/?repo=crac&pr=244&range=00.1 Changes: https://git.openjdk.org/crac/pull/244/files Stats: 85715 lines in 2189 files changed: 63539 ins; 13639 del; 8537 mod Patch: https://git.openjdk.org/crac/pull/244.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/244/head:pull/244 PR: https://git.openjdk.org/crac/pull/244 From tpushkin at openjdk.org Thu Jul 17 09:23:23 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Thu, 17 Jul 2025 09:23:23 GMT Subject: [crac] RFR: Merge jdk:jdk-25+22 In-Reply-To: <-n74iFcjrVTdpjcxxri0wOzVLCyPrbN6kfQlsqgnRyI=.4960fb5c-65c1-45f0-8581-7d26196ac83e@github.com> References: <-n74iFcjrVTdpjcxxri0wOzVLCyPrbN6kfQlsqgnRyI=.4960fb5c-65c1-45f0-8581-7d26196ac83e@github.com> Message-ID: On Wed, 16 Jul 2025 18:11:43 GMT, Dmitry Cherepanov wrote: > Merge with jdk-25+22 > > Attaching output of `--diff-merges=remerge` > >
> > jdk-25+20 > > > commit 28128cb4e515074ced2dfd4cd371bebe4cdc4dbc > Merge: 698225b6594 953eef4f113 > Author: Dmitry Cherepanov > Date: Tue Jul 15 11:33:36 2025 +0400 > > Merge with jdk-25+20 > > diff --git a/src/hotspot/cpu/x86/globals_x86.hpp b/src/hotspot/cpu/x86/globals_x86.hpp > remerge CONFLICT (content): Merge conflict in src/hotspot/cpu/x86/globals_x86.hpp > index 2d380144da1..103fde55fb3 100644 > --- a/src/hotspot/cpu/x86/globals_x86.hpp > +++ b/src/hotspot/cpu/x86/globals_x86.hpp > @@ -192,7 +192,6 @@ define_pd_global(intx, InitArrayShortSize, 8*BytesPerLong); > "Turn off JVM mitigations related to Intel micro code " \ > "mitigations for the Intel JCC erratum") \ > \ > -<<<<<<< 698225b6594 (Merge jdk:jdk-25+19) > product(ccstr, CPUFeatures, nullptr, "CPU feature set, " \ > "use -XX:CPUFeatures=0xnumber with -XX:CRaCCheckpointTo when you " \ > "get an error during -XX:CRaCRestoreFrom on a different machine; " \ > @@ -205,18 +204,16 @@ define_pd_global(intx, InitArrayShortSize, 8*BytesPerLong); > \ > product(bool, IgnoreCPUFeatures, false, RESTORE_SETTABLE | EXPERIMENTAL, \ > "Do not refuse to run after -XX:CRaCRestoreFrom finds out some " \ > - "CPU features are missing") > - > -======= > + "CPU features are missing") \ > + \ > product(int, X86ICacheSync, -1, DIAGNOSTIC, \ > "Select the X86 ICache sync mechanism: -1 = auto-select; " \ > "0 = none (dangerous); 1 = CLFLUSH loop; 2 = CLFLUSHOPT loop; "\ > "3 = CLWB loop; 4 = single CPUID; 5 = single SERIALIZE. " \ > "Explicitly selected mechanism will fail at startup if " \ > "hardware does not support it.") \ > - range(-1, 5) \ > - \ > ->>>>>>> 953eef4f113 (8347337: ZGC: String dedups short-lived strings) > + range(-1, 5) > + > // end of ARCH_FLAGS > > #endif // CPU_X86_GLOBALS_X86... src/hotspot/cpu/x86/globals_x86.hpp line 205: > 203: "Explicitly selected mechanism will fail at startup if " \ > 204: "hardware does not support it.") \ > 205: range(-1, 5) In the conflict resolution: - range(-1, 5) \ - \ ->>>>>>> 953eef4f113 (8347337: ZGC: String dedups short-lived strings) + range(-1, 5) + Would be better to leave the two ``, otherwise there will be conflicts later. src/hotspot/os/linux/os_linux.cpp line 5159: > 5157: if (count != 13) return -1; > 5158: if (user_sys_cpu_time) { > 5159: return ((jlong)sys_time + (jlong)user_time) * (1000000000 / clock_tics_per_sec); Cannot comment on a proper line but `clock_tics_per_sec` has been removed completely by https://bugs.openjdk.org/browse/JDK-8354811 while in the merge its definition and initialization has been preserved. Can't we remove it completely too? src/hotspot/share/runtime/abstract_vm_version.hpp line 134: > 132: static uint64_t features() { return _features; } > 133: static const char* features_string() { return _features_string; } > 134: IIUC this newline was added during a conflict resolution but there's no such new line in the original changes. Although it will be added in JDK 15+23 anyway... Not functionally important, just truing to minimize the difference. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/244#discussion_r2212685734 PR Review Comment: https://git.openjdk.org/crac/pull/244#discussion_r2212720781 PR Review Comment: https://git.openjdk.org/crac/pull/244#discussion_r2212790821 From dcherepanov at openjdk.org Thu Jul 17 10:09:35 2025 From: dcherepanov at openjdk.org (Dmitry Cherepanov) Date: Thu, 17 Jul 2025 10:09:35 GMT Subject: [crac] RFR: Merge jdk:jdk-25+22 [v2] In-Reply-To: <-n74iFcjrVTdpjcxxri0wOzVLCyPrbN6kfQlsqgnRyI=.4960fb5c-65c1-45f0-8581-7d26196ac83e@github.com> References: <-n74iFcjrVTdpjcxxri0wOzVLCyPrbN6kfQlsqgnRyI=.4960fb5c-65c1-45f0-8581-7d26196ac83e@github.com> Message-ID: > Merge with jdk-25+22 > > Attaching output of `--diff-merges=remerge` > >
> > jdk-25+20 > > > commit 28128cb4e515074ced2dfd4cd371bebe4cdc4dbc > Merge: 698225b6594 953eef4f113 > Author: Dmitry Cherepanov > Date: Tue Jul 15 11:33:36 2025 +0400 > > Merge with jdk-25+20 > > diff --git a/src/hotspot/cpu/x86/globals_x86.hpp b/src/hotspot/cpu/x86/globals_x86.hpp > remerge CONFLICT (content): Merge conflict in src/hotspot/cpu/x86/globals_x86.hpp > index 2d380144da1..103fde55fb3 100644 > --- a/src/hotspot/cpu/x86/globals_x86.hpp > +++ b/src/hotspot/cpu/x86/globals_x86.hpp > @@ -192,7 +192,6 @@ define_pd_global(intx, InitArrayShortSize, 8*BytesPerLong); > "Turn off JVM mitigations related to Intel micro code " \ > "mitigations for the Intel JCC erratum") \ > \ > -<<<<<<< 698225b6594 (Merge jdk:jdk-25+19) > product(ccstr, CPUFeatures, nullptr, "CPU feature set, " \ > "use -XX:CPUFeatures=0xnumber with -XX:CRaCCheckpointTo when you " \ > "get an error during -XX:CRaCRestoreFrom on a different machine; " \ > @@ -205,18 +204,16 @@ define_pd_global(intx, InitArrayShortSize, 8*BytesPerLong); > \ > product(bool, IgnoreCPUFeatures, false, RESTORE_SETTABLE | EXPERIMENTAL, \ > "Do not refuse to run after -XX:CRaCRestoreFrom finds out some " \ > - "CPU features are missing") > - > -======= > + "CPU features are missing") \ > + \ > product(int, X86ICacheSync, -1, DIAGNOSTIC, \ > "Select the X86 ICache sync mechanism: -1 = auto-select; " \ > "0 = none (dangerous); 1 = CLFLUSH loop; 2 = CLFLUSHOPT loop; "\ > "3 = CLWB loop; 4 = single CPUID; 5 = single SERIALIZE. " \ > "Explicitly selected mechanism will fail at startup if " \ > "hardware does not support it.") \ > - range(-1, 5) \ > - \ > ->>>>>>> 953eef4f113 (8347337: ZGC: String dedups short-lived strings) > + range(-1, 5) > + > // end of ARCH_FLAGS > > #endif // CPU_X86_GLOBALS_X86... Dmitry Cherepanov has updated the pull request incrementally with one additional commit since the last revision: cleanup ------------- Changes: - all: https://git.openjdk.org/crac/pull/244/files - new: https://git.openjdk.org/crac/pull/244/files/99eb6eac..31023e21 Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=244&range=01 - incr: https://webrevs.openjdk.org/?repo=crac&pr=244&range=00-01 Stats: 7 lines in 3 files changed: 0 ins; 5 del; 2 mod Patch: https://git.openjdk.org/crac/pull/244.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/244/head:pull/244 PR: https://git.openjdk.org/crac/pull/244 From tpushkin at openjdk.org Thu Jul 17 10:38:21 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Thu, 17 Jul 2025 10:38:21 GMT Subject: [crac] RFR: Merge jdk:jdk-25+22 [v2] In-Reply-To: References: <-n74iFcjrVTdpjcxxri0wOzVLCyPrbN6kfQlsqgnRyI=.4960fb5c-65c1-45f0-8581-7d26196ac83e@github.com> Message-ID: On Thu, 17 Jul 2025 10:09:35 GMT, Dmitry Cherepanov wrote: >> Merge with jdk-25+22 >> >> Attaching output of `--diff-merges=remerge` >> >>
>> >> jdk-25+20 >> >> >> commit 28128cb4e515074ced2dfd4cd371bebe4cdc4dbc >> Merge: 698225b6594 953eef4f113 >> Author: Dmitry Cherepanov >> Date: Tue Jul 15 11:33:36 2025 +0400 >> >> Merge with jdk-25+20 >> >> diff --git a/src/hotspot/cpu/x86/globals_x86.hpp b/src/hotspot/cpu/x86/globals_x86.hpp >> remerge CONFLICT (content): Merge conflict in src/hotspot/cpu/x86/globals_x86.hpp >> index 2d380144da1..103fde55fb3 100644 >> --- a/src/hotspot/cpu/x86/globals_x86.hpp >> +++ b/src/hotspot/cpu/x86/globals_x86.hpp >> @@ -192,7 +192,6 @@ define_pd_global(intx, InitArrayShortSize, 8*BytesPerLong); >> "Turn off JVM mitigations related to Intel micro code " \ >> "mitigations for the Intel JCC erratum") \ >> \ >> -<<<<<<< 698225b6594 (Merge jdk:jdk-25+19) >> product(ccstr, CPUFeatures, nullptr, "CPU feature set, " \ >> "use -XX:CPUFeatures=0xnumber with -XX:CRaCCheckpointTo when you " \ >> "get an error during -XX:CRaCRestoreFrom on a different machine; " \ >> @@ -205,18 +204,16 @@ define_pd_global(intx, InitArrayShortSize, 8*BytesPerLong); >> \ >> product(bool, IgnoreCPUFeatures, false, RESTORE_SETTABLE | EXPERIMENTAL, \ >> "Do not refuse to run after -XX:CRaCRestoreFrom finds out some " \ >> - "CPU features are missing") >> - >> -======= >> + "CPU features are missing") \ >> + \ >> product(int, X86ICacheSync, -1, DIAGNOSTIC, \ >> "Select the X86 ICache sync mechanism: -1 = auto-select; " \ >> "0 = none (dangerous); 1 = CLFLUSH loop; 2 = CLFLUSHOPT loop; "\ >> "3 = CLWB loop; 4 = single CPUID; 5 = single SERIALIZE. " \ >> "Explicitly selected mechanism will fail at startup if " \ >> "hardware does not support it.") \ >> - range(-1, 5) \ >> - \ >> ->>>>>>> 953eef4f113 (8347337: ZGC: String dedups short-live... > > Dmitry Cherepanov has updated the pull request incrementally with one additional commit since the last revision: > > cleanup Marked as reviewed by tpushkin (Committer). ------------- PR Review: https://git.openjdk.org/crac/pull/244#pullrequestreview-3028947980 From dcherepanov at openjdk.org Thu Jul 17 10:53:06 2025 From: dcherepanov at openjdk.org (Dmitry Cherepanov) Date: Thu, 17 Jul 2025 10:53:06 GMT Subject: [crac] RFR: Merge jdk:jdk-25+22 [v2] In-Reply-To: References: <-n74iFcjrVTdpjcxxri0wOzVLCyPrbN6kfQlsqgnRyI=.4960fb5c-65c1-45f0-8581-7d26196ac83e@github.com> Message-ID: On Thu, 17 Jul 2025 10:35:26 GMT, Timofei Pushkin wrote: >> Dmitry Cherepanov has updated the pull request incrementally with one additional commit since the last revision: >> >> cleanup > > Marked as reviewed by tpushkin (Committer). @TimPushkin Thank you. Fixed all three places. ------------- PR Comment: https://git.openjdk.org/crac/pull/244#issuecomment-3083577686 From duke at openjdk.org Thu Jul 17 10:53:06 2025 From: duke at openjdk.org (duke) Date: Thu, 17 Jul 2025 10:53:06 GMT Subject: [crac] RFR: Merge jdk:jdk-25+22 [v2] In-Reply-To: References: <-n74iFcjrVTdpjcxxri0wOzVLCyPrbN6kfQlsqgnRyI=.4960fb5c-65c1-45f0-8581-7d26196ac83e@github.com> Message-ID: On Thu, 17 Jul 2025 10:09:35 GMT, Dmitry Cherepanov wrote: >> Merge with jdk-25+22 >> >> Attaching output of `--diff-merges=remerge` >> >>
>> >> jdk-25+20 >> >> >> commit 28128cb4e515074ced2dfd4cd371bebe4cdc4dbc >> Merge: 698225b6594 953eef4f113 >> Author: Dmitry Cherepanov >> Date: Tue Jul 15 11:33:36 2025 +0400 >> >> Merge with jdk-25+20 >> >> diff --git a/src/hotspot/cpu/x86/globals_x86.hpp b/src/hotspot/cpu/x86/globals_x86.hpp >> remerge CONFLICT (content): Merge conflict in src/hotspot/cpu/x86/globals_x86.hpp >> index 2d380144da1..103fde55fb3 100644 >> --- a/src/hotspot/cpu/x86/globals_x86.hpp >> +++ b/src/hotspot/cpu/x86/globals_x86.hpp >> @@ -192,7 +192,6 @@ define_pd_global(intx, InitArrayShortSize, 8*BytesPerLong); >> "Turn off JVM mitigations related to Intel micro code " \ >> "mitigations for the Intel JCC erratum") \ >> \ >> -<<<<<<< 698225b6594 (Merge jdk:jdk-25+19) >> product(ccstr, CPUFeatures, nullptr, "CPU feature set, " \ >> "use -XX:CPUFeatures=0xnumber with -XX:CRaCCheckpointTo when you " \ >> "get an error during -XX:CRaCRestoreFrom on a different machine; " \ >> @@ -205,18 +204,16 @@ define_pd_global(intx, InitArrayShortSize, 8*BytesPerLong); >> \ >> product(bool, IgnoreCPUFeatures, false, RESTORE_SETTABLE | EXPERIMENTAL, \ >> "Do not refuse to run after -XX:CRaCRestoreFrom finds out some " \ >> - "CPU features are missing") >> - >> -======= >> + "CPU features are missing") \ >> + \ >> product(int, X86ICacheSync, -1, DIAGNOSTIC, \ >> "Select the X86 ICache sync mechanism: -1 = auto-select; " \ >> "0 = none (dangerous); 1 = CLFLUSH loop; 2 = CLFLUSHOPT loop; "\ >> "3 = CLWB loop; 4 = single CPUID; 5 = single SERIALIZE. " \ >> "Explicitly selected mechanism will fail at startup if " \ >> "hardware does not support it.") \ >> - range(-1, 5) \ >> - \ >> ->>>>>>> 953eef4f113 (8347337: ZGC: String dedups short-live... > > Dmitry Cherepanov has updated the pull request incrementally with one additional commit since the last revision: > > cleanup @dimitryc Your change (at version 31023e21e6af689f4e9ea7e74197a772a58a7e48) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/crac/pull/244#issuecomment-3083584021 From dcherepanov at openjdk.org Thu Jul 17 12:47:16 2025 From: dcherepanov at openjdk.org (Dmitry Cherepanov) Date: Thu, 17 Jul 2025 12:47:16 GMT Subject: [crac] Integrated: Merge jdk:jdk-25+22 In-Reply-To: <-n74iFcjrVTdpjcxxri0wOzVLCyPrbN6kfQlsqgnRyI=.4960fb5c-65c1-45f0-8581-7d26196ac83e@github.com> References: <-n74iFcjrVTdpjcxxri0wOzVLCyPrbN6kfQlsqgnRyI=.4960fb5c-65c1-45f0-8581-7d26196ac83e@github.com> Message-ID: On Wed, 16 Jul 2025 18:11:43 GMT, Dmitry Cherepanov wrote: > Merge with jdk-25+22 > > Attaching output of `--diff-merges=remerge` > >
> > jdk-25+20 > > > commit 28128cb4e515074ced2dfd4cd371bebe4cdc4dbc > Merge: 698225b6594 953eef4f113 > Author: Dmitry Cherepanov > Date: Tue Jul 15 11:33:36 2025 +0400 > > Merge with jdk-25+20 > > diff --git a/src/hotspot/cpu/x86/globals_x86.hpp b/src/hotspot/cpu/x86/globals_x86.hpp > remerge CONFLICT (content): Merge conflict in src/hotspot/cpu/x86/globals_x86.hpp > index 2d380144da1..103fde55fb3 100644 > --- a/src/hotspot/cpu/x86/globals_x86.hpp > +++ b/src/hotspot/cpu/x86/globals_x86.hpp > @@ -192,7 +192,6 @@ define_pd_global(intx, InitArrayShortSize, 8*BytesPerLong); > "Turn off JVM mitigations related to Intel micro code " \ > "mitigations for the Intel JCC erratum") \ > \ > -<<<<<<< 698225b6594 (Merge jdk:jdk-25+19) > product(ccstr, CPUFeatures, nullptr, "CPU feature set, " \ > "use -XX:CPUFeatures=0xnumber with -XX:CRaCCheckpointTo when you " \ > "get an error during -XX:CRaCRestoreFrom on a different machine; " \ > @@ -205,18 +204,16 @@ define_pd_global(intx, InitArrayShortSize, 8*BytesPerLong); > \ > product(bool, IgnoreCPUFeatures, false, RESTORE_SETTABLE | EXPERIMENTAL, \ > "Do not refuse to run after -XX:CRaCRestoreFrom finds out some " \ > - "CPU features are missing") > - > -======= > + "CPU features are missing") \ > + \ > product(int, X86ICacheSync, -1, DIAGNOSTIC, \ > "Select the X86 ICache sync mechanism: -1 = auto-select; " \ > "0 = none (dangerous); 1 = CLFLUSH loop; 2 = CLFLUSHOPT loop; "\ > "3 = CLWB loop; 4 = single CPUID; 5 = single SERIALIZE. " \ > "Explicitly selected mechanism will fail at startup if " \ > "hardware does not support it.") \ > - range(-1, 5) \ > - \ > ->>>>>>> 953eef4f113 (8347337: ZGC: String dedups short-lived strings) > + range(-1, 5) > + > // end of ARCH_FLAGS > > #endif // CPU_X86_GLOBALS_X86... This pull request has now been integrated. Changeset: 62d50fc0 Author: Dmitry Cherepanov Committer: Timofei Pushkin URL: https://git.openjdk.org/crac/commit/62d50fc03e9721c02b0ed9312b760c0ecb839c1e Stats: 85719 lines in 2189 files changed: 63538 ins; 13643 del; 8538 mod Merge jdk:jdk-25+22 Reviewed-by: tpushkin ------------- PR: https://git.openjdk.org/crac/pull/244 From jkratochvil at openjdk.org Thu Jul 17 14:39:52 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Thu, 17 Jul 2025 14:39:52 GMT Subject: [crac] RFR: Fix confusing but harmless typos Message-ID: The name `DECLARE_CPU_FEATURE_FLAG` is used in all other cases. In `vmStructs_jvmci.cpp` there was no matching `#define`. ------------- Commit messages: - Fix confusing but harmless typos Changes: https://git.openjdk.org/crac/pull/245/files Webrev: https://webrevs.openjdk.org/?repo=crac&pr=245&range=00 Stats: 4 lines in 2 files changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/crac/pull/245.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/245/head:pull/245 PR: https://git.openjdk.org/crac/pull/245 From jkratochvil at openjdk.org Thu Jul 17 14:39:52 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Thu, 17 Jul 2025 14:39:52 GMT Subject: [crac] RFR: Fix confusing but harmless typos In-Reply-To: References: Message-ID: On Thu, 17 Jul 2025 12:42:44 GMT, Jan Kratochvil wrote: > The name `DECLARE_CPU_FEATURE_FLAG` is used in all other cases. In `vmStructs_jvmci.cpp` there was no matching `#define`. Only MS-Windows are failing and that is an infrastructure problem: checking that Visual Studio variables have been correctly extracted... ok checking for cl... [not found] configure: error: Could not find a C compiler. ------------- PR Comment: https://git.openjdk.org/crac/pull/245#issuecomment-3084311349 From tpushkin at openjdk.org Thu Jul 17 14:45:15 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Thu, 17 Jul 2025 14:45:15 GMT Subject: [crac] RFR: Fix confusing but harmless typos In-Reply-To: References: Message-ID: On Thu, 17 Jul 2025 12:42:44 GMT, Jan Kratochvil wrote: > The name `DECLARE_CPU_FEATURE_FLAG` is used in all other cases. In `vmStructs_jvmci.cpp` there was no matching `#define`. Could you please create a JBS issue for this? I believe the current policy is to have a JBS issue for each change. Also IIUC this was introduced in the mainline, so will you also post it there to reduce the difference between CRaC and the mainline? These should probably be two separate JBS issues (for CRaC and for the mainline), but I'm not sure. ------------- PR Comment: https://git.openjdk.org/crac/pull/245#issuecomment-3084347923 From jkratochvil at openjdk.org Thu Jul 17 14:57:02 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Thu, 17 Jul 2025 14:57:02 GMT Subject: [crac] RFR: Fix confusing but harmless typos In-Reply-To: References: Message-ID: On Thu, 17 Jul 2025 12:42:44 GMT, Jan Kratochvil wrote: > The name `DECLARE_CPU_FEATURE_FLAG` is used in all other cases. In `vmStructs_jvmci.cpp` there was no matching `#define`. You are right it is in the mainline. So I will move it there, in the `crac` branch it will get fixed by an automatic merge. ------------- PR Comment: https://git.openjdk.org/crac/pull/245#issuecomment-3084389466 From jkratochvil at openjdk.org Thu Jul 17 14:57:03 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Thu, 17 Jul 2025 14:57:03 GMT Subject: [crac] Withdrawn: Fix confusing but harmless typos In-Reply-To: References: Message-ID: On Thu, 17 Jul 2025 12:42:44 GMT, Jan Kratochvil wrote: > The name `DECLARE_CPU_FEATURE_FLAG` is used in all other cases. In `vmStructs_jvmci.cpp` there was no matching `#define`. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/crac/pull/245 From rvansa at openjdk.org Fri Jul 18 08:21:23 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Fri, 18 Jul 2025 08:21:23 GMT Subject: [crac] RFR: 8362418: [CRaC] Leave unused G1 heap regions committed for C/R In-Reply-To: <-TiVEuvzgvvuO-I_pKCmNpw4WGsFmbwKqCv29Qyj2ks=.8de100bf-c7f8-4d69-a8ec-1f87fcddbe9f@github.com> References: <-TiVEuvzgvvuO-I_pKCmNpw4WGsFmbwKqCv29Qyj2ks=.8de100bf-c7f8-4d69-a8ec-1f87fcddbe9f@github.com> Message-ID: On Wed, 16 Jul 2025 13:56:07 GMT, Timofei Pushkin wrote: > See the JBS issue for the problem statement and the suggested approach to fix it. > > This PR: > 1. Implements the approach by expanding G1 heap back after shrinking and uncommitting it: shrink+uncommit makes memory in free regions uncommitted, expand commits it back. > 2. Removes `CollectedHeap::finish_collection()` added in #93 because it was only used in G1 to synchronize uncommitting with C/R but now uncommitting is performed synchronously during the CRaC-invoked full GC, i.e. it became redundant. > 3. Renames `CollectedHeap::do_cleanup_unused()` to `CollectedHeap::should_cleanup_unused()` because I find the old name unintuitive: it sounds like the method _does_ the actual work while in reality it just returns whether the work _should_ be done. > > Notes: > - If `-XX:+AlwaysPreTouch` is used (not the default) the cleaned-up pages will become OS-reserved again immediately which means that if the C/R engine saves such memory into the image the image size will become larger after this change than it was before. This is OK since it is off by default and some engines can handle pre-touched pages without fully saving them into the image. > - G1 heap still gets shrunk during C/R because of the automatic shrinking. But it is less aggressive as before which is enough not to cause immediate full/mixed GCs in my testing. The user can also set `MaxHeapFreeRatio` to a larger value during C/R to reduce the shrinking (or even disable it completely) if needed ? that was not possible before. > > I used a benchmark based on wrk and Helidon's hello-world example to check if there are any performance gains. On JDK 25+14 I saw a 2?3% improvement for the first after-restore iteration performance (before there was a ~4% regression in last-before-checkpoint iteration vs first-after-restore iteration ? it became ~1.4%) and a 20% start-up speed-up (100ms vs 80ms). However, between 25+14 and 25+18 there has been some change made that improved the baseline performance to roughly the same level, so the improvement brought by my fix became almost unnoticeable on this particular benchmark on JDK 25+18. > > But in GC logs it is clear that less work is performed on restore so I still believe the change is beneficial: > >
> > W/o the change > > The heap is shrunk from 252MB to 4MB and preparations for mixed GC are performed. Sometimes (but not this time) mixed GCs themselves occur, on 25+14 there were full GCs even. > > > [1752668313926ms] ################# benchmark before C/R start #####... LGTM; I also totally agree with the renaming. ------------- Marked as reviewed by rvansa (Committer). PR Review: https://git.openjdk.org/crac/pull/243#pullrequestreview-3032525066 From tpushkin at openjdk.org Fri Jul 18 09:32:10 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Fri, 18 Jul 2025 09:32:10 GMT Subject: [crac] Integrated: 8362418: [CRaC] Leave unused G1 heap regions committed for C/R In-Reply-To: <-TiVEuvzgvvuO-I_pKCmNpw4WGsFmbwKqCv29Qyj2ks=.8de100bf-c7f8-4d69-a8ec-1f87fcddbe9f@github.com> References: <-TiVEuvzgvvuO-I_pKCmNpw4WGsFmbwKqCv29Qyj2ks=.8de100bf-c7f8-4d69-a8ec-1f87fcddbe9f@github.com> Message-ID: On Wed, 16 Jul 2025 13:56:07 GMT, Timofei Pushkin wrote: > See the JBS issue for the problem statement and the suggested approach to fix it. > > This PR: > 1. Implements the approach by expanding G1 heap back after shrinking and uncommitting it: shrink+uncommit makes memory in free regions uncommitted, expand commits it back. > 2. Removes `CollectedHeap::finish_collection()` added in #93 because it was only used in G1 to synchronize uncommitting with C/R but now uncommitting is performed synchronously during the CRaC-invoked full GC, i.e. it became redundant. > 3. Renames `CollectedHeap::do_cleanup_unused()` to `CollectedHeap::should_cleanup_unused()` because I find the old name unintuitive: it sounds like the method _does_ the actual work while in reality it just returns whether the work _should_ be done. > > Notes: > - If `-XX:+AlwaysPreTouch` is used (not the default) the cleaned-up pages will become OS-reserved again immediately which means that if the C/R engine saves such memory into the image the image size will become larger after this change than it was before. This is OK since it is off by default and some engines can handle pre-touched pages without fully saving them into the image. > - G1 heap still gets shrunk during C/R because of the automatic shrinking. But it is less aggressive as before which is enough not to cause immediate full/mixed GCs in my testing. The user can also set `MaxHeapFreeRatio` to a larger value during C/R to reduce the shrinking (or even disable it completely) if needed ? that was not possible before. > > I used a benchmark based on wrk and Helidon's hello-world example to check if there are any performance gains. On JDK 25+14 I saw a 2?3% improvement for the first after-restore iteration performance (before there was a ~4% regression in last-before-checkpoint iteration vs first-after-restore iteration ? it became ~1.4%) and a 20% start-up speed-up (100ms vs 80ms). However, between 25+14 and 25+18 there has been some change made that improved the baseline performance to roughly the same level, so the improvement brought by my fix became almost unnoticeable on this particular benchmark on JDK 25+18. > > But in GC logs it is clear that less work is performed on restore so I still believe the change is beneficial: > >
> > W/o the change > > The heap is shrunk from 252MB to 4MB and preparations for mixed GC are performed. Sometimes (but not this time) mixed GCs themselves occur, on 25+14 there were full GCs even. > > > [1752668313926ms] ################# benchmark before C/R start #####... This pull request has now been integrated. Changeset: 1846ced2 Author: Timofei Pushkin URL: https://git.openjdk.org/crac/commit/1846ced274ed7642f1123d498fb83befdd33ff97 Stats: 57 lines in 10 files changed: 28 ins; 24 del; 5 mod 8362418: [CRaC] Leave unused G1 heap regions committed for C/R Reviewed-by: rvansa ------------- PR: https://git.openjdk.org/crac/pull/243 From jkratochvil at openjdk.org Sat Jul 19 20:59:58 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Sat, 19 Jul 2025 20:59:58 GMT Subject: [crac] RFR: 8362837: [CRaC] jdk/crac/MXBean.java can fail on macOS Message-ID: The CI runs fine but locally (Linux Fedora 42 x86_64) it is failing for me - for any testcase trying to use OutputAnalyzer for restore-only part. checkpoint&restore is OK. Such testcases failing for me are for example: - test/jdk/jdk/crac/fileDescriptors/CheckpointWithOpenFdsTest.java - test/jdk/jdk/crac/fileDescriptors/LoggingFileOpenTest.java - test/jdk/jdk/crac/SecureRandom/ReseedTest.java ------------- Commit messages: - whitespaces - ZULU-67550: [CRaC] jdk/crac/MXBean.java fails on macOS (Gitlab CI) Changes: https://git.openjdk.org/crac/pull/246/files Webrev: https://webrevs.openjdk.org/?repo=crac&pr=246&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8362837 Stats: 24 lines in 1 file changed: 17 ins; 1 del; 6 mod Patch: https://git.openjdk.org/crac/pull/246.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/246/head:pull/246 PR: https://git.openjdk.org/crac/pull/246 From tpushkin at openjdk.org Sat Jul 19 20:59:58 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Sat, 19 Jul 2025 20:59:58 GMT Subject: [crac] RFR: 8362837: [CRaC] jdk/crac/MXBean.java can fail on macOS In-Reply-To: References: Message-ID: On Sat, 19 Jul 2025 18:12:40 GMT, Jan Kratochvil wrote: > The CI runs fine but locally (Linux Fedora 42 x86_64) it is failing for me - for any testcase trying to use OutputAnalyzer for restore-only part. checkpoint&restore is OK. Such testcases failing for me are for example: > - test/jdk/jdk/crac/fileDescriptors/CheckpointWithOpenFdsTest.java > - test/jdk/jdk/crac/fileDescriptors/LoggingFileOpenTest.java > - test/jdk/jdk/crac/SecureRandom/ReseedTest.java GitHub Actions should run in your repo just like on PRs here, so you should not need to create PRs to test CI. Except for whitespace checking... ------------- PR Comment: https://git.openjdk.org/crac/pull/246#issuecomment-3092500291 From jkratochvil at openjdk.org Sat Jul 19 20:59:58 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Sat, 19 Jul 2025 20:59:58 GMT Subject: [crac] RFR: 8362837: [CRaC] jdk/crac/MXBean.java can fail on macOS In-Reply-To: References: Message-ID: <95v57NMYP0xDv40p3-QCcr86BB0k5hZ75GHJ0SVjM6Y=.0175b68f-833a-4bfa-b6fd-ec675a5bedd9@github.com> On Sat, 19 Jul 2025 18:26:26 GMT, Timofei Pushkin wrote: > GitHub Actions should run in your repo just like on PRs here, so you should not need to create PRs to test CI. Except for whitespace checking... True, thanks. ------------- PR Comment: https://git.openjdk.org/crac/pull/246#issuecomment-3092502704 From jkratochvil at openjdk.org Sat Jul 19 21:06:38 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Sat, 19 Jul 2025 21:06:38 GMT Subject: [crac] RFR: 8362837: [CRaC] jdk/crac/MXBean.java can fail on macOS [v2] In-Reply-To: References: Message-ID: > The CI runs fine but locally (Linux Fedora 42 x86_64) it is failing for me - for any testcase trying to use OutputAnalyzer for restore-only part. checkpoint&restore is OK. Such testcases failing for me are for example: > - test/jdk/jdk/crac/fileDescriptors/CheckpointWithOpenFdsTest.java > - test/jdk/jdk/crac/fileDescriptors/LoggingFileOpenTest.java > - test/jdk/jdk/crac/SecureRandom/ReseedTest.java Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision: update copyright year ------------- Changes: - all: https://git.openjdk.org/crac/pull/246/files - new: https://git.openjdk.org/crac/pull/246/files/a554fbdf..1b049dec Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=246&range=01 - incr: https://webrevs.openjdk.org/?repo=crac&pr=246&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/crac/pull/246.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/246/head:pull/246 PR: https://git.openjdk.org/crac/pull/246 From tpushkin at openjdk.org Sun Jul 20 17:31:01 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Sun, 20 Jul 2025 17:31:01 GMT Subject: [crac] RFR: 8362837: [CRaC] jdk/crac/MXBean.java can fail on macOS [v2] In-Reply-To: References: Message-ID: <2KgOXGZCY6RHc16akxXKfoRCyAIOHUDOWU-VZUwgYGE=.e5671686-6b7e-4b10-ac19-bcd19ed0124a@github.com> On Sat, 19 Jul 2025 21:06:38 GMT, Jan Kratochvil wrote: >> The CI runs fine but locally (Linux Fedora 42 x86_64) it is failing for me - for any testcase trying to use OutputAnalyzer for the restore-only part. Such testcases failing for me are for example: >> - test/jdk/jdk/crac/fileDescriptors/CheckpointWithOpenFdsTest.java >> - test/jdk/jdk/crac/fileDescriptors/LoggingFileOpenTest.java >> - test/jdk/jdk/crac/SecureRandom/ReseedTest.java >> >> It does not implement the part >> >>> close to 0 >> >> as that is the problem being fixed. > > Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision: > > update copyright year Maybe I do not understand the changes but to me it looks like they won't function right.
Here is how I envisioned it in my original suggestion I reduced the tolerance since the measured time should be less now, but maybe it is too bold of a reduction. diff --git a/test/jdk/jdk/crac/MXBean.java b/test/jdk/jdk/crac/MXBean.java index 336e3eecd12..0bb6605432e 100644 --- a/test/jdk/jdk/crac/MXBean.java +++ b/test/jdk/jdk/crac/MXBean.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2022, Azul Systems, Inc. All rights reserved. + * Copyright (c) 2022, 2025, Azul Systems, Inc. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -26,6 +26,7 @@ import jdk.crac.*; import jdk.crac.management.*; +import jdk.test.lib.Platform; import jdk.test.lib.crac.CracBuilder; import jdk.test.lib.crac.CracEngine; import jdk.test.lib.crac.CracTest; @@ -35,7 +36,7 @@ import java.time.ZoneId; import java.time.format.DateTimeFormatter; -import static jdk.test.lib.Asserts.assertLT; +import static jdk.test.lib.Asserts.*; /** * @test @@ -44,7 +45,12 @@ * @run driver jdk.test.lib.crac.CracTest */ public class MXBean implements CracTest { - static final long TIME_TOLERANCE = 10_000; // ms + static final long TIME_TOLERANCE = 1000; // ms + + private static String formatTime(long t) { + return DateTimeFormatter.ofPattern("E dd LLL yyyy HH:mm:ss.n").format( + Instant.ofEpochMilli(t).atZone(ZoneId.systemDefault())); + } @Override public void exec() throws CheckpointException, RestoreException { @@ -55,28 +61,36 @@ public void exec() throws CheckpointException, RestoreException { System.out.println("UptimeSinceRestore " + cracMXBean.getUptimeSinceRestore()); long restoreTime = cracMXBean.getRestoreTime(); - System.out.println("RestoreTime " + restoreTime + " " + - DateTimeFormatter.ofPattern("E dd LLL yyyy HH:mm:ss.n").format( - Instant.ofEpochMilli(restoreTime) - .atZone(ZoneId.systemDefault()))); + System.out.println("RestoreTime " + restoreTime + " " + formatTime(restoreTime)); } @Override public void test() throws Exception { - long start = System.currentTimeMillis(); + final var builder = new CracBuilder().captureOutput(true); - OutputAnalyzer output = new CracBuilder().engine(CracEngine.SIMULATE) - .captureOutput(true) - .startCheckpoint().waitForSuccess().outputAnalyzer(); - - long restoreUptime = Long.parseLong(output.firstMatch("UptimeSinceRestore ([0-9-]+)", 1)); - if (restoreUptime < 0 || TIME_TOLERANCE < restoreUptime) { - throw new Error("bad UptimeSinceRestore: " + restoreUptime); + final OutputAnalyzer output; + final long restoreStartTime; + if (Platform.isLinux()) { // Linux is currently the only platform supporting non-immediate restore + final var process = builder.engine(CracEngine.PAUSE).startCheckpoint(); + output = process.outputAnalyzer(); + process.waitForPausePid(); + restoreStartTime = System.currentTimeMillis(); + builder.doRestore(); + System.out.println("RestoreStartTime " + restoreStartTime + " " + formatTime(restoreStartTime)); + } else { + output = builder.engine(CracEngine.SIMULATE).startCheckpoint().waitForSuccess().outputAnalyzer(); + restoreStartTime = -1; // Unknown } - long restoreTime = Long.parseLong(output.firstMatch("RestoreTime ([0-9-]+)", 1)); - restoreTime -= start; + final long uptimeSinceRestore = Long.parseLong(output.firstMatch("UptimeSinceRestore ([0-9-]+)", 1)); + assertGTE(uptimeSinceRestore, 0L, "Bad UptimeSinceRestore"); + assertLT(uptimeSinceRestore, TIME_TOLERANCE, "UptimeSinceRestore should be close to 0"); - assertLT(Math.abs(restoreTime), TIME_TOLERANCE, "bad RestoreTime: " + restoreTime); + final long restoreTime = Long.parseLong(output.firstMatch("RestoreTime ([0-9-]+)", 1));
test/jdk/jdk/crac/MXBean.java line 79: > 77: long restoreTimePassed = System.currentTimeMillis() - restoreStart; > 78: System.err.println("restoreTimePassed="+restoreTimePassed); > 79: if (restoreTimePassed < 0 || TIME_TOLERANCE < restoreTimePassed) { What is the purpose of this check? As I understand it, it checks that restore + restored code execution takes time close to zero which I don't think is a reasonable expectation (it passes because the tolerance is high). Also the test is supposed to be about `CRaCMXBean` which is not involved here. test/jdk/jdk/crac/MXBean.java line 90: > 88: long restoreUptime = Long.parseLong(output.firstMatch("UptimeSinceRestore ([0-9-]+)", 1)); > 89: System.err.println("restoreUptime=" + restoreUptime); > 90: if (restoreUptime < 0) { AFAIK we have not had problems with this check, only with the below one. "UptimeSinceRestore" should be close to 0 on all platforms ------------- PR Review: https://git.openjdk.org/crac/pull/246#pullrequestreview-3036087307 PR Review Comment: https://git.openjdk.org/crac/pull/246#discussion_r2217875547 PR Review Comment: https://git.openjdk.org/crac/pull/246#discussion_r2217876080 From jkratochvil at openjdk.org Sun Jul 20 19:46:00 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Sun, 20 Jul 2025 19:46:00 GMT Subject: [crac] RFR: 8362837: [CRaC] jdk/crac/MXBean.java can fail on macOS [v2] In-Reply-To: <2KgOXGZCY6RHc16akxXKfoRCyAIOHUDOWU-VZUwgYGE=.e5671686-6b7e-4b10-ac19-bcd19ed0124a@github.com> References: <2KgOXGZCY6RHc16akxXKfoRCyAIOHUDOWU-VZUwgYGE=.e5671686-6b7e-4b10-ac19-bcd19ed0124a@github.com> Message-ID: On Sun, 20 Jul 2025 16:15:52 GMT, Timofei Pushkin wrote: >> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision: >> >> update copyright year > > test/jdk/jdk/crac/MXBean.java line 79: > >> 77: long restoreTimePassed = System.currentTimeMillis() - restoreStart; >> 78: System.err.println("restoreTimePassed="+restoreTimePassed); >> 79: if (restoreTimePassed < 0 || TIME_TOLERANCE < restoreTimePassed) { > > What is the purpose of this check? As I understand it, it checks that restore + restored code execution takes time close to zero which I don't think is a reasonable expectation (it passes because the tolerance is high). > > Also the test is supposed to be about `CRaCMXBean` which is not involved here. This check is implemented your words: > For platforms that have engines with restore time passing (only Linux currently, I think pauseengine is enough here) ? this will be almost the same test as it is now, but it will do an actual restore call and measure the restore start time from that call. Regarding `CRaCMXBean` - I do not see any need for it to implement your words above. Although maybe I did not understand it as I do not see why/how to use `pauseengine` when you want `actual restore call`. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/246#discussion_r2217933689 From jkratochvil at openjdk.org Sun Jul 20 19:52:04 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Sun, 20 Jul 2025 19:52:04 GMT Subject: [crac] RFR: 8362837: [CRaC] jdk/crac/MXBean.java can fail on macOS [v3] In-Reply-To: References: Message-ID: > The CI runs fine but locally (Linux Fedora 42 x86_64) it is failing for me - for any testcase trying to use OutputAnalyzer for the restore-only part. Such testcases failing for me are for example: > - test/jdk/jdk/crac/fileDescriptors/CheckpointWithOpenFdsTest.java > - test/jdk/jdk/crac/fileDescriptors/LoggingFileOpenTest.java > - test/jdk/jdk/crac/SecureRandom/ReseedTest.java > > It does not implement the part > >> close to 0 > > as that is the problem being fixed. Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision: remove UptimeSinceRestore ------------- Changes: - all: https://git.openjdk.org/crac/pull/246/files - new: https://git.openjdk.org/crac/pull/246/files/1b049dec..9a8feff6 Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=246&range=02 - incr: https://webrevs.openjdk.org/?repo=crac&pr=246&range=01-02 Stats: 9 lines in 1 file changed: 0 ins; 8 del; 1 mod Patch: https://git.openjdk.org/crac/pull/246.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/246/head:pull/246 PR: https://git.openjdk.org/crac/pull/246 From tpushkin at openjdk.org Sun Jul 20 19:52:04 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Sun, 20 Jul 2025 19:52:04 GMT Subject: [crac] RFR: 8362837: [CRaC] jdk/crac/MXBean.java can fail on macOS [v2] In-Reply-To: References: <2KgOXGZCY6RHc16akxXKfoRCyAIOHUDOWU-VZUwgYGE=.e5671686-6b7e-4b10-ac19-bcd19ed0124a@github.com> Message-ID: On Sun, 20 Jul 2025 19:43:19 GMT, Jan Kratochvil wrote: >> test/jdk/jdk/crac/MXBean.java line 79: >> >>> 77: long restoreTimePassed = System.currentTimeMillis() - restoreStart; >>> 78: System.err.println("restoreTimePassed="+restoreTimePassed); >>> 79: if (restoreTimePassed < 0 || TIME_TOLERANCE < restoreTimePassed) { >> >> What is the purpose of this check? As I understand it, it checks that restore + restored code execution takes time close to zero which I don't think is a reasonable expectation (it passes because the tolerance is high). >> >> Also the test is supposed to be about `CRaCMXBean` which is not involved here. > > This check is implementing your words: > >> For platforms that have engines with restore time passing (only Linux currently, I think pauseengine is enough here) ? this will be almost the same test as it is now, but it will do an actual restore call and measure the restore start time from that call. > > Regarding `CRaCMXBean` - I do not see any need for it to implement your words above. Although maybe I did not understand it as I do not see why/how to use `pauseengine` when you want `actual restore call`. I meant recording the time of restore start and then comparing it with the restore start time `MXBean` provides. `pauseengine` should be enough because we need an engine that allows to start restoring at some particular moment, not immediately after checkpoint as `simengine` does. Anyway, I posted the code that implements what I meant, it should be clearer. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/246#discussion_r2217935008 From jkratochvil at openjdk.org Sun Jul 20 19:52:04 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Sun, 20 Jul 2025 19:52:04 GMT Subject: [crac] RFR: 8362837: [CRaC] jdk/crac/MXBean.java can fail on macOS [v2] In-Reply-To: <2KgOXGZCY6RHc16akxXKfoRCyAIOHUDOWU-VZUwgYGE=.e5671686-6b7e-4b10-ac19-bcd19ed0124a@github.com> References: <2KgOXGZCY6RHc16akxXKfoRCyAIOHUDOWU-VZUwgYGE=.e5671686-6b7e-4b10-ac19-bcd19ed0124a@github.com> Message-ID: <8w22GUVMeApDweIt5cAAgB-cz5k6hA9-HOdy5xP7JNI=.b67df25e-76bf-4709-8fb0-c910837c057f@github.com> On Sun, 20 Jul 2025 16:18:17 GMT, Timofei Pushkin wrote: >> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision: >> >> update copyright year > > test/jdk/jdk/crac/MXBean.java line 90: > >> 88: long restoreUptime = Long.parseLong(output.firstMatch("UptimeSinceRestore ([0-9-]+)", 1)); >> 89: System.err.println("restoreUptime=" + restoreUptime); >> 90: if (restoreUptime < 0) { > > AFAIK we have not had problems with this check, only with the below one. "UptimeSinceRestore" should be close to 0 on all platforms What do you exactly mean by `close to 0`? I already mention here in the initial comment I did not implement `close to 0`. Do you mean less than `TIME_TOLERANCE`? But that is exactly the problem why it sometimes fails on Mac CI. I am going to remove the `restoreUptime < 0` test when you do not like it. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/246#discussion_r2217934603 From tpushkin at openjdk.org Sun Jul 20 19:56:19 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Sun, 20 Jul 2025 19:56:19 GMT Subject: [crac] RFR: 8362837: [CRaC] jdk/crac/MXBean.java can fail on macOS [v2] In-Reply-To: <8w22GUVMeApDweIt5cAAgB-cz5k6hA9-HOdy5xP7JNI=.b67df25e-76bf-4709-8fb0-c910837c057f@github.com> References: <2KgOXGZCY6RHc16akxXKfoRCyAIOHUDOWU-VZUwgYGE=.e5671686-6b7e-4b10-ac19-bcd19ed0124a@github.com> <8w22GUVMeApDweIt5cAAgB-cz5k6hA9-HOdy5xP7JNI=.b67df25e-76bf-4709-8fb0-c910837c057f@github.com> Message-ID: <7r982Bl_SFZMJov2oohOun8nBQYS2lHFdJazYAp5zzo=.245cc08d-8701-4711-b5a4-47dc14748a57@github.com> On Sun, 20 Jul 2025 19:46:48 GMT, Jan Kratochvil wrote: >> test/jdk/jdk/crac/MXBean.java line 90: >> >>> 88: long restoreUptime = Long.parseLong(output.firstMatch("UptimeSinceRestore ([0-9-]+)", 1)); >>> 89: System.err.println("restoreUptime=" + restoreUptime); >>> 90: if (restoreUptime < 0) { >> >> AFAIK we have not had problems with this check, only with the below one. "UptimeSinceRestore" should be close to 0 on all platforms > > What do you exactly mean by `close to 0`? I already mention here in the initial comment I did not implement `close to 0`. Do you mean less than `TIME_TOLERANCE`? But that is exactly the problem why it sometimes fails on Mac CI. > > I am going to remove the `restoreUptime < 0` test when you do not like it. CI was failing for the check below AFAIK. In my understanding this one should not be failing the way it is. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/246#discussion_r2217936481 From jkratochvil at openjdk.org Sun Jul 20 20:01:34 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Sun, 20 Jul 2025 20:01:34 GMT Subject: [crac] RFR: 8362837: [CRaC] jdk/crac/MXBean.java can fail on macOS [v4] In-Reply-To: References: Message-ID: > The CI runs fine but locally (Linux Fedora 42 x86_64) it is failing for me - for any testcase trying to use OutputAnalyzer for the restore-only part. Such testcases failing for me are for example: > - test/jdk/jdk/crac/fileDescriptors/CheckpointWithOpenFdsTest.java > - test/jdk/jdk/crac/fileDescriptors/LoggingFileOpenTest.java > - test/jdk/jdk/crac/SecureRandom/ReseedTest.java > > It does not implement the part > >> close to 0 > > as that is the problem being fixed. Jan Kratochvil has updated the pull request incrementally with two additional commits since the last revision: - Second TimPushkin's patch - 1st patch by TimPushkin ------------- Changes: - all: https://git.openjdk.org/crac/pull/246/files - new: https://git.openjdk.org/crac/pull/246/files/9a8feff6..6bd14b35 Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=246&range=03 - incr: https://webrevs.openjdk.org/?repo=crac&pr=246&range=02-03 Stats: 43 lines in 1 file changed: 18 ins; 10 del; 15 mod Patch: https://git.openjdk.org/crac/pull/246.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/246/head:pull/246 PR: https://git.openjdk.org/crac/pull/246 From tpushkin at openjdk.org Mon Jul 21 07:01:18 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Mon, 21 Jul 2025 07:01:18 GMT Subject: [crac] RFR: 8362837: [CRaC] jdk/crac/MXBean.java can fail on macOS [v4] In-Reply-To: References: Message-ID: On Sun, 20 Jul 2025 20:01:34 GMT, Jan Kratochvil wrote: >> The CI runs fine but locally (Linux Fedora 42 x86_64) it is failing for me - for any testcase trying to use OutputAnalyzer for the restore-only part. Such testcases failing for me are for example: >> - test/jdk/jdk/crac/fileDescriptors/CheckpointWithOpenFdsTest.java >> - test/jdk/jdk/crac/fileDescriptors/LoggingFileOpenTest.java >> - test/jdk/jdk/crac/SecureRandom/ReseedTest.java >> >> It does not implement the part >> >>> close to 0 >> >> as that is the problem being fixed. > > Jan Kratochvil has updated the pull request incrementally with two additional commits since the last revision: > > - Second TimPushkin's patch > - 1st patch by TimPushkin LGTM, although it is my own suggestion. If the reduced time tolerance will be too low for our CI we can raise it downstream. But I hope it won't be necessary. ------------- Marked as reviewed by tpushkin (Committer). PR Review: https://git.openjdk.org/crac/pull/246#pullrequestreview-3036802171 From rvansa at openjdk.org Mon Jul 21 09:15:31 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Mon, 21 Jul 2025 09:15:31 GMT Subject: [crac] RFR: 8362837: [CRaC] jdk/crac/MXBean.java can fail on macOS In-Reply-To: References: Message-ID: On Sat, 19 Jul 2025 18:26:26 GMT, Timofei Pushkin wrote: >> The CI runs fine but locally (Linux Fedora 42 x86_64) it is failing for me - for any testcase trying to use OutputAnalyzer for the restore-only part. Such testcases failing for me are for example: >> - test/jdk/jdk/crac/fileDescriptors/CheckpointWithOpenFdsTest.java >> - test/jdk/jdk/crac/fileDescriptors/LoggingFileOpenTest.java >> - test/jdk/jdk/crac/SecureRandom/ReseedTest.java >> >> It does not implement the part >> >>> close to 0 >> >> as that is the problem being fixed. > > GitHub Actions should run in your repo just like on PRs here, so you should not need to create PRs to test CI. Except for whitespace checking... @TimPushkin I don't really get the comment > But looking at the test I would expect it to be fragile: it measures the time from the start of the checkpointed process to the start of its restore and wants it to be 0, and since this is not a reasonable thing to expect it sets a huge tolerance of 10 seconds. On platforms that don't propagate the 'restore time', it is expected that the current time would be used (which is somewhat later than 'restore initiation'). The test asserts that from the point where we really invoke the restore up to this point it's less than 10 seconds - so asking a trivial process to be restored withing 10 seconds. I thought that this is a reasonable time, though we can make it even 60 seconds if we know that CI can be extra sluggish. ------------- PR Comment: https://git.openjdk.org/crac/pull/246#issuecomment-3095838669 From jkratochvil at openjdk.org Mon Jul 21 09:22:59 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Mon, 21 Jul 2025 09:22:59 GMT Subject: [crac] RFR: 8362837: [CRaC] jdk/crac/MXBean.java can fail on macOS [v4] In-Reply-To: References: Message-ID: On Sun, 20 Jul 2025 20:01:34 GMT, Jan Kratochvil wrote: >> The CI runs fine but locally (Linux Fedora 42 x86_64) it is failing for me - for any testcase trying to use OutputAnalyzer for the restore-only part. Such testcases failing for me are for example: >> - test/jdk/jdk/crac/fileDescriptors/CheckpointWithOpenFdsTest.java >> - test/jdk/jdk/crac/fileDescriptors/LoggingFileOpenTest.java >> - test/jdk/jdk/crac/SecureRandom/ReseedTest.java >> >> It does not implement the part >> >>> close to 0 >> >> as that is the problem being fixed. > > Jan Kratochvil has updated the pull request incrementally with two additional commits since the last revision: > > - Second TimPushkin's patch > - 1st patch by TimPushkin So either it is - a performance test - then it needs to track the time per platform, the limit should be tight and it must not run in parallel with other parts of the testsuite, IIRC perf lab dept. should take care of it - or it just checks whether it completes at all - and then it needs no limit at all as there is already a JTREG testcase limit ------------- PR Comment: https://git.openjdk.org/crac/pull/246#issuecomment-3095862862 From tpushkin at openjdk.org Mon Jul 21 09:41:13 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Mon, 21 Jul 2025 09:41:13 GMT Subject: [crac] RFR: 8362837: [CRaC] jdk/crac/MXBean.java can fail on macOS In-Reply-To: References: Message-ID: <3DSCNlY-zX9ILNGWAf2hlwlpx-7id0rEN7Mwfh-usK4=.2c211de2-fe96-41c0-9fea-e4faade068e4@github.com> On Mon, 21 Jul 2025 09:12:21 GMT, Radim Vansa wrote: >> GitHub Actions should run in your repo just like on PRs here, so you should not need to create PRs to test CI. Except for whitespace checking... > > @TimPushkin I don't really get the comment > >> But looking at the test I would expect it to be fragile: it measures the time from the start of the checkpointed process to the start of its restore and wants it to be 0, and since this is not a reasonable thing to expect it sets a huge tolerance of 10 seconds. > > On platforms that don't propagate the 'restore time', it is expected that the current time would be used (which is somewhat later than 'restore initiation'). The test asserts that from the point where we really invoke the restore up to this point it's less than 10 seconds - so asking a trivial process to be restored withing 10 seconds. I thought that this is a reasonable time, though we can make it even 60 seconds if we know that CI can be extra sluggish. @rvansa In our downstream CI it looks like 10 seconds is not enough for MacOS, that is why I proposed to rework the test to use an engine that allows to propagate restore time on platforms where such engine exists (Linux) and not use `TIME_TOLERANCE` at all for `getRestoreTime()` on platforms where there is no such engine (MacOS, Windows). To me it looks like a better solution than just increasing the tolerance because that would make the `getUptimeSinceRestore()` check on all platforms and `getRestoreTime()` check on non-MacOS platforms more tolerant then necessary (even 10s is too tolerant for Linux in my opinion) ------------- PR Comment: https://git.openjdk.org/crac/pull/246#issuecomment-3095922923 From tpushkin at openjdk.org Mon Jul 21 09:45:22 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Mon, 21 Jul 2025 09:45:22 GMT Subject: [crac] RFR: 8362837: [CRaC] jdk/crac/MXBean.java can fail on macOS [v4] In-Reply-To: References: Message-ID: On Sun, 20 Jul 2025 20:01:34 GMT, Jan Kratochvil wrote: >> The CI runs fine but locally (Linux Fedora 42 x86_64) it is failing for me - for any testcase trying to use OutputAnalyzer for the restore-only part. Such testcases failing for me are for example: >> - test/jdk/jdk/crac/fileDescriptors/CheckpointWithOpenFdsTest.java >> - test/jdk/jdk/crac/fileDescriptors/LoggingFileOpenTest.java >> - test/jdk/jdk/crac/SecureRandom/ReseedTest.java >> >> It does not implement the part >> >>> close to 0 >> >> as that is the problem being fixed. > > Jan Kratochvil has updated the pull request incrementally with two additional commits since the last revision: > > - Second TimPushkin's patch > - 1st patch by TimPushkin Maybe I am indeed overcomplicating it and just checking that the values are somewhat meaningful with a large tolerance (or none at all) is enough, as Jan suggests ------------- PR Comment: https://git.openjdk.org/crac/pull/246#issuecomment-3095937596 From rvansa at openjdk.org Mon Jul 21 12:37:00 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Mon, 21 Jul 2025 12:37:00 GMT Subject: [crac] RFR: 8362837: [CRaC] jdk/crac/MXBean.java can fail on macOS [v4] In-Reply-To: References: Message-ID: On Mon, 21 Jul 2025 09:40:55 GMT, Timofei Pushkin wrote: >> Jan Kratochvil has updated the pull request incrementally with two additional commits since the last revision: >> >> - Second TimPushkin's patch >> - 1st patch by TimPushkin > > Maybe I am indeed overcomplicating it and just checking that the values are somewhat meaningful with a large tolerance (or none at all) is enough, as Jan suggests @TimPushkin It asserts that the value we get is in a reasonable range (it's not entirely bogus value). >From test code-smell POV, it is a bit weird when one test does something different on Linux and other platforms. I won't push the ultimate decision what to do with this test, though. ------------- PR Comment: https://git.openjdk.org/crac/pull/246#issuecomment-3096564207 From tpushkin at openjdk.org Mon Jul 21 13:23:10 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Mon, 21 Jul 2025 13:23:10 GMT Subject: [crac] RFR: 8362837: [CRaC] jdk/crac/MXBean.java can fail on macOS [v4] In-Reply-To: References: Message-ID: On Sun, 20 Jul 2025 20:01:34 GMT, Jan Kratochvil wrote: >> The CI runs fine but locally (Linux Fedora 42 x86_64) it is failing for me - for any testcase trying to use OutputAnalyzer for the restore-only part. Such testcases failing for me are for example: >> - test/jdk/jdk/crac/fileDescriptors/CheckpointWithOpenFdsTest.java >> - test/jdk/jdk/crac/fileDescriptors/LoggingFileOpenTest.java >> - test/jdk/jdk/crac/SecureRandom/ReseedTest.java >> >> It does not implement the part >> >>> close to 0 >> >> as that is the problem being fixed. > > Jan Kratochvil has updated the pull request incrementally with two additional commits since the last revision: > > - Second TimPushkin's patch > - 1st patch by TimPushkin Ok, I can agree to just increase the tolerance instead of my suggestions. Looks like it should be `100_000` at least since we had `60143` at least once. Maybe we should even do it only downstream... Not sure why our MacOS runners are that slow. ------------- PR Comment: https://git.openjdk.org/crac/pull/246#issuecomment-3096767257 From jkratochvil at openjdk.org Mon Jul 21 16:49:40 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Mon, 21 Jul 2025 16:49:40 GMT Subject: [crac] RFR: 8362837: [CRaC] jdk/crac/MXBean.java can fail on macOS [v4] In-Reply-To: References: Message-ID: On Mon, 21 Jul 2025 13:19:48 GMT, Timofei Pushkin wrote: >> Jan Kratochvil has updated the pull request incrementally with two additional commits since the last revision: >> >> - Second TimPushkin's patch >> - 1st patch by TimPushkin > > Ok, I can agree to just increase the tolerance instead of my suggestions. Looks like it should be `100_000` at least since we had `60143` at least once. > > Maybe we should even do it only downstream... Not sure why our MacOS runners are that slow. @TimPushkin OK so going to submit only a oneliner downstream, sorry for your time. ------------- PR Comment: https://git.openjdk.org/crac/pull/246#issuecomment-3097564732 From jkratochvil at openjdk.org Mon Jul 21 16:49:40 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Mon, 21 Jul 2025 16:49:40 GMT Subject: [crac] Withdrawn: 8362837: [CRaC] jdk/crac/MXBean.java can fail on macOS In-Reply-To: References: Message-ID: On Sat, 19 Jul 2025 18:12:40 GMT, Jan Kratochvil wrote: > The CI runs fine but locally (Linux Fedora 42 x86_64) it is failing for me - for any testcase trying to use OutputAnalyzer for the restore-only part. Such testcases failing for me are for example: > - test/jdk/jdk/crac/fileDescriptors/CheckpointWithOpenFdsTest.java > - test/jdk/jdk/crac/fileDescriptors/LoggingFileOpenTest.java > - test/jdk/jdk/crac/SecureRandom/ReseedTest.java > > It does not implement the part > >> close to 0 > > as that is the problem being fixed. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/crac/pull/246 From jkratochvil at openjdk.org Mon Jul 21 18:28:22 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Mon, 21 Jul 2025 18:28:22 GMT Subject: [crac] RFR: 8352675: Support Intel AVX10 converged vector ISA feature detection Message-ID: This is the merge of the single commit [3b336a9da091c4df4373d2b845b60d2a7a4e3b1d](https://github.com/openjdk/jdk/commit/3b336a9da091c4df4373d2b845b60d2a7a4e3b1d) which also disables CPUFeatures. ------------- Commit messages: - 8352675: Support Intel AVX10 converged vector ISA feature detection Changes: https://git.openjdk.org/crac/pull/247/files Webrev: https://webrevs.openjdk.org/?repo=crac&pr=247&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352675 Stats: 603 lines in 19 files changed: 338 ins; 40 del; 225 mod Patch: https://git.openjdk.org/crac/pull/247.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/247/head:pull/247 PR: https://git.openjdk.org/crac/pull/247 From rvansa at openjdk.org Tue Jul 22 07:15:46 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 22 Jul 2025 07:15:46 GMT Subject: [crac] RFR: 8352675: Support Intel AVX10 converged vector ISA feature detection In-Reply-To: References: Message-ID: On Mon, 21 Jul 2025 18:19:49 GMT, Jan Kratochvil wrote: > This is the merge of the single commit [3b336a9da091c4df4373d2b845b60d2a7a4e3b1d](https://github.com/openjdk/jdk/commit/3b336a9da091c4df4373d2b845b60d2a7a4e3b1d) which also disables CPUFeatures. There are significant portions of code commented out through `#if 0` - what are the FIXMEs for? I like the improved readability with `VM_Version::VM_Features`. Would it be possible to replace the definitions constructed using `VM_STRUCTS_CPU` with a struct, too? Do you have a test (even some manually-run qemu-based script) that would demonstrate that the changes do what these are supposed to? src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotJVMCIBackendFactory.java line 99: > 97: * @return the set of converted values > 98: */ > 99: static > EnumSet convertFeatures( I suppose this is more generic version of the function above; wouldn't it be worth making the above just an adapter to the logic here? ------------- PR Review: https://git.openjdk.org/crac/pull/247#pullrequestreview-3041458011 PR Review Comment: https://git.openjdk.org/crac/pull/247#discussion_r2221445725 From jkratochvil at openjdk.org Tue Jul 22 07:21:49 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Tue, 22 Jul 2025 07:21:49 GMT Subject: [crac] RFR: 8352675: Support Intel AVX10 converged vector ISA feature detection In-Reply-To: References: Message-ID: On Tue, 22 Jul 2025 07:13:16 GMT, Radim Vansa wrote: > There are significant portions of code commented out through `#if 0` - what are the FIXMEs for? The CPUFeatures feature has been disabled as it is not ported yet. I will be porting it these days and sure these `#if 0` will be removed then. Another option would be to remove all the CPUFeatures code but it would be more work to do and then more work to add it back this week. > I like the improved readability with `VM_Version::VM_Features`. Would it be possible to replace the definitions constructed using `VM_STRUCTS_CPU` with a struct, too? You mean an upstream refactorization unrelated to CPUFeatures? > Do you have a test (even some manually-run qemu-based script) that would demonstrate that the changes do what these are supposed to? CPUFeatures are ignored/disabled now so only normal JVM testsuite matters. ------------- PR Comment: https://git.openjdk.org/crac/pull/247#issuecomment-3101402531 From rvansa at openjdk.org Tue Jul 22 08:12:49 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 22 Jul 2025 08:12:49 GMT Subject: [crac] RFR: 8352675: Support Intel AVX10 converged vector ISA feature detection In-Reply-To: References: Message-ID: On Mon, 21 Jul 2025 18:19:49 GMT, Jan Kratochvil wrote: > This is the merge of the single commit [3b336a9da091c4df4373d2b845b60d2a7a4e3b1d](https://github.com/openjdk/jdk/commit/3b336a9da091c4df4373d2b845b60d2a7a4e3b1d) which also disables CPUFeatures. Oh, I mistook this for your original work, rather than just a backport. I shall probably look at the diff of diffs. So you just commented out some parts of that. What exactly is disabled, and what are the implications? I suppose that this isn't disabling how CRaC can enforce a subset of CPU features available to the JIT... ------------- PR Comment: https://git.openjdk.org/crac/pull/247#issuecomment-3101563421 From jkratochvil at openjdk.org Tue Jul 22 12:19:50 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Tue, 22 Jul 2025 12:19:50 GMT Subject: [crac] RFR: 8352675: Support Intel AVX10 converged vector ISA feature detection In-Reply-To: References: Message-ID: On Mon, 21 Jul 2025 18:19:49 GMT, Jan Kratochvil wrote: > This is the merge of the single commit [3b336a9da091c4df4373d2b845b60d2a7a4e3b1d](https://github.com/openjdk/jdk/commit/3b336a9da091c4df4373d2b845b60d2a7a4e3b1d) which also disables CPUFeatures. Correct, it still behaves as with `-XX:CPUFeatures=ignore` no matter what you enter (or if you leave it default). This is just for a few days so that @dimitryc can finish the rebase on latest JDK. ------------- PR Comment: https://git.openjdk.org/crac/pull/247#issuecomment-3102464161 From rvansa at openjdk.org Tue Jul 22 14:22:46 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 22 Jul 2025 14:22:46 GMT Subject: [crac] RFR: 8352675: Support Intel AVX10 converged vector ISA feature detection In-Reply-To: References: Message-ID: On Mon, 21 Jul 2025 18:19:49 GMT, Jan Kratochvil wrote: > This is the merge of the single commit [3b336a9da091c4df4373d2b845b60d2a7a4e3b1d](https://github.com/openjdk/jdk/commit/3b336a9da091c4df4373d2b845b60d2a7a4e3b1d) which also disables CPUFeatures. OK, let's prepare the full path for this + @dimitryc 's merge + any fixup and then we can review that in full an merge it. ------------- PR Comment: https://git.openjdk.org/crac/pull/247#issuecomment-3102961207 From jkratochvil at openjdk.org Tue Jul 22 18:32:29 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Tue, 22 Jul 2025 18:32:29 GMT Subject: [crac] RFR: 8362837: [CRaC] jdk/crac/MXBean.java can fail on macOS [v5] In-Reply-To: References: Message-ID: > Some Mac CI hosts downstream occasionally fail, it looks like they are just too slow. Jan Kratochvil has updated the pull request incrementally with three additional commits since the last revision: - copyright year update - the oneliner fix - revert all the previous changes ------------- Changes: - all: https://git.openjdk.org/crac/pull/246/files - new: https://git.openjdk.org/crac/pull/246/files/6bd14b35..d9824bef Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=246&range=04 - incr: https://webrevs.openjdk.org/?repo=crac&pr=246&range=03-04 Stats: 36 lines in 1 file changed: 3 ins; 19 del; 14 mod Patch: https://git.openjdk.org/crac/pull/246.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/246/head:pull/246 PR: https://git.openjdk.org/crac/pull/246 From duke at openjdk.org Wed Jul 23 10:17:14 2025 From: duke at openjdk.org (duke) Date: Wed, 23 Jul 2025 10:17:14 GMT Subject: [crac] RFR: 8362837: [CRaC] jdk/crac/MXBean.java can fail on macOS [v5] In-Reply-To: References: Message-ID: On Tue, 22 Jul 2025 18:32:29 GMT, Jan Kratochvil wrote: >> Some Mac CI hosts downstream occasionally fail, it looks like they are just too slow. > > Jan Kratochvil has updated the pull request incrementally with three additional commits since the last revision: > > - copyright year update > - the oneliner fix > - revert all the previous changes @jankratochvil Your change (at version d9824bef3263fa0c992554d2ac8445a6896b6d54) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/crac/pull/246#issuecomment-3106850437 From jkratochvil at openjdk.org Wed Jul 23 11:20:39 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Wed, 23 Jul 2025 11:20:39 GMT Subject: [crac] Integrated: 8362837: [CRaC] jdk/crac/MXBean.java can fail on macOS In-Reply-To: References: Message-ID: On Sat, 19 Jul 2025 18:12:40 GMT, Jan Kratochvil wrote: > Some Mac CI hosts downstream occasionally fail, it looks like they are just too slow. This pull request has now been integrated. Changeset: 9a1ab26a Author: Jan Kratochvil Committer: Timofei Pushkin URL: https://git.openjdk.org/crac/commit/9a1ab26ab98c2307fb5b424f493c911abdcb1829 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8362837: [CRaC] jdk/crac/MXBean.java can fail on macOS Reviewed-by: tpushkin ------------- PR: https://git.openjdk.org/crac/pull/246 From dcherepanov at openjdk.org Wed Jul 23 18:04:22 2025 From: dcherepanov at openjdk.org (Dmitry Cherepanov) Date: Wed, 23 Jul 2025 18:04:22 GMT Subject: [crac] RFR: Merge jdk:jdk-25+26 Message-ID: <8s5ymOREBNkrHIH_me6UxsNK6QjhJ9VsUPWPrYFNOIY=.74bc9410-d039-40ee-bc17-d5f1e3833ae2@github.com> Since the merge for [JDK-8352675](https://bugs.openjdk.org/browse/JDK-8352675) is split into a separate PR (https://github.com/openjdk/crac/pull/247), I cherry-picked the current version and merging other changes on top of it. It will likely require rebase on top of the final version later. Attaching output of `--diff-merges=remerge`
Conflicts commit 5035f463900712ae47b7e1adfeff609bc1d66116 (HEAD -> merge-jdk, dmitry-crac/merge-jdk) Merge: d61227fe01d c59e44a7aa2 Author: Dmitry Cherepanov Date: Tue Jul 22 13:30:47 2025 +0400 Merge with jdk-25+26 diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml remerge CONFLICT (content): Merge conflict in .github/workflows/main.yml index 8cf745c1cff..02c6f3d2668 100644 --- a/.github/workflows/main.yml +++ b/.github/workflows/main.yml @@ -310,11 +310,7 @@ jobs: uses: ./.github/workflows/build-windows.yml with: platform: windows-x64 -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) msvc-toolset-version: '14.44' -======= - msvc-toolset-version: '14.43' ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) msvc-toolset-architecture: 'x86.x64' configure-arguments: ${{ github.event.inputs.configure-arguments }} make-arguments: ${{ github.event.inputs.make-arguments }} @@ -326,11 +322,7 @@ jobs: uses: ./.github/workflows/build-windows.yml with: platform: windows-aarch64 -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) msvc-toolset-version: '14.44' -======= - msvc-toolset-version: '14.43' ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) msvc-toolset-architecture: 'arm64' make-target: 'hotspot' extra-conf-options: '--openjdk-target=aarch64-unknown-cygwin' @@ -369,17 +361,17 @@ jobs: runs-on: ubuntu-22.04 debug-suffix: -debug - test-linux-x64-static: - name: linux-x64-static - needs: - - build-linux-x64 - - build-linux-x64-static - uses: ./.github/workflows/test.yml - with: - platform: linux-x64 - bootjdk-platform: linux-x64 - runs-on: ubuntu-22.04 - static-suffix: "-static" +# test-linux-x64-static: +# name: linux-x64-static +# needs: +# - build-linux-x64 +# - build-linux-x64-static +# uses: ./.github/workflows/test.yml +# with: +# platform: linux-x64 +# bootjdk-platform: linux-x64 +# runs-on: ubuntu-22.04 +# static-suffix: "-static" test-macos-aarch64: name: macos-aarch64 @@ -402,7 +394,4 @@ jobs: platform: windows-x64 bootjdk-platform: windows-x64 runs-on: windows-2025 -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) -======= debug-suffix: -debug ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml remerge CONFLICT (content): Merge conflict in .github/workflows/test.yml index 9b48eced764..52cb4ea0755 100644 --- a/.github/workflows/test.yml +++ b/.github/workflows/test.yml @@ -207,13 +207,9 @@ jobs: JDK_IMAGE_DIR=${{ steps.bundles.outputs.jdk-path }} SYMBOLS_IMAGE_DIR=${{ steps.bundles.outputs.symbols-path }} TEST_IMAGE_DIR=${{ steps.bundles.outputs.tests-path }} -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) - JTREG="JAVA_OPTIONS=$JAVA_OPTIONS;VERBOSE=fail,error,time;KEYWORDS=!headful" -======= ${{ steps.extra-options.outputs.test-jdk }} ${{ steps.extra-options.outputs.compile-jdk }} - JTREG='JAVA_OPTIONS=-XX:-CreateCoredumpOnCrash;VERBOSE=fail,error,time;KEYWORDS=!headful;${{ steps.extra-options.outputs.extra-problem-lists }}' ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) + JTREG="JAVA_OPTIONS=$JAVA_OPTIONS;VERBOSE=fail,error,time;KEYWORDS=!headful;${{ steps.extra-options.outputs.extra-problem-lists }}" && bash ./.github/scripts/gen-test-summary.sh "$GITHUB_STEP_SUMMARY" "$GITHUB_OUTPUT" env: PATH: ${{ steps.path.outputs.value }} diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp b/src/hotspot/cpu/x86/vm_version_x86.cpp remerge CONFLICT (content): Merge conflict in src/hotspot/cpu/x86/vm_version_x86.cpp index 26e1c363c9c..7747dfdd488 100644 --- a/src/hotspot/cpu/x86/vm_version_x86.cpp +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp @@ -105,7 +105,6 @@ bool VM_Version::supports_clflush() { // up. Assembler::flush calls this routine to check that clflush // is allowed. So, we give the caller a free pass if Universe init // is still in progress. -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) if (!Universe::is_fully_initialized()) { return true; } @@ -117,10 +116,6 @@ bool VM_Version::supports_clflush() { } vm_exit_during_initialization(err_msg("-XX:CPUFeatures option requires FLUSH flag to be set: 0x%llx", 1ULL << CPU_FLUSH)); return false; -======= - assert ((!Universe::is_fully_initialized() || _features.supports_feature(CPU_FLUSH)), "clflush should be available"); - return true; ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) } #define CPUID_STANDARD_FN 0x0 @@ -1296,7 +1291,6 @@ void VM_Version::get_processor_features_hardware() { _cpu = 4; // 486 by default _model = 0; _stepping = 0; -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) #if 0 FIXME:CPUFeatures1 _features = 0; @@ -1306,8 +1300,6 @@ FIXME:CPUFeatures2 FIXME:CPUFeatures3 #endif //FIXME:CPUFeatures4 -======= ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) _logical_processors_per_package = 1; // i486 internal cache is both I&D and has a 16-byte line size _L1_data_cache_line_size = 16; @@ -1323,7 +1315,6 @@ FIXME:CPUFeatures3 if (cpu_family() > 4) { // it supports CPUID _features = _cpuid_info.feature_flags(); // These can be changed by VM settings -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) #if 0 FIXME:CPUFeatures1 _cpu_features = _features; // Preserve features @@ -1334,9 +1325,6 @@ FIXME:CPUFeatures3 #endif _cpu_features = _features; // Preserve features //FIXME:CPUFeatures4 -======= - _cpu_features = _features; // Preserve features ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) // Logical processors are only available on P4s and above, // and only if hyperthreading is available. _logical_processors_per_package = logical_processor_count(); @@ -1588,7 +1576,6 @@ void VM_Version::get_processor_features_hotspot() { cpu_family(), _model, _stepping, os::cpu_microcode_revision()); assert(cpu_info_size > 0, "not enough temporary space allocated"); -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) #if 0 FIXME:CPUFeatures1 insert_features_names(buf + cpu_info_size, sizeof(buf) - cpu_info_size); @@ -1599,10 +1586,6 @@ FIXME:CPUFeatures3 insert_features_names(_features, buf + cpu_info_size, sizeof(buf) - cpu_info_size); //FIXME:CPUFeatures4 -======= - - insert_features_names(_features, buf + cpu_info_size, sizeof(buf) - cpu_info_size); ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) _cpu_info_string = os::strdup(buf); diff --git a/src/hotspot/cpu/x86/vm_version_x86.hpp b/src/hotspot/cpu/x86/vm_version_x86.hpp remerge CONFLICT (content): Merge conflict in src/hotspot/cpu/x86/vm_version_x86.hpp index a6cf4db1bdd..5df066432de 100644 --- a/src/hotspot/cpu/x86/vm_version_x86.hpp +++ b/src/hotspot/cpu/x86/vm_version_x86.hpp @@ -451,7 +451,6 @@ class VM_Version : public Abstract_VM_Version { #define DECLARE_CPU_FEATURE_FLAG(id, name, bit) CPU_##id = (bit), CPU_FEATURE_FLAGS(DECLARE_CPU_FEATURE_FLAG) #undef DECLARE_CPU_FEATURE_FLAG -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) #if 0 FIXME:CPUFeatures1 MAX_CPU = CPU_SHA512 << 1 @@ -492,11 +491,6 @@ FIXME:CPUFeatures1 FIXME:CPUFeatures2 FIXME:CPUFeatures3 #endif -======= - MAX_CPU_FEATURES - }; - ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) class VM_Features { friend class VMStructs; friend class JVMCIVMStructs; @@ -559,10 +553,7 @@ FIXME:CPUFeatures3 // Original CPU feature flags vector, not affected by VM settings. static VM_Features _cpu_features; -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) //FIXME:CPUFeatures4 -======= ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) static const char* _features_names[]; static const char* _glibc_features_names[]; @@ -571,11 +562,6 @@ FIXME:CPUFeatures3 _cpu_features = VM_Features(); } - static void clear_cpu_features() { - _features = VM_Features(); - _cpu_features = VM_Features(); - } - enum Extended_Family { // AMD CPU_FAMILY_AMD_11H = 0x11, @@ -718,7 +704,6 @@ FIXME:CPUFeatures3 jlong apx_save[2]; // Save r16 and r31 VM_Features feature_flags() const; -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) #if 0 FIXME:CPUFeatures1 @@ -747,8 +732,6 @@ FIXME:CPUFeatures1 uint64_t glibc_flags() const { return 0; } #endif //LINUX #endif -======= ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) // Asserts void assert_is_initialized() const { diff --git a/src/hotspot/share/gc/g1/g1CollectedHeap.cpp b/src/hotspot/share/gc/g1/g1CollectedHeap.cpp remerge CONFLICT (content): Merge conflict in src/hotspot/share/gc/g1/g1CollectedHeap.cpp index bb735a6b149..258ccba3331 100644 --- a/src/hotspot/share/gc/g1/g1CollectedHeap.cpp +++ b/src/hotspot/share/gc/g1/g1CollectedHeap.cpp @@ -792,17 +792,12 @@ void G1CollectedHeap::prepare_for_mutator_after_full_collection(size_t allocatio assert(num_free_regions() == 0, "we should not have added any free regions"); rebuild_region_sets(false /* free_list_only */); abort_refinement(); -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) - resize_heap_if_necessary(); + resize_heap_if_necessary(allocation_word_size); if (should_cleanup_unused()) { cleanup_unused_regions(); // Includes uncommitting } else { uncommit_regions_if_necessary(); } -======= - resize_heap_if_necessary(allocation_word_size); - uncommit_regions_if_necessary(); ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) // Rebuild the code root lists for each region rebuild_code_roots(); diff --git a/src/hotspot/share/gc/g1/g1HeapRegionManager.cpp b/src/hotspot/share/gc/g1/g1HeapRegionManager.cpp remerge CONFLICT (content): Merge conflict in src/hotspot/share/gc/g1/g1HeapRegionManager.cpp index 1148b063eca..49c79098eba 100644 --- a/src/hotspot/share/gc/g1/g1HeapRegionManager.cpp +++ b/src/hotspot/share/gc/g1/g1HeapRegionManager.cpp @@ -419,12 +419,11 @@ bool G1HeapRegionManager::expand_exact(uint start, uint num_regions, WorkerThrea uint G1HeapRegionManager::expand_on_preferred_node(uint preferred_index) { uint expand_candidate = UINT_MAX; -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) - if (available() >= 1) { + if (num_inactive_regions() >= 1) { if (_committed_map.num_active() + _committed_map.num_inactive() >= _max_available_regions) { // We have to use existing inactive region, cannot allocate new one // while we have inactive. - for (uint i = 0; i < reserved_length(); i++) { + for (uint i = 0; i < max_num_regions(); i++) { if (!_committed_map.inactive(i)) { continue; } @@ -433,17 +432,10 @@ uint G1HeapRegionManager::expand_on_preferred_node(uint preferred_index) { // We have found a candidate on the preferred node, break. break; } -======= - if (num_inactive_regions() >= 1) { - for (uint i = 0; i < max_num_regions(); i++) { - if (is_available(i)) { - // Already in use continue - continue; ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) } } if (expand_candidate == UINT_MAX) { - for (uint i = 0; i < reserved_length(); i++) { + for (uint i = 0; i < max_num_regions(); i++) { if (is_available(i)) { // Already in use continue continue; diff --git a/src/hotspot/share/gc/g1/g1HeapRegionManager.hpp b/src/hotspot/share/gc/g1/g1HeapRegionManager.hpp remerge CONFLICT (content): Merge conflict in src/hotspot/share/gc/g1/g1HeapRegionManager.hpp index 6a9884218d2..4e12dc57dc3 100644 --- a/src/hotspot/share/gc/g1/g1HeapRegionManager.hpp +++ b/src/hotspot/share/gc/g1/g1HeapRegionManager.hpp @@ -231,13 +231,8 @@ class G1HeapRegionManager: public CHeapObj { return num_free_regions() * G1HeapRegion::GrainBytes; } -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) - // Return the number of regions available (uncommitted) regions. - uint available() const { return _max_available_regions - length(); } -======= // Return the number of regions uncommitted or ready to be uncommitted. - uint num_inactive_regions() const { return max_num_regions() - num_committed_regions(); } ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) + uint num_inactive_regions() const { return _max_available_regions - num_committed_regions(); } // Return the number of regions currently active and available for use. uint num_committed_regions() const { return _committed_map.num_active(); } diff --git a/src/hotspot/share/gc/z/zPageAllocator.cpp b/src/hotspot/share/gc/z/zPageAllocator.cpp remerge CONFLICT (content): Merge conflict in src/hotspot/share/gc/z/zPageAllocator.cpp index 0ce3e0933cb..558facaabd2 100644 --- a/src/hotspot/share/gc/z/zPageAllocator.cpp +++ b/src/hotspot/share/gc/z/zPageAllocator.cpp @@ -756,89 +756,17 @@ bool ZPartition::claim_capacity(ZMemoryAllocation* allocation) { return true; } -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) -size_t ZPartition::uncommit(uint64_t* timeout, uintx delay) { - ZArray flushed_vmems; - size_t flushed = 0; -======= bool ZPartition::claim_capacity_fast_medium(ZMemoryAllocation* allocation) { precond(ZPageSizeMediumEnabled); ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) // Try to allocate a medium page sized contiguous vmem const size_t min_size = ZPageSizeMediumMin; const size_t max_size = ZStressFastMediumPageAllocation ? min_size : ZPageSizeMediumMax; ZVirtualMemory vmem = _cache.remove_contiguous_power_of_2(min_size, max_size); -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) - const double now = os::elapsedTime(); - const double time_since_last_commit = std::floor(now - _last_commit); - const double time_since_last_uncommit = std::floor(now - _last_uncommit); - - if (time_since_last_commit < double(delay)) { - // We have committed within the delay, stop uncommitting. - *timeout = uint64_t(double(delay) - time_since_last_commit); - return 0; - } - - // We flush out and uncommit chunks at a time (~0.8% of the max capacity, - // but at least one granule and at most 256M), in case demand for memory - // increases while we are uncommitting. - const size_t limit_upper_bound = MAX2(ZGranuleSize, align_down(256 * M / ZNUMA::count(), ZGranuleSize)); - const size_t limit = MIN2(align_up(_current_max_capacity >> 7, ZGranuleSize), limit_upper_bound); - - if (limit == 0) { - // This may occur if the current max capacity for this partition is 0 - - // Set timeout to delay - *timeout = delay; - return 0; - } - - if (time_since_last_uncommit < double(delay)) { - // We are in the uncommit phase - const size_t num_uncommits_left = _to_uncommit / limit; - const double time_left = double(delay) - time_since_last_uncommit; - if (time_left < *timeout * num_uncommits_left) { - // Running out of time, speed up. - uint64_t new_timeout = uint64_t(std::floor(time_left / double(num_uncommits_left + 1))); - *timeout = new_timeout; - } - } else { - // We are about to start uncommitting - _to_uncommit = _cache.reset_min(); - _last_uncommit = now; - - const size_t split = _to_uncommit / limit + 1; - uint64_t new_timeout = delay / split; - *timeout = new_timeout; - } - - // Never uncommit below min capacity. - const size_t retain = MAX2(_used, _min_capacity); - const size_t release = _capacity - retain; - const size_t flush = MIN3(release, limit, _to_uncommit); - - if (flush == 0) { - // Nothing to flush - return 0; - } - - // Flush memory from the mapped cache to uncommit - flushed = _cache.remove_from_min(flush, &flushed_vmems); - if (flushed == 0) { - // Nothing flushed - return 0; - } - - // Record flushed memory as claimed and how much we've flushed for this partition - Atomic::add(&_claimed, flushed); - _to_uncommit -= flushed; -======= if (vmem.is_null()) { // Failed to find a contiguous vmem return false; ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) } // Found a satisfying vmem in the cache @@ -2515,20 +2443,9 @@ void ZPageAllocator::print_cache_extended_on(outputStream* st) const { } void ZPageAllocator::uncommit_unused_memory() { - uint64_t timeout; - size_t flushed, uncommitted = 0; ZPartitionIterator iter = partition_iterator(); for (ZPartition* partition; iter.next(&partition);) { - partition->_cache.reset_min(); - do { - flushed = partition->uncommit(&timeout, 0); - uncommitted += flushed; - } while (flushed > 0); - } - if (uncommitted > 0) { - EventZUncommit event; - log_info(gc, heap)("Uncommitted (cleanup): %zuM(%.0f%%)", - uncommitted / M, percent_of(uncommitted, ZHeap::heap()->max_capacity())); - event.commit(uncommitted); + partition->_cache.reset_min_size_watermark(); + partition->_uncommitter.force_uncommit(); } } diff --git a/src/hotspot/share/gc/z/zPageAllocator.hpp b/src/hotspot/share/gc/z/zPageAllocator.hpp remerge CONFLICT (content): Merge conflict in src/hotspot/share/gc/z/zPageAllocator.hpp index 1b3f00b857d..a6e2f055cbe 100644 --- a/src/hotspot/share/gc/z/zPageAllocator.hpp +++ b/src/hotspot/share/gc/z/zPageAllocator.hpp @@ -99,12 +99,7 @@ class ZPartition { void claim_from_cache_or_increase_capacity(ZMemoryAllocation* allocation); bool claim_capacity(ZMemoryAllocation* allocation); -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) - - size_t uncommit(uint64_t* timeout, uintx delay); -======= bool claim_capacity_fast_medium(ZMemoryAllocation* allocation); ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) void sort_segments_physical(const ZVirtualMemory& vmem); diff --git a/src/hotspot/share/gc/z/zUncommitter.cpp b/src/hotspot/share/gc/z/zUncommitter.cpp remerge CONFLICT (content): Merge conflict in src/hotspot/share/gc/z/zUncommitter.cpp index 961e275fafa..ec952ce34ea 100644 --- a/src/hotspot/share/gc/z/zUncommitter.cpp +++ b/src/hotspot/share/gc/z/zUncommitter.cpp @@ -50,7 +50,9 @@ ZUncommitter::ZUncommitter(uint32_t id, ZPartition* partition) _next_uncommit_timeout(0), _cycle_start(0.0), _to_uncommit(0), - _uncommitted(0) { + _uncommitted(0), + _force_uncommit(false), + _force_uncommit_lock() { set_name("ZUncommitter#%u", id); create_and_start(); } @@ -61,7 +63,7 @@ bool ZUncommitter::wait(uint64_t timeout) const { _lock.wait(); } - if (!_stop && timeout > 0) { + if (!_stop && timeout > 0 && !_force_uncommit) { if (!uncommit_cycle_is_finished()) { log_trace(gc, heap)("Uncommitter (%u) Timeout: " UINT64_FORMAT "ms left to uncommit: " EXACTFMT, _id, timeout, EXACTFMTARGS(_to_uncommit)); @@ -80,9 +82,8 @@ bool ZUncommitter::wait(uint64_t timeout) const { // Wait _lock.wait(remaining_timeout_ms); - now = os::elapsedTime(); - } while (!_stop && now < wait_until); + } while (!_stop && now < wait_until && !_force_uncommit); } return !_stop; @@ -123,10 +124,6 @@ void ZUncommitter::run_thread() { while (should_continue()) { // Uncommit chunk -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) - const size_t uncommitted = _partition->uncommit(&timeout, ZUncommitDelay); - if (uncommitted == 0) { -======= const size_t uncommitted = uncommit(); // Update uncommitted counter @@ -135,7 +132,6 @@ void ZUncommitter::run_thread() { // 'uncommitted == 0' is a proxy for uncommit_cycle_is_canceled() without // having to take the page allocator lock if (uncommitted == 0 || uncommit_cycle_is_finished()) { ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) // Done break; } @@ -203,6 +199,10 @@ void ZUncommitter::deactivate_uncommit_cycle() { update_next_cycle_timeout_on_finish(); } + if (uncommit_cycle_is_finished()) { + finish_force_uncommit(); + } + // Reset the cycle reset_uncommit_cycle(); } @@ -428,3 +428,28 @@ size_t ZUncommitter::uncommit() { return flushed; } + +void ZUncommitter::force_uncommit() { + { + ZLocker locker(&_lock); + _force_uncommit = true; + _lock.notify_all(); + } + + wait_for_finish_force_uncommit(); +} + +void ZUncommitter::wait_for_finish_force_uncommit() { + ZLocker locker(&_force_uncommit_lock); + while (_force_uncommit) { + _force_uncommit_lock.wait(); + } +} + +void ZUncommitter::finish_force_uncommit() { + if (_force_uncommit) { + ZLocker locker(&_force_uncommit_lock); + _force_uncommit = false; + _force_uncommit_lock.notify_all(); + } +} diff --git a/src/hotspot/share/gc/z/zUncommitter.hpp b/src/hotspot/share/gc/z/zUncommitter.hpp index a3cd2b17e23..1c2fd3213ea 100644 --- a/src/hotspot/share/gc/z/zUncommitter.hpp +++ b/src/hotspot/share/gc/z/zUncommitter.hpp @@ -42,6 +42,8 @@ class ZUncommitter : public ZThread { double _cycle_start; size_t _to_uncommit; size_t _uncommitted; + bool _force_uncommit; + mutable ZConditionLock _force_uncommit_lock; bool wait(uint64_t timeout) const; bool should_continue() const; @@ -65,6 +67,9 @@ class ZUncommitter : public ZThread { void update_statistics(size_t uncommitted, Ticks start, Tickspan* accumulated_time) const; + void wait_for_finish_force_uncommit(); + void finish_force_uncommit(); + protected: virtual void run_thread(); virtual void terminate(); @@ -73,6 +78,8 @@ class ZUncommitter : public ZThread { ZUncommitter(uint32_t id, ZPartition* partition); void cancel_uncommit_cycle(); + + void force_uncommit(); }; #endif // SHARE_GC_Z_ZUNCOMMITTER_HPP diff --git a/src/hotspot/share/jfr/jfr.cpp b/src/hotspot/share/jfr/jfr.cpp remerge CONFLICT (content): Merge conflict in src/hotspot/share/jfr/jfr.cpp index dd9f2d07078..99c151af740 100644 --- a/src/hotspot/share/jfr/jfr.cpp +++ b/src/hotspot/share/jfr/jfr.cpp @@ -37,15 +37,12 @@ #include "jfr/support/jfrKlassExtension.hpp" #include "jfr/support/jfrResolution.hpp" #include "jfr/support/jfrThreadLocal.hpp" -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) #include "memory/resourceArea.hpp" #include "runtime/flags/jvmFlag.hpp" -======= #include "jfr/support/methodtracer/jfrMethodTracer.hpp" #include "oops/instanceKlass.hpp" #include "oops/instanceKlass.inline.hpp" #include "oops/klass.hpp" ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) #include "runtime/java.hpp" #include "runtime/javaThread.hpp" diff --git a/src/hotspot/share/jfr/jfr.hpp b/src/hotspot/share/jfr/jfr.hpp remerge CONFLICT (content): Merge conflict in src/hotspot/share/jfr/jfr.hpp index df2d24c92a6..26dfc51445e 100644 --- a/src/hotspot/share/jfr/jfr.hpp +++ b/src/hotspot/share/jfr/jfr.hpp @@ -76,13 +76,10 @@ class Jfr : AllStatic { static bool on_start_flight_recording_option(const JavaVMOption** option, char* delimiter); static void on_backpatching(const Method* callee_method, JavaThread* jt); static void initialize_main_thread(JavaThread* jt); -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) static void before_checkpoint(); static void after_restore(); -======= static bool has_sample_request(JavaThread* jt); static void check_and_process_sample_request(JavaThread* jt); ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) }; #endif // SHARE_JFR_JFR_HPP diff --git a/src/hotspot/share/jfr/jni/jfrJniMethodRegistration.cpp b/src/hotspot/share/jfr/jni/jfrJniMethodRegistration.cpp remerge CONFLICT (content): Merge conflict in src/hotspot/share/jfr/jni/jfrJniMethodRegistration.cpp index f5c56e0ad26..67c0a6615e0 100644 --- a/src/hotspot/share/jfr/jni/jfrJniMethodRegistration.cpp +++ b/src/hotspot/share/jfr/jni/jfrJniMethodRegistration.cpp @@ -102,14 +102,10 @@ JfrJniMethodRegistration::JfrJniMethodRegistration(JNIEnv* env) { (char*)"registerStackFilter", (char*)"([Ljava/lang/String;[Ljava/lang/String;)J", (void*)jfr_register_stack_filter, (char*)"unregisterStackFilter", (char*)"(J)V", (void*)jfr_unregister_stack_filter, (char*)"nanosNow", (char*)"()J", (void*)jfr_nanos_now, -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) (char*)"startFlightRecorderAfterRestore", (char*)"()V", (void*)jfr_start_after_restore, - (char*)"isProduct", (char*)"()Z", (void*)jfr_is_product -======= (char*)"isProduct", (char*)"()Z", (void*)jfr_is_product, (char*)"setMethodTraceFilters", (char*)"([Ljava/lang/String;[Ljava/lang/String;[Ljava/lang/String;[I)[J", (void*)jfr_set_method_trace_filters, (char*)"drainStaleMethodTracerIds", (char*)"()[J", (void*)jfr_drain_stale_method_tracer_ids ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) }; const size_t method_array_length = sizeof(method) / sizeof(JNINativeMethod); diff --git a/src/hotspot/share/jfr/jni/jfrUpcalls.cpp b/src/hotspot/share/jfr/jni/jfrUpcalls.cpp remerge CONFLICT (content): Merge conflict in src/hotspot/share/jfr/jni/jfrUpcalls.cpp index af81264f6ab..75a30d3ecd4 100644 --- a/src/hotspot/share/jfr/jni/jfrUpcalls.cpp +++ b/src/hotspot/share/jfr/jni/jfrUpcalls.cpp @@ -53,15 +53,12 @@ static Symbol* bytes_for_eager_instrumentation_sym = nullptr; static Symbol* bytes_for_eager_instrumentation_sig_sym = nullptr; static Symbol* unhide_internal_types_sym = nullptr; static Symbol* unhide_internal_types_sig_sym = nullptr; -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) static Symbol* request_start_after_restore_sym = nullptr; static Symbol* request_start_after_restore_sig_sym = nullptr; -======= static Symbol* on_method_trace_sym = nullptr; static Symbol* on_method_trace_sig_sym = nullptr; static Symbol* publish_method_timers_for_klass_sym = nullptr; static Symbol* publish_method_timers_for_klass_sig_sym = nullptr; ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) static bool initialize(TRAPS) { static bool initialized = false; @@ -74,17 +71,14 @@ static bool initialize(TRAPS) { bytes_for_eager_instrumentation_sig_sym = SymbolTable::new_permanent_symbol("(JZZLjava/lang/Class;[B)[B"); unhide_internal_types_sym = SymbolTable::new_permanent_symbol("unhideInternalTypes"); unhide_internal_types_sig_sym = SymbolTable::new_permanent_symbol("()V"); -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) request_start_after_restore_sym = SymbolTable::new_permanent_symbol("requestStartAfterRestore"); request_start_after_restore_sig_sym = SymbolTable::new_permanent_symbol("()V"); initialized = unhide_internal_types_sig_sym != nullptr; -======= on_method_trace_sym = SymbolTable::new_permanent_symbol("onMethodTrace"); on_method_trace_sig_sym = SymbolTable::new_permanent_symbol("(Ljava/lang/Module;Ljava/lang/ClassLoader;Ljava/lang/String;[B[J[Ljava/lang/String;[Ljava/lang/String;[I)[B"); publish_method_timers_for_klass_sym = SymbolTable::new_permanent_symbol("publishMethodTimersForClass"); publish_method_timers_for_klass_sig_sym = SymbolTable::new_permanent_symbol("(J)V"); initialized = publish_method_timers_for_klass_sig_sym != nullptr; ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) } return initialized; } @@ -233,7 +227,6 @@ bool JfrUpcalls::unhide_internal_types(TRAPS) { return true; } -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) void JfrUpcalls::request_start_after_restore() { JavaThread * const THREAD = JavaThread::current(); DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_vm(THREAD)); @@ -258,7 +251,8 @@ void JfrUpcalls::request_start_after_restore() { ResourceMark rm(THREAD); log_error(jfr, system)("JfrUpcall failed for %s", request_start_after_restore_sym->as_C_string()); } -======= +} + // Caller needs ResourceMark ClassFileStream* JfrUpcalls::on_method_trace(InstanceKlass* ik, const ClassFileStream* stream, GrowableArray* methods, TRAPS) { DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_vm(THREAD)); @@ -357,5 +351,4 @@ void JfrUpcalls::publish_method_timers_for_klass(traceid klass_id, TRAPS) { JavaValue result(T_VOID); args.push_long(static_cast(klass_id)); JavaCalls::call_static(&result, klass, publish_method_timers_for_klass_sym, publish_method_timers_for_klass_sig_sym, &args, CHECK); ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) } diff --git a/src/java.base/share/classes/java/net/InetAddress.java b/src/java.base/share/classes/java/net/InetAddress.java remerge CONFLICT (content): Merge conflict in src/java.base/share/classes/java/net/InetAddress.java index 9f31500c1af..c06121d4f5d 100644 --- a/src/java.base/share/classes/java/net/InetAddress.java +++ b/src/java.base/share/classes/java/net/InetAddress.java @@ -54,12 +54,9 @@ import java.util.concurrent.locks.ReentrantLock; import java.util.stream.Stream; -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) import jdk.internal.crac.mirror.Context; import jdk.internal.crac.mirror.Resource; -======= import jdk.internal.util.Exceptions; ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) import jdk.internal.access.JavaNetInetAddressAccess; import jdk.internal.access.SharedSecrets; import jdk.internal.crac.Core; diff --git a/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/amd64/AMD64HotSpotJVMCIBackendFactory.java b/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/amd64/AMD64HotSpotJVMCIBackendFactory.java remerge CONFLICT (content): Merge conflict in src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/amd64/AMD64HotSpotJVMCIBackendFactory.java index 58ddca49e47..040f39e3b8a 100644 --- a/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/amd64/AMD64HotSpotJVMCIBackendFactory.java +++ b/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/amd64/AMD64HotSpotJVMCIBackendFactory.java @@ -49,23 +49,14 @@ private static EnumSet computeFeatures(AMD64HotSpotVMConfig config) // Configure the feature set using the HotSpot flag settings. Map constants = config.getStore().getConstants(); Map renaming = Map.of("3DNOW_PREFETCH", "AMD_3DNOW_PREFETCH"); -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) - assert config.useSSE >= 2 : "minimum config for x64"; -======= ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) long featuresBitMapAddress = config.vmVersionFeatures + config.vmFeaturesFeaturesOffset; EnumSet features = HotSpotJVMCIBackendFactory.convertFeatures(CPUFeature.class, constants, featuresBitMapAddress, config.vmFeaturesFeaturesSize, renaming); -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) - features.add(AMD64.CPUFeature.SSE); - features.add(AMD64.CPUFeature.SSE2); -======= assert features.contains(AMD64.CPUFeature.SSE) : "minimum config for x64"; assert features.contains(AMD64.CPUFeature.SSE2) : "minimum config for x64"; ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) return features; } diff --git a/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/amd64/AMD64HotSpotVMConfig.java b/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/amd64/AMD64HotSpotVMConfig.java remerge CONFLICT (content): Merge conflict in src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/amd64/AMD64HotSpotVMConfig.java index aad0441e4fc..1b3a46fc8d7 100644 --- a/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/amd64/AMD64HotSpotVMConfig.java +++ b/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/amd64/AMD64HotSpotVMConfig.java @@ -35,61 +35,7 @@ class AMD64HotSpotVMConfig extends HotSpotVMConfigAccess { } final boolean useCompressedOops = getFlag("UseCompressedOops", Boolean.class); -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) - - final long vmVersionFeatures = getFieldAddress("VM_Version::_features", "VM_Version::VM_Features"); - final long vmFeaturesFeaturesOffset = getFieldOffset("VM_Version::VM_Features::_features_bitmap[0]", Long.class, "uint64_t"); - final long vmFeaturesFeaturesSize = getFieldValue("VM_Version::VM_Features::_features_bitmap_size", Long.class, "int"); - - // CPU capabilities - final int useSSE = getFlag("UseSSE", Integer.class); - final int useAVX = getFlag("UseAVX", Integer.class); - - // CPU feature flags - final long amd64CX8 = getConstant("VM_Version::CPU_CX8", Long.class); - final long amd64CMOV = getConstant("VM_Version::CPU_CMOV", Long.class); - final long amd64FXSR = getConstant("VM_Version::CPU_FXSR", Long.class); - final long amd64HT = getConstant("VM_Version::CPU_HT", Long.class); - final long amd64MMX = getConstant("VM_Version::CPU_MMX", Long.class); - final long amd643DNOWPREFETCH = getConstant("VM_Version::CPU_3DNOW_PREFETCH", Long.class); - final long amd64SSE = getConstant("VM_Version::CPU_SSE", Long.class); - final long amd64SSE2 = getConstant("VM_Version::CPU_SSE2", Long.class); - final long amd64SSE3 = getConstant("VM_Version::CPU_SSE3", Long.class); - final long amd64SSSE3 = getConstant("VM_Version::CPU_SSSE3", Long.class); - final long amd64SSE4A = getConstant("VM_Version::CPU_SSE4A", Long.class); - final long amd64SSE41 = getConstant("VM_Version::CPU_SSE4_1", Long.class); - final long amd64SSE42 = getConstant("VM_Version::CPU_SSE4_2", Long.class); - final long amd64POPCNT = getConstant("VM_Version::CPU_POPCNT", Long.class); - final long amd64LZCNT = getConstant("VM_Version::CPU_LZCNT", Long.class); - final long amd64TSC = getConstant("VM_Version::CPU_TSC", Long.class); - final long amd64TSCINV = getConstant("VM_Version::CPU_TSCINV", Long.class); - final long amd64AVX = getConstant("VM_Version::CPU_AVX", Long.class); - final long amd64AVX2 = getConstant("VM_Version::CPU_AVX2", Long.class); - final long amd64AES = getConstant("VM_Version::CPU_AES", Long.class); - final long amd64ERMS = getConstant("VM_Version::CPU_ERMS", Long.class); - final long amd64CLMUL = getConstant("VM_Version::CPU_CLMUL", Long.class); - final long amd64BMI1 = getConstant("VM_Version::CPU_BMI1", Long.class); - final long amd64BMI2 = getConstant("VM_Version::CPU_BMI2", Long.class); - final long amd64RTM = getConstant("VM_Version::CPU_RTM", Long.class); - final long amd64ADX = getConstant("VM_Version::CPU_ADX", Long.class); - final long amd64AVX512F = getConstant("VM_Version::CPU_AVX512F", Long.class); - final long amd64AVX512DQ = getConstant("VM_Version::CPU_AVX512DQ", Long.class); - final long amd64AVX512PF = getConstant("VM_Version::CPU_AVX512PF", Long.class); - final long amd64AVX512ER = getConstant("VM_Version::CPU_AVX512ER", Long.class); - final long amd64AVX512CD = getConstant("VM_Version::CPU_AVX512CD", Long.class); - final long amd64AVX512BW = getConstant("VM_Version::CPU_AVX512BW", Long.class); - final long amd64AVX512VL = getConstant("VM_Version::CPU_AVX512VL", Long.class); - final long amd64SHA = getConstant("VM_Version::CPU_SHA", Long.class); - final long amd64FMA = getConstant("VM_Version::CPU_FMA", Long.class); - final long amd64PKU = getConstant("VM_Version::CPU_PKU", Long.class); - final long amd64OSPKE = getConstant("VM_Version::CPU_OSPKE", Long.class); - final long amd64CET_IBT = getConstant("VM_Version::CPU_CET_IBT", Long.class); - final long amd64CET_SS = getConstant("VM_Version::CPU_CET_SS", Long.class); - final long amd64AVX10_1 = getConstant("VM_Version::CPU_AVX10_1", Long.class); - final long amd64AVX10_2 = getConstant("VM_Version::CPU_AVX10_2", Long.class); -======= final long vmVersionFeatures = getFieldAddress("VM_Version::_features", "VM_Version::VM_Features"); final long vmFeaturesFeaturesOffset = getFieldOffset("VM_Version::VM_Features::_features_bitmap[0]", Long.class, "uint64_t"); final long vmFeaturesFeaturesSize = getFieldValue("VM_Version::VM_Features::_features_bitmap_size", Long.class, "int"); ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) } diff --git a/src/jdk.jfr/share/classes/jdk/jfr/internal/JVMUpcalls.java b/src/jdk.jfr/share/classes/jdk/jfr/internal/JVMUpcalls.java remerge CONFLICT (content): Merge conflict in src/jdk.jfr/share/classes/jdk/jfr/internal/JVMUpcalls.java index 874b29e9880..ddf439066d3 100644 --- a/src/jdk.jfr/share/classes/jdk/jfr/internal/JVMUpcalls.java +++ b/src/jdk.jfr/share/classes/jdk/jfr/internal/JVMUpcalls.java @@ -25,11 +25,8 @@ package jdk.jfr.internal; import java.lang.reflect.Modifier; -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) import jdk.internal.crac.Core; -======= ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) import jdk.jfr.internal.event.EventConfiguration; import jdk.jfr.internal.util.Bytecode; import jdk.jfr.internal.util.Utils; @@ -167,12 +164,13 @@ static Thread createRecorderThread(ThreadGroup systemThreadGroup, ClassLoader co } /** -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) * Called by the JVM when it is restored with a new -XX:StartFlightRecorder */ static void requestStartAfterRestore() { Core.setStartFlightRecorder(JVM::startFlightRecorderAfterRestore); -======= + } + + /** * Called by the JVM to update method tracing instrumentation. *

* @param module the module the class belongs to @@ -201,6 +199,5 @@ public static byte[] onMethodTrace(Module module, ClassLoader classLoader, Strin */ public static void publishMethodTimersForClass(long classId) { PlatformTracer.publishClass(classId); ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) } } diff --git a/src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecorder.java b/src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecorder.java index 811c72be8c4..7c5190ca2eb 100644 --- a/src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecorder.java +++ b/src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecorder.java @@ -25,6 +25,7 @@ package jdk.jfr.internal; +import static jdk.jfr.internal.LogLevel.ERROR; import static jdk.jfr.internal.LogLevel.INFO; import static jdk.jfr.internal.LogLevel.TRACE; import static jdk.jfr.internal.LogLevel.WARN; diff --git a/test/hotspot/jtreg/ProblemList.txt b/test/hotspot/jtreg/ProblemList.txt remerge CONFLICT (content): Merge conflict in test/hotspot/jtreg/ProblemList.txt index 20bd09b4ce0..243723be61e 100644 --- a/test/hotspot/jtreg/ProblemList.txt +++ b/test/hotspot/jtreg/ProblemList.txt @@ -108,12 +108,9 @@ runtime/os/TestTracePageSizes.java#compiler-options 8267460 linux-aarch64 runtime/os/TestTracePageSizes.java#G1 8267460 linux-aarch64 runtime/os/TestTracePageSizes.java#Parallel 8267460 linux-aarch64 runtime/os/TestTracePageSizes.java#Serial 8267460 linux-aarch64 -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) runtime/ErrorHandling/CreateCoredumpOnCrash.java 8267433 macosx-x64 # JDK-8310862 was closed but we're still seeing errors with the updated test runtime/ClassInitErrors/TestStackOverflowDuringInit.java 8310862 generic-all -======= ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) runtime/StackGuardPages/TestStackGuardPagesNative.java 8303612 linux-all runtime/ErrorHandling/MachCodeFramesInErrorFile.java 8313315 linux-ppc64le runtime/NMT/VirtualAllocCommitMerge.java 8309698 linux-s390x

Notes about merge conflicts - `src/hotspot/share/gc/g1` - conflicts after renaming ([JDK-8357559](https://bugs.openjdk.org/browse/JDK-8357559)) and heap shrinking ([JDK-8355756](https://bugs.openjdk.org/browse/JDK-8355756)) - `src/hotspot/share/gc/z` - conflicts after cleanup ([JDK-8356716](https://bugs.openjdk.org/browse/JDK-8356716)), adding `ZUncommitter::force_uncommit` that is triggered at checkpoint - testing results look very similar, image size for example-spring-boot - before merge - G1 - 210-216MB ZGC - 277-282MB - after merge - G1 - 213-217MB ZGC - 281-292MB - `src/hotspot/share/jfr` - conflicts after [JDK-8352738](https://bugs.openjdk.org/browse/JDK-8352738) and [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251) - `src/jdk.internal.vm.ci` - conflicts after [JDK-8334717](https://bugs.openjdk.org/browse/JDK-8334717) - `.github/workflows` - [JDK-8355452](https://bugs.openjdk.org/browse/JDK-8355452) enabled testing on linux-x64 static-jdk. There are many failures in crac tests. Most of tests failed with `"Cannot find CRaC engine criuengine"` error but there might be other types of failures. I suggest fixing this separately. As part of this merge, I disabled running the tests on static-jdk. ------------- Commit messages: - Merge with jdk-25+26 - 8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual - 8337666: AArch64: SHA3 GPR intrinsic - 8358689: test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java does not build after JDK-8351594 - 8358633: Test ThreadPoolExecutorTest::testTimedInvokeAnyNullTimeUnit is broken by JDK-8347491 - 8358590: JFR: Include min and max in MethodTiming event - 8351594: JFR: Rate-limited sampling of Java events - 8349369: test/docs/jdk/javadoc/doccheck/checks/jdkCheckLinks.java did not report on missing man page files - 8356633: Incorrect use of {@link} in jdk.jshell - 8357962: JFR Cooperative Sampling reveals inconsistent interpreter frames as part of JVMTI PopFrame - ... and 536 more: https://git.openjdk.org/crac/compare/1846ced2...5035f463 The webrevs contain the adjustments done while merging with regards to each parent branch: - crac: https://webrevs.openjdk.org/?repo=crac&pr=248&range=00.0 - jdk:jdk-25+26: https://webrevs.openjdk.org/?repo=crac&pr=248&range=00.1 Changes: https://git.openjdk.org/crac/pull/248/files Stats: 167034 lines in 2901 files changed: 99490 ins; 45922 del; 21622 mod Patch: https://git.openjdk.org/crac/pull/248.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/248/head:pull/248 PR: https://git.openjdk.org/crac/pull/248 From tpushkin at openjdk.org Thu Jul 24 17:30:12 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Thu, 24 Jul 2025 17:30:12 GMT Subject: [crac] RFR: 8364078: [CRaC] CracTest mishandles NoSuchMethodException Message-ID: Fixes the issue by reducing the scope of the `NoSuchMethodException`'s try-catch statement. ------------- Commit messages: - Reduce try-catch scope Changes: https://git.openjdk.org/crac/pull/249/files Webrev: https://webrevs.openjdk.org/?repo=crac&pr=249&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364078 Stats: 62 lines in 1 file changed: 21 ins; 18 del; 23 mod Patch: https://git.openjdk.org/crac/pull/249.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/249/head:pull/249 PR: https://git.openjdk.org/crac/pull/249 From tpushkin at openjdk.org Thu Jul 24 19:19:28 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Thu, 24 Jul 2025 19:19:28 GMT Subject: [crac] RFR: Merge jdk:jdk-25+26 In-Reply-To: <8s5ymOREBNkrHIH_me6UxsNK6QjhJ9VsUPWPrYFNOIY=.74bc9410-d039-40ee-bc17-d5f1e3833ae2@github.com> References: <8s5ymOREBNkrHIH_me6UxsNK6QjhJ9VsUPWPrYFNOIY=.74bc9410-d039-40ee-bc17-d5f1e3833ae2@github.com> Message-ID: On Wed, 23 Jul 2025 17:58:09 GMT, Dmitry Cherepanov wrote: > Since the merge for [JDK-8352675](https://bugs.openjdk.org/browse/JDK-8352675) is split into a separate PR (https://github.com/openjdk/crac/pull/247), I cherry-picked the current version and merging other changes on top of it. It will likely require rebase on top of the final version later. > > Attaching output of `--diff-merges=remerge` > >
> > Conflicts > > > commit 5035f463900712ae47b7e1adfeff609bc1d66116 (HEAD -> merge-jdk, dmitry-crac/merge-jdk) > Merge: d61227fe01d c59e44a7aa2 > Author: Dmitry Cherepanov > Date: Tue Jul 22 13:30:47 2025 +0400 > > Merge with jdk-25+26 > > diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml > remerge CONFLICT (content): Merge conflict in .github/workflows/main.yml > index 8cf745c1cff..02c6f3d2668 100644 > --- a/.github/workflows/main.yml > +++ b/.github/workflows/main.yml > @@ -310,11 +310,7 @@ jobs: > uses: ./.github/workflows/build-windows.yml > with: > platform: windows-x64 > -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) > msvc-toolset-version: '14.44' > -======= > - msvc-toolset-version: '14.43' > ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) > msvc-toolset-architecture: 'x86.x64' > configure-arguments: ${{ github.event.inputs.configure-arguments }} > make-arguments: ${{ github.event.inputs.make-arguments }} > @@ -326,11 +322,7 @@ jobs: > uses: ./.github/workflows/build-windows.yml > with: > platform: windows-aarch64 > -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) > msvc-toolset-version: '14.44' > -======= > - msvc-toolset-version: '14.43' > ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) > msvc-toolset-architecture: 'arm64' > make-target: 'hotspot' > extra-conf-options: '--openjdk-target=aarch64-unknown-cygwin' > @@ -369,17 +361,17 @@ jobs: > runs-on: ubuntu-22.04 > debug-suffix: -debug > > - test-linux-x64-static: > - name: linux-x64-static > - needs: > - - build-linux-x64 > - - build-linux-x64-static > - uses: ./.github/workflows/test.yml > - with: > - platform: linux-x64 > - bootjdk-platform: linux-x64 > - runs-on: ubuntu-22.04 > - static-suffix: "-static" > +# test-linux-x64-static: > +# name: linux-x64-static > +# needs: > +# - build-linux-x64 > +# - build-lin... Have not finished the review yet, stopped on the JFR changes in the conflicts list, will continue tomorrow src/hotspot/share/gc/z/zUncommitter.cpp line 85: > 83: // Wait > 84: _lock.wait(remaining_timeout_ms); > 85: now = os::elapsedTime(); >From the conflict resolution: _lock.wait(remaining_timeout_ms); - now = os::elapsedTime(); Probably an accidental change. Better to stay closer to the mainline, i.e. retain the empty line src/hotspot/share/gc/z/zUncommitter.cpp line 435: > 433: { > 434: ZLocker locker(&_lock); > 435: _force_uncommit = true; Shouldn't all reads and writes to `_force_uncommit` be guarded by the same lock since it is done by different threads? Currently there are two different locks for writing and some reads are unguarded at all. I believe using `_lock` everywhere is fine: yes, waiting in `wait_for_finish_force_uncommit` will have more unneeded wake-ups but there probably won't be too many. src/hotspot/share/gc/z/zUncommitter.cpp line 444: > 442: void ZUncommitter::wait_for_finish_force_uncommit() { > 443: ZLocker locker(&_force_uncommit_lock); > 444: while (_force_uncommit) { Have not checked but I believe with `-XX:-ZUncommit` we will wait here forever since the uncommitting threads will be doing nothing src/hotspot/share/gc/z/zUncommitter.cpp line 447: > 445: _force_uncommit_lock.wait(); > 446: } > 447: } This method is used in just one place above, maybe inline it there? To me it would improve readability in this case (I initially assumed it is used somewhere else too). ------------- PR Review: https://git.openjdk.org/crac/pull/248#pullrequestreview-3052735414 PR Review Comment: https://git.openjdk.org/crac/pull/248#discussion_r2229235172 PR Review Comment: https://git.openjdk.org/crac/pull/248#discussion_r2229337886 PR Review Comment: https://git.openjdk.org/crac/pull/248#discussion_r2229317631 PR Review Comment: https://git.openjdk.org/crac/pull/248#discussion_r2229274620 From tpushkin at openjdk.org Thu Jul 24 19:19:28 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Thu, 24 Jul 2025 19:19:28 GMT Subject: [crac] RFR: Merge jdk:jdk-25+26 In-Reply-To: References: <8s5ymOREBNkrHIH_me6UxsNK6QjhJ9VsUPWPrYFNOIY=.74bc9410-d039-40ee-bc17-d5f1e3833ae2@github.com> Message-ID: <7YvFbPzjvdioz67YN1gyMIA7AHSyvDmkV4o8bI7Ojvw=.376d6d76-cfb3-4aa9-b6a9-c6c931538665@github.com> On Thu, 24 Jul 2025 18:56:13 GMT, Timofei Pushkin wrote: >> Since the merge for [JDK-8352675](https://bugs.openjdk.org/browse/JDK-8352675) is split into a separate PR (https://github.com/openjdk/crac/pull/247), I cherry-picked the current version and merging other changes on top of it. It will likely require rebase on top of the final version later. >> >> Attaching output of `--diff-merges=remerge` >> >>
>> >> Conflicts >> >> >> commit 5035f463900712ae47b7e1adfeff609bc1d66116 (HEAD -> merge-jdk, dmitry-crac/merge-jdk) >> Merge: d61227fe01d c59e44a7aa2 >> Author: Dmitry Cherepanov >> Date: Tue Jul 22 13:30:47 2025 +0400 >> >> Merge with jdk-25+26 >> >> diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml >> remerge CONFLICT (content): Merge conflict in .github/workflows/main.yml >> index 8cf745c1cff..02c6f3d2668 100644 >> --- a/.github/workflows/main.yml >> +++ b/.github/workflows/main.yml >> @@ -310,11 +310,7 @@ jobs: >> uses: ./.github/workflows/build-windows.yml >> with: >> platform: windows-x64 >> -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) >> msvc-toolset-version: '14.44' >> -======= >> - msvc-toolset-version: '14.43' >> ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) >> msvc-toolset-architecture: 'x86.x64' >> configure-arguments: ${{ github.event.inputs.configure-arguments }} >> make-arguments: ${{ github.event.inputs.make-arguments }} >> @@ -326,11 +322,7 @@ jobs: >> uses: ./.github/workflows/build-windows.yml >> with: >> platform: windows-aarch64 >> -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) >> msvc-toolset-version: '14.44' >> -======= >> - msvc-toolset-version: '14.43' >> ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) >> msvc-toolset-architecture: 'arm64' >> make-target: 'hotspot' >> extra-conf-options: '--openjdk-target=aarch64-unknown-cygwin' >> @@ -369,17 +361,17 @@ jobs: >> runs-on: ubuntu-22.04 >> debug-suffix: -debug >> >> - test-linux-x64-static: >> - name: linux-x64-static >> - needs: >> - - build-linux-x64 >> - - build-linux-x64-static >> - uses: ./.github/workflows/test.yml >> - with: >> - platform: linux-x64 >> - bootjdk-platform: linux-x64 >> - runs-on: ubuntu-22.04 >> - static-suffix: "-st... > > src/hotspot/share/gc/z/zUncommitter.cpp line 444: > >> 442: void ZUncommitter::wait_for_finish_force_uncommit() { >> 443: ZLocker locker(&_force_uncommit_lock); >> 444: while (_force_uncommit) { > > Have not checked but I believe with `-XX:-ZUncommit` we will wait here forever since the uncommitting threads will be doing nothing Also adding `&& !_stop` might be a good idea ------------- PR Review Comment: https://git.openjdk.org/crac/pull/248#discussion_r2229341182 From jkratochvil at openjdk.org Thu Jul 24 19:24:03 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Thu, 24 Jul 2025 19:24:03 GMT Subject: [crac] RFR: Fix up CPUFeatures on top of Merge jdk:jdk-25+26 Message-ID: This pull request contains: https://github.com/openjdk/crac/pull/248 I think the CRaC project does not provide the pr/NUMBER branches for dependent patches. This pull request enables the CPUFeatures again. ------------- Commit messages: - Merge branch 'avx-real' into dimitrycgit-merge-jdk-test - the real implementation - Merge branch 'avx' into avx-real - suspended - Merge branch 'avx' into dimitrycgit-merge-jdk-test - 8352675: Support Intel AVX10 converged vector ISA feature detection - Merge with jdk-25+26 - 8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual - 8337666: AArch64: SHA3 GPR intrinsic - 8358689: test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java does not build after JDK-8351594 - ... and 542 more: https://git.openjdk.org/crac/compare/1846ced2...ac87941d Changes: https://git.openjdk.org/crac/pull/250/files Webrev: https://webrevs.openjdk.org/?repo=crac&pr=250&range=00 Stats: 167422 lines in 2905 files changed: 99560 ins; 45992 del; 21870 mod Patch: https://git.openjdk.org/crac/pull/250.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/250/head:pull/250 PR: https://git.openjdk.org/crac/pull/250 From dcherepanov at openjdk.org Fri Jul 25 07:08:01 2025 From: dcherepanov at openjdk.org (Dmitry Cherepanov) Date: Fri, 25 Jul 2025 07:08:01 GMT Subject: [crac] RFR: Merge jdk:jdk-25+26 [v2] In-Reply-To: <8s5ymOREBNkrHIH_me6UxsNK6QjhJ9VsUPWPrYFNOIY=.74bc9410-d039-40ee-bc17-d5f1e3833ae2@github.com> References: <8s5ymOREBNkrHIH_me6UxsNK6QjhJ9VsUPWPrYFNOIY=.74bc9410-d039-40ee-bc17-d5f1e3833ae2@github.com> Message-ID: <8kXDTMFHjARFZBBREXJvwRdejvZtTiYi8RZhq9huIps=.7206f5b5-61f7-470a-b71a-6d1639115c97@github.com> > Since the merge for [JDK-8352675](https://bugs.openjdk.org/browse/JDK-8352675) is split into a separate PR (https://github.com/openjdk/crac/pull/247), I cherry-picked the current version and merging other changes on top of it. It will likely require rebase on top of the final version later. > > Attaching output of `--diff-merges=remerge` > >
> > Conflicts > > > commit 5035f463900712ae47b7e1adfeff609bc1d66116 (HEAD -> merge-jdk, dmitry-crac/merge-jdk) > Merge: d61227fe01d c59e44a7aa2 > Author: Dmitry Cherepanov > Date: Tue Jul 22 13:30:47 2025 +0400 > > Merge with jdk-25+26 > > diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml > remerge CONFLICT (content): Merge conflict in .github/workflows/main.yml > index 8cf745c1cff..02c6f3d2668 100644 > --- a/.github/workflows/main.yml > +++ b/.github/workflows/main.yml > @@ -310,11 +310,7 @@ jobs: > uses: ./.github/workflows/build-windows.yml > with: > platform: windows-x64 > -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) > msvc-toolset-version: '14.44' > -======= > - msvc-toolset-version: '14.43' > ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) > msvc-toolset-architecture: 'x86.x64' > configure-arguments: ${{ github.event.inputs.configure-arguments }} > make-arguments: ${{ github.event.inputs.make-arguments }} > @@ -326,11 +322,7 @@ jobs: > uses: ./.github/workflows/build-windows.yml > with: > platform: windows-aarch64 > -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) > msvc-toolset-version: '14.44' > -======= > - msvc-toolset-version: '14.43' > ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) > msvc-toolset-architecture: 'arm64' > make-target: 'hotspot' > extra-conf-options: '--openjdk-target=aarch64-unknown-cygwin' > @@ -369,17 +361,17 @@ jobs: > runs-on: ubuntu-22.04 > debug-suffix: -debug > > - test-linux-x64-static: > - name: linux-x64-static > - needs: > - - build-linux-x64 > - - build-linux-x64-static > - uses: ./.github/workflows/test.yml > - with: > - platform: linux-x64 > - bootjdk-platform: linux-x64 > - runs-on: ubuntu-22.04 > - static-suffix: "-static" > +# test-linux-x64-static: > +# name: linux-x64-static > +# needs: > +# - build-linux-x64 > +# - build-lin... Dmitry Cherepanov has updated the pull request incrementally with one additional commit since the last revision: zgc part cleanup ------------- Changes: - all: https://git.openjdk.org/crac/pull/248/files - new: https://git.openjdk.org/crac/pull/248/files/5035f463..df444e46 Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=248&range=01 - incr: https://webrevs.openjdk.org/?repo=crac&pr=248&range=00-01 Stats: 20 lines in 2 files changed: 2 ins; 11 del; 7 mod Patch: https://git.openjdk.org/crac/pull/248.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/248/head:pull/248 PR: https://git.openjdk.org/crac/pull/248 From tpushkin at openjdk.org Fri Jul 25 07:08:02 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Fri, 25 Jul 2025 07:08:02 GMT Subject: [crac] RFR: Merge jdk:jdk-25+26 [v2] In-Reply-To: <8kXDTMFHjARFZBBREXJvwRdejvZtTiYi8RZhq9huIps=.7206f5b5-61f7-470a-b71a-6d1639115c97@github.com> References: <8s5ymOREBNkrHIH_me6UxsNK6QjhJ9VsUPWPrYFNOIY=.74bc9410-d039-40ee-bc17-d5f1e3833ae2@github.com> <8kXDTMFHjARFZBBREXJvwRdejvZtTiYi8RZhq9huIps=.7206f5b5-61f7-470a-b71a-6d1639115c97@github.com> Message-ID: On Fri, 25 Jul 2025 07:02:02 GMT, Dmitry Cherepanov wrote: >> Since the merge for [JDK-8352675](https://bugs.openjdk.org/browse/JDK-8352675) is split into a separate PR (https://github.com/openjdk/crac/pull/247), I cherry-picked the current version and merging other changes on top of it. It will likely require rebase on top of the final version later. >> >> Attaching output of `--diff-merges=remerge` >> >>
>> >> Conflicts >> >> >> commit 5035f463900712ae47b7e1adfeff609bc1d66116 (HEAD -> merge-jdk, dmitry-crac/merge-jdk) >> Merge: d61227fe01d c59e44a7aa2 >> Author: Dmitry Cherepanov >> Date: Tue Jul 22 13:30:47 2025 +0400 >> >> Merge with jdk-25+26 >> >> diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml >> remerge CONFLICT (content): Merge conflict in .github/workflows/main.yml >> index 8cf745c1cff..02c6f3d2668 100644 >> --- a/.github/workflows/main.yml >> +++ b/.github/workflows/main.yml >> @@ -310,11 +310,7 @@ jobs: >> uses: ./.github/workflows/build-windows.yml >> with: >> platform: windows-x64 >> -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) >> msvc-toolset-version: '14.44' >> -======= >> - msvc-toolset-version: '14.43' >> ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) >> msvc-toolset-architecture: 'x86.x64' >> configure-arguments: ${{ github.event.inputs.configure-arguments }} >> make-arguments: ${{ github.event.inputs.make-arguments }} >> @@ -326,11 +322,7 @@ jobs: >> uses: ./.github/workflows/build-windows.yml >> with: >> platform: windows-aarch64 >> -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) >> msvc-toolset-version: '14.44' >> -======= >> - msvc-toolset-version: '14.43' >> ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) >> msvc-toolset-architecture: 'arm64' >> make-target: 'hotspot' >> extra-conf-options: '--openjdk-target=aarch64-unknown-cygwin' >> @@ -369,17 +361,17 @@ jobs: >> runs-on: ubuntu-22.04 >> debug-suffix: -debug >> >> - test-linux-x64-static: >> - name: linux-x64-static >> - needs: >> - - build-linux-x64 >> - - build-linux-x64-static >> - uses: ./.github/workflows/test.yml >> - with: >> - platform: linux-x64 >> - bootjdk-platform: linux-x64 >> - runs-on: ubuntu-22.04 >> - static-suffix: "-st... > > Dmitry Cherepanov has updated the pull request incrementally with one additional commit since the last revision: > > zgc part cleanup src/hotspot/share/jfr/jfr.cpp line 47: > 45: #include "oops/klass.hpp" > 46: #include "runtime/java.hpp" > 47: #include "runtime/javaThread.hpp" >From the conflicts resolution: #include "jfr/support/jfrKlassExtension.hpp" #include "jfr/support/jfrResolution.hpp" #include "jfr/support/jfrThreadLocal.hpp" -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) #include "memory/resourceArea.hpp" #include "runtime/flags/jvmFlag.hpp" -======= #include "jfr/support/methodtracer/jfrMethodTracer.hpp" #include "oops/instanceKlass.hpp" #include "oops/instanceKlass.inline.hpp" #include "oops/klass.hpp" ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) #include "runtime/java.hpp" #include "runtime/javaThread.hpp" Could you please keep the list sorted? src/hotspot/share/jfr/jni/jfrUpcalls.cpp line 81: > 79: publish_method_timers_for_klass_sym = SymbolTable::new_permanent_symbol("publishMethodTimersForClass"); > 80: publish_method_timers_for_klass_sig_sym = SymbolTable::new_permanent_symbol("(J)V"); > 81: initialized = publish_method_timers_for_klass_sig_sym != nullptr; `initialized` is now set twice test/hotspot/jtreg/ProblemList.txt line 1: > 1: # >From the conflict resolution: -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) runtime/ErrorHandling/CreateCoredumpOnCrash.java 8267433 macosx-x64 # JDK-8310862 was closed but we're still seeing errors with the updated test runtime/ClassInitErrors/TestStackOverflowDuringInit.java 8310862 generic-all -======= ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) JDK-8357924 removed `CreateCoredumpOnCrash.java` from the list, can't we remove it too? ------------- PR Review Comment: https://git.openjdk.org/crac/pull/248#discussion_r2230285572 PR Review Comment: https://git.openjdk.org/crac/pull/248#discussion_r2230292373 PR Review Comment: https://git.openjdk.org/crac/pull/248#discussion_r2230312546 From tpushkin at openjdk.org Fri Jul 25 07:08:03 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Fri, 25 Jul 2025 07:08:03 GMT Subject: [crac] RFR: Merge jdk:jdk-25+26 [v2] In-Reply-To: References: <8s5ymOREBNkrHIH_me6UxsNK6QjhJ9VsUPWPrYFNOIY=.74bc9410-d039-40ee-bc17-d5f1e3833ae2@github.com> <8kXDTMFHjARFZBBREXJvwRdejvZtTiYi8RZhq9huIps=.7206f5b5-61f7-470a-b71a-6d1639115c97@github.com> Message-ID: <2rDnm_l31GgkE4w1DwDMEtQJDSmqfWszlo-MzipIU60=.29a6ce5f-3b9d-446e-af59-537d75176897@github.com> On Fri, 25 Jul 2025 06:43:20 GMT, Timofei Pushkin wrote: >> Dmitry Cherepanov has updated the pull request incrementally with one additional commit since the last revision: >> >> zgc part cleanup > > src/hotspot/share/jfr/jfr.cpp line 47: > >> 45: #include "oops/klass.hpp" >> 46: #include "runtime/java.hpp" >> 47: #include "runtime/javaThread.hpp" > > From the conflicts resolution: > > #include "jfr/support/jfrKlassExtension.hpp" > #include "jfr/support/jfrResolution.hpp" > #include "jfr/support/jfrThreadLocal.hpp" > -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) > #include "memory/resourceArea.hpp" > #include "runtime/flags/jvmFlag.hpp" > -======= > #include "jfr/support/methodtracer/jfrMethodTracer.hpp" > #include "oops/instanceKlass.hpp" > #include "oops/instanceKlass.inline.hpp" > #include "oops/klass.hpp" > ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) > #include "runtime/java.hpp" > #include "runtime/javaThread.hpp" > > Could you please keep the list sorted? `#include "jfr/periodic/jfrOSInterface.hpp"`, which was also [added by us](https://github.com/openjdk/crac/pull/203/files#diff-5653173eea6fc7894f64ff537c902702a34482e0422146a9e890ebabccbc40f5), can also be repositioned properly while we are at it ------------- PR Review Comment: https://git.openjdk.org/crac/pull/248#discussion_r2230288026 From dcherepanov at openjdk.org Fri Jul 25 09:30:00 2025 From: dcherepanov at openjdk.org (Dmitry Cherepanov) Date: Fri, 25 Jul 2025 09:30:00 GMT Subject: [crac] RFR: Merge jdk:jdk-25+26 [v3] In-Reply-To: <8s5ymOREBNkrHIH_me6UxsNK6QjhJ9VsUPWPrYFNOIY=.74bc9410-d039-40ee-bc17-d5f1e3833ae2@github.com> References: <8s5ymOREBNkrHIH_me6UxsNK6QjhJ9VsUPWPrYFNOIY=.74bc9410-d039-40ee-bc17-d5f1e3833ae2@github.com> Message-ID: > Since the merge for [JDK-8352675](https://bugs.openjdk.org/browse/JDK-8352675) is split into a separate PR (https://github.com/openjdk/crac/pull/247), I cherry-picked the current version and merging other changes on top of it. It will likely require rebase on top of the final version later. > > Attaching output of `--diff-merges=remerge` > >
> > Conflicts > > > commit 5035f463900712ae47b7e1adfeff609bc1d66116 (HEAD -> merge-jdk, dmitry-crac/merge-jdk) > Merge: d61227fe01d c59e44a7aa2 > Author: Dmitry Cherepanov > Date: Tue Jul 22 13:30:47 2025 +0400 > > Merge with jdk-25+26 > > diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml > remerge CONFLICT (content): Merge conflict in .github/workflows/main.yml > index 8cf745c1cff..02c6f3d2668 100644 > --- a/.github/workflows/main.yml > +++ b/.github/workflows/main.yml > @@ -310,11 +310,7 @@ jobs: > uses: ./.github/workflows/build-windows.yml > with: > platform: windows-x64 > -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) > msvc-toolset-version: '14.44' > -======= > - msvc-toolset-version: '14.43' > ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) > msvc-toolset-architecture: 'x86.x64' > configure-arguments: ${{ github.event.inputs.configure-arguments }} > make-arguments: ${{ github.event.inputs.make-arguments }} > @@ -326,11 +322,7 @@ jobs: > uses: ./.github/workflows/build-windows.yml > with: > platform: windows-aarch64 > -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) > msvc-toolset-version: '14.44' > -======= > - msvc-toolset-version: '14.43' > ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) > msvc-toolset-architecture: 'arm64' > make-target: 'hotspot' > extra-conf-options: '--openjdk-target=aarch64-unknown-cygwin' > @@ -369,17 +361,17 @@ jobs: > runs-on: ubuntu-22.04 > debug-suffix: -debug > > - test-linux-x64-static: > - name: linux-x64-static > - needs: > - - build-linux-x64 > - - build-linux-x64-static > - uses: ./.github/workflows/test.yml > - with: > - platform: linux-x64 > - bootjdk-platform: linux-x64 > - runs-on: ubuntu-22.04 > - static-suffix: "-static" > +# test-linux-x64-static: > +# name: linux-x64-static > +# needs: > +# - build-linux-x64 > +# - build-lin... Dmitry Cherepanov has updated the pull request incrementally with one additional commit since the last revision: cleanup ------------- Changes: - all: https://git.openjdk.org/crac/pull/248/files - new: https://git.openjdk.org/crac/pull/248/files/df444e46..1665517e Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=248&range=02 - incr: https://webrevs.openjdk.org/?repo=crac&pr=248&range=01-02 Stats: 14 lines in 4 files changed: 5 ins; 5 del; 4 mod Patch: https://git.openjdk.org/crac/pull/248.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/248/head:pull/248 PR: https://git.openjdk.org/crac/pull/248 From jkratochvil at openjdk.org Fri Jul 25 09:46:14 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Fri, 25 Jul 2025 09:46:14 GMT Subject: [crac] RFR: Merge jdk:jdk-25+26 [v3] In-Reply-To: References: <8s5ymOREBNkrHIH_me6UxsNK6QjhJ9VsUPWPrYFNOIY=.74bc9410-d039-40ee-bc17-d5f1e3833ae2@github.com> Message-ID: On Fri, 25 Jul 2025 09:30:00 GMT, Dmitry Cherepanov wrote: >> Since the merge for [JDK-8352675](https://bugs.openjdk.org/browse/JDK-8352675) is split into a separate PR (https://github.com/openjdk/crac/pull/247), I cherry-picked the current version and merging other changes on top of it. It will likely require rebase on top of the final version later. >> >> Attaching output of `--diff-merges=remerge` >> >>
>> >> Conflicts >> >> >> commit 5035f463900712ae47b7e1adfeff609bc1d66116 (HEAD -> merge-jdk, dmitry-crac/merge-jdk) >> Merge: d61227fe01d c59e44a7aa2 >> Author: Dmitry Cherepanov >> Date: Tue Jul 22 13:30:47 2025 +0400 >> >> Merge with jdk-25+26 >> >> diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml >> remerge CONFLICT (content): Merge conflict in .github/workflows/main.yml >> index 8cf745c1cff..02c6f3d2668 100644 >> --- a/.github/workflows/main.yml >> +++ b/.github/workflows/main.yml >> @@ -310,11 +310,7 @@ jobs: >> uses: ./.github/workflows/build-windows.yml >> with: >> platform: windows-x64 >> -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) >> msvc-toolset-version: '14.44' >> -======= >> - msvc-toolset-version: '14.43' >> ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) >> msvc-toolset-architecture: 'x86.x64' >> configure-arguments: ${{ github.event.inputs.configure-arguments }} >> make-arguments: ${{ github.event.inputs.make-arguments }} >> @@ -326,11 +322,7 @@ jobs: >> uses: ./.github/workflows/build-windows.yml >> with: >> platform: windows-aarch64 >> -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) >> msvc-toolset-version: '14.44' >> -======= >> - msvc-toolset-version: '14.43' >> ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) >> msvc-toolset-architecture: 'arm64' >> make-target: 'hotspot' >> extra-conf-options: '--openjdk-target=aarch64-unknown-cygwin' >> @@ -369,17 +361,17 @@ jobs: >> runs-on: ubuntu-22.04 >> debug-suffix: -debug >> >> - test-linux-x64-static: >> - name: linux-x64-static >> - needs: >> - - build-linux-x64 >> - - build-linux-x64-static >> - uses: ./.github/workflows/test.yml >> - with: >> - platform: linux-x64 >> - bootjdk-platform: linux-x64 >> - runs-on: ubuntu-22.04 >> - static-suffix: "-st... > > Dmitry Cherepanov has updated the pull request incrementally with one additional commit since the last revision: > > cleanup The CPUFeatures are at: https://github.com/openjdk/crac/pull/250 ------------- PR Comment: https://git.openjdk.org/crac/pull/248#issuecomment-3117105494 From jkratochvil at openjdk.org Fri Jul 25 09:49:14 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Fri, 25 Jul 2025 09:49:14 GMT Subject: [crac] RFR: Fix up CPUFeatures on top of Merge jdk:jdk-25+26 [v2] In-Reply-To: References: Message-ID: <10FBa_moI_3Lo2PDZJdEjgnf4hVQTqzK8BI2mrAeBaE=.748ac54c-516e-4006-8c36-70c0b1428e22@github.com> > This pull request contains: https://github.com/openjdk/crac/pull/248 > I think the CRaC project does not provide the pr/NUMBER branches for dependent patches. > > This pull request enables the CPUFeatures again. Jan Kratochvil has updated the pull request incrementally with four additional commits since the last revision: - update test/lib-test/jdk/test/whitebox/CPUInfoTest.java - remove args - List CPUFeatures in Java - Fix static_assert ------------- Changes: - all: https://git.openjdk.org/crac/pull/250/files - new: https://git.openjdk.org/crac/pull/250/files/ac87941d..4a80393f Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=250&range=01 - incr: https://webrevs.openjdk.org/?repo=crac&pr=250&range=00-01 Stats: 23 lines in 4 files changed: 11 ins; 0 del; 12 mod Patch: https://git.openjdk.org/crac/pull/250.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/250/head:pull/250 PR: https://git.openjdk.org/crac/pull/250 From rvansa at openjdk.org Fri Jul 25 09:58:10 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Fri, 25 Jul 2025 09:58:10 GMT Subject: [crac] RFR: 8364078: [CRaC] CracTest mishandles NoSuchMethodException In-Reply-To: References: Message-ID: On Thu, 24 Jul 2025 17:24:58 GMT, Timofei Pushkin wrote: > Fixes the issue by reducing the scope of the `NoSuchMethodException`'s try-catch statement. Marked as reviewed by rvansa (Committer). ------------- PR Review: https://git.openjdk.org/crac/pull/249#pullrequestreview-3054824904 From tpushkin at openjdk.org Fri Jul 25 10:17:09 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Fri, 25 Jul 2025 10:17:09 GMT Subject: [crac] Integrated: 8364078: [CRaC] CracTest mishandles NoSuchMethodException In-Reply-To: References: Message-ID: On Thu, 24 Jul 2025 17:24:58 GMT, Timofei Pushkin wrote: > Fixes the issue by reducing the scope of the `NoSuchMethodException`'s try-catch statement. This pull request has now been integrated. Changeset: 5ceee7d6 Author: Timofei Pushkin URL: https://git.openjdk.org/crac/commit/5ceee7d6f171cf54816cc7a55ef3fc1c922ac911 Stats: 62 lines in 1 file changed: 21 ins; 18 del; 23 mod 8364078: [CRaC] CracTest mishandles NoSuchMethodException Reviewed-by: rvansa ------------- PR: https://git.openjdk.org/crac/pull/249 From tpushkin at openjdk.org Fri Jul 25 11:47:22 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Fri, 25 Jul 2025 11:47:22 GMT Subject: [crac] RFR: Merge jdk:jdk-25+26 [v3] In-Reply-To: References: <8s5ymOREBNkrHIH_me6UxsNK6QjhJ9VsUPWPrYFNOIY=.74bc9410-d039-40ee-bc17-d5f1e3833ae2@github.com> Message-ID: On Fri, 25 Jul 2025 09:30:00 GMT, Dmitry Cherepanov wrote: >> Since the merge for [JDK-8352675](https://bugs.openjdk.org/browse/JDK-8352675) is split into a separate PR (https://github.com/openjdk/crac/pull/247), I cherry-picked the current version and merging other changes on top of it. It will likely require rebase on top of the final version later. >> >> Attaching output of `--diff-merges=remerge` >> >>
>> >> Conflicts >> >> >> commit 5035f463900712ae47b7e1adfeff609bc1d66116 (HEAD -> merge-jdk, dmitry-crac/merge-jdk) >> Merge: d61227fe01d c59e44a7aa2 >> Author: Dmitry Cherepanov >> Date: Tue Jul 22 13:30:47 2025 +0400 >> >> Merge with jdk-25+26 >> >> diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml >> remerge CONFLICT (content): Merge conflict in .github/workflows/main.yml >> index 8cf745c1cff..02c6f3d2668 100644 >> --- a/.github/workflows/main.yml >> +++ b/.github/workflows/main.yml >> @@ -310,11 +310,7 @@ jobs: >> uses: ./.github/workflows/build-windows.yml >> with: >> platform: windows-x64 >> -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) >> msvc-toolset-version: '14.44' >> -======= >> - msvc-toolset-version: '14.43' >> ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) >> msvc-toolset-architecture: 'x86.x64' >> configure-arguments: ${{ github.event.inputs.configure-arguments }} >> make-arguments: ${{ github.event.inputs.make-arguments }} >> @@ -326,11 +322,7 @@ jobs: >> uses: ./.github/workflows/build-windows.yml >> with: >> platform: windows-aarch64 >> -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) >> msvc-toolset-version: '14.44' >> -======= >> - msvc-toolset-version: '14.43' >> ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) >> msvc-toolset-architecture: 'arm64' >> make-target: 'hotspot' >> extra-conf-options: '--openjdk-target=aarch64-unknown-cygwin' >> @@ -369,17 +361,17 @@ jobs: >> runs-on: ubuntu-22.04 >> debug-suffix: -debug >> >> - test-linux-x64-static: >> - name: linux-x64-static >> - needs: >> - - build-linux-x64 >> - - build-linux-x64-static >> - uses: ./.github/workflows/test.yml >> - with: >> - platform: linux-x64 >> - bootjdk-platform: linux-x64 >> - runs-on: ubuntu-22.04 >> - static-suffix: "-st... > > Dmitry Cherepanov has updated the pull request incrementally with one additional commit since the last revision: > > cleanup LGTM overall, not yet approving since Jan's CPUFeature-related changes will need to be integrated first, AFAIU. BTW, I've checked CRIU image size for ZGC before and after these changes on a simple Helidon-based app. There is an increase but I think it's ok and probably is caused by not our changes since without CRaC's cleanup the image size is much much more: - Before: 80?86 MB - After: 92?96 MB - Before, with CRaC's cleanup removed: ~3.5 GB src/hotspot/share/gc/z/zUncommitter.cpp line 434: > 432: void ZUncommitter::force_uncommit() { > 433: ZLocker locker(&_lock); > 434: if (ZUncommit) { Since `ZUncommit` is constant would be better to check it before taking the lock ------------- PR Review: https://git.openjdk.org/crac/pull/248#pullrequestreview-3055091544 PR Review Comment: https://git.openjdk.org/crac/pull/248#discussion_r2230875010 From dcherepanov at openjdk.org Fri Jul 25 12:50:11 2025 From: dcherepanov at openjdk.org (Dmitry Cherepanov) Date: Fri, 25 Jul 2025 12:50:11 GMT Subject: [crac] RFR: Merge jdk:jdk-25+26 [v4] In-Reply-To: <8s5ymOREBNkrHIH_me6UxsNK6QjhJ9VsUPWPrYFNOIY=.74bc9410-d039-40ee-bc17-d5f1e3833ae2@github.com> References: <8s5ymOREBNkrHIH_me6UxsNK6QjhJ9VsUPWPrYFNOIY=.74bc9410-d039-40ee-bc17-d5f1e3833ae2@github.com> Message-ID: > Since the merge for [JDK-8352675](https://bugs.openjdk.org/browse/JDK-8352675) is split into a separate PR (https://github.com/openjdk/crac/pull/247), I cherry-picked the current version and merging other changes on top of it. It will likely require rebase on top of the final version later. > > Attaching output of `--diff-merges=remerge` > >
> > Conflicts > > > commit 5035f463900712ae47b7e1adfeff609bc1d66116 (HEAD -> merge-jdk, dmitry-crac/merge-jdk) > Merge: d61227fe01d c59e44a7aa2 > Author: Dmitry Cherepanov > Date: Tue Jul 22 13:30:47 2025 +0400 > > Merge with jdk-25+26 > > diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml > remerge CONFLICT (content): Merge conflict in .github/workflows/main.yml > index 8cf745c1cff..02c6f3d2668 100644 > --- a/.github/workflows/main.yml > +++ b/.github/workflows/main.yml > @@ -310,11 +310,7 @@ jobs: > uses: ./.github/workflows/build-windows.yml > with: > platform: windows-x64 > -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) > msvc-toolset-version: '14.44' > -======= > - msvc-toolset-version: '14.43' > ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) > msvc-toolset-architecture: 'x86.x64' > configure-arguments: ${{ github.event.inputs.configure-arguments }} > make-arguments: ${{ github.event.inputs.make-arguments }} > @@ -326,11 +322,7 @@ jobs: > uses: ./.github/workflows/build-windows.yml > with: > platform: windows-aarch64 > -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) > msvc-toolset-version: '14.44' > -======= > - msvc-toolset-version: '14.43' > ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) > msvc-toolset-architecture: 'arm64' > make-target: 'hotspot' > extra-conf-options: '--openjdk-target=aarch64-unknown-cygwin' > @@ -369,17 +361,17 @@ jobs: > runs-on: ubuntu-22.04 > debug-suffix: -debug > > - test-linux-x64-static: > - name: linux-x64-static > - needs: > - - build-linux-x64 > - - build-linux-x64-static > - uses: ./.github/workflows/test.yml > - with: > - platform: linux-x64 > - bootjdk-platform: linux-x64 > - runs-on: ubuntu-22.04 > - static-suffix: "-static" > +# test-linux-x64-static: > +# name: linux-x64-static > +# needs: > +# - build-linux-x64 > +# - build-lin... Dmitry Cherepanov has updated the pull request incrementally with one additional commit since the last revision: cleanup ------------- Changes: - all: https://git.openjdk.org/crac/pull/248/files - new: https://git.openjdk.org/crac/pull/248/files/1665517e..322282a8 Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=248&range=03 - incr: https://webrevs.openjdk.org/?repo=crac&pr=248&range=02-03 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/crac/pull/248.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/248/head:pull/248 PR: https://git.openjdk.org/crac/pull/248 From dcherepanov at openjdk.org Fri Jul 25 12:50:12 2025 From: dcherepanov at openjdk.org (Dmitry Cherepanov) Date: Fri, 25 Jul 2025 12:50:12 GMT Subject: [crac] RFR: Merge jdk:jdk-25+26 [v3] In-Reply-To: References: <8s5ymOREBNkrHIH_me6UxsNK6QjhJ9VsUPWPrYFNOIY=.74bc9410-d039-40ee-bc17-d5f1e3833ae2@github.com> Message-ID: On Fri, 25 Jul 2025 09:30:00 GMT, Dmitry Cherepanov wrote: >> Since the merge for [JDK-8352675](https://bugs.openjdk.org/browse/JDK-8352675) is split into a separate PR (https://github.com/openjdk/crac/pull/247), I cherry-picked the current version and merging other changes on top of it. It will likely require rebase on top of the final version later. >> >> Attaching output of `--diff-merges=remerge` >> >>
>> >> Conflicts >> >> >> commit 5035f463900712ae47b7e1adfeff609bc1d66116 (HEAD -> merge-jdk, dmitry-crac/merge-jdk) >> Merge: d61227fe01d c59e44a7aa2 >> Author: Dmitry Cherepanov >> Date: Tue Jul 22 13:30:47 2025 +0400 >> >> Merge with jdk-25+26 >> >> diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml >> remerge CONFLICT (content): Merge conflict in .github/workflows/main.yml >> index 8cf745c1cff..02c6f3d2668 100644 >> --- a/.github/workflows/main.yml >> +++ b/.github/workflows/main.yml >> @@ -310,11 +310,7 @@ jobs: >> uses: ./.github/workflows/build-windows.yml >> with: >> platform: windows-x64 >> -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) >> msvc-toolset-version: '14.44' >> -======= >> - msvc-toolset-version: '14.43' >> ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) >> msvc-toolset-architecture: 'x86.x64' >> configure-arguments: ${{ github.event.inputs.configure-arguments }} >> make-arguments: ${{ github.event.inputs.make-arguments }} >> @@ -326,11 +322,7 @@ jobs: >> uses: ./.github/workflows/build-windows.yml >> with: >> platform: windows-aarch64 >> -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) >> msvc-toolset-version: '14.44' >> -======= >> - msvc-toolset-version: '14.43' >> ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) >> msvc-toolset-architecture: 'arm64' >> make-target: 'hotspot' >> extra-conf-options: '--openjdk-target=aarch64-unknown-cygwin' >> @@ -369,17 +361,17 @@ jobs: >> runs-on: ubuntu-22.04 >> debug-suffix: -debug >> >> - test-linux-x64-static: >> - name: linux-x64-static >> - needs: >> - - build-linux-x64 >> - - build-linux-x64-static >> - uses: ./.github/workflows/test.yml >> - with: >> - platform: linux-x64 >> - bootjdk-platform: linux-x64 >> - runs-on: ubuntu-22.04 >> - static-suffix: "-st... > > Dmitry Cherepanov has updated the pull request incrementally with one additional commit since the last revision: > > cleanup Thanks for the review! Incorporated all suggestions. > LGTM overall, not yet approving since Jan's CPUFeature-related changes will need to be integrated first, AFAIU. Right, I have the same understanding. ------------- PR Comment: https://git.openjdk.org/crac/pull/248#issuecomment-3117658432 From tpushkin at openjdk.org Fri Jul 25 13:46:29 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Fri, 25 Jul 2025 13:46:29 GMT Subject: [crac] RFR: Fix up CPUFeatures on top of Merge jdk:jdk-25+26 [v2] In-Reply-To: <10FBa_moI_3Lo2PDZJdEjgnf4hVQTqzK8BI2mrAeBaE=.748ac54c-516e-4006-8c36-70c0b1428e22@github.com> References: <10FBa_moI_3Lo2PDZJdEjgnf4hVQTqzK8BI2mrAeBaE=.748ac54c-516e-4006-8c36-70c0b1428e22@github.com> Message-ID: On Fri, 25 Jul 2025 09:49:14 GMT, Jan Kratochvil wrote: >> This pull request contains: https://github.com/openjdk/crac/pull/248 >> I think the CRaC project does not provide the pr/NUMBER branches for dependent patches. >> >> This pull request enables the CPUFeatures again. > > Jan Kratochvil has updated the pull request incrementally with four additional commits since the last revision: > > - update test/lib-test/jdk/test/whitebox/CPUInfoTest.java > - remove args > - List CPUFeatures in Java > - Fix static_assert Would be great if others took a look too, I won't say I've read into every detail of the changes src/hotspot/cpu/x86/vm_version_x86.cpp line 919: > 917: return retval; > 918: } > 919: } `str` does not seem to be modified in the loop, won't we be parsing only the first part of it on each iteration? src/hotspot/cpu/x86/vm_version_x86.cpp line 920: > 918: } > 919: } > 920: vm_exit_during_initialization(err_msg("VM option 'CPUFeatures=%s' must be of the form: 0xnum,0xnum", str)); This implies `count == 2`, maybe we should add a static assert? src/hotspot/cpu/x86/vm_version_x86.cpp line 1117: > 1115: assert(!shouldnotuse.supports_feature(CPU_MOVBE), "CPU_MOVBE in both _features and shouldnotuse cannot happen"); > 1116: // FMA is 2012+, AVX2+BMI1+BMI2+LZCNT are 2013+, MOVBE is 2015+ > 1117: shouldnotuse.set_feature( CPU_MOVBE); Suggestion: shouldnotuse.set_feature(CPU_MOVBE); src/hotspot/cpu/x86/vm_version_x86.cpp line 2542: > 2540: > 2541: // Print the feature names as " = feat1, ..., featN\n"; > 2542: void VM_Version::missing_features(VM_Version::VM_Features features_missing) { `features_missing` could be a const reference. Maybe it is even better to make this a const method of `VM_Version::VM_Features` itself? I also think `print_missing_features` would be a better name. And I don't understand why is it marked `/*[[noreturn]]*/` in the declaration. src/hotspot/cpu/x86/vm_version_x86.cpp line 2566: > 2564: if (ShowCPUFeatures) { > 2565: char buf[MAX_CPU_FEATURES * 16]; > 2566: (*data).print_numbers_and_names(buf, sizeof(buf)); Suggestion: data->print_numbers_and_names(buf, sizeof(buf)); src/hotspot/cpu/x86/vm_version_x86.cpp line 2579: > 2577: (*data & _features).print_numbers(buf_use, sizeof(buf_use)); > 2578: char buf_have[MAX_CPU_FEATURES]; > 2579: (*data).print_numbers(buf_have, sizeof(buf_have)); Suggestion: data->print_numbers(buf_have, sizeof(buf_have)); src/hotspot/cpu/x86/vm_version_x86.cpp line 2670: > 2668: char buf__features[MAX_CPU_FEATURES]; > 2669: _features.print_numbers(buf__features, sizeof(buf__features)); > 2670: tty->print("Specified -XX:CPUFeatures=%s; this machine's CPU features are %s", buf_CPUFeatures_parsed, buf__features); Suggestion: char buf_features[MAX_CPU_FEATURES]; _features.print_numbers(buf_features, sizeof(buf_features)); tty->print("Specified -XX:CPUFeatures=%s; this machine's CPU features are %s", buf_CPUFeatures_parsed, buf_features); src/hotspot/cpu/x86/vm_version_x86.hpp line 33: > 31: #include "utilities/macros.hpp" > 32: #include "utilities/sizes.hpp" > 33: #include It worries me that this one is not among [the explicitly permitted std lib headers](https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md#c-standard-library) so we may start getting compilation errors at some point... ------------- PR Review: https://git.openjdk.org/crac/pull/250#pullrequestreview-3055191329 PR Review Comment: https://git.openjdk.org/crac/pull/250#discussion_r2230982726 PR Review Comment: https://git.openjdk.org/crac/pull/250#discussion_r2230975019 PR Review Comment: https://git.openjdk.org/crac/pull/250#discussion_r2230991321 PR Review Comment: https://git.openjdk.org/crac/pull/250#discussion_r2231014067 PR Review Comment: https://git.openjdk.org/crac/pull/250#discussion_r2231026254 PR Review Comment: https://git.openjdk.org/crac/pull/250#discussion_r2231029414 PR Review Comment: https://git.openjdk.org/crac/pull/250#discussion_r2231034527 PR Review Comment: https://git.openjdk.org/crac/pull/250#discussion_r2230946338 From jkratochvil at openjdk.org Fri Jul 25 16:33:38 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Fri, 25 Jul 2025 16:33:38 GMT Subject: [crac] RFR: Fix up CPUFeatures on top of Merge jdk:jdk-25+26 [v3] In-Reply-To: References: Message-ID: > This pull request contains: https://github.com/openjdk/crac/pull/248 > I think the CRaC project does not provide the pr/NUMBER branches for dependent patches. > > This pull request enables the CPUFeatures again. Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision: remove ------------- Changes: - all: https://git.openjdk.org/crac/pull/250/files - new: https://git.openjdk.org/crac/pull/250/files/4a80393f..2f5f39eb Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=250&range=02 - incr: https://webrevs.openjdk.org/?repo=crac&pr=250&range=01-02 Stats: 7 lines in 1 file changed: 3 ins; 1 del; 3 mod Patch: https://git.openjdk.org/crac/pull/250.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/250/head:pull/250 PR: https://git.openjdk.org/crac/pull/250 From jkratochvil at openjdk.org Fri Jul 25 16:38:44 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Fri, 25 Jul 2025 16:38:44 GMT Subject: [crac] RFR: Fix up CPUFeatures on top of Merge jdk:jdk-25+26 [v4] In-Reply-To: References: Message-ID: > This pull request contains: https://github.com/openjdk/crac/pull/248 > I think the CRaC project does not provide the pr/NUMBER branches for dependent patches. > > This pull request enables the CPUFeatures again. Jan Kratochvil has updated the pull request incrementally with two additional commits since the last revision: - whitespace fix - fix -XX:CPUFeatures parsing and its error message ------------- Changes: - all: https://git.openjdk.org/crac/pull/250/files - new: https://git.openjdk.org/crac/pull/250/files/2f5f39eb..44aaef0e Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=250&range=03 - incr: https://webrevs.openjdk.org/?repo=crac&pr=250&range=02-03 Stats: 11 lines in 1 file changed: 7 ins; 0 del; 4 mod Patch: https://git.openjdk.org/crac/pull/250.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/250/head:pull/250 PR: https://git.openjdk.org/crac/pull/250 From jkratochvil at openjdk.org Fri Jul 25 16:38:45 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Fri, 25 Jul 2025 16:38:45 GMT Subject: [crac] RFR: Fix up CPUFeatures on top of Merge jdk:jdk-25+26 [v2] In-Reply-To: References: <10FBa_moI_3Lo2PDZJdEjgnf4hVQTqzK8BI2mrAeBaE=.748ac54c-516e-4006-8c36-70c0b1428e22@github.com> Message-ID: On Fri, 25 Jul 2025 12:38:57 GMT, Timofei Pushkin wrote: >> Jan Kratochvil has updated the pull request incrementally with four additional commits since the last revision: >> >> - update test/lib-test/jdk/test/whitebox/CPUInfoTest.java >> - remove args >> - List CPUFeatures in Java >> - Fix static_assert > > src/hotspot/cpu/x86/vm_version_x86.cpp line 919: > >> 917: return retval; >> 918: } >> 919: } > > `str` does not seem to be modified in the loop, won't we be parsing only the first part of it on each iteration? yes, thanks. > src/hotspot/cpu/x86/vm_version_x86.cpp line 920: > >> 918: } >> 919: } >> 920: vm_exit_during_initialization(err_msg("VM option 'CPUFeatures=%s' must be of the form: 0xnum,0xnum", str)); > > This implies `count == 2`, maybe we should add a static assert? I missed that, thanks. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/250#discussion_r2231570331 PR Review Comment: https://git.openjdk.org/crac/pull/250#discussion_r2231570614 From jkratochvil at openjdk.org Fri Jul 25 16:46:27 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Fri, 25 Jul 2025 16:46:27 GMT Subject: [crac] RFR: Fix up CPUFeatures on top of Merge jdk:jdk-25+26 [v5] In-Reply-To: References: Message-ID: > This pull request contains: https://github.com/openjdk/crac/pull/248 > I think the CRaC project does not provide the pr/NUMBER branches for dependent patches. > > This pull request enables the CPUFeatures again. Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision: fix ups of VM_Version::missing_features ------------- Changes: - all: https://git.openjdk.org/crac/pull/250/files - new: https://git.openjdk.org/crac/pull/250/files/44aaef0e..28bfd3c9 Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=250&range=04 - incr: https://webrevs.openjdk.org/?repo=crac&pr=250&range=03-04 Stats: 13 lines in 2 files changed: 2 ins; 4 del; 7 mod Patch: https://git.openjdk.org/crac/pull/250.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/250/head:pull/250 PR: https://git.openjdk.org/crac/pull/250 From jkratochvil at openjdk.org Fri Jul 25 16:46:28 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Fri, 25 Jul 2025 16:46:28 GMT Subject: [crac] RFR: Fix up CPUFeatures on top of Merge jdk:jdk-25+26 [v2] In-Reply-To: References: <10FBa_moI_3Lo2PDZJdEjgnf4hVQTqzK8BI2mrAeBaE=.748ac54c-516e-4006-8c36-70c0b1428e22@github.com> Message-ID: On Fri, 25 Jul 2025 12:53:03 GMT, Timofei Pushkin wrote: > features_missing could be a const reference. AI says: > For a 16?byte struct on a 64?bit system, passing by value is usually faster or equal, and passing by const& rarely improves performance. But it became a method now so it became a pointer anyway. `/*[[noreturn]]*/` was obsolete, thanks for catching it. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/250#discussion_r2231582073 From jkratochvil at openjdk.org Fri Jul 25 16:54:51 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Fri, 25 Jul 2025 16:54:51 GMT Subject: [crac] RFR: Fix up CPUFeatures on top of Merge jdk:jdk-25+26 [v6] In-Reply-To: References: Message-ID: <79xQdc6Xdpi0owazo6g3TOFh1jBFP9iKoIDCVUZaL8Q=.4cb07308-e5a7-4a7c-8215-a05a6d828134@github.com> > This pull request contains: https://github.com/openjdk/crac/pull/248 > I think the CRaC project does not provide the pr/NUMBER branches for dependent patches. > > This pull request enables the CPUFeatures again. Jan Kratochvil has updated the pull request incrementally with two additional commits since the last revision: - buf__features -> buf_features - Update (*data).print_numbers ------------- Changes: - all: https://git.openjdk.org/crac/pull/250/files - new: https://git.openjdk.org/crac/pull/250/files/28bfd3c9..0116543f Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=250&range=05 - incr: https://webrevs.openjdk.org/?repo=crac&pr=250&range=04-05 Stats: 11 lines in 1 file changed: 1 ins; 0 del; 10 mod Patch: https://git.openjdk.org/crac/pull/250.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/250/head:pull/250 PR: https://git.openjdk.org/crac/pull/250 From jkratochvil at openjdk.org Fri Jul 25 16:54:53 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Fri, 25 Jul 2025 16:54:53 GMT Subject: [crac] RFR: Fix up CPUFeatures on top of Merge jdk:jdk-25+26 [v2] In-Reply-To: References: <10FBa_moI_3Lo2PDZJdEjgnf4hVQTqzK8BI2mrAeBaE=.748ac54c-516e-4006-8c36-70c0b1428e22@github.com> Message-ID: On Fri, 25 Jul 2025 12:59:12 GMT, Timofei Pushkin wrote: >> Jan Kratochvil has updated the pull request incrementally with four additional commits since the last revision: >> >> - update test/lib-test/jdk/test/whitebox/CPUInfoTest.java >> - remove args >> - List CPUFeatures in Java >> - Fix static_assert > > src/hotspot/cpu/x86/vm_version_x86.cpp line 2566: > >> 2564: if (ShowCPUFeatures) { >> 2565: char buf[MAX_CPU_FEATURES * 16]; >> 2566: (*data).print_numbers_and_names(buf, sizeof(buf)); > > Suggestion: > > data->print_numbers_and_names(buf, sizeof(buf)); I have rather made `data` a non-pointer if you agree. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/250#discussion_r2231597142 From tpushkin at openjdk.org Fri Jul 25 17:01:34 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Fri, 25 Jul 2025 17:01:34 GMT Subject: [crac] RFR: Fix up CPUFeatures on top of Merge jdk:jdk-25+26 [v6] In-Reply-To: <79xQdc6Xdpi0owazo6g3TOFh1jBFP9iKoIDCVUZaL8Q=.4cb07308-e5a7-4a7c-8215-a05a6d828134@github.com> References: <79xQdc6Xdpi0owazo6g3TOFh1jBFP9iKoIDCVUZaL8Q=.4cb07308-e5a7-4a7c-8215-a05a6d828134@github.com> Message-ID: On Fri, 25 Jul 2025 16:54:51 GMT, Jan Kratochvil wrote: >> This pull request contains: https://github.com/openjdk/crac/pull/248 >> I think the CRaC project does not provide the pr/NUMBER branches for dependent patches. >> >> This pull request enables the CPUFeatures again. > > Jan Kratochvil has updated the pull request incrementally with two additional commits since the last revision: > > - buf__features -> buf_features > - Update (*data).print_numbers src/hotspot/cpu/x86/vm_version_x86.cpp line 2567: > 2565: return false; > 2566: } > 2567: VM_Version::VM_Features data = *data_ptr; Suggestion: const VM_Version::VM_Features &data = *data_ptr; ------------- PR Review Comment: https://git.openjdk.org/crac/pull/250#discussion_r2231615242 From tpushkin at openjdk.org Fri Jul 25 17:06:11 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Fri, 25 Jul 2025 17:06:11 GMT Subject: [crac] RFR: Fix up CPUFeatures on top of Merge jdk:jdk-25+26 [v6] In-Reply-To: References: <79xQdc6Xdpi0owazo6g3TOFh1jBFP9iKoIDCVUZaL8Q=.4cb07308-e5a7-4a7c-8215-a05a6d828134@github.com> Message-ID: On Fri, 25 Jul 2025 16:58:57 GMT, Timofei Pushkin wrote: >> Jan Kratochvil has updated the pull request incrementally with two additional commits since the last revision: >> >> - buf__features -> buf_features >> - Update (*data).print_numbers > > src/hotspot/cpu/x86/vm_version_x86.cpp line 2567: > >> 2565: return false; >> 2566: } >> 2567: VM_Version::VM_Features data = *data_ptr; > > Suggestion: > > const VM_Version::VM_Features &data = *data_ptr; Saw your comment regarding copying being faster than referencing for this struct, it is probably the same here, so cresolving ------------- PR Review Comment: https://git.openjdk.org/crac/pull/250#discussion_r2231624424 From jkratochvil at openjdk.org Fri Jul 25 17:06:11 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Fri, 25 Jul 2025 17:06:11 GMT Subject: [crac] RFR: Fix up CPUFeatures on top of Merge jdk:jdk-25+26 [v6] In-Reply-To: References: <79xQdc6Xdpi0owazo6g3TOFh1jBFP9iKoIDCVUZaL8Q=.4cb07308-e5a7-4a7c-8215-a05a6d828134@github.com> Message-ID: On Fri, 25 Jul 2025 17:02:40 GMT, Timofei Pushkin wrote: >> src/hotspot/cpu/x86/vm_version_x86.cpp line 2567: >> >>> 2565: return false; >>> 2566: } >>> 2567: VM_Version::VM_Features data = *data_ptr; >> >> Suggestion: >> >> const VM_Version::VM_Features &data = *data_ptr; > > Saw your comment regarding copying being faster than referencing for this struct, it is probably the same here, so cresolving It is true it may no longer apply in the futuer if VM_Features gets bigger. But yes, I did it based on the referenced benchmark. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/250#discussion_r2231626155 From jkratochvil at openjdk.org Fri Jul 25 18:14:40 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Fri, 25 Jul 2025 18:14:40 GMT Subject: [crac] RFR: Fix up CPUFeatures on top of Merge jdk:jdk-25+26 [v7] In-Reply-To: References: Message-ID: > This pull request contains: https://github.com/openjdk/crac/pull/248 > I think the CRaC project does not provide the pr/NUMBER branches for dependent patches. > > This pull request enables the CPUFeatures again. Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision: fix MS-Windows compilation ------------- Changes: - all: https://git.openjdk.org/crac/pull/250/files - new: https://git.openjdk.org/crac/pull/250/files/0116543f..aab5a6c6 Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=250&range=06 - incr: https://webrevs.openjdk.org/?repo=crac&pr=250&range=05-06 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/crac/pull/250.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/250/head:pull/250 PR: https://git.openjdk.org/crac/pull/250 From tpushkin at openjdk.org Sat Jul 26 18:13:08 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Sat, 26 Jul 2025 18:13:08 GMT Subject: [crac] RFR: Fix up CPUFeatures on top of Merge jdk:jdk-25+26 [v7] In-Reply-To: References: Message-ID: <95TZKvo8MMLAQJ0AkmD81cKatnR1HY9ZrSgE4mnKunE=.67c09d3c-ee7b-46ea-b665-a114c3618063@github.com> On Fri, 25 Jul 2025 18:14:40 GMT, Jan Kratochvil wrote: >> This pull request contains: https://github.com/openjdk/crac/pull/248 >> I think the CRaC project does not provide the pr/NUMBER branches for dependent patches. >> >> This pull request enables the CPUFeatures again. > > Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision: > > fix MS-Windows compilation src/hotspot/cpu/x86/vm_version_x86.cpp line 927: > 925: s = stpcpy(s, ",0xNUM"); > 926: } > 927: vm_exit_during_initialization(err_msg("VM option 'CPUFeatures=%s' must be of the form: %s", str, buf + 1)); `str` might have been moved by now so only a part of the actual user input would be printed src/hotspot/cpu/x86/vm_version_x86.cpp line 2553: > 2551: print_numbers_and_names(buf, sizeof(buf)); > 2552: tty->print_cr("; missing features of this CPU are %s\n" > 2553: "If you are sure it will not crash you can override this check by -XX:+UnlockExperimentalVMOptions -XX:+IgnoreCPUFeatures .", Suggestion: "If you are sure it will not crash you can override this check by -XX:+UnlockExperimentalVMOptions -XX:+IgnoreCPUFeatures.", ------------- PR Review Comment: https://git.openjdk.org/crac/pull/250#discussion_r2233124692 PR Review Comment: https://git.openjdk.org/crac/pull/250#discussion_r2233128650 From jkratochvil at openjdk.org Sun Jul 27 02:19:18 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Sun, 27 Jul 2025 02:19:18 GMT Subject: [crac] RFR: Fix up CPUFeatures on top of Merge jdk:jdk-25+26 [v8] In-Reply-To: References: Message-ID: > This pull request contains: https://github.com/openjdk/crac/pull/248 > I think the CRaC project does not provide the pr/NUMBER branches for dependent patches. > > This pull request enables the CPUFeatures again. Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision: Fix the message: VM option 'CPUFeatures=%s' must be of the form ------------- Changes: - all: https://git.openjdk.org/crac/pull/250/files - new: https://git.openjdk.org/crac/pull/250/files/aab5a6c6..e1d81587 Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=250&range=07 - incr: https://webrevs.openjdk.org/?repo=crac&pr=250&range=06-07 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/crac/pull/250.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/250/head:pull/250 PR: https://git.openjdk.org/crac/pull/250 From jkratochvil at openjdk.org Sun Jul 27 02:19:18 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Sun, 27 Jul 2025 02:19:18 GMT Subject: [crac] RFR: Fix up CPUFeatures on top of Merge jdk:jdk-25+26 [v7] In-Reply-To: <95TZKvo8MMLAQJ0AkmD81cKatnR1HY9ZrSgE4mnKunE=.67c09d3c-ee7b-46ea-b665-a114c3618063@github.com> References: <95TZKvo8MMLAQJ0AkmD81cKatnR1HY9ZrSgE4mnKunE=.67c09d3c-ee7b-46ea-b665-a114c3618063@github.com> Message-ID: On Sat, 26 Jul 2025 18:08:39 GMT, Timofei Pushkin wrote: >> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision: >> >> fix MS-Windows compilation > > src/hotspot/cpu/x86/vm_version_x86.cpp line 2553: > >> 2551: print_numbers_and_names(buf, sizeof(buf)); >> 2552: tty->print_cr("; missing features of this CPU are %s\n" >> 2553: "If you are sure it will not crash you can override this check by -XX:+UnlockExperimentalVMOptions -XX:+IgnoreCPUFeatures .", > > Suggestion: > > "If you are sure it will not crash you can override this check by -XX:+UnlockExperimentalVMOptions -XX:+IgnoreCPUFeatures.", It is intentional for easier copy-paste-by-word. Although it depends on the selection word delimiters. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/250#discussion_r2233596618 From tpushkin at openjdk.org Sun Jul 27 10:58:17 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Sun, 27 Jul 2025 10:58:17 GMT Subject: [crac] RFR: Fix up CPUFeatures on top of Merge jdk:jdk-25+26 [v8] In-Reply-To: References: Message-ID: <5BCqJMCHoQuwDP8jH5WQLI6Gr3yRnVUJvZFNa1ISpWI=.839460df-009b-414e-ad5a-b073356f3662@github.com> On Sun, 27 Jul 2025 02:19:18 GMT, Jan Kratochvil wrote: >> This pull request contains: https://github.com/openjdk/crac/pull/248 >> I think the CRaC project does not provide the pr/NUMBER branches for dependent patches. >> >> This pull request enables the CPUFeatures again. > > Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision: > > Fix the message: VM option 'CPUFeatures=%s' must be of the form Besides the small comment LGTM. I found a few issues with handling of incorrect inputs (ZULU-78855, ZULU-78856, ZULU-78857) but turns out they are all pre-existing, so should not be fixed here. Looks like the CPU features testing should be enlarged. src/hotspot/cpu/x86/vm_version_x86.cpp line 2556: > 2554: "If you are sure it will not crash you can override this check by -XX:+UnlockExperimentalVMOptions -XX:+IgnoreCPUFeatures .", > 2555: buf); > 2556: } When specifying missing features I am getting: Specified -XX:CPUFeatures=0xffffffffffffffff,0xfffffffffffffffe; this machine's CPU features are 0x44fbffff9dfdfbff,0x3cc; missing features of this CPU are 0xbb04000062020400,0x32 = , sse4a, tscinv, rtm, avx512pf, avx512er, fsrm, cet_ibt, cet_ss, avx_ifma, apx_f, sha512, avx10_1, fma4, ibt, shstk The comma after the "=" in "... 0xbb04000062020400,0x32 = , sse4a ..." is out of place. ------------- PR Review: https://git.openjdk.org/crac/pull/250#pullrequestreview-3059440411 PR Review Comment: https://git.openjdk.org/crac/pull/250#discussion_r2233888568 From jkratochvil at openjdk.org Sun Jul 27 15:33:20 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Sun, 27 Jul 2025 15:33:20 GMT Subject: [crac] RFR: Fix up CPUFeatures on top of Merge jdk:jdk-25+26 [v9] In-Reply-To: References: Message-ID: > This pull request contains: https://github.com/openjdk/crac/pull/248 > I think the CRaC project does not provide the pr/NUMBER branches for dependent patches. > > This pull request enables the CPUFeatures again. Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision: Fix leading ", " ------------- Changes: - all: https://git.openjdk.org/crac/pull/250/files - new: https://git.openjdk.org/crac/pull/250/files/e1d81587..d0c638a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=250&range=08 - incr: https://webrevs.openjdk.org/?repo=crac&pr=250&range=07-08 Stats: 9 lines in 1 file changed: 5 ins; 1 del; 3 mod Patch: https://git.openjdk.org/crac/pull/250.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/250/head:pull/250 PR: https://git.openjdk.org/crac/pull/250 From tpushkin at openjdk.org Sun Jul 27 15:52:08 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Sun, 27 Jul 2025 15:52:08 GMT Subject: [crac] RFR: Fix up CPUFeatures on top of Merge jdk:jdk-25+26 [v9] In-Reply-To: References: Message-ID: <7hfG5WiTVX6bScb_6cBU2lzh1dWUFybJscU2OCUOFt8=.7445fdb4-3698-4553-b0f3-750f3ec8c57e@github.com> On Sun, 27 Jul 2025 15:33:20 GMT, Jan Kratochvil wrote: >> This pull request contains: https://github.com/openjdk/crac/pull/248 >> I think the CRaC project does not provide the pr/NUMBER branches for dependent patches. >> >> This pull request enables the CPUFeatures again. > > Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision: > > Fix leading ", " LGTM, thank you ------------- Marked as reviewed by tpushkin (Committer). PR Review: https://git.openjdk.org/crac/pull/250#pullrequestreview-3059598975 From tpushkin at openjdk.org Mon Jul 28 07:10:08 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Mon, 28 Jul 2025 07:10:08 GMT Subject: [crac] RFR: 8364156: [CRaC] Recompile methods decompiled during or shortly after C/R Message-ID: Implements recording and triggering recompilation of methods decompiled during and shortly after C/R. The length of the "shortly-after" period can be controlled by the user via `-Djdk.crac.recompilation-delay-ms=`, the default is 10ms. Measuring the after-restore regression before and after this change shows improvement on hello-world apps. The numbers are the regression of the first after-restore 1 sec iteration vs average over 5 last before-checkpoint 1 sec iterations, i.e. lower means better; mean ? std dev over 30 runs. Measured in a Linux VM on MacOS, with CRIU, with 5ms after-restore recompilation delay. | | Before | After | |--------------------------|-------------|-------------| | Helidon hello-world | 0.9 ? 1.2 % | 0.4 ? 1.0 % | | Spring boot CRaC example | 9.5 ? 2.4 % | 6.4 ? 2.5 % | Currently decompilations are recorded during C/R + during the after-restore delay and then they all get recompiled together. An enhancement planned in the future is to record only during C/R recompiling immediately after restore and during the after-restore delay recompile immediately without recording. This way the recompilations would finish faster, also setting `jdk.crac.recompilation-delay-ms` to a higher value would have less negative impact. Implementation notes: - Native code (`nmethod`) is considered "decompiled" when `make_not_entrant(...)` is called on it ? a new mandatory parameter is added to the signature of this method that controls whether CRaC should consider this particular decompilation for recompilation or not. - The parameter is needed because we do not want to recompile, for example, when `nmethod` is thrown away once a replacement for it has been compiled (e.g. on another compilation level). - The parameter has no default so that we get compilation errors when new calls to `make_not_entrant(...)` are introduced in the mainline ? we will be deciding whether these new calls should be considered for recompilation or not. If CRaC was in the mainline I would enable the recompilation by default. - The new native `CRaCRecorder` class is the core of the implementation ? it records the decompilations and handles their recompilation. - `jdk.crac.internal.mirror.Core` notifies it when to start and stop the recording, it also handles the after-restore recompilation delay. - `nmethod.make_not_entrant(...)` notifies it about decompiled code. ------------- Commit messages: - Reduce default recompilation delay - Fix NaturalDecompilationTest on Windows - Make decompilation more reliable in NaturalDecompilationTest - Remove misleading comment - Stop preventing methods from becoming not compilable - Add tests - Recompile only if still appropriate - Cover all not-entrant causes - Re-compile uncommon_trap-ed Changes: https://git.openjdk.org/crac/pull/251/files Webrev: https://webrevs.openjdk.org/?repo=crac&pr=251&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364156 Stats: 848 lines in 26 files changed: 823 ins; 0 del; 25 mod Patch: https://git.openjdk.org/crac/pull/251.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/251/head:pull/251 PR: https://git.openjdk.org/crac/pull/251 From tpushkin at openjdk.org Mon Jul 28 07:14:08 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Mon, 28 Jul 2025 07:14:08 GMT Subject: [crac] RFR: 8364156: [CRaC] Recompile methods decompiled during or shortly after C/R In-Reply-To: References: Message-ID: On Mon, 28 Jul 2025 07:04:26 GMT, Timofei Pushkin wrote: > Implements recording and triggering recompilation of methods decompiled during and shortly after C/R. The length of the "shortly-after" period can be controlled by the user via `-Djdk.crac.recompilation-delay-ms=`, the default is 10ms. > > Measuring the after-restore regression before and after this change shows improvement on hello-world apps. The numbers are the regression of the first after-restore 1 sec iteration vs average over 5 last before-checkpoint 1 sec iterations, i.e. lower means better; mean ? std dev over 30 runs. Measured in a Linux VM on MacOS, with CRIU, with 5ms after-restore recompilation delay. > > | | Before | After | > |--------------------------|-------------|-------------| > | Helidon hello-world | 0.9 ? 1.2 % | 0.4 ? 1.0 % | > | Spring boot CRaC example | 9.5 ? 2.4 % | 6.4 ? 2.5 % | > > Currently decompilations are recorded during C/R + during the after-restore delay and then they all get recompiled together. An enhancement planned in the future is to record only during C/R recompiling immediately after restore and during the after-restore delay recompile immediately without recording. This way the recompilations would finish faster, also setting `jdk.crac.recompilation-delay-ms` to a higher value would have less negative impact. > > Implementation notes: > - Native code (`nmethod`) is considered "decompiled" when `make_not_entrant(...)` is called on it ? a new mandatory parameter is added to the signature of this method that controls whether CRaC should consider this particular decompilation for recompilation or not. > - The parameter is needed because we do not want to recompile, for example, when `nmethod` is thrown away once a replacement for it has been compiled (e.g. on another compilation level). > - The parameter has no default so that we get compilation errors when new calls to `make_not_entrant(...)` are introduced in the mainline ? we will be deciding whether these new calls should be considered for recompilation or not. If CRaC was in the mainline I would enable the recompilation by default. > - The new native `CRaCRecorder` class is the core of the implementation ? it records the decompilations and handles their recompilation. > - `jdk.crac.internal.mirror.Core` notifies it when to start and stop the recording, it also handles the after-restore recompilation delay. > - `nmethod.make_not_entrant(...)` notifies it about decompiled code. src/hotspot/share/runtime/cracRecompiler.cpp line 171: > 169: log_debug(crac)("Finishing recording decompilations and requesting %i recompilations", decomps->length()); > 170: // fence should allow the recorder threads to stop locking quicker > 171: Atomic::release_store_fence(&decompilations, static_cast(nullptr)); I've realized that after this nothing is guarding the recorded methods from being deleted by `RedefineClasses`. Need to fix this before integrating. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/251#discussion_r2235008362 From jkratochvil at openjdk.org Mon Jul 28 10:26:20 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Mon, 28 Jul 2025 10:26:20 GMT Subject: [crac] RFR: Merge jdk:jdk-25+26 [v4] In-Reply-To: References: <8s5ymOREBNkrHIH_me6UxsNK6QjhJ9VsUPWPrYFNOIY=.74bc9410-d039-40ee-bc17-d5f1e3833ae2@github.com> Message-ID: On Fri, 25 Jul 2025 12:50:11 GMT, Dmitry Cherepanov wrote: >> Since the merge for [JDK-8352675](https://bugs.openjdk.org/browse/JDK-8352675) is split into a separate PR (https://github.com/openjdk/crac/pull/247), I cherry-picked the current version and merging other changes on top of it. It will likely require rebase on top of the final version later. >> >> Attaching output of `--diff-merges=remerge` >> >>
>> >> Conflicts >> >> >> commit 5035f463900712ae47b7e1adfeff609bc1d66116 (HEAD -> merge-jdk, dmitry-crac/merge-jdk) >> Merge: d61227fe01d c59e44a7aa2 >> Author: Dmitry Cherepanov >> Date: Tue Jul 22 13:30:47 2025 +0400 >> >> Merge with jdk-25+26 >> >> diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml >> remerge CONFLICT (content): Merge conflict in .github/workflows/main.yml >> index 8cf745c1cff..02c6f3d2668 100644 >> --- a/.github/workflows/main.yml >> +++ b/.github/workflows/main.yml >> @@ -310,11 +310,7 @@ jobs: >> uses: ./.github/workflows/build-windows.yml >> with: >> platform: windows-x64 >> -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) >> msvc-toolset-version: '14.44' >> -======= >> - msvc-toolset-version: '14.43' >> ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) >> msvc-toolset-architecture: 'x86.x64' >> configure-arguments: ${{ github.event.inputs.configure-arguments }} >> make-arguments: ${{ github.event.inputs.make-arguments }} >> @@ -326,11 +322,7 @@ jobs: >> uses: ./.github/workflows/build-windows.yml >> with: >> platform: windows-aarch64 >> -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) >> msvc-toolset-version: '14.44' >> -======= >> - msvc-toolset-version: '14.43' >> ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) >> msvc-toolset-architecture: 'arm64' >> make-target: 'hotspot' >> extra-conf-options: '--openjdk-target=aarch64-unknown-cygwin' >> @@ -369,17 +361,17 @@ jobs: >> runs-on: ubuntu-22.04 >> debug-suffix: -debug >> >> - test-linux-x64-static: >> - name: linux-x64-static >> - needs: >> - - build-linux-x64 >> - - build-linux-x64-static >> - uses: ./.github/workflows/test.yml >> - with: >> - platform: linux-x64 >> - bootjdk-platform: linux-x64 >> - runs-on: ubuntu-22.04 >> - static-suffix: "-st... > > Dmitry Cherepanov has updated the pull request incrementally with one additional commit since the last revision: > > cleanup #250 for the CPUFeatures has been approved. ------------- PR Comment: https://git.openjdk.org/crac/pull/248#issuecomment-3126565014 From dcherepanov at openjdk.org Mon Jul 28 10:52:45 2025 From: dcherepanov at openjdk.org (Dmitry Cherepanov) Date: Mon, 28 Jul 2025 10:52:45 GMT Subject: [crac] RFR: Merge jdk:jdk-25+26 [v5] In-Reply-To: <8s5ymOREBNkrHIH_me6UxsNK6QjhJ9VsUPWPrYFNOIY=.74bc9410-d039-40ee-bc17-d5f1e3833ae2@github.com> References: <8s5ymOREBNkrHIH_me6UxsNK6QjhJ9VsUPWPrYFNOIY=.74bc9410-d039-40ee-bc17-d5f1e3833ae2@github.com> Message-ID: > Since the merge for [JDK-8352675](https://bugs.openjdk.org/browse/JDK-8352675) is split into a separate PR (https://github.com/openjdk/crac/pull/247), I cherry-picked the current version and merging other changes on top of it. It will likely require rebase on top of the final version later. > > Attaching output of `--diff-merges=remerge` > >
> > Conflicts > > > commit 5035f463900712ae47b7e1adfeff609bc1d66116 (HEAD -> merge-jdk, dmitry-crac/merge-jdk) > Merge: d61227fe01d c59e44a7aa2 > Author: Dmitry Cherepanov > Date: Tue Jul 22 13:30:47 2025 +0400 > > Merge with jdk-25+26 > > diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml > remerge CONFLICT (content): Merge conflict in .github/workflows/main.yml > index 8cf745c1cff..02c6f3d2668 100644 > --- a/.github/workflows/main.yml > +++ b/.github/workflows/main.yml > @@ -310,11 +310,7 @@ jobs: > uses: ./.github/workflows/build-windows.yml > with: > platform: windows-x64 > -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) > msvc-toolset-version: '14.44' > -======= > - msvc-toolset-version: '14.43' > ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) > msvc-toolset-architecture: 'x86.x64' > configure-arguments: ${{ github.event.inputs.configure-arguments }} > make-arguments: ${{ github.event.inputs.make-arguments }} > @@ -326,11 +322,7 @@ jobs: > uses: ./.github/workflows/build-windows.yml > with: > platform: windows-aarch64 > -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) > msvc-toolset-version: '14.44' > -======= > - msvc-toolset-version: '14.43' > ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) > msvc-toolset-architecture: 'arm64' > make-target: 'hotspot' > extra-conf-options: '--openjdk-target=aarch64-unknown-cygwin' > @@ -369,17 +361,17 @@ jobs: > runs-on: ubuntu-22.04 > debug-suffix: -debug > > - test-linux-x64-static: > - name: linux-x64-static > - needs: > - - build-linux-x64 > - - build-linux-x64-static > - uses: ./.github/workflows/test.yml > - with: > - platform: linux-x64 > - bootjdk-platform: linux-x64 > - runs-on: ubuntu-22.04 > - static-suffix: "-static" > +# test-linux-x64-static: > +# name: linux-x64-static > +# needs: > +# - build-linux-x64 > +# - build-lin... Dmitry Cherepanov has updated the pull request incrementally with 20 additional commits since the last revision: - Merge branch 'pull/250' into merge-jdk - Fix leading ", " - Fix the message: VM option 'CPUFeatures=%s' must be of the form - fix MS-Windows compilation - buf__features -> buf_features - Update (*data).print_numbers - fix ups of VM_Version::missing_features - whitespace fix - fix -XX:CPUFeatures parsing and its error message - remove - ... and 10 more: https://git.openjdk.org/crac/compare/322282a8...5041060a ------------- Changes: - all: https://git.openjdk.org/crac/pull/248/files - new: https://git.openjdk.org/crac/pull/248/files/322282a8..5041060a Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=248&range=04 - incr: https://webrevs.openjdk.org/?repo=crac&pr=248&range=03-04 Stats: 609 lines in 13 files changed: 195 ins; 170 del; 244 mod Patch: https://git.openjdk.org/crac/pull/248.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/248/head:pull/248 PR: https://git.openjdk.org/crac/pull/248 From dcherepanov at openjdk.org Mon Jul 28 10:52:45 2025 From: dcherepanov at openjdk.org (Dmitry Cherepanov) Date: Mon, 28 Jul 2025 10:52:45 GMT Subject: [crac] RFR: Merge jdk:jdk-25+26 [v4] In-Reply-To: References: <8s5ymOREBNkrHIH_me6UxsNK6QjhJ9VsUPWPrYFNOIY=.74bc9410-d039-40ee-bc17-d5f1e3833ae2@github.com> Message-ID: On Mon, 28 Jul 2025 10:23:33 GMT, Jan Kratochvil wrote: > #250 for the CPUFeatures has been approved. Thanks. I've merged changes from https://github.com/openjdk/crac/pull/250 into this MR. Alternatively, we can update https://github.com/openjdk/crac/pull/250 with recent changes from this MR. ------------- PR Comment: https://git.openjdk.org/crac/pull/248#issuecomment-3126649645 From tpushkin at openjdk.org Mon Jul 28 11:29:23 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Mon, 28 Jul 2025 11:29:23 GMT Subject: [crac] RFR: Merge jdk:jdk-25+26 [v5] In-Reply-To: References: <8s5ymOREBNkrHIH_me6UxsNK6QjhJ9VsUPWPrYFNOIY=.74bc9410-d039-40ee-bc17-d5f1e3833ae2@github.com> Message-ID: On Mon, 28 Jul 2025 10:52:45 GMT, Dmitry Cherepanov wrote: >> Since the merge for [JDK-8352675](https://bugs.openjdk.org/browse/JDK-8352675) is split into a separate PR (https://github.com/openjdk/crac/pull/247), I cherry-picked the current version and merging other changes on top of it. It will likely require rebase on top of the final version later. >> >> Attaching output of `--diff-merges=remerge` >> >>
>> >> Conflicts >> >> >> commit 5035f463900712ae47b7e1adfeff609bc1d66116 (HEAD -> merge-jdk, dmitry-crac/merge-jdk) >> Merge: d61227fe01d c59e44a7aa2 >> Author: Dmitry Cherepanov >> Date: Tue Jul 22 13:30:47 2025 +0400 >> >> Merge with jdk-25+26 >> >> diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml >> remerge CONFLICT (content): Merge conflict in .github/workflows/main.yml >> index 8cf745c1cff..02c6f3d2668 100644 >> --- a/.github/workflows/main.yml >> +++ b/.github/workflows/main.yml >> @@ -310,11 +310,7 @@ jobs: >> uses: ./.github/workflows/build-windows.yml >> with: >> platform: windows-x64 >> -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) >> msvc-toolset-version: '14.44' >> -======= >> - msvc-toolset-version: '14.43' >> ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) >> msvc-toolset-architecture: 'x86.x64' >> configure-arguments: ${{ github.event.inputs.configure-arguments }} >> make-arguments: ${{ github.event.inputs.make-arguments }} >> @@ -326,11 +322,7 @@ jobs: >> uses: ./.github/workflows/build-windows.yml >> with: >> platform: windows-aarch64 >> -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) >> msvc-toolset-version: '14.44' >> -======= >> - msvc-toolset-version: '14.43' >> ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) >> msvc-toolset-architecture: 'arm64' >> make-target: 'hotspot' >> extra-conf-options: '--openjdk-target=aarch64-unknown-cygwin' >> @@ -369,17 +361,17 @@ jobs: >> runs-on: ubuntu-22.04 >> debug-suffix: -debug >> >> - test-linux-x64-static: >> - name: linux-x64-static >> - needs: >> - - build-linux-x64 >> - - build-linux-x64-static >> - uses: ./.github/workflows/test.yml >> - with: >> - platform: linux-x64 >> - bootjdk-platform: linux-x64 >> - runs-on: ubuntu-22.04 >> - static-suffix: "-st... > > Dmitry Cherepanov has updated the pull request incrementally with 20 additional commits since the last revision: > > - Merge branch 'pull/250' into merge-jdk > - Fix leading ", " > - Fix the message: VM option 'CPUFeatures=%s' must be of the form > - fix MS-Windows compilation > - buf__features -> buf_features > - Update (*data).print_numbers > - fix ups of VM_Version::missing_features > - whitespace fix > - fix -XX:CPUFeatures parsing and its error message > - remove > - ... and 10 more: https://git.openjdk.org/crac/compare/322282a8...5041060a The merge should've been clean so I am re-approving without additional review. I think we should integrate this PR since Jan's changes are basically a part of the conflict resolution process. Do I understand correctly that all of out commits (Dmitry's and Jan's) will be squashed into a single merge commit upon integration? Would be confusing to have them as separate commits. ------------- Marked as reviewed by tpushkin (Committer). PR Review: https://git.openjdk.org/crac/pull/248#pullrequestreview-3062087440 From jkratochvil at openjdk.org Mon Jul 28 11:29:23 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Mon, 28 Jul 2025 11:29:23 GMT Subject: [crac] RFR: Merge jdk:jdk-25+26 [v5] In-Reply-To: References: <8s5ymOREBNkrHIH_me6UxsNK6QjhJ9VsUPWPrYFNOIY=.74bc9410-d039-40ee-bc17-d5f1e3833ae2@github.com> Message-ID: <_IMYhisfgbqwLBmJAjJrlljO3CYh237kOifZNJXizIY=.d25d5bcd-a4bb-460b-ae2a-69c9fb7e3b0a@github.com> On Mon, 28 Jul 2025 10:52:45 GMT, Dmitry Cherepanov wrote: >> Since the merge for [JDK-8352675](https://bugs.openjdk.org/browse/JDK-8352675) is split into a separate PR (https://github.com/openjdk/crac/pull/247), I cherry-picked the current version and merging other changes on top of it. It will likely require rebase on top of the final version later. >> >> Attaching output of `--diff-merges=remerge` >> >>
>> >> Conflicts >> >> >> commit 5035f463900712ae47b7e1adfeff609bc1d66116 (HEAD -> merge-jdk, dmitry-crac/merge-jdk) >> Merge: d61227fe01d c59e44a7aa2 >> Author: Dmitry Cherepanov >> Date: Tue Jul 22 13:30:47 2025 +0400 >> >> Merge with jdk-25+26 >> >> diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml >> remerge CONFLICT (content): Merge conflict in .github/workflows/main.yml >> index 8cf745c1cff..02c6f3d2668 100644 >> --- a/.github/workflows/main.yml >> +++ b/.github/workflows/main.yml >> @@ -310,11 +310,7 @@ jobs: >> uses: ./.github/workflows/build-windows.yml >> with: >> platform: windows-x64 >> -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) >> msvc-toolset-version: '14.44' >> -======= >> - msvc-toolset-version: '14.43' >> ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) >> msvc-toolset-architecture: 'x86.x64' >> configure-arguments: ${{ github.event.inputs.configure-arguments }} >> make-arguments: ${{ github.event.inputs.make-arguments }} >> @@ -326,11 +322,7 @@ jobs: >> uses: ./.github/workflows/build-windows.yml >> with: >> platform: windows-aarch64 >> -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) >> msvc-toolset-version: '14.44' >> -======= >> - msvc-toolset-version: '14.43' >> ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) >> msvc-toolset-architecture: 'arm64' >> make-target: 'hotspot' >> extra-conf-options: '--openjdk-target=aarch64-unknown-cygwin' >> @@ -369,17 +361,17 @@ jobs: >> runs-on: ubuntu-22.04 >> debug-suffix: -debug >> >> - test-linux-x64-static: >> - name: linux-x64-static >> - needs: >> - - build-linux-x64 >> - - build-linux-x64-static >> - uses: ./.github/workflows/test.yml >> - with: >> - platform: linux-x64 >> - bootjdk-platform: linux-x64 >> - runs-on: ubuntu-22.04 >> - static-suffix: "-st... > > Dmitry Cherepanov has updated the pull request incrementally with 20 additional commits since the last revision: > > - Merge branch 'pull/250' into merge-jdk > - Fix leading ", " > - Fix the message: VM option 'CPUFeatures=%s' must be of the form > - fix MS-Windows compilation > - buf__features -> buf_features > - Update (*data).print_numbers > - fix ups of VM_Version::missing_features > - whitespace fix > - fix -XX:CPUFeatures parsing and its error message > - remove > - ... and 10 more: https://git.openjdk.org/crac/compare/322282a8...5041060a So I am going to close #250. ------------- PR Comment: https://git.openjdk.org/crac/pull/248#issuecomment-3126781912 From dcherepanov at openjdk.org Mon Jul 28 13:11:23 2025 From: dcherepanov at openjdk.org (Dmitry Cherepanov) Date: Mon, 28 Jul 2025 13:11:23 GMT Subject: [crac] RFR: Merge jdk:jdk-25+26 [v5] In-Reply-To: References: <8s5ymOREBNkrHIH_me6UxsNK6QjhJ9VsUPWPrYFNOIY=.74bc9410-d039-40ee-bc17-d5f1e3833ae2@github.com> Message-ID: On Mon, 28 Jul 2025 11:26:26 GMT, Timofei Pushkin wrote: > The merge should've been clean so I am re-approving without additional review. I think we should integrate this PR since Jan's changes are basically a part of the conflict resolution process. Right, it's a clean merge. > Do I understand correctly that all of out commits (Dmitry's and Jan's) will be squashed into a single merge commit upon integration? Would be confusing to have them as separate commits. Looks like all commits should be squashed into one commit according to https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands#PullRequestCommands-/integrate ------------- PR Comment: https://git.openjdk.org/crac/pull/248#issuecomment-3127174550 From dcherepanov at openjdk.org Mon Jul 28 13:29:15 2025 From: dcherepanov at openjdk.org (Dmitry Cherepanov) Date: Mon, 28 Jul 2025 13:29:15 GMT Subject: [crac] RFR: Merge jdk:jdk-25+26 [v5] In-Reply-To: References: <8s5ymOREBNkrHIH_me6UxsNK6QjhJ9VsUPWPrYFNOIY=.74bc9410-d039-40ee-bc17-d5f1e3833ae2@github.com> Message-ID: On Mon, 28 Jul 2025 10:52:45 GMT, Dmitry Cherepanov wrote: >> Since the merge for [JDK-8352675](https://bugs.openjdk.org/browse/JDK-8352675) is split into a separate PR (https://github.com/openjdk/crac/pull/247), I cherry-picked the current version and merging other changes on top of it. It will likely require rebase on top of the final version later. >> >> Attaching output of `--diff-merges=remerge` >> >>
>> >> Conflicts >> >> >> commit 5035f463900712ae47b7e1adfeff609bc1d66116 (HEAD -> merge-jdk, dmitry-crac/merge-jdk) >> Merge: d61227fe01d c59e44a7aa2 >> Author: Dmitry Cherepanov >> Date: Tue Jul 22 13:30:47 2025 +0400 >> >> Merge with jdk-25+26 >> >> diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml >> remerge CONFLICT (content): Merge conflict in .github/workflows/main.yml >> index 8cf745c1cff..02c6f3d2668 100644 >> --- a/.github/workflows/main.yml >> +++ b/.github/workflows/main.yml >> @@ -310,11 +310,7 @@ jobs: >> uses: ./.github/workflows/build-windows.yml >> with: >> platform: windows-x64 >> -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) >> msvc-toolset-version: '14.44' >> -======= >> - msvc-toolset-version: '14.43' >> ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) >> msvc-toolset-architecture: 'x86.x64' >> configure-arguments: ${{ github.event.inputs.configure-arguments }} >> make-arguments: ${{ github.event.inputs.make-arguments }} >> @@ -326,11 +322,7 @@ jobs: >> uses: ./.github/workflows/build-windows.yml >> with: >> platform: windows-aarch64 >> -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) >> msvc-toolset-version: '14.44' >> -======= >> - msvc-toolset-version: '14.43' >> ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) >> msvc-toolset-architecture: 'arm64' >> make-target: 'hotspot' >> extra-conf-options: '--openjdk-target=aarch64-unknown-cygwin' >> @@ -369,17 +361,17 @@ jobs: >> runs-on: ubuntu-22.04 >> debug-suffix: -debug >> >> - test-linux-x64-static: >> - name: linux-x64-static >> - needs: >> - - build-linux-x64 >> - - build-linux-x64-static >> - uses: ./.github/workflows/test.yml >> - with: >> - platform: linux-x64 >> - bootjdk-platform: linux-x64 >> - runs-on: ubuntu-22.04 >> - static-suffix: "-st... > > Dmitry Cherepanov has updated the pull request incrementally with 20 additional commits since the last revision: > > - Merge branch 'pull/250' into merge-jdk > - Fix leading ", " > - Fix the message: VM option 'CPUFeatures=%s' must be of the form > - fix MS-Windows compilation > - buf__features -> buf_features > - Update (*data).print_numbers > - fix ups of VM_Version::missing_features > - whitespace fix > - fix -XX:CPUFeatures parsing and its error message > - remove > - ... and 10 more: https://git.openjdk.org/crac/compare/322282a8...5041060a Usually openbot adds a comment with a preview of the commit message > After integration, the commit message for the final commit will be: > ? For some reason, I don't see similar comment for this PR but I expect the commit message to be in the same format as for other Merge PRs ------------- PR Comment: https://git.openjdk.org/crac/pull/248#issuecomment-3127226691 From duke at openjdk.org Mon Jul 28 13:29:15 2025 From: duke at openjdk.org (duke) Date: Mon, 28 Jul 2025 13:29:15 GMT Subject: [crac] RFR: Merge jdk:jdk-25+26 [v5] In-Reply-To: References: <8s5ymOREBNkrHIH_me6UxsNK6QjhJ9VsUPWPrYFNOIY=.74bc9410-d039-40ee-bc17-d5f1e3833ae2@github.com> Message-ID: On Mon, 28 Jul 2025 10:52:45 GMT, Dmitry Cherepanov wrote: >> Since the merge for [JDK-8352675](https://bugs.openjdk.org/browse/JDK-8352675) is split into a separate PR (https://github.com/openjdk/crac/pull/247), I cherry-picked the current version and merging other changes on top of it. It will likely require rebase on top of the final version later. >> >> Attaching output of `--diff-merges=remerge` >> >>
>> >> Conflicts >> >> >> commit 5035f463900712ae47b7e1adfeff609bc1d66116 (HEAD -> merge-jdk, dmitry-crac/merge-jdk) >> Merge: d61227fe01d c59e44a7aa2 >> Author: Dmitry Cherepanov >> Date: Tue Jul 22 13:30:47 2025 +0400 >> >> Merge with jdk-25+26 >> >> diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml >> remerge CONFLICT (content): Merge conflict in .github/workflows/main.yml >> index 8cf745c1cff..02c6f3d2668 100644 >> --- a/.github/workflows/main.yml >> +++ b/.github/workflows/main.yml >> @@ -310,11 +310,7 @@ jobs: >> uses: ./.github/workflows/build-windows.yml >> with: >> platform: windows-x64 >> -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) >> msvc-toolset-version: '14.44' >> -======= >> - msvc-toolset-version: '14.43' >> ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) >> msvc-toolset-architecture: 'x86.x64' >> configure-arguments: ${{ github.event.inputs.configure-arguments }} >> make-arguments: ${{ github.event.inputs.make-arguments }} >> @@ -326,11 +322,7 @@ jobs: >> uses: ./.github/workflows/build-windows.yml >> with: >> platform: windows-aarch64 >> -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) >> msvc-toolset-version: '14.44' >> -======= >> - msvc-toolset-version: '14.43' >> ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) >> msvc-toolset-architecture: 'arm64' >> make-target: 'hotspot' >> extra-conf-options: '--openjdk-target=aarch64-unknown-cygwin' >> @@ -369,17 +361,17 @@ jobs: >> runs-on: ubuntu-22.04 >> debug-suffix: -debug >> >> - test-linux-x64-static: >> - name: linux-x64-static >> - needs: >> - - build-linux-x64 >> - - build-linux-x64-static >> - uses: ./.github/workflows/test.yml >> - with: >> - platform: linux-x64 >> - bootjdk-platform: linux-x64 >> - runs-on: ubuntu-22.04 >> - static-suffix: "-st... > > Dmitry Cherepanov has updated the pull request incrementally with 20 additional commits since the last revision: > > - Merge branch 'pull/250' into merge-jdk > - Fix leading ", " > - Fix the message: VM option 'CPUFeatures=%s' must be of the form > - fix MS-Windows compilation > - buf__features -> buf_features > - Update (*data).print_numbers > - fix ups of VM_Version::missing_features > - whitespace fix > - fix -XX:CPUFeatures parsing and its error message > - remove > - ... and 10 more: https://git.openjdk.org/crac/compare/322282a8...5041060a @dimitryc Your change (at version 5041060af03f6240c18021561ba7a66525434a2b) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/crac/pull/248#issuecomment-3127232640 From tpushkin at openjdk.org Mon Jul 28 13:53:13 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Mon, 28 Jul 2025 13:53:13 GMT Subject: [crac] RFR: Merge jdk:jdk-25+26 [v5] In-Reply-To: References: <8s5ymOREBNkrHIH_me6UxsNK6QjhJ9VsUPWPrYFNOIY=.74bc9410-d039-40ee-bc17-d5f1e3833ae2@github.com> Message-ID: On Mon, 28 Jul 2025 13:23:02 GMT, Dmitry Cherepanov wrote: >> Dmitry Cherepanov has updated the pull request incrementally with 20 additional commits since the last revision: >> >> - Merge branch 'pull/250' into merge-jdk >> - Fix leading ", " >> - Fix the message: VM option 'CPUFeatures=%s' must be of the form >> - fix MS-Windows compilation >> - buf__features -> buf_features >> - Update (*data).print_numbers >> - fix ups of VM_Version::missing_features >> - whitespace fix >> - fix -XX:CPUFeatures parsing and its error message >> - remove >> - ... and 10 more: https://git.openjdk.org/crac/compare/322282a8...5041060a > > Usually openbot adds a comment with a preview of the commit message > >> After integration, the commit message for the final commit will be: >> ? > > For some reason, I don't see similar comment for this PR but I expect the commit message to be in the same format as for other Merge PRs @dimitryc Here is the summary message, it is just hidden because there's a lot of messages: https://github.com/openjdk/crac/pull/248#issuecomment-3109588887 ------------- PR Comment: https://git.openjdk.org/crac/pull/248#issuecomment-3127339488 From dcherepanov at openjdk.org Mon Jul 28 14:08:27 2025 From: dcherepanov at openjdk.org (Dmitry Cherepanov) Date: Mon, 28 Jul 2025 14:08:27 GMT Subject: [crac] Integrated: Merge jdk:jdk-25+26 In-Reply-To: <8s5ymOREBNkrHIH_me6UxsNK6QjhJ9VsUPWPrYFNOIY=.74bc9410-d039-40ee-bc17-d5f1e3833ae2@github.com> References: <8s5ymOREBNkrHIH_me6UxsNK6QjhJ9VsUPWPrYFNOIY=.74bc9410-d039-40ee-bc17-d5f1e3833ae2@github.com> Message-ID: On Wed, 23 Jul 2025 17:58:09 GMT, Dmitry Cherepanov wrote: > Since the merge for [JDK-8352675](https://bugs.openjdk.org/browse/JDK-8352675) is split into a separate PR (https://github.com/openjdk/crac/pull/247), I cherry-picked the current version and merging other changes on top of it. It will likely require rebase on top of the final version later. > > Attaching output of `--diff-merges=remerge` > >
> > Conflicts > > > commit 5035f463900712ae47b7e1adfeff609bc1d66116 (HEAD -> merge-jdk, dmitry-crac/merge-jdk) > Merge: d61227fe01d c59e44a7aa2 > Author: Dmitry Cherepanov > Date: Tue Jul 22 13:30:47 2025 +0400 > > Merge with jdk-25+26 > > diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml > remerge CONFLICT (content): Merge conflict in .github/workflows/main.yml > index 8cf745c1cff..02c6f3d2668 100644 > --- a/.github/workflows/main.yml > +++ b/.github/workflows/main.yml > @@ -310,11 +310,7 @@ jobs: > uses: ./.github/workflows/build-windows.yml > with: > platform: windows-x64 > -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) > msvc-toolset-version: '14.44' > -======= > - msvc-toolset-version: '14.43' > ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) > msvc-toolset-architecture: 'x86.x64' > configure-arguments: ${{ github.event.inputs.configure-arguments }} > make-arguments: ${{ github.event.inputs.make-arguments }} > @@ -326,11 +322,7 @@ jobs: > uses: ./.github/workflows/build-windows.yml > with: > platform: windows-aarch64 > -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection) > msvc-toolset-version: '14.44' > -======= > - msvc-toolset-version: '14.43' > ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual) > msvc-toolset-architecture: 'arm64' > make-target: 'hotspot' > extra-conf-options: '--openjdk-target=aarch64-unknown-cygwin' > @@ -369,17 +361,17 @@ jobs: > runs-on: ubuntu-22.04 > debug-suffix: -debug > > - test-linux-x64-static: > - name: linux-x64-static > - needs: > - - build-linux-x64 > - - build-linux-x64-static > - uses: ./.github/workflows/test.yml > - with: > - platform: linux-x64 > - bootjdk-platform: linux-x64 > - runs-on: ubuntu-22.04 > - static-suffix: "-static" > +# test-linux-x64-static: > +# name: linux-x64-static > +# needs: > +# - build-linux-x64 > +# - build-lin... This pull request has now been integrated. Changeset: dddb8e0d Author: Dmitry Cherepanov Committer: Timofei Pushkin URL: https://git.openjdk.org/crac/commit/dddb8e0dcd64ce4a6d325bca551ff22ca9c266c3 Stats: 167455 lines in 2905 files changed: 99582 ins; 45998 del; 21875 mod Merge jdk:jdk-25+26 Co-authored-by: Jan Kratochvil Co-authored-by: Timofei Pushkin Reviewed-by: tpushkin ------------- PR: https://git.openjdk.org/crac/pull/248 From tpushkin at openjdk.org Mon Jul 28 14:10:16 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Mon, 28 Jul 2025 14:10:16 GMT Subject: [crac] RFR: 8352675: Support Intel AVX10 converged vector ISA feature detection In-Reply-To: References: Message-ID: <8rBoYYlfG46J2An_5ykMsKMzdjO5LL-Xd6LoeTgImiY=.e0f084fb-0a5b-4cc6-b2ea-911f0989c150@github.com> On Mon, 21 Jul 2025 18:19:49 GMT, Jan Kratochvil wrote: > This is the merge of the single commit [3b336a9da091c4df4373d2b845b60d2a7a4e3b1d](https://github.com/openjdk/jdk/commit/3b336a9da091c4df4373d2b845b60d2a7a4e3b1d) which also disables CPUFeatures. Closing as integrated as part of #248 ------------- PR Comment: https://git.openjdk.org/crac/pull/247#issuecomment-3127405724 From tpushkin at openjdk.org Mon Jul 28 14:10:17 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Mon, 28 Jul 2025 14:10:17 GMT Subject: [crac] Withdrawn: 8352675: Support Intel AVX10 converged vector ISA feature detection In-Reply-To: References: Message-ID: On Mon, 21 Jul 2025 18:19:49 GMT, Jan Kratochvil wrote: > This is the merge of the single commit [3b336a9da091c4df4373d2b845b60d2a7a4e3b1d](https://github.com/openjdk/jdk/commit/3b336a9da091c4df4373d2b845b60d2a7a4e3b1d) which also disables CPUFeatures. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/crac/pull/247 From tpushkin at openjdk.org Mon Jul 28 14:10:22 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Mon, 28 Jul 2025 14:10:22 GMT Subject: [crac] Withdrawn: Fix up CPUFeatures on top of Merge jdk:jdk-25+26 In-Reply-To: References: Message-ID: On Thu, 24 Jul 2025 19:15:41 GMT, Jan Kratochvil wrote: > This pull request contains: https://github.com/openjdk/crac/pull/248 > I think the CRaC project does not provide the pr/NUMBER branches for dependent patches. > > This pull request enables the CPUFeatures again. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/crac/pull/250 From tpushkin at openjdk.org Mon Jul 28 14:10:21 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Mon, 28 Jul 2025 14:10:21 GMT Subject: [crac] RFR: Fix up CPUFeatures on top of Merge jdk:jdk-25+26 [v9] In-Reply-To: References: Message-ID: <8Or9s-OdrxNuh_5v8IXOjE6lI0C9In1Mz6at3wPH3II=.c9da7baa-f1f7-4426-8159-76cd9305bd32@github.com> On Sun, 27 Jul 2025 15:33:20 GMT, Jan Kratochvil wrote: >> This pull request contains: https://github.com/openjdk/crac/pull/248 >> I think the CRaC project does not provide the pr/NUMBER branches for dependent patches. >> >> This pull request enables the CPUFeatures again. > > Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision: > > Fix leading ", " Closing as integrated as part of https://github.com/openjdk/crac/pull/248 ------------- PR Comment: https://git.openjdk.org/crac/pull/250#issuecomment-3127406591 From tpushkin at openjdk.org Tue Jul 29 06:43:20 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Tue, 29 Jul 2025 06:43:20 GMT Subject: [crac] RFR: 8364156: [CRaC] Recompile methods decompiled during or shortly after C/R [v2] In-Reply-To: References: Message-ID: > Implements recording and triggering recompilation of methods decompiled during and shortly after C/R. The length of the "shortly-after" period can be controlled by the user via `-Djdk.crac.recompilation-delay-ms=`, the default is 10ms. > > Measuring the after-restore regression before and after this change shows improvement on hello-world apps. The numbers are the regression of the first after-restore 1 sec iteration vs average over 5 last before-checkpoint 1 sec iterations, i.e. lower means better; mean ? std dev over 30 runs. Measured in a Linux VM on MacOS, with CRIU, with 5ms after-restore recompilation delay. > > | | Before | After | > |--------------------------|-------------|-------------| > | Helidon hello-world | 0.9 ? 1.2 % | 0.4 ? 1.0 % | > | Spring boot CRaC example | 9.5 ? 2.4 % | 6.4 ? 2.5 % | > > Currently decompilations are recorded during C/R + during the after-restore delay and then they all get recompiled together. An enhancement planned in the future is to record only during C/R recompiling immediately after restore and during the after-restore delay recompile immediately without recording. This way the recompilations would finish faster, also setting `jdk.crac.recompilation-delay-ms` to a higher value would have less negative impact. > > Implementation notes: > - Native code (`nmethod`) is considered "decompiled" when `make_not_entrant(...)` is called on it ? a new mandatory parameter is added to the signature of this method that controls whether CRaC should consider this particular decompilation for recompilation or not. > - The parameter is needed because we do not want to recompile, for example, when `nmethod` is thrown away once a replacement for it has been compiled (e.g. on another compilation level). > - The parameter has no default so that we get compilation errors when new calls to `make_not_entrant(...)` are introduced in the mainline ? we will be deciding whether these new calls should be considered for recompilation or not. If CRaC was in the mainline I would enable the recompilation by default. > - The new native `CRaCRecorder` class is the core of the implementation ? it records the decompilations and handles their recompilation. > - `jdk.crac.internal.mirror.Core` notifies it when to start and stop the recording, it also handles the after-restore recompilation delay. > - `nmethod.make_not_entrant(...)` notifies it about decompiled code. Timofei Pushkin has updated the pull request incrementally with five additional commits since the last revision: - Implement flag-related review suggestions - Cleanup tests - Remove erroneously added assert - Bring back erroneously removed locking - Fix RedefineClasses defence ------------- Changes: - all: https://git.openjdk.org/crac/pull/251/files - new: https://git.openjdk.org/crac/pull/251/files/a1be69c2..536ce035 Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=251&range=01 - incr: https://webrevs.openjdk.org/?repo=crac&pr=251&range=00-01 Stats: 429 lines in 7 files changed: 208 ins; 167 del; 54 mod Patch: https://git.openjdk.org/crac/pull/251.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/251/head:pull/251 PR: https://git.openjdk.org/crac/pull/251 From rvansa at openjdk.org Tue Jul 29 06:43:20 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 29 Jul 2025 06:43:20 GMT Subject: [crac] RFR: 8364156: [CRaC] Recompile methods decompiled during or shortly after C/R [v2] In-Reply-To: References: Message-ID: On Tue, 29 Jul 2025 06:39:09 GMT, Timofei Pushkin wrote: >> Implements recording and triggering recompilation of methods decompiled during and shortly after C/R. The length of the "shortly-after" period can be controlled by the user via `-Djdk.crac.recompilation-delay-ms=`, the default is 10ms. >> >> Measuring the after-restore regression before and after this change shows improvement on hello-world apps. The numbers are the regression of the first after-restore 1 sec iteration vs average over 5 last before-checkpoint 1 sec iterations, i.e. lower means better; mean ? std dev over 30 runs. Measured in a Linux VM on MacOS, with CRIU, with 5ms after-restore recompilation delay. >> >> | | Before | After | >> |--------------------------|-------------|-------------| >> | Helidon hello-world | 0.9 ? 1.2 % | 0.4 ? 1.0 % | >> | Spring boot CRaC example | 9.5 ? 2.4 % | 6.4 ? 2.5 % | >> >> Currently decompilations are recorded during C/R + during the after-restore delay and then they all get recompiled together. An enhancement planned in the future is to record only during C/R recompiling immediately after restore and during the after-restore delay recompile immediately without recording. This way the recompilations would finish faster, also setting `jdk.crac.recompilation-delay-ms` to a higher value would have less negative impact. >> >> Implementation notes: >> - Native code (`nmethod`) is considered "decompiled" when `make_not_entrant(...)` is called on it ? a new mandatory parameter is added to the signature of this method that controls whether CRaC should consider this particular decompilation for recompilation or not. >> - The parameter is needed because we do not want to recompile, for example, when `nmethod` is thrown away once a replacement for it has been compiled (e.g. on another compilation level). >> - The parameter has no default so that we get compilation errors when new calls to `make_not_entrant(...)` are introduced in the mainline ? we will be deciding whether these new calls should be considered for recompilation or not. If CRaC was in the mainline I would enable the recompilation by default. >> - The new native `CRaCRecorder` class is the core of the implementation ? it records the decompilations and handles their recompilation. >> - `jdk.crac.internal.mirror.Core` notifies it when to start and stop the recording, it also handles the after-restore recompilation delay. >> - `nmethod.make_not_entrant(...)` notifies it about decompiled code. > > Timofei Pushkin has updated the pull request incrementally with five additional commits since the last revision: > > - Implement flag-related review suggestions > - Cleanup tests > - Remove erroneously added assert > - Bring back erroneously removed locking > - Fix RedefineClasses defence Great work! We shall give some thought to the possible timing issues in the tests, as timing-related failures in the testsuite are really annoying. src/hotspot/share/runtime/cracRecompiler.cpp line 151: > 149: } > 150: const MutexLocker ml(decompilations_lock, Mutex::_no_safepoint_check_flag); > 151: auto * const decomps = const_cast *>(decompilations); Do you really need the `const_cast` here? I wonder why you use `GrowableArrayCHeap<...> * const` here and `const GrowableArrayCHeap<...> *` in the next function (or am I misinterpreting the `auto` use?) src/hotspot/share/runtime/cracRecompiler.cpp line 198: > 196: assert(decompilations != nullptr, "unexpected state: is_recording = %s, decompilations = %p", > 197: BOOL_TO_STR(is_recording), decompilations); > 198: decompilations->append(new CompilationInfo(nmethod.method(), Would it be problematic to make `CompilationInfo` copy-able, rather than allocating each element individually? src/java.base/share/classes/jdk/internal/crac/mirror/Core.java line 70: > 68: public static final boolean TRACE_STARTUP_TIME = > 69: Boolean.getBoolean("jdk.crac.trace-startup-time"); > 70: public static final long RECOMPILATION_DELAY_MS = I am thinking about an option for the 'old behaviour', at least for some testing. Could you interpret negative values as "don't disable the recompilations at all"? And another thing: by putting this into a static variable you're fixing the value at checkpoint time. I believe it would be better if we could adjust this on restore (I think that at the point where you use this the system properties are already updated). Naturally if the recompilations were not disabled through a negative value this should have not effect but a warning being printed out. test/jdk/jdk/crac/recompiler/NaturalDecompilationTest.java line 120: > 118: } > 119: try { > 120: Thread.sleep(500); // Time to compile I think this has some potential for false positives in the testsuite. I guess there is no API in whitebox to wait until this is observed? Alternatively watching the output in `test()` and signaling the process somehow... test/jdk/jdk/crac/recompiler/RecompilationDelayTest.java line 96: > 94: > 95: @Override > 96: public void beforeCheckpoint(Context context) throws Exception {} total nitpick: you can remove the `throws Exception`... test/jdk/jdk/crac/recompiler/RecompilationDelayTest.java line 115: > 113: > 114: if (delayMs > 0) { > 115: assertEquals( 10 seconds sounds like enough, but ideally I would have tests as independent to timing as possible. Are there any timestamps in the compilation log so rather than checking the current time we could just read the logs and run assertions on those? ------------- PR Review: https://git.openjdk.org/crac/pull/251#pullrequestreview-3061259649 PR Review Comment: https://git.openjdk.org/crac/pull/251#discussion_r2235358504 PR Review Comment: https://git.openjdk.org/crac/pull/251#discussion_r2237085852 PR Review Comment: https://git.openjdk.org/crac/pull/251#discussion_r2235606890 PR Review Comment: https://git.openjdk.org/crac/pull/251#discussion_r2235585317 PR Review Comment: https://git.openjdk.org/crac/pull/251#discussion_r2235626356 PR Review Comment: https://git.openjdk.org/crac/pull/251#discussion_r2235662916 From tpushkin at openjdk.org Tue Jul 29 06:43:20 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Tue, 29 Jul 2025 06:43:20 GMT Subject: [crac] RFR: 8364156: [CRaC] Recompile methods decompiled during or shortly after C/R [v2] In-Reply-To: References: Message-ID: <5-VP5AOjIpeRRqwgvgKdDebbjQt04cKS29gvx7dxSIU=.435b7e10-be21-4477-a377-e8ba7c72eb82@github.com> On Mon, 28 Jul 2025 08:42:08 GMT, Radim Vansa wrote: >> Timofei Pushkin has updated the pull request incrementally with five additional commits since the last revision: >> >> - Implement flag-related review suggestions >> - Cleanup tests >> - Remove erroneously added assert >> - Bring back erroneously removed locking >> - Fix RedefineClasses defence > > src/hotspot/share/runtime/cracRecompiler.cpp line 151: > >> 149: } >> 150: const MutexLocker ml(decompilations_lock, Mutex::_no_safepoint_check_flag); >> 151: auto * const decomps = const_cast *>(decompilations); > > Do you really need the `const_cast` here? I wonder why you use `GrowableArrayCHeap<...> * const` here and `const GrowableArrayCHeap<...> *` in the next function (or am I misinterpreting the `auto` use?) That was actually to cast-away `volatile` because it should not be needed under the lock. I am now rewriting this while fixing https://github.com/openjdk/crac/pull/251#discussion_r2235008362 so it will disappear. > src/hotspot/share/runtime/cracRecompiler.cpp line 198: > >> 196: assert(decompilations != nullptr, "unexpected state: is_recording = %s, decompilations = %p", >> 197: BOOL_TO_STR(is_recording), decompilations); >> 198: decompilations->append(new CompilationInfo(nmethod.method(), > > Would it be problematic to make `CompilationInfo` copy-able, rather than allocating each element individually? It can be done but `_klass_holder` field complicates things. As I see it, it will be either inefficient (fill `_klass_holder` in the temporary, then do it again in `_klass_holder` ? an excess allocation of a weak handle) or ugly (don't initiate `_klass_holder` by default, add a method to initiate it, call it on the non-temporary ? until this method is called the object is in a weird semi-initialized state). I would prefer to just leave it as is. It is sad that `GrowableArray` and HotSpot in general do not support move semantics... > src/java.base/share/classes/jdk/internal/crac/mirror/Core.java line 70: > >> 68: public static final boolean TRACE_STARTUP_TIME = >> 69: Boolean.getBoolean("jdk.crac.trace-startup-time"); >> 70: public static final long RECOMPILATION_DELAY_MS = > > I am thinking about an option for the 'old behaviour', at least for some testing. Could you interpret negative values as "don't disable the recompilations at all"? > > And another thing: by putting this into a static variable you're fixing the value at checkpoint time. I believe it would be better if we could adjust this on restore (I think that at the point where you use this the system properties are already updated). Naturally if the recompilations were not disabled through a negative value this should have not effect but a warning being printed out. There are two properties now: - `jdk.crac.enable-recompilation` ? setting it to false enables the old behavior, it is static final because letting it change at runtime would complicate things and I don't think it is so much needed - `jdk.crac.recompilation-delay-ms` ? same as before but can be changed at runtime, a warning is printed if it is set when `jdk.crac.enable-recompilation` is false > test/jdk/jdk/crac/recompiler/NaturalDecompilationTest.java line 120: > >> 118: } >> 119: try { >> 120: Thread.sleep(500); // Time to compile > > I think this has some potential for false positives in the testsuite. I guess there is no API in whitebox to wait until this is observed? Alternatively watching the output in `test()` and signaling the process somehow... I am not sure what kind of false positives can there be, as I see it, in worst case we will just wait longer then necessary. WhiteBox API indeed does not provide a way to wait for a compilation. I could probably indeed make the parent process read `PrintCompilation` from stdout and print to stdin but I am not sure this is needed as it is more complicated. > test/jdk/jdk/crac/recompiler/RecompilationDelayTest.java line 115: > >> 113: >> 114: if (delayMs > 0) { >> 115: assertEquals( > > 10 seconds sounds like enough, but ideally I would have tests as independent to timing as possible. Are there any timestamps in the compilation log so rather than checking the current time we could just read the logs and run assertions on those? I don't think this particular assert can be removed even if we would read logs. It asserts that the machine had time to deoptimize the method before the delay expired. Because if we do it after the delay expires it is expected that there will be no recompilation. Reading logs won't free us from this assert. The only thing I can come up with is to implement some mechanism to relaunch the test (or just the restore part if I implement the request above to make recompilation delay restore-settable) with a higher delay when the test fails this way. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/251#discussion_r2236770641 PR Review Comment: https://git.openjdk.org/crac/pull/251#discussion_r2237407052 PR Review Comment: https://git.openjdk.org/crac/pull/251#discussion_r2237388627 PR Review Comment: https://git.openjdk.org/crac/pull/251#discussion_r2236845446 PR Review Comment: https://git.openjdk.org/crac/pull/251#discussion_r2237161288 From rvansa at openjdk.org Tue Jul 29 06:43:21 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 29 Jul 2025 06:43:21 GMT Subject: [crac] RFR: 8364156: [CRaC] Recompile methods decompiled during or shortly after C/R [v2] In-Reply-To: <5-VP5AOjIpeRRqwgvgKdDebbjQt04cKS29gvx7dxSIU=.435b7e10-be21-4477-a377-e8ba7c72eb82@github.com> References: <5-VP5AOjIpeRRqwgvgKdDebbjQt04cKS29gvx7dxSIU=.435b7e10-be21-4477-a377-e8ba7c72eb82@github.com> Message-ID: <2Tz0WYseV99QNWq-veXwIFxULnAW6h0xEf4UsWLMNm0=.0f4a8d80-bd73-4dfd-a0a9-8f917ec2b2fb@github.com> On Mon, 28 Jul 2025 14:59:16 GMT, Timofei Pushkin wrote: >> test/jdk/jdk/crac/recompiler/NaturalDecompilationTest.java line 120: >> >>> 118: } >>> 119: try { >>> 120: Thread.sleep(500); // Time to compile >> >> I think this has some potential for false positives in the testsuite. I guess there is no API in whitebox to wait until this is observed? Alternatively watching the output in `test()` and signaling the process somehow... > > I am not sure what kind of false positives can there be, as I see it, in worst case we will just wait longer then necessary. > > WhiteBox API indeed does not provide a way to wait for a compilation. I could probably indeed make the parent process read `PrintCompilation` from stdout and print to stdin but I am not sure this is needed as it is more complicated. My bad, I misread this for failing when the method is not compiled but this is just a busy loop (and it won't fail if the first 2000 executions won't trigger recompilation). All is good, then. >> test/jdk/jdk/crac/recompiler/RecompilationDelayTest.java line 115: >> >>> 113: >>> 114: if (delayMs > 0) { >>> 115: assertEquals( >> >> 10 seconds sounds like enough, but ideally I would have tests as independent to timing as possible. Are there any timestamps in the compilation log so rather than checking the current time we could just read the logs and run assertions on those? > > I don't think this particular assert can be removed even if we would read logs. > > It asserts that the machine had time to deoptimize the method before the delay expired. Because if we do it after the delay expires it is expected that there will be no recompilation. Reading logs won't free us from this assert. > > The only thing I can come up with is to implement some mechanism to relaunch the test (or just the restore part if I implement the request above to make recompilation delay restore-settable) with a higher delay when the test fails this way. So this is actually triggering the deoptimization (yes, the method sounds like that, but the error message sounds like it's just checking some statistics)? If the purpose of the test is to check that recompilations won't happen too soon, why is there a difference in the time when you trigger the deoptimization? (for delayMs == 0 this must be in the afterRestore, but why wouldn't you trigger it there even for delayMs > 0?) ------------- PR Review Comment: https://git.openjdk.org/crac/pull/251#discussion_r2237034394 PR Review Comment: https://git.openjdk.org/crac/pull/251#discussion_r2237818802 From tpushkin at openjdk.org Tue Jul 29 06:43:21 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Tue, 29 Jul 2025 06:43:21 GMT Subject: [crac] RFR: 8364156: [CRaC] Recompile methods decompiled during or shortly after C/R [v2] In-Reply-To: <2Tz0WYseV99QNWq-veXwIFxULnAW6h0xEf4UsWLMNm0=.0f4a8d80-bd73-4dfd-a0a9-8f917ec2b2fb@github.com> References: <5-VP5AOjIpeRRqwgvgKdDebbjQt04cKS29gvx7dxSIU=.435b7e10-be21-4477-a377-e8ba7c72eb82@github.com> <2Tz0WYseV99QNWq-veXwIFxULnAW6h0xEf4UsWLMNm0=.0f4a8d80-bd73-4dfd-a0a9-8f917ec2b2fb@github.com> Message-ID: On Mon, 28 Jul 2025 20:37:16 GMT, Radim Vansa wrote: > So this is actually triggering the deoptimization Yes, it triggers the deoptimization. It returns the amount of compilations actually deoptimized (can be zero if the method was not compiled; can be multiple for one method if there were OSR compilations with different entry byte codes, although I believe this overload skips OSRs). > but why wouldn't you trigger it there even for delayMs > 0 Because then the test would succeed even if the delaying code gets removed, i.e. it won't actually be testing that the delay works. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/251#discussion_r2238682711 From tpushkin at openjdk.org Tue Jul 29 06:45:15 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Tue, 29 Jul 2025 06:45:15 GMT Subject: [crac] RFR: 8364156: [CRaC] Recompile methods decompiled during or shortly after C/R [v2] In-Reply-To: References: <5-VP5AOjIpeRRqwgvgKdDebbjQt04cKS29gvx7dxSIU=.435b7e10-be21-4477-a377-e8ba7c72eb82@github.com> <2Tz0WYseV99QNWq-veXwIFxULnAW6h0xEf4UsWLMNm0=.0f4a8d80-bd73-4dfd-a0a9-8f917ec2b2fb@github.com> Message-ID: On Tue, 29 Jul 2025 06:37:06 GMT, Timofei Pushkin wrote: >> So this is actually triggering the deoptimization (yes, the method sounds like that, but the error message sounds like it's just checking some statistics)? If the purpose of the test is to check that recompilations won't happen too soon, why is there a difference in the time when you trigger the deoptimization? (for delayMs == 0 this must be in the afterRestore, but why wouldn't you trigger it there even for delayMs > 0?) > >> So this is actually triggering the deoptimization > > Yes, it triggers the deoptimization. It returns the amount of compilations actually deoptimized (can be zero if the method was not compiled; can be multiple for one method if there were OSR compilations with different entry byte codes, although I believe this overload skips OSRs). > >> but why wouldn't you trigger it there even for delayMs > 0 > > Because then the test would succeed even if the delaying code gets removed, i.e. it won't actually be testing that the delay works. It would be easier to test if after-restore recompilations would happen immediately instead of after the delay expires (then I could set a very large delay but after triggering the decompilation just wait a bit until it gets recompiled instead of having to wait until the delay expires). But that turned out to not be easy to implement (threads triggering decompilations sometimes cannot enqueue compilations), so it is something to maybe implement in the future. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/251#discussion_r2238693138 From rvansa at openjdk.org Tue Jul 29 08:48:18 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 29 Jul 2025 08:48:18 GMT Subject: [crac] RFR: 8364156: [CRaC] Recompile methods decompiled during or shortly after C/R [v2] In-Reply-To: References: <5-VP5AOjIpeRRqwgvgKdDebbjQt04cKS29gvx7dxSIU=.435b7e10-be21-4477-a377-e8ba7c72eb82@github.com> <2Tz0WYseV99QNWq-veXwIFxULnAW6h0xEf4UsWLMNm0=.0f4a8d80-bd73-4dfd-a0a9-8f917ec2b2fb@github.com> Message-ID: On Tue, 29 Jul 2025 06:42:35 GMT, Timofei Pushkin wrote: >>> So this is actually triggering the deoptimization >> >> Yes, it triggers the deoptimization. It returns the amount of compilations actually deoptimized (can be zero if the method was not compiled; can be multiple for one method if there were OSR compilations with different entry byte codes, although I believe this overload skips OSRs). >> >>> but why wouldn't you trigger it there even for delayMs > 0 >> >> Because then the test would succeed even if the delaying code gets removed, i.e. it won't actually be testing that the delay works. > > It would be easier to test if after-restore recompilations would happen immediately instead of after the delay expires (then I could set a very large delay but after triggering the decompilation just wait a bit until it gets recompiled instead of having to wait until the delay expires). But that turned out to not be easy to implement (threads triggering decompilations sometimes cannot enqueue compilations), so it is something to maybe implement in the future. > Because then the test would succeed even if the delaying code gets removed, i.e. it won't actually be testing that the delay works. And can't you test `whiteBox.getMethodCompilationLevel()` and ensure that the method is still deoptimized? That'd be prone to timing as well, but you could check timestamp after the level check and invalidate it if it's too late... ------------- PR Review Comment: https://git.openjdk.org/crac/pull/251#discussion_r2239018950 From tpushkin at openjdk.org Tue Jul 29 09:08:00 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Tue, 29 Jul 2025 09:08:00 GMT Subject: [crac] RFR: 8364156: [CRaC] Recompile methods decompiled during or shortly after C/R [v3] In-Reply-To: References: <5-VP5AOjIpeRRqwgvgKdDebbjQt04cKS29gvx7dxSIU=.435b7e10-be21-4477-a377-e8ba7c72eb82@github.com> <2Tz0WYseV99QNWq-veXwIFxULnAW6h0xEf4UsWLMNm0=.0f4a8d80-bd73-4dfd-a0a9-8f917ec2b2fb@github.com> Message-ID: On Tue, 29 Jul 2025 08:45:34 GMT, Radim Vansa wrote: >> It would be easier to test if after-restore recompilations would happen immediately instead of after the delay expires (then I could set a very large delay but after triggering the decompilation just wait a bit until it gets recompiled instead of having to wait until the delay expires). But that turned out to not be easy to implement (threads triggering decompilations sometimes cannot enqueue compilations), so it is something to maybe implement in the future. > >> Because then the test would succeed even if the delaying code gets removed, i.e. it won't actually be testing that the delay works. > > And can't you test `whiteBox.getMethodCompilationLevel()` and ensure that the method is still deoptimized? That'd be prone to timing as well, but you could check timestamp after the level check and invalidate it if it's too late... IIUC that would be essentially the same thing just tested the other way: we are still checking that the delay is long enough for this machine. And we would still need the timestamp check to check that the check itself did not happen too late, so there will still be two checks. Also I consider optimizing the implementation in the future to recompile things recorded during C/R right after restore and start a new recording for the delay (this would recompile during-C/R decompilations earlier potentially improving the performance) ? such implementation would require the test to be as it is now. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/251#discussion_r2239060325 From tpushkin at openjdk.org Tue Jul 29 09:08:00 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Tue, 29 Jul 2025 09:08:00 GMT Subject: [crac] RFR: 8364156: [CRaC] Recompile methods decompiled during or shortly after C/R [v3] In-Reply-To: References: Message-ID: > Implements recording and triggering recompilation of methods decompiled during and shortly after C/R. The length of the "shortly-after" period can be controlled by the user via `-Djdk.crac.recompilation-delay-ms=`, the default is 10ms. > > Measuring the after-restore regression before and after this change shows improvement on hello-world apps. The numbers are the regression of the first after-restore 1 sec iteration vs average over 5 last before-checkpoint 1 sec iterations, i.e. lower means better; mean ? std dev over 30 runs. Measured in a Linux VM on MacOS, with CRIU, with 5ms after-restore recompilation delay. > > | | Before | After | > |--------------------------|-------------|-------------| > | Helidon hello-world | 0.9 ? 1.2 % | 0.4 ? 1.0 % | > | Spring boot CRaC example | 9.5 ? 2.4 % | 6.4 ? 2.5 % | > > Currently decompilations are recorded during C/R + during the after-restore delay and then they all get recompiled together. An enhancement planned in the future is to record only during C/R recompiling immediately after restore and during the after-restore delay recompile immediately without recording. This way the recompilations would finish faster, also setting `jdk.crac.recompilation-delay-ms` to a higher value would have less negative impact. > > Implementation notes: > - Native code (`nmethod`) is considered "decompiled" when `make_not_entrant(...)` is called on it ? a new mandatory parameter is added to the signature of this method that controls whether CRaC should consider this particular decompilation for recompilation or not. > - The parameter is needed because we do not want to recompile, for example, when `nmethod` is thrown away once a replacement for it has been compiled (e.g. on another compilation level). > - The parameter has no default so that we get compilation errors when new calls to `make_not_entrant(...)` are introduced in the mainline ? we will be deciding whether these new calls should be considered for recompilation or not. If CRaC was in the mainline I would enable the recompilation by default. > - The new native `CRaCRecorder` class is the core of the implementation ? it records the decompilations and handles their recompilation. > - `jdk.crac.internal.mirror.Core` notifies it when to start and stop the recording, it also handles the after-restore recompilation delay. > - `nmethod.make_not_entrant(...)` notifies it about decompiled code. Timofei Pushkin has updated the pull request with a new target base 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: - Resolve issues brought-in by the merge - Merge remote-tracking branch 'openjdk-crac/crac' into recompile - Implement flag-related review suggestions - Cleanup tests - Remove erroneously added assert - Bring back erroneously removed locking - Fix RedefineClasses defence - Reduce default recompilation delay - Fix NaturalDecompilationTest on Windows - Make decompilation more reliable in NaturalDecompilationTest - ... and 6 more: https://git.openjdk.org/crac/compare/d54797c5...db100b7f ------------- Changes: - all: https://git.openjdk.org/crac/pull/251/files - new: https://git.openjdk.org/crac/pull/251/files/536ce035..db100b7f Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=251&range=02 - incr: https://webrevs.openjdk.org/?repo=crac&pr=251&range=01-02 Stats: 167522 lines in 2908 files changed: 99603 ins; 46016 del; 21903 mod Patch: https://git.openjdk.org/crac/pull/251.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/251/head:pull/251 PR: https://git.openjdk.org/crac/pull/251 From tpushkin at openjdk.org Tue Jul 29 12:47:35 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Tue, 29 Jul 2025 12:47:35 GMT Subject: [crac] RFR: 8364272: [CRaC] Make inclusion of crac.hpp in os_posix.cpp conditional Message-ID: Just a small, mostly cosmetic enhancement. ------------- Commit messages: - Make CRaC include conditional Changes: https://git.openjdk.org/crac/pull/252/files Webrev: https://webrevs.openjdk.org/?repo=crac&pr=252&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364272 Stats: 4 lines in 1 file changed: 3 ins; 1 del; 0 mod Patch: https://git.openjdk.org/crac/pull/252.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/252/head:pull/252 PR: https://git.openjdk.org/crac/pull/252 From rvansa at openjdk.org Tue Jul 29 12:49:31 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 29 Jul 2025 12:49:31 GMT Subject: [crac] RFR: 8364156: [CRaC] Recompile methods decompiled during or shortly after C/R [v3] In-Reply-To: References: Message-ID: On Tue, 29 Jul 2025 09:08:00 GMT, Timofei Pushkin wrote: >> Implements recording and triggering recompilation of methods decompiled during and shortly after C/R. The length of the "shortly-after" period can be controlled by the user via `-Djdk.crac.recompilation-delay-ms=`, the default is 10ms. >> >> Measuring the after-restore regression before and after this change shows improvement on hello-world apps. The numbers are the regression of the first after-restore 1 sec iteration vs average over 5 last before-checkpoint 1 sec iterations, i.e. lower means better; mean ? std dev over 30 runs. Measured in a Linux VM on MacOS, with CRIU, with 5ms after-restore recompilation delay. >> >> | | Before | After | >> |--------------------------|-------------|-------------| >> | Helidon hello-world | 0.9 ? 1.2 % | 0.4 ? 1.0 % | >> | Spring boot CRaC example | 9.5 ? 2.4 % | 6.4 ? 2.5 % | >> >> Currently decompilations are recorded during C/R + during the after-restore delay and then they all get recompiled together. An enhancement planned in the future is to record only during C/R recompiling immediately after restore and during the after-restore delay recompile immediately without recording. This way the recompilations would finish faster, also setting `jdk.crac.recompilation-delay-ms` to a higher value would have less negative impact. >> >> Implementation notes: >> - Native code (`nmethod`) is considered "decompiled" when `make_not_entrant(...)` is called on it ? a new mandatory parameter is added to the signature of this method that controls whether CRaC should consider this particular decompilation for recompilation or not. >> - The parameter is needed because we do not want to recompile, for example, when `nmethod` is thrown away once a replacement for it has been compiled (e.g. on another compilation level). >> - The parameter has no default so that we get compilation errors when new calls to `make_not_entrant(...)` are introduced in the mainline ? we will be deciding whether these new calls should be considered for recompilation or not. If CRaC was in the mainline I would enable the recompilation by default. >> - The new native `CRaCRecorder` class is the core of the implementation ? it records the decompilations and handles their recompilation. >> - `jdk.crac.internal.mirror.Core` notifies it when to start and stop the recording, it also handles the after-restore recompilation delay. >> - `nmethod.make_not_entrant(...)` notifies it about decompiled code. > > Timofei Pushkin has updated the pull request with a new target base 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: > > - Resolve issues brought-in by the merge > - Merge remote-tracking branch 'openjdk-crac/crac' into recompile > - Implement flag-related review suggestions > - Cleanup tests > - Remove erroneously added assert > - Bring back erroneously removed locking > - Fix RedefineClasses defence > - Reduce default recompilation delay > - Fix NaturalDecompilationTest on Windows > - Make decompilation more reliable in NaturalDecompilationTest > - ... and 6 more: https://git.openjdk.org/crac/compare/90deba84...db100b7f Thanks for the patience & explanations, approved. ------------- Marked as reviewed by rvansa (Committer). PR Review: https://git.openjdk.org/crac/pull/251#pullrequestreview-3067367678 From tpushkin at openjdk.org Tue Jul 29 12:55:26 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Tue, 29 Jul 2025 12:55:26 GMT Subject: [crac] RFR: 8364156: [CRaC] Recompile methods decompiled during or shortly after C/R [v3] In-Reply-To: References: Message-ID: On Tue, 29 Jul 2025 09:08:00 GMT, Timofei Pushkin wrote: >> Implements recording and triggering recompilation of methods decompiled during and shortly after C/R. The length of the "shortly-after" period can be controlled by the user via `-Djdk.crac.recompilation-delay-ms=`, the default is 10ms. >> >> Measuring the after-restore regression before and after this change shows improvement on hello-world apps. The numbers are the regression of the first after-restore 1 sec iteration vs average over 5 last before-checkpoint 1 sec iterations, i.e. lower means better; mean ? std dev over 30 runs. Measured in a Linux VM on MacOS, with CRIU, with 5ms after-restore recompilation delay. >> >> | | Before | After | >> |--------------------------|-------------|-------------| >> | Helidon hello-world | 0.9 ? 1.2 % | 0.4 ? 1.0 % | >> | Spring boot CRaC example | 9.5 ? 2.4 % | 6.4 ? 2.5 % | >> >> Currently decompilations are recorded during C/R + during the after-restore delay and then they all get recompiled together. An enhancement planned in the future is to record only during C/R recompiling immediately after restore and during the after-restore delay recompile immediately without recording. This way the recompilations would finish faster, also setting `jdk.crac.recompilation-delay-ms` to a higher value would have less negative impact. >> >> Implementation notes: >> - Native code (`nmethod`) is considered "decompiled" when `make_not_entrant(...)` is called on it ? a new mandatory parameter is added to the signature of this method that controls whether CRaC should consider this particular decompilation for recompilation or not. >> - The parameter is needed because we do not want to recompile, for example, when `nmethod` is thrown away once a replacement for it has been compiled (e.g. on another compilation level). >> - The parameter has no default so that we get compilation errors when new calls to `make_not_entrant(...)` are introduced in the mainline ? we will be deciding whether these new calls should be considered for recompilation or not. If CRaC was in the mainline I would enable the recompilation by default. >> - The new native `CRaCRecorder` class is the core of the implementation ? it records the decompilations and handles their recompilation. >> - `jdk.crac.internal.mirror.Core` notifies it when to start and stop the recording, it also handles the after-restore recompilation delay. >> - `nmethod.make_not_entrant(...)` notifies it about decompiled code. > > Timofei Pushkin has updated the pull request with a new target base 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: > > - Resolve issues brought-in by the merge > - Merge remote-tracking branch 'openjdk-crac/crac' into recompile > - Implement flag-related review suggestions > - Cleanup tests > - Remove erroneously added assert > - Bring back erroneously removed locking > - Fix RedefineClasses defence > - Reduce default recompilation delay > - Fix NaturalDecompilationTest on Windows > - Make decompilation more reliable in NaturalDecompilationTest > - ... and 6 more: https://git.openjdk.org/crac/compare/1fe5635b...db100b7f Thank you! ------------- PR Comment: https://git.openjdk.org/crac/pull/251#issuecomment-3132387901 From tpushkin at openjdk.org Tue Jul 29 12:55:28 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Tue, 29 Jul 2025 12:55:28 GMT Subject: [crac] Integrated: 8364156: [CRaC] Recompile methods decompiled during or shortly after C/R In-Reply-To: References: Message-ID: On Mon, 28 Jul 2025 07:04:26 GMT, Timofei Pushkin wrote: > Implements recording and triggering recompilation of methods decompiled during and shortly after C/R. The length of the "shortly-after" period can be controlled by the user via `-Djdk.crac.recompilation-delay-ms=`, the default is 10ms. > > Measuring the after-restore regression before and after this change shows improvement on hello-world apps. The numbers are the regression of the first after-restore 1 sec iteration vs average over 5 last before-checkpoint 1 sec iterations, i.e. lower means better; mean ? std dev over 30 runs. Measured in a Linux VM on MacOS, with CRIU, with 5ms after-restore recompilation delay. > > | | Before | After | > |--------------------------|-------------|-------------| > | Helidon hello-world | 0.9 ? 1.2 % | 0.4 ? 1.0 % | > | Spring boot CRaC example | 9.5 ? 2.4 % | 6.4 ? 2.5 % | > > Currently decompilations are recorded during C/R + during the after-restore delay and then they all get recompiled together. An enhancement planned in the future is to record only during C/R recompiling immediately after restore and during the after-restore delay recompile immediately without recording. This way the recompilations would finish faster, also setting `jdk.crac.recompilation-delay-ms` to a higher value would have less negative impact. > > Implementation notes: > - Native code (`nmethod`) is considered "decompiled" when `make_not_entrant(...)` is called on it ? a new mandatory parameter is added to the signature of this method that controls whether CRaC should consider this particular decompilation for recompilation or not. > - The parameter is needed because we do not want to recompile, for example, when `nmethod` is thrown away once a replacement for it has been compiled (e.g. on another compilation level). > - The parameter has no default so that we get compilation errors when new calls to `make_not_entrant(...)` are introduced in the mainline ? we will be deciding whether these new calls should be considered for recompilation or not. If CRaC was in the mainline I would enable the recompilation by default. > - The new native `CRaCRecorder` class is the core of the implementation ? it records the decompilations and handles their recompilation. > - `jdk.crac.internal.mirror.Core` notifies it when to start and stop the recording, it also handles the after-restore recompilation delay. > - `nmethod.make_not_entrant(...)` notifies it about decompiled code. This pull request has now been integrated. Changeset: 0ef37fb2 Author: Timofei Pushkin URL: https://git.openjdk.org/crac/commit/0ef37fb29a708c8b5b35e0c9e5f373711dd94a4e Stats: 889 lines in 26 files changed: 864 ins; 0 del; 25 mod 8364156: [CRaC] Recompile methods decompiled during or shortly after C/R Reviewed-by: rvansa ------------- PR: https://git.openjdk.org/crac/pull/251 From rvansa at openjdk.org Wed Jul 30 13:52:13 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Wed, 30 Jul 2025 13:52:13 GMT Subject: [crac] RFR: 8364272: [CRaC] Make inclusion of crac.hpp in os_posix.cpp conditional In-Reply-To: References: Message-ID: On Tue, 29 Jul 2025 12:42:49 GMT, Timofei Pushkin wrote: > Just a small, mostly cosmetic enhancement. Marked as reviewed by rvansa (Committer). ------------- PR Review: https://git.openjdk.org/crac/pull/252#pullrequestreview-3071652609 From tpushkin at openjdk.org Wed Jul 30 13:55:16 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Wed, 30 Jul 2025 13:55:16 GMT Subject: [crac] Integrated: 8364272: [CRaC] Make inclusion of crac.hpp in os_posix.cpp conditional In-Reply-To: References: Message-ID: <7xtIuseea58PEYAD-2v5QFxWEh5X7cdGrjjso2Vy8ow=.ea157696-0e2d-4d42-a8f0-af83dee3c90f@github.com> On Tue, 29 Jul 2025 12:42:49 GMT, Timofei Pushkin wrote: > Just a small, mostly cosmetic enhancement. This pull request has now been integrated. Changeset: aaa3e2a0 Author: Timofei Pushkin URL: https://git.openjdk.org/crac/commit/aaa3e2a09a41c402892708bbf1e40d787f2cdefb Stats: 4 lines in 1 file changed: 3 ins; 1 del; 0 mod 8364272: [CRaC] Make inclusion of crac.hpp in os_posix.cpp conditional Reviewed-by: rvansa ------------- PR: https://git.openjdk.org/crac/pull/252 From tpushkin at openjdk.org Thu Jul 31 16:23:30 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Thu, 31 Jul 2025 16:23:30 GMT Subject: [crac] RFR: 8364449: [CRaC] Launch new main outside of the core C/R body Message-ID: <-V4E4yMxB9oQlO6AEnLQ6O51jsAuwtBEroQsVztNaBA=.55f01f27-c801-43b1-a8a2-022806c65f36@github.com> New main is now launched after restoration completes solving the issues outlined in the JBS task. ------------- Commit messages: - Launch new main outside of the core C/R body Changes: https://git.openjdk.org/crac/pull/253/files Webrev: https://webrevs.openjdk.org/?repo=crac&pr=253&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364449 Stats: 412 lines in 5 files changed: 303 ins; 103 del; 6 mod Patch: https://git.openjdk.org/crac/pull/253.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/253/head:pull/253 PR: https://git.openjdk.org/crac/pull/253 From tpushkin at openjdk.org Thu Jul 31 16:41:20 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Thu, 31 Jul 2025 16:41:20 GMT Subject: [crac] RFR: 8364449: [CRaC] Launch new main outside of the core C/R body [v2] In-Reply-To: <-V4E4yMxB9oQlO6AEnLQ6O51jsAuwtBEroQsVztNaBA=.55f01f27-c801-43b1-a8a2-022806c65f36@github.com> References: <-V4E4yMxB9oQlO6AEnLQ6O51jsAuwtBEroQsVztNaBA=.55f01f27-c801-43b1-a8a2-022806c65f36@github.com> Message-ID: > New main is now launched after restoration completes solving the issues outlined in the JBS task. > > Also the error message when the new main is not found (e.g. the feature is used by accident like in https://github.com/spring-projects/spring-framework/issues/33226) or throws an exception should become less cryptic: > > $ java -XX:CRaCRestoreFrom=cr -jar app.jar > Exception in thread "main" jdk.crac.RestoreException > Suppressed: java.lang.Exception: Failed to execute the new main entry: new initial class = 'app.jar', new main arguments = []. Do not specify these if you just wish to continue the checkpointed execution. > at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:314) > at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:263) > at jdk.crac/jdk.crac.Core.checkpointRestore(Core.java:73) > at Main.main(Main.java:4) > Caused by: java.lang.ClassNotFoundException: app.jar > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:580) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490) > at java.base/java.lang.Class.forName0(Native Method) > at java.base/java.lang.Class.forName(Class.java:547) > at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:302) > ... 3 more Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: Add missing space ------------- Changes: - all: https://git.openjdk.org/crac/pull/253/files - new: https://git.openjdk.org/crac/pull/253/files/43860e78..fe256b05 Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=253&range=01 - incr: https://webrevs.openjdk.org/?repo=crac&pr=253&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/crac/pull/253.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/253/head:pull/253 PR: https://git.openjdk.org/crac/pull/253 From tpushkin at openjdk.org Thu Jul 31 18:05:24 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Thu, 31 Jul 2025 18:05:24 GMT Subject: [crac] RFR: 8364456: [CRaC] Extend error logging of waitForCheckpointed Message-ID: Makes `CracProcess.waitForCheckpointed()` print the same logs as `CracProcess.waitForSuccess()` does.
Before STDERR: Starting process to be checkpointed: /build/linux-arm64-slow-openjdk/images/jdk/bin/java -ea -XX:CRaCEngine=criuengine -cp /build/linux-arm64-slow-openjdk/test-support/jtreg_test_jdk_jdk_crac_newArgs_CheckpointInNewMainTest_java/classes/0/jdk/crac/newArgs/CheckpointInNewMainTest.d:/build/linux-arm64-slow-openjdk/test-support/jtreg_test_jdk_jdk_crac_newArgs_CheckpointInNewMainTest_java/classes/0/test/lib -XX:CRaCEngineOptions=direct_map=false -XX:CRaCCheckpointTo=cr jdk.test.lib.crac.CracTest __run_test__ CheckpointInNewMainTest java.lang.RuntimeException: Checkpointed process was not killed as expected. expected: 137 but was: 1 at jdk.test.lib.Asserts.fail(Asserts.java:715) at jdk.test.lib.Asserts.assertEquals(Asserts.java:208) at jdk.test.lib.crac.CracProcess.waitForCheckpointed(CracProcess.java:41) at jdk.test.lib.crac.CracBuilder.doCheckpoint(CracBuilder.java:241) at CheckpointInNewMainTest.test(CheckpointInNewMainTest.java:53) at jdk.test.lib.crac.CracTest.run(CracTest.java:163) at jdk.test.lib.crac.CracTest.main(CracTest.java:90) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) at java.base/java.lang.Thread.run(Thread.java:1474) JavaTest Message: Test threw exception: java.lang.RuntimeException JavaTest Message: shutting down test
After STDERR: Starting process to be checkpointed: /build/linux-arm64-slow-openjdk/images/jdk/bin/java -ea -XX:CRaCEngine=criuengine -cp /build/linux-arm64-slow-openjdk/test-support/jtreg_test_jdk_jdk_crac_newArgs_CheckpointInNewMainTest_java/classes/0/jdk/crac/newArgs/CheckpointInNewMainTest.d:/build/linux-arm64-slow-openjdk/test-support/jtreg_test_jdk_jdk_crac_newArgs_CheckpointInNewMainTest_java/classes/0/test/lib -XX:CRaCEngineOptions=direct_map=false -XX:CRaCCheckpointTo=cr jdk.test.lib.crac.CracTest __run_test__ CheckpointInNewMainTest stdout: [ ] stderr: [ Exception in thread "main" java.lang.IllegalStateException: Some very useful explanation of the problem at CheckpointInNewMainTest.exec(CheckpointInNewMainTest.java:64) at jdk.test.lib.crac.CracTest.run(CracTest.java:165) at jdk.test.lib.crac.CracTest.main(CracTest.java:90) ] exitValue = 1 java.lang.RuntimeException: Checkpointed process was not killed as expected. expected: 137 but was: 1 at jdk.test.lib.Asserts.fail(Asserts.java:715) at jdk.test.lib.Asserts.assertEquals(Asserts.java:208) at jdk.test.lib.crac.CracProcess.waitForCheckpointed(CracProcess.java:45) at jdk.test.lib.crac.CracBuilder.doCheckpoint(CracBuilder.java:241) at CheckpointInNewMainTest.test(CheckpointInNewMainTest.java:53) at jdk.test.lib.crac.CracTest.run(CracTest.java:163) at jdk.test.lib.crac.CracTest.main(CracTest.java:90) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) at java.base/java.lang.Thread.run(Thread.java:1474) JavaTest Message: Test threw exception: java.lang.RuntimeException JavaTest Message: shutting down test STDOUT: [2025-07-31T17:40:07.905590979Z] Gathering output for process 172600 [2025-07-31T17:40:08.016154176Z] Waiting for completion for process 172600 [2025-07-31T17:40:08.016337160Z] Waiting for completion finished for process 172600
It also changes the format in which `CracProcess.waitForSuccess()` prints child process output: before it was divided between stdout and stderr of the parent process, now it all goes into stderr of the parent process ? it makes it easier to read because everything (commandline, stdout, stderr) is in the same place. ------------- Commit messages: - Extend waitForCheckpointed logging Changes: https://git.openjdk.org/crac/pull/254/files Webrev: https://webrevs.openjdk.org/?repo=crac&pr=254&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364456 Stats: 16 lines in 1 file changed: 11 ins; 2 del; 3 mod Patch: https://git.openjdk.org/crac/pull/254.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/254/head:pull/254 PR: https://git.openjdk.org/crac/pull/254