RFR: 8268163: Change the order of fallback full GCs in G1

Stefan Johansson sjohanss at openjdk.java.net
Mon Jun 7 10:08:01 UTC 2021


On Mon, 7 Jun 2021 08:51:51 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to make the order of G1 Full GCs a bit more straight forward.
>> 
>> **Summary**
>> 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).
>> 
>> **Testing**
>> Tier 1-3, plus manual testing looking at output in near OOM situations.
>
> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1102:
> 
>> 1100:   bool success = do_full_collection(false /* explicit gc */,
>> 1101:                                     true  /* clear_all_soft_refs */,
>> 1102:                                     false /* do_maximum_compaction */);
> 
> Shouldn't this have `do_maximum_compaction` == true?  That's what the change to `VM_G1CollectForAllocation` expects.  In which case, do we really need separate arguments for `do_full_collection` for `clear_all_soft_refs` and `do_maximum_compaction` or could they be collapsed to one `maximum_compaction` argument?

This is currently the only case where we need separate arguments for the two. So previously the "upgraded" Full collections used `clear_all_soft_refs == true` and `do_maximum_compaction == false`, so I kept it that way. In some sense I think this is fine, when upgrading this is the first time we try a Full GC so leaving dead wood (`maximum==false`) could still find some space. It is only when we attempt a second Full collection in a row we set `do_maximum_compaction == true`. Makes sense, or do you think we should force a "maximum compaction" when upgrading?

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

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


More information about the hotspot-gc-dev mailing list