RFR: 8268163: Change the order of fallback full GCs in G1
tschatzl at openjdk.java.net
Tue Jun 8 14:53:18 UTC 2021
On Mon, 7 Jun 2021 10:04:57 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:
>> 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?
Fwiw, I am good with either, i.e. do a maximally compacting gc or not; both will likely free some space but the non-maximally compacting should be faster. Maybe this change should just remove the third full gc, and in a separate change think about the upgrade policy. I already filed https://bugs.openjdk.java.net/browse/JDK-8268393 for such work.
More information about the hotspot-gc-dev