-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
8314935: Shenandoah: Unable to throw OOME on back-to-back Full GCs #15500
Conversation
👋 Welcome back wkemper! A progress list of the required criteria for merging this PR into |
@earthling-amzn The following labels will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command. |
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. Looks good to me.
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.
A couple of comments about harmonizing the code in GenShen tip with that here, but otherwise looks good.
@@ -40,7 +40,8 @@ class ShenandoahCollectorPolicy : public CHeapObj<mtGC> { | |||
private: | |||
size_t _success_concurrent_gcs; | |||
size_t _success_degenerated_gcs; | |||
size_t _success_full_gcs; | |||
// Written by control thread, read by mutators | |||
volatile size_t _success_full_gcs; | |||
size_t _alloc_failure_degenerated; | |||
size_t _alloc_failure_degenerated_upgrade_to_full; |
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.
In GenShen tip, _alloc_failure_degenerated_upgrade_to_full
is also declared volatile.
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.
_alloc_failure_degenerated_upgrade_to_full
is only changed on a safepoint, so it shouldn't need any additional synchronization.
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.
OK, as long as this resolves in genshen tip.
@@ -82,6 +83,10 @@ class ShenandoahCollectorPolicy : public CHeapObj<mtGC> { | |||
size_t cycle_counter() const; | |||
|
|||
void print_gc_stats(outputStream* out) const; | |||
|
|||
size_t full_gc_count() const { |
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.
Is it worthwhile to harmonize this with tip and rename to get_fullgc_count()
?
Unless the idea is to change genshen tip to use full_gc_count()
like here when you pull these changes down.
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 went with the style convention established by cycle_counter
. I don't feel strongly about this. If you prefer get_full_gc_count
, I can change that here (otherwise, I'll change genshen to use full_gc_count
).
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.
full_gc_count is fine; so long as these eventually get resolved in genshen tip.
@earthling-amzn 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 76 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. As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@ysramakrishna) but any other Committer may sponsor as well. ➡️ To flag this PR as ready for integration with the above commit message, type |
result = allocate_memory_under_lock(req, in_new_region); | ||
} | ||
|
||
while (result == nullptr && tries <= ShenandoahFullGCThreshold) { |
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.
Just want to point out, the description of ShenandoahFullGCThreshold
does not cover this use case (also, the original code here was not concerned with full GCs):
"How many back-to-back Degenerated GCs should happen before going to a Full GC."
/integrate |
@earthling-amzn |
Reviewed! /sponsor |
Going to push as commit 716201c.
Your commit was automatically rebased without conflicts. |
@ysramakrishna @earthling-amzn Pushed as commit 716201c. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Retry allocations until at least one full gc is complete, do not spin unnecessarily when gc is not making progress.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/15500/head:pull/15500
$ git checkout pull/15500
Update a local copy of the PR:
$ git checkout pull/15500
$ git pull https://git.openjdk.org/jdk.git pull/15500/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 15500
View PR using the GUI difftool:
$ git pr show -t 15500
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/15500.diff
Webrev
Link to Webrev Comment