RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v12]

[Thomas Stuefe]

On Wed, 7 Jun 2023 14:06:31 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Hi Thomas,
> 
> Thank you for your followup comments. I am in total agreement that it is a shame the challenges we have faced and the progress we have made is not better documented in the history of JBS tickets. I have been the worst offender. I apologize.

Please, no need to apologize. I understand that during early development one needs to move quickly. I just thought that your team's experience with tuning Shenandoah is valuable, and it is regrettable when it is lost.

> You are correct that the change is to N, the number of times in a row that we perform degenerated GC before we automatically upgrade to Full GC. It is still possible that we will upgrade to Full GC before N is reached, because there are other situations, such as lack of progress by degenerated GC, that will cause us to upgrade to Full even before N is reached.
> 
> The comment is still valid as written. During degenerated GC, the mutator threads are all blocked, so the ONLY kind of allocation failure that can occur during degenerated GC is a GC-worker-thread allocation for the purpose of evacuating memory. If we experience an "evacuation failure" during degenerated GC. we will upgrade to Full GC.

Thank you for the thorough explanation.

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

PR Comment: https://git.openjdk.org/jdk/pull/14185#issuecomment-1581232734