-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
8299970: Speed up compiler/arraycopy/TestArrayCopyConjoint.java #12475
Conversation
👋 Welcome back epeter! A progress list of the required criteria for merging this PR into |
Webrevs
|
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.
That looks reasonable.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the idea, I applied it to TestArrayCopyDisjoint.java
, and updated the description above.
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.
Filed follow-up RFE
https://bugs.openjdk.org/browse/JDK-8302135
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.
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 to me too.
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-catch
statement that seems to serve no purpose, but may actually prevent us from detecting failures of the test.Per
@run
statement, I got the runtime down from about4-4.5 sec
to1-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 thearraycopy
intrinsification. For1000_000
and30_000
iterations I got336
intrinisifications, 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 sec
down to0.7 sec
per run statement.Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/12475/head:pull/12475
$ git checkout pull/12475
Update a local copy of the PR:
$ git checkout pull/12475
$ git pull https://git.openjdk.org/jdk pull/12475/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 12475
View PR using the GUI difftool:
$ git pr show -t 12475
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/12475.diff