From kbarrett at openjdk.org Sun Feb 1 00:26:01 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 1 Feb 2026 00:26:01 GMT Subject: RFR: 8376115: G1: Convert G1CMRootRegions to use Atomic [v2] In-Reply-To: References:

Message-ID: On Mon, 26 Jan 2026 09:45:46 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change to convert `G1CMRootRegions` to use `Atomic`. >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * kbarrett review Still good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29363#pullrequestreview-3734061605 From lkorinth at openjdk.org Mon Feb 2 08:05:21 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 2 Feb 2026 08:05:21 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v9] In-Reply-To: References:

Message-ID: On Thu, 29 Jan 2026 14:47:12 GMT, Leo Korinth wrote: >> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. >> >> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. >> >> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. >> >> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. > > Leo Korinth has updated the pull request incrementally with two additional commits since the last revision: > > - Reapply "remove commented out code" > > This reverts commit d0d1860058f0dae7813c3e5115e2784da8331f3b. > - Reapply "Stefan J 4" > > This reverts commit c5a7e2bb44ce111f8c8d1d7f728f1bf8013475e0. Thanks everyone! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28723#issuecomment-3833554735 From lkorinth at openjdk.org Mon Feb 2 08:05:23 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 2 Feb 2026 08:05:23 GMT Subject: Integrated: 8367993: G1: Speed up ConcurrentMark initialization In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 14:56:49 GMT, Leo Korinth wrote: > This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. > > It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. > > This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. > > I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. This pull request has now been integrated. Changeset: 766e03b1 Author: Leo Korinth URL: https://git.openjdk.org/jdk/commit/766e03b151b2972108ddc207eed10428e9a91c30 Stats: 57 lines in 9 files changed: 30 ins; 6 del; 21 mod 8367993: G1: Speed up ConcurrentMark initialization Reviewed-by: sjohanss, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/28723 From tschatzl at openjdk.org Mon Feb 2 08:23:03 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 2 Feb 2026 08:23:03 GMT Subject: RFR: 8374782: Parallel: Investigate removal of specialized objArray iteration code In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 12:58:01 GMT, Ivan Walulya wrote: > Hi, > > Please review this change removes specialized local methods used to iterate over array slices in `PSPromotionManager`. Any performance differences between these methods and `objArrayOopDesc::oop_iterate_elements_range` are attributable to differences in inlining behavior. For this reason, `ALWAYSINLINE` is applied. Further investigation is ongoing to improve inlining of calls through `objArrayOopDesc::oop_iterate_elements_range`. > > Testing: Tier 1-3, perf testing with SPECjvm2008-XML.validation. Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29486#pullrequestreview-3737938205 From tschatzl at openjdk.org Mon Feb 2 10:02:47 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 2 Feb 2026 10:02:47 GMT Subject: RFR: 8376115: G1: Convert G1CMRootRegions to use Atomic [v2] In-Reply-To: References:

Message-ID: On Sun, 1 Feb 2026 00:23:36 GMT, Kim Barrett wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * kbarrett review > > Still good. Thanks @kimbarrett @walulyai for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/29363#issuecomment-3834103665 From tschatzl at openjdk.org Mon Feb 2 10:02:48 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 2 Feb 2026 10:02:48 GMT Subject: Integrated: 8376115: G1: Convert G1CMRootRegions to use Atomic In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 15:00:17 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to convert `G1CMRootRegions` to use `Atomic`. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 5e248603 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/5e248603813a46221c97f1c05311b06f21387bd7 Stats: 23 lines in 2 files changed: 2 ins; 0 del; 21 mod 8376115: G1: Convert G1CMRootRegions to use Atomic Reviewed-by: kbarrett, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/29363 From tschatzl at openjdk.org Mon Feb 2 16:06:12 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 2 Feb 2026 16:06:12 GMT Subject: RFR: 8376666: Convert various BlockOffsetTables to use Atomic In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 09:22:07 GMT, Thomas Schatzl wrote: > Hi all, > > please review this conversion of the various block offset tables to use `Atomic`. Since they are very similar, and mostly changes from `uint8*` to `Atomic*` I merged the conversion together. > > It is not the goal to actually merge them into one class that all three collectors use. I filed https://bugs.openjdk.org/browse/JDK-8376667 though, not finding a pre-existing RFE. > > Testing: tier1-5, gha GHA issue is infra issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29482#issuecomment-3836113200 From tschatzl at openjdk.org Mon Feb 2 16:08:32 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 2 Feb 2026 16:08:32 GMT Subject: RFR: 8376410: G1: Task queue statistics not reset properly on mark abort Message-ID: <-UYpFztsGGQm6jVAXDuAcHO36Wrzjlyk7Hjq0Ns1laY=.eab92324-7cc0-4c7d-bed1-6642fa534232@github.com> Hi all, please review this change that makes sure that task queue stats are properly reset. Previously, if marking had been aborted (or restarted), there were leftovers in the statistics, which caused the assertion failure. The change not only fixes reset of the task queue stats, but also reset of the partial array splitter which suffers from the same issue. Testing: given test case not failing any more after 30mins (failed within a few iterations typically), GHA, tier1-5 Thanks, Thomas ------------- Commit messages: - 8376410 Changes: https://git.openjdk.org/jdk/pull/29524/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29524&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376410 Stats: 16 lines in 2 files changed: 9 ins; 5 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29524.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29524/head:pull/29524 PR: https://git.openjdk.org/jdk/pull/29524 From iwalulya at openjdk.org Mon Feb 2 16:51:39 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 2 Feb 2026 16:51:39 GMT Subject: RFR: 8376126: G1: Convert remaining volatiles in G1ConcurrentMark to Atomic [v4] In-Reply-To: <0ksKxc3kj_pqlRLKTKLNjqVBu-f9kz7HYwaqa7-wQIs=.4cc463ce-de77-4682-807c-66cf13612748@github.com> References: <0ksKxc3kj_pqlRLKTKLNjqVBu-f9kz7HYwaqa7-wQIs=.4cc463ce-de77-4682-807c-66cf13612748@github.com> Message-ID: On Wed, 28 Jan 2026 12:54:52 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please convert remaining volatile declarations in `G1ConcurrentMark` to use `Atomic`. These volatiles are used to indicate concurrent phased access (like changing the variable in thread A, then reading the variable in thread B while A is dormant, or only ever updating it in one direction) where concurrency safety is provided by barriers between these phases. But there are also other cases) >> >> The exception is `G1ConcurrentMark::_finger` that has apparently been overlooked in an earlier changes. >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * try to fix non-gcc build failures Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29368#pullrequestreview-3740705028 From tschatzl at openjdk.org Mon Feb 2 17:00:13 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 2 Feb 2026 17:00:13 GMT Subject: RFR: 8376126: G1: Convert remaining volatiles in G1ConcurrentMark to Atomic [v4] In-Reply-To: References: <0ksKxc3kj_pqlRLKTKLNjqVBu-f9kz7HYwaqa7-wQIs=.4cc463ce-de77-4682-807c-66cf13612748@github.com> Message-ID: On Mon, 2 Feb 2026 16:48:19 GMT, Ivan Walulya wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * try to fix non-gcc build failures > > Marked as reviewed by iwalulya (Reviewer). Thanks @walulyai @stefank @kimbarrett for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/29368#issuecomment-3836481160 From tschatzl at openjdk.org Mon Feb 2 17:00:16 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 2 Feb 2026 17:00:16 GMT Subject: Integrated: 8376126: G1: Convert remaining volatiles in G1ConcurrentMark to Atomic In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 16:36:08 GMT, Thomas Schatzl wrote: > Hi all, > > please convert remaining volatile declarations in `G1ConcurrentMark` to use `Atomic`. These volatiles are used to indicate concurrent phased access (like changing the variable in thread A, then reading the variable in thread B while A is dormant, or only ever updating it in one direction) where concurrency safety is provided by barriers between these phases. But there are also other cases) > > The exception is `G1ConcurrentMark::_finger` that has apparently been overlooked in an earlier changes. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: b6024988 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/b60249882cc511a7fc9cf9ae11e8beb1602ea10f Stats: 64 lines in 4 files changed: 10 ins; 0 del; 54 mod 8376126: G1: Convert remaining volatiles in G1ConcurrentMark to Atomic Reviewed-by: iwalulya, kbarrett, stefank ------------- PR: https://git.openjdk.org/jdk/pull/29368 From iwalulya at openjdk.org Mon Feb 2 17:18:45 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 2 Feb 2026 17:18:45 GMT Subject: RFR: 8376199: Convert CodeCacheUnloadingTask to use Atomic In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 13:58:05 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to convert usages of `AtomicAccess` to `Atomic` in the `CodeCacheUnloadingTask` class. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29418#pullrequestreview-3740848773 From iwalulya at openjdk.org Mon Feb 2 17:25:04 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 2 Feb 2026 17:25:04 GMT Subject: RFR: 8376328: Convert PLABStats to use Atomic In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 14:42:04 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to convert the `PLABStats` class to use `Atomic`. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29420#pullrequestreview-3740888152 From wkemper at openjdk.org Mon Feb 2 17:26:14 2026 From: wkemper at openjdk.org (William Kemper) Date: Mon, 2 Feb 2026 17:26:14 GMT Subject: RFR: 8376839: GenShen: Improve performance of evacuations into the old generation In-Reply-To: References:

Message-ID: On Sat, 31 Jan 2026 00:52:29 GMT, Kelvin Nilsen wrote: >> When GenShen evacuates an object into the old generation, it also dirties the card for that object and updates the offsets of the first and last object in the card. In many cases, the same card may dirtied repeatedly and the object starts updated unnecessarily. We can reduce the total amount of work by moving these operations into a separate phase of the cycle which allows them to be batched. > > src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 223: > >> 221: } >> 222: >> 223: current_card_index = object_card_index; > > IIUC, I believe current_card_index corresponds to previous_offset and previous_address in the next iteration of this loop. For clarity in naming of variables, would it make sense to call this "previous_card_index"? Yes, will do. > src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 234: > >> 232: >> 233: const oop obj = cast_to_oop(address); >> 234: address += obj->oop_iterate_size(&make_cards_dirty); > > It feels to me like this code will still redundantly mark a card dirty for as many objects as touch this card. Wouldn't it be faster to have a single call outside this loop to mark all cards dirty in the range from address to end? I tested that configuration, but the results may have been distorted by my instrumentation. I will rerun that comparison without so much instrumentation. > src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 238: > >> 236: >> 237: // Register the last object seen in this range. >> 238: set_last_start(current_card_index, previous_offset); > > It seems this statement should only be executed if previous_address != nullptr That is correct, will fix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29511#discussion_r2755450701 PR Review Comment: https://git.openjdk.org/jdk/pull/29511#discussion_r2755448659 PR Review Comment: https://git.openjdk.org/jdk/pull/29511#discussion_r2755451417 From wkemper at openjdk.org Mon Feb 2 17:31:38 2026 From: wkemper at openjdk.org (William Kemper) Date: Mon, 2 Feb 2026 17:31:38 GMT Subject: RFR: 8376839: GenShen: Improve performance of evacuations into the old generation In-Reply-To: References:

Message-ID: On Sat, 31 Jan 2026 01:22:43 GMT, Kelvin Nilsen wrote: >> When GenShen evacuates an object into the old generation, it also dirties the card for that object and updates the offsets of the first and last object in the card. In many cases, the same card may dirtied repeatedly and the object starts updated unnecessarily. We can reduce the total amount of work by moving these operations into a separate phase of the cycle which allows them to be batched. > > src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 41: > >> 39: ShenandoahScanRemembered* const _scanner; >> 40: >> 41: public: > > I had not initially appreciated that we are investing in more precise dirtying of cards as part of this PR. Please check my analysis of the tradeoffs here: > > Option 1 (as currently implemented): > 1. This will take longer to do entry_update_card_table() because we have to rescan every copied object. This rescanning may also result in increased contention for cache lines and memory bus with mutator threads during this phase. This also results in redundant dirtying of cards for any card that holds more than one "interesting pointer". > 2. The benefit of this option is that our subsequent scan-remembered pass will have less work to do because potentially fewer cards will need to be scanned. > > Option 2(blindly dirty the entire range of copied objects): > 1. This matches current implementation. The existing design is based on the idea that it is "overall" more efficient to scan this data once rather than twice. We'll scan the data once when we next scan remembered set. > 2. The scan-once benefit applies only to cards that are dirty. In option 1, we scan data corresponding to dirty cards twice. In option 2, we scan data corresponding to dirty cards once. Data corresponding to clean cards is scanned only once in either option, though the timing of when we scan that data is different. > > I'm wondering if we've done any experiment to evaluate the tradeoffs of these alternative approaches on various workloads? I ran these tests on an earlier iteration of the changes here. They showed the reduction in remembered set scan times was greater than the increase in the time to update the card table. I will re-run the tests with the current version of the code here. > src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 210: > >> 208: log_debug(gc, remset)("Update remembered set from " PTR_FORMAT ", to " PTR_FORMAT, p2i(start), p2i(end)); >> 209: >> 210: while (address < end) { > > I'm assuming there must be a preparatory pass over all cards to pre-initialize each one, denoting that each card does not hold the start of an object. Then, this loop changes that state only for the cards that do hold the start of an object. > > I haven't worked through the all the details, so my intuition may be wrong here. But it feels to me like we could skip the preparatory pass by making a small change to how this loop is structured. The following is my "first" impulse for how I would write this loop. I'm not sure it's better, but offer it for your consideration. > > next_relevant_object = address > For each card_index in the range: > if the next_relevant_object pertains to this card { > set_first_start(card_index, offset_in_card(next_relevant_object)) > while (next_relevant_object + next_relevant_object->size() < addr_for_card_index(card_index+1)) { > next_relevant_object += next_relevant_object->size(); > } > set_last_start(card_index, offset_in_card(next_relevant_object); > next_relevant_object += next_relevant_object->size(); > } else { > clear_card_status(card_index); // no objects start in this card's range > } Somewhat surprisingly, we clear the card table for old regions when they are initially allocated: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp#L1558. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29511#discussion_r2755470989 PR Review Comment: https://git.openjdk.org/jdk/pull/29511#discussion_r2755462158 From shade at openjdk.org Mon Feb 2 17:37:41 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 2 Feb 2026 17:37:41 GMT Subject: RFR: 8376969: Shenandoah: GC state getters should be inlineable Message-ID: <2aByvBR2EIBUPX9TMNhIeYWYEeANzDmRKuWdQx8WDic=.5524d6d2-77de-4ad7-95d3-f9753bc2e0ac@github.com> Noticed this when working on [JDK-8376749](https://bugs.openjdk.org/browse/JDK-8376749). Looks like some GC state checks we are using from the native barriers are not inlined into the fast-paths. This is very visible with smaller clones, for example. We should move GC state checks to appropriate .inline.hpp-s. Actually, I think these were inlineable before [JDK-8344055](https://bugs.openjdk.org/browse/JDK-8344055), so it is a minor regression in JDK 25. This PR does a pretty simple move, so I expect no semantics change. Additional testing: - [x] Eye-balling barrier profiles on targeted microbenchmarks - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/29526/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29526&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376969 Stats: 25 lines in 3 files changed: 11 ins; 12 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29526.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29526/head:pull/29526 PR: https://git.openjdk.org/jdk/pull/29526 From iwalulya at openjdk.org Mon Feb 2 17:43:31 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 2 Feb 2026 17:43:31 GMT Subject: RFR: 8376353: Parallel: Convert PSParallelCompact classes to use Atomic In-Reply-To: <-5nTZabTnBZ5xbkLyrYTPKb7qYHO5FFrnHCaWYHWGSI=.be644ab7-3373-4ab0-9549-29290a532bdb@github.com> References: <-5nTZabTnBZ5xbkLyrYTPKb7qYHO5FFrnHCaWYHWGSI=.be644ab7-3373-4ab0-9549-29290a532bdb@github.com> Message-ID: On Mon, 26 Jan 2026 16:58:25 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to convert `PSParallelCompact` to use `Atomic`. > > Testing: tier1-5,gha > > Thanks, > Thomas Note: These files seem to follow a different style guide. Example: `class SplitInfo {` then many of the constructors are `defaulted`, not clear if that is intentional. ------------- Marked as reviewed by iwalulya (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29425#pullrequestreview-3740974678 From shade at openjdk.org Mon Feb 2 17:44:38 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 2 Feb 2026 17:44:38 GMT Subject: RFR: 8376410: G1: Task queue statistics not reset properly on mark abort In-Reply-To: <-UYpFztsGGQm6jVAXDuAcHO36Wrzjlyk7Hjq0Ns1laY=.eab92324-7cc0-4c7d-bed1-6642fa534232@github.com> References: <-UYpFztsGGQm6jVAXDuAcHO36Wrzjlyk7Hjq0Ns1laY=.eab92324-7cc0-4c7d-bed1-6642fa534232@github.com> Message-ID: <7DJZXGel3CIdifAgyhpEacA9LQv_G05oWp2CxifQTnI=.9bb4d939-11ab-4413-9357-8df86599fc51@github.com> On Mon, 2 Feb 2026 13:55:21 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that makes sure that task queue stats are properly reset. Previously, if marking had been aborted (or restarted), there were leftovers in the statistics, which caused the assertion failure. > > The change not only fixes reset of the task queue stats, but also reset of the partial array splitter which suffers from the same issue. > > Testing: given test case not failing any more after 30mins (failed within a few iterations typically), GHA, tier1-5 > > Thanks, > Thomas Looks reasonable ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29524#pullrequestreview-3740979185 From shade at openjdk.org Mon Feb 2 18:14:57 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 2 Feb 2026 18:14:57 GMT Subject: RFR: 8376970: Shenandoah: Verifier should do basic verification before touching oops Message-ID: Noticed this when working on [JDK-8376749](https://bugs.openjdk.org/browse/JDK-8376749). When Verifier is about to fail on broken oop, it would decode the broken compressed pointer before doing any verification on it. So the end result is that we _at best_ catch the non-verbose assert in shared code in debug builds, or we crash the VM with opaque error in release builds, instead of rich Shenandoah verification failure. We need to tighten this up, so that Verifier does work properly in these conditions. Additional testing: - [x] Ad-hoc crashes now show proper diagnostics - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` ------------- Commit messages: - Also make sure the verificaion runs in release mode - Other paths too - Fix Changes: https://git.openjdk.org/jdk/pull/29527/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29527&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376970 Stats: 39 lines in 1 file changed: 27 ins; 5 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/29527.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29527/head:pull/29527 PR: https://git.openjdk.org/jdk/pull/29527 From wkemper at openjdk.org Mon Feb 2 18:30:10 2026 From: wkemper at openjdk.org (William Kemper) Date: Mon, 2 Feb 2026 18:30:10 GMT Subject: RFR: 8376969: Shenandoah: GC state getters should be inlineable In-Reply-To: <2aByvBR2EIBUPX9TMNhIeYWYEeANzDmRKuWdQx8WDic=.5524d6d2-77de-4ad7-95d3-f9753bc2e0ac@github.com> References: <2aByvBR2EIBUPX9TMNhIeYWYEeANzDmRKuWdQx8WDic=.5524d6d2-77de-4ad7-95d3-f9753bc2e0ac@github.com> Message-ID: On Mon, 2 Feb 2026 17:29:49 GMT, Aleksey Shipilev wrote: > Noticed this when working on [JDK-8376749](https://bugs.openjdk.org/browse/JDK-8376749). Looks like some GC state checks we are using from the native barriers are not inlined into the fast-paths. This is very visible with smaller clones, for example. We should move GC state checks to appropriate .inline.hpp-s. Actually, I think these were inlineable before [JDK-8344055](https://bugs.openjdk.org/browse/JDK-8344055), so it is a minor regression in JDK 25. > > This PR does a pretty simple move, so I expect no semantic change. > > Additional testing: > - [x] Eye-balling barrier profiles on targeted microbenchmarks > - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` Looks good to me. ------------- Marked as reviewed by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29526#pullrequestreview-3741199164 From wkemper at openjdk.org Mon Feb 2 18:36:35 2026 From: wkemper at openjdk.org (William Kemper) Date: Mon, 2 Feb 2026 18:36:35 GMT Subject: RFR: 8376970: Shenandoah: Verifier should do basic verification before touching oops In-Reply-To: References: Message-ID: On Mon, 2 Feb 2026 18:06:33 GMT, Aleksey Shipilev wrote: > Noticed this when working on [JDK-8376749](https://bugs.openjdk.org/browse/JDK-8376749). When Verifier is about to fail on broken oop, it would decode the broken compressed pointer before doing any verification on it. So the end result is that we _at best_ catch the non-verbose assert in shared code in debug builds, or we crash the VM with opaque error in release builds, instead of rich Shenandoah verification failure. > > We need to tighten this up, so that Verifier does work properly in these conditions. > > Additional testing: > - [x] Ad-hoc crashes now show proper diagnostics > - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` Looks good, thank you! ------------- Marked as reviewed by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29527#pullrequestreview-3741227348 From wkemper at openjdk.org Mon Feb 2 19:59:05 2026 From: wkemper at openjdk.org (William Kemper) Date: Mon, 2 Feb 2026 19:59:05 GMT Subject: RFR: 8314599: [GenShen] Couple adaptive tenuring and generation size budgeting [v14] In-Reply-To: References:

Message-ID: <3HLZm6atopwuoyqNfTD3klcS1wgz_gCJ4FuOeyxrD1Q=.13088047-4dce-49c1-9b6a-f7d51491871c@github.com> On Tue, 6 Jan 2026 23:18:02 GMT, William Kemper wrote: >> Notable changes: >> * Improvements to logging >> * More accurate tracking of promotion failures >> * Use shared allocation for promotions only when the size is above the maximum plab size (not the minimum size) >> * Use census information gathered during mark to size promotion reserves and old generation >> >> With these changes, GenShen is expected to have fewer promotion failures and this is indeed the case. As a result of this, we expect less time to be spent in concurrent marking and update refs for young collections. We may also expect shorter concurrent evacuation phases because GenShen will have fewer densely packed regions stuck in the young generation. With more objects being promoted, we also expect to see longer remembered set scan times. This is generally the case across all benchmarks, but we do also see some counter-intuitive results. >> >> Here we are comparing 20 executions (10 on x86, 10 on aarch64) of the changes in the PR (experiment) against 20 executions of the same benchmarks results from tip. This is a summary of statistically significant changes of more than 5% across all benchmarks: >> >> >> Concurrent Evacuation: 7 improvements, 3 regressions >> ? Best improvements: extremem-large-45g (-29.6%), neo4j-analytics (-26.9%) >> ? Worst regression: xalan (+53.7%) >> >> Concurrent Marking: 15 improvements, 1 regression >> ? Best improvements: hyperalloc_a2048_o4096 (-30.1%), crypto.rsa (-27.3%) >> ? Only regression: serial (+8.9%) >> >> Concurrent Scan Remembered Set: 7 improvements, 2 regressions >> ? Best improvements: xalan (-49.4%), pmd (-49.0%), crypto.rsa (-41.8%) >> ? Worst regression: extremem-phased (+52.4%) >> >> Concurrent Update Refs: 5 improvements, 4 regressions >> ? Best improvements: crypto.rsa (-36.4%), mnemonics (-28.4%) >> ? Worst regression: xalan (+89.4%) > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 81 commits: > > - Merge remote-tracking branch 'jdk/master' into promotion-budget-improvements > - Merge remote-tracking branch 'jdk/master' into promotion-budget-improvements > - Fix comments, add back an assertion > - Merge remote-tracking branch 'jdk/master' into promotion-budget-improvements > - Accommodate behavior of global heuristic > - Restore missing update for inplace promotion padding > - Remove reference to adaptive tuning flag > - Remove commented out assertion > - Merge remote-tracking branch 'jdk/master' into promotion-budget-improvements > - Adaptive tenuring is no longer optional > > We are using age census data to compute promotion reserves. The tenuring threshold may still be fixed by setting the min/max threshold to the same value. > - ... and 71 more: https://git.openjdk.org/jdk/compare/7c979c14...f460f115 This PR will need considerable rework after recent changes in mainline. I'm closing this PR and will follow up with others. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27632#issuecomment-3837259118 From wkemper at openjdk.org Mon Feb 2 19:59:06 2026 From: wkemper at openjdk.org (William Kemper) Date: Mon, 2 Feb 2026 19:59:06 GMT Subject: Withdrawn: 8314599: [GenShen] Couple adaptive tenuring and generation size budgeting In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 23:19:58 GMT, William Kemper wrote: > Notable changes: > * Improvements to logging > * More accurate tracking of promotion failures > * Use shared allocation for promotions only when the size is above the maximum plab size (not the minimum size) > * Use census information gathered during mark to size promotion reserves and old generation > > With these changes, GenShen is expected to have fewer promotion failures and this is indeed the case. As a result of this, we expect less time to be spent in concurrent marking and update refs for young collections. We may also expect shorter concurrent evacuation phases because GenShen will have fewer densely packed regions stuck in the young generation. With more objects being promoted, we also expect to see longer remembered set scan times. This is generally the case across all benchmarks, but we do also see some counter-intuitive results. > > Here we are comparing 20 executions (10 on x86, 10 on aarch64) of the changes in the PR (experiment) against 20 executions of the same benchmarks results from tip. This is a summary of statistically significant changes of more than 5% across all benchmarks: > > > Concurrent Evacuation: 7 improvements, 3 regressions > ? Best improvements: extremem-large-45g (-29.6%), neo4j-analytics (-26.9%) > ? Worst regression: xalan (+53.7%) > > Concurrent Marking: 15 improvements, 1 regression > ? Best improvements: hyperalloc_a2048_o4096 (-30.1%), crypto.rsa (-27.3%) > ? Only regression: serial (+8.9%) > > Concurrent Scan Remembered Set: 7 improvements, 2 regressions > ? Best improvements: xalan (-49.4%), pmd (-49.0%), crypto.rsa (-41.8%) > ? Worst regression: extremem-phased (+52.4%) > > Concurrent Update Refs: 5 improvements, 4 regressions > ? Best improvements: crypto.rsa (-36.4%), mnemonics (-28.4%) > ? Worst regression: xalan (+89.4%) This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27632 From kdnilsen at openjdk.org Mon Feb 2 21:47:23 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 2 Feb 2026 21:47:23 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v21] In-Reply-To: References: Message-ID: <5qi-C9Dr6BXFdxDtwpfEdB8DUfqDQ-p5ORn-NgOuZ1o=.e4c0d575-c4ea-46d6-9e6f-a4e5c7517685@github.com> > After studying large numbers of GC logs with degenerated cycles that have resulted from "late" triggers, we propose the following general improvements: > > 1. Track trends in GC times rather than always using the average GC time plus standard deviation. In many situations, GC times trend upward due to, for example, increasing amounts of live data that must be marked as a workload builds up its working set of memory. > 2. Sample allocation rates more frequently than once every 100 ms. > 3. Track trends in allocation rates. In some situations, the allocation rate trends upwards due to, for example, the start of a new phase of execution or a spike in client workload. > 4. When we detect acceleration of allocation rate, predict consumption of memory based on accelerated allocation rates rather than assuming constant allocation rate. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Remove debug instrumentation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29039/files - new: https://git.openjdk.org/jdk/pull/29039/files/26296f5d..edcde867 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=20 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=19-20 Stats: 197 lines in 1 file changed: 0 ins; 197 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29039.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29039/head:pull/29039 PR: https://git.openjdk.org/jdk/pull/29039 From dholmes at openjdk.org Mon Feb 2 22:18:16 2026 From: dholmes at openjdk.org (David Holmes) Date: Mon, 2 Feb 2026 22:18:16 GMT Subject: RFR: 8377000: [BACKOUT] JDK-8376126 G1: Convert remaining volatiles in G1ConcurrentMark to Atomic Message-ID: <5CGGZou08_G7sFJD43JtJWwHCDzgjxcHEQ3l2k7OKuE=.6836d4d4-3578-4ce0-b795-5928c19660c6@github.com> Revert "8376126: G1: Convert remaining volatiles in G1ConcurrentMark to Atomic" This reverts commit b60249882cc511a7fc9cf9ae11e8beb1602ea10f. Thanks ------------- Commit messages: - Revert "8376126: G1: Convert remaining volatiles in G1ConcurrentMark to Atomic" Changes: https://git.openjdk.org/jdk/pull/29535/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29535&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377000 Stats: 64 lines in 4 files changed: 0 ins; 10 del; 54 mod Patch: https://git.openjdk.org/jdk/pull/29535.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29535/head:pull/29535 PR: https://git.openjdk.org/jdk/pull/29535 From kvn at openjdk.org Mon Feb 2 22:28:42 2026 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 2 Feb 2026 22:28:42 GMT Subject: RFR: 8377000: [BACKOUT] JDK-8376126 G1: Convert remaining volatiles in G1ConcurrentMark to Atomic In-Reply-To: <5CGGZou08_G7sFJD43JtJWwHCDzgjxcHEQ3l2k7OKuE=.6836d4d4-3578-4ce0-b795-5928c19660c6@github.com> References: <5CGGZou08_G7sFJD43JtJWwHCDzgjxcHEQ3l2k7OKuE=.6836d4d4-3578-4ce0-b795-5928c19660c6@github.com> Message-ID: <_cUvAKgeKYuEwcQ_vMp17ubqv6n1k8qzBWNnliCFlPg=.439d3e35-f9e6-4584-bab2-61f753689fc6@github.com> On Mon, 2 Feb 2026 22:10:48 GMT, David Holmes wrote: > Revert "8376126: G1: Convert remaining volatiles in G1ConcurrentMark to Atomic" > > This reverts commit b60249882cc511a7fc9cf9ae11e8beb1602ea10f. > > Thanks trivial ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29535#pullrequestreview-3741894082 From dholmes at openjdk.org Mon Feb 2 22:32:27 2026 From: dholmes at openjdk.org (David Holmes) Date: Mon, 2 Feb 2026 22:32:27 GMT Subject: RFR: 8377000: [BACKOUT] JDK-8376126 G1: Convert remaining volatiles in G1ConcurrentMark to Atomic In-Reply-To: <_cUvAKgeKYuEwcQ_vMp17ubqv6n1k8qzBWNnliCFlPg=.439d3e35-f9e6-4584-bab2-61f753689fc6@github.com> References: <5CGGZou08_G7sFJD43JtJWwHCDzgjxcHEQ3l2k7OKuE=.6836d4d4-3578-4ce0-b795-5928c19660c6@github.com> <_cUvAKgeKYuEwcQ_vMp17ubqv6n1k8qzBWNnliCFlPg=.439d3e35-f9e6-4584-bab2-61f753689fc6@github.com> Message-ID: On Mon, 2 Feb 2026 22:25:52 GMT, Vladimir Kozlov wrote: >> Revert "8376126: G1: Convert remaining volatiles in G1ConcurrentMark to Atomic" >> >> This reverts commit b60249882cc511a7fc9cf9ae11e8beb1602ea10f. >> >> Thanks > > trivial Thanks @vnkozlov ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29535#issuecomment-3837634840 From dholmes at openjdk.org Mon Feb 2 22:32:29 2026 From: dholmes at openjdk.org (David Holmes) Date: Mon, 2 Feb 2026 22:32:29 GMT Subject: Integrated: 8377000: [BACKOUT] JDK-8376126 G1: Convert remaining volatiles in G1ConcurrentMark to Atomic In-Reply-To: <5CGGZou08_G7sFJD43JtJWwHCDzgjxcHEQ3l2k7OKuE=.6836d4d4-3578-4ce0-b795-5928c19660c6@github.com> References: <5CGGZou08_G7sFJD43JtJWwHCDzgjxcHEQ3l2k7OKuE=.6836d4d4-3578-4ce0-b795-5928c19660c6@github.com> Message-ID: On Mon, 2 Feb 2026 22:10:48 GMT, David Holmes wrote: > Revert "8376126: G1: Convert remaining volatiles in G1ConcurrentMark to Atomic" > > This reverts commit b60249882cc511a7fc9cf9ae11e8beb1602ea10f. > > Thanks This pull request has now been integrated. Changeset: 67079b18 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/67079b18afb4454fc849a35dd208ccf0b702339f Stats: 64 lines in 4 files changed: 0 ins; 10 del; 54 mod 8377000: [BACKOUT] JDK-8376126 G1: Convert remaining volatiles in G1ConcurrentMark to Atomic Reviewed-by: kvn ------------- PR: https://git.openjdk.org/jdk/pull/29535 From xpeng at openjdk.org Mon Feb 2 22:56:04 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 2 Feb 2026 22:56:04 GMT Subject: RFR: 8376969: Shenandoah: GC state getters should be inlineable In-Reply-To: <2aByvBR2EIBUPX9TMNhIeYWYEeANzDmRKuWdQx8WDic=.5524d6d2-77de-4ad7-95d3-f9753bc2e0ac@github.com> References: <2aByvBR2EIBUPX9TMNhIeYWYEeANzDmRKuWdQx8WDic=.5524d6d2-77de-4ad7-95d3-f9753bc2e0ac@github.com> Message-ID: <1ijpyw_aBXLeoPnsSir4YwtVrQr3PiYsIDLlN1Mrtg8=.673e187f-9b4d-4345-acf1-4219bc9db962@github.com> On Mon, 2 Feb 2026 17:29:49 GMT, Aleksey Shipilev wrote: > Noticed this when working on [JDK-8376749](https://bugs.openjdk.org/browse/JDK-8376749). Looks like some GC state checks we are using from the native barriers are not inlined into the fast-paths. This is very visible with smaller clones, for example. We should move GC state checks to appropriate .inline.hpp-s. Actually, I think these were inlineable before [JDK-8344055](https://bugs.openjdk.org/browse/JDK-8344055), so it is a minor regression in JDK 25. > > This PR does a pretty simple move, so I expect no semantic change. > > Additional testing: > - [x] Eye-balling barrier profiles on targeted microbenchmarks > - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` It looks good to me. I did test in gitfarm pipeline few months ago for the same change, but left it behind since I didn't see significant difference in the result, but it is still good to inline these two functions. ------------- Marked as reviewed by xpeng (Committer). PR Review: https://git.openjdk.org/jdk/pull/29526#pullrequestreview-3741970401 From xpeng at openjdk.org Mon Feb 2 22:59:44 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 2 Feb 2026 22:59:44 GMT Subject: RFR: 8376970: Shenandoah: Verifier should do basic verification before touching oops In-Reply-To: References: Message-ID: On Mon, 2 Feb 2026 18:06:33 GMT, Aleksey Shipilev wrote: > Noticed this when working on [JDK-8376749](https://bugs.openjdk.org/browse/JDK-8376749). When Verifier is about to fail on broken oop, it would decode the broken compressed pointer before doing any verification on it. So the end result is that we _at best_ catch the non-verbose assert in shared code in debug builds, or we crash the VM with opaque error in release builds, instead of rich Shenandoah verification failure. > > We need to tighten this up, so that Verifier does work properly in these conditions. > > Additional testing: > - [x] Ad-hoc crashes now show proper diagnostics > - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` LGTM, thanks! ------------- Marked as reviewed by xpeng (Committer). PR Review: https://git.openjdk.org/jdk/pull/29527#pullrequestreview-3741982329 From kdnilsen at openjdk.org Tue Feb 3 00:29:52 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 3 Feb 2026 00:29:52 GMT Subject: RFR: 8376969: Shenandoah: GC state getters should be inlineable In-Reply-To: <2aByvBR2EIBUPX9TMNhIeYWYEeANzDmRKuWdQx8WDic=.5524d6d2-77de-4ad7-95d3-f9753bc2e0ac@github.com> References: <2aByvBR2EIBUPX9TMNhIeYWYEeANzDmRKuWdQx8WDic=.5524d6d2-77de-4ad7-95d3-f9753bc2e0ac@github.com> Message-ID: On Mon, 2 Feb 2026 17:29:49 GMT, Aleksey Shipilev wrote: > Noticed this when working on [JDK-8376749](https://bugs.openjdk.org/browse/JDK-8376749). Looks like some GC state checks we are using from the native barriers are not inlined into the fast-paths. This is very visible with smaller clones, for example. We should move GC state checks to appropriate .inline.hpp-s. Actually, I think these were inlineable before [JDK-8344055](https://bugs.openjdk.org/browse/JDK-8344055), so it is a minor regression in JDK 25. > > This PR does a pretty simple move, so I expect no semantic change. > > Additional testing: > - [x] Eye-balling barrier profiles on targeted microbenchmarks > - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` Thanks. ------------- Marked as reviewed by kdnilsen (Committer). PR Review: https://git.openjdk.org/jdk/pull/29526#pullrequestreview-3742208069 From kdnilsen at openjdk.org Tue Feb 3 00:35:24 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 3 Feb 2026 00:35:24 GMT Subject: RFR: 8376970: Shenandoah: Verifier should do basic verification before touching oops In-Reply-To: References: Message-ID: On Mon, 2 Feb 2026 18:06:33 GMT, Aleksey Shipilev wrote: > Noticed this when working on [JDK-8376749](https://bugs.openjdk.org/browse/JDK-8376749). When Verifier is about to fail on broken oop, it would decode the broken compressed pointer before doing any verification on it. So the end result is that we _at best_ catch the non-verbose assert in shared code in debug builds, or we crash the VM with opaque error in release builds, instead of rich Shenandoah verification failure. > > We need to tighten this up, so that Verifier does work properly in these conditions. > > Additional testing: > - [x] Ad-hoc crashes now show proper diagnostics > - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` Marked as reviewed by kdnilsen (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29527#pullrequestreview-3742224088 From xpeng at openjdk.org Tue Feb 3 00:44:06 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 3 Feb 2026 00:44:06 GMT Subject: RFR: 8377011: Shenandoah: assert_bounds should be only called when boundaries have changed Message-ID: <8ouDpZSQ5PMoSTH_nLgt9jTYHOBYrpDVGZ5O6uDjoE0=.7e1f8a47-2c28-4cd8-9b61-963bc57c7564@github.com> This fix the problem causing following 3 jtreg tests with tlab disabled to fail: gc/shenandoah/TestRetainObjects.java#no-tlab 8361099 generic-all gc/shenandoah/TestSieveObjects.java#no-tlab 8361099 generic-all gc/shenandoah/TestSieveObjects.java#no-tlab-genshen 8361099 generic-all The problem is assert_bounds is always called from function ShenandoahFreeSet::try_allocate_in, no matter the boundaries have changed or not after the allocation, this is new behavior introduced by https://bugs.openjdk.org/browse/JDK-8365880, before which assert_bounds was only called after retiring a region. The fix is to call assert_bounds only when boundaries have changed: 1. When retire a region; 2. When a the object is allocated in a new region - one region became non-empty. There is also minor improvement to the if-else code in the PR. Overall the change should be safe and only affect Shenandoah related tests, I have run Shenandoah test suite on MacOS. Profiler data from the problematic jtreg test: [jtreg-gc_shenandoah_TestRetainObjects_no_tlab.html](https://github.com/user-attachments/files/25027324/jtreg-gc_shenandoah_TestRetainObjects_no_tlab.html) ### Tests - [x] hotspot_gc_shenandoah - [ ] GHA ------------- Commit messages: - assert_bounds should be only called when boundaries have changed Changes: https://git.openjdk.org/jdk/pull/29537/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29537&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377011 Stats: 20 lines in 2 files changed: 11 ins; 8 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29537.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29537/head:pull/29537 PR: https://git.openjdk.org/jdk/pull/29537 From iwalulya at openjdk.org Tue Feb 3 04:52:00 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 3 Feb 2026 04:52:00 GMT Subject: RFR: 8376410: G1: Task queue statistics not reset properly on mark abort In-Reply-To: <-UYpFztsGGQm6jVAXDuAcHO36Wrzjlyk7Hjq0Ns1laY=.eab92324-7cc0-4c7d-bed1-6642fa534232@github.com> References: <-UYpFztsGGQm6jVAXDuAcHO36Wrzjlyk7Hjq0Ns1laY=.eab92324-7cc0-4c7d-bed1-6642fa534232@github.com> Message-ID: On Mon, 2 Feb 2026 13:55:21 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that makes sure that task queue stats are properly reset. Previously, if marking had been aborted (or restarted), there were leftovers in the statistics, which caused the assertion failure. > > The change not only fixes reset of the task queue stats, but also reset of the partial array splitter which suffers from the same issue. > > Testing: given test case not failing any more after 30mins (failed within a few iterations typically), GHA, tier1-5 > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29524#pullrequestreview-3742930005 From aboldtch at openjdk.org Tue Feb 3 06:25:00 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 3 Feb 2026 06:25:00 GMT Subject: RFR: 8376491: ZGC: crash in __memset_evex_unaligned_erms when initializing heap using high values for -XX:ConcGCThreads In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 07:21:24 GMT, Guanqiang Han wrote: > Please review this change. Thanks! > > **Description:** > > This change fixes a crash during ZGC initialization when -XX:ConcGCThreads is set to an extremely large value. > ZThreadLocalAllocBuffer::initialize() creates a ZPerWorker, which uses ZValueStorage::alloc to allocate per-worker storage which size is related to ConcGCThreads > https://github.com/openjdk/jdk/blob/1161a640abe454b47de95ed73452a78535160deb/src/hotspot/share/gc/z/zThreadLocalAllocBuffer.cpp#L35-L38 > https://github.com/openjdk/jdk/blob/1161a640abe454b47de95ed73452a78535160deb/src/hotspot/share/gc/z/zValue.hpp#L111 > https://github.com/openjdk/jdk/blob/1161a640abe454b47de95ed73452a78535160deb/src/hotspot/share/gc/z/zValue.inline.hpp#L125-L127 > https://github.com/openjdk/jdk/blob/1161a640abe454b47de95ed73452a78535160deb/src/hotspot/share/gc/z/zValue.inline.hpp#L60-L61 > https://github.com/openjdk/jdk/blob/1161a640abe454b47de95ed73452a78535160deb/src/hotspot/share/gc/z/zValue.inline.hpp#L108-L110 > > For very large ConcGCThreads, the calculated block_size becomes huge and os::malloc() inside ZUtils::alloc_aligned_unfreeable() may fail. > https://github.com/openjdk/jdk/blob/1161a640abe454b47de95ed73452a78535160deb/src/hotspot/share/gc/z/zUtils.inline.hpp#L37-L42 > > The current code does not check the returned pointer and unconditionally aligns and memset()s it, which can lead to a segmentation fault. > > **Fix:** > > The fix adds a NULL check after os::malloc() and terminates the VM with a proper OutOfMemoryError message instead of crashing. > > **Test:** > > GHA Looks good. Exiting without a core file when we fail to allocated these data structures seems resonable. Not sure how valuable the regression test is. Maybe someone else has an opinion. test/hotspot/jtreg/gc/z/TestZValueStorageAlloc.java line 46: > 44: output.shouldNotContain("# A fatal error has been detected by the Java Runtime Environment"); > 45: } > 46: } Suggestion: } ------------- PR Review: https://git.openjdk.org/jdk/pull/29460#pullrequestreview-3743220397 PR Review Comment: https://git.openjdk.org/jdk/pull/29460#discussion_r2757404086 From stefank at openjdk.org Tue Feb 3 08:07:03 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 3 Feb 2026 08:07:03 GMT Subject: RFR: 8376491: ZGC: crash in __memset_evex_unaligned_erms when initializing heap using high values for -XX:ConcGCThreads In-Reply-To: References:

Message-ID: On Tue, 3 Feb 2026 06:22:51 GMT, Axel Boldt-Christmas wrote: >> Please review this change. Thanks! >> >> **Description:** >> >> This change fixes a crash during ZGC initialization when -XX:ConcGCThreads is set to an extremely large value. >> ZThreadLocalAllocBuffer::initialize() creates a ZPerWorker, which uses ZValueStorage::alloc to allocate per-worker storage which size is related to ConcGCThreads >> https://github.com/openjdk/jdk/blob/1161a640abe454b47de95ed73452a78535160deb/src/hotspot/share/gc/z/zThreadLocalAllocBuffer.cpp#L35-L38 >> https://github.com/openjdk/jdk/blob/1161a640abe454b47de95ed73452a78535160deb/src/hotspot/share/gc/z/zValue.hpp#L111 >> https://github.com/openjdk/jdk/blob/1161a640abe454b47de95ed73452a78535160deb/src/hotspot/share/gc/z/zValue.inline.hpp#L125-L127 >> https://github.com/openjdk/jdk/blob/1161a640abe454b47de95ed73452a78535160deb/src/hotspot/share/gc/z/zValue.inline.hpp#L60-L61 >> https://github.com/openjdk/jdk/blob/1161a640abe454b47de95ed73452a78535160deb/src/hotspot/share/gc/z/zValue.inline.hpp#L108-L110 >> >> For very large ConcGCThreads, the calculated block_size becomes huge and os::malloc() inside ZUtils::alloc_aligned_unfreeable() may fail. >> https://github.com/openjdk/jdk/blob/1161a640abe454b47de95ed73452a78535160deb/src/hotspot/share/gc/z/zUtils.inline.hpp#L37-L42 >> >> The current code does not check the returned pointer and unconditionally aligns and memset()s it, which can lead to a segmentation fault. >> >> **Fix:** >> >> The fix adds a NULL check after os::malloc() and terminates the VM with a proper OutOfMemoryError message instead of crashing. >> >> **Test:** >> >> GHA > > test/hotspot/jtreg/gc/z/TestZValueStorageAlloc.java line 46: > >> 44: output.shouldNotContain("# A fatal error has been detected by the Java Runtime Environment"); >> 45: } >> 46: } > > Suggestion: > > } That test took a very long time to run on my machines. If we want to integrate it we need to figure out a way so that it is not run in tier1. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29460#discussion_r2757752389 From shade at openjdk.org Tue Feb 3 08:43:52 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 3 Feb 2026 08:43:52 GMT Subject: RFR: 8376969: Shenandoah: GC state getters should be inlineable In-Reply-To: <2aByvBR2EIBUPX9TMNhIeYWYEeANzDmRKuWdQx8WDic=.5524d6d2-77de-4ad7-95d3-f9753bc2e0ac@github.com> References: <2aByvBR2EIBUPX9TMNhIeYWYEeANzDmRKuWdQx8WDic=.5524d6d2-77de-4ad7-95d3-f9753bc2e0ac@github.com> Message-ID: On Mon, 2 Feb 2026 17:29:49 GMT, Aleksey Shipilev wrote: > Noticed this when working on [JDK-8376749](https://bugs.openjdk.org/browse/JDK-8376749). Looks like some GC state checks we are using from the native barriers are not inlined into the fast-paths. This is very visible with smaller clones, for example. We should move GC state checks to appropriate .inline.hpp-s. Actually, I think these were inlineable before [JDK-8344055](https://bugs.openjdk.org/browse/JDK-8344055), so it is a minor regression in JDK 25. > > This PR does a pretty simple move, so I expect no semantic change. > > Additional testing: > - [x] Eye-balling barrier profiles on targeted microbenchmarks > - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` Thanks for reviews! I think all interested parties have replied, so I am integrating before 24 hours expire. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29526#issuecomment-3839906686 From shade at openjdk.org Tue Feb 3 08:45:10 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 3 Feb 2026 08:45:10 GMT Subject: RFR: 8376970: Shenandoah: Verifier should do basic verification before touching oops In-Reply-To: References: Message-ID: On Mon, 2 Feb 2026 18:06:33 GMT, Aleksey Shipilev wrote: > Noticed this when working on [JDK-8376749](https://bugs.openjdk.org/browse/JDK-8376749). When Verifier is about to fail on broken oop, it would decode the broken compressed pointer before doing any verification on it. So the end result is that we _at best_ catch the non-verbose assert in shared code in debug builds, or we crash the VM with opaque error in release builds, instead of rich Shenandoah verification failure. > > We need to tighten this up, so that Verifier does work properly in these conditions. > > Additional testing: > - [x] Ad-hoc crashes now show proper diagnostics > - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` Thanks for reviews! I think all interested parties have replied, so I am integrating before 24 hours expire. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29527#issuecomment-3839905109 From shade at openjdk.org Tue Feb 3 08:45:12 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 3 Feb 2026 08:45:12 GMT Subject: Integrated: 8376970: Shenandoah: Verifier should do basic verification before touching oops In-Reply-To: References: Message-ID: On Mon, 2 Feb 2026 18:06:33 GMT, Aleksey Shipilev wrote: > Noticed this when working on [JDK-8376749](https://bugs.openjdk.org/browse/JDK-8376749). When Verifier is about to fail on broken oop, it would decode the broken compressed pointer before doing any verification on it. So the end result is that we _at best_ catch the non-verbose assert in shared code in debug builds, or we crash the VM with opaque error in release builds, instead of rich Shenandoah verification failure. > > We need to tighten this up, so that Verifier does work properly in these conditions. > > Additional testing: > - [x] Ad-hoc crashes now show proper diagnostics > - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` This pull request has now been integrated. Changeset: 8e2bd92b Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/8e2bd92bacd6503346a48df236959c8a959c9c77 Stats: 39 lines in 1 file changed: 27 ins; 5 del; 7 mod 8376970: Shenandoah: Verifier should do basic verification before touching oops Reviewed-by: wkemper, xpeng, kdnilsen ------------- PR: https://git.openjdk.org/jdk/pull/29527 From shade at openjdk.org Tue Feb 3 08:47:12 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 3 Feb 2026 08:47:12 GMT Subject: Integrated: 8376969: Shenandoah: GC state getters should be inlineable In-Reply-To: <2aByvBR2EIBUPX9TMNhIeYWYEeANzDmRKuWdQx8WDic=.5524d6d2-77de-4ad7-95d3-f9753bc2e0ac@github.com> References: <2aByvBR2EIBUPX9TMNhIeYWYEeANzDmRKuWdQx8WDic=.5524d6d2-77de-4ad7-95d3-f9753bc2e0ac@github.com> Message-ID: On Mon, 2 Feb 2026 17:29:49 GMT, Aleksey Shipilev wrote: > Noticed this when working on [JDK-8376749](https://bugs.openjdk.org/browse/JDK-8376749). Looks like some GC state checks we are using from the native barriers are not inlined into the fast-paths. This is very visible with smaller clones, for example. We should move GC state checks to appropriate .inline.hpp-s. Actually, I think these were inlineable before [JDK-8344055](https://bugs.openjdk.org/browse/JDK-8344055), so it is a minor regression in JDK 25. > > This PR does a pretty simple move, so I expect no semantic change. > > Additional testing: > - [x] Eye-balling barrier profiles on targeted microbenchmarks > - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` This pull request has now been integrated. Changeset: 692444f0 Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/692444f071cab930d1b92bbfac79f87d0d801aab Stats: 25 lines in 3 files changed: 11 ins; 12 del; 2 mod 8376969: Shenandoah: GC state getters should be inlineable Reviewed-by: wkemper, xpeng, kdnilsen ------------- PR: https://git.openjdk.org/jdk/pull/29526 From stefank at openjdk.org Tue Feb 3 08:58:05 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 3 Feb 2026 08:58:05 GMT Subject: RFR: 8376761: ARM32: Constant base assert after JDK-8373266 In-Reply-To: References: Message-ID: On Mon, 2 Feb 2026 18:39:50 GMT, Aleksey Shipilev wrote: > Missed the obvious spot in [JDK-8373266](https://bugs.openjdk.org/browse/JDK-8373266). ARM32 uses this cached field for quick loads in CardTableBarrierSet barriers. This does not apply to Shenandoah and G1 barriers. So we only need to make sure card table is properly initialized to nullptr. > > Additional testing: > - [x] Linux ARM32 build now passes `java HelloWorld.java` Could you explain why this is needed? It looks like the old code already initialized _card_table_base in the else-branch: if (bs->is_a(BarrierSet::CardTableBarrierSet)) { CardTableBarrierSet* ctbs = CardTableBarrierSet::barrier_set(); _card_table_base = (address)ctbs->card_table_base_const(); } else { _card_table_base = nullptr; } Does G1 and Shenandoah answer `true` to the `bs->is_a(BarrierSet::CardTableBarrierSet)` check? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29528#issuecomment-3839974235 From shade at openjdk.org Tue Feb 3 09:07:18 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 3 Feb 2026 09:07:18 GMT Subject: RFR: 8376761: ARM32: Constant base assert after JDK-8373266 In-Reply-To: References:

Message-ID: On Tue, 3 Feb 2026 08:55:49 GMT, Stefan Karlsson wrote: > Does G1 and Shenandoah answer `true` to the `bs->is_a(BarrierSet::CardTableBarrierSet)` check? Yes, because they are having card tables. But in both G1 and Shenandoah the card table base is not constant, so stashing it somewhere is a programming error. You can ask for a card table base as long as you are sure it would not change, e.g. in error handler. Otherwise you are risking recording bad (stale) card table. That is why we did original: https://github.com/openjdk/jdk/commit/88c8a55a4337a857ac17ffff068f730f67cf5763 -- to capture the accesses where we assume the card table base is constant (notice `*_const` in getter name), while it is actually isn't. Exactly like this one. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29528#issuecomment-3840011675 From ghan at openjdk.org Tue Feb 3 11:52:27 2026 From: ghan at openjdk.org (Guanqiang Han) Date: Tue, 3 Feb 2026 11:52:27 GMT Subject: RFR: 8376491: ZGC: crash in __memset_evex_unaligned_erms when initializing heap using high values for -XX:ConcGCThreads In-Reply-To: References:

Message-ID: On Wed, 3 Dec 2025 16:11:14 GMT, Aleksey Shipilev wrote: >> Evgeny Astigeevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: >> >> - Fix linux-cross-compile build aarch64 >> - Merge branch 'master' into JDK-8370947 >> - Remove trailing whitespaces >> - Add support of deferred icache invalidation to other GCs and JIT >> - Add UseDeferredICacheInvalidation to defer invalidation on CPU with hardware cache coherence >> - Add jtreg test >> - Fix linux-cross-compile aarch64 build >> - Fix regressions for Java methods without field accesses >> - Fix code style >> - Correct ifdef; Add dsb after ic >> - ... and 9 more: https://git.openjdk.org/jdk/compare/3d54a802...4b04496f > > Interesting work! I was able to look through it very briefly: @shipilev @theRealAph @fisk Ping ------------- PR Comment: https://git.openjdk.org/jdk/pull/28328#issuecomment-3841835786 From xpeng at openjdk.org Tue Feb 3 16:59:49 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 3 Feb 2026 16:59:49 GMT Subject: RFR: 8377048: Shenandoah: shenandoahLock related improvments Message-ID: While I was working on https://bugs.openjdk.org/browse/JDK-8373371, I made these changes to the shenandoahLock, but I feel it make sense peel off these changes into a separate PR as they are not really related to JDK-8373371. Major thing in this PR is to use template for ShenandoahReentrantLock and ShenandoahLocker so we could get rid of duplicate code, along with some other changes where the locks are used e.g. use type alias for ShenandoahNMethodLock and ShenandoahNMethodLocker, use ShenandoahReentrantLock for ShenandoahRebuildLock. Another improvement is to strengthen assert in SheandnoahHeapLocker to avoid potential dead lock(this was also discussed in previous PR [here](https://github.com/openjdk/jdk/pull/27612#discussion_r2479898169) and our internal channel ### Test - [x] MacOS aach64, server fastdebug: hotspot_gc_shenandoah - [x] GHA ------------- Commit messages: - Merge branch 'openjdk:master' into shenandoah-heap-lock-asserts - Def type ShenandoahRebuildLock as ShenandoahReentrantLock - Revert name change of ShenandoahRebuildLock for the PR(it will be in next pr after this) - Rename ShenandoahRebuildLock to ShenandoahHeapUsageAccountingLock - Use ShenandoahReentrantLock as ShenandoahRebuildLock to simplify code - ShenandoahHeapLocker should assert if current thread is holding free-set rebuild lock - Use template to impl ShenandoahReentrantLock and ShenandoahLocker Changes: https://git.openjdk.org/jdk/pull/29543/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29543&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377048 Stats: 136 lines in 15 files changed: 38 ins; 34 del; 64 mod Patch: https://git.openjdk.org/jdk/pull/29543.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29543/head:pull/29543 PR: https://git.openjdk.org/jdk/pull/29543 From xpeng at openjdk.org Tue Feb 3 17:07:34 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 3 Feb 2026 17:07:34 GMT Subject: RFR: 8373468: Shenandoah: Mutator may block at _gc_waiters_lock after allocation failure even block parameter is false [v5] In-Reply-To: References: <62mzeOhRYpxYa0sNRcH2vs58S-jcGhv8gAqIx2R4L5M=.9914f2b4-4632-4f3c-ac05-0132b0d1370d@github.com> Message-ID: On Thu, 11 Dec 2025 18:56:15 GMT, Xiaolong Peng wrote: >> There is behavior discrepancy between Shenandoah generational mode and non-generational when it handles mutator allocation failure, as stated in the description of [JDK-8373468](https://bugs.openjdk.org/browse/JDK-8373468), in non-generational, the `block` parameter may not always work. >> >> Further looking into ShenandoahGenerationalControlThread and ShenandoahControlThread, they handle the _requested_gc_cause and ShenandoahHeap::cancelled_cause differently in other places as well, the change in this PR will minimize the gap to unify the behavior, and also fix potentially missed allocation failure notifications in some rare cases for both control threads. >> >> ### Test >> - [x] hotspot_gc_shenandoah >> - [x] GHA (includes tier1 but no unit unit with gtest) >> - [x] gtest > > Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: > > format issue Closing this PR as we may not want to change the behavior of classic Shenandoah as long as it is not broken. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28758#issuecomment-3842535770 From xpeng at openjdk.org Tue Feb 3 17:07:35 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 3 Feb 2026 17:07:35 GMT Subject: Withdrawn: 8373468: Shenandoah: Mutator may block at _gc_waiters_lock after allocation failure even block parameter is false In-Reply-To: <62mzeOhRYpxYa0sNRcH2vs58S-jcGhv8gAqIx2R4L5M=.9914f2b4-4632-4f3c-ac05-0132b0d1370d@github.com> References: <62mzeOhRYpxYa0sNRcH2vs58S-jcGhv8gAqIx2R4L5M=.9914f2b4-4632-4f3c-ac05-0132b0d1370d@github.com> Message-ID: On Thu, 11 Dec 2025 00:28:50 GMT, Xiaolong Peng wrote: > There is behavior discrepancy between Shenandoah generational mode and non-generational when it handles mutator allocation failure, as stated in the description of [JDK-8373468](https://bugs.openjdk.org/browse/JDK-8373468), in non-generational, the `block` parameter may not always work. > > Further looking into ShenandoahGenerationalControlThread and ShenandoahControlThread, they handle the _requested_gc_cause and ShenandoahHeap::cancelled_cause differently in other places as well, the change in this PR will minimize the gap to unify the behavior, and also fix potentially missed allocation failure notifications in some rare cases for both control threads. > > ### Test > - [x] hotspot_gc_shenandoah > - [x] GHA (includes tier1 but no unit unit with gtest) > - [x] gtest This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/28758 From kdnilsen at openjdk.org Tue Feb 3 17:56:33 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 3 Feb 2026 17:56:33 GMT Subject: RFR: 8377048: Shenandoah: shenandoahLock related improvments In-Reply-To: References: Message-ID: On Tue, 3 Feb 2026 09:54:44 GMT, Xiaolong Peng wrote: > While I was working on https://bugs.openjdk.org/browse/JDK-8373371, I made these changes to the shenandoahLock, but I feel it make sense peel off these changes into a separate PR as they are not really related to JDK-8373371. > > Major thing in this PR is to use template for ShenandoahReentrantLock and ShenandoahLocker so we could get rid of duplicate code, along with some other changes where the locks are used e.g. use type alias for ShenandoahNMethodLock and ShenandoahNMethodLocker, use ShenandoahReentrantLock for ShenandoahRebuildLock. > > Another improvement is to strengthen assert in SheandnoahHeapLocker to avoid potential dead lock(this was also discussed in previous PR [here](https://github.com/openjdk/jdk/pull/27612#discussion_r2479898169) and our internal channel > > ### Test > - [x] MacOS aach64, server fastdebug: hotspot_gc_shenandoah > - [x] GHA Thanks for submitting this PR. Please help motivate the changes in the intro to this PR. src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 912: > 910: void ShenandoahRegionPartitions::assert_bounds() { > 911: shenandoah_assert_heaplocked(); > 912: ShenandoahRebuildLocker locker(_free_set->rebuild_lock()); assert_bounds() often happens when we are not rebuilding the free set. Not clear why you need to add this lock here. src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 647: > 645: ShenandoahFreeSet(ShenandoahHeap* heap, size_t max_regions); > 646: > 647: ShenandoahRebuildLock* rebuild_lock() { unintentional spaces? src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 790: > 788: // inconsistent data: available may not equal capacity - used because the intermediate states of any "atomic" > 789: // locked action can be seen by these unlocked functions. > 790: inline size_t capacity_holding_lock() const { It looks like you're adding overhead to these calls here. Previously, we were able to ask for capacity() and used() and available() without needing to pay the cost of acquiring a lock. Now, we always have to acquire the lock(). Have you measured impact? src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2846: > 2844: } > 2845: > 2846: ShenandoahHeapLocker::ShenandoahHeapLocker(ShenandoahHeapLock* lock, bool allow_block_for_safepoint) : _lock(lock) { Can we have a comment to explain when lock will equal nullptr? src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2848: > 2846: ShenandoahHeapLocker::ShenandoahHeapLocker(ShenandoahHeapLock* lock, bool allow_block_for_safepoint) : _lock(lock) { > 2847: ShenandoahFreeSet* free_set = ShenandoahHeap::heap()->free_set(); > 2848: assert(free_set == nullptr || !free_set->rebuild_lock()->owned_by_self(), "Dead lock, can't acquire heap lock while holding free-set rebuild lock"); Can we add a comment to explain when free_set will equal nullptr? Does this correspond to "pre-initialized state" or something else? Would probably be more clear that we don't need to consult free_set unless asserts are enabled, so enclose this code in #ifdef ASSERT src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 121: > 119: > 120: typedef ShenandoahLock ShenandoahHeapLock; > 121: // ShenandoahHeapLocker checks potential deadlock and asserts Years from now, the reader of this comment will not "appreciate" the context in which it was written. The comment only makes sense in the context of this "diff". Would be better to say: ShenandoahHeapLocker implements a lock to assure mutually exclusive access to the global heap data structures. Asserts in the implementation detect potential deadlock usage with regards the rebuild lock that is present in ShenandoahFreeSet. Whenever both locks are acquired, this lock should be acquired before the ShenandoahFreeSet rebuild lock. ------------- Changes requested by kdnilsen (Committer). PR Review: https://git.openjdk.org/jdk/pull/29543#pullrequestreview-3746585690 PR Review Comment: https://git.openjdk.org/jdk/pull/29543#discussion_r2760187909 PR Review Comment: https://git.openjdk.org/jdk/pull/29543#discussion_r2760194774 PR Review Comment: https://git.openjdk.org/jdk/pull/29543#discussion_r2760206836 PR Review Comment: https://git.openjdk.org/jdk/pull/29543#discussion_r2760231347 PR Review Comment: https://git.openjdk.org/jdk/pull/29543#discussion_r2760229796 PR Review Comment: https://git.openjdk.org/jdk/pull/29543#discussion_r2760247618 From kdnilsen at openjdk.org Tue Feb 3 18:08:16 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 3 Feb 2026 18:08:16 GMT Subject: RFR: 8376839: GenShen: Improve performance of evacuations into the old generation In-Reply-To: References:

Message-ID: On Mon, 2 Feb 2026 17:26:10 GMT, William Kemper wrote: >> src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 210: >> >>> 208: log_debug(gc, remset)("Update remembered set from " PTR_FORMAT ", to " PTR_FORMAT, p2i(start), p2i(end)); >>> 209: >>> 210: while (address < end) { >> >> I'm assuming there must be a preparatory pass over all cards to pre-initialize each one, denoting that each card does not hold the start of an object. Then, this loop changes that state only for the cards that do hold the start of an object. >> >> I haven't worked through the all the details, so my intuition may be wrong here. But it feels to me like we could skip the preparatory pass by making a small change to how this loop is structured. The following is my "first" impulse for how I would write this loop. I'm not sure it's better, but offer it for your consideration. >> >> next_relevant_object = address >> For each card_index in the range: >> if the next_relevant_object pertains to this card { >> set_first_start(card_index, offset_in_card(next_relevant_object)) >> while (next_relevant_object + next_relevant_object->size() < addr_for_card_index(card_index+1)) { >> next_relevant_object += next_relevant_object->size(); >> } >> set_last_start(card_index, offset_in_card(next_relevant_object); >> next_relevant_object += next_relevant_object->size(); >> } else { >> clear_card_status(card_index); // no objects start in this card's range >> } > > Somewhat surprisingly, we clear the card table for old regions when they are initially allocated: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp#L1558. So that happens when region r is first put into action (having been initially empty). When we promote regions in place, it looks to me like we (currently) dirty up to top_before_promote, but we don't clean from top to end. Is this a bug? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29511#discussion_r2760330782 From kdnilsen at openjdk.org Tue Feb 3 18:08:17 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 3 Feb 2026 18:08:17 GMT Subject: RFR: 8376839: GenShen: Improve performance of evacuations into the old generation In-Reply-To: References:

Message-ID: On Tue, 3 Feb 2026 18:04:32 GMT, Kelvin Nilsen wrote: >> Somewhat surprisingly, we clear the card table for old regions when they are initially allocated: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp#L1558. > > So that happens when region r is first put into action (having been initially empty). When we promote regions in place, it looks to me like we (currently) dirty up to top_before_promote, but we don't clean from top to end. Is this a bug? (I guess the bug would be "harmless", in that it might result in some rescan of data that is not really dirty.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29511#discussion_r2760333702 From xpeng at openjdk.org Tue Feb 3 18:41:15 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 3 Feb 2026 18:41:15 GMT Subject: RFR: 8377048: Shenandoah: shenandoahLock related improvments In-Reply-To: References:

Message-ID: On Tue, 3 Feb 2026 17:28:14 GMT, Kelvin Nilsen wrote: >> While I was working on https://bugs.openjdk.org/browse/JDK-8373371, I made these changes to the shenandoahLock, but I feel it make sense peel off these changes into a separate PR as they are not really related to JDK-8373371. >> >> Major thing in this PR is to use template for ShenandoahReentrantLock and ShenandoahLocker so we could get rid of duplicate code, along with some other changes where the locks are used e.g. use type alias for ShenandoahNMethodLock and ShenandoahNMethodLocker, use ShenandoahReentrantLock for ShenandoahRebuildLock. >> >> Another improvement is to strengthen assert in SheandnoahHeapLocker to avoid potential dead lock(this was also discussed in previous PR [here](https://github.com/openjdk/jdk/pull/27612#discussion_r2479898169) and our internal channel >> >> ### Test >> - [x] MacOS aach64, server fastdebug: hotspot_gc_shenandoah >> - [x] GHA > > src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 912: > >> 910: void ShenandoahRegionPartitions::assert_bounds() { >> 911: shenandoah_assert_heaplocked(); >> 912: ShenandoahRebuildLocker locker(_free_set->rebuild_lock()); > > assert_bounds() often happens when we are not rebuilding the free set. Not clear why you need to add this lock here. For this change, it is not needed, I peel the PR from the change to defer heap usage accounting re-computation in which the same lock is used for when update&read heap usage accounting data, this one is untented, I'll remove it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29543#discussion_r2760474019 From xpeng at openjdk.org Tue Feb 3 18:51:04 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 3 Feb 2026 18:51:04 GMT Subject: RFR: 8377048: Shenandoah: shenandoahLock related improvments In-Reply-To: References:

Message-ID: On Tue, 3 Feb 2026 17:39:52 GMT, Kelvin Nilsen wrote: >> While I was working on https://bugs.openjdk.org/browse/JDK-8373371, I made these changes to the shenandoahLock, but I feel it make sense peel off these changes into a separate PR as they are not really related to JDK-8373371. >> >> Major thing in this PR is to use template for ShenandoahReentrantLock and ShenandoahLocker so we could get rid of duplicate code, along with some other changes where the locks are used e.g. use type alias for ShenandoahNMethodLock and ShenandoahNMethodLocker, use ShenandoahReentrantLock for ShenandoahRebuildLock. >> >> Another improvement is to strengthen assert in SheandnoahHeapLocker to avoid potential dead lock(this was also discussed in previous PR [here](https://github.com/openjdk/jdk/pull/27612#discussion_r2479898169) and our internal channel >> >> ### Test >> - [x] MacOS aach64, server fastdebug: hotspot_gc_shenandoah >> - [x] GHA > > src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2846: > >> 2844: } >> 2845: >> 2846: ShenandoahHeapLocker::ShenandoahHeapLocker(ShenandoahHeapLock* lock, bool allow_block_for_safepoint) : _lock(lock) { > > Can we have a comment to explain when lock will equal nullptr? Good catch. I think it is impossible to be nullprt. I copied the Locker impl from shenandoahLock.hpp which implies the lock could be nullptr, but I think we should assert non-null for all the Locker impls. > src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2848: > >> 2846: ShenandoahHeapLocker::ShenandoahHeapLocker(ShenandoahHeapLock* lock, bool allow_block_for_safepoint) : _lock(lock) { >> 2847: ShenandoahFreeSet* free_set = ShenandoahHeap::heap()->free_set(); >> 2848: assert(free_set == nullptr || !free_set->rebuild_lock()->owned_by_self(), "Dead lock, can't acquire heap lock while holding free-set rebuild lock"); > > Can we add a comment to explain when free_set will equal nullptr? Does this correspond to "pre-initialized state" or something else? > > Would probably be more clear that we don't need to consult free_set unless asserts are enabled, so enclose this code in #ifdef ASSERT Yes, it is related to initialization, and only happens in the "pre-initialized state", I'll add some comments for this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29543#discussion_r2760511873 PR Review Comment: https://git.openjdk.org/jdk/pull/29543#discussion_r2760517897 From wkemper at openjdk.org Tue Feb 3 18:52:12 2026 From: wkemper at openjdk.org (William Kemper) Date: Tue, 3 Feb 2026 18:52:12 GMT Subject: RFR: 8376839: GenShen: Improve performance of evacuations into the old generation In-Reply-To: References:

Message-ID: On Tue, 3 Feb 2026 18:05:20 GMT, Kelvin Nilsen wrote: >> So that happens when region r is first put into action (having been initially empty). When we promote regions in place, it looks to me like we (currently) dirty up to top_before_promote, but we don't clean from top to end. Is this a bug? > > (I guess the bug would be "harmless", in that it might result in some rescan of data that is not really dirty.) > When we promote regions in place, it looks to me like we (currently) dirty up to top_before_promote, but we don't clean from top to end. It could be? You are worried about invalid/stale object start registrations for the memory between `_top_before_promote` and `_end`? To me, it makes more intuitive sense to clear cards when a region is recycled. This would cover the case when a young region becomes old by way of in-place-promotions. What I think you're describing might not be harmless, it could cause invalid object registrations if the in-place-promoted region is used for subsequent evacuations to old. It could be rare because I think, generally, in-place-promoted regions have `_top == _end`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29511#discussion_r2760519944 From xpeng at openjdk.org Tue Feb 3 18:57:51 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 3 Feb 2026 18:57:51 GMT Subject: RFR: 8377048: Shenandoah: shenandoahLock related improvments In-Reply-To: References:

Message-ID: On Tue, 3 Feb 2026 17:43:56 GMT, Kelvin Nilsen wrote: >> While I was working on https://bugs.openjdk.org/browse/JDK-8373371, I made these changes to the shenandoahLock, but I feel it make sense peel off these changes into a separate PR as they are not really related to JDK-8373371. >> >> Major thing in this PR is to use template for ShenandoahReentrantLock and ShenandoahLocker so we could get rid of duplicate code, along with some other changes where the locks are used e.g. use type alias for ShenandoahNMethodLock and ShenandoahNMethodLocker, use ShenandoahReentrantLock for ShenandoahRebuildLock. >> >> Another improvement is to strengthen assert in SheandnoahHeapLocker to avoid potential dead lock(this was also discussed in previous PR [here](https://github.com/openjdk/jdk/pull/27612#discussion_r2479898169) and our internal channel >> >> ### Test >> - [x] MacOS aach64, server fastdebug: hotspot_gc_shenandoah >> - [x] GHA > > src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 121: > >> 119: >> 120: typedef ShenandoahLock ShenandoahHeapLock; >> 121: // ShenandoahHeapLocker checks potential deadlock and asserts > > Years from now, the reader of this comment will not "appreciate" the context in which it was written. The comment only makes sense in the context of this "diff". > > Would be better to say: ShenandoahHeapLocker implements a lock to assure mutually exclusive access to the global heap data structures. Asserts in the implementation detect potential deadlock usage with regards the rebuild lock that is present in ShenandoahFreeSet. Whenever both locks are acquired, this lock should be acquired before the ShenandoahFreeSet rebuild lock. Thanks, appreciate it! I'll update the comments here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29543#discussion_r2760537365 From xpeng at openjdk.org Tue Feb 3 21:26:08 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 3 Feb 2026 21:26:08 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v59] In-Reply-To: References: Message-ID: <9Q9sgr4WY1itebA0jJPIMQtDBCgEMxoBwJ-zLpr9RP0=.94de7762-dd7d-4022-b506-dd4f4538c2e1@github.com> > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of memory allocation to improve heap lock contention, along with the optimization, a better OOD is also done to Shenandoah memory allocation to reuse the majority of the code: > > * ShenandoahAllocator: base class of the allocators, most of the allocation code is in this class. > * ShenandoahMutatorAllocator: allocator for mutator, inherit from ShenandoahAllocator, only override methods `alloc_start_index`, `verify`, `_alloc_region_count` and `_yield_to_safepoint` to customize the allocator for mutator. > * ShenandoahCollectorAllocator: allocator for collector allocation in Collector partition, similar to ShenandoahMutatorAllocator, only few lines of code to customize the allocator for Collector. > * ShenandoahOldCollectorAllocator: allocator for mutator collector allocation in OldCollector partition, it doesn't inherit the logic from ShenandoahAllocator for now, the `allocate` method has been overridden to delegate to `FreeSet::allocate_for_collector` due to the special allocation considerations for `plab` in old gen. We will rewrite this part later and move the code out of `FreeSet::allocate_for_collector` > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, but in some cases it may improve the latency/performance: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores, p90 is improved from 500+us to less than 150us, p99 from 1000+us to ~200us. > > java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms31G -Xmx31G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > > > Openjdk TIP: > > ===== DaCapo tail latency, metered full smoothing: 50% 241098 usec, 90% 402356 usec, 99% 411065 usec, 99.9% 411763 usec, 99.99% 415531 usec, max 428584 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 902 usec, 90% 3713 usec, 99% 5898 usec, 99.9% 6488 usec, 99.99% 7081 usec, max 8048 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 2... Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 328 commits: - Merge branch 'master' into cas-alloc-1 - Add assert to functions new_top & set_new_top; fix typo - Update ProblemList to enable the tests affected by the change for accounting update - Fix crash after merging from tip(due to the new free-set rebuild calls) - Fix build error after merging tip - Merge branch 'master' into cas-alloc-1 - FullGC should not update accounting when release alloc regions - Not update accounting if no region is unretired to partition - Invoke assert_bounds after updating accounting from ShenandoahAllocator - Remove use AtomicAccess for _top if permits - ... and 318 more: https://git.openjdk.org/jdk/compare/efa16e9e...a5e38b0a ------------- Changes: https://git.openjdk.org/jdk/pull/26171/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=58 Stats: 1844 lines in 30 files changed: 1468 ins; 240 del; 136 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From xpeng at openjdk.org Tue Feb 3 23:35:15 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 3 Feb 2026 23:35:15 GMT Subject: RFR: 8377048: Shenandoah: shenandoahLock related improvments [v2] In-Reply-To: References: Message-ID: <9KS1Ric-CGdg0GgEVCFFNQ2B9lXJ8CW5caDnGR8ifxI=.13cff9eb-1024-4664-818d-de31cf4fb721@github.com> > While I was working on https://bugs.openjdk.org/browse/JDK-8373371, I made these changes to the shenandoahLock, but I feel it make sense peel off these changes into a separate PR as they are not really related to JDK-8373371. > > Major thing in this PR is to use template for ShenandoahReentrantLock and ShenandoahLocker so we could get rid of duplicate code, along with some other changes where the locks are used e.g. use type alias for ShenandoahNMethodLock and ShenandoahNMethodLocker, use ShenandoahReentrantLock for ShenandoahRebuildLock. > > Another improvement is to strengthen assert in SheandnoahHeapLocker to avoid potential dead lock(this was also discussed in previous PR [here](https://github.com/openjdk/jdk/pull/27612#discussion_r2479898169) and our internal channel > > ### Test > - [x] MacOS aach64, server fastdebug: hotspot_gc_shenandoah > - [x] GHA Xiaolong Peng has updated the pull request incrementally with three additional commits since the last revision: - Address review comments - Remove unintentional spaces - Remove unintended lock in ShenandoahRegionPartitions::assert_bounds ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29543/files - new: https://git.openjdk.org/jdk/pull/29543/files/44bdd69a..14cbd3ed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29543&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29543&range=00-01 Stats: 11 lines in 4 files changed: 7 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29543.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29543/head:pull/29543 PR: https://git.openjdk.org/jdk/pull/29543 From xpeng at openjdk.org Wed Feb 4 00:30:18 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 4 Feb 2026 00:30:18 GMT Subject: RFR: 8377011: Shenandoah: assert_bounds should be only called when boundaries have changed [v2] In-Reply-To: <8ouDpZSQ5PMoSTH_nLgt9jTYHOBYrpDVGZ5O6uDjoE0=.7e1f8a47-2c28-4cd8-9b61-963bc57c7564@github.com> References: <8ouDpZSQ5PMoSTH_nLgt9jTYHOBYrpDVGZ5O6uDjoE0=.7e1f8a47-2c28-4cd8-9b61-963bc57c7564@github.com> Message-ID: > This fix the problem causing following 3 jtreg tests with tlab disabled to fail: > > gc/shenandoah/TestRetainObjects.java#no-tlab 8361099 generic-all > gc/shenandoah/TestSieveObjects.java#no-tlab 8361099 generic-all > gc/shenandoah/TestSieveObjects.java#no-tlab-genshen 8361099 generic-all > > > > The problem is assert_bounds is always called from function ShenandoahFreeSet::try_allocate_in, no matter the boundaries have changed or not after the allocation, this is new behavior introduced by https://bugs.openjdk.org/browse/JDK-8365880, before which assert_bounds was only called after retiring a region. > > The fix is to call assert_bounds only when boundaries have changed: > 1. When retire a region; > 2. When a the object is allocated in a new region - one region became non-empty. > > There is also minor improvement to the if-else code in the PR. > > Overall the change should be safe and only affect Shenandoah related tests, I have run Shenandoah test suite on MacOS. > > Profiler data from the problematic jtreg test: [jtreg-gc_shenandoah_TestRetainObjects_no_tlab.html](https://github.com/user-attachments/files/25027324/jtreg-gc_shenandoah_TestRetainObjects_no_tlab.html) > > ### Tests > - [x] hotspot_gc_shenandoah > - [x] GHA Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Add assert_bounds_not_changed as Kelvin suggested ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29537/files - new: https://git.openjdk.org/jdk/pull/29537/files/c487fe96..ea68047f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29537&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29537&range=00-01 Stats: 22 lines in 2 files changed: 18 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29537.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29537/head:pull/29537 PR: https://git.openjdk.org/jdk/pull/29537 From kdnilsen at openjdk.org Wed Feb 4 00:30:40 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 4 Feb 2026 00:30:40 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v22] In-Reply-To: References: Message-ID: > After studying large numbers of GC logs with degenerated cycles that have resulted from "late" triggers, we propose the following general improvements: > > 1. Track trends in GC times rather than always using the average GC time plus standard deviation. In many situations, GC times trend upward due to, for example, increasing amounts of live data that must be marked as a workload builds up its working set of memory. > 2. Sample allocation rates more frequently than once every 100 ms. > 3. Track trends in allocation rates. In some situations, the allocation rate trends upwards due to, for example, the start of a new phase of execution or a spike in client workload. > 4. When we detect acceleration of allocation rate, predict consumption of memory based on accelerated allocation rates rather than assuming constant allocation rate. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Delay accelerated trigger until some garbage has accumulated ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29039/files - new: https://git.openjdk.org/jdk/pull/29039/files/edcde867..6d1adcac Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=21 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=20-21 Stats: 28 lines in 1 file changed: 16 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/29039.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29039/head:pull/29039 PR: https://git.openjdk.org/jdk/pull/29039 From xpeng at openjdk.org Wed Feb 4 00:31:09 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 4 Feb 2026 00:31:09 GMT Subject: RFR: 8377048: Shenandoah: shenandoahLock related improvments [v2] In-Reply-To: References:

Message-ID: On Tue, 3 Feb 2026 18:38:31 GMT, Xiaolong Peng wrote: >> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 912: >> >>> 910: void ShenandoahRegionPartitions::assert_bounds() { >>> 911: shenandoah_assert_heaplocked(); >>> 912: ShenandoahRebuildLocker locker(_free_set->rebuild_lock()); >> >> assert_bounds() often happens when we are not rebuilding the free set. Not clear why you need to add this lock here. > > For this change, it is not needed, I peel the PR from the change to defer heap usage accounting re-computation in which the same lock is used when update&read heap usage accounting data, this one is untented, I'll remove it. I have removed it from the PR, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29543#discussion_r2761624262 From xpeng at openjdk.org Wed Feb 4 00:31:12 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 4 Feb 2026 00:31:12 GMT Subject: RFR: 8377048: Shenandoah: shenandoahLock related improvments [v2] In-Reply-To: References:

Message-ID: On Tue, 3 Feb 2026 17:30:13 GMT, Kelvin Nilsen wrote: >> Xiaolong Peng has updated the pull request incrementally with three additional commits since the last revision: >> >> - Address review comments >> - Remove unintentional spaces >> - Remove unintended lock in ShenandoahRegionPartitions::assert_bounds > > src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 647: > >> 645: ShenandoahFreeSet(ShenandoahHeap* heap, size_t max_regions); >> 646: >> 647: ShenandoahRebuildLock* rebuild_lock() { > > unintentional spaces? Fixed, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29543#discussion_r2761623404 From xpeng at openjdk.org Wed Feb 4 00:58:58 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 4 Feb 2026 00:58:58 GMT Subject: RFR: 8377011: Shenandoah: assert_bounds should be only called when boundaries have changed [v3] In-Reply-To: <8ouDpZSQ5PMoSTH_nLgt9jTYHOBYrpDVGZ5O6uDjoE0=.7e1f8a47-2c28-4cd8-9b61-963bc57c7564@github.com> References: <8ouDpZSQ5PMoSTH_nLgt9jTYHOBYrpDVGZ5O6uDjoE0=.7e1f8a47-2c28-4cd8-9b61-963bc57c7564@github.com> Message-ID: > This fix the problem causing following 3 jtreg tests with tlab disabled to fail: > > gc/shenandoah/TestRetainObjects.java#no-tlab 8361099 generic-all > gc/shenandoah/TestSieveObjects.java#no-tlab 8361099 generic-all > gc/shenandoah/TestSieveObjects.java#no-tlab-genshen 8361099 generic-all > > > > The problem is assert_bounds is always called from function ShenandoahFreeSet::try_allocate_in, no matter the boundaries have changed or not after the allocation, this is new behavior introduced by https://bugs.openjdk.org/browse/JDK-8365880, before which assert_bounds was only called after retiring a region. > > The fix is to call assert_bounds only when boundaries have changed: > 1. When retire a region; > 2. When a the object is allocated in a new region - one region became non-empty. > > There is also minor improvement to the if-else code in the PR. > > Overall the change should be safe and only affect Shenandoah related tests, I have run Shenandoah test suite on MacOS. > > Profiler data from the problematic jtreg test: [jtreg-gc_shenandoah_TestRetainObjects_no_tlab.html](https://github.com/user-attachments/files/25027324/jtreg-gc_shenandoah_TestRetainObjects_no_tlab.html) > > ### Tests > - [x] hotspot_gc_shenandoah > - [x] GHA Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: code format ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29537/files - new: https://git.openjdk.org/jdk/pull/29537/files/ea68047f..4339e8c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29537&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29537&range=01-02 Stats: 10 lines in 1 file changed: 4 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/29537.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29537/head:pull/29537 PR: https://git.openjdk.org/jdk/pull/29537 From wkemper at openjdk.org Wed Feb 4 00:59:55 2026 From: wkemper at openjdk.org (William Kemper) Date: Wed, 4 Feb 2026 00:59:55 GMT Subject: RFR: 8376839: GenShen: Improve performance of evacuations into the old generation [v2] In-Reply-To: References: Message-ID: > When GenShen evacuates an object into the old generation, it also dirties the card for that object and updates the offsets of the first and last object in the card. In many cases, the same card may dirtied repeatedly and the object starts updated unnecessarily. We can reduce the total amount of work by moving these operations into a separate phase of the cycle which allows them to be batched. William Kemper has updated the pull request incrementally with six additional commits since the last revision: - Search for interesting pointers in objects that span into the next card - Reset card table for old regions when they are recycled Instead of when they are allocated. This covers the case of in-place-promotions having potentially stale card table entries above top after being promoted. - Do not iterate objects on cards that are already dirty - Record top at evac start when in place promotion completes - Use better names for things - Record top at evac start when preparing for evacuation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29511/files - new: https://git.openjdk.org/jdk/pull/29511/files/d1456700..08bfab8b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29511&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29511&range=00-01 Stats: 41 lines in 8 files changed: 29 ins; 2 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/29511.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29511/head:pull/29511 PR: https://git.openjdk.org/jdk/pull/29511 From xpeng at openjdk.org Wed Feb 4 07:15:24 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 4 Feb 2026 07:15:24 GMT Subject: RFR: 8377048: Shenandoah: shenandoahLock related improvments [v3] In-Reply-To: References:

Message-ID: On Tue, 3 Feb 2026 18:46:37 GMT, Xiaolong Peng wrote: >> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2846: >> >>> 2844: } >>> 2845: >>> 2846: ShenandoahHeapLocker::ShenandoahHeapLocker(ShenandoahHeapLock* lock, bool allow_block_for_safepoint) : _lock(lock) { >> >> Can we have a comment to explain when lock will equal nullptr? > > Good catch. > I think it is impossible to be nullprt. I copied the Locker impl from shenandoahLock.hpp which implies the lock could be nullptr, but I think we should assert non-null for all the Locker impls. I have changed code to assert _lock != nullptr for both ShenandoahHeapLocker and the ShenandoahLocker in shenandoahLock.hpp. >> src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 121: >> >>> 119: >>> 120: typedef ShenandoahLock ShenandoahHeapLock; >>> 121: // ShenandoahHeapLocker checks potential deadlock and asserts >> >> Years from now, the reader of this comment will not "appreciate" the context in which it was written. The comment only makes sense in the context of this "diff". >> >> Would be better to say: ShenandoahHeapLocker implements a lock to assure mutually exclusive access to the global heap data structures. Asserts in the implementation detect potential deadlock usage with regards the rebuild lock that is present in ShenandoahFreeSet. Whenever both locks are acquired, this lock should be acquired before the ShenandoahFreeSet rebuild lock. > > Thanks, appreciate it! I'll update the comments here. Updated the comment as you suggested. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29543#discussion_r2762544296 PR Review Comment: https://git.openjdk.org/jdk/pull/29543#discussion_r2762539612 From xpeng at openjdk.org Wed Feb 4 07:15:22 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 4 Feb 2026 07:15:22 GMT Subject: RFR: 8377048: Shenandoah: shenandoahLock related improvments [v3] In-Reply-To: References: Message-ID: > While I was working on https://bugs.openjdk.org/browse/JDK-8373371, I made these changes to the shenandoahLock, but I feel it make sense peel off these changes into a separate PR as they are not really related to JDK-8373371. > > Major thing in this PR is to use template for ShenandoahReentrantLock and ShenandoahLocker so we could get rid of duplicate code, along with some other changes where the locks are used e.g. use type alias for ShenandoahNMethodLock and ShenandoahNMethodLocker, use ShenandoahReentrantLock for ShenandoahRebuildLock. > > Another improvement is to strengthen assert in SheandnoahHeapLocker to avoid potential dead lock(this was also discussed in previous PR [here](https://github.com/openjdk/jdk/pull/27612#discussion_r2479898169) and our internal channel > > ### Test > - [x] MacOS aach64, server fastdebug: hotspot_gc_shenandoah > - [x] GHA Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Locker class should assume that lock instance is never be nullptr ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29543/files - new: https://git.openjdk.org/jdk/pull/29543/files/14cbd3ed..af4cbe5c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29543&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29543&range=01-02 Stats: 12 lines in 3 files changed: 0 ins; 7 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/29543.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29543/head:pull/29543 PR: https://git.openjdk.org/jdk/pull/29543 From xpeng at openjdk.org Wed Feb 4 07:45:37 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 4 Feb 2026 07:45:37 GMT Subject: RFR: 8377048: Shenandoah: shenandoahLock related improvments [v3] In-Reply-To: References:

Message-ID: <9zecTWGyAX-5Cl1JvJBWu5Cl68dN-1oqx2FfDh1YVoA=.c20d02f5-7025-41cc-9d3a-40e94c63226e@github.com> On Tue, 3 Feb 2026 17:32:57 GMT, Kelvin Nilsen wrote: >> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Locker class should assume that lock instance is never be nullptr > > src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 790: > >> 788: // inconsistent data: available may not equal capacity - used because the intermediate states of any "atomic" >> 789: // locked action can be seen by these unlocked functions. >> 790: inline size_t capacity_holding_lock() const { > > It looks like you're adding overhead to these calls here. Previously, we were able to ask for capacity() and used() and available() without needing to pay the cost of acquiring a lock. Now, we always have to acquire the lock(). Have you measured impact? I didn't run test for it yet, but for non-debug build, the capacity/used/available are not frequently read, the overhead should have very minor impact(it may still compete with thread doing rebuild). In debug build, because of the asserts need to read the accountings much more often, it should have a small performance impact. The change is really about correctness, these filed may be be updated with rebuild lock being hold, but can be read w/o acquiring the rebuild lock, so a thread reading them w/o the rebuild lock may see stale value. As a part of the change of JDK-8373371, I am updating how the heap usage accountings are updated: 1. All changes to heap usage accountings must be done with holding heap lock and heap usage accounting lock(rebuild lock will be renamed to usage accounting lock), 2. All reads must be done under heap usage accounting lock, no need to hold heap lock. 3. Computation of total/young/old accountings will be done in the read path under heap usage accounting lock. Here are the examples of young_used(), old_used(), global_used() with deferred re-computation: // Return bytes used by young inline size_t young_used() { ShenandoahHeapUsageAccountingLocker locker(usage_accounting_lock()); return _partitions.used_by(ShenandoahFreeSetPartitionId::Mutator) + _partitions.used_by(ShenandoahFreeSetPartitionId::Collector); } // Return bytes used by old inline size_t old_used() { ShenandoahHeapUsageAccountingLocker locker(usage_accounting_lock()); return _partitions.used_by(ShenandoahFreeSetPartitionId::OldCollector); } // Return bytes used by global inline size_t global_used() { ShenandoahHeapUsageAccountingLocker locker(usage_accounting_lock()); return young_used() + old_used(); } ShenandoahHeapUsageAccountingLock is a reentrant lock, global_used acquires the lock first, so it will have stable snapshot of young_used and old old_used when it calculate the global_used. Reentrance of the ShenandoahHeapUsageAccountingLock is very cheap since the current thread already holds it, it just checks the owner of the lock and increase the counter. I have pushed this change to gitfarm pipeline, I'm not really expecting any performance regression form this, I'll check the result tomorrow. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29543#discussion_r2762629599 From ayang at openjdk.org Wed Feb 4 07:49:12 2026 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 4 Feb 2026 07:49:12 GMT Subject: RFR: 8377141: G1: Remove unused local declaration in G1BarrierSetC2 Message-ID: Trivial removing dead code. Test: tier1 ------------- Commit messages: - g1-trivial-remove-local-var Changes: https://git.openjdk.org/jdk/pull/29561/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29561&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377141 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29561.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29561/head:pull/29561 PR: https://git.openjdk.org/jdk/pull/29561 From shade at openjdk.org Wed Feb 4 07:52:47 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 4 Feb 2026 07:52:47 GMT Subject: RFR: 8376761: ARM32: Constant base assert after JDK-8373266 In-Reply-To: References: Message-ID: <1M_v5TvlO_vCamgM6NOiEEk9Fi6Jjyl7P6ySr9Pt8So=.34b81e9f-82c2-486f-99d3-171e0c0dee25@github.com> On Mon, 2 Feb 2026 18:39:50 GMT, Aleksey Shipilev wrote: > Missed the obvious spot in [JDK-8373266](https://bugs.openjdk.org/browse/JDK-8373266). ARM32 uses this cached field for quick loads in CardTableBarrierSet barriers. This does not apply to Shenandoah and G1 barriers. So we only need to make sure card table is properly initialized to nullptr. > > Additional testing: > - [x] Linux ARM32 build now passes `java HelloWorld.java` Thanks Stefan! I need another Review before I can integrate. @tschatzl -- you were interested in this fix, I think :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/29528#issuecomment-3845875432 From ayang at openjdk.org Wed Feb 4 08:05:37 2026 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 4 Feb 2026 08:05:37 GMT Subject: RFR: 8376761: ARM32: Constant base assert after JDK-8373266 In-Reply-To: References: Message-ID: <3qMpMczy46cLl0788x9RH6nchRUxKQdo0iSbqH5oAJE=.516d280d-5990-4795-862b-f84a9a0b1f7b@github.com> On Mon, 2 Feb 2026 18:39:50 GMT, Aleksey Shipilev wrote: > Missed the obvious spot in [JDK-8373266](https://bugs.openjdk.org/browse/JDK-8373266). ARM32 uses this cached field for quick loads in CardTableBarrierSet barriers. This does not apply to Shenandoah and G1 barriers. So we only need to make sure card table is properly initialized to nullptr. > > Additional testing: > - [x] Linux ARM32 build now passes `java HelloWorld.java` Instead of relying on `bs->is_a`, I wonder whether the intention is more explicit if using `UseXGC`, sth like: // Some comment saying that only Serial/Parallel has constant card-table-base, etc. if (UseSerialGC || UseParallelGC) { _card_table_base = ... } else { _card_table_base = nullptr; } ------------- PR Review: https://git.openjdk.org/jdk/pull/29528#pullrequestreview-3749548941 From shade at openjdk.org Wed Feb 4 08:05:38 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 4 Feb 2026 08:05:38 GMT Subject: RFR: 8376761: ARM32: Constant base assert after JDK-8373266 In-Reply-To: <3qMpMczy46cLl0788x9RH6nchRUxKQdo0iSbqH5oAJE=.516d280d-5990-4795-862b-f84a9a0b1f7b@github.com> References: <3qMpMczy46cLl0788x9RH6nchRUxKQdo0iSbqH5oAJE=.516d280d-5990-4795-862b-f84a9a0b1f7b@github.com> Message-ID: On Wed, 4 Feb 2026 08:02:33 GMT, Albert Mingkun Yang wrote: > Instead of relying on `bs->is_a`, I wonder whether the intention is more explicit if using `UseXGC`, sth like: Maybe, but the current fix follows https://github.com/openjdk/jdk/commit/88c8a55a4337a857ac17ffff068f730f67cf5763 style. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29528#issuecomment-3845921452 From tschatzl at openjdk.org Wed Feb 4 08:11:02 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 4 Feb 2026 08:11:02 GMT Subject: RFR: 8377141: G1: Remove unused local declaration in G1BarrierSetC2 In-Reply-To: References: Message-ID: On Wed, 4 Feb 2026 07:37:21 GMT, Albert Mingkun Yang wrote: > Trivial removing dead code. > > Test: tier1 Trivial, but copyright update is missing. ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29561#pullrequestreview-3749567979 From ayang at openjdk.org Wed Feb 4 08:15:57 2026 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 4 Feb 2026 08:15:57 GMT Subject: RFR: 8377141: G1: Remove unused local declaration in G1BarrierSetC2 [v2] In-Reply-To: References: Message-ID: <_VXEdaxQL-SDtgfYgtFIDgja7IEMrnUo5ilJlNrxl6s=.22b89b4e-5a7a-4a2e-9915-cdcd55bf0bc9@github.com> > Trivial removing dead code. > > Test: tier1 Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29561/files - new: https://git.openjdk.org/jdk/pull/29561/files/81319b57..0b074d3e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29561&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29561&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29561.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29561/head:pull/29561 PR: https://git.openjdk.org/jdk/pull/29561 From shade at openjdk.org Wed Feb 4 08:32:16 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 4 Feb 2026 08:32:16 GMT Subject: RFR: 8377141: G1: Remove unused local declaration in G1BarrierSetC2 [v2] In-Reply-To: <_VXEdaxQL-SDtgfYgtFIDgja7IEMrnUo5ilJlNrxl6s=.22b89b4e-5a7a-4a2e-9915-cdcd55bf0bc9@github.com> References: <_VXEdaxQL-SDtgfYgtFIDgja7IEMrnUo5ilJlNrxl6s=.22b89b4e-5a7a-4a2e-9915-cdcd55bf0bc9@github.com> Message-ID: On Wed, 4 Feb 2026 08:15:57 GMT, Albert Mingkun Yang wrote: >> Trivial removing dead code. >> >> Test: tier1 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > copyright Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29561#pullrequestreview-3749658092 From xpeng at openjdk.org Wed Feb 4 08:33:40 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 4 Feb 2026 08:33:40 GMT Subject: RFR: 8377048: Shenandoah: shenandoahLock related improvments [v3] In-Reply-To: References:

Message-ID: On Wed, 4 Feb 2026 07:15:22 GMT, Xiaolong Peng wrote: >> While I was working on https://bugs.openjdk.org/browse/JDK-8373371, I made these changes to the shenandoahLock, but I feel it make sense peel off these changes into a separate PR as they are not really related to JDK-8373371. >> >> Major thing in this PR is to use template for ShenandoahReentrantLock and ShenandoahLocker so we could get rid of duplicate code, along with some other changes where the locks are used e.g. use type alias for ShenandoahNMethodLock and ShenandoahNMethodLocker, use ShenandoahReentrantLock for ShenandoahRebuildLock. >> >> Another improvement is to strengthen assert in SheandnoahHeapLocker to avoid potential dead lock(this was also discussed in previous PR [here](https://github.com/openjdk/jdk/pull/27612#discussion_r2479898169) and our internal channel >> >> ### Test >> - [x] MacOS aach64, server fastdebug: hotspot_gc_shenandoah >> - [x] GHA > > Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: > > Locker class should assume that lock instance is never be nullptr src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 69: > 67: idx_t const _max; // The maximum number of heap regions > 68: size_t const _region_size_bytes; > 69: ShenandoahFreeSet* const _free_set; unintended change, will revert these lines. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29543#discussion_r2762799966 From ayang at openjdk.org Wed Feb 4 08:39:47 2026 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 4 Feb 2026 08:39:47 GMT Subject: RFR: 8376761: ARM32: Constant base assert after JDK-8373266 In-Reply-To: References: <3qMpMczy46cLl0788x9RH6nchRUxKQdo0iSbqH5oAJE=.516d280d-5990-4795-862b-f84a9a0b1f7b@github.com> Message-ID: On Wed, 4 Feb 2026 08:03:33 GMT, Aleksey Shipilev wrote: > Maybe, but the current fix follows https://github.com/openjdk/jdk/commit/88c8a55a4337a857ac17ffff068f730f67cf5763 style. Thanks for the link. I skimmed through it and found the following sites of that style: `disassembler.cpp`: I don't understand why can't all GCs use the same `card_table()->byte_map_base()` path to retrieve `card_table_base`. Is specializing the constant-card-table-base case just for perf purpose? (I tend to think it's written that way because card-table-base was always constant for `CardTableBarrierSet` from the start.) `jvmciCompilerToVMInit.cpp` probably don't need to use `bs->is_a` -- directly checking `UseXGC` is enough, which is more similar to the scenario here. Based on that, I am leaned towards not using `bs->is_a` in all those cases; just my 2c. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29528#issuecomment-3846075650 From stefank at openjdk.org Wed Feb 4 08:39:49 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 4 Feb 2026 08:39:49 GMT Subject: RFR: 8376761: ARM32: Constant base assert after JDK-8373266 In-Reply-To: References: Message-ID: On Mon, 2 Feb 2026 18:39:50 GMT, Aleksey Shipilev wrote: > Missed the obvious spot in [JDK-8373266](https://bugs.openjdk.org/browse/JDK-8373266). ARM32 uses this cached field for quick loads in CardTableBarrierSet barriers. This does not apply to Shenandoah and G1 barriers. So we only need to make sure card table is properly initialized to nullptr. > > Additional testing: > - [x] Linux ARM32 build now passes `java HelloWorld.java` > > Instead of relying on `bs->is_a`, I wonder whether the intention is more explicit if using `UseXGC`, sth like: > > Maybe, but the current fix follows [88c8a55](https://github.com/openjdk/jdk/commit/88c8a55a4337a857ac17ffff068f730f67cf5763) style. FWIW, I would have been less confused if the code was using "UseXGC". I didn't know that the FakeRTTI / is_a had support for answering true for multiple tags ------------- PR Comment: https://git.openjdk.org/jdk/pull/29528#issuecomment-3846081380 From ayang at openjdk.org Wed Feb 4 08:43:16 2026 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 4 Feb 2026 08:43:16 GMT Subject: RFR: 8374782: Parallel: Investigate removal of specialized objArray iteration code In-Reply-To: References: Message-ID: <4Wi37KBHk5HvwoG1TDLvkncuBtBVdawVu0kJ8QCLUMg=.df5f7492-7fd8-482a-b1da-fe29f29facae@github.com> On Thu, 29 Jan 2026 12:58:01 GMT, Ivan Walulya wrote: > Hi, > > Please review this change removes specialized local methods used to iterate over array slices in `PSPromotionManager`. Any performance differences between these methods and `objArrayOopDesc::oop_iterate_elements_range` are attributable to differences in inlining behavior. For this reason, `ALWAYSINLINE` is applied. Further investigation is ongoing to improve inlining of calls through `objArrayOopDesc::oop_iterate_elements_range`. > > Testing: Tier 1-3, perf testing with SPECjvm2008-XML.validation. I suggest renaming the title now that the investigation is complete; maybe just `Parallel: Remove specialized ...`. ------------- Marked as reviewed by ayang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29486#pullrequestreview-3749698825 From shade at openjdk.org Wed Feb 4 08:54:56 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 4 Feb 2026 08:54:56 GMT Subject: RFR: 8376761: ARM32: Constant base assert after JDK-8373266 In-Reply-To: References: Message-ID: <7kwRDf7utKePzyfksGZUIkg7ScJCD-IoIkbPcE0bNuM=.d8753d11-6434-41f8-953b-bee552e2edfc@github.com> On Mon, 2 Feb 2026 18:39:50 GMT, Aleksey Shipilev wrote: > Missed the obvious spot in [JDK-8373266](https://bugs.openjdk.org/browse/JDK-8373266). ARM32 uses this cached field for quick loads in CardTableBarrierSet barriers. This does not apply to Shenandoah and G1 barriers. So we only need to make sure card table is properly initialized to nullptr. > > Additional testing: > - [x] Linux ARM32 build now passes `java HelloWorld.java` Let's not spend too much time on this. If you want to change the style, then sure, we can do that as the followups. But this one is for unbreaking ARM32, and it stands to reason to follow the style of the original changeset. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29528#issuecomment-3846143038 From xpeng at openjdk.org Wed Feb 4 08:55:45 2026 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 4 Feb 2026 08:55:45 GMT Subject: RFR: 8377048: Shenandoah: shenandoahLock related improvments [v4] In-Reply-To: References: Message-ID: > While I was working on https://bugs.openjdk.org/browse/JDK-8373371, I made these changes to the shenandoahLock, but I feel it make sense peel off these changes into a separate PR as they are not really related to JDK-8373371. > > Major thing in this PR is to use template for ShenandoahReentrantLock and ShenandoahLocker so we could get rid of duplicate code, along with some other changes where the locks are used e.g. use type alias for ShenandoahNMethodLock and ShenandoahNMethodLocker, use ShenandoahReentrantLock for ShenandoahRebuildLock. > > Another improvement is to strengthen assert in SheandnoahHeapLocker to avoid potential dead lock(this was also discussed in previous PR [here](https://github.com/openjdk/jdk/pull/27612#discussion_r2479898169) and our internal channel > > ### Test > - [x] MacOS aach64, server fastdebug: hotspot_gc_shenandoah > - [x] GHA Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Revert unintended changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29543/files - new: https://git.openjdk.org/jdk/pull/29543/files/af4cbe5c..76a97f46 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29543&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29543&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29543.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29543/head:pull/29543 PR: https://git.openjdk.org/jdk/pull/29543 From ayang at openjdk.org Wed Feb 4 09:08:01 2026 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 4 Feb 2026 09:08:01 GMT Subject: RFR: 8376761: ARM32: Constant base assert after JDK-8373266 In-Reply-To: References: Message-ID: On Mon, 2 Feb 2026 18:39:50 GMT, Aleksey Shipilev wrote: > Missed the obvious spot in [JDK-8373266](https://bugs.openjdk.org/browse/JDK-8373266). ARM32 uses this cached field for quick loads in CardTableBarrierSet barriers. This does not apply to Shenandoah and G1 barriers. So we only need to make sure card table is properly initialized to nullptr. > > Additional testing: > - [x] Linux ARM32 build now passes `java HelloWorld.java` > Let's not spend too much time on this. If you want to change the style, then sure, we can do that as the followups... Sure. ------------- Marked as reviewed by ayang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29528#pullrequestreview-3749834351 From tschatzl at openjdk.org Wed Feb 4 09:35:38 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 4 Feb 2026 09:35:38 GMT Subject: RFR: 8376666: Convert G1BlockOffsetTable to use Atomic In-Reply-To: References: Message-ID: <9tBCyz_5ZpK5A_-oGzsfvCp9yUGb9piJMsw1aIMMabg=.8789b6d4-2b39-44e8-bf15-81ec5be3c8cd@github.com> On Thu, 29 Jan 2026 09:22:07 GMT, Thomas Schatzl wrote: > Hi all, > > please review this conversion of the G1 block offset table to use `Atomic`. > > Testing: tier1-5, gha Limited the change to G1. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29482#issuecomment-3846329186 From tschatzl at openjdk.org Wed Feb 4 09:35:37 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 4 Feb 2026 09:35:37 GMT Subject: RFR: 8376666: Convert G1BlockOffsetTable to use Atomic [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review this conversion of the G1 block offset table to use `Atomic`. > > Testing: tier1-5, gha Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - * only change G1 BOT for now - Merge branch 'master' into 8376666-convert-bot - 8376666 Hi all, please review this conversion of the various block offset tables to use `Atomic`. Since they are very similar, and mostly changes from `uint8*` to `Atomic*` I merged the conversion together. It is not the goal to actually merge them into one class that all three collectors use. Testing: tier1-5, gha ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29482/files - new: https://git.openjdk.org/jdk/pull/29482/files/cb652fe6..4d588b78 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29482&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29482&range=00-01 Stats: 45066 lines in 593 files changed: 20652 ins; 15837 del; 8577 mod Patch: https://git.openjdk.org/jdk/pull/29482.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29482/head:pull/29482 PR: https://git.openjdk.org/jdk/pull/29482 From iwalulya at openjdk.org Wed Feb 4 09:51:28 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 4 Feb 2026 09:51:28 GMT Subject: RFR: 8374782: Parallel: Remove specialized objArray iteration code In-Reply-To: <4Wi37KBHk5HvwoG1TDLvkncuBtBVdawVu0kJ8QCLUMg=.df5f7492-7fd8-482a-b1da-fe29f29facae@github.com> References: <4Wi37KBHk5HvwoG1TDLvkncuBtBVdawVu0kJ8QCLUMg=.df5f7492-7fd8-482a-b1da-fe29f29facae@github.com> Message-ID: <8rRwRZhZndc6FfIu9TYHF_vdmiwzqz0rXHdDn7odjxA=.e5c66773-1e85-46c1-b689-d0e1e219f79f@github.com> On Wed, 4 Feb 2026 08:40:07 GMT, Albert Mingkun Yang wrote: >> Hi, >> >> Please review this change removes specialized local methods used to iterate over array slices in `PSPromotionManager`. Any performance differences between these methods and `objArrayOopDesc::oop_iterate_elements_range` are attributable to differences in inlining behavior. For this reason, `ALWAYSINLINE` is applied. Further investigation is ongoing to improve inlining of calls through `objArrayOopDesc::oop_iterate_elements_range`. >> >> Testing: Tier 1-3, perf testing with SPECjvm2008-XML.validation. > > I suggest renaming the title now that the investigation is complete; maybe just `Parallel: Remove specialized ...`. Thanks @albertnetymk and @tschatzl for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29486#issuecomment-3846410781 From iwalulya at openjdk.org Wed Feb 4 09:54:57 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 4 Feb 2026 09:54:57 GMT Subject: Integrated: 8374782: Parallel: Remove specialized objArray iteration code In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 12:58:01 GMT, Ivan Walulya wrote: > Hi, > > Please review this change removes specialized local methods used to iterate over array slices in `PSPromotionManager`. Any performance differences between these methods and `objArrayOopDesc::oop_iterate_elements_range` are attributable to differences in inlining behavior. For this reason, `ALWAYSINLINE` is applied. Further investigation is ongoing to improve inlining of calls through `objArrayOopDesc::oop_iterate_elements_range`. > > Testing: Tier 1-3, perf testing with SPECjvm2008-XML.validation. This pull request has now been integrated. Changeset: 848171a6 Author: Ivan Walulya URL: https://git.openjdk.org/jdk/commit/848171a6ccc6c3610b8de0c871d0082204369bee Stats: 29 lines in 3 files changed: 2 ins; 17 del; 10 mod 8374782: Parallel: Remove specialized objArray iteration code Reviewed-by: tschatzl, ayang ------------- PR: https://git.openjdk.org/jdk/pull/29486 From tschatzl at openjdk.org Wed Feb 4 11:04:46 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 4 Feb 2026 11:04:46 GMT Subject: RFR: 8377141: G1: Remove unused local declaration in G1BarrierSetC2 [v2] In-Reply-To: <_VXEdaxQL-SDtgfYgtFIDgja7IEMrnUo5ilJlNrxl6s=.22b89b4e-5a7a-4a2e-9915-cdcd55bf0bc9@github.com> References: <_VXEdaxQL-SDtgfYgtFIDgja7IEMrnUo5ilJlNrxl6s=.22b89b4e-5a7a-4a2e-9915-cdcd55bf0bc9@github.com> Message-ID: On Wed, 4 Feb 2026 08:15:57 GMT, Albert Mingkun Yang wrote: >> Trivial removing dead code. >> >> Test: tier1 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > copyright Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29561#pullrequestreview-3750391524 From tschatzl at openjdk.org Wed Feb 4 11:05:45 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 4 Feb 2026 11:05:45 GMT Subject: RFR: 8376761: ARM32: Constant base assert after JDK-8373266 In-Reply-To: References: Message-ID: On Mon, 2 Feb 2026 18:39:50 GMT, Aleksey Shipilev wrote: > Missed the obvious spot in [JDK-8373266](https://bugs.openjdk.org/browse/JDK-8373266). ARM32 uses this cached field for quick loads in CardTableBarrierSet barriers. This does not apply to Shenandoah and G1 barriers. So we only need to make sure card table is properly initialized to nullptr. > > Additional testing: > - [x] Linux ARM32 build now passes `java HelloWorld.java` Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29528#pullrequestreview-3750394288 From shade at openjdk.org Wed Feb 4 11:57:35 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 4 Feb 2026 11:57:35 GMT Subject: RFR: 8376761: ARM32: Constant base assert after JDK-8373266 In-Reply-To: References: Message-ID: On Mon, 2 Feb 2026 18:39:50 GMT, Aleksey Shipilev wrote: > Missed the obvious spot in [JDK-8373266](https://bugs.openjdk.org/browse/JDK-8373266). ARM32 uses this cached field for quick loads in CardTableBarrierSet barriers. This does not apply to Shenandoah and G1 barriers. So we only need to make sure card table is properly initialized to nullptr. > > Additional testing: > - [x] Linux ARM32 build now passes `java HelloWorld.java` Thanks! Here goes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29528#issuecomment-3847001144 From shade at openjdk.org Wed Feb 4 11:57:37 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 4 Feb 2026 11:57:37 GMT Subject: Integrated: 8376761: ARM32: Constant base assert after JDK-8373266 In-Reply-To: References: Message-ID: On Mon, 2 Feb 2026 18:39:50 GMT, Aleksey Shipilev wrote: > Missed the obvious spot in [JDK-8373266](https://bugs.openjdk.org/browse/JDK-8373266). ARM32 uses this cached field for quick loads in CardTableBarrierSet barriers. This does not apply to Shenandoah and G1 barriers. So we only need to make sure card table is properly initialized to nullptr. > > Additional testing: > - [x] Linux ARM32 build now passes `java HelloWorld.java` This pull request has now been integrated. Changeset: a181dd09 Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/a181dd09bd7ba6b23bf34327aa2be61bb00768dd Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod 8376761: ARM32: Constant base assert after JDK-8373266 Reviewed-by: stefank, ayang, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/29528 From tschatzl at openjdk.org Wed Feb 4 12:16:49 2026 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 4 Feb 2026 12:16:49 GMT Subject: RFR: 8377161: G1: Remove unnecessary member G1FullGCScope::_g1h Message-ID: Hi all, please review this trivial change that inlines the `_g1h` member use in ?G1FullGCScope` to be allowed to remove it. Testing: gha Thanks, Thomas ------------- Commit messages: - 8377161 Changes: https://git.openjdk.org/jdk/pull/29566/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29566&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377161 Stats: 5 lines in 2 files changed: 0 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29566.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29566/head:pull/29566 PR: https://git.openjdk.org/jdk/pull/29566 From shade at openjdk.org Wed Feb 4 12:16:49 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 4 Feb 2026 12:16:49 GMT Subject: RFR: 8377161: G1: Remove unnecessary member G1FullGCScope::_g1h In-Reply-To: References: Message-ID: On Wed, 4 Feb 2026 12:06:14 GMT, Thomas Schatzl wrote: > Hi all, > > please review this trivial change that inlines the `_g1h` member use in ?G1FullGCScope` to be allowed to remove it. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29566#pullrequestreview-3750707964 From ayang at openjdk.org Wed Feb 4 13:01:11 2026 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 4 Feb 2026 13:01:11 GMT Subject: RFR: 8377141: G1: Remove unused local declaration in G1BarrierSetC2 [v2] In-Reply-To: <_VXEdaxQL-SDtgfYgtFIDgja7IEMrnUo5ilJlNrxl6s=.22b89b4e-5a7a-4a2e-9915-cdcd55bf0bc9@github.com> References: <_VXEdaxQL-SDtgfYgtFIDgja7IEMrnUo5ilJlNrxl6s=.22b89b4e-5a7a-4a2e-9915-cdcd55bf0bc9@github.com> Message-ID: <5g_ZTg2hnlCjtm1dzK2dzVuhH5vZt4MdOLXTEZJLX30=.b92cb938-0b6c-45f9-94aa-8becbc30947a@github.com> On Wed, 4 Feb 2026 08:15:57 GMT, Albert Mingkun Yang wrote: >> Trivial removing dead code. >> >> Test: tier1 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > copyright Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29561#issuecomment-3847300233 From ayang at openjdk.org Wed Feb 4 13:01:13 2026 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 4 Feb 2026 13:01:13 GMT Subject: Integrated: 8377141: G1: Remove unused local declaration in G1BarrierSetC2 In-Reply-To: References: Message-ID: On Wed, 4 Feb 2026 07:37:21 GMT, Albert Mingkun Yang wrote: > Trivial removing dead code. > > Test: tier1 This pull request has now been integrated. Changeset: 8ad91ac1 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/8ad91ac1109e76ee8485bf221adeac7e1751ef17 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod 8377141: G1: Remove unused local declaration in G1BarrierSetC2 Reviewed-by: tschatzl, shade ------------- PR: https://git.openjdk.org/jdk/pull/29561 From ayang at openjdk.org Wed Feb 4 13:01:57 2026 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 4 Feb 2026 13:01:57 GMT Subject: RFR: 8377161: G1: Remove unnecessary member G1FullGCScope::_g1h In-Reply-To: References: Message-ID: On Wed, 4 Feb 2026 12:06:14 GMT, Thomas Schatzl wrote: > Hi all, > > please review this trivial change that inlines the `_g1h` member use in `G1FullGCScope` to be allowed to remove it. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29566#pullrequestreview-3750925987 From iwalulya at openjdk.org Wed Feb 4 13:13:03 2026 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 4 Feb 2026 13:13:03 GMT Subject: RFR: 8376666: Convert G1BlockOffsetTable to use Atomic [v2] In-Reply-To: References:

Message-ID: On Wed, 4 Feb 2026 09:35:37 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this conversion of the G1 block offset table to use `Atomic`. >> >> Testing: tier1-5, gha > > Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - * only change G1 BOT for now > - Merge branch 'master' into 8376666-convert-bot > - 8376666 > > Hi all, > > please review this conversion of the various block offset tables to use `Atomic`. Since they are very similar, and mostly changes from `uint8*` to `Atomic*` I merged the conversion together. > > It is not the goal to actually merge them into one class that all three collectors use. > > Testing: tier1-5, gha Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29482#pullrequestreview-3750989248 From aph at openjdk.org Wed Feb 4 14:26:23 2026 From: aph at openjdk.org (Andrew Haley) Date: Wed, 4 Feb 2026 14:26:23 GMT Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact on GCs and JIT performance [v25] In-Reply-To: References:

Message-ID: On Thu, 15 Jan 2026 13:54:01 GMT, Evgeny Astigeevich wrote: >> Arm Neoverse N1 erratum 1542419: "The core might fetch a stale instruction from memory which violates the ordering of instruction fetches". It is fixed in Neoverse N1 r4p1. >> >> Neoverse-N1 implementations mitigate erratum 1542419 with a workaround: >> - Disable coherent icache. >> - Trap IC IVAU instructions. >> - Execute: >> - `tlbi vae3is, xzr` >> - `dsb sy` >> >> `tlbi vae3is, xzr` invalidates translations for all address spaces (global for address). It waits for all memory accesses using in-scope old translation information to complete before it is considered complete. >> >> As this workaround has significant overhead, Arm Neoverse N1 (MP050) Software Developer Errata Notice version 29.0 suggests: >> >> "Since one TLB inner-shareable invalidation is enough to avoid this erratum, the number of injected TLB invalidations should be minimized in the trap handler to mitigate the performance impact due to this workaround." >> >> This PR introduces a mechanism to defer instruction cache (ICache) invalidation for AArch64 to address the Arm Neoverse N1 erratum 1542419, which causes significant performance overhead if ICache invalidation is performed too frequently. The implementation includes detection of affected Neoverse N1 CPUs and automatic enabling of the workaround for relevant Neoverse N1 revisions. >> >> Changes include: >> >> * Added a new diagnostic AArch64 JVM flag `NeoverseN1Errata1542419` to enable or disable the workaround for the erratum. The flag is automatically enabled for Neoverse N1 CPUs prior to r4p1, as detected during VM initialization. >> * Added a new diagnostic JVM flag `UseDeferredICacheInvalidation` to enable or disable defered icache invalidation. The flag is automatically enabled for AArch64 if CPU supports hardware cache coherence. >> * Introduced the `ICacheInvalidationContext` class to manage deferred ICache invalidation, with platform-specific logic for AArch64. This context is used to batch ICache invalidations, reducing performance impact. >> * Provided a default (no-op) implementation for `DefaultICacheInvalidationContext` on platforms where the workaround is not needed, ensuring portability and minimal impact on other architectures. >> >> **Testing results: linux fastdebug build** >> - Neoverse-N1 (Graviton 2) >> - [x] tier1: passed >> - [x] tier2: passed >> - [x] tier3: passed >> - [x] tier4: 3 failures >> - `containers/docker/TestJcmdWithSideCar.java`: JDK-8341518 >> - `com/sun/nio/sctp/SctpChannel/CloseDe... > > Evgeny Astigeevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits: > > - Merge branch 'master' into JDK-8370947 > - Use SingleShotTime mode with multiple iterations for GCPatchingNmethodCost > - Fix macos and windows aarch64 debug builds > - Remove redundant code > - Merge branch 'master' into JDK-8370947 > - Fix linux-cross-compile riscv64 build > - Restore deleted comment > - Remove redundant blank line > - Remove redundant include > - Merge branch 'master' into JDK-8370947 > - ... and 26 more: https://git.openjdk.org/jdk/compare/78a106ff...b0ede0a8 What's the test plan for this? That is, how do we ensure the erratum-specific code path gets tested? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28328#issuecomment-3847761733 From kdnilsen at openjdk.org Wed Feb 4 14:41:22 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 4 Feb 2026 14:41:22 GMT Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers more timely [v23] In-Reply-To: References: Message-ID: > After studying large numbers of GC logs with degenerated cycles that have resulted from "late" triggers, we propose the following general improvements: > > 1. Track trends in GC times rather than always using the average GC time plus standard deviation. In many situations, GC times trend upward due to, for example, increasing amounts of live data that must be marked as a workload builds up its working set of memory. > 2. Sample allocation rates more frequently than once every 100 ms. > 3. Track trends in allocation rates. In some situations, the allocation rate trends upwards due to, for example, the start of a new phase of execution or a spike in client workload. > 4. When we detect acceleration of allocation rate, predict consumption of memory based on accelerated allocation rates rather than assuming constant allocation rate. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Make delay of acceleration trigger shorter ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29039/files - new: https://git.openjdk.org/jdk/pull/29039/files/6d1adcac..d5161df7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=22 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=21-22 Stats: 9 lines in 1 file changed: 1 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/29039.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29039/head:pull/29039 PR: https://git.openjdk.org/jdk/pull/29039 From shade at openjdk.org Wed Feb 4 17:11:31 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 4 Feb 2026 17:11:31 GMT Subject: RFR: 8376756: GenShen: Improve encapsulation of generational collection set choosing [v2] In-Reply-To: References:

Message-ID: On Fri, 30 Jan 2026 00:46:39 GMT, William Kemper wrote: >> Choosing the collection set for Shenandoah's generational mode is somewhat more complicated than the non-generational modes. The logic is spread out in unnatural places which compounds the complexity. This change was spun off from https://github.com/openjdk/jdk/pull/27632. There is more to come, but I'm breaking the changes up over several PRs to facilitate reviewing. >> >> Description of changes: >> >> The methods: >> * `ShGeneration::compute_evacuation_budgets` >> * `ShGeneration::select_aged_regions` >> * `ShGeneration::adjust_evacuation-budgets` >> >> Were all moved into `ShGenerationalHeuristics`. The signature of `ShHeuritics::choose_collection_set` is restored to return `void` instead of returning a `size_t` which represents the number of old regions to be added to top off the collection set. The one heuristic that returned a non-zero value for this (`ShYoungHeuristics`) now carries it in a member variable. >> >> Redundant keyword modifiers have been removed from the headers touched here. > > William Kemper has updated the pull request incrementally with one additional commit since the last revision: > > Fix zero build I assume the bulk of the move is mechanical and there are no substantial changes in the body of those bulk moves. src/hotspot/share/gc/shenandoah/heuristics/shenandoahCompactHeuristics.hpp line 40: > 38: bool should_start_gc() override; > 39: > 40: void choose_collection_set_from_regiondata(ShenandoahCollectionSet* cset, Argument list indenting is a bit off now. src/hotspot/share/gc/shenandoah/heuristics/shenandoahYoungHeuristics.hpp line 41: > 39: > 40: > 41: void choose_collection_set_from_regiondata(ShenandoahCollectionSet* cset, Same: argument indentation. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29496#pullrequestreview-3752239839 PR Review Comment: https://git.openjdk.org/jdk/pull/29496#discussion_r2765047521 PR Review Comment: https://git.openjdk.org/jdk/pull/29496#discussion_r2765053792 From kdnilsen at openjdk.org Wed Feb 4 17:18:36 2026 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 4 Feb 2026 17:18:36 GMT Subject: RFR: 8377180: Shenandoah: make escalation from degen to full more conservative Message-ID: This PR merges into Traditional Shenandoah an optimization that was applied to Generational Shenandoah in September 2025 and has proven itself effective in that context. The change is to not immediately escalate Degenerated GC to Full GC following "bad progress" by Degen GC. The most common reason for bad degenerated progress is that most of the potential garbage was created following the start of the concurrent GC cycle which degenerated. This "floating" garbage cannot be reclaimed by the degenerated cycle because of the SATB protocol. Pursuing at least one additional concurrent cycle, even if that subsequent concurrent GC, is usually a much better approach than forcing immediate escalation to Full GC. While escalation to full GC will resolve the out-of-memory condition, it imposes unnecessarily long stop-the-world pauses: Existing behavior not to scale: <--- Concurrent GC experiencesallocation failure --> <-- Degen STW pause with bad progress --> <-- Full GC --> [ STW pause is 100 ms degen + 3s full GC] ------------- Commit messages: - Delay escalation to full GC for traditional Shenandoah Changes: https://git.openjdk.org/jdk/pull/29574/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29574&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377180 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29574.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29574/head:pull/29574 PR: https://git.openjdk.org/jdk/pull/29574 From wkemper at openjdk.org Wed Feb 4 17:24:07 2026 From: wkemper at openjdk.org (William Kemper) Date: Wed, 4 Feb 2026 17:24:07 GMT Subject: RFR: 8376756: GenShen: Improve encapsulation of generational collection set choosing [v3] In-Reply-To: References: Message-ID: > Choosing the collection set for Shenandoah's generational mode is somewhat more complicated than the non-generational modes. The logic is spread out in unnatural places which compounds the complexity. This change was spun off from https://github.com/openjdk/jdk/pull/27632. There is more to come, but I'm breaking the changes up over several PRs to facilitate reviewing. > > Description of changes: > > The methods: > * `ShGeneration::compute_evacuation_budgets` > * `ShGeneration::select_aged_regions` > * `ShGeneration::adjust_evacuation-budgets` > > Were all moved into `ShGenerationalHeuristics`. The signature of `ShHeuritics::choose_collection_set` is restored to return `void` instead of returning a `size_t` which represents the number of old regions to be added to top off the collection set. The one heuristic that returned a non-zero value for this (`ShYoungHeuristics`) now carries it in a member variable. > > Redundant keyword modifiers have been removed from the headers touched here. William Kemper has updated the pull request incrementally with one additional commit since the last revision: Fix parameter indentation after signature change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29496/files - new: https://git.openjdk.org/jdk/pull/29496/files/cf28eff5..6b39a7b2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29496&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29496&range=01-02 Stats: 23 lines in 12 files changed: 0 ins; 0 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/29496.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29496/head:pull/29496 PR: https://git.openjdk.org/jdk/pull/29496 From wkemper at openjdk.org Wed Feb 4 17:31:30 2026 From: wkemper at openjdk.org (William Kemper) Date: Wed, 4 Feb 2026 17:31:30 GMT Subject: RFR: 8376756: GenShen: Improve encapsulation of generational collection set choosing [v2] In-Reply-To: