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

[Y. Srinivas Ramakrishna]

On Tue, 28 Nov 2023 17:51:31 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`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8317755-g1-periodic-whole
>  - Merge branch 'master' into JDK-8317755-g1-periodic-whole
>  - Optional flag
>  - Merge branch 'master' into JDK-8317755-g1-periodic-whole
>  - Keep the cast
>  - Fix

Clearly ...

> 
> I may have misunderstood the long comment stream, so will go back and reread in case I missed something crucial about the objection to this PR in its current form.

I now see that you noted it might be better to separate this out into its own independent controller option:

> This is the reason for the suggestion to phase out the current option `G1PeriodicGCInterval` to use a different name, and add this functionality (regular whole heap analysis to clean out cruft) as a new option (something like `WholeHeapAnalysisInterval`, or something more aligned with other collectors)
> 
> I could easily imagine the use case where one would want to act fairly quickly (and allowing a disruptive full gc) on the detected idle case ("shortly" after detecting idle), and be more relaxed about general cleanup (long period, being least disruptive using a concurrent mark).

I believe I now understand your objection. Thanks, and sorry for the noise :-)

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

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