-
Notifications
You must be signed in to change notification settings - Fork 37
8319342: GenShen: Reset the count of degenerated cycles in a row following Full GC #352
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Also remove unused method in ShenandoahGeneration.
👋 Welcome back kdnilsen! A progress list of the required criteria for merging this PR into |
Webrevs
|
@@ -61,6 +61,8 @@ class ShenandoahCollectorPolicy : public CHeapObj<mtGC> { | |||
ShenandoahSharedFlag _in_shutdown; | |||
ShenandoahTracer* _tracer; | |||
|
|||
uint _degenerated_cycles_in_a_row; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit, but we could call this _consecutive_degenerated_gcs
for consistency with other fields in this class? (Also, possibly rename _abbreviated_cycles
to _abbreviated_gcs
for the same reason.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. Making this change.
@@ -44,11 +44,6 @@ bool ShenandoahPassiveHeuristics::should_unload_classes() { | |||
return can_unload_classes(); | |||
} | |||
|
|||
bool ShenandoahPassiveHeuristics::should_degenerate_cycle() { | |||
// Always fail to Degenerated GC, if enabled | |||
return ShenandoahDegeneratedGC; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch. That was an unintended consequence. I will return the methods to the Heuristics hierarchy, but will query the consecutive_degenerated_gcs value from collector policy.
Restore the original ShenandoahHeuristics::should_degenerate_cycle() so that ShenandoahPassiveHeuristics can differentate from other implementations. Improve instance variable names.
@kdnilsen This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 161 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
/integrate |
Going to push as commit 81de88c.
Your commit was automatically rebased without conflicts. |
After a Full GC completes, reset the count on consecutive degenerated cycles to zero. This prevents automatic triggering of back-to-back Full GC.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/shenandoah.git pull/352/head:pull/352
$ git checkout pull/352
Update a local copy of the PR:
$ git checkout pull/352
$ git pull https://git.openjdk.org/shenandoah.git pull/352/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 352
View PR using the GUI difftool:
$ git pr show -t 352
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/shenandoah/pull/352.diff
Webrev
Link to Webrev Comment