RFR: 8268163: Change the order of fallback full GCs in G1
sjohanss at openjdk.java.net
Wed Jun 9 13:47:16 UTC 2021
On Tue, 8 Jun 2021 14:46:47 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
>> Please review this change to make the order of G1 Full GCs a bit more straight forward.
>> In [JDK-8233822](https://bugs.openjdk.java.net/browse/JDK-8233822) the way Full GCs were scheduled was changed a bit to support a use-case introduced by [JDK-8202286](https://bugs.openjdk.java.net/browse/JDK-8202286) (which allowed the heap to have the old generation on an alternative memory device). This feature has been removed ([JDK-8256181](https://bugs.openjdk.java.net/browse/JDK-8256181)), but the Full GC scheduling has not been reverted. This can lead to situations where we do three Full GCs in a row. Doing more than two seems a bit over the top, so this change more or less reverts back to the old behavior
>> * Young collection requesting to allocate when done will cause at most two Full GCs, the first will not clear any soft references and allow dead wood to be left. The second one, if still not able to satisfy the allocation will clear soft references and compact everything not allowing any dead wood.
>> * For concurrent start collections and young collections not requesting any allocation, one Full GC will be scheduled if no regions were freed up by the initial collection.
>> A change compared to current behavior is that a concurrent collection started because of the metadata threshold not being met, will no longer be upgraded to a Full GC. This is still equal to how things were handled prior to [JDK-8233822](https://bugs.openjdk.java.net/browse/JDK-8233822).
>> Tier 1-3, plus manual testing looking at output in near OOM situations.
> Marked as reviewed by tschatzl (Reviewer).
Thanks for the reviews @tschatzl and @kimbarrett!
As Kim mention there will be another follow up on this that will remove the check on the gc-cause in `should_upgrade_to_full_gc(GCCause)` (see [JDK-8268390](https://bugs.openjdk.java.net/browse/JDK-8268390)). We can't do that in this change since it would re-introduce the assertion-failure in [JDK-8195158](https://bugs.openjdk.java.net/browse/JDK-8195158). The assertion is caused because we use the "system GC cause" but the explicit flag is not set. I have another change out for review that I will integrate short after this one, PR #4357, it will add a new GC cause for upgraded GCs. So in the future an upgraded system GC would not keep that cause and the assertion will no longer trigger.
More information about the hotspot-gc-dev