From xpeng at openjdk.org Sat Mar 1 06:06:01 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Sat, 1 Mar 2025 06:06:01 GMT Subject: RFR: 8338737: Shenandoah: Reset marking bitmaps after the cycle [v9] In-Reply-To: References: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com> Message-ID: On Fri, 28 Feb 2025 00:08:22 GMT, Xiaolong Peng wrote: >> Reset marking bitmaps after collection cycle; for GenShen only do this for young generation, also choose not do this for Degen and full GC since both are running at safepoint, we should leave safepoint as ASAP. >> >> I have run same workload for 30s with Shenandoah in generational mode and classic mode, average average time of concurrent reset dropped significantly since in most case bitmap for young gen should have been reset after pervious concurrent cycle finishes if there is no need to preserve bitmap states. >> >> GenShen: >> Before: >> >> [33.342s][info][gc,stats ] Concurrent Reset = 0.023 s (a = 1921 us) (n = 12) (lvls, us = 133, 385, 1191, 1836, 8878) >> >> >> After: >> >> [33.597s][info][gc,stats ] Concurrent Reset = 0.004 s (a = 317 us) (n = 13) (lvls, us = 58, 119, 217, 410, 670) >> [33.597s][info][gc,stats ] Concurrent Reset After Collect = 0.018 s (a = 1365 us) (n = 13) (lvls, us = 91, 186, 818, 1836, 3872) >> >> >> Shenandoah: >> Before: >> >> [33.144s][info][gc,stats ] Concurrent Reset = 0.014 s (a = 1067 us) (n = 13) (lvls, us = 139, 277, 898, 1328, 2118) >> >> After: >> >> [33.128s][info][gc,stats ] Concurrent Reset = 0.003 s (a = 225 us) (n = 13) (lvls, us = 32, 92, 137, 295, 542) >> [33.128s][info][gc,stats ] Concurrent Reset After Collect = 0.009 s (a = 661 us) (n = 13) (lvls, us = 92, 160, 594, 896, 1661) >> >> >> Additional changes: >> * Remove `ShenandoahResetBitmapClosure` and `ShenandoahPrepareForMarkClosure`, merge the code with `ShenandoahResetBitmapClosure`, saving one iteration over all the regions. >> * Use API `ShenandoahGeneration::parallel_heap_region_iterate_free` to iterate the regions, two benefits from this: >> - Underneath it calls `ShenandoahHeap::parallel_heap_region_iterate`, which is faster for very light tasks, see https://bugs.openjdk.org/browse/JDK-8337154 >> - `ShenandoahGeneration::parallel_heap_region_iterate_free` decorate the closure with `ShenandoahExcludeRegionClosure`, which simplifies the code in closure. >> * When `_do_old_gc_bootstrap is true`, instead of reset mark bitmap for old gen separately, simply reset the global generations, so we don't need walk the all regions twice. >> * Clean up FullGC code, remove duplicate code. >> >> ... > > Xiaolong Peng 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 25 additional commits since the last revision: > > - Merge branch 'openjdk:master' into reset-bitmap > - Merge branch 'openjdk:master' into reset-bitmap > - Merge branch 'openjdk:master' into reset-bitmap > - Merge branch 'openjdk:master' into reset-bitmap > - Merge branch 'openjdk:master' into reset-bitmap > - Adding condition "!_do_old_gc_bootstrap && !heap->is_concurrent_old_mark_in_progress()" back and address some PR comments > - Remove entry_reset_after_collect from ShenandoahOldGC > - Remove condition check !_do_old_gc_bootstrap && !heap->is_concurrent_old_mark_in_progress() from op_reset_after_collect > - Merge branch 'openjdk:master' into reset-bitmap > - Address review comments > - ... and 15 more: https://git.openjdk.org/jdk/compare/8e164a93...7eea9556 Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22778#issuecomment-2691984558 From duke at openjdk.org Sat Mar 1 06:06:01 2025 From: duke at openjdk.org (duke) Date: Sat, 1 Mar 2025 06:06:01 GMT Subject: RFR: 8338737: Shenandoah: Reset marking bitmaps after the cycle [v9] In-Reply-To: References: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com> Message-ID: On Fri, 28 Feb 2025 00:08:22 GMT, Xiaolong Peng wrote: >> Reset marking bitmaps after collection cycle; for GenShen only do this for young generation, also choose not do this for Degen and full GC since both are running at safepoint, we should leave safepoint as ASAP. >> >> I have run same workload for 30s with Shenandoah in generational mode and classic mode, average average time of concurrent reset dropped significantly since in most case bitmap for young gen should have been reset after pervious concurrent cycle finishes if there is no need to preserve bitmap states. >> >> GenShen: >> Before: >> >> [33.342s][info][gc,stats ] Concurrent Reset = 0.023 s (a = 1921 us) (n = 12) (lvls, us = 133, 385, 1191, 1836, 8878) >> >> >> After: >> >> [33.597s][info][gc,stats ] Concurrent Reset = 0.004 s (a = 317 us) (n = 13) (lvls, us = 58, 119, 217, 410, 670) >> [33.597s][info][gc,stats ] Concurrent Reset After Collect = 0.018 s (a = 1365 us) (n = 13) (lvls, us = 91, 186, 818, 1836, 3872) >> >> >> Shenandoah: >> Before: >> >> [33.144s][info][gc,stats ] Concurrent Reset = 0.014 s (a = 1067 us) (n = 13) (lvls, us = 139, 277, 898, 1328, 2118) >> >> After: >> >> [33.128s][info][gc,stats ] Concurrent Reset = 0.003 s (a = 225 us) (n = 13) (lvls, us = 32, 92, 137, 295, 542) >> [33.128s][info][gc,stats ] Concurrent Reset After Collect = 0.009 s (a = 661 us) (n = 13) (lvls, us = 92, 160, 594, 896, 1661) >> >> >> Additional changes: >> * Remove `ShenandoahResetBitmapClosure` and `ShenandoahPrepareForMarkClosure`, merge the code with `ShenandoahResetBitmapClosure`, saving one iteration over all the regions. >> * Use API `ShenandoahGeneration::parallel_heap_region_iterate_free` to iterate the regions, two benefits from this: >> - Underneath it calls `ShenandoahHeap::parallel_heap_region_iterate`, which is faster for very light tasks, see https://bugs.openjdk.org/browse/JDK-8337154 >> - `ShenandoahGeneration::parallel_heap_region_iterate_free` decorate the closure with `ShenandoahExcludeRegionClosure`, which simplifies the code in closure. >> * When `_do_old_gc_bootstrap is true`, instead of reset mark bitmap for old gen separately, simply reset the global generations, so we don't need walk the all regions twice. >> * Clean up FullGC code, remove duplicate code. >> >> ... > > Xiaolong Peng 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 25 additional commits since the last revision: > > - Merge branch 'openjdk:master' into reset-bitmap > - Merge branch 'openjdk:master' into reset-bitmap > - Merge branch 'openjdk:master' into reset-bitmap > - Merge branch 'openjdk:master' into reset-bitmap > - Merge branch 'openjdk:master' into reset-bitmap > - Adding condition "!_do_old_gc_bootstrap && !heap->is_concurrent_old_mark_in_progress()" back and address some PR comments > - Remove entry_reset_after_collect from ShenandoahOldGC > - Remove condition check !_do_old_gc_bootstrap && !heap->is_concurrent_old_mark_in_progress() from op_reset_after_collect > - Merge branch 'openjdk:master' into reset-bitmap > - Address review comments > - ... and 15 more: https://git.openjdk.org/jdk/compare/8e164a93...7eea9556 @pengxiaolong Your change (at version 7eea95568115c3ceb976bf83559b4df1d2b490d4) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22778#issuecomment-2691985569 From jsjolen at openjdk.org Mon Mar 3 10:10:00 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 3 Mar 2025 10:10:00 GMT Subject: RFR: 8350566: NMT: add size parameter to MemTracker::record_virtual_memory_tag In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 09:49:41 GMT, Afshin Zafari wrote: > With the `size` parameter there will be no need to traverse/go through the nodes between the base and end of the region. > Tests: > linux-x64-debug, gtest:NMT* and runtime/NMT* LGTM ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23770#pullrequestreview-2653648133 From dfenacci at openjdk.org Mon Mar 3 12:43:53 2025 From: dfenacci at openjdk.org (Damon Fenacci) Date: Mon, 3 Mar 2025 12:43:53 GMT Subject: RFR: 8347406: [REDO] C1/C2 don't handle allocation failure properly during initialization (RuntimeStub::new_runtime_stub fatal crash) [v4] In-Reply-To: <2jI87up85vKeQq7xy6WoI987MOuqTqA6I8G75VvC74g=.e8ef9f9c-b8b3-496d-9b48-28c83dc1fb64@github.com> References:

<2jI87up85vKeQq7xy6WoI987MOuqTqA6I8G75VvC74g=.e8ef9f9c-b8b3-496d-9b48-28c83dc1fb64@github.com> Message-ID: On Fri, 28 Feb 2025 20:35:58 GMT, Dean Long wrote: > Refreshing my memory, isn't the real problem with trying to fix this with a minimum codecache size is that some of these stubs are not allocated during initial single-threaded JVM startup, but later when the first compiler threads start, and that allows other code blobs to fill up the codecache? Yes, exactly. This seems to be even more of an issue with 2 compiler threads (i.e. C1/C2) since the first can fill up the code cache first at the expense of the other. The result is that if one compiler thread tries to allocate more space in a full code cache during initialization with one of the 4 call paths above, the VM crashes (but could actually just turn off the compiler thread instead). ------------- PR Comment: https://git.openjdk.org/jdk/pull/23630#issuecomment-2694260818 From dfenacci at openjdk.org Mon Mar 3 12:54:26 2025 From: dfenacci at openjdk.org (Damon Fenacci) Date: Mon, 3 Mar 2025 12:54:26 GMT Subject: RFR: 8347406: [REDO] C1/C2 don't handle allocation failure properly during initialization (RuntimeStub::new_runtime_stub fatal crash) [v5] In-Reply-To: References: Message-ID: > # Issue > The test `src/hotspot/share/opto/c2compiler.cpp` fails intermittently due to a crash that happens when trying to allocate code cache space for C1 and C2 in `RuntimeStub::new_runtime_stub` and `SingletonBlob::operator new`. > > # Causes > There are a few call paths during the initialization of C1 and C2 that can lead to the code cache allocations in `RuntimeStub::new_runtime_stub` (through `RuntimeStub::operator new`) and `SingletonBlob::operator new` triggering a fatal error if there is no more space. The paths in question are: > 1. `Compiler::init_c1_runtime` -> `Runtime1::initialize` -> `Runtime1::generate_blob_for` -> `Runtime1::generate_blob` -> `RuntimeStub::new_runtime_stub` > 1. `C2Compiler::initialize` -> `C2Compiler::init_c2_runtime` -> `OptoRuntime::generate` -> `OptoRuntime::generate_stub` -> `Compile::Compile` -> `Compile::Code_Gen` -> `PhaseOutput::install` -> `PhaseOutput::install_stub` -> `RuntimeStub::new_runtime_stub` > 1. `C2Compiler::initialize` -> `C2Compiler::init_c2_runtime` -> `OptoRuntime::generate` -> `OptoRuntime::generate_uncommon_trap_blob` -> `UncommonTrapBlob::create` -> `new UncommonTrapBlob` > 1. `C2Compiler::initialize` -> `C2Compiler::init_c2_runtime` -> `OptoRuntime::generate` -> `OptoRuntime::generate_exception_blob` -> `ExceptionBlob::create` -> `new ExceptionBlob` > > # Solution > Instead of fatally crashing the we can use the `alloc_fail_is_fatal` flag of `RuntimeStub::new_runtime_stub` to avoid crashing in cases 1 and 2 and add a similar flag to `SingletonBlob::operator new` for cases 3 and 4. In the latter case we need to adjust all calls accordingly. > > Note: In [JDK-8326615](https://bugs.openjdk.org/browse/JDK-8326615) it was argued that increasing the minimum code cache size would solve the issue but that wasn't entirely accurate: doing so possibly decreases the chances of a failed allocation in these 4 places but doesn't totally avoid it. > > # Testing > The original failing regression test in `test/hotspot/jtreg/compiler/startup/StartupOutput.java` has been modified to run multiple times with randomized values (within the original failing range) to increase the chances of hitting the fatal assertion. > > Tests: Tier 1-4 (windows-x64, linux-x64/aarch64, and macosx-x64/aarch64; release and debug mode) Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision: JDK-8347406: move assert into else clause ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23630/files - new: https://git.openjdk.org/jdk/pull/23630/files/906cd756..722ca508 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23630&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23630&range=03-04 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23630.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23630/head:pull/23630 PR: https://git.openjdk.org/jdk/pull/23630 From dfenacci at openjdk.org Mon Mar 3 12:58:53 2025 From: dfenacci at openjdk.org (Damon Fenacci) Date: Mon, 3 Mar 2025 12:58:53 GMT Subject: RFR: 8347406: [REDO] C1/C2 don't handle allocation failure properly during initialization (RuntimeStub::new_runtime_stub fatal crash) [v5] In-Reply-To: References:

Message-ID: <7p-BfhPDiY8ImbAwlaBaN1Mre-HA0zpEz42NTQWYMoE=.38ad35e1-0e5f-43b7-9f1d-4c0461881f76@github.com> On Fri, 28 Feb 2025 20:43:03 GMT, Dean Long wrote: >> A slightly modified one surely is. Inserted it again. > > I was thinking it could be moved into the `else` clause and simplified further. Oh I see ?. Moved. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23630#discussion_r1977476672 From xpeng at openjdk.org Mon Mar 3 17:24:02 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 3 Mar 2025 17:24:02 GMT Subject: Integrated: 8338737: Shenandoah: Reset marking bitmaps after the cycle In-Reply-To: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com> References: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com> Message-ID: On Tue, 17 Dec 2024 00:09:25 GMT, Xiaolong Peng wrote: > Reset marking bitmaps after collection cycle; for GenShen only do this for young generation, also choose not do this for Degen and full GC since both are running at safepoint, we should leave safepoint as ASAP. > > I have run same workload for 30s with Shenandoah in generational mode and classic mode, average average time of concurrent reset dropped significantly since in most case bitmap for young gen should have been reset after pervious concurrent cycle finishes if there is no need to preserve bitmap states. > > GenShen: > Before: > > [33.342s][info][gc,stats ] Concurrent Reset = 0.023 s (a = 1921 us) (n = 12) (lvls, us = 133, 385, 1191, 1836, 8878) > > > After: > > [33.597s][info][gc,stats ] Concurrent Reset = 0.004 s (a = 317 us) (n = 13) (lvls, us = 58, 119, 217, 410, 670) > [33.597s][info][gc,stats ] Concurrent Reset After Collect = 0.018 s (a = 1365 us) (n = 13) (lvls, us = 91, 186, 818, 1836, 3872) > > > Shenandoah: > Before: > > [33.144s][info][gc,stats ] Concurrent Reset = 0.014 s (a = 1067 us) (n = 13) (lvls, us = 139, 277, 898, 1328, 2118) > > After: > > [33.128s][info][gc,stats ] Concurrent Reset = 0.003 s (a = 225 us) (n = 13) (lvls, us = 32, 92, 137, 295, 542) > [33.128s][info][gc,stats ] Concurrent Reset After Collect = 0.009 s (a = 661 us) (n = 13) (lvls, us = 92, 160, 594, 896, 1661) > > > Additional changes: > * Remove `ShenandoahResetBitmapClosure` and `ShenandoahPrepareForMarkClosure`, merge the code with `ShenandoahResetBitmapClosure`, saving one iteration over all the regions. > * Use API `ShenandoahGeneration::parallel_heap_region_iterate_free` to iterate the regions, two benefits from this: > - Underneath it calls `ShenandoahHeap::parallel_heap_region_iterate`, which is faster for very light tasks, see https://bugs.openjdk.org/browse/JDK-8337154 > - `ShenandoahGeneration::parallel_heap_region_iterate_free` decorate the closure with `ShenandoahExcludeRegionClosure`, which simplifies the code in closure. > * When `_do_old_gc_bootstrap is true`, instead of reset mark bitmap for old gen separately, simply reset the global generations, so we don't need walk the all regions twice. > * Clean up FullGC code, remove duplicate code. > > Additional tests: > - [x] CONF=macosx-aarch64-server-fastdebug make test T... This pull request has now been integrated. Changeset: 7c187b5d Author: Xiaolong Peng Committer: Paul Hohensee URL: https://git.openjdk.org/jdk/commit/7c187b5d81a653b87fc498101ad9e2d99b72efc6 Stats: 180 lines in 8 files changed: 95 ins; 62 del; 23 mod 8338737: Shenandoah: Reset marking bitmaps after the cycle Reviewed-by: wkemper ------------- PR: https://git.openjdk.org/jdk/pull/22778 From wkemper at openjdk.org Mon Mar 3 18:24:52 2025 From: wkemper at openjdk.org (William Kemper) Date: Mon, 3 Mar 2025 18:24:52 GMT Subject: RFR: 8350605: assert(!heap->is_uncommit_in_progress()) failed: Cannot uncommit bitmaps while resetting them [v3] In-Reply-To: References:

Message-ID: On Fri, 28 Feb 2025 17:44:36 GMT, William Kemper wrote: >> The protocol which is meant to prevent regions from being uncommitted while their bitmaps are being reset may fail. This happens when the control thread attempts to wait for the uncommit thread to finish, but the uncommit thread has not yet indicated that it has started. >> >> ## Testing >> GHA, Dacapo, Extremem, Heapothesys, Diluvian, SpecJBB2015, SpecJVM2008 (with and without stress flags, asserts). Also have run the JTREG test that failed this assertion over 10K times (and counting). > > William Kemper has updated the pull request incrementally with one additional commit since the last revision: > > Comment tweak Tests with uncommit behavior enabled look good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23760#issuecomment-2695210222 From wkemper at openjdk.org Mon Mar 3 18:30:33 2025 From: wkemper at openjdk.org (William Kemper) Date: Mon, 3 Mar 2025 18:30:33 GMT Subject: RFR: 8350898: Shenandoah: Eliminate final roots safepoint [v2] In-Reply-To: References: Message-ID: <5Lr95p3Uwv5w0n3YzDmALQc6KESs9xLnWdGm7p1IwGA=.3df358c6-f5d5-4f10-822d-5905429c050e@github.com> > This PR converts the final roots safepoint operation into a handshake. The safepoint operation still exists, but is only executed when `ShenandoahVerify` is enabled. In addition to this change, this PR also improves the logging for the concurrent preparation for update references from [PR 22688](https://github.com/openjdk/jdk/pull/22688). William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Merge remote-tracking branch 'jdk/master' into eliminate-final-roots - Fix comments - Add whitespace at end of file - More detail for init update refs event message - Use timing tracker for timing verification - Merge remote-tracking branch 'jdk/master' into eliminate-final-roots - WIP: Fix up phase timings for newly concurrent final roots and init update refs - WIP: Combine satb transfer with state propagation, restore phase timing data - WIP: Transfer pointers out of SATB with a handshake - WIP: Clear weak roots flag concurrently ------------- Changes: https://git.openjdk.org/jdk/pull/23830/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23830&range=01 Stats: 291 lines in 14 files changed: 194 ins; 47 del; 50 mod Patch: https://git.openjdk.org/jdk/pull/23830.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23830/head:pull/23830 PR: https://git.openjdk.org/jdk/pull/23830 From xpeng at openjdk.org Mon Mar 3 20:16:32 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 3 Mar 2025 20:16:32 GMT Subject: RFR: 8351077: Shenandoah: Update comments in ShenandoahConcurrentGC::op_reset_after_collect Message-ID: <1drXUZ5QM7_IPvLi3eRBKVx14M0ofow8KF0XlnzaJzY=.b37d216f-4c68-4427-ab2d-f591bf00d18f@github.com> This is a trivial PR to update the code comments in ShenandoahConcurrentGC::op_reset_after_collect. After doing more test and analysis, we have a better understanding why reset bitmap of young gen after concurrent cycle may cause crash if there is pending old GC cycle to execute: When there is soft reference in old gen, but the referent is in young, reseting bitmap of young will cause wrong state of the soft reference, which may lead to expected cashes. ------------- Commit messages: - 8351077: Shenandoah: Update comments in ShenandoahConcurrentGC::op_reset_after_collect Changes: https://git.openjdk.org/jdk/pull/23872/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23872&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351077 Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23872.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23872/head:pull/23872 PR: https://git.openjdk.org/jdk/pull/23872 From wkemper at openjdk.org Mon Mar 3 20:20:05 2025 From: wkemper at openjdk.org (William Kemper) Date: Mon, 3 Mar 2025 20:20:05 GMT Subject: RFR: 8351077: Shenandoah: Update comments in ShenandoahConcurrentGC::op_reset_after_collect In-Reply-To: <1drXUZ5QM7_IPvLi3eRBKVx14M0ofow8KF0XlnzaJzY=.b37d216f-4c68-4427-ab2d-f591bf00d18f@github.com> References: <1drXUZ5QM7_IPvLi3eRBKVx14M0ofow8KF0XlnzaJzY=.b37d216f-4c68-4427-ab2d-f591bf00d18f@github.com> Message-ID: On Mon, 3 Mar 2025 20:12:34 GMT, Xiaolong Peng wrote: > This is a trivial PR to update the code comments in ShenandoahConcurrentGC::op_reset_after_collect. > > After doing more test and analysis, we have a better understanding why reset bitmap of young gen after concurrent cycle may cause crash if there is pending old GC cycle to execute: When there is soft reference in old gen, but the referent is in young, reseting bitmap of young will cause wrong state of the soft reference, which may lead to expected cashes. Thanks for getting to the bottom of this. ------------- Marked as reviewed by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23872#pullrequestreview-2655199892 From xpeng at openjdk.org Mon Mar 3 20:30:59 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 3 Mar 2025 20:30:59 GMT Subject: RFR: 8351077: Shenandoah: Update comments in ShenandoahConcurrentGC::op_reset_after_collect In-Reply-To: <1drXUZ5QM7_IPvLi3eRBKVx14M0ofow8KF0XlnzaJzY=.b37d216f-4c68-4427-ab2d-f591bf00d18f@github.com> References: <1drXUZ5QM7_IPvLi3eRBKVx14M0ofow8KF0XlnzaJzY=.b37d216f-4c68-4427-ab2d-f591bf00d18f@github.com> Message-ID: On Mon, 3 Mar 2025 20:12:34 GMT, Xiaolong Peng wrote: > This is a trivial PR to update the code comments in ShenandoahConcurrentGC::op_reset_after_collect. > > After doing more test and analysis, we have a better understanding why reset bitmap of young gen after concurrent cycle may cause crash if there is pending old GC cycle to execute: When there is soft reference in old gen, but the referent is in young, reseting bitmap of young will cause wrong state of the soft reference, which may lead to expected cashes. Thanks for the review, I'll integrate it since it is really a trivial only for code comments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23872#issuecomment-2695462169 From duke at openjdk.org Mon Mar 3 20:31:00 2025 From: duke at openjdk.org (duke) Date: Mon, 3 Mar 2025 20:31:00 GMT Subject: RFR: 8351077: Shenandoah: Update comments in ShenandoahConcurrentGC::op_reset_after_collect In-Reply-To: <1drXUZ5QM7_IPvLi3eRBKVx14M0ofow8KF0XlnzaJzY=.b37d216f-4c68-4427-ab2d-f591bf00d18f@github.com> References: <1drXUZ5QM7_IPvLi3eRBKVx14M0ofow8KF0XlnzaJzY=.b37d216f-4c68-4427-ab2d-f591bf00d18f@github.com> Message-ID: On Mon, 3 Mar 2025 20:12:34 GMT, Xiaolong Peng wrote: > This is a trivial PR to update the code comments in ShenandoahConcurrentGC::op_reset_after_collect. > > After doing more test and analysis, we have a better understanding why reset bitmap of young gen after concurrent cycle may cause crash if there is pending old GC cycle to execute: When there is soft reference in old gen, but the referent is in young, reseting bitmap of young will cause wrong state of the soft reference, which may lead to expected cashes. @pengxiaolong Your change (at version 3764bf7d41619a2b51bb860e7ae4005e7f8c0e37) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23872#issuecomment-2695464781 From cslucas at openjdk.org Mon Mar 3 21:09:48 2025 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Mon, 3 Mar 2025 21:09:48 GMT Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card tables [v4] In-Reply-To: References: Message-ID: > In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. > > The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase. > > The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table. > > Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address. > > The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged. > > Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code. > > Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry ?) and PowerPC (@TheRealMDoerr ?) platforms could review and test the changes for those platforms, as I have limited access to running tests on them. Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Fix merge conflict - Address PR feedback: no changes to shared files. - Merge master - Addressing PR comments: some refactorings, ppc fix, off-by-one fix. - Relocation of Card Tables ------------- Changes: https://git.openjdk.org/jdk/pull/23170/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23170&range=03 Stats: 305 lines in 30 files changed: 151 ins; 95 del; 59 mod Patch: https://git.openjdk.org/jdk/pull/23170.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23170/head:pull/23170 PR: https://git.openjdk.org/jdk/pull/23170 From ysr at openjdk.org Mon Mar 3 21:19:02 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Mon, 3 Mar 2025 21:19:02 GMT Subject: RFR: 8351077: Shenandoah: Update comments in ShenandoahConcurrentGC::op_reset_after_collect In-Reply-To: <1drXUZ5QM7_IPvLi3eRBKVx14M0ofow8KF0XlnzaJzY=.b37d216f-4c68-4427-ab2d-f591bf00d18f@github.com> References: <1drXUZ5QM7_IPvLi3eRBKVx14M0ofow8KF0XlnzaJzY=.b37d216f-4c68-4427-ab2d-f591bf00d18f@github.com> Message-ID: On Mon, 3 Mar 2025 20:12:34 GMT, Xiaolong Peng wrote: > This is a trivial PR to update the code comments in ShenandoahConcurrentGC::op_reset_after_collect. > > After doing more test and analysis, we have a better understanding why reset bitmap of young gen after concurrent cycle may cause crash if there is pending old GC cycle to execute: When there is soft reference in old gen, but the referent is in young, reseting bitmap of young will cause wrong state of the soft reference, which may lead to expected cashes. src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 1235: > 1233: // Valid bitmap of young generation is needed by concurrent weak references phase of old GC cycle, > 1234: // because it is possible that there is soft reference in old generation with the referent in young generation; > 1235: // therefore mark bitmap of young generation can't be reset if there will be old GC after the concurrent GC cycle. I don't understand the comment. If the soft reference in old gen points to its referent in the young gen, then the latter should be either reachable, or should have been cleared (depending on who discovered the soft reference & the soft reference clearing policy). If the former, the old gen card should be dirty. May be I am confused about the change in comment, but this may be pointing to a bug in the reference processing code or the associated card-marking code. Or I am not clearly understanding your comment in context. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23872#discussion_r1978221380 From ysr at openjdk.org Mon Mar 3 23:01:07 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Mon, 3 Mar 2025 23:01:07 GMT Subject: RFR: 8349094: GenShen: Race between control and regulator threads may violate assertions [v18] In-Reply-To: References:

Message-ID: <9rfQ1rnji3vwQIPlRGqVmh_PwZxLdvcYv-JuukdP7G0=.b4583678-800b-416a-a154-b878535189e4@github.com> On Fri, 28 Feb 2025 17:17:17 GMT, William Kemper wrote: >> There are several changes to the operation of Shenandoah's control threads here. >> * The reason for cancellation is now recorded in `ShenandoahHeap::_cancelled_gc` as a `GCCause`, instead of various member variables in the control thread. >> * The cancellation handling is driven entirely by the cancellation cause >> * The graceful shutdown, alloc failure, humongous alloc failure and preemption requested flags are all removed >> * The shutdown sequence is simpler >> * The generational control thread uses a lock to coordinate updates to the requested cause and generation >> * APIs have been simplified to avoid converting between the generation `type` and the actual generation instance >> * The old heuristic, rather than the control thread itself, is now responsible for resuming old generation cycles >> * The control thread doesn't loop on its own (unless the pacer is enabled). >> >> ## Testing >> * jtreg hotspot_gc_shenandoah >> * dacapo, extremem, diluvian, specjbb2015, specjvm2018, heapothesys > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits: > > - Merge remote-tracking branch 'jdk/master' into fix-control-regulator-threads > - Don't check for shutdown in control thread loop condition > > It may cause the thread to exit before it is requested to stop > - Add assertions about old gen state when resuming old cycles > - Remove duplicated field pointer for old generation > - Improve names and comments > - Merge tag 'jdk-25+11' into fix-control-regulator-threads > > Added tag jdk-25+11 for changeset 0131c1bf > - Address review feedback (better comments, better names) > - Merge remote-tracking branch 'jdk/master' into fix-control-regulator-threads > - Old gen bootstrap cycle must make it to init mark > - Merge remote-tracking branch 'jdk/master' into fix-control-regulator-threads > - ... and 27 more: https://git.openjdk.org/jdk/compare/e98df71d...37e445d6 ? ------------- Marked as reviewed by ysr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23475#pullrequestreview-2655535655 From ysr at openjdk.org Mon Mar 3 23:08:06 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Mon, 3 Mar 2025 23:08:06 GMT Subject: RFR: 8350605: assert(!heap->is_uncommit_in_progress()) failed: Cannot uncommit bitmaps while resetting them [v3] In-Reply-To: References:

Message-ID: On Fri, 28 Feb 2025 17:44:57 GMT, William Kemper wrote: > That's a good point. I created a branch that enables uncommit for the test pipelines when I made this original change. I'll resurrect that branch and run that configuration again. Thanks. Any reason not to have (a subset or all) non-performance testing in pipeline run with the default of uncommit enabled? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23760#issuecomment-2695768379 From ysr at openjdk.org Mon Mar 3 23:52:53 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Mon, 3 Mar 2025 23:52:53 GMT Subject: RFR: 8350605: assert(!heap->is_uncommit_in_progress()) failed: Cannot uncommit bitmaps while resetting them [v3] In-Reply-To: References:

Message-ID: On Tue, 4 Mar 2025 00:02:29 GMT, Y. Srinivas Ramakrishna wrote: >> src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 1235: >> >>> 1233: // Valid bitmap of young generation is needed by concurrent weak references phase of old GC cycle, >>> 1234: // because it is possible that there is soft reference in old generation with the referent in young generation; >>> 1235: // therefore mark bitmap of young generation can't be reset if there will be old GC after the concurrent GC cycle. >> >> I don't understand the comment. If the soft reference in old gen points to its referent in the young gen, then the latter should be either reachable, or should have been cleared (depending on who discovered the soft reference & the soft reference clearing policy). If the former, the old gen card should be dirty. >> >> May be I am confused about the change in comment, but this may be pointing to a bug in the reference processing code or the associated card-marking code. >> >> Or I am not clearly understanding your comment in context. > > Thanks @earthling-amzn for explaining the issue to me offline. Based on my current understanding of the issue from that explanation, I'd suggest rewording the comment as follows: > > // If we are in the midst of an old gc bootstrap or an old marking, we want to leave the mark bit map of > // the young generation intact. In particular, reference processing in the old generation may potentially > // need the reachability of a young generation referent of a Reference object in the old generation. Thank you Ramki, I'll update the comments and refresh the PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23872#discussion_r1978411180 From wkemper at openjdk.org Tue Mar 4 00:44:58 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 4 Mar 2025 00:44:58 GMT Subject: Integrated: 8349094: GenShen: Race between control and regulator threads may violate assertions In-Reply-To: References: Message-ID: On Wed, 5 Feb 2025 22:30:35 GMT, William Kemper wrote: > There are several changes to the operation of Shenandoah's control threads here. > * The reason for cancellation is now recorded in `ShenandoahHeap::_cancelled_gc` as a `GCCause`, instead of various member variables in the control thread. > * The cancellation handling is driven entirely by the cancellation cause > * The graceful shutdown, alloc failure, humongous alloc failure and preemption requested flags are all removed > * The shutdown sequence is simpler > * The generational control thread uses a lock to coordinate updates to the requested cause and generation > * APIs have been simplified to avoid converting between the generation `type` and the actual generation instance > * The old heuristic, rather than the control thread itself, is now responsible for resuming old generation cycles > * The control thread doesn't loop on its own (unless the pacer is enabled). > > ## Testing > * jtreg hotspot_gc_shenandoah > * dacapo, extremem, diluvian, specjbb2015, specjvm2018, heapothesys This pull request has now been integrated. Changeset: 3a8a432c Author: William Kemper URL: https://git.openjdk.org/jdk/commit/3a8a432c05999fe478b94de75b416404b5a515d2 Stats: 963 lines in 18 files changed: 327 ins; 294 del; 342 mod 8349094: GenShen: Race between control and regulator threads may violate assertions Reviewed-by: ysr, kdnilsen ------------- PR: https://git.openjdk.org/jdk/pull/23475 From wkemper at openjdk.org Tue Mar 4 00:57:06 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 4 Mar 2025 00:57:06 GMT Subject: RFR: 8350605: assert(!heap->is_uncommit_in_progress()) failed: Cannot uncommit bitmaps while resetting them [v4] In-Reply-To: References: Message-ID: > The protocol which is meant to prevent regions from being uncommitted while their bitmaps are being reset may fail. This happens when the control thread attempts to wait for the uncommit thread to finish, but the uncommit thread has not yet indicated that it has started. > > ## Testing > GHA, Dacapo, Extremem, Heapothesys, Diluvian, SpecJBB2015, SpecJVM2008 (with and without stress flags, asserts). Also have run the JTREG test that failed this assertion over 10K times (and counting). William Kemper has updated the pull request incrementally with one additional commit since the last revision: Document parameters for do_uncommit_work ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23760/files - new: https://git.openjdk.org/jdk/pull/23760/files/1c32c0e3..e25e6276 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23760&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23760&range=02-03 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23760.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23760/head:pull/23760 PR: https://git.openjdk.org/jdk/pull/23760 From wkemper at openjdk.org Tue Mar 4 00:57:06 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 4 Mar 2025 00:57:06 GMT Subject: RFR: 8350605: assert(!heap->is_uncommit_in_progress()) failed: Cannot uncommit bitmaps while resetting them [v3] In-Reply-To: References:

Message-ID: On Mon, 3 Mar 2025 23:05:45 GMT, Y. Srinivas Ramakrishna wrote: >> That's a good point. I created a branch that enables uncommit for the test pipelines when I made this original change. I'll resurrect that branch and run that configuration again. Thanks. > >> That's a good point. I created a branch that enables uncommit for the test pipelines when I made this original change. I'll resurrect that branch and run that configuration again. Thanks. > > Any reason not to have (a subset or all) non-performance testing in pipeline run with the default of uncommit enabled? @ysramakrishna , I will enable uncommit for the stress tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23760#issuecomment-2695908894 From wkemper at openjdk.org Tue Mar 4 00:57:06 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 4 Mar 2025 00:57:06 GMT Subject: RFR: 8350605: assert(!heap->is_uncommit_in_progress()) failed: Cannot uncommit bitmaps while resetting them [v3] In-Reply-To: References:

Message-ID: On Mon, 3 Mar 2025 23:40:25 GMT, Y. Srinivas Ramakrishna wrote: >> William Kemper has updated the pull request incrementally with one additional commit since the last revision: >> >> Comment tweak > > src/hotspot/share/gc/shenandoah/shenandoahUncommitThread.hpp line 65: > >> 63: // Iterate and uncommit eligible regions. Return the number of regions uncommitted. >> 64: // This operation may be interrupted if the GC calls `forbid_uncommit`. >> 65: size_t do_uncommit_work(double shrink_before, size_t shrink_until) const; > > I'd document the semantics of the parameters too: > > // Iterate over and uncommit eligible regions unless committed heap would fall below `shrink_until` . > // A region is eligible if it's been empty for at least `shrink_before` > // Returns the number of regions uncommitted. May be interrupted by `forbid_uncommit`. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23760#discussion_r1978440214 From xpeng at openjdk.org Tue Mar 4 00:58:27 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 4 Mar 2025 00:58:27 GMT Subject: RFR: 8351077: Shenandoah: Update comments in ShenandoahConcurrentGC::op_reset_after_collect [v2] In-Reply-To: <1drXUZ5QM7_IPvLi3eRBKVx14M0ofow8KF0XlnzaJzY=.b37d216f-4c68-4427-ab2d-f591bf00d18f@github.com> References: <1drXUZ5QM7_IPvLi3eRBKVx14M0ofow8KF0XlnzaJzY=.b37d216f-4c68-4427-ab2d-f591bf00d18f@github.com> Message-ID: <6GKNvjF02TlZU_UZMNtWnzbs_BIRVf2x1UeiDIFg4hU=.160089d2-5601-4fc4-9d77-2fb6aa09d18b@github.com> > This is a trivial PR to update the code comments in ShenandoahConcurrentGC::op_reset_after_collect. > > After doing more test and analysis, we have a better understanding why reset bitmap of young gen after concurrent cycle may cause crash if there is pending old GC cycle to execute: When there is soft reference in old gen, but the referent is in young, reseting bitmap of young will cause wrong state of the soft reference, which may lead to expected cashes. Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Update code comments as suggested in PR ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23872/files - new: https://git.openjdk.org/jdk/pull/23872/files/3764bf7d..d760471e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23872&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23872&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23872.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23872/head:pull/23872 PR: https://git.openjdk.org/jdk/pull/23872 From xpeng at openjdk.org Tue Mar 4 00:58:27 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 4 Mar 2025 00:58:27 GMT Subject: RFR: 8351077: Shenandoah: Update comments in ShenandoahConcurrentGC::op_reset_after_collect [v2] In-Reply-To: References: <1drXUZ5QM7_IPvLi3eRBKVx14M0ofow8KF0XlnzaJzY=.b37d216f-4c68-4427-ab2d-f591bf00d18f@github.com> Message-ID: On Tue, 4 Mar 2025 00:08:27 GMT, Y. Srinivas Ramakrishna wrote: >> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Update code comments as suggested in PR > > ? > > small suggested rewording, although what you have also works. > > (I'll think some more about this to fully understand the context. Thanks.) Thank you @ysramakrishna and @earthling-amzn! I have updated the comments as you have suggested in the PR review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23872#issuecomment-2695910096 From wkemper at openjdk.org Tue Mar 4 01:08:54 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 4 Mar 2025 01:08:54 GMT Subject: RFR: 8351077: Shenandoah: Update comments in ShenandoahConcurrentGC::op_reset_after_collect [v2] In-Reply-To: <6GKNvjF02TlZU_UZMNtWnzbs_BIRVf2x1UeiDIFg4hU=.160089d2-5601-4fc4-9d77-2fb6aa09d18b@github.com> References: <1drXUZ5QM7_IPvLi3eRBKVx14M0ofow8KF0XlnzaJzY=.b37d216f-4c68-4427-ab2d-f591bf00d18f@github.com> <6GKNvjF02TlZU_UZMNtWnzbs_BIRVf2x1UeiDIFg4hU=.160089d2-5601-4fc4-9d77-2fb6aa09d18b@github.com> Message-ID: On Tue, 4 Mar 2025 00:58:27 GMT, Xiaolong Peng wrote: >> This is a trivial PR to update the code comments in ShenandoahConcurrentGC::op_reset_after_collect. >> >> After doing more test and analysis, we have a better understanding why reset bitmap of young gen after concurrent cycle may cause crash if there is pending old GC cycle to execute: When there is soft reference in old gen, but the referent is in young, reseting bitmap of young will cause wrong state of the soft reference, which may lead to expected cashes. > > Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: > > Update code comments as suggested in PR Marked as reviewed by wkemper (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23872#pullrequestreview-2655679787 From duke at openjdk.org Tue Mar 4 01:19:52 2025 From: duke at openjdk.org (duke) Date: Tue, 4 Mar 2025 01:19:52 GMT Subject: RFR: 8351077: Shenandoah: Update comments in ShenandoahConcurrentGC::op_reset_after_collect [v2] In-Reply-To: <6GKNvjF02TlZU_UZMNtWnzbs_BIRVf2x1UeiDIFg4hU=.160089d2-5601-4fc4-9d77-2fb6aa09d18b@github.com> References: <1drXUZ5QM7_IPvLi3eRBKVx14M0ofow8KF0XlnzaJzY=.b37d216f-4c68-4427-ab2d-f591bf00d18f@github.com> <6GKNvjF02TlZU_UZMNtWnzbs_BIRVf2x1UeiDIFg4hU=.160089d2-5601-4fc4-9d77-2fb6aa09d18b@github.com> Message-ID: On Tue, 4 Mar 2025 00:58:27 GMT, Xiaolong Peng wrote: >> This is a trivial PR to update the code comments in ShenandoahConcurrentGC::op_reset_after_collect. >> >> After doing more test and analysis, we have a better understanding why reset bitmap of young gen after concurrent cycle may cause crash if there is pending old GC cycle to execute: When there is soft reference in old gen, but the referent is in young, reseting bitmap of young will cause wrong state of the soft reference, which may lead to expected cashes. > > Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: > > Update code comments as suggested in PR @pengxiaolong Your change (at version d760471e5a84bc45466ba2d676f97a0efcb477db) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23872#issuecomment-2695934719 From ysr at openjdk.org Tue Mar 4 02:13:54 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Tue, 4 Mar 2025 02:13:54 GMT Subject: RFR: 8350605: assert(!heap->is_uncommit_in_progress()) failed: Cannot uncommit bitmaps while resetting them [v4] In-Reply-To: References:

Message-ID: On Tue, 4 Mar 2025 00:57:06 GMT, William Kemper wrote: >> The protocol which is meant to prevent regions from being uncommitted while their bitmaps are being reset may fail. This happens when the control thread attempts to wait for the uncommit thread to finish, but the uncommit thread has not yet indicated that it has started. >> >> ## Testing >> GHA, Dacapo, Extremem, Heapothesys, Diluvian, SpecJBB2015, SpecJVM2008 (with and without stress flags, asserts). Also have run the JTREG test that failed this assertion over 10K times (and counting). > > William Kemper has updated the pull request incrementally with one additional commit since the last revision: > > Document parameters for do_uncommit_work Marked as reviewed by ysr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23760#pullrequestreview-2655747950 From xpeng at openjdk.org Tue Mar 4 03:58:56 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 4 Mar 2025 03:58:56 GMT Subject: Integrated: 8351077: Shenandoah: Update comments in ShenandoahConcurrentGC::op_reset_after_collect In-Reply-To: <1drXUZ5QM7_IPvLi3eRBKVx14M0ofow8KF0XlnzaJzY=.b37d216f-4c68-4427-ab2d-f591bf00d18f@github.com> References: <1drXUZ5QM7_IPvLi3eRBKVx14M0ofow8KF0XlnzaJzY=.b37d216f-4c68-4427-ab2d-f591bf00d18f@github.com> Message-ID: On Mon, 3 Mar 2025 20:12:34 GMT, Xiaolong Peng wrote: > This is a trivial PR to update the code comments in ShenandoahConcurrentGC::op_reset_after_collect. > > After doing more test and analysis, we have a better understanding why reset bitmap of young gen after concurrent cycle may cause crash if there is pending old GC cycle to execute: When there is soft reference in old gen, but the referent is in young, reseting bitmap of young will cause wrong state of the soft reference, which may lead to expected cashes. This pull request has now been integrated. Changeset: 7c173fde Author: Xiaolong Peng URL: https://git.openjdk.org/jdk/commit/7c173fde4274a798f299876492a2cd833eee9fdd Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 mod 8351077: Shenandoah: Update comments in ShenandoahConcurrentGC::op_reset_after_collect Reviewed-by: wkemper, ysr ------------- PR: https://git.openjdk.org/jdk/pull/23872 From cslucas at openjdk.org Tue Mar 4 04:10:25 2025 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Tue, 4 Mar 2025 04:10:25 GMT Subject: RFR: 8351081: Off-by-one error in ShenandoahCardCluster Message-ID: Given certain values for the variables in [this expression](https://github.com/openjdk/jdk/blob/a87dd1a75f78cf872df49bea83ba48af8acfa2fd/src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp#L173) the result of the computation can be equal to `_ rs->total_cards()` which will lead to segmentation fault, for instance in [starts_object(card_at_end)](https://github.com/openjdk/jdk/blob/a87dd1a75f78cf872df49bea83ba48af8acfa2fd/src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp#L393). The problem happens, though, because the `_object_starts` array doesn't have a [guarding entry](https://github.com/openjdk/jdk/blob/a87dd1a75f78cf872df49bea83ba48af8acfa2fd/src/hotspot/share/gc/shenandoah/shenandoahCardTable.cpp#L37) at the end. This pull request adjusts the allocation of `_object_starts` to include an additional entry at the end to account for this situation. Tested with JTREG tier 1-4, x86_64 & AArch64 on Linux. ------------- Commit messages: - Adjust allocation of object_starts Changes: https://git.openjdk.org/jdk/pull/23882/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23882&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351081 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23882.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23882/head:pull/23882 PR: https://git.openjdk.org/jdk/pull/23882 From cslucas at openjdk.org Tue Mar 4 04:13:33 2025 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Tue, 4 Mar 2025 04:13:33 GMT Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card tables [v5] In-Reply-To: References: Message-ID: > In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. > > The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase. > > The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table. > > Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address. > > The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged. > > Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code. > > Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry ?) and PowerPC (@TheRealMDoerr ?) platforms could review and test the changes for those platforms, as I have limited access to running tests on them. Cesar Soares Lucas has updated the pull request incrementally with two additional commits since the last revision: - Revert changes to shared cardTable.hpp - Revert changes to shared cardTable.hpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23170/files - new: https://git.openjdk.org/jdk/pull/23170/files/6210f026..717b8b44 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23170&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23170&range=03-04 Stats: 6 lines in 1 file changed: 0 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/23170.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23170/head:pull/23170 PR: https://git.openjdk.org/jdk/pull/23170 From cslucas at openjdk.org Tue Mar 4 04:16:03 2025 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Tue, 4 Mar 2025 04:16:03 GMT Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card tables [v3] In-Reply-To: References: <6_AoWQhldJttOIEOL1T7HSapPzE4Qn2j4WN7E-bI3rM=.2685d3d8-e47c-42a6-845b-b68f50cc568e@github.com>

Message-ID: On Thu, 20 Feb 2025 15:33:35 GMT, Aleksey Shipilev wrote: >> src/hotspot/share/gc/shared/cardTable.hpp line 205: >> >>> 203: virtual CardValue* byte_map_base() const { return _byte_map_base; } >>> 204: >>> 205: virtual CardValue* byte_map() const { return _byte_map; } >> >> @shipilev - can you please confirm that this is the part that you didn't like? > > Yes, I am not fond of extending `CardTable` with virtual members, especially if they can be used on high-performance paths. Not sure if the following idea is viable. > > ShenandoahBarrierSet knows where to get card table base: from Shenandoah thread local data. Now it looks like we need to deal with two problems: > 1. Protect ourselves from accidentally calling `CardTable` methods that may reference "incorrect" `_byte_map_(base)`. To do that, it looks it is enough to initialize `CardTable::_byte_map_(base)` to non-sensical values (`nullptr`-s?), and let the testing crash. > 2. Allow calls to `CardTable` utility methods with our base. For that, I think we can drill a few new (non-virtual) methods in `CardTable`, and enter from Shenandoah through them. So for example `byte_for_index(const size_t card_index)` becomes: > ``` > CardValue* byte_for_index(const CardValue* base, const size_t card_index) const { > return base + card_index; > } > CardValue* byte_for_index(const size_t card_index) const { > return byte_for_index(_byte_map, card_index); > } > ``` @shipilev - can you please take a look at the latest pushes? I realized that the logic implemented already keeps the fields of the base card table class always updated, therefore I don't really need to make the methods (`_byte_map_(base)` virtual at all. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1978578378 From shade at openjdk.org Tue Mar 4 11:51:07 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 4 Mar 2025 11:51:07 GMT Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port In-Reply-To: References: Message-ID: On Thu, 5 Dec 2024 08:26:10 GMT, Aleksey Shipilev wrote: > **NOTE: This is work-in-progress draft for interested parties. The JEP is not even submitted, let alone targeted.** > > My plan is to to get this done in a quiet time in mainline to limit the ongoing conflicts with mainline. Feel free to comment in this PR, if you see something ahead of time. These comments might adjust the trajectory we take to implement this removal and/or allows us submit and work out more RFEs ahead of this removal. I plan to re-open a clean PR after this preliminary PR is done, maybe after the round of preliminary reviews. > > This removes the 32-bit x86 port and does a deeper cleaning in Hotspot. The following paragraphs describe what and why was being done. > > Easy stuff first: all files named `*_x86_32` are gone. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. > > The code under `!LP64`, `!AMD64` and `IA32` is removed in `x86`-specific files. There is quite a bit of the code, especially around `Assembler` and `MacroAssembler`. I think these removals make the whole thing cleaner. The downside is that some of the `MacroAssembler::*ptr` functions that were used to select the "machine pointer" instructions either from x86_64 or x86_32 are now exclusively for x86_64. I don't think we want to rewrite `*ptr` -> `*q` at this point. I think we gradually morph the code base to use `*q`-flavored methods in new code. > > x86_32 is the only platform that has special cases for x87 FPU. > > C1 even implements the whole separate thing to deal with x87 FPU: the parts of regalloc treat it specially, there is `FpuStackSim`, there is `VerifyFPU` family of flags, etc. There are also peculiarities with FP conversions that use FPU, that's why x86_32 used to have template interpreter stubs for FP conversion methods. None of that is needed anymore without x86_32. This cleans up some arch-specific code as well. > > Both C1 and C2 implement the workarounds for non-IEEE compliant rounding of x87 FPU. After x86_32 is gone, these are not needed anymore. This removes some C2 nodes, removes the rounding instructions in C1. > > x86_64 is baselined on SSE2+, the VM would not even start if SSE2 is not supported. Most of the checks that we have for `UseSSE < 2` are for the benefit of x86_32. Because of this I folded redundant `UseSSE` checks around Hotspot. > > The one thing I _deliberately_ avoided doing is merging `x86.ad` and `x86_64.ad`. It would likely introduce uncomfortable amount of conflicts with pending work in mainli... Great, thanks for the feedback. I think we are going to go with the JEP implementation that removes the easy parts of x86_32 code, and then do the deeper cleanups under [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella. I added some subtasks there, based on the commits from this bulk PR. I am closing this PR in favor of about-to-be-created cleaner PR for JEP 503. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22567#issuecomment-2697266596 From shade at openjdk.org Tue Mar 4 11:51:07 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 4 Mar 2025 11:51:07 GMT Subject: Withdrawn: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port In-Reply-To: References: Message-ID: On Thu, 5 Dec 2024 08:26:10 GMT, Aleksey Shipilev wrote: > **NOTE: This is work-in-progress draft for interested parties. The JEP is not even submitted, let alone targeted.** > > My plan is to to get this done in a quiet time in mainline to limit the ongoing conflicts with mainline. Feel free to comment in this PR, if you see something ahead of time. These comments might adjust the trajectory we take to implement this removal and/or allows us submit and work out more RFEs ahead of this removal. I plan to re-open a clean PR after this preliminary PR is done, maybe after the round of preliminary reviews. > > This removes the 32-bit x86 port and does a deeper cleaning in Hotspot. The following paragraphs describe what and why was being done. > > Easy stuff first: all files named `*_x86_32` are gone. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. > > The code under `!LP64`, `!AMD64` and `IA32` is removed in `x86`-specific files. There is quite a bit of the code, especially around `Assembler` and `MacroAssembler`. I think these removals make the whole thing cleaner. The downside is that some of the `MacroAssembler::*ptr` functions that were used to select the "machine pointer" instructions either from x86_64 or x86_32 are now exclusively for x86_64. I don't think we want to rewrite `*ptr` -> `*q` at this point. I think we gradually morph the code base to use `*q`-flavored methods in new code. > > x86_32 is the only platform that has special cases for x87 FPU. > > C1 even implements the whole separate thing to deal with x87 FPU: the parts of regalloc treat it specially, there is `FpuStackSim`, there is `VerifyFPU` family of flags, etc. There are also peculiarities with FP conversions that use FPU, that's why x86_32 used to have template interpreter stubs for FP conversion methods. None of that is needed anymore without x86_32. This cleans up some arch-specific code as well. > > Both C1 and C2 implement the workarounds for non-IEEE compliant rounding of x87 FPU. After x86_32 is gone, these are not needed anymore. This removes some C2 nodes, removes the rounding instructions in C1. > > x86_64 is baselined on SSE2+, the VM would not even start if SSE2 is not supported. Most of the checks that we have for `UseSSE < 2` are for the benefit of x86_32. Because of this I folded redundant `UseSSE` checks around Hotspot. > > The one thing I _deliberately_ avoided doing is merging `x86.ad` and `x86_64.ad`. It would likely introduce uncomfortable amount of conflicts with pending work in mainli... This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/22567 From kdnilsen at openjdk.org Tue Mar 4 15:02:04 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 4 Mar 2025 15:02:04 GMT Subject: RFR: 8350898: Shenandoah: Eliminate final roots safepoint [v2] In-Reply-To: <5Lr95p3Uwv5w0n3YzDmALQc6KESs9xLnWdGm7p1IwGA=.3df358c6-f5d5-4f10-822d-5905429c050e@github.com> References: <5Lr95p3Uwv5w0n3YzDmALQc6KESs9xLnWdGm7p1IwGA=.3df358c6-f5d5-4f10-822d-5905429c050e@github.com> Message-ID: On Mon, 3 Mar 2025 18:30:33 GMT, William Kemper wrote: >> This PR converts the final roots safepoint operation into a handshake. The safepoint operation still exists, but is only executed when `ShenandoahVerify` is enabled. In addition to this change, this PR also improves the logging for the concurrent preparation for update references from [PR 22688](https://github.com/openjdk/jdk/pull/22688). > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - Merge remote-tracking branch 'jdk/master' into eliminate-final-roots > - Fix comments > - Add whitespace at end of file > - More detail for init update refs event message > - Use timing tracker for timing verification > - Merge remote-tracking branch 'jdk/master' into eliminate-final-roots > - WIP: Fix up phase timings for newly concurrent final roots and init update refs > - WIP: Combine satb transfer with state propagation, restore phase timing data > - WIP: Transfer pointers out of SATB with a handshake > - WIP: Clear weak roots flag concurrently Thanks. Great improvement. src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 458: > 456: > 457: // Step 1. All threads need to 'complete' partially filled, thread local buffers. This > 458: // is accomplished in ShenandoahConcurrentGC::complete_abbreviated_cycle using a Handshake I think we're talking about "complete processing" of thread-local satb buffers. To avoid confusion with tlab, maybe add satb to this comment. ------------- Marked as reviewed by kdnilsen (Committer). PR Review: https://git.openjdk.org/jdk/pull/23830#pullrequestreview-2657883998 PR Review Comment: https://git.openjdk.org/jdk/pull/23830#discussion_r1979620964 From kdnilsen at openjdk.org Tue Mar 4 15:04:59 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 4 Mar 2025 15:04:59 GMT Subject: RFR: 8350605: assert(!heap->is_uncommit_in_progress()) failed: Cannot uncommit bitmaps while resetting them [v4] In-Reply-To: References:

Message-ID: On Tue, 4 Mar 2025 00:57:06 GMT, William Kemper wrote: >> The protocol which is meant to prevent regions from being uncommitted while their bitmaps are being reset may fail. This happens when the control thread attempts to wait for the uncommit thread to finish, but the uncommit thread has not yet indicated that it has started. >> >> ## Testing >> GHA, Dacapo, Extremem, Heapothesys, Diluvian, SpecJBB2015, SpecJVM2008 (with and without stress flags, asserts). Also have run the JTREG test that failed this assertion over 10K times (and counting). > > William Kemper has updated the pull request incrementally with one additional commit since the last revision: > > Document parameters for do_uncommit_work Repeat approval. ------------- Marked as reviewed by kdnilsen (Committer). PR Review: https://git.openjdk.org/jdk/pull/23760#pullrequestreview-2657921882 From wkemper at openjdk.org Tue Mar 4 17:14:58 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 4 Mar 2025 17:14:58 GMT Subject: Integrated: 8350605: assert(!heap->is_uncommit_in_progress()) failed: Cannot uncommit bitmaps while resetting them In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 01:38:14 GMT, William Kemper wrote: > The protocol which is meant to prevent regions from being uncommitted while their bitmaps are being reset may fail. This happens when the control thread attempts to wait for the uncommit thread to finish, but the uncommit thread has not yet indicated that it has started. > > ## Testing > GHA, Dacapo, Extremem, Heapothesys, Diluvian, SpecJBB2015, SpecJVM2008 (with and without stress flags, asserts). Also have run the JTREG test that failed this assertion over 10K times (and counting). This pull request has now been integrated. Changeset: fe806caa Author: William Kemper URL: https://git.openjdk.org/jdk/commit/fe806caa160b2d550db273af17dc08270f143819 Stats: 79 lines in 2 files changed: 41 ins; 24 del; 14 mod 8350605: assert(!heap->is_uncommit_in_progress()) failed: Cannot uncommit bitmaps while resetting them Reviewed-by: kdnilsen, ysr ------------- PR: https://git.openjdk.org/jdk/pull/23760 From wkemper at openjdk.org Tue Mar 4 17:14:54 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 4 Mar 2025 17:14:54 GMT Subject: RFR: 8350898: Shenandoah: Eliminate final roots safepoint [v2] In-Reply-To: References: <5Lr95p3Uwv5w0n3YzDmALQc6KESs9xLnWdGm7p1IwGA=.3df358c6-f5d5-4f10-822d-5905429c050e@github.com> Message-ID: On Tue, 4 Mar 2025 14:52:23 GMT, Kelvin Nilsen wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: >> >> - Merge remote-tracking branch 'jdk/master' into eliminate-final-roots >> - Fix comments >> - Add whitespace at end of file >> - More detail for init update refs event message >> - Use timing tracker for timing verification >> - Merge remote-tracking branch 'jdk/master' into eliminate-final-roots >> - WIP: Fix up phase timings for newly concurrent final roots and init update refs >> - WIP: Combine satb transfer with state propagation, restore phase timing data >> - WIP: Transfer pointers out of SATB with a handshake >> - WIP: Clear weak roots flag concurrently > > src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 458: > >> 456: >> 457: // Step 1. All threads need to 'complete' partially filled, thread local buffers. This >> 458: // is accomplished in ShenandoahConcurrentGC::complete_abbreviated_cycle using a Handshake > > I think we're talking about "complete processing" of thread-local satb buffers. To avoid confusion with tlab, maybe add satb to this comment. Yes, good point. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23830#discussion_r1979884800 From wkemper at openjdk.org Tue Mar 4 17:18:37 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 4 Mar 2025 17:18:37 GMT Subject: RFR: 8350898: Shenandoah: Eliminate final roots safepoint [v3] In-Reply-To: References: Message-ID: > This PR converts the final roots safepoint operation into a handshake. The safepoint operation still exists, but is only executed when `ShenandoahVerify` is enabled. In addition to this change, this PR also improves the logging for the concurrent preparation for update references from [PR 22688](https://github.com/openjdk/jdk/pull/22688). William Kemper has updated the pull request incrementally with one additional commit since the last revision: Clarify which thread local buffers in comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23830/files - new: https://git.openjdk.org/jdk/pull/23830/files/0b2675af..390de7f9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23830&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23830&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23830.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23830/head:pull/23830 PR: https://git.openjdk.org/jdk/pull/23830 From wkemper at openjdk.org Tue Mar 4 18:40:55 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 4 Mar 2025 18:40:55 GMT Subject: RFR: 8351081: Off-by-one error in ShenandoahCardCluster In-Reply-To: References: Message-ID: <6todYj98wTBywpKJ8GkvakvJGoPiAvF2Gurs01Pq6t0=.8cfb3200-86a3-4289-91c4-5fdfdb7d82bb@github.com> On Tue, 4 Mar 2025 04:06:00 GMT, Cesar Soares Lucas wrote: > Given certain values for the variables in [this expression](https://github.com/openjdk/jdk/blob/a87dd1a75f78cf872df49bea83ba48af8acfa2fd/src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp#L173) the result of the computation can be equal to `_ rs->total_cards()` which will lead to segmentation fault, for instance in [starts_object(card_at_end)](https://github.com/openjdk/jdk/blob/a87dd1a75f78cf872df49bea83ba48af8acfa2fd/src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp#L393). The problem happens, though, because the `_object_starts` array doesn't have a [guarding entry](https://github.com/openjdk/jdk/blob/a87dd1a75f78cf872df49bea83ba48af8acfa2fd/src/hotspot/share/gc/shenandoah/shenandoahCardTable.cpp#L37) at the end. This pull request adjusts the allocation of `_object_starts` to include an additional entry at the end to account for this situation. > > Tested with JTREG tier 1-4, x86_64 & AArch64 on Linux. LGTM. ------------- Marked as reviewed by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23882#pullrequestreview-2658615578 From duke at openjdk.org Tue Mar 4 19:18:59 2025 From: duke at openjdk.org (duke) Date: Tue, 4 Mar 2025 19:18:59 GMT Subject: RFR: 8351081: Off-by-one error in ShenandoahCardCluster In-Reply-To: References: Message-ID: <65Nau_mejcjgMsRM1Qli2hkyeEJlXGZxDExGV6vmWcQ=.84f05fff-f04c-4708-bb40-b974a99aff5e@github.com> On Tue, 4 Mar 2025 04:06:00 GMT, Cesar Soares Lucas wrote: > Given certain values for the variables in [this expression](https://github.com/openjdk/jdk/blob/a87dd1a75f78cf872df49bea83ba48af8acfa2fd/src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp#L173) the result of the computation can be equal to `_ rs->total_cards()` which will lead to segmentation fault, for instance in [starts_object(card_at_end)](https://github.com/openjdk/jdk/blob/a87dd1a75f78cf872df49bea83ba48af8acfa2fd/src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp#L393). The problem happens, though, because the `_object_starts` array doesn't have a [guarding entry](https://github.com/openjdk/jdk/blob/a87dd1a75f78cf872df49bea83ba48af8acfa2fd/src/hotspot/share/gc/shenandoah/shenandoahCardTable.cpp#L37) at the end. This pull request adjusts the allocation of `_object_starts` to include an additional entry at the end to account for this situation. > > Tested with JTREG tier 1-4, x86_64 & AArch64 on Linux. @JohnTortugo Your change (at version 9a4ac53343aaa62b055241f90bd6d610a483ed66) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23882#issuecomment-2698667853 From shade at openjdk.org Tue Mar 4 20:09:58 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 4 Mar 2025 20:09:58 GMT Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card tables [v5] In-Reply-To: References:

Message-ID: <2ZFtKLn2EcbzjKQ_USb3yiOWEWQJYocFwj_rk-5h0Jg=.f4eec566-3e0c-4a75-8c27-2cb785b0081a@github.com> On Tue, 4 Mar 2025 04:13:33 GMT, Cesar Soares Lucas wrote: >> In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. >> >> The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase. >> >> The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table. >> >> Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address. >> >> The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged. >> >> Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code. >> >> Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry ?) and PowerPC (@TheRealMDoerr ?) platforms could review and test the changes for those platforms, as I have limited access to running tests on them. > > Cesar Soares Lucas has updated the pull request incrementally with two additional commits since the last revision: > > - Revert changes to shared cardTable.hpp > - Revert changes to shared cardTable.hpp Much cleaner, thanks! I'll take another look later, but meanwhile, some comments: src/hotspot/cpu/arm/gc/shared/cardTableBarrierSetAssembler_arm.cpp line 100: > 98: assert(bs->kind() == BarrierSet::CardTableBarrierSet, > 99: "Wrong barrier set kind"); > 100: Unnecessary deletion of blank line? src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp line 655: > 653: > 654: #ifndef _LP64 > 655: __ pop(tmp1); Sounds like `tmp1` is undefined here. Should be `tmp`? src/hotspot/os_cpu/linux_arm/javaThread_linux_arm.cpp line 46: > 44: if (UseShenandoahGC) { > 45: _card_table_base = nullptr; > 46: return ; Suggestion: return; src/hotspot/os_cpu/linux_arm/javaThread_linux_arm.cpp line 50: > 48: _card_table_base = nullptr; > 49: } > 50: Unnecessary removals of blank lines? src/hotspot/share/ci/ciUtilities.cpp line 49: > 47: CardTableBarrierSet* ctbs = barrier_set_cast(bs); > 48: CardTable* ct = ctbs->card_table(); > 49: SHENANDOAHGC_ONLY(assert(!UseShenandoahGC, "Shenandoah byte_map_base is not constant.");) Here is a bit of a trick about the `Use${X}GC` flags: you don't need to guard them with `${X}GC_ONLY` macros. They are specifically designed that way: they reside in `gc_globals.hpp` without any feature flags. src/hotspot/share/gc/shenandoah/shenandoahCardTable.cpp line 25: > 23: */ > 24: > 25: #include "gc/shenandoah/shenandoahThreadLocalData.hpp" Includes should be sorted alphabetically. src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 268: > 266: > 267: void ShenandoahGeneration::prepare_gc() { > 268: Unnecessary removal. src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 258: > 256: if (ShenandoahCardBarrier) { > 257: ShenandoahThreadLocalData::set_card_table(Thread::current(), bs->card_table()->write_byte_map_base()); > 258: } Er. This sets up card table for VMThread, right? I am surprised we do not need this for other fields in `ShenandoahThreadLocalData`. src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line 407: > 405: ShenandoahCardCluster(ShenandoahDirectCardMarkRememberedSet* rs) { > 406: _rs = rs; > 407: _object_starts = NEW_C_HEAP_ARRAY(crossing_info, rs->total_cards()+1, mtGC); What is this `+1`? This is #23882, right? ------------- PR Review: https://git.openjdk.org/jdk/pull/23170#pullrequestreview-2656931853 PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1980148491 PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1979192037 PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1980147454 PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1980121669 PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1980118417 PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1980116049 PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1979940218 PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1979944657 PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1979158102 From cslucas at openjdk.org Tue Mar 4 21:08:08 2025 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Tue, 4 Mar 2025 21:08:08 GMT Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card tables [v5] In-Reply-To: <2ZFtKLn2EcbzjKQ_USb3yiOWEWQJYocFwj_rk-5h0Jg=.f4eec566-3e0c-4a75-8c27-2cb785b0081a@github.com> References:

<2ZFtKLn2EcbzjKQ_USb3yiOWEWQJYocFwj_rk-5h0Jg=.f4eec566-3e0c-4a75-8c27-2cb785b0081a@github.com> Message-ID: On Tue, 4 Mar 2025 10:50:30 GMT, Aleksey Shipilev wrote: >> Cesar Soares Lucas has updated the pull request incrementally with two additional commits since the last revision: >> >> - Revert changes to shared cardTable.hpp >> - Revert changes to shared cardTable.hpp > > src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line 407: > >> 405: ShenandoahCardCluster(ShenandoahDirectCardMarkRememberedSet* rs) { >> 406: _rs = rs; >> 407: _object_starts = NEW_C_HEAP_ARRAY(crossing_info, rs->total_cards()+1, mtGC); > > What is this `+1`? This is #23882, right? Yes, correct. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1980229122 From xpeng at openjdk.org Tue Mar 4 21:26:03 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 4 Mar 2025 21:26:03 GMT Subject: RFR: 8351091: Shenandoah: global marking context completeness is not accurately maintained Message-ID: With the JEP 404: Generational Shenandoah implementation, there are generation specific marking completeness flags introduced, and the global marking context completeness flag is not updated at all after initialization, hence the global marking context completeness is not accurate anymore. This may cause expected behavior: [ShenandoahHeap::complete_marking_context()](https://github.com/openjdk/jdk/pull/23886/files#diff-d5ddf298c36b1c91bf33f9bff7bedcc063074edd68c298817f1fdf39d2ed970fL642) should throw assert error if the global marking context completeness flag is false, but now it always return the marking context even it marking is not complete, this may hide bugs where we expect the global/generational marking to be completed. This change PR fix the bug in global marking context completeness flag, and update all the places using `ShenandoahHeap::complete_marking_context()` to use proper API. ### Test - [x] hotspot_gc_shenandoah - [x] Tier 1 - [ ] Tier 2 ------------- Commit messages: - Revert unnecessary changes in ShenandoahReferenceProcessor - Revert the change in ShenandoahHeap::generation_for - touch up - If GC generation is young and referent is in old, make should_drop return false if old gen marking is not complete - Remove ShenandoahHeap::complete_marking_context() - Fix improper use of heap->complete_marking_context() - promotion in place and reference processor should be aware of heap generation when use complete marking context - JDK-8351091: initial works Changes: https://git.openjdk.org/jdk/pull/23886/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23886&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351091 Stats: 61 lines in 17 files changed: 9 ins; 23 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/23886.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23886/head:pull/23886 PR: https://git.openjdk.org/jdk/pull/23886 From wkemper at openjdk.org Tue Mar 4 21:26:04 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 4 Mar 2025 21:26:04 GMT Subject: RFR: 8351091: Shenandoah: global marking context completeness is not accurately maintained In-Reply-To: References: Message-ID: On Tue, 4 Mar 2025 08:34:16 GMT, Xiaolong Peng wrote: > With the JEP 404: Generational Shenandoah implementation, there are generation specific marking completeness flags introduced, and the global marking context completeness flag is not updated at all after initialization, hence the global marking context completeness is not accurate anymore. This may cause expected behavior: [ShenandoahHeap::complete_marking_context()](https://github.com/openjdk/jdk/pull/23886/files#diff-d5ddf298c36b1c91bf33f9bff7bedcc063074edd68c298817f1fdf39d2ed970fL642) should throw assert error if the global marking context completeness flag is false, but now it always return the marking context even it marking is not complete, this may hide bugs where we expect the global/generational marking to be completed. > > This change PR fix the bug in global marking context completeness flag, and update all the places using `ShenandoahHeap::complete_marking_context()` to use proper API. > > ### Test > - [x] hotspot_gc_shenandoah > - [x] Tier 1 > - [ ] Tier 2 Changes requested by wkemper (Reviewer). src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2837: > 2835: } else if (affiliation == OLD_GENERATION) { > 2836: return old_generation(); > 2837: } else if (affiliation == FREE) { I don't think it makes sense to connect `FREE` regions to the global generation in this way. Free regions are _not_ affiliated with any generation. I think in some of these cases where you want to find the mark context, it would be possible to take it from a `_generation` member variable. src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp line 337: > 335: // If generation is young and referent is in old, marking context of the old > 336: // may or may not be complete, we can safely drop the reference when old gen mark is complete. > 337: if (_generation->is_young() && referent_region->is_old()) { Have you seen this happen? The reference processor for each generation is only supposed to discover references for which the referent is in the collected generation. See `ShenandoahReferenceProcessor::should_discover`: if (!heap->is_in_active_generation(referent)) { log_trace(gc,ref)("Referent outside of active generation: " PTR_FORMAT, p2i(referent)); return false; } ------------- PR Review: https://git.openjdk.org/jdk/pull/23886#pullrequestreview-2658463721 PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r1979938123 PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r1979932540 From xpeng at openjdk.org Tue Mar 4 21:26:04 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 4 Mar 2025 21:26:04 GMT Subject: RFR: 8351091: Shenandoah: global marking context completeness is not accurately maintained In-Reply-To: References:

Message-ID: <5EhmY89ZN6u3AyeugsAf1wAVw7AxHU5HD0pfEmPZXZE=.a69c2802-cae9-479d-ab51-47cc69f85c4d@github.com> On Tue, 4 Mar 2025 17:48:58 GMT, William Kemper wrote: >> With the JEP 404: Generational Shenandoah implementation, there are generation specific marking completeness flags introduced, and the global marking context completeness flag is not updated at all after initialization, hence the global marking context completeness is not accurate anymore. This may cause expected behavior: [ShenandoahHeap::complete_marking_context()](https://github.com/openjdk/jdk/pull/23886/files#diff-d5ddf298c36b1c91bf33f9bff7bedcc063074edd68c298817f1fdf39d2ed970fL642) should throw assert error if the global marking context completeness flag is false, but now it always return the marking context even it marking is not complete, this may hide bugs where we expect the global/generational marking to be completed. >> >> This change PR fix the bug in global marking context completeness flag, and update all the places using `ShenandoahHeap::complete_marking_context()` to use proper API. >> >> ### Test >> - [x] hotspot_gc_shenandoah >> - [x] Tier 1 >> - [ ] Tier 2 > > src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2837: > >> 2835: } else if (affiliation == OLD_GENERATION) { >> 2836: return old_generation(); >> 2837: } else if (affiliation == FREE) { > > I don't think it makes sense to connect `FREE` regions to the global generation in this way. Free regions are _not_ affiliated with any generation. I think in some of these cases where you want to find the mark context, it would be possible to take it from a `_generation` member variable. Yeah, I don't think it is necessary to change the behavior here either, I'll remove it in later update. > src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp line 337: > >> 335: // If generation is young and referent is in old, marking context of the old >> 336: // may or may not be complete, we can safely drop the reference when old gen mark is complete. >> 337: if (_generation->is_young() && referent_region->is_old()) { > > Have you seen this happen? The reference processor for each generation is only supposed to discover references for which the referent is in the collected generation. See `ShenandoahReferenceProcessor::should_discover`: > > if (!heap->is_in_active_generation(referent)) { > log_trace(gc,ref)("Referent outside of active generation: " PTR_FORMAT, p2i(referent)); > return false; > } Ok, I didn't see happen in any of the jtreg tests yet. Just base on the the behavior we saw in old gc, I assumed this could happen. Now I am more curious about the real cause of the crash caused by reference from old to young, since we always check if the referent is in the active generation, that shouldn't have happened if it works as described, my feeling is there might be something fishy in the place where we use `_active_generation`(the comments it should be update only in the STW phases), maybe should we should get rid of it, currently we directly use _gc_generation in many places as well, not sure it if is possible to cause inconsistency. I'll revert this part, I'll follow up on the questions in separate work. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r1979976173 PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r1980145388 From xpeng at openjdk.org Tue Mar 4 21:26:04 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 4 Mar 2025 21:26:04 GMT Subject: RFR: 8351091: Shenandoah: global marking context completeness is not accurately maintained In-Reply-To: <5EhmY89ZN6u3AyeugsAf1wAVw7AxHU5HD0pfEmPZXZE=.a69c2802-cae9-479d-ab51-47cc69f85c4d@github.com> References:

<5EhmY89ZN6u3AyeugsAf1wAVw7AxHU5HD0pfEmPZXZE=.a69c2802-cae9-479d-ab51-47cc69f85c4d@github.com> Message-ID: <4_6n2QkucG-4itVGY9thZovsVDHqZFD_FbgFdBo5Fyg=.03fa388d-d65f-4ab2-b891-109de430fd2c@github.com> On Tue, 4 Mar 2025 18:14:58 GMT, Xiaolong Peng wrote: >> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2837: >> >>> 2835: } else if (affiliation == OLD_GENERATION) { >>> 2836: return old_generation(); >>> 2837: } else if (affiliation == FREE) { >> >> I don't think it makes sense to connect `FREE` regions to the global generation in this way. Free regions are _not_ affiliated with any generation. I think in some of these cases where you want to find the mark context, it would be possible to take it from a `_generation` member variable. > > Yeah, I don't think it is necessary to change the behavior here either, I'll remove it in later update. I have removed the change. >> src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp line 337: >> >>> 335: // If generation is young and referent is in old, marking context of the old >>> 336: // may or may not be complete, we can safely drop the reference when old gen mark is complete. >>> 337: if (_generation->is_young() && referent_region->is_old()) { >> >> Have you seen this happen? The reference processor for each generation is only supposed to discover references for which the referent is in the collected generation. See `ShenandoahReferenceProcessor::should_discover`: >> >> if (!heap->is_in_active_generation(referent)) { >> log_trace(gc,ref)("Referent outside of active generation: " PTR_FORMAT, p2i(referent)); >> return false; >> } > > Ok, I didn't see happen in any of the jtreg tests yet. > > Just base on the the behavior we saw in old gc, I assumed this could happen. Now I am more curious about the real cause of the crash caused by reference from old to young, since we always check if the referent is in the active generation, that shouldn't have happened if it works as described, my feeling is there might be something fishy in the place where we use `_active_generation`(the comments it should be update only in the STW phases), maybe should we should get rid of it, currently we directly use _gc_generation in many places as well, not sure it if is possible to cause inconsistency. > > I'll revert this part, I'll follow up on the questions in separate work. Reverted, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r1980219344 PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r1980239633 From cslucas at openjdk.org Tue Mar 4 21:47:57 2025 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Tue, 4 Mar 2025 21:47:57 GMT Subject: Integrated: 8351081: Off-by-one error in ShenandoahCardCluster In-Reply-To: References: Message-ID: On Tue, 4 Mar 2025 04:06:00 GMT, Cesar Soares Lucas wrote: > Given certain values for the variables in [this expression](https://github.com/openjdk/jdk/blob/a87dd1a75f78cf872df49bea83ba48af8acfa2fd/src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp#L173) the result of the computation can be equal to `_ rs->total_cards()` which will lead to segmentation fault, for instance in [starts_object(card_at_end)](https://github.com/openjdk/jdk/blob/a87dd1a75f78cf872df49bea83ba48af8acfa2fd/src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp#L393). The problem happens, though, because the `_object_starts` array doesn't have a [guarding entry](https://github.com/openjdk/jdk/blob/a87dd1a75f78cf872df49bea83ba48af8acfa2fd/src/hotspot/share/gc/shenandoah/shenandoahCardTable.cpp#L37) at the end. This pull request adjusts the allocation of `_object_starts` to include an additional entry at the end to account for this situation. > > Tested with JTREG tier 1-4, x86_64 & AArch64 on Linux. This pull request has now been integrated. Changeset: 38b4d46c Author: Cesar Soares Lucas Committer: William Kemper URL: https://git.openjdk.org/jdk/commit/38b4d46c1ff3701d75ff8347e5edbb01acd9b512 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8351081: Off-by-one error in ShenandoahCardCluster Reviewed-by: wkemper ------------- PR: https://git.openjdk.org/jdk/pull/23882 From andrew at openjdk.org Tue Mar 4 22:38:25 2025 From: andrew at openjdk.org (Andrew John Hughes) Date: Tue, 4 Mar 2025 22:38:25 GMT Subject: RFR: Merge jdk8u:master Message-ID: <4cF-jYBLChdNhTp1jOQC3_ssjO14CZ13bGr1oQHDW5o=.85737113-070b-4691-9e16-c4ff6b33ab2f@github.com> Merge jdk8u332-b08 ------------- Commit messages: - Merge jdk8u332-b08 - 8284920: Incorrect Token type causes XPath expression to return empty result - Added tag jdk8u332-b07 for changeset 6d526dbc3432 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/shenandoah-jdk8u/pull/13/files Stats: 10 lines in 4 files changed: 2 ins; 1 del; 7 mod Patch: https://git.openjdk.org/shenandoah-jdk8u/pull/13.diff Fetch: git fetch https://git.openjdk.org/shenandoah-jdk8u.git pull/13/head:pull/13 PR: https://git.openjdk.org/shenandoah-jdk8u/pull/13 From andrew at openjdk.org Tue Mar 4 22:40:56 2025 From: andrew at openjdk.org (Andrew John Hughes) Date: Tue, 4 Mar 2025 22:40:56 GMT Subject: git: openjdk/shenandoah-jdk8u: master: 3 new changesets Message-ID: <8b817646-49f9-43aa-a4d3-8e45bdd1024d@openjdk.org> Changeset: f1a7de17 Branch: master Author: Andrew John Hughes Date: 2022-04-15 04:34:35 +0000 URL: https://git.openjdk.org/shenandoah-jdk8u/commit/f1a7de17268b2278ccd9ed7f757718d21ca085d8 Added tag jdk8u332-b07 for changeset 6d526dbc3432 ! .hgtags Changeset: d0b89297 Branch: master Author: Anton Kozlov Date: 2022-04-16 04:22:57 +0000 URL: https://git.openjdk.org/shenandoah-jdk8u/commit/d0b8929739120d9f8850a1dffbb5d891acdcd70e 8284920: Incorrect Token type causes XPath expression to return empty result Reviewed-by: andrew ! jaxp/src/com/sun/org/apache/xpath/internal/compiler/Lexer.java ! jaxp/src/com/sun/org/apache/xpath/internal/compiler/Token.java ! jaxp/src/com/sun/org/apache/xpath/internal/compiler/XPathParser.java Changeset: 9bdf1b61 Branch: master Author: Andrew John Hughes Date: 2025-02-19 15:53:41 +0000 URL: https://git.openjdk.org/shenandoah-jdk8u/commit/9bdf1b614403327870d04fa23dbba16d4aa68063 Merge jdk8u332-b08 From andrew at openjdk.org Tue Mar 4 22:41:14 2025 From: andrew at openjdk.org (Andrew John Hughes) Date: Tue, 4 Mar 2025 22:41:14 GMT Subject: git: openjdk/shenandoah-jdk8u: Added tag jdk8u332-b08 for changeset d0b89297 Message-ID: <43f36c20-1cf1-48dd-a684-34f48cfecf51@openjdk.org> Tagged by: Andrew John Hughes Date: 2022-04-16 04:24:00 +0000 Changeset: d0b89297 Author: Anton Kozlov Date: 2022-04-16 04:22:57 +0000 URL: https://git.openjdk.org/shenandoah-jdk8u/commit/d0b8929739120d9f8850a1dffbb5d891acdcd70e From andrew at openjdk.org Tue Mar 4 22:41:17 2025 From: andrew at openjdk.org (Andrew John Hughes) Date: Tue, 4 Mar 2025 22:41:17 GMT Subject: git: openjdk/shenandoah-jdk8u: Added tag shenandoah8u332-b08 for changeset 9bdf1b61 Message-ID: <594f4f66-c132-445d-bd7b-2fb601e0ccae@openjdk.org> Tagged by: Andrew John Hughes Date: 2025-02-19 19:35:24 +0000 Added tag shenandoah8u332-b08 for changeset 9bdf1b61440 Changeset: 9bdf1b61 Author: Andrew John Hughes Date: 2025-02-19 15:53:41 +0000 URL: https://git.openjdk.org/shenandoah-jdk8u/commit/9bdf1b614403327870d04fa23dbba16d4aa68063 From iris at openjdk.org Tue Mar 4 22:42:52 2025 From: iris at openjdk.org (Iris Clark) Date: Tue, 4 Mar 2025 22:42:52 GMT Subject: Withdrawn: Merge jdk8u:master In-Reply-To: <4cF-jYBLChdNhTp1jOQC3_ssjO14CZ13bGr1oQHDW5o=.85737113-070b-4691-9e16-c4ff6b33ab2f@github.com> References: <4cF-jYBLChdNhTp1jOQC3_ssjO14CZ13bGr1oQHDW5o=.85737113-070b-4691-9e16-c4ff6b33ab2f@github.com> Message-ID: On Tue, 4 Mar 2025 22:34:19 GMT, Andrew John Hughes wrote: > Merge jdk8u332-b08 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/shenandoah-jdk8u/pull/13 From andrew at openjdk.org Tue Mar 4 22:42:52 2025 From: andrew at openjdk.org (Andrew John Hughes) Date: Tue, 4 Mar 2025 22:42:52 GMT Subject: RFR: Merge jdk8u:master [v2] In-Reply-To: <4cF-jYBLChdNhTp1jOQC3_ssjO14CZ13bGr1oQHDW5o=.85737113-070b-4691-9e16-c4ff6b33ab2f@github.com> References: <4cF-jYBLChdNhTp1jOQC3_ssjO14CZ13bGr1oQHDW5o=.85737113-070b-4691-9e16-c4ff6b33ab2f@github.com> Message-ID: <1NSi8jQ8G7Uxk_pVhGSZXYdGexBJxoET1J6TJqpG3bk=.be5e0266-946a-46f9-9d25-6c5044133d44@github.com> > Merge jdk8u332-b08 Andrew John Hughes 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. ------------- Changes: - all: https://git.openjdk.org/shenandoah-jdk8u/pull/13/files - new: https://git.openjdk.org/shenandoah-jdk8u/pull/13/files/9bdf1b61..9bdf1b61 Webrevs: - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk8u&pr=13&range=01 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk8u&pr=13&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/shenandoah-jdk8u/pull/13.diff Fetch: git fetch https://git.openjdk.org/shenandoah-jdk8u.git pull/13/head:pull/13 PR: https://git.openjdk.org/shenandoah-jdk8u/pull/13 From cslucas at openjdk.org Wed Mar 5 00:57:54 2025 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Wed, 5 Mar 2025 00:57:54 GMT Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card tables [v5] In-Reply-To: <2ZFtKLn2EcbzjKQ_USb3yiOWEWQJYocFwj_rk-5h0Jg=.f4eec566-3e0c-4a75-8c27-2cb785b0081a@github.com> References:

<2ZFtKLn2EcbzjKQ_USb3yiOWEWQJYocFwj_rk-5h0Jg=.f4eec566-3e0c-4a75-8c27-2cb785b0081a@github.com> Message-ID: On Tue, 4 Mar 2025 17:53:57 GMT, Aleksey Shipilev wrote: >> Cesar Soares Lucas has updated the pull request incrementally with two additional commits since the last revision: >> >> - Revert changes to shared cardTable.hpp >> - Revert changes to shared cardTable.hpp > > src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 258: > >> 256: if (ShenandoahCardBarrier) { >> 257: ShenandoahThreadLocalData::set_card_table(Thread::current(), bs->card_table()->write_byte_map_base()); >> 258: } > > Er. This sets up card table for VMThread, right? I am surprised we do not need this for other fields in `ShenandoahThreadLocalData`. Yes, that's for the VMThread. That seems like a good question. I ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1980492593 From cslucas at openjdk.org Wed Mar 5 01:10:50 2025 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Wed, 5 Mar 2025 01:10:50 GMT Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card tables [v6] In-Reply-To: References: Message-ID: > In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. > > The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase. > > The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table. > > Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address. > > The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged. > > Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code. > > Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry ?) and PowerPC (@TheRealMDoerr ?) platforms could review and test the changes for those platforms, as I have limited access to running tests on them. Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: Address PR feedback: formatting. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23170/files - new: https://git.openjdk.org/jdk/pull/23170/files/717b8b44..cbf5aab0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23170&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23170&range=04-05 Stats: 8 lines in 6 files changed: 4 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23170.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23170/head:pull/23170 PR: https://git.openjdk.org/jdk/pull/23170 From cslucas at openjdk.org Wed Mar 5 01:14:44 2025 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Wed, 5 Mar 2025 01:14:44 GMT Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card tables [v7] In-Reply-To: References: Message-ID: > In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. > > The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase. > > The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table. > > Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address. > > The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged. > > Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code. > > Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry ?) and PowerPC (@TheRealMDoerr ?) platforms could review and test the changes for those platforms, as I have limited access to running tests on them. Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: - Fix merge conflict - Address PR feedback: formatting. - Revert changes to shared cardTable.hpp - Revert changes to shared cardTable.hpp - Fix merge conflict - Address PR feedback: no changes to shared files. - Merge master - Addressing PR comments: some refactorings, ppc fix, off-by-one fix. - Relocation of Card Tables ------------- Changes: https://git.openjdk.org/jdk/pull/23170/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23170&range=06 Stats: 295 lines in 28 files changed: 150 ins; 92 del; 53 mod Patch: https://git.openjdk.org/jdk/pull/23170.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23170/head:pull/23170 PR: https://git.openjdk.org/jdk/pull/23170 From gziemski at openjdk.org Wed Mar 5 15:32:03 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Wed, 5 Mar 2025 15:32:03 GMT Subject: RFR: 8350566: NMT: add size parameter to MemTracker::record_virtual_memory_tag In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 09:49:41 GMT, Afshin Zafari wrote: > With the `size` parameter there will be no need to traverse/go through the nodes between the base and end of the region. > Tests: > linux-x64-debug, gtest:NMT* and runtime/NMT* Changes requested by gziemski (Reviewer). Changes requested by gziemski (Reviewer). src/hotspot/share/cds/metaspaceShared.cpp line 1475: > 1473: (address)archive_space_rs.base() == base_address, "Sanity"); > 1474: // Register archive space with NMT. > 1475: MemTracker::record_virtual_memory_tag(archive_space_rs.base(), archive_space_rs.size(), mtClassShared); The pattern here is: `something.base(), something.base.size()` instead of doing this over and over again, why can't we just pass `something` to MemTracker::record_virtual_memory_tag() and let it figure out `base` and `size` itself? src/hotspot/share/cds/metaspaceShared.cpp line 1548: > 1546: return nullptr; > 1547: } > 1548: // NMT: fix up the space tags What exactly needs to be fixed here? ------------- PR Review: https://git.openjdk.org/jdk/pull/23770#pullrequestreview-2661498707 PR Review: https://git.openjdk.org/jdk/pull/23770#pullrequestreview-2661515550 PR Review Comment: https://git.openjdk.org/jdk/pull/23770#discussion_r1981647511 PR Review Comment: https://git.openjdk.org/jdk/pull/23770#discussion_r1981635746 From shade at openjdk.org Wed Mar 5 16:55:25 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 5 Mar 2025 16:55:25 GMT Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port Message-ID: This PR implements JEP 503: Remove the 32-bit x86 Port. The JEP is proposed to target 25, we would not integrate until JEP is ready. Reviews are appreciated meanwhile. This is only the removal of obvious 32-bit x86 parts, mostly files with `x86_32` in their name. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. The approach for removing x86_32 files only also makes this PR borderline trivial, and requires no additional testing beyond normal pre-integration checks. The rest of the code is quite heavily intertwined with x86_64 and/or Zero, and would require accurate untangling. It would be much easier to review and test once we purge the free-standing parts of 32-bit x86 port, which is also a bulk of the port. The tangling with 32-bit x86 Zero is also why I did not touch most of the build system paths that handle x86. There is [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella that tracks further cleanup work. One can peek the final state that can be reached with all the cleanups in my earlier exploratory https://github.com/openjdk/jdk/pull/22567. Additional testing: - [x] Linux x86_32 Server fastdebug, `make bootcycle-images` (now fails configure) - [x] Linux x86_64 Server fastdebug, `make bootcycle-images` (still works) - [x] Linux x86_32 Zero fastdebug, `make bootcycle-images` (still works) - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works) ------------- Commit messages: - Generic 32-bit x86 configure error supercedes Windows 32-bit x86 - 8345169: Implement JEP 503: Remove the 32-bit x86 Port Changes: https://git.openjdk.org/jdk/pull/23906/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23906&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345169 Stats: 30068 lines in 26 files changed: 4 ins; 30054 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/23906.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23906/head:pull/23906 PR: https://git.openjdk.org/jdk/pull/23906 From vlivanov at openjdk.org Wed Mar 5 17:19:13 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 5 Mar 2025 17:19:13 GMT Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port In-Reply-To: References: Message-ID: On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev wrote: > This PR implements JEP 503: Remove the 32-bit x86 Port. > > The JEP is proposed to target 25, we would not integrate until JEP is ready. Reviews are appreciated meanwhile. > > This is only the removal of obvious 32-bit x86 parts, mostly files with `x86_32` in their name. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. The approach for removing x86_32 files only also makes this PR borderline trivial, and requires no additional testing beyond normal pre-integration checks. > > The rest of the code is quite heavily intertwined with x86_64 and/or Zero, and would require accurate untangling. It would be much easier to review and test once we purge the free-standing parts of 32-bit x86 port, which is also a bulk of the port. The tangling with 32-bit x86 Zero is also why I did not touch most of the build system paths that handle x86. There is [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella that tracks further cleanup work. One can peek the final state that can be reached with all the cleanups in my earlier exploratory https://github.com/openjdk/jdk/pull/22567. > > Additional testing: > - [x] Linux x86_32 Server fastdebug, `make bootcycle-images` (now fails configure) > - [x] Linux x86_64 Server fastdebug, `make bootcycle-images` (still works) > - [x] Linux x86_32 Zero fastdebug, `make bootcycle-images` (still works) > - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works) Hotspot changes look good to me. I fully support removing x86-32-specific files first and then clean up x86-32-specific code in x86-specific and shared files (e.g., guarded by `#ifndef _LP64`). ------------- Marked as reviewed by vlivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23906#pullrequestreview-2661836831 From shade at openjdk.org Wed Mar 5 17:48:09 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 5 Mar 2025 17:48:09 GMT Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card tables [v5] In-Reply-To: References:

<2ZFtKLn2EcbzjKQ_USb3yiOWEWQJYocFwj_rk-5h0Jg=.f4eec566-3e0c-4a75-8c27-2cb785b0081a@github.com> Message-ID: On Wed, 5 Mar 2025 00:55:13 GMT, Cesar Soares Lucas wrote: >> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 258: >> >>> 256: if (ShenandoahCardBarrier) { >>> 257: ShenandoahThreadLocalData::set_card_table(Thread::current(), bs->card_table()->write_byte_map_base()); >>> 258: } >> >> Er. This sets up card table for VMThread, right? I am surprised we do not need this for other fields in `ShenandoahThreadLocalData`. > > Yes, that's for the VMThread. That seems like a good question. I Actually, I am wondering why this is needed. It looks to me VMThread attaches after heap initialization, and the normal `ShenandoahBarrierSet::on_thread_attach` should handle it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1981887605 From shade at openjdk.org Wed Mar 5 17:48:08 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 5 Mar 2025 17:48:08 GMT Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card tables [v7] In-Reply-To: References:

Message-ID: <_LIv8Ggp3ukK0HmhknyG_Mz2x5OKs63Y-qSXTQo9Gdo=.9efc86f1-6cc4-425b-9319-5e1500eb59da@github.com> On Wed, 5 Mar 2025 01:14:44 GMT, Cesar Soares Lucas wrote: >> In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. >> >> The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase. >> >> The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table. >> >> Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address. >> >> The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged. >> >> Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code. >> >> Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry ?) and PowerPC (@TheRealMDoerr ?) platforms could review and test the changes for those platforms, as I have limited access to running tests on them. > > Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: > > - Fix merge conflict > - Address PR feedback: formatting. > - Revert changes to shared cardTable.hpp > - Revert changes to shared cardTable.hpp > - Fix merge conflict > - Address PR feedback: no changes to shared files. > - Merge master > - Addressing PR comments: some refactorings, ppc fix, off-by-one fix. > - Relocation of Card Tables src/hotspot/os_cpu/linux_arm/javaThread_linux_arm.cpp line 43: > 41: > 42: void JavaThread::cache_global_variables() { > 43: #if INCLUDE_SHENANDOAHGC Sounds like we want to be consistent between C1 and C2 code, so maybe we should inject in adjacent block as: if (bs->is_a(BarrierSet::CardTableBarrierSet) && !bs->is_a(BarrierSet::ShenandoahBarrierSet)) { ... src/hotspot/share/gc/shenandoah/shenandoahCardTable.cpp line 57: > 55: _byte_map_base = _byte_map - (uintptr_t(low_bound) >> _card_shift); > 56: assert(byte_for(low_bound) == &_byte_map[0], "Checking start of map"); > 57: assert(byte_for(high_bound-1) <= &_byte_map[last_valid_index()], "Checking end of map"); It is a bit sad to see these asserts go. Is this because `_byte_map` is now mutable? May I suggest doing something like: _write_byte_map = (CardValue*) write_space.base(); _write_byte_map_base = _byte_map - (uintptr_t(low_bound) >> _card_shift); ...later... _read_byte_map = (CardValue*) read_space.base(); _read_byte_map_base = _byte_map - (uintptr_t(low_bound) >> _card_shift); ...later... // Set up current byte map _byte_map = _write_byte_map; _byte_map_base = _write_byte_map_base; // Check one side is good assert(byte_for(low_bound) == &_byte_map[0], "Checking start of map"); assert(byte_for(high_bound-1) <= &_byte_map[last_valid_index()], "Checking end of map"); swap_read_and_write_tables(); // Check another side is good assert(byte_for(low_bound) == &_byte_map[0], "Checking start of map"); assert(byte_for(high_bound-1) <= &_byte_map[last_valid_index()], "Checking end of map"); swap_read_and_write_tables(); src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 638: > 636: CardTable::CardValue* new_ptr; > 637: SwapTLSCardTable(CardTable::CardValue* np) { > 638: this->new_ptr = np; Suggestion: CardTable::CardValue* const _new_ptr; SwapTLSCardTable(CardTable::CardValue* np) : _new_ptr(np) {} ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1981872217 PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1981869962 PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1981835070 From ysr at openjdk.org Wed Mar 5 18:02:57 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Wed, 5 Mar 2025 18:02:57 GMT Subject: RFR: 8351091: Shenandoah: global marking context completeness is not accurately maintained In-Reply-To: References:

Message-ID: On Tue, 4 Mar 2025 23:29:18 GMT, Y. Srinivas Ramakrishna wrote: >> With the JEP 404: Generational Shenandoah implementation, there are generation specific marking completeness flags introduced, and the global marking context completeness flag is not updated at all after initialization, hence the global marking context completeness is not accurate anymore. This may cause expected behavior: [ShenandoahHeap::complete_marking_context()](https://github.com/openjdk/jdk/pull/23886/files#diff-d5ddf298c36b1c91bf33f9bff7bedcc063074edd68c298817f1fdf39d2ed970fL642) should throw assert error if the global marking context completeness flag is false, but now it always return the marking context even it marking is not complete, this may hide bugs where we expect the global/generational marking to be completed. >> >> This change PR fix the bug in global marking context completeness flag, and update all the places using `ShenandoahHeap::complete_marking_context()` to use proper API. >> >> ### Test >> - [x] hotspot_gc_shenandoah >> - [x] Tier 1 >> - [x] Tier 2 > > src/hotspot/share/gc/shenandoah/shenandoahGeneration.hpp line 206: > >> 204: bool is_mark_complete() { return _is_marking_complete.is_set(); } >> 205: virtual void set_mark_complete(); >> 206: virtual void set_mark_incomplete(); > > Why are these declared virtual? OK, I see that `ShenandoahGlobalGeneration` forces the state of `ShenandoahOdGeneration` and `ShenandoahYoungGeneration`, but is that our intention? I am seeing (see comment elsewhere) that we are always either using global generation's marking context explicitly, or using a region to index into the appropriate containing generation's marking context. If so, can we dispense with the forcing of global context's state into the contexts for the two generations? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r1980429065 From ysr at openjdk.org Wed Mar 5 18:02:56 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Wed, 5 Mar 2025 18:02:56 GMT Subject: RFR: 8351091: Shenandoah: global marking context completeness is not accurately maintained In-Reply-To: References: Message-ID: On Tue, 4 Mar 2025 08:34:16 GMT, Xiaolong Peng wrote: > With the JEP 404: Generational Shenandoah implementation, there are generation specific marking completeness flags introduced, and the global marking context completeness flag is not updated at all after initialization, hence the global marking context completeness is not accurate anymore. This may cause expected behavior: [ShenandoahHeap::complete_marking_context()](https://github.com/openjdk/jdk/pull/23886/files#diff-d5ddf298c36b1c91bf33f9bff7bedcc063074edd68c298817f1fdf39d2ed970fL642) should throw assert error if the global marking context completeness flag is false, but now it always return the marking context even it marking is not complete, this may hide bugs where we expect the global/generational marking to be completed. > > This change PR fix the bug in global marking context completeness flag, and update all the places using `ShenandoahHeap::complete_marking_context()` to use proper API. > > ### Test > - [x] hotspot_gc_shenandoah > - [x] Tier 1 > - [x] Tier 2 Had a few questions and comments inline. I'll take a closer look once you have responded to those. Thank you for finding this probably long-standing incorrectness/fuzziness and fixing it properly! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1028: > 1026: > 1027: #ifdef ASSERT > 1028: ShenandoahMarkingContext* const ctx = _heap->marking_context(); Why not this instead? ShenandoahMarkingContext* const ctx = _heap->marking_context(r); src/hotspot/share/gc/shenandoah/shenandoahGeneration.hpp line 206: > 204: bool is_mark_complete() { return _is_marking_complete.is_set(); } > 205: virtual void set_mark_complete(); > 206: virtual void set_mark_incomplete(); Why are these declared virtual? src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 737: > 735: public: > 736: inline ShenandoahMarkingContext* complete_marking_context(ShenandoahHeapRegion* region) const; > 737: inline ShenandoahMarkingContext* marking_context() const; Should document semantics of both methods, please! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 868: > 866: #ifdef ASSERT > 867: { > 868: // During full gc, heap->complete_marking_context() is not valid, may equal nullptr. Looks like this comment is obsolete? src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.cpp line 103: > 101: > 102: bool ShenandoahMarkingContext::is_complete() { > 103: return ShenandoahHeap::heap()->global_generation()->is_mark_complete(); Do we need this? It seems wrong to me that even though each generation has its own marking context, we ask any marking context to report if that of the Global Generation is complete. I'd explicitly let generations maintain the state of completeness of their marking contexts, and for clients to query the generations for that state rather than having the individual marking contexts respond to that question. Where is this used after your changes? src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.hpp line 88: > 86: bool is_bitmap_range_within_region_clear(const HeapWord* start, const HeapWord* end) const; > 87: > 88: bool is_complete(); Add a 1-line documentation comment for this method. src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp line 337: > 335: // drop the reference. > 336: if (type == REF_PHANTOM) { > 337: return heap->complete_marking_context(referent_region)->is_marked(raw_referent); Doesn't the assert down at line 350 also need `complete_marking_context` ? Same at line 441. May be comb through all of these to determine which we need for proper assertion checking? I'd start by documenting the semantics of the APIs clearly. I am not completely clear on that yet (pun not intended :-) ------------- PR Review: https://git.openjdk.org/jdk/pull/23886#pullrequestreview-2659389355 PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r1980523168 PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r1980420417 PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r1980401312 PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r1980403403 PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r1980437298 PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r1980406186 PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r1981905245 From andrew at openjdk.org Wed Mar 5 18:25:18 2025 From: andrew at openjdk.org (Andrew John Hughes) Date: Wed, 5 Mar 2025 18:25:18 GMT Subject: RFR: Merge jdk8u:master Message-ID: Merge jdk8u332-b09 ------------- Commit messages: - Merge jdk8u332-b09 - 8284936: Fix Java 7 bootstrap breakage due to use of Arrays.stream - Added tag jdk8u332-b08 for changeset 95b31159fdfd The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/shenandoah-jdk8u/pull/14/files Stats: 13 lines in 3 files changed: 11 ins; 0 del; 2 mod Patch: https://git.openjdk.org/shenandoah-jdk8u/pull/14.diff Fetch: git fetch https://git.openjdk.org/shenandoah-jdk8u.git pull/14/head:pull/14 PR: https://git.openjdk.org/shenandoah-jdk8u/pull/14 From cslucas at openjdk.org Wed Mar 5 18:49:05 2025 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Wed, 5 Mar 2025 18:49:05 GMT Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card tables [v7] In-Reply-To: <_LIv8Ggp3ukK0HmhknyG_Mz2x5OKs63Y-qSXTQo9Gdo=.9efc86f1-6cc4-425b-9319-5e1500eb59da@github.com> References:

<_LIv8Ggp3ukK0HmhknyG_Mz2x5OKs63Y-qSXTQo9Gdo=.9efc86f1-6cc4-425b-9319-5e1500eb59da@github.com> Message-ID: On Wed, 5 Mar 2025 17:32:30 GMT, Aleksey Shipilev wrote: >> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: >> >> - Fix merge conflict >> - Address PR feedback: formatting. >> - Revert changes to shared cardTable.hpp >> - Revert changes to shared cardTable.hpp >> - Fix merge conflict >> - Address PR feedback: no changes to shared files. >> - Merge master >> - Addressing PR comments: some refactorings, ppc fix, off-by-one fix. >> - Relocation of Card Tables > > src/hotspot/share/gc/shenandoah/shenandoahCardTable.cpp line 57: > >> 55: _byte_map_base = _byte_map - (uintptr_t(low_bound) >> _card_shift); >> 56: assert(byte_for(low_bound) == &_byte_map[0], "Checking start of map"); >> 57: assert(byte_for(high_bound-1) <= &_byte_map[last_valid_index()], "Checking end of map"); > > It is a bit sad to see these asserts go. Is this because `_byte_map` is now mutable? May I suggest doing something like: > > > _write_byte_map = (CardValue*) write_space.base(); > _write_byte_map_base = _byte_map - (uintptr_t(low_bound) >> _card_shift); > ...later... > _read_byte_map = (CardValue*) read_space.base(); > _read_byte_map_base = _byte_map - (uintptr_t(low_bound) >> _card_shift); > ...later... > > // Set up current byte map > _byte_map = _write_byte_map; > _byte_map_base = _write_byte_map_base; > > // Check one side is good > assert(byte_for(low_bound) == &_byte_map[0], "Checking start of map"); > assert(byte_for(high_bound-1) <= &_byte_map[last_valid_index()], "Checking end of map"); > swap_read_and_write_tables(); > > // Check another side is good > assert(byte_for(low_bound) == &_byte_map[0], "Checking start of map"); > assert(byte_for(high_bound-1) <= &_byte_map[last_valid_index()], "Checking end of map"); > swap_read_and_write_tables(); Yeah, I didn't like that either. If I recall correctly I had to remove them because part of the expressions ended up calling `byte_map(_base)` which would come from `ThreadLocalData` which wasn't set at the time `initialize()` was being called. Now that we don't have the virtual methods anymore I think I can put back the asserts. I'll try+test that and get back to you. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1981983462 From andrew at openjdk.org Wed Mar 5 18:59:30 2025 From: andrew at openjdk.org (Andrew John Hughes) Date: Wed, 5 Mar 2025 18:59:30 GMT Subject: git: openjdk/shenandoah-jdk8u: master: 3 new changesets Message-ID: Changeset: c7a735dd Branch: master Author: Andrew John Hughes Date: 2022-04-16 04:24:00 +0000 URL: https://git.openjdk.org/shenandoah-jdk8u/commit/c7a735ddeb50ed7fb24b5024c5fb11841b0818e0 Added tag jdk8u332-b08 for changeset 95b31159fdfd ! .hgtags Changeset: 3d2fe9bb Branch: master Author: Andrew John Hughes Date: 2022-04-18 01:32:28 +0000 URL: https://git.openjdk.org/shenandoah-jdk8u/commit/3d2fe9bbb4c5f704d08982a3b1c4b424a9dd1d37 8284936: Fix Java 7 bootstrap breakage due to use of Arrays.stream Reviewed-by: mbalao ! jaxp/src/com/sun/java_cup/internal/runtime/lr_parser.java ! jaxp/src/com/sun/org/apache/xpath/internal/compiler/Token.java Changeset: 0f3b1805 Branch: master Author: Andrew John Hughes Date: 2025-03-04 22:41:27 +0000 URL: https://git.openjdk.org/shenandoah-jdk8u/commit/0f3b1805da765b18999dc8b614f29795fb060195 Merge jdk8u332-b09 From andrew at openjdk.org Wed Mar 5 18:59:38 2025 From: andrew at openjdk.org (Andrew John Hughes) Date: Wed, 5 Mar 2025 18:59:38 GMT Subject: git: openjdk/shenandoah-jdk8u: Added tag jdk8u332-b09 for changeset 3d2fe9bb Message-ID: <66942053-dd81-4670-a7b2-7dda936161d9@openjdk.org> Tagged by: Andrew John Hughes Date: 2022-04-18 02:47:59 +0000 Changeset: 3d2fe9bb Author: Andrew John Hughes Date: 2022-04-18 01:32:28 +0000 URL: https://git.openjdk.org/shenandoah-jdk8u/commit/3d2fe9bbb4c5f704d08982a3b1c4b424a9dd1d37 From andrew at openjdk.org Wed Mar 5 18:59:46 2025 From: andrew at openjdk.org (Andrew John Hughes) Date: Wed, 5 Mar 2025 18:59:46 GMT Subject: git: openjdk/shenandoah-jdk8u: Added tag shenandoah8u332-b09 for changeset 0f3b1805 Message-ID: <1f30b32a-2303-4866-a29d-eabc47ced3e4@openjdk.org> Tagged by: Andrew John Hughes Date: 2025-03-05 17:52:40 +0000 Added tag shenandoah8u332-b09 for changeset 0f3b1805da7 Changeset: 0f3b1805 Author: Andrew John Hughes Date: 2025-03-04 22:41:27 +0000 URL: https://git.openjdk.org/shenandoah-jdk8u/commit/0f3b1805da765b18999dc8b614f29795fb060195 From andrew at openjdk.org Wed Mar 5 18:59:48 2025 From: andrew at openjdk.org (Andrew John Hughes) Date: Wed, 5 Mar 2025 18:59:48 GMT Subject: git: openjdk/shenandoah-jdk8u: Added tag jdk8u332-ga for changeset 3d2fe9bb Message-ID: <8cc9c4e5-5f42-4692-98b4-7e6bf86c78e2@openjdk.org> Tagged by: Andrew John Hughes Date: 2022-04-22 16:45:54 +0000 Changeset: 3d2fe9bb Author: Andrew John Hughes Date: 2022-04-18 01:32:28 +0000 URL: https://git.openjdk.org/shenandoah-jdk8u/commit/3d2fe9bbb4c5f704d08982a3b1c4b424a9dd1d37 From andrew at openjdk.org Wed Mar 5 19:02:15 2025 From: andrew at openjdk.org (Andrew John Hughes) Date: Wed, 5 Mar 2025 19:02:15 GMT Subject: RFR: Merge jdk8u:master [v2] In-Reply-To: References: Message-ID: > Merge jdk8u332-b09 Andrew John Hughes 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. ------------- Changes: - all: https://git.openjdk.org/shenandoah-jdk8u/pull/14/files - new: https://git.openjdk.org/shenandoah-jdk8u/pull/14/files/0f3b1805..0f3b1805 Webrevs: - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk8u&pr=14&range=01 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk8u&pr=14&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/shenandoah-jdk8u/pull/14.diff Fetch: git fetch https://git.openjdk.org/shenandoah-jdk8u.git pull/14/head:pull/14 PR: https://git.openjdk.org/shenandoah-jdk8u/pull/14 From andrew at openjdk.org Wed Mar 5 19:02:15 2025 From: andrew at openjdk.org (Andrew John Hughes) Date: Wed, 5 Mar 2025 19:02:15 GMT Subject: RFR: Merge jdk8u:master In-Reply-To: References: Message-ID: On Wed, 5 Mar 2025 18:20:12 GMT, Andrew John Hughes wrote: > Merge jdk8u332-b09 GHA builds will not work until [JDK-8284622](https://bugs.openjdk.org/browse/JDK-8284622) is merged in 8u362-b03 ------------- PR Comment: https://git.openjdk.org/shenandoah-jdk8u/pull/14#issuecomment-2701812530 From iris at openjdk.org Wed Mar 5 19:02:15 2025 From: iris at openjdk.org (Iris Clark) Date: Wed, 5 Mar 2025 19:02:15 GMT Subject: Withdrawn: Merge jdk8u:master In-Reply-To: References: Message-ID: On Wed, 5 Mar 2025 18:20:12 GMT, Andrew John Hughes wrote: > Merge jdk8u332-b09 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/shenandoah-jdk8u/pull/14 From xpeng at openjdk.org Wed Mar 5 19:11:30 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 5 Mar 2025 19:11:30 GMT Subject: RFR: 8351091: Shenandoah: global marking context completeness is not accurately maintained [v2] In-Reply-To: References: Message-ID: > With the JEP 404: Generational Shenandoah implementation, there are generation specific marking completeness flags introduced, and the global marking context completeness flag is not updated at all after initialization, hence the global marking context completeness is not accurate anymore. This may cause expected behavior: [ShenandoahHeap::complete_marking_context()](https://github.com/openjdk/jdk/pull/23886/files#diff-d5ddf298c36b1c91bf33f9bff7bedcc063074edd68c298817f1fdf39d2ed970fL642) should throw assert error if the global marking context completeness flag is false, but now it always return the marking context even it marking is not complete, this may hide bugs where we expect the global/generational marking to be completed. > > This change PR fix the bug in global marking context completeness flag, and update all the places using `ShenandoahHeap::complete_marking_context()` to use proper API. > > ### Test > - [x] hotspot_gc_shenandoah > - [x] Tier 1 > - [x] Tier 2 Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Always use active_generation()->complete_marking_context() during reference processing ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23886/files - new: https://git.openjdk.org/jdk/pull/23886/files/01c6ea66..465deaec Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23886&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23886&range=00-01 Stats: 6 lines in 1 file changed: 0 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23886.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23886/head:pull/23886 PR: https://git.openjdk.org/jdk/pull/23886 From kvn at openjdk.org Wed Mar 5 20:10:53 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 5 Mar 2025 20:10:53 GMT Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port In-Reply-To: References: Message-ID: On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev wrote: > This PR implements JEP 503: Remove the 32-bit x86 Port. > > The JEP is proposed to target 25, we would not integrate until JEP is ready. Reviews are appreciated meanwhile. > > This is only the removal of obvious 32-bit x86 parts, mostly files with `x86_32` in their name. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. The approach for removing x86_32 files only also makes this PR borderline trivial, and requires no additional testing beyond normal pre-integration checks. > > The rest of the code is quite heavily intertwined with x86_64 and/or Zero, and would require accurate untangling. It would be much easier to review and test once we purge the free-standing parts of 32-bit x86 port, which is also a bulk of the port. The tangling with 32-bit x86 Zero is also why I did not touch most of the build system paths that handle x86. There is [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella that tracks further cleanup work. One can peek the final state that can be reached with all the cleanups in my earlier exploratory https://github.com/openjdk/jdk/pull/22567. > > Additional testing: > - [x] Linux x86_32 Server fastdebug, `make bootcycle-images` (now fails configure) > - [x] Linux x86_64 Server fastdebug, `make bootcycle-images` (still works) > - [x] Linux x86_32 Zero fastdebug, `make bootcycle-images` (still works) > - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works) Good. So it will be stacked PRs which you will combine for final integration? ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23906#pullrequestreview-2662377172 From kvn at openjdk.org Wed Mar 5 20:14:53 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 5 Mar 2025 20:14:53 GMT Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port In-Reply-To: References: Message-ID: <8UpKLmwCBMscNGtKyktL_h1aBYo6uzB3kYJOWeJIugA=.78c737ec-e212-4458-a009-79867ad260e5@github.com> On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev wrote: > This PR implements JEP 503: Remove the 32-bit x86 Port. > > The JEP is proposed to target 25, we would not integrate until JEP is ready. Reviews are appreciated meanwhile. > > This is only the removal of obvious 32-bit x86 parts, mostly files with `x86_32` in their name. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. The approach for removing x86_32 files only also makes this PR borderline trivial, and requires no additional testing beyond normal pre-integration checks. > > The rest of the code is quite heavily intertwined with x86_64 and/or Zero, and would require accurate untangling. It would be much easier to review and test once we purge the free-standing parts of 32-bit x86 port, which is also a bulk of the port. The tangling with 32-bit x86 Zero is also why I did not touch most of the build system paths that handle x86. There is [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella that tracks further cleanup work. One can peek the final state that can be reached with all the cleanups in my earlier exploratory https://github.com/openjdk/jdk/pull/22567. > > Additional testing: > - [x] Linux x86_32 Server fastdebug, `make bootcycle-images` (now fails configure) > - [x] Linux x86_64 Server fastdebug, `make bootcycle-images` (still works) > - [x] Linux x86_32 Zero fastdebug, `make bootcycle-images` (still works) > - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works) This is confusing. This PR is part of changes so it can't be "Implement JEP 503: Remove the 32-bit x86 Port" and should be subtask of Umbrella RFE. Am I missing something? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23906#issuecomment-2701962563 From xpeng at openjdk.org Wed Mar 5 21:13:53 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 5 Mar 2025 21:13:53 GMT Subject: RFR: 8351091: Shenandoah: global marking context completeness is not accurately maintained [v2] In-Reply-To: References:

Message-ID: <18_o9YLk3Ri0MTJscSSdp1Mg1C8c_cLUjoRfnxGL2e4=.ab8937c4-7ba2-4a67-8ecf-248f1c6f5545@github.com> On Wed, 5 Mar 2025 17:59:36 GMT, Y. Srinivas Ramakrishna wrote: > Had a few questions and comments inline. I'll take a closer look once you have responded to those. > > Thank you for finding this probably long-standing incorrectness/fuzziness and fixing it properly! Thanks, I'll update PR to address your comments. > src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.cpp line 103: > >> 101: >> 102: bool ShenandoahMarkingContext::is_complete() { >> 103: return ShenandoahHeap::heap()->global_generation()->is_mark_complete(); > > Do we need this? It seems wrong to me that even though each generation has its own marking context, we ask any marking context to report if that of the Global Generation is complete. I'd explicitly let generations maintain the state of completeness of their marking contexts, and for clients to query the generations for that state rather than having the individual marking contexts respond to that question. > > Where is this used after your changes? It may not be needed anymore, I will double check the usage and remove it is not used at all. > src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp line 337: > >> 335: // drop the reference. >> 336: if (type == REF_PHANTOM) { >> 337: return heap->complete_marking_context(referent_region)->is_marked(raw_referent); > > Doesn't the assert down at line 350 also need `complete_marking_context` ? Same at line 441. May be comb through all of these to determine which we need for proper assertion checking? > > I'd start by documenting the semantics of the APIs clearly. I am not completely clear on that yet (pun not intended :-) Yes, the assert at line 350 should use complete_marking_context, I have update it in the fix of the issue we found in stress test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23886#issuecomment-2702079928 PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r1982190515 PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r1982188076 From xpeng at openjdk.org Wed Mar 5 21:50:09 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 5 Mar 2025 21:50:09 GMT Subject: RFR: 8351091: Shenandoah: global marking context completeness is not accurately maintained [v2] In-Reply-To: References:

Message-ID: On Tue, 4 Mar 2025 23:11:20 GMT, Y. Srinivas Ramakrishna wrote: >> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Always use active_generation()->complete_marking_context() during reference processing > > src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 737: > >> 735: public: >> 736: inline ShenandoahMarkingContext* complete_marking_context(ShenandoahHeapRegion* region) const; >> 737: inline ShenandoahMarkingContext* marking_context() const; > > Should document semantics of both methods, please! I'll add some comments for both. Also I'm feel the assert is not enough, I feel we should change the `assert` in complete_marking_context to `guarantee`, should be something like: guarantee(is_mark_complete(), "Marking must be completed."); return ShenandoahHeap::heap()->marking_context(); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r1982236158 From xpeng at openjdk.org Wed Mar 5 21:54:08 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 5 Mar 2025 21:54:08 GMT Subject: RFR: 8351091: Shenandoah: global marking context completeness is not accurately maintained [v3] In-Reply-To: References: Message-ID: <1fKMcwPJFREZry2kJf0Vv3DoY5G4xzbdVJcK4It9hyo=.9a38f089-86c6-4fc9-abeb-a807284be822@github.com> > With the JEP 404: Generational Shenandoah implementation, there are generation specific marking completeness flags introduced, and the global marking context completeness flag is not updated at all after initialization, hence the global marking context completeness is not accurate anymore. This may cause expected behavior: [ShenandoahHeap::complete_marking_context()](https://github.com/openjdk/jdk/pull/23886/files#diff-d5ddf298c36b1c91bf33f9bff7bedcc063074edd68c298817f1fdf39d2ed970fL642) should throw assert error if the global marking context completeness flag is false, but now it always return the marking context even it marking is not complete, this may hide bugs where we expect the global/generational marking to be completed. > > This change PR fix the bug in global marking context completeness flag, and update all the places using `ShenandoahHeap::complete_marking_context()` to use proper API. > > ### Test > - [x] hotspot_gc_shenandoah > - [x] Tier 1 > - [x] Tier 2 Xiaolong Peng has updated the pull request incrementally with two additional commits since the last revision: - Remove obsolete code comments - Address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23886/files - new: https://git.openjdk.org/jdk/pull/23886/files/465deaec..c78f66ee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23886&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23886&range=01-02 Stats: 9 lines in 4 files changed: 2 ins; 7 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23886.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23886/head:pull/23886 PR: https://git.openjdk.org/jdk/pull/23886 From xpeng at openjdk.org Wed Mar 5 22:02:02 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 5 Mar 2025 22:02:02 GMT Subject: RFR: 8351091: Shenandoah: global marking context completeness is not accurately maintained [v3] In-Reply-To: References:

Message-ID: On Wed, 5 Mar 2025 01:33:26 GMT, Y. Srinivas Ramakrishna wrote: >> Xiaolong Peng has updated the pull request incrementally with two additional commits since the last revision: >> >> - Remove obsolete code comments >> - Address review comments > > src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1028: > >> 1026: >> 1027: #ifdef ASSERT >> 1028: ShenandoahMarkingContext* const ctx = _heap->marking_context(); > > Why not this instead? > > ShenandoahMarkingContext* const ctx = _heap->marking_context(r); Technically there is only one global marking context for Shenandoah, even in generational mode, passing the region to marking_context doesn't make any difference. But in the method `complete_marking_context(r)`, it checks if the affiliated generation has complete marking, it is a more convenient version of `complete_marking_context(affiliation)`. > src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.hpp line 88: > >> 86: bool is_bitmap_range_within_region_clear(const HeapWord* start, const HeapWord* end) const; >> 87: >> 88: bool is_complete(); > > Add a 1-line documentation comment for this method. is_complete is not used in any place, I removed it in the new version. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r1982247904 PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r1982248805 From vlivanov at openjdk.org Wed Mar 5 23:22:51 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 5 Mar 2025 23:22:51 GMT Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port In-Reply-To: References: Message-ID: <5nkWE-TpdoNk-k_5JE7MopX5_KJf6DjjLWMADxWr29k=.ee34fa19-882c-4731-86f6-bdaed2a6e276@github.com> On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev wrote: > This PR implements JEP 503: Remove the 32-bit x86 Port. > > The JEP is proposed to target 25, we would not integrate until JEP is ready. Reviews are appreciated meanwhile. > > This is only the removal of obvious 32-bit x86 parts, mostly files with `x86_32` in their name. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. The approach for removing x86_32 files only also makes this PR borderline trivial, and requires no additional testing beyond normal pre-integration checks. > > The rest of the code is quite heavily intertwined with x86_64 and/or Zero, and would require accurate untangling. It would be much easier to review and test once we purge the free-standing parts of 32-bit x86 port, which is also a bulk of the port. The tangling with 32-bit x86 Zero is also why I did not touch most of the build system paths that handle x86. There is [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella that tracks further cleanup work. One can peek the final state that can be reached with all the cleanups in my earlier exploratory https://github.com/openjdk/jdk/pull/22567. > > Additional testing: > - [x] Linux x86_32 Server fastdebug, `make bootcycle-images` (now fails configure) > - [x] Linux x86_64 Server fastdebug, `make bootcycle-images` (still works) > - [x] Linux x86_32 Zero fastdebug, `make bootcycle-images` (still works) > - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works) There's a wide variety of options to justify the goal of the JEP. A bare minimum would be to just remove x86-32 build support. And on the other side of the spectrum the current patch would be accompanied by all x86-32-specific code and all the features used exclusively by x86-32 port. During previous round of discussions I expressed my preference as keeping JEP implementation simple and perform all non-trivial cleanups as follow-up RFEs. IMO it enables swift removal (and eliminates the burden to keep x86-32 port alive during ongoing development work) while keeping incremental cleanup activities at comfortable pace. Proposed patch perfectly justifies my preference. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23906#issuecomment-2702299307 From kvn at openjdk.org Wed Mar 5 23:35:54 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 5 Mar 2025 23:35:54 GMT Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port In-Reply-To: References: Message-ID: <5ztalawYQsCNUsfzWyR_b5YVFWbDNzoHVUA4ycRjvRs=.42fd2b02-462f-4803-9d3b-2b907121c5be@github.com> On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev wrote: > This PR implements JEP 503: Remove the 32-bit x86 Port. > > The JEP is proposed to target 25, we would not integrate until JEP is ready. Reviews are appreciated meanwhile. > > This is only the removal of obvious 32-bit x86 parts, mostly files with `x86_32` in their name. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. The approach for removing x86_32 files only also makes this PR borderline trivial, and requires no additional testing beyond normal pre-integration checks. > > The rest of the code is quite heavily intertwined with x86_64 and/or Zero, and would require accurate untangling. It would be much easier to review and test once we purge the free-standing parts of 32-bit x86 port, which is also a bulk of the port. The tangling with 32-bit x86 Zero is also why I did not touch most of the build system paths that handle x86. There is [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella that tracks further cleanup work. One can peek the final state that can be reached with all the cleanups in my earlier exploratory https://github.com/openjdk/jdk/pull/22567. > > Additional testing: > - [x] Linux x86_32 Server fastdebug, `make bootcycle-images` (now fails configure) > - [x] Linux x86_64 Server fastdebug, `make bootcycle-images` (still works) > - [x] Linux x86_32 Zero fastdebug, `make bootcycle-images` (still works) > - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works) To clarify. I am completely agree with changes in this PR - I approved it. My concern is the **Title** of this PR and JBS entry. So I want to understand the steps we do with this PR and following changes covered by numbers of subtask pointed by Aleksey. So what, @iwanowww, you say is that this PR is **indeed** implementation of the JEP. And all subtasks listed in Umbrella RFE are following up RFEs after we integrated the JEP. Do I understand that correctly? Why not do what Ioi did for AOT class loading JEP? I mean, to have depending PRs which are combined into one implementation push. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23906#issuecomment-2702316448 From vlivanov at openjdk.org Thu Mar 6 00:18:52 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 6 Mar 2025 00:18:52 GMT Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port In-Reply-To: <5nkWE-TpdoNk-k_5JE7MopX5_KJf6DjjLWMADxWr29k=.ee34fa19-882c-4731-86f6-bdaed2a6e276@github.com> References: <5nkWE-TpdoNk-k_5JE7MopX5_KJf6DjjLWMADxWr29k=.ee34fa19-882c-4731-86f6-bdaed2a6e276@github.com> Message-ID: On Wed, 5 Mar 2025 23:19:50 GMT, Vladimir Ivanov wrote: >> This PR implements JEP 503: Remove the 32-bit x86 Port. >> >> The JEP is proposed to target 25, we would not integrate until JEP is ready. Reviews are appreciated meanwhile. >> >> This is only the removal of obvious 32-bit x86 parts, mostly files with `x86_32` in their name. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. The approach for removing x86_32 files only also makes this PR borderline trivial, and requires no additional testing beyond normal pre-integration checks. >> >> The rest of the code is quite heavily intertwined with x86_64 and/or Zero, and would require accurate untangling. It would be much easier to review and test once we purge the free-standing parts of 32-bit x86 port, which is also a bulk of the port. The tangling with 32-bit x86 Zero is also why I did not touch most of the build system paths that handle x86. There is [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella that tracks further cleanup work. One can peek the final state that can be reached with all the cleanups in my earlier exploratory https://github.com/openjdk/jdk/pull/22567. >> >> Additional testing: >> - [x] Linux x86_32 Server fastdebug, `make bootcycle-images` (now fails configure) >> - [x] Linux x86_64 Server fastdebug, `make bootcycle-images` (still works) >> - [x] Linux x86_32 Zero fastdebug, `make bootcycle-images` (still works) >> - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works) > > There's a wide variety of options to justify the goal of the JEP. A bare minimum would be to just remove x86-32 build support. And on the other side of the spectrum the current patch would be accompanied by all x86-32-specific code and all the features used exclusively by x86-32 port. > > During previous round of discussions I expressed my preference as keeping JEP implementation simple and perform all non-trivial cleanups as follow-up RFEs. IMO it enables swift removal (and eliminates the burden to keep x86-32 port alive during ongoing development work) while keeping incremental cleanup activities at comfortable pace. > > Proposed patch perfectly justifies my preference. > So what, @iwanowww, you say is that this PR is indeed implementation of the JEP. > And all subtasks listed in Umbrella RFE are following up RFEs after we integrated the JEP. > Do I understand that correctly? Yes. > Why not do what Ioi did for AOT class loading JEP? I mean, to have depending PRs which are combined into one implementation push. It's definitely an option. But, most likely, there'll be some overlooked cases anyway (leading to additional followup RFEs). And the more convoluted the changes are the harder it is to validate their correctness, thus increasing the risks for product stability and delaying the integration. (I'm not sure how much time Aleksey and other contributors want to volunteer to this project.) Also, in case of AOT JEP the situation was quite the opposite: it started with a huge patch which was split into multiple mostly independent parts to streamline its review. For x86-32 code removal there's no such patch prepared yet and the complete scope of work is not clear yet. IMO the crucial part is to get the port officially retired. After that the rest can become a good source of starter tasks :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23906#issuecomment-2702376289 From kvn at openjdk.org Thu Mar 6 00:21:53 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 6 Mar 2025 00:21:53 GMT Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port In-Reply-To: References: Message-ID: On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev wrote: > This PR implements JEP 503: Remove the 32-bit x86 Port. > > The JEP is proposed to target 25, we would not integrate until JEP is ready. Reviews are appreciated meanwhile. > > This is only the removal of obvious 32-bit x86 parts, mostly files with `x86_32` in their name. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. The approach for removing x86_32 files only also makes this PR borderline trivial, and requires no additional testing beyond normal pre-integration checks. > > The rest of the code is quite heavily intertwined with x86_64 and/or Zero, and would require accurate untangling. It would be much easier to review and test once we purge the free-standing parts of 32-bit x86 port, which is also a bulk of the port. The tangling with 32-bit x86 Zero is also why I did not touch most of the build system paths that handle x86. There is [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella that tracks further cleanup work. One can peek the final state that can be reached with all the cleanups in my earlier exploratory https://github.com/openjdk/jdk/pull/22567. > > Additional testing: > - [x] Linux x86_32 Server fastdebug, `make bootcycle-images` (now fails configure) > - [x] Linux x86_64 Server fastdebug, `make bootcycle-images` (still works) > - [x] Linux x86_32 Zero fastdebug, `make bootcycle-images` (still works) > - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works) Okay. Thank you for explaining. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23906#issuecomment-2702380269 From dholmes at openjdk.org Thu Mar 6 04:38:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 6 Mar 2025 04:38:52 GMT Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port In-Reply-To: References: Message-ID: On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev wrote: > This PR implements JEP 503: Remove the 32-bit x86 Port. > > The JEP is proposed to target 25, we would not integrate until JEP is ready. Reviews are appreciated meanwhile. > > This is only the removal of obvious 32-bit x86 parts, mostly files with `x86_32` in their name. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. The approach for removing x86_32 files only also makes this PR borderline trivial, and requires no additional testing beyond normal pre-integration checks. > > The rest of the code is quite heavily intertwined with x86_64 and/or Zero, and would require accurate untangling. It would be much easier to review and test once we purge the free-standing parts of 32-bit x86 port, which is also a bulk of the port. The tangling with 32-bit x86 Zero is also why I did not touch most of the build system paths that handle x86. There is [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella that tracks further cleanup work. One can peek the final state that can be reached with all the cleanups in my earlier exploratory https://github.com/openjdk/jdk/pull/22567. > > Additional testing: > - [x] Linux x86_32 Server fastdebug, `make bootcycle-images` (now fails configure) > - [x] Linux x86_64 Server fastdebug, `make bootcycle-images` (still works) > - [x] Linux x86_32 Zero fastdebug, `make bootcycle-images` (still works) > - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works) I am also a bit puzzled by the JEP/JBS strategy here. I would expect a bunch of dependent PRs that then get integrated together as "The Implementation of JEP 503". I understand things may be missed that require some follow up RFE's but I don't think we should start from that position and have a large chunk of work not be done under the JEP umbrella. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23906#issuecomment-2702781694 From shade at openjdk.org Thu Mar 6 09:52:09 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 6 Mar 2025 09:52:09 GMT Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port In-Reply-To: References: <5nkWE-TpdoNk-k_5JE7MopX5_KJf6DjjLWMADxWr29k=.ee34fa19-882c-4731-86f6-bdaed2a6e276@github.com> Message-ID: On Thu, 6 Mar 2025 00:16:12 GMT, Vladimir Ivanov wrote: >> There's a wide variety of options to justify the goal of the JEP. A bare minimum would be to just remove x86-32 build support. And on the other side of the spectrum the current patch would be accompanied by all x86-32-specific code and all the features used exclusively by x86-32 port. >> >> During previous round of discussions I expressed my preference as keeping JEP implementation simple and perform all non-trivial cleanups as follow-up RFEs. IMO it enables swift removal (and eliminates the burden to keep x86-32 port alive during ongoing development work) while keeping incremental cleanup activities at comfortable pace. >> >> Proposed patch perfectly justifies my preference. > >> So what, @iwanowww, you say is that this PR is indeed implementation of the JEP. >> And all subtasks listed in Umbrella RFE are following up RFEs after we integrated the JEP. >> Do I understand that correctly? > > Yes. > >> Why not do what Ioi did for AOT class loading JEP? I mean, to have depending PRs which are combined into one implementation push. > > It's definitely an option. But, most likely, there'll be some overlooked cases anyway (leading to additional followup RFEs). And the more convoluted the changes are the harder it is to validate their correctness, thus increasing the risks for product stability and delaying the integration. (I'm not sure how much time Aleksey and other contributors want to volunteer to this project.) > > Also, in case of AOT JEP the situation was quite the opposite: it started with a huge patch which was split into multiple mostly independent parts to streamline its review. For x86-32 code removal there's no such patch prepared yet and the complete scope of work is not clear yet. > > IMO the crucial part is to get the port officially retired. After that the rest can become a good source of starter tasks :-) Basically what @iwanowww said: this PR *is* the removal of x86_32 port. After this PR integrates, it is not possible to build x86_32, because the core implementation of it is missing, and build system would refuse to even try building it. So this removes x86_32 port as the feature, atomically, matching the title and intent of the JEP. *Then*, follow-up subtasks RFE would clean up the parts of Hotspot that were added to support various x86_32-specific features, and are no longer needed anymore. I, for one, also believed the complete PR would be more straight-forward. I attempted this at at https://github.com/openjdk/jdk/pull/22567. After working on that draft PR, and listening to what people said about it, I can conclude that is not a great way to go with this removal. The massive drawbacks of complete/stacked PR are now obvious to me: 1. It is hard to review. The complete PR is huge, 210+ files affected. A lot of removals are logically connected across different files, and while they are simple in isolation, it is hard for a reviewer to separate several cleanups in large PRs. 2. It accrues merge conflicts very fast. This happens even when mainline is somewhat idle without large feature integrations. I expect this work to be even harder once we are closer to RDP1. 3. It is hard to reach consensus on. Non-trivial changes require thorough review, and cobbling together multiple non-trivial changes require polynomially more coordination. I have seen this in Win32 port removal, so for a large PR like that I expect multiple, week-long review and amendment sessions. Which conspires with (1) and (2). 4. It is easy to introduce/overlook bugs. I already did this once in a complete PR when I accidentally removed the wrong part of C1 regalloc code, and it started ever so slightly misbehaving. And it was not obvious, because it was obscured by other changes in the vicinity. Which conspires with (1), (2) and (3). 5. It would introduce a single changeset that would be hard to bisect when things go wrong. And the things would go wrong, because of (1), (4) and partially by new opportunities presented by (2). For the C1 bug I mentioned above, I was able to quickly nail it through the bisection of my stack of atomic commits. That stack would not be available once we squash the commits/PRs before the integration. So while on a surface it might look more enticing to purge everything at once, the amount of hassle we would endure is hard to justify. Doing this PR for port removal + multiple post-removal cleanups piecewise lets us reach the same final state without extra work, while doing so at leisurely pace and maintaining more convenient code history for future bug hunts. Bottom-line: Let's not make our own lives harder unnecessarily. Atomic commits FTW. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23906#issuecomment-2703337731 From jsjolen at openjdk.org Thu Mar 6 10:27:06 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 6 Mar 2025 10:27:06 GMT Subject: RFR: 8350566: NMT: add size parameter to MemTracker::record_virtual_memory_tag In-Reply-To: References:

Message-ID: <0CDxD_JcYtu4Ax1xB8TDyWqLkxNub6OfJRtSmCFONgU=.bd3edae0-3eaf-4ba3-ac9e-2582d1baf151@github.com> On Wed, 5 Mar 2025 15:28:59 GMT, Gerard Ziemski wrote: >> With the `size` parameter there will be no need to traverse/go through the nodes between the base and end of the region. >> Tests: >> linux-x64-debug, gtest:NMT* and runtime/NMT* > > src/hotspot/share/cds/metaspaceShared.cpp line 1475: > >> 1473: (address)archive_space_rs.base() == base_address, "Sanity"); >> 1474: // Register archive space with NMT. >> 1475: MemTracker::record_virtual_memory_tag(archive_space_rs.base(), archive_space_rs.size(), mtClassShared); > > The pattern here is: > > `something.base(), something.base.size()` > > instead of doing this over and over again, why can't we just pass `something` to MemTracker::record_virtual_memory_tag() and let it figure out `base` and `size` itself? We could have an overload for `ReservedSpace`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23770#discussion_r1983093725 From coleenp at openjdk.org Thu Mar 6 12:38:52 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 6 Mar 2025 12:38:52 GMT Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port In-Reply-To: References: Message-ID: On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev wrote: > This PR implements JEP 503: Remove the 32-bit x86 Port. > > The JEP is proposed to target 25, we would not integrate until JEP is ready. Reviews are appreciated meanwhile. > > This is only the removal of obvious 32-bit x86 parts, mostly files with `x86_32` in their name. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. The approach for removing x86_32 files only also makes this PR borderline trivial, and requires no additional testing beyond normal pre-integration checks. > > The rest of the code is quite heavily intertwined with x86_64 and/or Zero, and would require accurate untangling. It would be much easier to review and test once we purge the free-standing parts of 32-bit x86 port, which is also a bulk of the port. The tangling with 32-bit x86 Zero is also why I did not touch most of the build system paths that handle x86. There is [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella that tracks further cleanup work. One can peek the final state that can be reached with all the cleanups in my earlier exploratory https://github.com/openjdk/jdk/pull/22567. > > Additional testing: > - [x] Linux x86_32 Server fastdebug, `make bootcycle-images` (now fails configure) > - [x] Linux x86_64 Server fastdebug, `make bootcycle-images` (still works) > - [x] Linux x86_32 Zero fastdebug, `make bootcycle-images` (still works) > - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works) I agree with @iwanowww's and @shipilev comments. I would like to see this be the JEP implementation and the additional cleanups, particularly in the interpreter, handled one by one. I don't see any advantage for one big integration push. It'll be disruptive and for this, there is no scenario where this would be helpful to any future work. When Aleksey sent out the original PR there were cleanups that needed explanation. Finding the explanations in the big PR is a pain for scrolling. And the reviewers for that part of the change were a different set than ones needed for this change. Again for no benefit. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23906#pullrequestreview-2664309410 From coleenp at openjdk.org Thu Mar 6 12:38:53 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 6 Mar 2025 12:38:53 GMT Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port In-Reply-To: References: <5nkWE-TpdoNk-k_5JE7MopX5_KJf6DjjLWMADxWr29k=.ee34fa19-882c-4731-86f6-bdaed2a6e276@github.com>

Message-ID: On Thu, 6 Mar 2025 09:48:47 GMT, Aleksey Shipilev wrote: >>> So what, @iwanowww, you say is that this PR is indeed implementation of the JEP. >>> And all subtasks listed in Umbrella RFE are following up RFEs after we integrated the JEP. >>> Do I understand that correctly? >> >> Yes. >> >>> Why not do what Ioi did for AOT class loading JEP? I mean, to have depending PRs which are combined into one implementation push. >> >> It's definitely an option. But, most likely, there'll be some overlooked cases anyway (leading to additional followup RFEs). And the more convoluted the changes are the harder it is to validate their correctness, thus increasing the risks for product stability and delaying the integration. (I'm not sure how much time Aleksey and other contributors want to volunteer to this project.) >> >> Also, in case of AOT JEP the situation was quite the opposite: it started with a huge patch which was split into multiple mostly independent parts to streamline its review. For x86-32 code removal there's no such patch prepared yet and the complete scope of work is not clear yet. >> >> IMO the crucial part is to get the port officially retired. After that the rest can become a good source of starter tasks :-) > > Basically what @iwanowww said: this PR *is* the removal of x86_32 port. > > After this PR integrates, it is not possible to build x86_32, because the core implementation of it is missing, and build system would refuse to even try building it. So this removes x86_32 port as the feature, atomically, matching the title and intent of the JEP. *Then*, follow-up subtasks RFE would clean up the parts of Hotspot that were added to support various x86_32-specific features, and are no longer needed anymore. > > Honestly, I also believed the complete PR that cleans up every dusty corner at once would be more straight-forward. But then I tried it at https://github.com/openjdk/jdk/pull/22567. After investing a few full days on that draft PR, and listening to what people said about it, I firmly changed my mind, and can conclude that singular PR or series of stacked PRs are not a great way to go with this removal. > > The massive drawbacks of complete/stacked PR are now obvious to me: > 1. It is hard to review. The complete PR is huge, 210+ files affected. A lot of removals are logically connected across different files, and while they are simple in isolation, it is hard for a reviewer to separate several cleanups in large PRs. Stacked PRs would help some, but: > 2. It accrues merge conflicts very fast. This happens even when mainline is somewhat idle without large feature integrations. I did complete PR near New Year holidays, and it was _already_ a headache. I expect this work to be even harder once we are closer to RDP1. It would be even more tedious with a chain of 10+ stacked PRs, as I got the preview of this when rebasing the stack of atomic commits in the complete draft PR several times. > 3. It is hard to reach consensus on. Non-trivial changes require thorough review, and cobbling together multiple non-trivial changes require polynomially more coordination. I have seen this in Win32 port removal, so for a large PR like that I expect multiple, week-long review and amendment sessions. Which conspires with (1) and (2). > 4. It is easy to introduce/overlook bugs. I already did this once in a complete PR when I accidentally removed the wrong part of C1 regalloc code, and it started ever so slightly misbehaving. And it was not obvious, because it was obscured by other changes in the vicinity, and it only failed one test in tier4. This conspires with (1), (2) and (3). > 5. It would introduce a single changeset that would be hard to bisect when things go wrong. And the things wo... Also @shipilev I'm jealous of all your code removal. :) Well done getting agreement on this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23906#issuecomment-2703725960 From azafari at openjdk.org Thu Mar 6 14:22:38 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 6 Mar 2025 14:22:38 GMT Subject: RFR: 8350566: NMT: add size parameter to MemTracker::record_virtual_memory_tag [v2] In-Reply-To: References: Message-ID: > With the `size` parameter there will be no need to traverse/go through the nodes between the base and end of the region. > Tests: > linux-x64-debug, gtest:NMT* and runtime/NMT* Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: ReservedSpace is accepted as param. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23770/files - new: https://git.openjdk.org/jdk/pull/23770/files/0a1495bc..1e7853e6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23770&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23770&range=00-01 Stats: 21 lines in 12 files changed: 4 ins; 1 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/23770.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23770/head:pull/23770 PR: https://git.openjdk.org/jdk/pull/23770 From azafari at openjdk.org Thu Mar 6 14:22:39 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 6 Mar 2025 14:22:39 GMT Subject: RFR: 8350566: NMT: add size parameter to MemTracker::record_virtual_memory_tag [v2] In-Reply-To: References:

Message-ID: On Wed, 5 Mar 2025 15:25:29 GMT, Gerard Ziemski wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> ReservedSpace is accepted as param. > > src/hotspot/share/cds/metaspaceShared.cpp line 1548: > >> 1546: return nullptr; >> 1547: } >> 1548: // NMT: fix up the space tags > > What exactly needs to be fixed here? Removed. Obsolete comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23770#discussion_r1983442554 From azafari at openjdk.org Thu Mar 6 14:22:39 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 6 Mar 2025 14:22:39 GMT Subject: RFR: 8350566: NMT: add size parameter to MemTracker::record_virtual_memory_tag [v2] In-Reply-To: <0CDxD_JcYtu4Ax1xB8TDyWqLkxNub6OfJRtSmCFONgU=.bd3edae0-3eaf-4ba3-ac9e-2582d1baf151@github.com> References:

<0CDxD_JcYtu4Ax1xB8TDyWqLkxNub6OfJRtSmCFONgU=.bd3edae0-3eaf-4ba3-ac9e-2582d1baf151@github.com> Message-ID: On Thu, 6 Mar 2025 10:23:54 GMT, Johan Sj?len wrote: >> src/hotspot/share/cds/metaspaceShared.cpp line 1475: >> >>> 1473: (address)archive_space_rs.base() == base_address, "Sanity"); >>> 1474: // Register archive space with NMT. >>> 1475: MemTracker::record_virtual_memory_tag(archive_space_rs.base(), archive_space_rs.size(), mtClassShared); >> >> The pattern here is: >> >> `something.base(), something.base.size()` >> >> instead of doing this over and over again, why can't we just pass `something` to MemTracker::record_virtual_memory_tag() and let it figure out `base` and `size` itself? > > We could have an overload for `ReservedSpace`. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23770#discussion_r1983441505 From gziemski at openjdk.org Thu Mar 6 15:27:04 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Thu, 6 Mar 2025 15:27:04 GMT Subject: RFR: 8350566: NMT: add size parameter to MemTracker::record_virtual_memory_tag [v2] In-Reply-To: References:

Message-ID: On Thu, 6 Mar 2025 14:22:38 GMT, Afshin Zafari wrote: >> With the `size` parameter there will be no need to traverse/go through the nodes between the base and end of the region. >> Tests: >> linux-x64-debug, gtest:NMT* and runtime/NMT* > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > ReservedSpace is accepted as param. LGTM, thank you for fixing this. Need to fix the build errors: /home/runner/work/jdk/jdk/src/hotspot/share/nmt/memTracker.hpp:224:31: error: invalid use of incomplete type ?const class ReservedSpace? 224 | record_virtual_memory_tag(rs.base(), rs.size(), mem_tag); | ^~ In file included from /home/runner/work/jdk/jdk/src/hotspot/share/memory/allocation.cpp:28: /home/runner/work/jdk/jdk/src/hotspot/share/memory/metaspace.hpp:38:7: note: forward declaration of ?class ReservedSpace? 38 | class ReservedSpace; | ^~~~~~~~~~~~~ In file included from /home/runner/work/jdk/jdk/src/hotspot/share/memory/allocation.cpp:30: /home/runner/work/jdk/jdk/src/hotspot/share/nmt/memTracker.hpp:224:42: error: invalid use of incomplete type ?const class ReservedSpace? 224 | record_virtual_memory_tag(rs.base(), rs.size(), mem_tag); | ^~ In file included from /home/runner/work/jdk/jdk/src/hotspot/share/memory/allocation.cpp:28: /home/runner/work/jdk/jdk/src/hotspot/share/memory/metaspace.hpp:38:7: note: forward declaration of ?class ReservedSpace? ... (rest of output omitted) ------------- Marked as reviewed by gziemski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23770#pullrequestreview-2664792545 PR Comment: https://git.openjdk.org/jdk/pull/23770#issuecomment-2704168962 From ihse at openjdk.org Thu Mar 6 16:21:54 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 6 Mar 2025 16:21:54 GMT Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port In-Reply-To: References: Message-ID: On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev wrote: > This PR implements JEP 503: Remove the 32-bit x86 Port. > > The JEP is proposed to target 25, we would not integrate until JEP is ready. Reviews are appreciated meanwhile. > > This is only the removal of obvious 32-bit x86 parts, mostly files with `x86_32` in their name. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. The approach for removing x86_32 files only also makes this PR borderline trivial, and requires no additional testing beyond normal pre-integration checks. > > The rest of the code is quite heavily intertwined with x86_64 and/or Zero, and would require accurate untangling. It would be much easier to review and test once we purge the free-standing parts of 32-bit x86 port, which is also a bulk of the port. The tangling with 32-bit x86 Zero is also why I did not touch most of the build system paths that handle x86. There is [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella that tracks further cleanup work. One can peek the final state that can be reached with all the cleanups in my earlier exploratory https://github.com/openjdk/jdk/pull/22567. > > Additional testing: > - [x] Linux x86_32 Server fastdebug, `make bootcycle-images` (now fails configure) > - [x] Linux x86_64 Server fastdebug, `make bootcycle-images` (still works) > - [x] Linux x86_32 Zero fastdebug, `make bootcycle-images` (still works) > - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works) make/autoconf/platform.m4 line 669: > 667: AC_ARG_ENABLE(deprecated-ports, [AS_HELP_STRING([--enable-deprecated-ports@<:@=yes/no@:>@], > 668: [Suppress the error when configuring for a deprecated port @<:@no@:>@])]) > 669: # There are no deprecated ports. This option is left to be consistent with future deprecations. Please remove. Old code is always present in git history if you want to reuse it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23906#discussion_r1983670151 From shade at openjdk.org Thu Mar 6 16:40:58 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 6 Mar 2025 16:40:58 GMT Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port In-Reply-To: References:

Message-ID: On Thu, 6 Mar 2025 16:18:50 GMT, Magnus Ihse Bursie wrote: >> This PR implements JEP 503: Remove the 32-bit x86 Port. >> >> The JEP is proposed to target 25, we would not integrate until JEP is ready. Reviews are appreciated meanwhile. >> >> This is only the removal of obvious 32-bit x86 parts, mostly files with `x86_32` in their name. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. The approach for removing x86_32 files only also makes this PR borderline trivial, and requires no additional testing beyond normal pre-integration checks. >> >> The rest of the code is quite heavily intertwined with x86_64 and/or Zero, and would require accurate untangling. It would be much easier to review and test once we purge the free-standing parts of 32-bit x86 port, which is also a bulk of the port. The tangling with 32-bit x86 Zero is also why I did not touch most of the build system paths that handle x86. There is [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella that tracks further cleanup work. One can peek the final state that can be reached with all the cleanups in my earlier exploratory https://github.com/openjdk/jdk/pull/22567. >> >> Additional testing: >> - [x] Linux x86_32 Server fastdebug, `make bootcycle-images` (now fails configure) >> - [x] Linux x86_64 Server fastdebug, `make bootcycle-images` (still works) >> - [x] Linux x86_32 Zero fastdebug, `make bootcycle-images` (still works) >> - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works) > > make/autoconf/platform.m4 line 669: > >> 667: AC_ARG_ENABLE(deprecated-ports, [AS_HELP_STRING([--enable-deprecated-ports@<:@=yes/no@:>@], >> 668: [Suppress the error when configuring for a deprecated port @<:@no@:>@])]) >> 669: # There are no deprecated ports. This option is left to be consistent with future deprecations. > > Please remove. Old code is always present in git history if you want to reuse it. I don't mind removing it, my concern would be to _remember_ this option was there! I guess it is okay to re-re-invent it later, possibly under a different name, when the next port gets deprecated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23906#discussion_r1983704213 From wkemper at openjdk.org Thu Mar 6 17:59:00 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 6 Mar 2025 17:59:00 GMT Subject: RFR: 8351091: Shenandoah: global marking context completeness is not accurately maintained [v3] In-Reply-To: <1fKMcwPJFREZry2kJf0Vv3DoY5G4xzbdVJcK4It9hyo=.9a38f089-86c6-4fc9-abeb-a807284be822@github.com> References: <1fKMcwPJFREZry2kJf0Vv3DoY5G4xzbdVJcK4It9hyo=.9a38f089-86c6-4fc9-abeb-a807284be822@github.com> Message-ID: On Wed, 5 Mar 2025 21:54:08 GMT, Xiaolong Peng wrote: >> With the JEP 404: Generational Shenandoah implementation, there are generation specific marking completeness flags introduced, and the global marking context completeness flag is not updated at all after initialization, hence the global marking context completeness is not accurate anymore. This may cause expected behavior: [ShenandoahHeap::complete_marking_context()](https://github.com/openjdk/jdk/pull/23886/files#diff-d5ddf298c36b1c91bf33f9bff7bedcc063074edd68c298817f1fdf39d2ed970fL642) should throw assert error if the global marking context completeness flag is false, but now it always return the marking context even it marking is not complete, this may hide bugs where we expect the global/generational marking to be completed. >> >> This change PR fix the bug in global marking context completeness flag, and update all the places using `ShenandoahHeap::complete_marking_context()` to use proper API. >> >> ### Test >> - [x] hotspot_gc_shenandoah >> - [x] Tier 1 >> - [x] Tier 2 > > Xiaolong Peng has updated the pull request incrementally with two additional commits since the last revision: > > - Remove obsolete code comments > - Address review comments If we always get the complete marking context directly through the generation, we can delete `ShenandoahHeap::complete_marking_context`. src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 123: > 121: #ifdef ASSERT > 122: bool reg_live = region->has_live(); > 123: bool bm_live = heap->complete_marking_context(region)->is_marked(cast_to_oop(region->bottom())); Could also use `heap->active_generation()->complete_marking_context()` here. src/hotspot/share/gc/shenandoah/shenandoahGenerationalEvacuationTask.cpp line 172: > 170: // contained herein. > 171: void ShenandoahGenerationalEvacuationTask::promote_in_place(ShenandoahHeapRegion* region) { > 172: ShenandoahMarkingContext* const marking_context = _heap->complete_marking_context(region); We shouldn't need to look up the generation for this region. It's being promoted so it must be young (in fact, this asserted a few lines down). Perhaps: assert(_heap->young_generation()->is_mark_completed(), "Cannot promote without complete marking for young"); ShenandoahMarkingContext* const marking_context = _heap->marking_context(); ------------- Changes requested by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23886#pullrequestreview-2665222915 PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r1983818301 PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r1983812569 From wkemper at openjdk.org Thu Mar 6 17:59:01 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 6 Mar 2025 17:59:01 GMT Subject: RFR: 8351091: Shenandoah: global marking context completeness is not accurately maintained [v3] In-Reply-To: References: <1fKMcwPJFREZry2kJf0Vv3DoY5G4xzbdVJcK4It9hyo=.9a38f089-86c6-4fc9-abeb-a807284be822@github.com> Message-ID: On Thu, 6 Mar 2025 17:49:35 GMT, William Kemper wrote: >> Xiaolong Peng has updated the pull request incrementally with two additional commits since the last revision: >> >> - Remove obsolete code comments >> - Address review comments > > src/hotspot/share/gc/shenandoah/shenandoahGenerationalEvacuationTask.cpp line 172: > >> 170: // contained herein. >> 171: void ShenandoahGenerationalEvacuationTask::promote_in_place(ShenandoahHeapRegion* region) { >> 172: ShenandoahMarkingContext* const marking_context = _heap->complete_marking_context(region); > > We shouldn't need to look up the generation for this region. It's being promoted so it must be young (in fact, this asserted a few lines down). Perhaps: > > assert(_heap->young_generation()->is_mark_completed(), "Cannot promote without complete marking for young"); > ShenandoahMarkingContext* const marking_context = _heap->marking_context(); or `_heap->young_generation()->complete_marking_context()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r1983821706 From cslucas at openjdk.org Thu Mar 6 18:24:34 2025 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Thu, 6 Mar 2025 18:24:34 GMT Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card tables [v8] In-Reply-To: References: Message-ID: > In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. > > The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase. > > The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table. > > Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address. > > The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged. > > Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code. > > Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry ?) and PowerPC (@TheRealMDoerr ?) platforms could review and test the changes for those platforms, as I have limited access to running tests on them. Cesar Soares Lucas has updated the pull request incrementally with two additional commits since the last revision: - Revert changes to shenandoahHeap.cpp - Address PR feedback: moar clean-up. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23170/files - new: https://git.openjdk.org/jdk/pull/23170/files/046ea8a0..0262b7df Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23170&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23170&range=06-07 Stats: 29 lines in 4 files changed: 5 ins; 18 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/23170.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23170/head:pull/23170 PR: https://git.openjdk.org/jdk/pull/23170 From cslucas at openjdk.org Thu Mar 6 18:24:34 2025 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Thu, 6 Mar 2025 18:24:34 GMT Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card tables [v6] In-Reply-To: <_LIv8Ggp3ukK0HmhknyG_Mz2x5OKs63Y-qSXTQo9Gdo=.9efc86f1-6cc4-425b-9319-5e1500eb59da@github.com> References:

<_LIv8Ggp3ukK0HmhknyG_Mz2x5OKs63Y-qSXTQo9Gdo=.9efc86f1-6cc4-425b-9319-5e1500eb59da@github.com> Message-ID: On Wed, 5 Mar 2025 17:32:30 GMT, Aleksey Shipilev wrote: >> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: >> >> Address PR feedback: formatting. > > src/hotspot/share/gc/shenandoah/shenandoahCardTable.cpp line 57: > >> 55: _byte_map = (CardValue*) write_space.base(); >> 56: _byte_map_base = _byte_map - (uintptr_t(low_bound) >> _card_shift); >> 57: > > It is a bit sad to see these asserts go. Is this because `_byte_map` is now mutable? May I suggest doing something like: > > > _write_byte_map = (CardValue*) write_space.base(); > _write_byte_map_base = _byte_map - (uintptr_t(low_bound) >> _card_shift); > ...later... > _read_byte_map = (CardValue*) read_space.base(); > _read_byte_map_base = _byte_map - (uintptr_t(low_bound) >> _card_shift); > ...later... > > // Set up current byte map > _byte_map = _write_byte_map; > _byte_map_base = _write_byte_map_base; > > // Check one side is good > assert(byte_for(low_bound) == &_byte_map[0], "Checking start of map"); > assert(byte_for(high_bound-1) <= &_byte_map[last_valid_index()], "Checking end of map"); > swap_read_and_write_tables(); > > // Check another side is good > assert(byte_for(low_bound) == &_byte_map[0], "Checking start of map"); > assert(byte_for(high_bound-1) <= &_byte_map[last_valid_index()], "Checking end of map"); > swap_read_and_write_tables(); @shipilev - I did some tests and the conclusion is that we can put the asserts back. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1983847384 From cslucas at openjdk.org Thu Mar 6 18:24:34 2025 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Thu, 6 Mar 2025 18:24:34 GMT Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card tables [v5] In-Reply-To: References:

<2ZFtKLn2EcbzjKQ_USb3yiOWEWQJYocFwj_rk-5h0Jg=.f4eec566-3e0c-4a75-8c27-2cb785b0081a@github.com>

Message-ID: On Wed, 5 Mar 2025 17:45:19 GMT, Aleksey Shipilev wrote: >> Yes, that's for the VMThread. That seems like a good question. I > > Actually, I am wondering why this is needed. It looks to me VMThread attaches after heap initialization, and the normal `ShenandoahBarrierSet::on_thread_attach` should handle it. You're right, we didn't need that anymore. I removed + test it and we're good. I pushed a commit removing that code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1983853294 From ihse at openjdk.org Thu Mar 6 18:25:54 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 6 Mar 2025 18:25:54 GMT Subject: RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port In-Reply-To: References:

Message-ID: On Thu, 6 Mar 2025 16:38:13 GMT, Aleksey Shipilev wrote: >> make/autoconf/platform.m4 line 669: >> >>> 667: AC_ARG_ENABLE(deprecated-ports, [AS_HELP_STRING([--enable-deprecated-ports@<:@=yes/no@:>@], >>> 668: [Suppress the error when configuring for a deprecated port @<:@no@:>@])]) >>> 669: # There are no deprecated ports. This option is left to be consistent with future deprecations. >> >> Please remove. Old code is always present in git history if you want to reuse it. > > I don't mind removing it, my concern would be to _remember_ this option was there! I guess it is okay to re-re-invent it later, possibly under a different name, when the next port gets deprecated. It's no that important, no. I'm not sure if previous deprecated ports were handles exactly like this. And you can always do like `git log | grep -i "remove .* port"` to find the change it was removed in, and look what it did... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23906#discussion_r1983855800 From xpeng at openjdk.org Thu Mar 6 18:29:59 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Thu, 6 Mar 2025 18:29:59 GMT Subject: RFR: 8351091: Shenandoah: global marking context completeness is not accurately maintained [v3] In-Reply-To: References: <1fKMcwPJFREZry2kJf0Vv3DoY5G4xzbdVJcK4It9hyo=.9a38f089-86c6-4fc9-abeb-a807284be822@github.com> Message-ID: <4q52xc9nKJWFe63AT5i4InyJuRu6pTPahZYmmWTJia4=.f7be6d2d-2082-4644-b6e9-dff343b20cdf@github.com> On Thu, 6 Mar 2025 17:55:53 GMT, William Kemper wrote: > If we always get the complete marking context directly through the generation, we can delete `ShenandoahHeap::complete_marking_context`. True, we don't really need it anymore, I'll update the PR and remove it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23886#issuecomment-2704629400 From xpeng at openjdk.org Thu Mar 6 18:30:00 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Thu, 6 Mar 2025 18:30:00 GMT Subject: RFR: 8351091: Shenandoah: global marking context completeness is not accurately maintained [v3] In-Reply-To: References: <1fKMcwPJFREZry2kJf0Vv3DoY5G4xzbdVJcK4It9hyo=.9a38f089-86c6-4fc9-abeb-a807284be822@github.com>

Message-ID: On Thu, 6 Mar 2025 17:56:31 GMT, William Kemper wrote: >> src/hotspot/share/gc/shenandoah/shenandoahGenerationalEvacuationTask.cpp line 172: >> >>> 170: // contained herein. >>> 171: void ShenandoahGenerationalEvacuationTask::promote_in_place(ShenandoahHeapRegion* region) { >>> 172: ShenandoahMarkingContext* const marking_context = _heap->complete_marking_context(region); >> >> We shouldn't need to look up the generation for this region. It's being promoted so it must be young (in fact, this asserted a few lines down). Perhaps: >> >> assert(_heap->young_generation()->is_mark_completed(), "Cannot promote without complete marking for young"); >> ShenandoahMarkingContext* const marking_context = _heap->marking_context(); > > or `_heap->young_generation()->complete_marking_context()`. I think `_heap->young_generation()->complete_marking_context()` is better here, I'll update it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r1983859657 From xpeng at openjdk.org Thu Mar 6 18:34:43 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Thu, 6 Mar 2025 18:34:43 GMT Subject: RFR: 8351091: Shenandoah: global marking context completeness is not accurately maintained [v4] In-Reply-To: References: Message-ID: > With the JEP 404: Generational Shenandoah implementation, there are generation specific marking completeness flags introduced, and the global marking context completeness flag is not updated at all after initialization, hence the global marking context completeness is not accurate anymore. This may cause expected behavior: [ShenandoahHeap::complete_marking_context()](https://github.com/openjdk/jdk/pull/23886/files#diff-d5ddf298c36b1c91bf33f9bff7bedcc063074edd68c298817f1fdf39d2ed970fL642) should throw assert error if the global marking context completeness flag is false, but now it always return the marking context even it marking is not complete, this may hide bugs where we expect the global/generational marking to be completed. > > This change PR fix the bug in global marking context completeness flag, and update all the places using `ShenandoahHeap::complete_marking_context()` to use proper API. > > ### Test > - [x] hotspot_gc_shenandoah > - [x] Tier 1 > - [x] Tier 2 Xiaolong Peng has updated the pull request incrementally with three additional commits since the last revision: - Remove ShenandoahHeap::complete_marking_context(ShenandoahHeapRegion* region) - Revert "complete_marking_context should guarantee mark is complete" This reverts commit 2004973965ea0e617cf9e5fc45be24f0e06e90a1. - complete_marking_context should guarantee mark is complete ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23886/files - new: https://git.openjdk.org/jdk/pull/23886/files/c78f66ee..952f7ea5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23886&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23886&range=02-03 Stats: 9 lines in 5 files changed: 0 ins; 6 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23886.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23886/head:pull/23886 PR: https://git.openjdk.org/jdk/pull/23886 From wkemper at openjdk.org Thu Mar 6 18:47:58 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 6 Mar 2025 18:47:58 GMT Subject: RFR: 8351091: Shenandoah: global marking context completeness is not accurately maintained [v4] In-Reply-To: References:

Message-ID: On Thu, 6 Mar 2025 18:34:43 GMT, Xiaolong Peng wrote: >> With the JEP 404: Generational Shenandoah implementation, there are generation specific marking completeness flags introduced, and the global marking context completeness flag is not updated at all after initialization, hence the global marking context completeness is not accurate anymore. This may cause expected behavior: [ShenandoahHeap::complete_marking_context()](https://github.com/openjdk/jdk/pull/23886/files#diff-d5ddf298c36b1c91bf33f9bff7bedcc063074edd68c298817f1fdf39d2ed970fL642) should throw assert error if the global marking context completeness flag is false, but now it always return the marking context even it marking is not complete, this may hide bugs where we expect the global/generational marking to be completed. >> >> This change PR fix the bug in global marking context completeness flag, and update all the places using `ShenandoahHeap::complete_marking_context()` to use proper API. >> >> ### Test >> - [x] hotspot_gc_shenandoah >> - [x] Tier 1 >> - [x] Tier 2 > > Xiaolong Peng has updated the pull request incrementally with three additional commits since the last revision: > > - Remove ShenandoahHeap::complete_marking_context(ShenandoahHeapRegion* region) > - Revert "complete_marking_context should guarantee mark is complete" > > This reverts commit 2004973965ea0e617cf9e5fc45be24f0e06e90a1. > - complete_marking_context should guarantee mark is complete Thanks for cleaning this up. ------------- Marked as reviewed by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23886#pullrequestreview-2665341497 From cslucas at openjdk.org Thu Mar 6 19:45:21 2025 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Thu, 6 Mar 2025 19:45:21 GMT Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card tables [v9] In-Reply-To: References: Message-ID: > In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. > > The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase. > > The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table. > > Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address. > > The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged. > > Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code. > > Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry ?) and PowerPC (@TheRealMDoerr ?) platforms could review and test the changes for those platforms, as I have limited access to running tests on them. Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: Fix build: no shenandoah on arm32. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23170/files - new: https://git.openjdk.org/jdk/pull/23170/files/0262b7df..0a540c79 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23170&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23170&range=07-08 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23170.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23170/head:pull/23170 PR: https://git.openjdk.org/jdk/pull/23170 From shade at openjdk.org Thu Mar 6 19:49:58 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 6 Mar 2025 19:49:58 GMT Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card tables [v9] In-Reply-To: References:

Message-ID: On Thu, 6 Mar 2025 19:45:21 GMT, Cesar Soares Lucas