8315766: Parallelize gc/stress/TestStressIHOPMultiThread.java test #15710
Conversation
TestStressIHOPMultiThread takes about 10 minutes to run. This limits effective parallelism of tier4 testing on large machines. We can parallelize its `@run` configs to improve effective parallelism for tier4. With both fastdebug and release configuration runs, it has been found that the final testcase in the sequential run configuration takes the most amount of time. Because of that to parallel configurations were tried out, one with all 5 test cases parallelized and second with 3 sections of parallel runs: 1st with first 2 tests, 2nd with the next 2 tests and 3rd with the last test case. Below are the results in fast debug: * before : **974.87s user 108.92s system 172% cpu 10:27.46 total** * after_full-parallelization : **796.79s user 88.73s system 343% cpu 4:17.51 total** * after_partial-parallelization: **904.82s user 102.00s system 391% cpu 4:17.01 total** From the reults we can see that even though partial and full parallelization has similar total running time, the user and system times and considerably better with full parallelization with repeated runs. Below are the results with release mode: * before : **1111.11s user 196.52s system 210% cpu 10:20.80 total** * after_full-parallelization: **837.07s user 151.57s system 378% cpu 4:20.89 total**
|
👋 Welcome back roy-soumadipta! A progress list of the required criteria for merging this PR into |
|
@roy-soumadipta The following label 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 list. If you would like to change these labels, use the /label pull request command. |
Webrevs
|
|
@roy-soumadipta 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 110 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 (@shipilev, @tschatzl) but any other Committer may sponsor as well. ➡️ To flag this PR as ready for integration with the above commit message, type |
|
/integrate |
|
@roy-soumadipta |
|
/sponsor |
|
Going to push as commit edd454b.
Your commit was automatically rebased without conflicts. |
openjdk
bot
removed
ready
|
@shipilev @roy-soumadipta Pushed as commit edd454b. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Backporting the fix for https://bugs.openjdk.org/browse/JDK-8315766 merged as part of openjdk/jdk#15710. https://github.com/openjdk/jdk/commit/edd454b502b9bacde55492820e52655bbac63b89.patch could be cleanly applied. Below are the test results: * before_release: **1535.51s user 72.40s system 257% cpu 10:24.79 total** * after_release: **1655.73s user 74.16s system 1195% cpu 2:24.68 total** * before_fastdebug: **1064.03s user 57.21s system 177% cpu 10:32.29 total** * after_fastdebug: **1137.89s user 58.07s system 783% cpu 2:32.61 total**
Backporting the fix for https://bugs.openjdk.org/browse/JDK-8315766 merged as part of openjdk/jdk#15710. https://github.com/openjdk/jdk/commit/edd454b502b9bacde55492820e52655bbac63b89.patch could be cleanly applied. Below are the test results: * before_release: **1557.98s user 220.66s system 287% cpu 10:17.90 total** * after_release: **1653.52s user 203.46s system 1340% cpu 2:18.54 total** * before_fastdebug: **1045.98s user 114.93s system 182% cpu 10:35.68 total** * after_fastdebug: **1082.15s user 111.88s system 795% cpu 2:30.11 total**
Backporting the fix for https://bugs.openjdk.org/browse/JDK-8315766 merged as part of openjdk/jdk#15710. https://github.com/openjdk/jdk/commit/edd454b502b9bacde55492820e52655bbac63b89.patch could be cleanly applied. Below are the test results: * before_release: **1642.99s user 146.56s system 291% cpu 10:14.77 total** * after_release: **1613.99s user 125.32s system 1323% cpu 2:11.44 total** * before_fastdebug: **1214.26s user 54.36s system 200% cpu 10:34.09 total** * after_fastdebug: **1246.25s user 57.25s system 889% cpu 2:26.55 total**
TestStressIHOPMultiThread takes about 10 minutes to run. This limits effective parallelism of tier4 testing on large machines. We can parallelize its
@runconfigs to improve effective parallelism for tier4. With both fastdebug and release configuration runs, it has been found that the final testcase in the sequential run configuration takes the most amount of time. Because of that to parallel configurations were tried out, one with all 5 test cases parallelized and second with 3 sections of parallel runs: 1st with first 2 tests, 2nd with the next 2 tests and 3rd with the last test case. Below are the results in fast debug:From the reults we can see that even though partial and full parallelization has similar total running time, the user and system times and considerably better with full parallelization with repeated runs.
Below are the results with release mode:
Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/15710/head:pull/15710$ git checkout pull/15710Update a local copy of the PR:
$ git checkout pull/15710$ git pull https://git.openjdk.org/jdk.git pull/15710/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 15710View PR using the GUI difftool:
$ git pr show -t 15710Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/15710.diff
Webrev
Link to Webrev Comment