Fail threshold for GC

[eugene-krivobokov]

Current use case

Using GCWarningThreshold highlights the problems in some scenarios.
Unfortunately, users rarely notice it. We react to this only after some time.

I'd like to answer to possible questions in advance:

Why can't we just increase Xmx one time?

1. It's not obvious how to choose the best value for all users.

We have a big mono repository with multiple apps.
Choosing Xmx for the worst scenario looks controversial:

• It depends on scenarios. Some are heavy and rarely used.
• Some users have lower RAM sizes
• It depends on parallelism - Gradle max workers

2. It's a reactive approach with monitoring warnings with unpredicted lag.

The value must be reevaluated after any significant change in the project (AGP, Gradle, Kotlin, ... versions, and so on) and while growing the codebase.

Why can't we just use -XX:+UseParallelGC -XX:+UseGCOverheadLimit -XX:GCTimeLimit=N?

In our benchmarks, G1 somehow shows better performance results than ParallelGC.
Also, ParallelGC can't shrink unused memory and return it to the OS (Java 11)

Proposed use case

Add an option to fail the build:

GCFailThreshold = 0.9f

It will give a strong signal to decide what to do.
Thus we won't need to monitor warnings. The final goal is to have stronger guarantees about not wasting time in GC.