From shade at openjdk.org  Mon Feb  2 07:15:19 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Feb 2026 07:15:19 GMT
Subject: RFR: 8376472: Shenandoah: Assembler store barriers read
 destination memory despite the decorators [v2]
In-Reply-To: <vBLP5BzYVxowPzkbnUodw36aQC4B6wlMvfojaU0XTkk=.6086f9dd-4550-4728-a884-d40d2cee6fd2@github.com>
References: <rA2nRqQQDXRzbF0lgmMI444XJMCgZ9LvFzvm7EgxA38=.120616e9-825c-4648-8090-1703660289d3@github.com>
 <vBLP5BzYVxowPzkbnUodw36aQC4B6wlMvfojaU0XTkk=.6086f9dd-4550-4728-a884-d40d2cee6fd2@github.com>
Message-ID: <-XK_Jf4sJArKYhzJltTtV3CUe3k4iI1ZpVT4E5QaDbo=.52cd97d5-9d47-44bd-9618-01f10fb04ed9@github.com>

On Fri, 30 Jan 2026 10:16:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> The issue is really a correctness issue, and it readily manifests in Valhalla, which sometimes does the stores with `IS_DEST_UNINITIALIZED` set. Unfortunately, Shenandoah SATB barriers ignore this attribute, and attempt to read the memory at store address. At best it crashes the VM with the "oopness" asserts, at worst it feeds "garbage" pointers into SATB machinery, which then wrecks havoc on everything else.
>> 
>> We need to make sure store barriers are consistently checking these attributes. Unfortunately, that would mean doing the changes in arch-specific assembler code. 
>> 
>> This PR makes sure the ShenandoahBarrierSetAssembler store barriers are roughly in the same shape, and that they consult `ShenandoahBarrierSet::need_*_barrier` to make the proper decisions whether to use SATB/card barriers.
>> 
>> `hotspot_gc_shenandoah` is enough to sanity-check this patch, but I am also running `all` tests for extra safety.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>>  - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah`
>>  - [x] Linux x86_64 server fastdebug, `all` + `-XX:+UseShenandoahGC`
>>  - [x] Linux AArch64 server fastdebug, `all` + `-XX:+UseShenandoahGC`
>>  - [x] Linux {PPC64, RISC-V, S390X} server fastdebug, cross-compilation
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Missing return in PPC64 for non-reference stores
>  - Merge branch 'master' into JDK-8376472-shenandoah-store-barriers
>  - More polish
>  - RISC-V version
>  - More touchups, AArch64 version
>  - Store barrier cleanup

Let's go! Thanks for reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29444#issuecomment-3833369307

From shade at openjdk.org  Mon Feb  2 07:15:20 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Feb 2026 07:15:20 GMT
Subject: Integrated: 8376472: Shenandoah: Assembler store barriers read
 destination memory despite the decorators
In-Reply-To: <rA2nRqQQDXRzbF0lgmMI444XJMCgZ9LvFzvm7EgxA38=.120616e9-825c-4648-8090-1703660289d3@github.com>
References: <rA2nRqQQDXRzbF0lgmMI444XJMCgZ9LvFzvm7EgxA38=.120616e9-825c-4648-8090-1703660289d3@github.com>
Message-ID: <xpW6NpVdWSovUZ11tiHjg4nuN_Q689azaifAjgB3JEk=.798b9f97-03d6-4fa2-9afa-c5703fc643b1@github.com>

On Tue, 27 Jan 2026 10:47:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> The issue is really a correctness issue, and it readily manifests in Valhalla, which sometimes does the stores with `IS_DEST_UNINITIALIZED` set. Unfortunately, Shenandoah SATB barriers ignore this attribute, and attempt to read the memory at store address. At best it crashes the VM with the "oopness" asserts, at worst it feeds "garbage" pointers into SATB machinery, which then wrecks havoc on everything else.
> 
> We need to make sure store barriers are consistently checking these attributes. Unfortunately, that would mean doing the changes in arch-specific assembler code. 
> 
> This PR makes sure the ShenandoahBarrierSetAssembler store barriers are roughly in the same shape, and that they consult `ShenandoahBarrierSet::need_*_barrier` to make the proper decisions whether to use SATB/card barriers.
> 
> `hotspot_gc_shenandoah` is enough to sanity-check this patch, but I am also running `all` tests for extra safety.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux x86_64 server fastdebug, `all` + `-XX:+UseShenandoahGC`
>  - [x] Linux AArch64 server fastdebug, `all` + `-XX:+UseShenandoahGC`
>  - [x] Linux {PPC64, RISC-V, S390X} server fastdebug, cross-compilation

This pull request has now been integrated.

Changeset: f8b0ff26
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f8b0ff26c9e6643e96f06c18c509ddaf50326205
Stats:     270 lines in 10 files changed: 48 ins; 61 del; 161 mod

8376472: Shenandoah: Assembler store barriers read destination memory despite the decorators

Reviewed-by: mdoerr, wkemper

-------------

PR: https://git.openjdk.org/jdk/pull/29444

From amitkumar at openjdk.org  Mon Feb  2 09:53:00 2026
From: amitkumar at openjdk.org (Amit Kumar)
Date: Mon, 2 Feb 2026 09:53:00 GMT
Subject: RFR: 8373595: A new ObjectMonitorTable implementation
In-Reply-To: <NpCJRO5OePJjpy3I-x4DV3C-NipfM9fkC9UvEwso4kw=.7fb88fe9-15e6-458e-ae43-77b3db67886d@github.com>
References: <NpCJRO5OePJjpy3I-x4DV3C-NipfM9fkC9UvEwso4kw=.7fb88fe9-15e6-458e-ae43-77b3db67886d@github.com>
Message-ID: <AA1NpCFOALRmiLksNdGdtDhY4BwTppWlsyMz5kNyzHo=.366d1c25-386b-4232-8266-28ce68d53106@github.com>

On Fri, 23 Jan 2026 10:36:26 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Me and Anton Artemov (@toxaart) investigated a quite large regression that occurred in Pet Clinic that happened if you turned on Compact Object Headers. It was found that a large portion of that regression could be attributed to not finding the monitor in the Object Monitor Cache, and because we couldn't access the Object Monitor Table from C2 generated code, we often had to take the slow path.
> 
> By making the object monitor cache larger and make it use the object's hash value as a key, we managed to mitigate the regression.
> 
> Erik ?sterlund (@fisk) took that idea and elevated it to the next level, which means that he rewrote the object monitor table code so that we can now search for an object in the global object monitor table from C2 generated code. I.e. from `C2_MacroAssembler::fast_lock()`. As in my and Anton's version, the key is the hash value from the object.
> 
> Erik also provided new barrier code needed for ZGC for x86 and aarch64. Roman Kennke (@rkennke) provided the same for Shenandoah, also for x86 and aarch64.
> 
> We decided to keep the Object Monitor Cache, since we found that for most programs (but not Pet Clinic) the monitor you are looking for is likely found in the first positions of the cache (it's sorted in most recently used order). However we decresed the size from 8 to 2 elements.
> 
> After running extensive performance tests we can say that this has improved the performance in many of them, not only mitigated the regression in Pet Clinic.
> 
> Tests are running okay tier1-7 on supported platforms.
> 
> The rest of the platforms (`ppc`, `riscv` and `s390`) have been smoke tested using QEMU.
> I mainly used this test for smoke testing with QEMU: `-XX:+UnlockDiagnosticVMOptions -XX:+UseObjectMonitorTable ./test/hotspot/jtreg/runtime/Monitor/UseObjectMonitorTableTest.java `

src/hotspot/cpu/s390/macroAssembler_s390.cpp line 6397:

> 6395: 
> 6396:       // Get the hash code.
> 6397:       z_srlg(hash, hash, markWord::hash_shift);

the monitor you are looking for is likely found in the first positions of the cache (it's sorted in most recently used order).


Then would it be helpful to load the hash only just before extraction? If the `monitor_found` cases are frequent, the load would not be needed at all.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29383#discussion_r2753340056

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: <WkvotZc49SzL-mvw8hGGaztJ_Jl2vZV2rI1kee2FieY=.f936d1e8-716d-4ba3-b703-73f8a3ad6514@github.com>
References: <Z288PGqFBbtMZ27wlMUh8r2qtvMk3Y3ko5BsmQRXquE=.0ef90b86-53b6-431c-bf7f-7119ca943e8d@github.com>
 <WkvotZc49SzL-mvw8hGGaztJ_Jl2vZV2rI1kee2FieY=.f936d1e8-716d-4ba3-b703-73f8a3ad6514@github.com>
Message-ID: <LdhqDyYvUkIU0lv9GakYFY33xLaVAgqc1dl7Lde8MjA=.66f02c98-fdc5-42bd-a1a4-a89eab7104d3@github.com>

On Sat, 31 Jan 2026 00:52:29 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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: <WkvotZc49SzL-mvw8hGGaztJ_Jl2vZV2rI1kee2FieY=.f936d1e8-716d-4ba3-b703-73f8a3ad6514@github.com>
References: <Z288PGqFBbtMZ27wlMUh8r2qtvMk3Y3ko5BsmQRXquE=.0ef90b86-53b6-431c-bf7f-7119ca943e8d@github.com>
 <WkvotZc49SzL-mvw8hGGaztJ_Jl2vZV2rI1kee2FieY=.f936d1e8-716d-4ba3-b703-73f8a3ad6514@github.com>
Message-ID: <RA1TDb9UP2zDxJa_SHnVNuOeHg1FEGiwacfXLenlIWA=.8d589aed-8f8e-40bc-bd82-9bbceacafb63@github.com>

On Sat, 31 Jan 2026 01:22:43 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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 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: <QO39tBAUVePa4PSgGTx5dfU0QFWgBgEZzU9ZlaNwxEQ=.98fd427e-d2ba-4bee-a30b-31cfcbea2be8@github.com>

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: <L3DZwoLR_pWBB9eAafVbYrxM0w8h6lJ_anpyNtA2QC0=.5b27f9b5-d657-4cc3-b30f-3c748765f688@github.com>

On Mon, 2 Feb 2026 17:29:49 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <QO39tBAUVePa4PSgGTx5dfU0QFWgBgEZzU9ZlaNwxEQ=.98fd427e-d2ba-4bee-a30b-31cfcbea2be8@github.com>
References: <QO39tBAUVePa4PSgGTx5dfU0QFWgBgEZzU9ZlaNwxEQ=.98fd427e-d2ba-4bee-a30b-31cfcbea2be8@github.com>
Message-ID: <HZBINJRxUPsl58G35SJKYUQ60c_UFLO4kZUjnGn_VDk=.989c15a9-29e4-4a4a-9921-3654a21c1071@github.com>

On Mon, 2 Feb 2026 18:06:33 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <pLG9HbKwZjLXVEZF72rguqGNzo94Iu47OphhOLsd59I=.cb4ffbe0-db49-4b3f-9e0c-a90bf92d76e9@github.com>
References: <I5yN-P2pZOGGsr0BovMGkqF7tc39fEkAPpb_07sHmog=.616fd50b-1cf8-4820-8230-284e2433fd7b@github.com>
 <pLG9HbKwZjLXVEZF72rguqGNzo94Iu47OphhOLsd59I=.cb4ffbe0-db49-4b3f-9e0c-a90bf92d76e9@github.com>
Message-ID: <3HLZm6atopwuoyqNfTD3klcS1wgz_gCJ4FuOeyxrD1Q=.13088047-4dce-49c1-9b6a-f7d51491871c@github.com>

On Tue, 6 Jan 2026 23:18:02 GMT, William Kemper <wkemper at openjdk.org> 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: <I5yN-P2pZOGGsr0BovMGkqF7tc39fEkAPpb_07sHmog=.616fd50b-1cf8-4820-8230-284e2433fd7b@github.com>
References: <I5yN-P2pZOGGsr0BovMGkqF7tc39fEkAPpb_07sHmog=.616fd50b-1cf8-4820-8230-284e2433fd7b@github.com>
Message-ID: <KGDnIitV_AE7ZE48wLsGe3gEGLTyulhXc5_zPHJr750=.4213a54f-5d4a-4ca8-8ce8-7a17fb8b0cf0@github.com>

On Fri, 3 Oct 2025 23:19:58 GMT, William Kemper <wkemper at openjdk.org> 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: <AN1rtpFsazMdRtzTrcdFNqti6I-sVhnwTCzDH2gZJLQ=.84f227b4-849e-4728-9e1d-56c38d8c251d@github.com>
References: <AN1rtpFsazMdRtzTrcdFNqti6I-sVhnwTCzDH2gZJLQ=.84f227b4-849e-4728-9e1d-56c38d8c251d@github.com>
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 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 <shade at openjdk.org> 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: <QO39tBAUVePa4PSgGTx5dfU0QFWgBgEZzU9ZlaNwxEQ=.98fd427e-d2ba-4bee-a30b-31cfcbea2be8@github.com>
References: <QO39tBAUVePa4PSgGTx5dfU0QFWgBgEZzU9ZlaNwxEQ=.98fd427e-d2ba-4bee-a30b-31cfcbea2be8@github.com>
Message-ID: <hs6xD6i-27Idm7t57fD7UXRvOS70nvy6o5gMHBRMH5Q=.b646e5c3-f939-421f-914a-67f3573a6b6f@github.com>

On Mon, 2 Feb 2026 18:06:33 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <LpogWuVDC-57UEh6td7B3a21J91RLv6DVJDkzVNUjcs=.36d65a44-7ed5-4dcb-89cb-a97ca95e4c47@github.com>

On Mon, 2 Feb 2026 17:29:49 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <QO39tBAUVePa4PSgGTx5dfU0QFWgBgEZzU9ZlaNwxEQ=.98fd427e-d2ba-4bee-a30b-31cfcbea2be8@github.com>
References: <QO39tBAUVePa4PSgGTx5dfU0QFWgBgEZzU9ZlaNwxEQ=.98fd427e-d2ba-4bee-a30b-31cfcbea2be8@github.com>
Message-ID: <hkWlg3QFJmywMvBD0rFKDHICZ1tgrsgNVoApu-lvBxU=.c914b5f6-517f-43e4-a830-00205ecfe6a4@github.com>

On Mon, 2 Feb 2026 18:06:33 GMT, Aleksey Shipilev <shade at openjdk.org> 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 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: <RC-LJICdII0o6HS6uQQ1VR2l1DRjx9rKTubGE_ihqyc=.0c2cea3e-7f80-496f-9b91-5fdc49c2bb38@github.com>

On Mon, 2 Feb 2026 17:29:49 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <QO39tBAUVePa4PSgGTx5dfU0QFWgBgEZzU9ZlaNwxEQ=.98fd427e-d2ba-4bee-a30b-31cfcbea2be8@github.com>
References: <QO39tBAUVePa4PSgGTx5dfU0QFWgBgEZzU9ZlaNwxEQ=.98fd427e-d2ba-4bee-a30b-31cfcbea2be8@github.com>
Message-ID: <d0FlXuov1lSl44GdcIMBe7ZETwmVt1vChVVp-v2CXdc=.9480f87c-6c6b-4091-936f-e40dd9571386@github.com>

On Mon, 2 Feb 2026 18:06:33 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <QO39tBAUVePa4PSgGTx5dfU0QFWgBgEZzU9ZlaNwxEQ=.98fd427e-d2ba-4bee-a30b-31cfcbea2be8@github.com>
References: <QO39tBAUVePa4PSgGTx5dfU0QFWgBgEZzU9ZlaNwxEQ=.98fd427e-d2ba-4bee-a30b-31cfcbea2be8@github.com>
Message-ID: <TN5irjZByL9GMd_JvKBlQJf8kyKvvp2jyqtBSpnDENQ=.d3ab37d7-3da2-45f0-bcb8-eeea03428e7a@github.com>

On Mon, 2 Feb 2026 18:06:33 GMT, Aleksey Shipilev <shade at openjdk.org> 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 <shade at openjdk.org>
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: <mmpB8PwrXqyIIGT6cXJrE42ZxLBl3FkVy-pSQkI3oEw=.560d6a0a-b8c5-4761-b348-9f6fc1917684@github.com>

On Mon, 2 Feb 2026 17:29:49 GMT, Aleksey Shipilev <shade at openjdk.org> 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 <shade at openjdk.org>
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 duke at openjdk.org  Tue Feb  3 09:01:19 2026
From: duke at openjdk.org (Harshit470250)
Date: Tue, 3 Feb 2026 09:01:19 GMT
Subject: RFR: 8347396: Efficient TypeFunc creations [v6]
In-Reply-To: <VQs3SMtk1y6xTi8nCvTeWsTFfCQlTJtDdCGnfWQmRmw=.f3b33ba1-3efe-477b-b6d2-b43faae9ee2b@github.com>
References: <VQs3SMtk1y6xTi8nCvTeWsTFfCQlTJtDdCGnfWQmRmw=.f3b33ba1-3efe-477b-b6d2-b43faae9ee2b@github.com>
Message-ID: <H3R12cuDv6CYf9j7F4XJ1wxW0NAyFFz_9cSnV4Qe5Hs=.5640efc1-a3c3-491f-998a-374d80a7f48b@github.com>

> This PR do similar changes done by [JDK-8330851](https://bugs.openjdk.org/browse/JDK-8330851) on the GC TypeFunc creation as suggested by [JDK-8347396](https://bugs.openjdk.org/browse/JDK-8347396). As discussed in [https://github.com/openjdk/jdk/pull/21782#discussion_r1906535686,](https://github.com/openjdk/jdk/pull/21782#discussion_r1906535686) I have put guard on the shenandoah gc specific part of the code.

Harshit470250 has updated the pull request incrementally with four additional commits since the last revision:

 - remove import of barrierSetC2 from runtime
 - make shenandoah types private
 - move _clone_type_Type to BarrierSetC2
 - remove whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27279/files
  - new: https://git.openjdk.org/jdk/pull/27279/files/6a02f24e..a4302cba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27279&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27279&range=04-05

  Stats: 29 lines in 6 files changed: 14 ins; 10 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/27279.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27279/head:pull/27279

PR: https://git.openjdk.org/jdk/pull/27279

From eastigeevich at openjdk.org  Tue Feb  3 15:00:31 2026
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Tue, 3 Feb 2026 15:00:31 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v13]
In-Reply-To: <Kl5e4lLy09In3ii23YLueZVqzzzkBkZJLGAJb2k7Aio=.4347ba54-eb6b-4a9f-81e8-6db06a03824f@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
 <rtneArX_lMKv-UqOQNXv8DT_n8pY4UNn7nEE4FpKT4k=.ca641bc2-9d9a-4e0b-a329-da375913f5db@github.com>
 <Kl5e4lLy09In3ii23YLueZVqzzzkBkZJLGAJb2k7Aio=.4347ba54-eb6b-4a9f-81e8-6db06a03824f@github.com>
Message-ID: <t-svjgeZqUoc4MPTyi0IJCvh9FvMrKDvg3_2gr7Kqhs=.88410b5d-a649-4484-8fa0-ade68c981806@github.com>

On Wed, 3 Dec 2025 16:11:14 GMT, Aleksey Shipilev <shade at openjdk.org> 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: <gwhzNS34QKsFh_FAUeKUNm2AMuYNIq0lW7C5_rq8A6g=.79f550ba-0f3f-44e1-ba7b-8be3df425084@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

-------------

Commit messages:
 - Merge branch 'openjdk:master' into shenandoah-heap-lock-asserts
 - Def type ShenandoahRebuildLock as ShenandoahReentrantLock<ShenandoahLock>
 - Revert name change of ShenandoahRebuildLock for the PR(it will be in next pr after this)
 - Rename ShenandoahRebuildLock to ShenandoahHeapUsageAccountingLock
 - Use ShenandoahReentrantLock<ShenandoahLock> 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: <cVj6I5zHfpzK4LF8BQ0e6dh5V0vLI72ssWVIV_KF6zI=.98ac2e06-7752-4fc4-8feb-675b7783091e@github.com>
References: <62mzeOhRYpxYa0sNRcH2vs58S-jcGhv8gAqIx2R4L5M=.9914f2b4-4632-4f3c-ac05-0132b0d1370d@github.com>
 <cVj6I5zHfpzK4LF8BQ0e6dh5V0vLI72ssWVIV_KF6zI=.98ac2e06-7752-4fc4-8feb-675b7783091e@github.com>
Message-ID: <gwYgvn21MYwVsCeMa3dTcr6qjwZrJ8FzyGnVq-8XH6I=.8c3d75ee-d181-455d-bf3f-53e1e7c001d0@github.com>

On Thu, 11 Dec 2025 18:56:15 GMT, Xiaolong Peng <xpeng at openjdk.org> 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: <FGCslI4tLUcnfhZj3wuFsxxecxLjwyklrqyQjn5RslU=.9a456e2b-27f0-442c-a2f7-2c20ac5b2ed3@github.com>

On Thu, 11 Dec 2025 00:28:50 GMT, Xiaolong Peng <xpeng at openjdk.org> 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: <gwhzNS34QKsFh_FAUeKUNm2AMuYNIq0lW7C5_rq8A6g=.79f550ba-0f3f-44e1-ba7b-8be3df425084@github.com>
References: <gwhzNS34QKsFh_FAUeKUNm2AMuYNIq0lW7C5_rq8A6g=.79f550ba-0f3f-44e1-ba7b-8be3df425084@github.com>
Message-ID: <b8G5vI0cfXbe1SeSnAZELmqbwKPYvSdZ9KgG1KkJtxE=.7010ae7b-2dda-4768-9a54-34c922e50e41@github.com>

On Tue, 3 Feb 2026 09:54:44 GMT, Xiaolong Peng <xpeng at openjdk.org> 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: <RA1TDb9UP2zDxJa_SHnVNuOeHg1FEGiwacfXLenlIWA=.8d589aed-8f8e-40bc-bd82-9bbceacafb63@github.com>
References: <Z288PGqFBbtMZ27wlMUh8r2qtvMk3Y3ko5BsmQRXquE=.0ef90b86-53b6-431c-bf7f-7119ca943e8d@github.com>
 <WkvotZc49SzL-mvw8hGGaztJ_Jl2vZV2rI1kee2FieY=.f936d1e8-716d-4ba3-b703-73f8a3ad6514@github.com>
 <RA1TDb9UP2zDxJa_SHnVNuOeHg1FEGiwacfXLenlIWA=.8d589aed-8f8e-40bc-bd82-9bbceacafb63@github.com>
Message-ID: <T56HRgHp9XXnfufykuLSIdz-sHHfoXwu-8ZZ42NEUvc=.3fa47c29-746e-4faa-a770-bfafeadaa976@github.com>

On Mon, 2 Feb 2026 17:26:10 GMT, William Kemper <wkemper at openjdk.org> 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: <T56HRgHp9XXnfufykuLSIdz-sHHfoXwu-8ZZ42NEUvc=.3fa47c29-746e-4faa-a770-bfafeadaa976@github.com>
References: <Z288PGqFBbtMZ27wlMUh8r2qtvMk3Y3ko5BsmQRXquE=.0ef90b86-53b6-431c-bf7f-7119ca943e8d@github.com>
 <WkvotZc49SzL-mvw8hGGaztJ_Jl2vZV2rI1kee2FieY=.f936d1e8-716d-4ba3-b703-73f8a3ad6514@github.com>
 <RA1TDb9UP2zDxJa_SHnVNuOeHg1FEGiwacfXLenlIWA=.8d589aed-8f8e-40bc-bd82-9bbceacafb63@github.com>
 <T56HRgHp9XXnfufykuLSIdz-sHHfoXwu-8ZZ42NEUvc=.3fa47c29-746e-4faa-a770-bfafeadaa976@github.com>
Message-ID: <hlZtMDLxFdF6FUhmJKX-KVssOiQtf-QHuTPwH6FU2HQ=.c0455a63-225e-413a-8ace-c79efe48dea7@github.com>

On Tue, 3 Feb 2026 18:04:32 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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: <b8G5vI0cfXbe1SeSnAZELmqbwKPYvSdZ9KgG1KkJtxE=.7010ae7b-2dda-4768-9a54-34c922e50e41@github.com>
References: <gwhzNS34QKsFh_FAUeKUNm2AMuYNIq0lW7C5_rq8A6g=.79f550ba-0f3f-44e1-ba7b-8be3df425084@github.com>
 <b8G5vI0cfXbe1SeSnAZELmqbwKPYvSdZ9KgG1KkJtxE=.7010ae7b-2dda-4768-9a54-34c922e50e41@github.com>
Message-ID: <jLOsfAEtGKVnTvn3zTSogYI8MyfVlcONZIp8kOBSTdM=.5d3aa347-266e-4d22-8346-04b0c22c34c7@github.com>

On Tue, 3 Feb 2026 17:28:14 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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: <b8G5vI0cfXbe1SeSnAZELmqbwKPYvSdZ9KgG1KkJtxE=.7010ae7b-2dda-4768-9a54-34c922e50e41@github.com>
References: <gwhzNS34QKsFh_FAUeKUNm2AMuYNIq0lW7C5_rq8A6g=.79f550ba-0f3f-44e1-ba7b-8be3df425084@github.com>
 <b8G5vI0cfXbe1SeSnAZELmqbwKPYvSdZ9KgG1KkJtxE=.7010ae7b-2dda-4768-9a54-34c922e50e41@github.com>
Message-ID: <GLPwIkfHiePDDeUMiYguHDn8rm_eXp5vi4TIWn1MrAs=.7c663561-367a-4999-a6d7-13012241cce8@github.com>

On Tue, 3 Feb 2026 17:39:52 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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: <hlZtMDLxFdF6FUhmJKX-KVssOiQtf-QHuTPwH6FU2HQ=.c0455a63-225e-413a-8ace-c79efe48dea7@github.com>
References: <Z288PGqFBbtMZ27wlMUh8r2qtvMk3Y3ko5BsmQRXquE=.0ef90b86-53b6-431c-bf7f-7119ca943e8d@github.com>
 <WkvotZc49SzL-mvw8hGGaztJ_Jl2vZV2rI1kee2FieY=.f936d1e8-716d-4ba3-b703-73f8a3ad6514@github.com>
 <RA1TDb9UP2zDxJa_SHnVNuOeHg1FEGiwacfXLenlIWA=.8d589aed-8f8e-40bc-bd82-9bbceacafb63@github.com>
 <T56HRgHp9XXnfufykuLSIdz-sHHfoXwu-8ZZ42NEUvc=.3fa47c29-746e-4faa-a770-bfafeadaa976@github.com>
 <hlZtMDLxFdF6FUhmJKX-KVssOiQtf-QHuTPwH6FU2HQ=.c0455a63-225e-413a-8ace-c79efe48dea7@github.com>
Message-ID: <Jcz_wabI7WdImihWUzZ2xBVD6FP5d2ZMeH3yMrmbidk=.597ae3e6-053f-43f1-894c-d5aaa1591f38@github.com>

On Tue, 3 Feb 2026 18:05:20 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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: <b8G5vI0cfXbe1SeSnAZELmqbwKPYvSdZ9KgG1KkJtxE=.7010ae7b-2dda-4768-9a54-34c922e50e41@github.com>
References: <gwhzNS34QKsFh_FAUeKUNm2AMuYNIq0lW7C5_rq8A6g=.79f550ba-0f3f-44e1-ba7b-8be3df425084@github.com>
 <b8G5vI0cfXbe1SeSnAZELmqbwKPYvSdZ9KgG1KkJtxE=.7010ae7b-2dda-4768-9a54-34c922e50e41@github.com>
Message-ID: <CpsBJ0EXP1_1hjqA0DTMbF_dqkjs2VS3sb_SmpLmSvw=.623eb3c9-a002-42b9-98cf-a3a22aba7ec5@github.com>

On Tue, 3 Feb 2026 17:43:56 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
References: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
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 dlong at openjdk.org  Tue Feb  3 23:20:07 2026
From: dlong at openjdk.org (Dean Long)
Date: Tue, 3 Feb 2026 23:20:07 GMT
Subject: RFR: 8347396: Efficient TypeFunc creations [v6]
In-Reply-To: <H3R12cuDv6CYf9j7F4XJ1wxW0NAyFFz_9cSnV4Qe5Hs=.5640efc1-a3c3-491f-998a-374d80a7f48b@github.com>
References: <VQs3SMtk1y6xTi8nCvTeWsTFfCQlTJtDdCGnfWQmRmw=.f3b33ba1-3efe-477b-b6d2-b43faae9ee2b@github.com>
 <H3R12cuDv6CYf9j7F4XJ1wxW0NAyFFz_9cSnV4Qe5Hs=.5640efc1-a3c3-491f-998a-374d80a7f48b@github.com>
Message-ID: <E13dXljVq68XjNYyd7K0aaqQWGJtvT587ZR5Y507c8k=.d1308d9b-e4c4-402e-878d-b84414982afe@github.com>

On Tue, 3 Feb 2026 09:01:19 GMT, Harshit470250 <duke at openjdk.org> wrote:

>> This PR do similar changes done by [JDK-8330851](https://bugs.openjdk.org/browse/JDK-8330851) on the GC TypeFunc creation as suggested by [JDK-8347396](https://bugs.openjdk.org/browse/JDK-8347396). As discussed in [https://github.com/openjdk/jdk/pull/21782#discussion_r1906535686,](https://github.com/openjdk/jdk/pull/21782#discussion_r1906535686) I have put guard on the shenandoah gc specific part of the code.
>
> Harshit470250 has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - remove import of barrierSetC2 from runtime
>  - make shenandoah types private
>  - move _clone_type_Type to BarrierSetC2
>  - remove whitespace

src/hotspot/share/opto/type.cpp line 737:

> 735: 
> 736: #if INCLUDE_SHENANDOAHGC
> 737:   ShenandoahBarrierSetC2::make_write_barrier_pre_Type();

How about replacing these 3 calls with a single call, something like ShenandoahBarrierSetC2::init()?  Can these functions then be made private?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27279#discussion_r2761458562

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: <gwhzNS34QKsFh_FAUeKUNm2AMuYNIq0lW7C5_rq8A6g=.79f550ba-0f3f-44e1-ba7b-8be3df425084@github.com>
References: <gwhzNS34QKsFh_FAUeKUNm2AMuYNIq0lW7C5_rq8A6g=.79f550ba-0f3f-44e1-ba7b-8be3df425084@github.com>
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: <l1LxY-EuWxwaJQCxq1kTuUsGsrW5F5aeL4HuLBJHxhQ=.bb970706-f6f3-48b5-b5c8-4bee13188c61@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
> - [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: <AN1rtpFsazMdRtzTrcdFNqti6I-sVhnwTCzDH2gZJLQ=.84f227b4-849e-4728-9e1d-56c38d8c251d@github.com>
References: <AN1rtpFsazMdRtzTrcdFNqti6I-sVhnwTCzDH2gZJLQ=.84f227b4-849e-4728-9e1d-56c38d8c251d@github.com>
Message-ID: <h4DUFfAm3mbJ0BQQDLyBxTaGmEKb4J2DF1B-mNrJWXI=.5b07247b-ed16-46c7-b8dc-892945a8a221@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:

  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: <jLOsfAEtGKVnTvn3zTSogYI8MyfVlcONZIp8kOBSTdM=.5d3aa347-266e-4d22-8346-04b0c22c34c7@github.com>
References: <gwhzNS34QKsFh_FAUeKUNm2AMuYNIq0lW7C5_rq8A6g=.79f550ba-0f3f-44e1-ba7b-8be3df425084@github.com>
 <b8G5vI0cfXbe1SeSnAZELmqbwKPYvSdZ9KgG1KkJtxE=.7010ae7b-2dda-4768-9a54-34c922e50e41@github.com>
 <jLOsfAEtGKVnTvn3zTSogYI8MyfVlcONZIp8kOBSTdM=.5d3aa347-266e-4d22-8346-04b0c22c34c7@github.com>
Message-ID: <rI3yTlvC3CCWkP0nutJXDQvkkTuGMeXMkoBylzIiW4c=.febb5cd8-1eee-4b42-a2dc-eb3c0d85529a@github.com>

On Tue, 3 Feb 2026 18:38:31 GMT, Xiaolong Peng <xpeng at openjdk.org> 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: <b8G5vI0cfXbe1SeSnAZELmqbwKPYvSdZ9KgG1KkJtxE=.7010ae7b-2dda-4768-9a54-34c922e50e41@github.com>
References: <gwhzNS34QKsFh_FAUeKUNm2AMuYNIq0lW7C5_rq8A6g=.79f550ba-0f3f-44e1-ba7b-8be3df425084@github.com>
 <b8G5vI0cfXbe1SeSnAZELmqbwKPYvSdZ9KgG1KkJtxE=.7010ae7b-2dda-4768-9a54-34c922e50e41@github.com>
Message-ID: <T0hc0pxGk3TDWKF7SOweSef4ug9KEVyFfg3yJopNCr4=.60dd259a-c2f2-42ed-979e-281fa9a24f56@github.com>

On Tue, 3 Feb 2026 17:30:13 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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: <DJfvNMYHp2RMU2d5kAwKRh0TQK39RArN903z3vUdYsQ=.faa606df-ac5b-436f-ba5f-2f3d87180329@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
> - [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: <Z288PGqFBbtMZ27wlMUh8r2qtvMk3Y3ko5BsmQRXquE=.0ef90b86-53b6-431c-bf7f-7119ca943e8d@github.com>
References: <Z288PGqFBbtMZ27wlMUh8r2qtvMk3Y3ko5BsmQRXquE=.0ef90b86-53b6-431c-bf7f-7119ca943e8d@github.com>
Message-ID: <aeZKgB276-Ptn1FpsegN7F4MUsOIqgaW2Q72p1IaJg0=.80baedd8-0890-42fd-9433-6a661551c063@github.com>

> 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: <GLPwIkfHiePDDeUMiYguHDn8rm_eXp5vi4TIWn1MrAs=.7c663561-367a-4999-a6d7-13012241cce8@github.com>
References: <gwhzNS34QKsFh_FAUeKUNm2AMuYNIq0lW7C5_rq8A6g=.79f550ba-0f3f-44e1-ba7b-8be3df425084@github.com>
 <b8G5vI0cfXbe1SeSnAZELmqbwKPYvSdZ9KgG1KkJtxE=.7010ae7b-2dda-4768-9a54-34c922e50e41@github.com>
 <GLPwIkfHiePDDeUMiYguHDn8rm_eXp5vi4TIWn1MrAs=.7c663561-367a-4999-a6d7-13012241cce8@github.com>
Message-ID: <v74-qnrHlzxp1CD6-FuKGOqUFNUhN8psmZ9qnFciets=.bc963137-62e4-4c0c-b32d-81149035b10e@github.com>

On Tue, 3 Feb 2026 18:46:37 GMT, Xiaolong Peng <xpeng at openjdk.org> 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<Lock> 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: <gwhzNS34QKsFh_FAUeKUNm2AMuYNIq0lW7C5_rq8A6g=.79f550ba-0f3f-44e1-ba7b-8be3df425084@github.com>
References: <gwhzNS34QKsFh_FAUeKUNm2AMuYNIq0lW7C5_rq8A6g=.79f550ba-0f3f-44e1-ba7b-8be3df425084@github.com>
Message-ID: <BzgvIMnJVCrKbpbCib6WiMUfjzYbkXiVmAJ-n4F0JWU=.4be5b1dd-1f63-40c4-b878-12c57ae97015@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 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: <b8G5vI0cfXbe1SeSnAZELmqbwKPYvSdZ9KgG1KkJtxE=.7010ae7b-2dda-4768-9a54-34c922e50e41@github.com>
References: <gwhzNS34QKsFh_FAUeKUNm2AMuYNIq0lW7C5_rq8A6g=.79f550ba-0f3f-44e1-ba7b-8be3df425084@github.com>
 <b8G5vI0cfXbe1SeSnAZELmqbwKPYvSdZ9KgG1KkJtxE=.7010ae7b-2dda-4768-9a54-34c922e50e41@github.com>
Message-ID: <9zecTWGyAX-5Cl1JvJBWu5Cl68dN-1oqx2FfDh1YVoA=.c20d02f5-7025-41cc-9d3a-40e94c63226e@github.com>

On Tue, 3 Feb 2026 17:32:57 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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 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: <BzgvIMnJVCrKbpbCib6WiMUfjzYbkXiVmAJ-n4F0JWU=.4be5b1dd-1f63-40c4-b878-12c57ae97015@github.com>
References: <gwhzNS34QKsFh_FAUeKUNm2AMuYNIq0lW7C5_rq8A6g=.79f550ba-0f3f-44e1-ba7b-8be3df425084@github.com>
 <BzgvIMnJVCrKbpbCib6WiMUfjzYbkXiVmAJ-n4F0JWU=.4be5b1dd-1f63-40c4-b878-12c57ae97015@github.com>
Message-ID: <EJV2NJ1pC9ajgXT0pjWS03vqVfpNwYV9kjzaIJReapE=.60cdaef8-1875-401c-ae6d-580344948161@github.com>

On Wed, 4 Feb 2026 07:15:22 GMT, Xiaolong Peng <xpeng at openjdk.org> 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 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: <gwhzNS34QKsFh_FAUeKUNm2AMuYNIq0lW7C5_rq8A6g=.79f550ba-0f3f-44e1-ba7b-8be3df425084@github.com>
References: <gwhzNS34QKsFh_FAUeKUNm2AMuYNIq0lW7C5_rq8A6g=.79f550ba-0f3f-44e1-ba7b-8be3df425084@github.com>
Message-ID: <sFlNlrTEgJ0jrIX4AV5UA49Aj6w26pauuRezHALEZFE=.9db13eac-4c98-4ab3-9c5e-fe79654883cb@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 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 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: <s2L-YL6e2M4yAi3Y1I2FoZwCNPfwia0-wwV6SDLjkf4=.02e9ca45-0845-4d1e-b260-5105468466db@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
 <s2L-YL6e2M4yAi3Y1I2FoZwCNPfwia0-wwV6SDLjkf4=.02e9ca45-0845-4d1e-b260-5105468466db@github.com>
Message-ID: <fCOEaefEYCLAOC79UHKa3elPyu2Wve-eMvfo7kDeQqQ=.3af3d71f-2954-41bb-a94e-a0b12e85abea@github.com>

On Thu, 15 Jan 2026 13:54:01 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> 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: <AN1rtpFsazMdRtzTrcdFNqti6I-sVhnwTCzDH2gZJLQ=.84f227b4-849e-4728-9e1d-56c38d8c251d@github.com>
References: <AN1rtpFsazMdRtzTrcdFNqti6I-sVhnwTCzDH2gZJLQ=.84f227b4-849e-4728-9e1d-56c38d8c251d@github.com>
Message-ID: <imrxTjHvzYMp5b1zt5sB6v2nNmvP5eutvv5AW_EF-7I=.d7cb770a-5c66-41a9-958a-5f556b70988d@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:

  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 fbredberg at openjdk.org  Wed Feb  4 14:57:46 2026
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 4 Feb 2026 14:57:46 GMT
Subject: RFR: 8373595: A new ObjectMonitorTable implementation [v2]
In-Reply-To: <KlaUAdH12kUcQoHF5lYz7t8sPH2stVVqhywcgbp72mk=.759e86d9-ccd2-4b44-ac84-a6ac822f9964@github.com>
References: <NpCJRO5OePJjpy3I-x4DV3C-NipfM9fkC9UvEwso4kw=.7fb88fe9-15e6-458e-ae43-77b3db67886d@github.com>
 <KlaUAdH12kUcQoHF5lYz7t8sPH2stVVqhywcgbp72mk=.759e86d9-ccd2-4b44-ac84-a6ac822f9964@github.com>
Message-ID: <QBsdGgMOTo3qG9bKvvMRHUG9cuWrGwRlK6poUmkHH_4=.6998b48c-0aed-4eab-917e-23f29696ba0e@github.com>

On Wed, 28 Jan 2026 09:13:35 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated all platforms after review comments
>
> src/hotspot/cpu/s390/macroAssembler_s390.cpp line 6394:
> 
>> 6392:         z_bre(monitor_found);
>> 6393:         add2reg(cache_addr, in_bytes(OMCache::oop_to_oop_difference()));
>> 6394:       }
> 
> This would be an alternative for the above loop:
> 
>       ByteSize cache_offset   = JavaThread::om_cache_oops_offset();
>       ByteSize monitor_offset = OMCache::oop_to_monitor_difference();
>       const unsigned int num_unrolled = 2;
>       
>       for (unsigned int i = 0; i < num_unrolled; i++) {
>         z_lg(tmp1_monitor, Address(Z_thread, cache_offset + monitor_offset));
>         z_cg(obj, Address(Z_thread, cache_offset));
>         z_bre(monitor_found);
>         cache_offset += in_bytes(OMCache::oop_to_oop_difference());
>       }

Nice suggestion! It's now been added to all platforms.

> src/hotspot/cpu/s390/macroAssembler_s390.cpp line 6403:
> 
>> 6401:       z_lg(tmp2, Address(tmp2));
>> 6402:       z_lg(tmp1, Address(tmp2, ObjectMonitorTable::table_capacity_mask_offset()));
>> 6403:       z_ngr(hash, tmp1);
> 
> The above two instructions could be combined:
> `    z_ng(hash, Address(tmp2, ObjectMonitorTable::table_capacity_mask_offset()));`

Fixed

> src/hotspot/cpu/s390/macroAssembler_s390.cpp line 6404:
> 
>> 6402:       z_lg(tmp1, Address(tmp2, ObjectMonitorTable::table_capacity_mask_offset()));
>> 6403:       z_ngr(hash, tmp1);
>> 6404:       z_lg(tmp1, Address(tmp2, ObjectMonitorTable::table_buckets_offset()));
> 
> Wouldn't it be clearer to use `tmp1_bucket` here?

Fixed

> src/hotspot/cpu/s390/macroAssembler_s390.cpp line 6412:
> 
>> 6410: 
>> 6411:       // Check if the monitor in the bucket is special (empty, tombstone or removed).
>> 6412:       z_cghi(tmp1_monitor, ObjectMonitorTable::SpecialPointerValues::below_is_special);
> 
> Address comparison should be unsigned. Please use `clgfi` instead.

Fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29383#discussion_r2764429795
PR Review Comment: https://git.openjdk.org/jdk/pull/29383#discussion_r2764432547
PR Review Comment: https://git.openjdk.org/jdk/pull/29383#discussion_r2764431016
PR Review Comment: https://git.openjdk.org/jdk/pull/29383#discussion_r2764422747

From fbredberg at openjdk.org  Wed Feb  4 14:57:39 2026
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 4 Feb 2026 14:57:39 GMT
Subject: RFR: 8373595: A new ObjectMonitorTable implementation [v2]
In-Reply-To: <NpCJRO5OePJjpy3I-x4DV3C-NipfM9fkC9UvEwso4kw=.7fb88fe9-15e6-458e-ae43-77b3db67886d@github.com>
References: <NpCJRO5OePJjpy3I-x4DV3C-NipfM9fkC9UvEwso4kw=.7fb88fe9-15e6-458e-ae43-77b3db67886d@github.com>
Message-ID: <E-DcxoLSLFfZwb3TCalwptZEu3sJpOJP585CusdSHIM=.0f8f276d-7453-4492-adeb-fd097fb1b0d6@github.com>

> Me and Anton Artemov (@toxaart) investigated a quite large regression that occurred in Pet Clinic that happened if you turned on Compact Object Headers. It was found that a large portion of that regression could be attributed to not finding the monitor in the Object Monitor Cache, and because we couldn't access the Object Monitor Table from C2 generated code, we often had to take the slow path.
> 
> By making the object monitor cache larger and make it use the object's hash value as a key, we managed to mitigate the regression.
> 
> Erik ?sterlund (@fisk) took that idea and elevated it to the next level, which means that he rewrote the object monitor table code so that we can now search for an object in the global object monitor table from C2 generated code. I.e. from `C2_MacroAssembler::fast_lock()`. As in my and Anton's version, the key is the hash value from the object.
> 
> Erik also provided new barrier code needed for ZGC for x86 and aarch64. Roman Kennke (@rkennke) provided the same for Shenandoah, also for x86 and aarch64.
> 
> We decided to keep the Object Monitor Cache, since we found that for most programs (but not Pet Clinic) the monitor you are looking for is likely found in the first positions of the cache (it's sorted in most recently used order). However we decresed the size from 8 to 2 elements.
> 
> After running extensive performance tests we can say that this has improved the performance in many of them, not only mitigated the regression in Pet Clinic.
> 
> Tests are running okay tier1-7 on supported platforms.
> 
> The rest of the platforms (`ppc`, `riscv` and `s390`) have been smoke tested using QEMU.
> I mainly used this test for smoke testing with QEMU: `-XX:+UnlockDiagnosticVMOptions -XX:+UseObjectMonitorTable ./test/hotspot/jtreg/runtime/Monitor/UseObjectMonitorTableTest.java `

Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:

  Updated all platforms after review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29383/files
  - new: https://git.openjdk.org/jdk/pull/29383/files/d7411cf6..47413369

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29383&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29383&range=00-01

  Stats: 61 lines in 6 files changed: 2 ins; 13 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/29383.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29383/head:pull/29383

PR: https://git.openjdk.org/jdk/pull/29383

From fbredberg at openjdk.org  Wed Feb  4 14:57:41 2026
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 4 Feb 2026 14:57:41 GMT
Subject: RFR: 8373595: A new ObjectMonitorTable implementation
In-Reply-To: <m_YZSc79iTALh9NJGAEYckwDCwIppujpN_0SwgmHmeY=.c7a9b61e-3cd8-421a-a455-ca1679887184@github.com>
References: <NpCJRO5OePJjpy3I-x4DV3C-NipfM9fkC9UvEwso4kw=.7fb88fe9-15e6-458e-ae43-77b3db67886d@github.com>
 <m_YZSc79iTALh9NJGAEYckwDCwIppujpN_0SwgmHmeY=.c7a9b61e-3cd8-421a-a455-ca1679887184@github.com>
Message-ID: <_K78djZvz2SxZjO3Ow6j_9Vk-9s-wIwta6S_UmCLmQI=.5d070723-580c-4b4f-8d3d-acac44af4817@github.com>

On Mon, 26 Jan 2026 15:24:48 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Me and Anton Artemov (@toxaart) investigated a quite large regression that occurred in Pet Clinic that happened if you turned on Compact Object Headers. It was found that a large portion of that regression could be attributed to not finding the monitor in the Object Monitor Cache, and because we couldn't access the Object Monitor Table from C2 generated code, we often had to take the slow path.
>> 
>> By making the object monitor cache larger and make it use the object's hash value as a key, we managed to mitigate the regression.
>> 
>> Erik ?sterlund (@fisk) took that idea and elevated it to the next level, which means that he rewrote the object monitor table code so that we can now search for an object in the global object monitor table from C2 generated code. I.e. from `C2_MacroAssembler::fast_lock()`. As in my and Anton's version, the key is the hash value from the object.
>> 
>> Erik also provided new barrier code needed for ZGC for x86 and aarch64. Roman Kennke (@rkennke) provided the same for Shenandoah, also for x86 and aarch64.
>> 
>> We decided to keep the Object Monitor Cache, since we found that for most programs (but not Pet Clinic) the monitor you are looking for is likely found in the first positions of the cache (it's sorted in most recently used order). However we decresed the size from 8 to 2 elements.
>> 
>> After running extensive performance tests we can say that this has improved the performance in many of them, not only mitigated the regression in Pet Clinic.
>> 
>> Tests are running okay tier1-7 on supported platforms.
>> 
>> The rest of the platforms (`ppc`, `riscv` and `s390`) have been smoke tested using QEMU.
>> I mainly used this test for smoke testing with QEMU: `-XX:+UnlockDiagnosticVMOptions -XX:+UseObjectMonitorTable ./test/hotspot/jtreg/runtime/Monitor/UseObjectMonitorTableTest.java `
>
> Nice work! And thanks for writing the platform code as well. That's awesome! The PPC64 tests have passed (executed huge number of tests), but the comparison with `below_is_special` should be unsigned. In addition, the code can be optimized:
> 
> diff --git a/src/hotspot/cpu/ppc/gc/z/zBarrierSetAssembler_ppc.cpp b/src/hotspot/cpu/ppc/gc/z/zBarrierSetAssembler_ppc.cpp
> index c1c818684cd..9012a3767b9 100644
> --- a/src/hotspot/cpu/ppc/gc/z/zBarrierSetAssembler_ppc.cpp
> +++ b/src/hotspot/cpu/ppc/gc/z/zBarrierSetAssembler_ppc.cpp
> @@ -955,8 +955,8 @@ void ZBarrierSetAssembler::try_resolve_weak_handle_in_c2(MacroAssembler* masm, R
>    BarrierSetAssembler::try_resolve_weak_handle_in_c2(masm, obj, tmp, slow_path);
>  
>    // Check if the oop is bad, in which case we need to take the slow path.
> -  __ ld(tmp, in_bytes(ZThreadLocalData::mark_bad_mask_offset()), R16_thread);
> -  __ and_(tmp, obj, tmp);
> +  __ relocate(barrier_Relocation::spec(), ZBarrierRelocationFormatMarkBadMask);
> +  __ andi_(tmp, obj, barrier_Relocation::unpatched);
>    __ bne(CR0, slow_path);
>  
>    // Oop is okay, so we uncolor it.
> diff --git a/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp b/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
> index f7a59983854..7ff8c08e1bf 100644
> --- a/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
> +++ b/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
> @@ -2756,47 +2756,41 @@ void MacroAssembler::compiler_fast_lock_object(ConditionRegister flag, Register
>        addi(owner_addr, mark, in_bytes(ObjectMonitor::owner_offset()) - monitor_tag);
>        mark = noreg;
>      } else {
> -      const Register cache_addr = tmp3;
> -      const Register tmp3_bucket = tmp3;
> -      const Register tmp2_hash = tmp2;
>        Label monitor_found;
>  
> -      // Save the mark, we might need it to extract the hash.
> -      mr(tmp2_hash, mark);
> -
>        // Look for the monitor in the om_cache.
> -
> -      // Load cache address
> -      addi(cache_addr, R16_thread, in_bytes(JavaThread::om_cache_oops_offset()));
> -
> +      const int first_obj_offset = in_bytes(JavaThread::om_cache_oops_offset());
> +      const int first_monitor_offset = first_obj_offset + in_bytes(OMCache::oop_to_monitor_difference());
> +      const int entry_size = in_bytes(OMCache::oop_to_oop_difference());
>        const int num_unrolled = OMCache::CAPACITY;
> +
>        for (int i = 0; i < num_unrolled; i++) {
> -        ld(R0, 0, cache_addr);
> -        ld(monitor, in_bytes(OMCache::oop_to_monitor_difference()), cache_addr);
> +        ld(R0, first_obj_offset + i * entry_size, R16_thre...

@TheRealMDoerr, @RealFYang, @offamitkumar, @RealLucy

Thank you for the reviews. I might not have done exactly as you suggested, but I have tried to incorporate them one way or the other.

**First:** Thank you for pointing out that the comparison with `below_is_special` should be unsigned. That problem also lured its way into the AArch64 port. I'll be more careful not mixing up "Lower" with "Less Than" in the future, promise!

**Second:** I liked the optimization idea for the om_cache loop, so I adopted it for all platforms.

**Third:** The registers for mark and monitor are the same (unfortunately), so I need to take a copy of the mark word before the om_cache code. This is because I speculatively set the monitor value in the om_cache code, and thereby overwrites the mark value.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29383#issuecomment-3847909014

From fbredberg at openjdk.org  Wed Feb  4 14:57:47 2026
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 4 Feb 2026 14:57:47 GMT
Subject: RFR: 8373595: A new ObjectMonitorTable implementation [v2]
In-Reply-To: <AA1NpCFOALRmiLksNdGdtDhY4BwTppWlsyMz5kNyzHo=.366d1c25-386b-4232-8266-28ce68d53106@github.com>
References: <NpCJRO5OePJjpy3I-x4DV3C-NipfM9fkC9UvEwso4kw=.7fb88fe9-15e6-458e-ae43-77b3db67886d@github.com>
 <AA1NpCFOALRmiLksNdGdtDhY4BwTppWlsyMz5kNyzHo=.366d1c25-386b-4232-8266-28ce68d53106@github.com>
Message-ID: <v33XSL2YkXXCh8XKWtET8CdDmiVV4uSdJlw5GtmYTGE=.b8028598-a197-4600-b686-879942ee76c4@github.com>

On Mon, 2 Feb 2026 09:17:33 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated all platforms after review comments
>
> src/hotspot/cpu/s390/macroAssembler_s390.cpp line 6397:
> 
>> 6395: 
>> 6396:       // Get the hash code.
>> 6397:       z_srlg(hash, hash, markWord::hash_shift);
> 
> the monitor you are looking for is likely found in the first positions of the cache (it's sorted in most recently used order).
> 
> 
> Then would it be helpful to load the hash only just before extraction? If the `monitor_found` cases are frequent, the load would not be needed at all.

The registers for mark and monitor are the same (unfortunately), so I need to take a copy of the mark word before the om_cache code. This is because I speculatively set the monitor value in the om_cache code, and thereby overwrites the mark value.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29383#discussion_r2764418971

From fbredberg at openjdk.org  Wed Feb  4 15:00:39 2026
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 4 Feb 2026 15:00:39 GMT
Subject: RFR: 8373595: A new ObjectMonitorTable implementation [v2]
In-Reply-To: <OPhXCwLYa_I7kU_5Kaj2EkfCiuk1FBFD24_Te1sLlgI=.354a9718-56e4-4592-8ff7-0625743185ff@github.com>
References: <NpCJRO5OePJjpy3I-x4DV3C-NipfM9fkC9UvEwso4kw=.7fb88fe9-15e6-458e-ae43-77b3db67886d@github.com>
 <OPhXCwLYa_I7kU_5Kaj2EkfCiuk1FBFD24_Te1sLlgI=.354a9718-56e4-4592-8ff7-0625743185ff@github.com>
Message-ID: <ITIoph3uPWIqX8Tz2kDmXmbzUAYhoa3eDyQVdlt4dGg=.5c2f76db-d711-4d7d-a92c-85e98d576d6d@github.com>

On Tue, 27 Jan 2026 06:33:46 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated all platforms after review comments
>
> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 229:
> 
>> 227: 
>> 228:       // Save the mark, we might need it to extract the hash.
>> 229:       mov(rscratch2, t1_mark);
> 
> Using `rscratch2` here is a little bit scary as we call other MacroAssembler functions with the expectation of it being live. 
> 
> Guessing the `ldr`, `lea` and `increment` implementations are not likely to change anytime soon, but maybe it is worth a comment saying that we do not expect these to modify the state of `rscratch2`

Rewrote the code. Don't use `rscratch2` anymore.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29383#discussion_r2764450323

From mdoerr at openjdk.org  Wed Feb  4 16:26:13 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 4 Feb 2026 16:26:13 GMT
Subject: RFR: 8373595: A new ObjectMonitorTable implementation
In-Reply-To: <_K78djZvz2SxZjO3Ow6j_9Vk-9s-wIwta6S_UmCLmQI=.5d070723-580c-4b4f-8d3d-acac44af4817@github.com>
References: <NpCJRO5OePJjpy3I-x4DV3C-NipfM9fkC9UvEwso4kw=.7fb88fe9-15e6-458e-ae43-77b3db67886d@github.com>
 <m_YZSc79iTALh9NJGAEYckwDCwIppujpN_0SwgmHmeY=.c7a9b61e-3cd8-421a-a455-ca1679887184@github.com>
 <_K78djZvz2SxZjO3Ow6j_9Vk-9s-wIwta6S_UmCLmQI=.5d070723-580c-4b4f-8d3d-acac44af4817@github.com>
Message-ID: <gzK5cJ1tu7QzSV92qjrXWveFkXb0jFQF_zdqFl2ySmg=.717515e8-1e21-40ec-beae-3a648b9ece35@github.com>

On Wed, 4 Feb 2026 14:49:28 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Thank you for the reviews. I might not have done exactly as you suggested, but I have tried to incorporate them one way or the other.

That's fine. Thanks a lot for overworking it!
 
> **First:** Thank you for pointing out that the comparison with `below_is_special` should be unsigned. That problem also lured its way into the AArch64 port. I'll be more careful not mixing up "Lower" with "Less Than" in the future, promise!
> 
> **Second:** I liked the optimization idea for the om_cache loop, so I adopted it for all platforms.
> 

Nice!

> **Third:** The registers for mark and monitor are the same (unfortunately), so I need to take a copy of the mark word before the om_cache code. This is because I speculatively set the monitor value in the om_cache code, and thereby overwrites the mark value.

Good catch! Alternatively, you could move the hash code extraction up like this:

diff --git a/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp b/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
index 819599126b2..72ca5caa1c1 100644
--- a/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
+++ b/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
@@ -2760,8 +2760,8 @@ void MacroAssembler::compiler_fast_lock_object(ConditionRegister flag, Register
       const Register tmp2_hash = tmp2;
       Label monitor_found;
 
-      // Save the mark, we might need it to extract the hash.
-      mr(tmp2_hash, mark);
+      // Get the hash code here, because mark will be killed.
+      srdi(tmp2_hash, mark, markWord::hash_shift);
 
       // Look for the monitor in the om_cache.
 
@@ -2778,9 +2778,6 @@ void MacroAssembler::compiler_fast_lock_object(ConditionRegister flag, Register
 
       // Look for the monitor in the table.
 
-      // Get the hash code.
-      srdi(tmp2_hash, tmp2_hash, markWord::hash_shift);
-
       // Get the table and calculate the bucket's address
       int simm16_rest = load_const_optimized(tmp3, ObjectMonitorTable::current_table_address(), R0, true);
       ld_ptr(tmp3, simm16_rest, tmp3);

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29383#issuecomment-3848424901

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: <d8M0ssnm1eX51gHR98afamU8qAnP0vKHI7S93XUFVag=.c1b19b91-c180-40f7-978f-427cafb40252@github.com>
References: <IyhQA2oBx97_eASYwxEHxtln34DwHBnwiJ6ZnT05jpk=.0f240e6c-ca47-4165-a32f-27c7bde5b184@github.com>
 <d8M0ssnm1eX51gHR98afamU8qAnP0vKHI7S93XUFVag=.c1b19b91-c180-40f7-978f-427cafb40252@github.com>
Message-ID: <O6vLqJDa7cmTBDrMF1FtyYxeRft6BlEtdeAnf6d_CM8=.6cd3d929-427a-41eb-9e92-e13e8b604764@github.com>

On Fri, 30 Jan 2026 00:46:39 GMT, William Kemper <wkemper at openjdk.org> 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: <oXA87tZwDFxnG-0laPzGM6_zGEgqrmw5VeTomO-RxpM=.5c20460a-b20d-48b3-8dec-835ff911a069@github.com>

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: <IyhQA2oBx97_eASYwxEHxtln34DwHBnwiJ6ZnT05jpk=.0f240e6c-ca47-4165-a32f-27c7bde5b184@github.com>
References: <IyhQA2oBx97_eASYwxEHxtln34DwHBnwiJ6ZnT05jpk=.0f240e6c-ca47-4165-a32f-27c7bde5b184@github.com>
Message-ID: <ho6Z9m_Wn2GIUGKmgBFJMQFrwALCOHrHT-_AcQAMx58=.b11294e9-8db9-449a-be8c-83299da65816@github.com>

> 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: <O6vLqJDa7cmTBDrMF1FtyYxeRft6BlEtdeAnf6d_CM8=.6cd3d929-427a-41eb-9e92-e13e8b604764@github.com>
References: <IyhQA2oBx97_eASYwxEHxtln34DwHBnwiJ6ZnT05jpk=.0f240e6c-ca47-4165-a32f-27c7bde5b184@github.com>
 <d8M0ssnm1eX51gHR98afamU8qAnP0vKHI7S93XUFVag=.c1b19b91-c180-40f7-978f-427cafb40252@github.com>
 <O6vLqJDa7cmTBDrMF1FtyYxeRft6BlEtdeAnf6d_CM8=.6cd3d929-427a-41eb-9e92-e13e8b604764@github.com>
Message-ID: <g6kXLdpwK8tcF84iSWVaWaE9_nl7cWE1AdTuWsjArso=.9b0b1c23-91c0-4217-885d-6b9ae7e73f22@github.com>

On Wed, 4 Feb 2026 17:08:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I assume the bulk of the move is mechanical and there are no substantial changes in the body of those bulk moves.

Correct. The most substantive change is converting the return value of `chose_collection_set_from_regiondata` into a member variable, used here: https://github.com/openjdk/jdk/pull/29496/changes#diff-4fe32d046615496c72012064c8b5c7d44b8430699281bd20173c4035d3b913cbR65 and here: https://github.com/openjdk/jdk/pull/29496/changes#diff-777feeea79dc19a54964570587e9ae6cc864829a67f640c6c7f0f78b6480b001R647

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29496#issuecomment-3848769993

From shade at openjdk.org  Wed Feb  4 17:35:08 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 4 Feb 2026 17:35:08 GMT
Subject: RFR: 8376756: GenShen: Improve encapsulation of generational
 collection set choosing [v3]
In-Reply-To: <ho6Z9m_Wn2GIUGKmgBFJMQFrwALCOHrHT-_AcQAMx58=.b11294e9-8db9-449a-be8c-83299da65816@github.com>
References: <IyhQA2oBx97_eASYwxEHxtln34DwHBnwiJ6ZnT05jpk=.0f240e6c-ca47-4165-a32f-27c7bde5b184@github.com>
 <ho6Z9m_Wn2GIUGKmgBFJMQFrwALCOHrHT-_AcQAMx58=.b11294e9-8db9-449a-be8c-83299da65816@github.com>
Message-ID: <pq6mwxhwNNuUbNXhh1tISq_8jiVdbHXO8DQZ4Rf0_sY=.9fd342db-f7dc-46dc-8534-8ba0de54c195@github.com>

On Wed, 4 Feb 2026 17:24:07 GMT, William Kemper <wkemper at openjdk.org> 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 parameter indentation after signature change

Marked as reviewed by shade (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29496#pullrequestreview-3752369950

From kdnilsen at openjdk.org  Wed Feb  4 17:46:50 2026
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 4 Feb 2026 17:46:50 GMT
Subject: RFR: 8377180: Shenandoah: make escalation from degen to full more
 conservative [v2]
In-Reply-To: <oXA87tZwDFxnG-0laPzGM6_zGEgqrmw5VeTomO-RxpM=.5c20460a-b20d-48b3-8dec-835ff911a069@github.com>
References: <oXA87tZwDFxnG-0laPzGM6_zGEgqrmw5VeTomO-RxpM=.5c20460a-b20d-48b3-8dec-835ff911a069@github.com>
Message-ID: <UDZhZUijMhKYVsU9wvCHI3ilPBZ9sfX9mm-rBTsZm68=.c9a4920e-0dae-40e1-b79a-559039e02802@github.com>

> 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:
>        <- [       Conc GC       ] -> <- [ Degen    ] -> <- [            Full GC             ]
>           [    experiences      ]       [  with    ]
>           [     allocation      ]       [   bad    ]
>           [      failure        ]       [ progress ]
>                                         [ STW pause is 100 ms degen + 3s full GC            ]
> 
>    Revised behavior not to scale:
>        <- [       Conc GC       ] -> <- [ Degen    ] -> <- [       Conc GC       ] -> [ Degen    ]
>           [    experiences      ]       [  with    ]       [    experiences      ]    [  with    ]
>           [     allocation      ]       [   bad    ]       [     allocation      ]    [  good    ]
>           [      failure        ]       [ progress ]       [      failure        ]    [ progress ]
>                                         [  100 ms  ]                                  [  100 ms  ] 
>                                         [   pause  ]                                  [   pause  ]

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  Fix gtest for ShenandoahCollectorPolicy

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29574/files
  - new: https://git.openjdk.org/jdk/pull/29574/files/8c8aee6f..0f094a68

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29574&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29574&range=00-01

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 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 btaylor at openjdk.org  Wed Feb  4 18:47:14 2026
From: btaylor at openjdk.org (Ben Taylor)
Date: Wed, 4 Feb 2026 18:47:14 GMT
Subject: RFR: 8377126: Convert ShenandoahVerifier related code to use Atomic<T>
Message-ID: <WwWN7V6-onaSKKJnwxN59Mr7BA6f94rUZmS2lkKzD8Y=.e072616c-6495-46b1-8cfe-79345ee31635@github.com>

Modernizes ShenandoahVerifier code by replacing `AtomicAccess` methods with `Atomic<T>` types.

Tier1 test results on x86_64 linux are the same before and after this change when running with `TEST_VM_OPTS=-XX:+UseShenandoahGC`.

-------------

Commit messages:
 - 8377126: Convert ShenandoahVerifier related code to use Atomic<T>

Changes: https://git.openjdk.org/jdk/pull/29576/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29576&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377126
  Stats: 14 lines in 2 files changed: 0 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/29576.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29576/head:pull/29576

PR: https://git.openjdk.org/jdk/pull/29576

From wkemper at openjdk.org  Wed Feb  4 19:26:11 2026
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 4 Feb 2026 19:26:11 GMT
Subject: RFR: 8377126: Shenandoah: Convert ShenandoahVerifier related code
 to use Atomic<T>
In-Reply-To: <WwWN7V6-onaSKKJnwxN59Mr7BA6f94rUZmS2lkKzD8Y=.e072616c-6495-46b1-8cfe-79345ee31635@github.com>
References: <WwWN7V6-onaSKKJnwxN59Mr7BA6f94rUZmS2lkKzD8Y=.e072616c-6495-46b1-8cfe-79345ee31635@github.com>
Message-ID: <4HiyHpIE75zagr0IROnRhR87n9swrhcUEm6CYoC5WbE=.45d17a1e-ad9d-4c81-a673-545b96f2284f@github.com>

On Wed, 4 Feb 2026 18:20:18 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

> Modernizes ShenandoahVerifier code by replacing `AtomicAccess` methods with `Atomic<T>` types.
> 
> Tier1 test results on x86_64 linux are the same before and after this change when running with `TEST_VM_OPTS=-XX:+UseShenandoahGC`.

LGTM

-------------

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29576#pullrequestreview-3752910670

From wkemper at openjdk.org  Wed Feb  4 19:36:16 2026
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 4 Feb 2026 19:36:16 GMT
Subject: Integrated: 8376756: GenShen: Improve encapsulation of generational
 collection set choosing
In-Reply-To: <IyhQA2oBx97_eASYwxEHxtln34DwHBnwiJ6ZnT05jpk=.0f240e6c-ca47-4165-a32f-27c7bde5b184@github.com>
References: <IyhQA2oBx97_eASYwxEHxtln34DwHBnwiJ6ZnT05jpk=.0f240e6c-ca47-4165-a32f-27c7bde5b184@github.com>
Message-ID: <iACFY8K9TP-yg7pL29mXYi6Ca7O2i-q52w7N3ewBh1Y=.87123fb6-ec39-498b-bdff-da93c727bcc1@github.com>

On Thu, 29 Jan 2026 23:43:31 GMT, William Kemper <wkemper at openjdk.org> 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.

This pull request has now been integrated.

Changeset: 949370ab
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/949370ab0e701cfcc68cb84dd0f91e5db41f4f45
Stats:     1234 lines in 22 files changed: 574 ins; 573 del; 87 mod

8376756: GenShen: Improve encapsulation of generational collection set choosing

Reviewed-by: shade, kdnilsen

-------------

PR: https://git.openjdk.org/jdk/pull/29496

From duke at openjdk.org  Wed Feb  4 22:40:12 2026
From: duke at openjdk.org (duke)
Date: Wed, 4 Feb 2026 22:40:12 GMT
Subject: Withdrawn: 8372779: C2: Disambiguate Node::adr_type for the IR graph
In-Reply-To: <dEidZLl1MkM6TbAxS2FsitU70AYAahwzK9cun61wwV8=.ccdad883-5d8f-403e-a19f-40aef0f53b11@github.com>
References: <dEidZLl1MkM6TbAxS2FsitU70AYAahwzK9cun61wwV8=.ccdad883-5d8f-403e-a19f-40aef0f53b11@github.com>
Message-ID: <N2dWmtIMY28RWG9aSzZATUCsLQasgm3SSnYQ1vWMby8=.dfb9e0a4-c27e-4336-86ab-ab2f9dc19c9e@github.com>

On Mon, 1 Dec 2025 06:21:56 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> Currently, `Node::adr_type` is ambiguous. For some, it refers to the memory the node consumes, while for the others, it refer to the memory the node produces. This PR removes that ambiguity by introducing `Node::in_adr_type` and `Node::out_adr_type` that refer to those properties, respectively. It also introduces a local verification of the memory graph during compilation. These additions uncover some issues:
> 
> - Sometimes, the memory is wired incorrectly, such as in `LibraryCall::extend_setCurrentThread`, the `Phi` collect the `StoreNode`s instead of the whole memory state. I think these issues do not result in crashes or miscompilation, though.
> - `AryEqNode` reports `adr_type` being `TypeAryPtr::BYTES` (it inherits this from `StrIntrinsicNode`). This is incorrect, however, as it can accept `char[]` inputs, too.
> - For nodes such as `StrInflatedCopyNode`, as it consumes more than it produces, during scheduling, we need to compute anti-dependencies. This is not the case, so I fixed it by making it kill all the memory it consumes.
> - `GraphKit::set_output_for_allocation` uses a raw `ProjNode` as the base for a `MergeMem`, this is really suspicious. I didn't fix it, as it seems to not result in any symptom at the moment.
> 
> In the end, the execution of the compiler is strictly more restricted than before, and there is less room for ambiguity.
> 
> Please take a look and leave your reviews, thanks a lot.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/28570

From xpeng at openjdk.org  Wed Feb  4 23:08:38 2026
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 4 Feb 2026 23:08:38 GMT
Subject: RFR: 8377126: Shenandoah: Convert ShenandoahVerifier related code
 to use Atomic<T>
In-Reply-To: <WwWN7V6-onaSKKJnwxN59Mr7BA6f94rUZmS2lkKzD8Y=.e072616c-6495-46b1-8cfe-79345ee31635@github.com>
References: <WwWN7V6-onaSKKJnwxN59Mr7BA6f94rUZmS2lkKzD8Y=.e072616c-6495-46b1-8cfe-79345ee31635@github.com>
Message-ID: <l68U0YNMdw4HpHqY80g1WY7k53dtc5MIZtDP7wQ5B2k=.0fa898e9-77be-4236-9f83-1d171c463d57@github.com>

On Wed, 4 Feb 2026 18:20:18 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

> Modernizes ShenandoahVerifier code by replacing `AtomicAccess` methods with `Atomic<T>` types.
> 
> Tier1 test results on x86_64 linux are the same before and after this change when running with `TEST_VM_OPTS=-XX:+UseShenandoahGC`.

LGTM, thanks!

-------------

Marked as reviewed by xpeng (Committer).

PR Review: https://git.openjdk.org/jdk/pull/29576#pullrequestreview-3753717179

From shade at openjdk.org  Thu Feb  5 07:33:31 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 5 Feb 2026 07:33:31 GMT
Subject: RFR: 8377126: Shenandoah: Convert ShenandoahVerifier related code
 to use Atomic<T>
In-Reply-To: <WwWN7V6-onaSKKJnwxN59Mr7BA6f94rUZmS2lkKzD8Y=.e072616c-6495-46b1-8cfe-79345ee31635@github.com>
References: <WwWN7V6-onaSKKJnwxN59Mr7BA6f94rUZmS2lkKzD8Y=.e072616c-6495-46b1-8cfe-79345ee31635@github.com>
Message-ID: <CNHa6gcQ2Lz1f6zP99KYSZZyOcHsyEoA7HSsoiNLgro=.a276f313-abf9-4f21-9015-87562efc6b2f@github.com>

On Wed, 4 Feb 2026 18:20:18 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

> Modernizes ShenandoahVerifier code by replacing `AtomicAccess` methods with `Atomic<T>` types.
> 
> Tier1 test results on x86_64 linux are the same before and after this change when running with `TEST_VM_OPTS=-XX:+UseShenandoahGC`.

src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp line 667:

> 665:     }
> 666: 
> 667:     _processed.add_then_fetch(processed);

Lost `memory_order_relaxed` here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29576#discussion_r2767523123

From stuefe at openjdk.org  Thu Feb  5 07:53:07 2026
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 5 Feb 2026 07:53:07 GMT
Subject: RFR: 8372566: Genshen: crash at
 ShenandoahScanRemembered::process_clusters after JDK-8371667 [v2]
In-Reply-To: <H7Of8lrvbu4DOgwPr59ZhQBhfstq5oE_2WHe-udrxLo=.dfdf83a9-0da0-4195-ba73-89043ee3ae1a@github.com>
References: <9K39uUxWtW6O-UsFRqrUXttqHu1K29lVAYNHcFMTaoc=.ab3856ff-55ff-4a23-ab33-870c9713e6ab@github.com>
 <6Y104R2wl_Z1TSFnYaYXRQdOzZGCCxXigrwBK8RM_r4=.265e3f37-88ff-4189-865b-8c17b6b8317a@github.com>
 <hLF8iL0C2wWQAzvASOHriOmlyAXDUayOs2ioq1GqKlU=.4a9cd6c7-d72f-4372-bfd2-d3e5f893b988@github.com>
 <H7Of8lrvbu4DOgwPr59ZhQBhfstq5oE_2WHe-udrxLo=.dfdf83a9-0da0-4195-ba73-89043ee3ae1a@github.com>
Message-ID: <Ogw-MtZgCEOTEVLCOzN5fUzhh8VIs9NNWtOhkbCbWDM=.5a37c294-2337-41c9-9527-7cb38300d097@github.com>

On Tue, 27 Jan 2026 18:01:10 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Thanks all for the reviews!
>
>> Hi, @pengxiaolong ,
>> 
>> I have user error reports for JDK 25. Cannot reproduce them myself, but they have in common
>> 
>> * Lilliput + GenShen
>> * SIGSEGV during marking phase
>> * disassembly seems to indicate we crash when trying in Klass::is_array_klass(). Crash address always in the narrow Klass decoding range. Most likely cause is reading a garbage markword from the heap, extracting a garbage narrow Klass pointer, then decoding it.
>> 
>> The second hs-err file in your JBS issue (the one with the segfault) looks similar, at least for the latter point. Even though the crash was in a different GC phase.
>> 
>> So, question: could this error happen in JDK 25? If yes, should the fix be downported?
> 
> Hi @tstuefe,
> 
> I believe it is a different bug in JDK25, this PR fix the bug caused by https://github.com/openjdk/jdk/pull/28247, which has not been backported to JDK25 yet. 
> Could you share more details of the crash? the hs-err file would be great, I can try to run the test and reproduce it.
> 
> Thanks.

> > Hi, @pengxiaolong ,
> > I have user error reports for JDK 25. Cannot reproduce them myself, but they have in common
> > 
> > * Lilliput + GenShen
> > * SIGSEGV during marking phase
> > * disassembly seems to indicate we crash when trying in Klass::is_array_klass(). Crash address always in the narrow Klass decoding range. Most likely cause is reading a garbage markword from the heap, extracting a garbage narrow Klass pointer, then decoding it.
> > 
> > The second hs-err file in your JBS issue (the one with the segfault) looks similar, at least for the latter point. Even though the crash was in a different GC phase.
> > So, question: could this error happen in JDK 25? If yes, should the fix be downported?
> 
> Hi @tstuefe,
> 
> I believe it is a different bug in JDK25, this PR fix the bug caused by #28247, which has not been backported to JDK25 yet. Could you share more details of the crash? the hs-err file would be great, I can try to run the test and reproduce it.
> 
> Thanks.

Hi @pengxiaolong, @kdnilsen,

I opened https://bugs.openjdk.org/browse/JDK-8377214 with my findings and the users' logs. In that bug, it looks like we fall over garbage narrow Klass pointers read from heap during marking. I assigned the bug to @kdnilsen so that it would not get lost.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28521#issuecomment-3851606510

From duke at openjdk.org  Thu Feb  5 08:54:12 2026
From: duke at openjdk.org (Harshit470250)
Date: Thu, 5 Feb 2026 08:54:12 GMT
Subject: RFR: 8347396: Efficient TypeFunc creations [v7]
In-Reply-To: <VQs3SMtk1y6xTi8nCvTeWsTFfCQlTJtDdCGnfWQmRmw=.f3b33ba1-3efe-477b-b6d2-b43faae9ee2b@github.com>
References: <VQs3SMtk1y6xTi8nCvTeWsTFfCQlTJtDdCGnfWQmRmw=.f3b33ba1-3efe-477b-b6d2-b43faae9ee2b@github.com>
Message-ID: <cyD5ndm075vVR5XCGymZ3WAr6K8VAU2MFEGvpoRBOq0=.bb186b53-9697-488c-8d87-021a514fa55d@github.com>

> This PR do similar changes done by [JDK-8330851](https://bugs.openjdk.org/browse/JDK-8330851) on the GC TypeFunc creation as suggested by [JDK-8347396](https://bugs.openjdk.org/browse/JDK-8347396). As discussed in [https://github.com/openjdk/jdk/pull/21782#discussion_r1906535686,](https://github.com/openjdk/jdk/pull/21782#discussion_r1906535686) I have put guard on the shenandoah gc specific part of the code.

Harshit470250 has updated the pull request incrementally with two additional commits since the last revision:

 - change name of init call
 - define shenandoah make_barrier_Type_init

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27279/files
  - new: https://git.openjdk.org/jdk/pull/27279/files/a4302cba..b4b6851e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27279&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27279&range=05-06

  Stats: 17 lines in 3 files changed: 9 ins; 6 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27279.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27279/head:pull/27279

PR: https://git.openjdk.org/jdk/pull/27279

From amitkumar at openjdk.org  Thu Feb  5 09:08:53 2026
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 5 Feb 2026 09:08:53 GMT
Subject: RFR: 8373595: A new ObjectMonitorTable implementation [v2]
In-Reply-To: <E-DcxoLSLFfZwb3TCalwptZEu3sJpOJP585CusdSHIM=.0f8f276d-7453-4492-adeb-fd097fb1b0d6@github.com>
References: <NpCJRO5OePJjpy3I-x4DV3C-NipfM9fkC9UvEwso4kw=.7fb88fe9-15e6-458e-ae43-77b3db67886d@github.com>
 <E-DcxoLSLFfZwb3TCalwptZEu3sJpOJP585CusdSHIM=.0f8f276d-7453-4492-adeb-fd097fb1b0d6@github.com>
Message-ID: <_4uxTH8CljdSGclVkrCDoiY7e4i-6UJ-zqjio5o8lZc=.306761ab-f726-4ad6-89a1-cb3e919336a9@github.com>

On Wed, 4 Feb 2026 14:57:39 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Me and Anton Artemov (@toxaart) investigated a quite large regression that occurred in Pet Clinic that happened if you turned on Compact Object Headers. It was found that a large portion of that regression could be attributed to not finding the monitor in the Object Monitor Cache, and because we couldn't access the Object Monitor Table from C2 generated code, we often had to take the slow path.
>> 
>> By making the object monitor cache larger and make it use the object's hash value as a key, we managed to mitigate the regression.
>> 
>> Erik ?sterlund (@fisk) took that idea and elevated it to the next level, which means that he rewrote the object monitor table code so that we can now search for an object in the global object monitor table from C2 generated code. I.e. from `C2_MacroAssembler::fast_lock()`. As in my and Anton's version, the key is the hash value from the object.
>> 
>> Erik also provided new barrier code needed for ZGC for x86 and aarch64. Roman Kennke (@rkennke) provided the same for Shenandoah, also for x86 and aarch64.
>> 
>> We decided to keep the Object Monitor Cache, since we found that for most programs (but not Pet Clinic) the monitor you are looking for is likely found in the first positions of the cache (it's sorted in most recently used order). However we decresed the size from 8 to 2 elements.
>> 
>> After running extensive performance tests we can say that this has improved the performance in many of them, not only mitigated the regression in Pet Clinic.
>> 
>> Tests are running okay tier1-7 on supported platforms.
>> 
>> The rest of the platforms (`ppc`, `riscv` and `s390`) have been smoke tested using QEMU.
>> I mainly used this test for smoke testing with QEMU: `-XX:+UnlockDiagnosticVMOptions -XX:+UseObjectMonitorTable ./test/hotspot/jtreg/runtime/Monitor/UseObjectMonitorTableTest.java `
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated all platforms after review comments

s390 code looks good now. I ran tier1 test as well, and no regression over there. 

Thanks a lot for the port.

-------------

Marked as reviewed by amitkumar (Committer).

PR Review: https://git.openjdk.org/jdk/pull/29383#pullrequestreview-3755411374

From wkemper at openjdk.org  Thu Feb  5 14:59:27 2026
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 5 Feb 2026 14:59:27 GMT
Subject: RFR: Merge openjdk/jdk21u:master
Message-ID: <RKXbSKSCv9jNNmHbQntDzlCYEeRVEgqjAv8_EYPswuE=.41011e7e-b5e0-483e-8eb6-4b7db9b75813@github.com>

Merges tag jdk-21.0.11+1

-------------

Commit messages:
 - 8356107: [java.lang] Use @requires tag instead of exiting based on os.name or separatorChar property
 - 8354219: Automate javax/swing/JComboBox/ComboPopupBug.java
 - 8355278: Improve debuggability of com/sun/jndi/ldap/LdapPoolTimeoutTest.java test
 - 8345578: New test in JDK-8343622 fails with a promoted build
 - 8372348: Adjust some UL / JFR string deduplication output messages
 - 8330016: Stress seed should be initialized for runtime stub compilation
 - 8375063: Update Libpng to 1.6.54
 - 8375549: ConcurrentModificationException if jdk.crypto.disabledAlgorithms has multiple entries with known oid
 - 8351639: Improve debuggability of test/langtools/jdk/jshell/JdiHangingListenExecutionControlTest.java test
 - 8075917: The regression-swing case failed as the text on label is not painted red with the GTK L&F
 - ... and 93 more: https://git.openjdk.org/shenandoah-jdk21u/compare/2e594b6c...2ce50303

The webrev contains the conflicts with master:
 - merge conflicts: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=233&range=00.conflicts

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/233/files
  Stats: 14895 lines in 361 files changed: 7757 ins; 4063 del; 3075 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/233.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/233/head:pull/233

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/233

From eastigeevich at openjdk.org  Thu Feb  5 16:10:23 2026
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Thu, 5 Feb 2026 16:10:23 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v25]
In-Reply-To: <fCOEaefEYCLAOC79UHKa3elPyu2Wve-eMvfo7kDeQqQ=.3af3d71f-2954-41bb-a94e-a0b12e85abea@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
 <s2L-YL6e2M4yAi3Y1I2FoZwCNPfwia0-wwV6SDLjkf4=.02e9ca45-0845-4d1e-b260-5105468466db@github.com>
 <fCOEaefEYCLAOC79UHKa3elPyu2Wve-eMvfo7kDeQqQ=.3af3d71f-2954-41bb-a94e-a0b12e85abea@github.com>
Message-ID: <u4r0c4d_QfDSqr-INzNzMrEVN4GVEJzipwVVNfYCWBI=.70970716-34a4-497a-828c-dc46a2b6ce90@github.com>

On Wed, 4 Feb 2026 14:23:08 GMT, Andrew Haley <aph at openjdk.org> wrote:

> What's the test plan for this? That is, how do we ensure the erratum-specific code path gets tested?

`test/hotspot/jtreg/gc/TestDeferredICacheInvalidation.java` is a minimal test checking no assert is triggered.
Other possible tests to write:
- If `NeoverseN1Errata1542419` is set then `UseDeferredICacheInvalidation` is set. There can be a set of tests checking those options are set correctly.
- There could be tests that involve multiple threads executing methods while GC is patching those methods.

Tests to run on Neoverse-N1:
- jcstress
- tier 1 - tier 4
- benchmarks: specjvm, specjbb, dacapo, renaissance

Does this plan look reasonable?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28328#issuecomment-3854622153

From btaylor at openjdk.org  Thu Feb  5 16:45:30 2026
From: btaylor at openjdk.org (Ben Taylor)
Date: Thu, 5 Feb 2026 16:45:30 GMT
Subject: RFR: 8377043: Shenandoah: Convert ShenandoahHeapRegion related code to
 use Atomic<T>
Message-ID: <dCwe2rCeNQxmU_eHCd497BjIrYr36J-xUyLp6z6m4dw=.4f0a1b33-f4e0-49d6-9464-bca38157645f@github.com>

Modernizes ShenandoahHeapRegion code by replacing `AtomicAccess` methods with `Atomic<T>` types.

Tier1 test results on x86_64 linux are the same before and after this change when running with `TEST_VM_OPTS=-XX:+UseShenandoahGC`.

-------------

Commit messages:
 - 8377043: Convert ShenandoahHeapRegion related code to use Atomic<T>

Changes: https://git.openjdk.org/jdk/pull/29575/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29575&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377043
  Stats: 37 lines in 4 files changed: 2 ins; 2 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/29575.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29575/head:pull/29575

PR: https://git.openjdk.org/jdk/pull/29575

From btaylor at openjdk.org  Thu Feb  5 16:54:34 2026
From: btaylor at openjdk.org (Ben Taylor)
Date: Thu, 5 Feb 2026 16:54:34 GMT
Subject: RFR: 8377126: Shenandoah: Convert ShenandoahVerifier related code
 to use Atomic<T> [v2]
In-Reply-To: <WwWN7V6-onaSKKJnwxN59Mr7BA6f94rUZmS2lkKzD8Y=.e072616c-6495-46b1-8cfe-79345ee31635@github.com>
References: <WwWN7V6-onaSKKJnwxN59Mr7BA6f94rUZmS2lkKzD8Y=.e072616c-6495-46b1-8cfe-79345ee31635@github.com>
Message-ID: <mnPfAiCAHT2CTeOPF8gZpx565BxQJXmpaMtk8lZri-g=.c5a418a8-f668-46fa-b708-f45895ff5364@github.com>

> Modernizes ShenandoahVerifier code by replacing `AtomicAccess` methods with `Atomic<T>` types.
> 
> Tier1 test results on x86_64 linux are the same before and after this change when running with `TEST_VM_OPTS=-XX:+UseShenandoahGC`.

Ben Taylor has updated the pull request incrementally with one additional commit since the last revision:

  Restore dropped  in shenandoahVerifier

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29576/files
  - new: https://git.openjdk.org/jdk/pull/29576/files/f5c311b4..87229bad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29576&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29576&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/29576.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29576/head:pull/29576

PR: https://git.openjdk.org/jdk/pull/29576

From shade at openjdk.org  Thu Feb  5 17:27:14 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 5 Feb 2026 17:27:14 GMT
Subject: RFR: 8377126: Shenandoah: Convert ShenandoahVerifier related code
 to use Atomic<T> [v2]
In-Reply-To: <mnPfAiCAHT2CTeOPF8gZpx565BxQJXmpaMtk8lZri-g=.c5a418a8-f668-46fa-b708-f45895ff5364@github.com>
References: <WwWN7V6-onaSKKJnwxN59Mr7BA6f94rUZmS2lkKzD8Y=.e072616c-6495-46b1-8cfe-79345ee31635@github.com>
 <mnPfAiCAHT2CTeOPF8gZpx565BxQJXmpaMtk8lZri-g=.c5a418a8-f668-46fa-b708-f45895ff5364@github.com>
Message-ID: <OP4aaSKtWBVPbYx5Ro2nHHBSRJ1Jg3FzQuQHDXo7Jyw=.3c74abec-2ffc-4e72-b7bd-083631bd47d7@github.com>

On Thu, 5 Feb 2026 16:54:34 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

>> Modernizes ShenandoahVerifier code by replacing `AtomicAccess` methods with `Atomic<T>` types.
>> 
>> Tier1 test results on x86_64 linux are the same before and after this change when running with `TEST_VM_OPTS=-XX:+UseShenandoahGC`.
>
> Ben Taylor has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore dropped  in shenandoahVerifier

Marked as reviewed by shade (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29576#pullrequestreview-3758424642

From wkemper at openjdk.org  Thu Feb  5 17:34:20 2026
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 5 Feb 2026 17:34:20 GMT
Subject: RFR: 8376839: GenShen: Improve performance of evacuations into the
 old generation [v3]
In-Reply-To: <Z288PGqFBbtMZ27wlMUh8r2qtvMk3Y3ko5BsmQRXquE=.0ef90b86-53b6-431c-bf7f-7119ca943e8d@github.com>
References: <Z288PGqFBbtMZ27wlMUh8r2qtvMk3Y3ko5BsmQRXquE=.0ef90b86-53b6-431c-bf7f-7119ca943e8d@github.com>
Message-ID: <MKwnrd6pAW9JxPc4WvO3F8EbZlilc0QgVd8LI-Mks9o=.77aabcfb-20bc-4f4e-b0ff-fb25a1a38dab@github.com>

> 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 three additional commits since the last revision:

 - Merge branch 'more-precise-rset-rebuild' into dirty-all-the-cards
 - Clear card table for young regions when full gc rebuilds remembered set
 - Dirty all the cards en masse
   
   This might be faster if less precise.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29511/files
  - new: https://git.openjdk.org/jdk/pull/29511/files/08bfab8b..f905138c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29511&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29511&range=01-02

  Stats: 69 lines in 1 file changed: 27 ins; 32 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 wkemper at openjdk.org  Thu Feb  5 17:34:21 2026
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 5 Feb 2026 17:34:21 GMT
Subject: RFR: 8376839: GenShen: Improve performance of evacuations into the
 old generation [v3]
In-Reply-To: <MKwnrd6pAW9JxPc4WvO3F8EbZlilc0QgVd8LI-Mks9o=.77aabcfb-20bc-4f4e-b0ff-fb25a1a38dab@github.com>
References: <Z288PGqFBbtMZ27wlMUh8r2qtvMk3Y3ko5BsmQRXquE=.0ef90b86-53b6-431c-bf7f-7119ca943e8d@github.com>
 <MKwnrd6pAW9JxPc4WvO3F8EbZlilc0QgVd8LI-Mks9o=.77aabcfb-20bc-4f4e-b0ff-fb25a1a38dab@github.com>
Message-ID: <excXY1HSNPdBPA4F3YhB-IDSsmbmlwsxWjDWE5AEmnI=.eb071c36-b748-47db-8d14-66d798a1adf0@github.com>

On Thu, 5 Feb 2026 17:31:58 GMT, William Kemper <wkemper at openjdk.org> 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.
>
> William Kemper has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Merge branch 'more-precise-rset-rebuild' into dirty-all-the-cards
>  - Clear card table for young regions when full gc rebuilds remembered set
>  - Dirty all the cards en masse
>    
>    This might be faster if less precise.

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1558:

> 1556:       // coalesce-and-fill processing.
> 1557:       r->end_preemptible_coalesce_and_fill();
> 1558:       _heap->old_generation()->clear_cards_for(r);

Clearing the card table and object starts when allocating new old regions likely contributed to slower evacuations in old generation. Cards are now cleared when old regions are recycled. We must also do this when a full GC switches the affiliation of regions from young to old.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29511#discussion_r2770328359

From wkemper at openjdk.org  Thu Feb  5 17:39:16 2026
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 5 Feb 2026 17:39:16 GMT
Subject: RFR: 8376839: GenShen: Improve performance of evacuations into the
 old generation [v3]
In-Reply-To: <RA1TDb9UP2zDxJa_SHnVNuOeHg1FEGiwacfXLenlIWA=.8d589aed-8f8e-40bc-bd82-9bbceacafb63@github.com>
References: <Z288PGqFBbtMZ27wlMUh8r2qtvMk3Y3ko5BsmQRXquE=.0ef90b86-53b6-431c-bf7f-7119ca943e8d@github.com>
 <WkvotZc49SzL-mvw8hGGaztJ_Jl2vZV2rI1kee2FieY=.f936d1e8-716d-4ba3-b703-73f8a3ad6514@github.com>
 <RA1TDb9UP2zDxJa_SHnVNuOeHg1FEGiwacfXLenlIWA=.8d589aed-8f8e-40bc-bd82-9bbceacafb63@github.com>
Message-ID: <yqGh3xGoLA9C8-u3dlaNF3TasrovSF98yuG9ulQ5I3M=.37edce9f-baa4-4d0b-acf1-299ea53c7e74@github.com>

On Mon, 2 Feb 2026 17:28:39 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> 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.

Latest round of testing shows that more precise card dirtying approximately doubles the time of this new phase with no significant reduction in average remembered set scan times.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29511#discussion_r2770346664

From kdnilsen at openjdk.org  Thu Feb  5 18:18:16 2026
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 5 Feb 2026 18:18:16 GMT
Subject: RFR: 8312116: GenShen: make instantaneous allocation rate triggers
 more timely [v24]
In-Reply-To: <AN1rtpFsazMdRtzTrcdFNqti6I-sVhnwTCzDH2gZJLQ=.84f227b4-849e-4728-9e1d-56c38d8c251d@github.com>
References: <AN1rtpFsazMdRtzTrcdFNqti6I-sVhnwTCzDH2gZJLQ=.84f227b4-849e-4728-9e1d-56c38d8c251d@github.com>
Message-ID: <95batM-97UOIYqamTcd-NbHYYeSzDSwhYqeWkAOWufg=.0fb157d7-850c-4c1c-9241-593b1cc972ed@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 with a new target base due to a merge or a rebase. The pull request now contains 91 commits:

 - Merge remote-tracking branch 'jdk/master' into accelerated-triggers
 - Make delay of acceleration trigger shorter
 - Delay accelerated trigger until some garbage has accumulated
 - Remove debug instrumentation
 - no need to set_mutator_free_after_updaterefs
 - Merge remote-tracking branch 'jdk/master' into accelerated-triggers
 - some cosmetic improvements
 - Use fewer samples to detect acceleration
 - align log messages for trigger trace
 - remove problematic debug messages
 - ... and 81 more: https://git.openjdk.org/jdk/compare/949370ab...d6dfa2c7

-------------

Changes: https://git.openjdk.org/jdk/pull/29039/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29039&range=23
  Stats: 1007 lines in 24 files changed: 902 ins; 41 del; 64 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  Thu Feb  5 18:43:00 2026
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 5 Feb 2026 18:43:00 GMT
Subject: RFR: 8377043: Shenandoah: Convert ShenandoahHeapRegion related
 code to use Atomic<T>
In-Reply-To: <dCwe2rCeNQxmU_eHCd497BjIrYr36J-xUyLp6z6m4dw=.4f0a1b33-f4e0-49d6-9464-bca38157645f@github.com>
References: <dCwe2rCeNQxmU_eHCd497BjIrYr36J-xUyLp6z6m4dw=.4f0a1b33-f4e0-49d6-9464-bca38157645f@github.com>
Message-ID: <gjYaGedE_MuOK6cDs1jhR_KYucTCa9lX5QP7iZFGJvk=.aa151a37-310d-4ca8-a71b-6f85b6b2a37d@github.com>

On Wed, 4 Feb 2026 18:20:17 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

> Modernizes ShenandoahHeapRegion code by replacing `AtomicAccess` methods with `Atomic<T>` types.
> 
> Tier1 test results on x86_64 linux are the same before and after this change when running with `TEST_VM_OPTS=-XX:+UseShenandoahGC`.

Looks good to me, thanks!

-------------

Marked as reviewed by xpeng (Committer).

PR Review: https://git.openjdk.org/jdk/pull/29575#pullrequestreview-3758761900

From xpeng at openjdk.org  Thu Feb  5 20:05:50 2026
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 5 Feb 2026 20:05:50 GMT
Subject: RFR: 8377126: Shenandoah: Convert ShenandoahVerifier related code
 to use Atomic<T> [v2]
In-Reply-To: <mnPfAiCAHT2CTeOPF8gZpx565BxQJXmpaMtk8lZri-g=.c5a418a8-f668-46fa-b708-f45895ff5364@github.com>
References: <WwWN7V6-onaSKKJnwxN59Mr7BA6f94rUZmS2lkKzD8Y=.e072616c-6495-46b1-8cfe-79345ee31635@github.com>
 <mnPfAiCAHT2CTeOPF8gZpx565BxQJXmpaMtk8lZri-g=.c5a418a8-f668-46fa-b708-f45895ff5364@github.com>
Message-ID: <UJu3qoSVH6ZcuX6xNiI4obhUlIrNL9BxnniwVNANXYw=.ce041008-bbfd-4a33-9e04-6bab7bece3c7@github.com>

On Thu, 5 Feb 2026 16:54:34 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

>> Modernizes ShenandoahVerifier code by replacing `AtomicAccess` methods with `Atomic<T>` types.
>> 
>> Tier1 test results on x86_64 linux are the same before and after this change when running with `TEST_VM_OPTS=-XX:+UseShenandoahGC`.
>
> Ben Taylor has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore dropped  in shenandoahVerifier

Still good, thanks!

-------------

Marked as reviewed by xpeng (Committer).

PR Review: https://git.openjdk.org/jdk/pull/29576#pullrequestreview-3759168196

From wkemper at openjdk.org  Thu Feb  5 21:04:00 2026
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 5 Feb 2026 21:04:00 GMT
Subject: RFR: 8377180: Shenandoah: make escalation from degen to full more
 conservative [v2]
In-Reply-To: <UDZhZUijMhKYVsU9wvCHI3ilPBZ9sfX9mm-rBTsZm68=.c9a4920e-0dae-40e1-b79a-559039e02802@github.com>
References: <oXA87tZwDFxnG-0laPzGM6_zGEgqrmw5VeTomO-RxpM=.5c20460a-b20d-48b3-8dec-835ff911a069@github.com>
 <UDZhZUijMhKYVsU9wvCHI3ilPBZ9sfX9mm-rBTsZm68=.c9a4920e-0dae-40e1-b79a-559039e02802@github.com>
Message-ID: <gMhjTgNqPAIMVuSxL7VR379uX8-QDuXONRJsymYO5Oc=.f634bd20-e25e-48c3-a251-83a756d131e7@github.com>

On Wed, 4 Feb 2026 17:46:50 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> 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.  See https://github.com/openjdk/jdk/pull/27456
>> 
>> 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 degenerates, 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:
>>        <- [       Conc GC       ] -> <- [ Degen    ] -> <- [            Full GC             ]
>>           [    experiences      ]       [  with    ]
>>           [     allocation      ]       [   bad    ]
>>           [      failure        ]       [ progress ]
>>                                         [ STW pause is 100 ms degen + 3s full GC            ]
>> 
>>    Revised behavior not to scale:
>>        <- [       Conc GC       ] -> <- [ Degen    ] -> <- [       Conc GC       ] -> [ Degen    ]
>>           [    experiences      ]       [  with    ]       [    experiences      ]    [  with    ]
>>           [     allocation      ]       [   bad    ]       [     allocation      ]    [  good    ]
>>           [      failure        ]       [ progress ]       [      failure        ]    [ progress ]
>>                                         [  100 ms  ]                                  [  100 ms  ] 
>>                                         [   pause  ]                                  [   pause  ]
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix gtest for ShenandoahCollectorPolicy

Looks good, suggest one small change.

src/hotspot/share/gc/shenandoah/shenandoahCollectorPolicy.hpp line 122:

> 120:   // Genshen will only upgrade to a full gc after the configured number of futile degenerated cycles.
> 121:   bool should_upgrade_degenerated_gc() const {
> 122:     return _consecutive_degenerated_gcs_without_progress >= GENERATIONAL_CONSECUTIVE_BAD_DEGEN_PROGRESS_THRESHOLD;

Shall we rename `GENERATIONAL_CONSECUTIVE_BAD_DEGEN_PROGRESS_THRESHOLD` as well? Perhaps `CONSECUTIVE_BAD_DEGEN_PROGRESS_THRESHOLD`?

-------------

Changes requested by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29574#pullrequestreview-3759449781
PR Review Comment: https://git.openjdk.org/jdk/pull/29574#discussion_r2771144740

From duke at openjdk.org  Thu Feb  5 21:19:46 2026
From: duke at openjdk.org (duke)
Date: Thu, 5 Feb 2026 21:19:46 GMT
Subject: RFR: 8377126: Shenandoah: Convert ShenandoahVerifier related code
 to use Atomic<T> [v2]
In-Reply-To: <mnPfAiCAHT2CTeOPF8gZpx565BxQJXmpaMtk8lZri-g=.c5a418a8-f668-46fa-b708-f45895ff5364@github.com>
References: <WwWN7V6-onaSKKJnwxN59Mr7BA6f94rUZmS2lkKzD8Y=.e072616c-6495-46b1-8cfe-79345ee31635@github.com>
 <mnPfAiCAHT2CTeOPF8gZpx565BxQJXmpaMtk8lZri-g=.c5a418a8-f668-46fa-b708-f45895ff5364@github.com>
Message-ID: <1djorDXv3XwEsODETkD4Kuo47HzX5UUw3WRhWau98Jw=.ec3ed535-b9ee-4053-afa8-b8d0a21283f0@github.com>

On Thu, 5 Feb 2026 16:54:34 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

>> Modernizes ShenandoahVerifier code by replacing `AtomicAccess` methods with `Atomic<T>` types.
>> 
>> Tier1 test results on x86_64 linux are the same before and after this change when running with `TEST_VM_OPTS=-XX:+UseShenandoahGC`.
>
> Ben Taylor has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore dropped  in shenandoahVerifier

@benty-amzn 
Your change (at version 87229bad6ec3d50bce64794c80b08c211a60613e) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29576#issuecomment-3856264690

From cslucas at openjdk.org  Thu Feb  5 21:39:37 2026
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 5 Feb 2026 21:39:37 GMT
Subject: RFR: 8377043: Shenandoah: Convert ShenandoahHeapRegion related
 code to use Atomic<T>
In-Reply-To: <dCwe2rCeNQxmU_eHCd497BjIrYr36J-xUyLp6z6m4dw=.4f0a1b33-f4e0-49d6-9464-bca38157645f@github.com>
References: <dCwe2rCeNQxmU_eHCd497BjIrYr36J-xUyLp6z6m4dw=.4f0a1b33-f4e0-49d6-9464-bca38157645f@github.com>
Message-ID: <8HnXSOHh_q32Z3Xv9Xvu02fClOTTv94R3kZeUiyfiDI=.b9b581f1-482d-46f4-b282-d0f639004b96@github.com>

On Wed, 4 Feb 2026 18:20:17 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

> Modernizes ShenandoahHeapRegion code by replacing `AtomicAccess` methods with `Atomic<T>` types.
> 
> Tier1 test results on x86_64 linux are the same before and after this change when running with `TEST_VM_OPTS=-XX:+UseShenandoahGC`.

LGTM, although I suggest testing on other platforms and tiers as well.

-------------

Marked as reviewed by cslucas (Committer).

PR Review: https://git.openjdk.org/jdk/pull/29575#pullrequestreview-3759588380

From dlong at openjdk.org  Thu Feb  5 22:11:50 2026
From: dlong at openjdk.org (Dean Long)
Date: Thu, 5 Feb 2026 22:11:50 GMT
Subject: RFR: 8347396: Efficient TypeFunc creations [v7]
In-Reply-To: <cyD5ndm075vVR5XCGymZ3WAr6K8VAU2MFEGvpoRBOq0=.bb186b53-9697-488c-8d87-021a514fa55d@github.com>
References: <VQs3SMtk1y6xTi8nCvTeWsTFfCQlTJtDdCGnfWQmRmw=.f3b33ba1-3efe-477b-b6d2-b43faae9ee2b@github.com>
 <cyD5ndm075vVR5XCGymZ3WAr6K8VAU2MFEGvpoRBOq0=.bb186b53-9697-488c-8d87-021a514fa55d@github.com>
Message-ID: <5_jm8COPxw1tUhgoGmUGeMszwGD37tte0cKZVmmCozo=.b29e21b7-8111-486d-9916-b93a09c7c44b@github.com>

On Thu, 5 Feb 2026 08:54:12 GMT, Harshit470250 <duke at openjdk.org> wrote:

>> This PR do similar changes done by [JDK-8330851](https://bugs.openjdk.org/browse/JDK-8330851) on the GC TypeFunc creation as suggested by [JDK-8347396](https://bugs.openjdk.org/browse/JDK-8347396). As discussed in [https://github.com/openjdk/jdk/pull/21782#discussion_r1906535686,](https://github.com/openjdk/jdk/pull/21782#discussion_r1906535686) I have put guard on the shenandoah gc specific part of the code.
>
> Harshit470250 has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - change name of init call
>  - define shenandoah make_barrier_Type_init

Marked as reviewed by dlong (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27279#pullrequestreview-3759718643

From kdnilsen at openjdk.org  Thu Feb  5 22:22:34 2026
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 5 Feb 2026 22:22:34 GMT
Subject: RFR: 8377043: Shenandoah: Convert ShenandoahHeapRegion related
 code to use Atomic<T>
In-Reply-To: <dCwe2rCeNQxmU_eHCd497BjIrYr36J-xUyLp6z6m4dw=.4f0a1b33-f4e0-49d6-9464-bca38157645f@github.com>
References: <dCwe2rCeNQxmU_eHCd497BjIrYr36J-xUyLp6z6m4dw=.4f0a1b33-f4e0-49d6-9464-bca38157645f@github.com>
Message-ID: <E73fEvVHqc8EwkypJLtjbjfPUG-gHEWKjRZe1-eZ0QE=.c9351bae-76b0-4146-b2e9-be26d0e624ae@github.com>

On Wed, 4 Feb 2026 18:20:17 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

> Modernizes ShenandoahHeapRegion code by replacing `AtomicAccess` methods with `Atomic<T>` types.
> 
> Tier1 test results on x86_64 linux are the same before and after this change when running with `TEST_VM_OPTS=-XX:+UseShenandoahGC`.

Thanks.

-------------

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/29575#pullrequestreview-3759755707

From kdnilsen at openjdk.org  Thu Feb  5 22:25:37 2026
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 5 Feb 2026 22:25:37 GMT
Subject: RFR: 8377180: Shenandoah: make escalation from degen to full more
 conservative [v2]
In-Reply-To: <gMhjTgNqPAIMVuSxL7VR379uX8-QDuXONRJsymYO5Oc=.f634bd20-e25e-48c3-a251-83a756d131e7@github.com>
References: <oXA87tZwDFxnG-0laPzGM6_zGEgqrmw5VeTomO-RxpM=.5c20460a-b20d-48b3-8dec-835ff911a069@github.com>
 <UDZhZUijMhKYVsU9wvCHI3ilPBZ9sfX9mm-rBTsZm68=.c9a4920e-0dae-40e1-b79a-559039e02802@github.com>
 <gMhjTgNqPAIMVuSxL7VR379uX8-QDuXONRJsymYO5Oc=.f634bd20-e25e-48c3-a251-83a756d131e7@github.com>
Message-ID: <UnCB2izoN_q4YGzw6CwPjvqKfgUVrgVNvdAb8MKzOpo=.6cc2e538-6a97-459b-9a85-87cb5d4fc754@github.com>

On Thu, 5 Feb 2026 21:00:58 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix gtest for ShenandoahCollectorPolicy
>
> src/hotspot/share/gc/shenandoah/shenandoahCollectorPolicy.hpp line 122:
> 
>> 120:   // Genshen will only upgrade to a full gc after the configured number of futile degenerated cycles.
>> 121:   bool should_upgrade_degenerated_gc() const {
>> 122:     return _consecutive_degenerated_gcs_without_progress >= GENERATIONAL_CONSECUTIVE_BAD_DEGEN_PROGRESS_THRESHOLD;
> 
> Shall we rename `GENERATIONAL_CONSECUTIVE_BAD_DEGEN_PROGRESS_THRESHOLD` as well? Perhaps `CONSECUTIVE_BAD_DEGEN_PROGRESS_THRESHOLD`?

Sure.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29574#discussion_r2771410369

From kdnilsen at openjdk.org  Thu Feb  5 22:32:44 2026
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 5 Feb 2026 22:32:44 GMT
Subject: RFR: 8377180: Shenandoah: make escalation from degen to full more
 conservative [v3]
In-Reply-To: <oXA87tZwDFxnG-0laPzGM6_zGEgqrmw5VeTomO-RxpM=.5c20460a-b20d-48b3-8dec-835ff911a069@github.com>
References: <oXA87tZwDFxnG-0laPzGM6_zGEgqrmw5VeTomO-RxpM=.5c20460a-b20d-48b3-8dec-835ff911a069@github.com>
Message-ID: <_n936ekjoiLn1UK9n2hRUWzov1EIHoP46h-WfudjH3c=.37563954-4a2e-49ea-b0d8-7679c2744251@github.com>

> 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.  See https://github.com/openjdk/jdk/pull/27456
> 
> 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 degenerates, 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:
>        <- [       Conc GC       ] -> <- [ Degen    ] -> <- [            Full GC             ]
>           [    experiences      ]       [  with    ]
>           [     allocation      ]       [   bad    ]
>           [      failure        ]       [ progress ]
>                                         [ STW pause is 100 ms degen + 3s full GC            ]
> 
>    Revised behavior not to scale:
>        <- [       Conc GC       ] -> <- [ Degen    ] -> <- [       Conc GC       ] -> [ Degen    ]
>           [    experiences      ]       [  with    ]       [    experiences      ]    [  with    ]
>           [     allocation      ]       [   bad    ]       [     allocation      ]    [  good    ]
>           [      failure        ]       [ progress ]       [      failure        ]    [ progress ]
>                                         [  100 ms  ]                                  [  100 ms  ] 
>                                         [   pause  ]                                  [   pause  ]

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  Fix constant name and comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29574/files
  - new: https://git.openjdk.org/jdk/pull/29574/files/0f094a68..d8d5423f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29574&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29574&range=01-02

  Stats: 11 lines in 1 file changed: 0 ins; 7 del; 4 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 btaylor at openjdk.org  Thu Feb  5 22:47:40 2026
From: btaylor at openjdk.org (Ben Taylor)
Date: Thu, 5 Feb 2026 22:47:40 GMT
Subject: Integrated: 8377126: Shenandoah: Convert ShenandoahVerifier related
 code to use Atomic<T>
In-Reply-To: <WwWN7V6-onaSKKJnwxN59Mr7BA6f94rUZmS2lkKzD8Y=.e072616c-6495-46b1-8cfe-79345ee31635@github.com>
References: <WwWN7V6-onaSKKJnwxN59Mr7BA6f94rUZmS2lkKzD8Y=.e072616c-6495-46b1-8cfe-79345ee31635@github.com>
Message-ID: <N2N8r7WoJ8xhkaLi4EPo2sElTUgfRpfbYYZ70OkSJUs=.a10994d6-2fb0-4bbe-b41c-a3c1a86d203b@github.com>

On Wed, 4 Feb 2026 18:20:18 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

> Modernizes ShenandoahVerifier code by replacing `AtomicAccess` methods with `Atomic<T>` types.
> 
> Tier1 test results on x86_64 linux are the same before and after this change when running with `TEST_VM_OPTS=-XX:+UseShenandoahGC`.

This pull request has now been integrated.

Changeset: b9c0e053
Author:    Ben Taylor <btaylor at openjdk.org>
Committer: Xiaolong Peng <xpeng at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b9c0e0537f979534b12ba6c44b6cf35a8ed78f89
Stats:     14 lines in 2 files changed: 0 ins; 0 del; 14 mod

8377126: Shenandoah: Convert ShenandoahVerifier related code to use Atomic<T>

Reviewed-by: xpeng, shade, wkemper

-------------

PR: https://git.openjdk.org/jdk/pull/29576

From kdnilsen at openjdk.org  Thu Feb  5 22:56:07 2026
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 5 Feb 2026 22:56:07 GMT
Subject: RFR: 8377180: Shenandoah: make escalation from degen to full more
 conservative [v4]
In-Reply-To: <oXA87tZwDFxnG-0laPzGM6_zGEgqrmw5VeTomO-RxpM=.5c20460a-b20d-48b3-8dec-835ff911a069@github.com>
References: <oXA87tZwDFxnG-0laPzGM6_zGEgqrmw5VeTomO-RxpM=.5c20460a-b20d-48b3-8dec-835ff911a069@github.com>
Message-ID: <ohv1qvnfSi6hSc0miWAZDufBS7rfdM0XN7ycEXZXgcY=.0e44dd87-4463-4f88-9b57-1e616119db10@github.com>

> 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.  See https://github.com/openjdk/jdk/pull/27456
> 
> 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 degenerates, 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:
>        <- [       Conc GC       ] -> <- [ Degen    ] -> <- [            Full GC             ]
>           [    experiences      ]       [  with    ]
>           [     allocation      ]       [   bad    ]
>           [      failure        ]       [ progress ]
>                                         [ STW pause is 100 ms degen + 3s full GC            ]
> 
>    Revised behavior not to scale:
>        <- [       Conc GC       ] -> <- [ Degen    ] -> <- [       Conc GC       ] -> [ Degen    ]
>           [    experiences      ]       [  with    ]       [    experiences      ]    [  with    ]
>           [     allocation      ]       [   bad    ]       [     allocation      ]    [  good    ]
>           [      failure        ]       [ progress ]       [      failure        ]    [ progress ]
>                                         [  100 ms  ]                                  [  100 ms  ] 
>                                         [   pause  ]                                  [   pause  ]

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  Fix comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29574/files
  - new: https://git.openjdk.org/jdk/pull/29574/files/d8d5423f..cb40a211

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29574&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29574&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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  Thu Feb  5 23:37:17 2026
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 5 Feb 2026 23:37:17 GMT
Subject: RFR: 8377180: Shenandoah: make escalation from degen to full more
 conservative [v4]
In-Reply-To: <ohv1qvnfSi6hSc0miWAZDufBS7rfdM0XN7ycEXZXgcY=.0e44dd87-4463-4f88-9b57-1e616119db10@github.com>
References: <oXA87tZwDFxnG-0laPzGM6_zGEgqrmw5VeTomO-RxpM=.5c20460a-b20d-48b3-8dec-835ff911a069@github.com>
 <ohv1qvnfSi6hSc0miWAZDufBS7rfdM0XN7ycEXZXgcY=.0e44dd87-4463-4f88-9b57-1e616119db10@github.com>
Message-ID: <m-mBs5Hj0V3L7nKocz0Zizx3fCxUcBpZDECw_vjin4g=.e54261c0-2896-4253-bbda-0804db285764@github.com>

On Thu, 5 Feb 2026 22:56:07 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> 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.  See https://github.com/openjdk/jdk/pull/27456
>> 
>> 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 degenerates, 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:
>>        <- [       Conc GC       ] -> <- [ Degen    ] -> <- [            Full GC             ]
>>           [    experiences      ]       [  with    ]
>>           [     allocation      ]       [   bad    ]
>>           [      failure        ]       [ progress ]
>>                                         [ STW pause is 100 ms degen + 3s full GC            ]
>> 
>>    Revised behavior not to scale:
>>        <- [       Conc GC       ] -> <- [ Degen    ] -> <- [       Conc GC       ] -> [ Degen    ]
>>           [    experiences      ]       [  with    ]       [    experiences      ]    [  with    ]
>>           [     allocation      ]       [   bad    ]       [     allocation      ]    [  good    ]
>>           [      failure        ]       [ progress ]       [      failure        ]    [ progress ]
>>                                         [  100 ms  ]                                  [  100 ms  ] 
>>                                         [   pause  ]                                  [   pause  ]
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment

Marked as reviewed by wkemper (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29574#pullrequestreview-3759952680