8299970: Speed up compiler/arraycopy/TestArrayCopyConjoint.java#12475
8299970: Speed up compiler/arraycopy/TestArrayCopyConjoint.java#12475eme64 wants to merge 3 commits intoopenjdk:masterfrom
Conversation
|
👋 Welcome back epeter! A progress list of the required criteria for merging this PR into |
Webrevs
|
|
@eme64 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 60 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. ➡️ To integrate this PR with the above commit message to the |
| } catch (Exception e) { | ||
| System.out.println(e.getMessage()); |
There was a problem hiding this comment.
try/catch is there because arraycopy may throw exception due to some mess up in code generation and we want call stack and information about that to debug the issue.
There was a problem hiding this comment.
But with that try/catch, no exception will be thrown and therefore the test would pass, right? And the exception would contain a stack trace, no need to catch it and print its contents.
There was a problem hiding this comment.
You are right. In this case, please also update TestArrayCopyDisjoint.java test.
It could be "copy/paste" issue when these tests were created based on other existing tests.
May be in separate RFE we should review tests which use catch and may hide a failure.
There was a problem hiding this comment.
Thanks for the idea, I applied it to TestArrayCopyDisjoint.java, and updated the description above.
There was a problem hiding this comment.
Filed follow-up RFE
https://bugs.openjdk.org/browse/JDK-8302135
|
Thanks @TobiHartmann @vnkozlov @chhagedorn for the reviews! |
|
Going to push as commit 5d39d14.
Your commit was automatically rebased without conflicts. |
I lowered the iteration count from
1000_000(million) down to30_000(30k). I also removed atry-catchstatement that seems to serve no purpose, but may actually prevent us from detecting failures of the test.Per
@runstatement, I got the runtime down from about4-4.5 secto1-1.3 sec(3-4x speedup).Details
I ran the test with
-XX:+PrintCompilation -XX:+PrintInlining -XX:-TieredCompilation -XX:CICompilerCount=1 -Xbatch, and then analyzed the output with thiscat txt.txt | sed -n -e "s/.*java.lang.System::\(\w*\).*intrinsic.*/\1/p" | sort | uniq -c, which gives me the count for thearraycopyintrinsification. For1000_000and30_000iterations I got336intrinisifications, so I am not losing any. I also tried to lower the iterations further down to10_000, but that did only marginally lower the runtime, to1 sec, but with much less intrinsifications, only144. So I decided to stay at30k.If this fix does not turn out to be sufficient, we can try an IR test, and trigger compilation of the test methods after a much smaller iteration count for warmup (after all we want to make sure intrinsification happens), and then verify that the intrinsic is in the IR.
Update
I applied the same changes to
compiler/arraycopy/TestArrayCopyDisjoint.java, verified that no intrinsification was lost. Marginal speedup from1 secdown to0.7 secper run statement.Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/12475/head:pull/12475$ git checkout pull/12475Update a local copy of the PR:
$ git checkout pull/12475$ git pull https://git.openjdk.org/jdk pull/12475/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 12475View PR using the GUI difftool:
$ git pr show -t 12475Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/12475.diff