Skip to content

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

Closed
wants to merge 4 commits into from

Conversation

kdnilsen
Copy link
Contributor

@kdnilsen kdnilsen commented Nov 3, 2023

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

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed (1 review required, with at least 1 Committer)

Issue

  • JDK-8319342: GenShen: Reset the count of degenerated cycles in a row following Full GC (Bug - P3)

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

@bridgekeeper
Copy link

bridgekeeper bot commented Nov 3, 2023

👋 Welcome back kdnilsen! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk openjdk bot added the rfr Pull request is ready for review label Nov 3, 2023
@mlbridge
Copy link

mlbridge bot commented Nov 3, 2023

Webrevs

@@ -61,6 +61,8 @@ class ShenandoahCollectorPolicy : public CHeapObj<mtGC> {
ShenandoahSharedFlag _in_shutdown;
ShenandoahTracer* _tracer;

uint _degenerated_cycles_in_a_row;
Copy link
Contributor

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.

Copy link
Contributor Author

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;
Copy link
Contributor

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".

Copy link
Member

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.

Copy link
Contributor Author

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.
@openjdk
Copy link

openjdk bot commented Nov 13, 2023

@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:

8319342: GenShen: Reset the count of degenerated cycles in a row following Full GC

Reviewed-by: wkemper, ysr

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 master branch:

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 master branch, type /integrate in a new comment.

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Nov 13, 2023
@kdnilsen
Copy link
Contributor Author

/integrate

@openjdk
Copy link

openjdk bot commented Nov 13, 2023

Going to push as commit 81de88c.
Since your change was applied there have been 161 commits pushed to the master branch:

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Nov 13, 2023
@openjdk openjdk bot closed this Nov 13, 2023
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Nov 13, 2023
@openjdk
Copy link

openjdk bot commented Nov 13, 2023

@kdnilsen Pushed as commit 81de88c.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
integrated Pull request has been integrated
Development

Successfully merging this pull request may close these issues.

3 participants