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
8272970: Parallelize runtime/InvocationTests/ #5250
8272970: Parallelize runtime/InvocationTests/ #5250
Conversation
|
Webrevs
|
Hi Aleksey, I can't find any jtreg documentation that indicates that multiple @test entries within a single Java file will be run concurrently. ?? That aside the split you have done seem quite reasonable. Thanks, |
@shipilev This change now passes all automated pre-integration checks. 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 33 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.
|
Not sure how well the parallelization aspect is documented, but multiple |
Sure but uniquely named tests just gives uniquely named output directories, otherwise they'd overwrite each other. It says nothing about concurrent execution. I'm not saying it doesn't execute concurrently as apparently it does, but it is not documented and certainly not something that can easily be inferred from the docs. It is easy to imagine each file being processed in parallel, but somewhat more involved to parallelize the processing of each test within a file. I did an experiment running a multi-test with -concurrency:1 and -concurrency:16 and it made no difference to real time consumed. |
Weird. As I said, we use that technique every so often in other tests. Look:
|
I wonder whether "othervm" versus "driver" mode makes the difference here? |
It does not matter here. |
Anyone else wants to take a look? @iignatev, maybe? |
LGTM. one nit: it should be possible to reduce clutter by removing @compile
actions, could you please either do that here or file an RFE?
PS I wish jtreg had a way not to duplicate all these tags, perhaps w/ some kind of a preprocessor.
@iignatev At least some of the compile commands must remain. The top level test doesn't reference the actual test classes directly so must explicitly compile them. Any classes those directly reference do not need an explicit compile-command. |
Right. The generators are referencing the |
Thanks, I think this is good to go in. /integrate |
Going to push as commit 6cfe314.
Your commit was automatically rebased without conflicts. |
Current runtime/InvocationTests/ are long and serial. They take about half an hour on a modern desktop, mostly using a single CPU. They can be parallelized better, at least on sub-test level. This would be important as JDK-8272914 would start to run them in tier3.
Sample run times:
I think we can technically go even deeper, for example parallelising by
packageSet
in the generators themselves, but that would be much more intrusive. I think 17 minutes is already quite good, given other tests running in prospectivehotspot:tier3
.Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/5250/head:pull/5250
$ git checkout pull/5250
Update a local copy of the PR:
$ git checkout pull/5250
$ git pull https://git.openjdk.java.net/jdk pull/5250/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 5250
View PR using the GUI difftool:
$ git pr show -t 5250
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/5250.diff