-
Notifications
You must be signed in to change notification settings - Fork 5.7k
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
8263971: C2 crashes with SIGFPE with -XX:+StressGCM and -XX:+StressIGVN #3190
Conversation
👋 Welcome back roland! A progress list of the required criteria for merging this PR into |
Webrevs
|
* @bug 8263971 | ||
* @summary C2 crashes with SIGFPE with -XX:+StressGCM and -XX:+StressIGVN | ||
* | ||
* @run main/othervm -Xcomp -XX:-TieredCompilation -XX:CompileOnly=TestLostDependencyOnZeroTripGuard -XX:+StressGCM -XX:StressSeed=886771365 TestLostDependencyOnZeroTripGuard |
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.
-XX:+UnlockDiagnosticVMOptions -XX:+IgnoreUnrecognizedVMOptions
should be added for the test, right?
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.
-XX:+UnlockDiagnosticVMOptions
should be enough.
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 looking at this
-XX:+UnlockDiagnosticVMOptions -XX:+IgnoreUnrecognizedVMOptions
should be added for the test, right?
I added -XX:+UnlockDiagnosticVMOptions so the test can be run with a release build.
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.
I don't think -XX:+UnlockDiagnosticVMOptions
is enough since StressGCM
is a C2-only flag.
What will happen if there is no c2 compiler?
Thanks.
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.
I don't think
-XX:+UnlockDiagnosticVMOptions
is enough sinceStressGCM
is a C2-only flag.What will happen if there is no c2 compiler?
Right. Command line option added.
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.
I don't think
-XX:+UnlockDiagnosticVMOptions
is enough sinceStressGCM
is a C2-only flag.
What will happen if there is no c2 compiler?Right. Command line option added.
Thanks for your update.
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.
What will happen if there is no c2 compiler?
Ah, yes, good point! I was only thinking about product builds.
There are actually more compiler tests that have -XX:+IgnoreUnrecognizedVMOptions
missing as for example: Vec_mulAddS2I that uses C2-specific flags. I'll file a bug to clean that up separately.
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.
Otherwise, looks good to me!
* @bug 8263971 | ||
* @summary C2 crashes with SIGFPE with -XX:+StressGCM and -XX:+StressIGVN | ||
* | ||
* @run main/othervm -Xcomp -XX:-TieredCompilation -XX:CompileOnly=TestLostDependencyOnZeroTripGuard -XX:+StressGCM -XX:StressSeed=886771365 TestLostDependencyOnZeroTripGuard |
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.
-XX:+UnlockDiagnosticVMOptions
should be enough.
@rwestrel 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 77 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 |
@rwestrel 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 25 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 |
Thanks for the review. |
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.
* @summary C2 crashes with SIGFPE with -XX:+StressGCM and -XX:+StressIGVN | ||
* | ||
* @run main/othervm -Xcomp -XX:-TieredCompilation -XX:CompileOnly=TestLostDependencyOnZeroTripGuard -XX:+UnlockDiagnosticVMOptions | ||
* -XX:+IgnoreUnrecognizedVMOptions -XX:+StressGCM -XX:StressSeed=886771365 TestLostDependencyOnZeroTripGuard |
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.
Is it worth adding another @run with no fixed seed? Just to give this a chance to still trigger the bug if the implementation changes in the future such that the fixed seed does not work anymore.
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 review. Would you drop -XX:+StressGCM as well or keep it?
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.
I would keep it.
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.
Done in updated change.
/integrate |
@rwestrel Since your change was applied there have been 77 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit 8100a20. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
For the inner for loop of the test case:
1- the control input of the DivI node in the loop body is cleared
because the range of values for i23, the loop's iv, is known to
never be null.
2- pre/main/post loops are added
3- the main loop is unrolled enough that it's fully unrolled but
actually never entered
4- because the main loop is no longer a looop, DiVI nodes from the
main loop can float and are scheduled in the pre loop.
5- the main loop is never executed (the values of the iv for the main
loop after unrolling fall outside the (3, 68] range of values of the
initial loop), one of the main loop DivI nodes divides by 0 and
because it doesn't stay in the main loop, the crash occurs.
The calls to PhaseIdealLoop::cast_incr_before_loop() in
PhaseIdealLoop::insert_pre_post_loops() should guarantee that nodes
that uses the loop iv stay control dependent on the test that guards
the main loop. For that it inserts a CastII node with the
_carry_dependency flag set. With 8256730, that CastII for the main
loop is pushed through the iv AddI of the pre loop. In the process, it
looses the _carry_dependency flag which causes the CastII node to be
optimized out and the DivI nodes to float.
With the proposed fix, CastII nodes created by the logic from 8256730
have the _carry_dependency flag set if the CastII node that's
transform has it.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/3190/head:pull/3190
$ git checkout pull/3190
Update a local copy of the PR:
$ git checkout pull/3190
$ git pull https://git.openjdk.java.net/jdk pull/3190/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 3190
View PR using the GUI difftool:
$ git pr show -t 3190
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/3190.diff