-
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
8319879: Stress mode to randomize incremental inlining decision #16597
Conversation
👋 Welcome back thartmann! A progress list of the required criteria for merging this PR into |
@TobiHartmann 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. |
133e8f2
to
31a6375
Compare
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.
Why you switch off flag in cha/*RootMethod.java
tests?
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 wish it was one flag - too much duplication. But I see why you separated them: to get randomness only if AlwaysIncrementalInline
is not specified.
If AlwaysIncrementalInline
was tuple {false | true | random} it would solve this.
They already have
|
Thanks for looking at this, Vladimir.
Right, a tuple would be better but then again we might want to merge all these stress flags into one flag at some point. For simplicity (and backport-ability), let's keep them separated for now and do a cleanup later. There's more to come, especially in the area of loop opts. |
src/hotspot/share/opto/doCall.cpp
Outdated
@@ -185,7 +185,7 @@ CallGenerator* Compile::call_generator(ciMethod* callee, int vtable_index, bool | |||
// Try inlining a bytecoded method: | |||
if (!call_does_dispatch) { | |||
InlineTree* ilt = InlineTree::find_subtree_from_root(this->ilt(), jvms->caller(), jvms->method()); | |||
bool should_delay = AlwaysIncrementalInline; | |||
bool should_delay = AlwaysIncrementalInline || (StressIncrementalInlining && (C->random() % 2) == 0); |
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.
Any specific reason to keep vector, string , boxing call generators out of scope, I understand that lazy intrinsification gives constants and opportunity to seep in the graph and enable meeting closed world compilation constraints, but this is a stress testing option, an eager failed intrinsification will take the control flow to line# 214 , but only if we randomize creating LateInlineCallGenerators for these APIs.
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 do you mean by keeping them out of scope? String, boxing and vector methods will be late inlined if the respective should_delay_*_inlining
method returns true. Otherwise, the stress option might still trigger late inlining randomly. Isn't that exactly what we want? Or do you suggest to check should_delay
first?
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.
Exactly, should_delay_vector_inlining is not affected by newly added option. Yes, should_delay check should be earlier if we intend to randomize lazy intrinsification decisions for vector , boxing methods.
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.
Right, I think that would be reasonable. I'll give that a try.
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.
Seems to work fine. I moved the check up.
I don't see |
Can we change meaning of
Also |
You are right, I looked at the wrong test.
Also, I think it would be misleading if Separately, we could convert |
Okay. |
It seems that these test changes were not required so I removed them. |
I executed a lot of testing up to and including tier7 + stress testing with I think that proves the value of this stress flag and given that these bugs are independent of the stress flag implementation, I propose to integrate it even if these issues are still unresolved. |
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.
Agree.
@TobiHartmann 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 99 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, Vladimir. |
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.
@@ -989,8 +989,9 @@ CallGenerator* CallGenerator::for_method_handle_call(JVMState* jvms, ciMethod* c | |||
bool input_not_const; | |||
CallGenerator* cg = CallGenerator::for_method_handle_inline(jvms, caller, callee, allow_inline, input_not_const); | |||
Compile* C = Compile::current(); | |||
bool should_delay = AlwaysIncrementalInline || (StressIncrementalInlining && (C->random() % 2) == 0); |
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.
Maybe this should go in its own function.
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, Roland! I added a new should_delay_inlining
method to Compile
.
Thanks again, Roland! |
/integrate |
Going to push as commit 303757b.
Your commit was automatically rebased without conflicts. |
@TobiHartmann Pushed as commit 303757b. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
We had quite a few C2 bugs in the past that only reproduced with a specific sequence of incremental inlining (for example, JDK-8319764). We should randomize the incremental inlining decision to trigger these code paths more frequently.
I did some testing with the flag enabled and I hit JDK-8319764 and JDK-8319889. I think it's still valuable to integrate this even if these bugs are not resolved yet.
Thanks,
Tobias
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/16597/head:pull/16597
$ git checkout pull/16597
Update a local copy of the PR:
$ git checkout pull/16597
$ git pull https://git.openjdk.org/jdk.git pull/16597/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 16597
View PR using the GUI difftool:
$ git pr show -t 16597
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/16597.diff
Webrev
Link to Webrev Comment