RFR: 8319342: GenShen: Reset the count of degenerated cycles in a row following Full GC
Y. Srinivas Ramakrishna
ysr at openjdk.org
Tue Nov 7 00:29:25 UTC 2023
On Mon, 6 Nov 2023 22:59:31 GMT, William Kemper <wkemper at openjdk.org> wrote:
>> After a Full GC completes, reset the count on consecutive degenerated cycles to zero. This prevents automatic triggering of back-to-back Full GC.
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahPassiveHeuristics.cpp line 49:
>
>> 47: bool ShenandoahPassiveHeuristics::should_degenerate_cycle() {
>> 48: // Always fail to Degenerated GC, if enabled
>> 49: return ShenandoahDegeneratedGC;
>
> Are we changing how the passive heuristic behaves now? With this change `ShenandoahCollectorPolicy::should_degenerate_cycle` would return `false` sometimes when the passive heuristic would have "degenerated".
I agee with William... You can leave all state (counters) and its manipulation entirely in the heuristics object, and let the policy object query the heuristics like you do today, and inform it when it does do a full gc, etc. so relevant state may be updated.
Of course, the policy should not independently reach in and change the state maintained in the heuristics, just query that state, and inform it of events that might entail changes to that state.
We can clean things up by asking what the role of heuristics is vs what the role of policy is. It seems as if policy is broad and heuristics is more specific within that broad policy. It is also possible to keep the state in the policy, be mutated only by policy in response to events, and have the heuristics be completely state-free, but call-back to policy to use any state it would use for its decisions. Clarifying this structure and their relationship, and sticking to a consistent (documented) protocol here would avoid confusion and errors.
-------------
PR Review Comment: https://git.openjdk.org/shenandoah/pull/352#discussion_r1384200774
More information about the shenandoah-dev
mailing list