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

[Stefan Johansson]

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.

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?

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

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