RFR: 8257774: G1: Trigger collect when free region count drops below threshold to prevent evacuation failures [v9]

Stefan Johansson sjohanss at openjdk.java.net
Tue Jun 1 08:29:21 UTC 2021

On Sat, 29 May 2021 05:58:51 GMT, Aditya Mandaleeka <adityam at openjdk.org> wrote:

>> _This PR picks up from [this previous PR](https://github.com/openjdk/jdk/pull/1650) by @charliegracie._
>> I won't repeat the full description from the prior PR, but the general idea is to add the notion of a "proactive GC" to G1 which gets triggered in the slow allocation path if the number of free regions drops below the amount that would be required to complete a GC if it happened at that moment. The threshold is based on the survival rates from eden and survivor spaces along with the space required for tenured space evacuations.
>> There are a couple of outstanding issues/questions known:
>> - [Update: This has been resolved] _Interaction with GCLocker_: In the case where we determine that a proactive GC is required and GC locker is active, we don't allow the young gen to expand (instead threads will stall). @tschatzl raised this and suggested that it should be discussed as part of the review.
>> - [Update: This has been resolved] _Disable proactive GC heuristic during initialization_: I ran into an issue in testing where code in the universe initialization codepath was tripping the proactive GC heuristic, leading to a GC being triggered before the VM has finished initialization. I need to find a good way to prevent this from happening. There may already be a mechanism for this, but I couldn't find one so I added a temporary placeholder (`zzinit_complete`) just to unblock testing.
> Aditya Mandaleeka has updated the pull request incrementally with one additional commit since the last revision:
>   Rename proactive to preventive.

> _Mailing list message from [Kirk Pepperdine](mailto:kirk at kodewerk.com) on [hotspot-gc-dev](mailto:hotspot-gc-dev at mail.openjdk.java.net):_
> Hi Stefan,
> > The failing test made me look a bit more at the logs when running with this feature and I found at least one thing I think we need to fix.
> > What I did was to run SPECjbb2015 with a fixed injection-rate and and with tweaked parameters to force a bit more live objects. Running this with an 8g heap was fine and I saw no "preventive" GCs. Turning the heap size down to 6gb the preventive GCs started to show and we do a lot more GCs with this patch than without, but looking at the total GC time it is pretty similar to before. So not sure how much to care about this.
> > What I think we should change, or at least discuss is the fact that we now get:
> > [340,066s][info][gc             ] GC(3148) Pause Full (G1 Preventive Collection) 6091M->3082M(6144M) 726,846ms
> > A "preventive" Full GC looks a bit strange to me, I mean the Full GC occurs because we failed not prevent it. So I think we should avoid using this GC cause for Full collections. What do others think?
> This is certainly not preventing a full GC implying that the name is misleading.
It is certainly misleading for the Full GC, but for normal collections I think it's the best alternative presented so far. You are not always certain that a preventive measure will be successful. 

> At 8G, I?m not sure that I care all that much about a full collection being triggered but it?s at a threshold where I?m going to take notice. At issue is? it?s very unlikely that we?d want to see a full collection when heaps get bigger than this. I?d much rather set a larger reserve or take other measures to prevent the failure rather than endure the penalty of a full collection.

I agree, in cases like this the best thing from a configuration perspective is to give more memory to the process and hopefully avoid the Full GCs. But we still need to test and make sure a feature like this handle high heap occupancy in a good way. I did some extended runs during the night and after a while the "preventive" GCs occur even for the 8g case. But the overall numbers still look ok, currently running a less stressful configuration to make sure that is even less affected.


PR: https://git.openjdk.java.net/jdk/pull/3143

More information about the hotspot-gc-dev mailing list