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

[Thomas Schatzl]

On Thu, 29 Apr 2021 18:41:24 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:
>> - _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.
>> - _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:
> 
>   Remove temp comment.

Fyi, I've been running this change through our performance test suite, and there are two notable differences in results in the Renaissance benchmark suite (http://renaissance.dev):
* Renaissance-Neo4jAnalytics improves in scores (avg. runtime) by ~10%
* Renaissance-Scrabble decreases in scores (avg. runtime) by ~10%

We use the JMH wrappers which should be part of the benchmark suite (I think), and run jmh with `-t 1 -i 15 -wi 25 -f 10`.

Original results:

Result "org.renaissance.jdk.streams.JmhScrabble.runOperation":
  N = 150
  mean =    232.878 ±(99.9%) 5.846 ms/op

Changes:

Result "org.renaissance.jdk.streams.JmhScrabble.runOperation":
  N = 150
  mean =    265.658 ±(99.9%) 11.011 ms/op


There are significant differences I can't explain right now. It may be due to (since we do not use any special VM options except logging) heap sizing or similar, but can you look into this a bit?
I'll probably retry with a rebase on latest, maybe I screwed up with the builds. There is no proactive gc in this particular benchmark run, but I can see that e.g. neo4j has some, so builds should be correct.

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

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