RFR: 8348400: GenShen: assert(ShenandoahHeap::heap()->is_full_gc_in_progress() || (used_regions_size() <= _max_capacity)) failed: Cannot use more than capacity #

[Y. Srinivas Ramakrishna]

On Thu, 23 Jan 2025 21:36:37 GMT, William Kemper <wkemper at openjdk.org> wrote:

> When the capacity of a trashed region is transferred from the young to old generation, we must first recycle the region to break its affiliation with the young generation. Failing to do this may violate the constraint that the capacity of a generation is always equal to or greater than the capacity of its affiliated regions.

Looks good (but seemed tricky to reason about; I left some comments questions, but these are more for me to understand the full context of state transitions than as a formal review necessarily).

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

> 1298:   if (!transferred) {
> 1299:     log_warning(gc, free)("Forcing transfer of %zu to old reserve.", idx);
> 1300:     if (r->is_trash() && r->is_young()) {

I see that you don't unnecessarily want to recycle eagerly here unless the transfer attempt fails (which it could for one of several reasons).

But can you share the disadvantage of always checking if the region is trash and recycling eagerly first? I can see that eager check and recycling unnecessarily slows down this path which can make the evacuation path slightly more heavyweight sometimes.

I also noticed that the allocation paths allow for the region being fresh trash that is unrecycled and therefore would try the recycle regardless, so this does look like it's being done only to satisfy the size invariant checks, and not to get any more efficiency from skipping the recycle.

Could recycling of trash be happening concurrently such that our skipping it here can sometimes make things faster because it's been done by the time we start allocating into it?

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23282#pullrequestreview-2573651629
PR Review Comment: https://git.openjdk.org/jdk/pull/23282#discussion_r1929278125