RFR: 8317755: G1: Periodic GC interval should test for the last whole heap GC

[Thomas Schatzl]

On Mon, 9 Oct 2023 20:46:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the description in the bug. Fortunately, we already track the last whole-heap GC. The new regression test verifies the behavior.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `tier1 tier2 tier3`

Initial comments when looking at it:

>From what I understand from the CR description, the VM is not completely idle but has GCs now and then which do not (or almost do not) increase old gen occupancy.

So the problem seems to be that the existing policy for the periodic gcs does not detect idleness (and the request to give back memory) in this case. The JEP mentions the `G1PeriodicGCSystemLoadThreshold` option to improve upon that. Maybe use of it is an option in this case?

This is probably a significant behavioral change which I think is unintended: if the user enabled to use execution of a full gc instead of a concurrent marking - then instead of chugging along if there is at least some activity, there would be regular full gcs now regardless of "being idle" (depending on how you see idle; very long periodis of only young gcs can be induced by e.g. an overly large heap). I do not think this is expected, even if the user asked for full gcs for periodic gcs.

Because this topic about periodic gcs has come up a few times, the RFE does not describe the actual situation you are in, so it would be interesting to have more information. For example, would it be acceptable to have some kind of interaction with the VM to set e.g.  `SoftMaxHeapSize` at idle? It is kind of hard to cover all "idle" situations and this has been part of the discussion in the original JEP, and this change seems to try to fix this with the imo fairly crude hammer of "guarantee a whole heap analysis" regularly instead.
Which is not necessarily incompatible with the current mechanism (i.e. an either-or situation).

There may be other aspects of this suggestion.

Formal things: This is a significant behavioral change which needs a CSR imo. The referenced JEP exactly defines the expected behavior to listen to young gcs.

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

PR Comment: https://git.openjdk.org/jdk/pull/16107#issuecomment-1755080550