RFR: Fix fullgc

[William Kemper]

On Wed, 8 Jun 2022 22:00:15 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Two errors were recently discovered in the generational-mode implementation of FullGC:
> 
> 1. There was an off-by-one error which caused full-gc to promote one cycle later than intent.
> 2. During a post-compaction phase of full-gc, certain old-gen regions were relabeled as young-gen, sometimes resulting in young-gen having usage above its capacity.  When this occurs, further allocations are blocked because available within young-gen is zero (actually is negative).

Does it make sense to remove the side-effect of `make_regular_bypass`. It's probably a vestige of an out-dated version of the generational support for Full GC.

src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp line 838:

> 836:     if (r->is_cset()) {
> 837:       // If generational, leave affiliation alone.
> 838:       r->make_regular_bypass(!is_generational);

So - if we are not in generational mode, we will set the affiliation to `YOUNG`, is that necessary when we are not in generational mode? Wouldn't it already be young (or free) in that mode?

And when we are in generational mode, we don't want to change the affiliation. Should we just remove this affiliation changing side-effect of `make_regular_bypass`?

src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp line 1347:

> 1345:           ShenandoahHeapRegion* r = heap->get_region(c);
> 1346:           // Consider regions emptied by humongous evacuation to be young
> 1347:           r->make_regular_bypass(true);

If we remove the side-effect of `make_regular_bypass`, we would have something like:

if (r->is_humongous_start() || r->is_humongous_cont()) {
  r->set_affiliation(YOUNG);
}

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

Changes requested by wkemper (Committer).

PR: https://git.openjdk.java.net/shenandoah/pull/142