RFR: 8376839: GenShen: Improve performance of evacuations into the old generation [v3]
Xiaolong Peng
xpeng at openjdk.org
Mon Feb 9 21:24:43 UTC 2026
On Thu, 5 Feb 2026 17:34:20 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/shenandoahOldGeneration.cpp line 641:
> 639: // when the in-place-promotion is completed. Such a region may be used for additional
> 640: // promotions in the same cycle it was itself promoted.
> 641: _card_scan->update_card_table(region->get_top_at_evac_start(), region->top());
parallel_heap_region_iterate(which is used by for_each_region) use single thread if the number of is <= 4096; the assumption is for most of lightweight task, for example, capturing TAMS at init mark, the overhead of multiple threads is more expensive than the task itself. For more complicated task, we may not want to use parallel_heap_region_iterate, I had a [PR](https://github.com/openjdk/jdk/pull/28613) recently to address this kind of issue in bitmap reset.
I'm not sure update_card_table is suitable to use parallel_heap_region_iterate after reading the impl, I saw you also added timing metrics for it, you can do some simple test to verify it.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/29511#discussion_r2784359317
More information about the hotspot-gc-dev
mailing list