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

[Aditya Mandaleeka]

On Tue, 25 May 2021 04:42:08 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 two additional commits since the last revision:
> 
>  - Add G1 configuration option for proactive collections.
>  - Minor indentation/formatting improvements.

@stefank Thanks for pointing out the indentations/formatting. I've fixed them.

I've also pushed an update introducing a config flag for controlling this feature (on by default).

And finally, for the naming discussion, I'm okay with renaming it to "preventive" if that's preferable. I also think "proactive" is fine as-is, but I understand if people don't want to reuse the same term used in another collector for a different purpose.

I am not a fan of "preemptive" for this because there's nothing about these GCs that is more preemptive than other GCs. "Predictive" as raised by Bernd is okay, but I _think_ the strict definition of that word relates to prediction itself (predictive power, predictive sign, etc.) and not to the thing being predicted.

In any case, I didn't want to make any naming changes until there's some consensus, so I'm leaving it as-is for now.

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

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