8271064: ZGC several jvm08 perf regressions after JDK-8268372 #298
Conversation
👋 Welcome back eosterlund! A progress list of the required criteria for merging this PR into |
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.
Looks good!
@fisk 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 2 new commits pushed to the
Please see this link for an up-to-date comparison between the source branch of this pull request and the ➡️ To integrate this PR with the above commit message to the |
Thanks for the reviews, @albertnetymk, @pliden and @tschatzl |
/integrate |
Going to push as commit 181483b.
Your commit was automatically rebased without conflicts. |
After the integration of ZGC dynamic thread selection, there was a regression that popped up on a few benchmarks that all had in common a high allocation rate and very quick GC times. An extra conservative measure for not trusting the heuristics when using few GC threads, did not play very well with this scenario. The effect of it is back-to-back GC causing thousands of GCs when <100 were really needed. Removing this conservative measure causes the regression to go away, and a bunch of green benchmarks to pop up instead of red ones. This suggest that conservative measure isn't working very well and does not scale to these scenarios. It is also already taken care of by other conservative measures. I propose it is removed, to solve the regressions.
The entire ZGC perf suite was rerun (no red, only green), and tier1-3 was run. There isn't much potential for things to blow up as I just removed one parameter in the heuristic. So if anything nasty was to show up, it would be in the perf runs.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk17 pull/298/head:pull/298
$ git checkout pull/298
Update a local copy of the PR:
$ git checkout pull/298
$ git pull https://git.openjdk.java.net/jdk17 pull/298/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 298
View PR using the GUI difftool:
$ git pr show -t 298
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk17/pull/298.diff