RFR: Fix fullgc

[Kelvin Nilsen]

On Wed, 8 Jun 2022 22:37:35 GMT, William Kemper <wkemper 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).
>
> 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`?

You raise good questions here.  I was not sure why make_regular_bypass() wanted to overwrite affiliation with young.  I knew it shouldn't do it in the case I was observing.  I was trying to effect only my use case so as not to break other "use cases".

I'll think a bit harder on this.

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

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