On Wed, 7 Jun 2023 14:06:31 GMT, Kelvin Nilsen <kdnil...@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
