Skip to content
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

8257498: Remove useless skeleton predicates #2075

Closed
wants to merge 6 commits into from

Conversation

chhagedorn
Copy link
Member

@chhagedorn chhagedorn commented Jan 14, 2021

This enhancement removes useless skeleton predicates in the same way as we already remove normal useless predicates in PhaseIdealLoop::eliminate_useless_predicates().

Thanks,
Christian


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

Reviewers

Download

$ git fetch https://git.openjdk.java.net/jdk pull/2075/head:pull/2075
$ git checkout pull/2075

@bridgekeeper
Copy link

bridgekeeper bot commented Jan 14, 2021

👋 Welcome back chagedorn! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk openjdk bot added the rfr label Jan 14, 2021
@openjdk
Copy link

openjdk bot commented Jan 14, 2021

@chhagedorn The following label will be automatically applied to this pull request:

  • hotspot-compiler

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.

@openjdk openjdk bot added the hotspot-compiler label Jan 14, 2021
@mlbridge
Copy link

mlbridge bot commented Jan 14, 2021

Webrevs

useful_predicates.push(entry->in(0)->in(1)->in(1)); // good one

if (UseLoopPredicate) {
predicate = find_predicate_insertion_point(entry, Deoptimization::Reason_predicate);
Copy link
Contributor

@rwestrel rwestrel Jan 15, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't we need to do this for Deoptimization::Reason_profile_predicate as well?

Copy link
Member Author

@chhagedorn chhagedorn Jan 18, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, we need that as well. I updated it.

@@ -288,6 +275,34 @@ void PhaseIdealLoop::clone_skeleton_predicates_to_unswitched_loop(IdealLoopTree*
}
}

// Put all skeleton predicate projections on a list, starting at 'predicate' and going up in the tree. If 'get_opaque'
// is set, then the Opaque4 nodes of the skeleton predicates are put on the list instead of the projections.
void PhaseIdealLoop::get_skeleton_predicates(Node* predicate, Unique_Node_List& list, bool get_opaque) {
Copy link
Contributor

@rwestrel rwestrel Jan 19, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would remove the get_opaque parameter, populate the list with projections (the get_opaque false case) and have the caller retrieve the opaque node (predicate->in(0)->in(1)) if that's what it needs.

Copy link
Member Author

@chhagedorn chhagedorn Jan 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I updated it and removed the get_opaque flag.

Node* n = C->skeleton_predicate_opaque4_node(idx);
assert(n->Opcode() == Op_Opaque4, "must be");
if (!useful_predicates.member(n)) { // not in the useful list
C->remove_skeleton_predicate_opaque4_node(idx);
Copy link
Contributor

@rwestrel rwestrel Jan 19, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Usually when nodes are kept in a global list, when a node dies, the node is removed from the list. It's the case of Compile::_predicate_opaqs for instance. So when the logic here iterates over _predicate_opaqs and removes some of them from the graph, the node is automatically removed from the _predicate_opaqs list. I don't see similar logic for skeleton Opaque4 nodes. I think it's a problem because you could end up with a node in the list that was removed from the graph (because that part of the graph is dead) and freed from memory (which could cause a crash).

Copy link
Member Author

@chhagedorn chhagedorn Jan 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's true. I have not considered that. I updated it to remove it in the same way as we are removing other nodes as for example expensive nodes.

@openjdk
Copy link

openjdk bot commented Jan 20, 2021

@chhagedorn this pull request can not be integrated into master due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout JDK-8257498
git fetch https://git.openjdk.java.net/jdk master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push

@openjdk openjdk bot added the merge-conflict label Jan 20, 2021
Copy link
Contributor

@rwestrel rwestrel left a comment

Other than that, looks good to me.

predicates.push(opaq);
}
}

Copy link
Contributor

@rwestrel rwestrel Jan 21, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't realize you would have to go through an extra list. So I guess what you had before with the get_opaque parameter was better.

Copy link
Member Author

@chhagedorn chhagedorn Jan 22, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we need an extra one. I reverted that part back again.

@openjdk
Copy link

openjdk bot commented Jan 25, 2021

@chhagedorn 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:

8257498: Remove useless skeleton predicates

Reviewed-by: roland, thartmann

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 3 new commits pushed to the master branch:

  • ca20c63: 8259710: Inlining trace leaks memory
  • 09489e2: 8260338: Some fields in HaltNode is not cloned
  • af155fc: 8258836: JNI local refs exceed capacity getDiagnosticCommandInfo

Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
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 master branch, type /integrate in a new comment.

@openjdk openjdk bot added ready and removed merge-conflict labels Jan 25, 2021
Copy link
Member

@TobiHartmann TobiHartmann left a comment

Looks good to me.

assert(n->Opcode() == Op_Opaque1, "must be");
if (!useful_predicates.member(n)) { // not in the useful list
_igvn.replace_node(n, n->in(1));
}
}

for (int i = C->skeleton_predicate_count(); i > 0; i--) {
const int idx = i - 1;
Copy link
Member

@TobiHartmann TobiHartmann Jan 25, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could be removed for consistency with above code.

Copy link
Member Author

@chhagedorn chhagedorn Jan 25, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that was a left over from a previous commit where we needed idx twice. I update that.

@chhagedorn
Copy link
Member Author

chhagedorn commented Jan 27, 2021

Thanks Roland and Tobias for your reviews!

@chhagedorn
Copy link
Member Author

chhagedorn commented Feb 1, 2021

/integrate

@openjdk openjdk bot closed this Feb 1, 2021
@openjdk openjdk bot added integrated and removed ready rfr labels Feb 1, 2021
@openjdk
Copy link

openjdk bot commented Feb 1, 2021

@chhagedorn Since your change was applied there have been 103 commits pushed to the master branch:

  • ab727f0: 8260591: Shenandoah: improve parallelism for concurrent thread root scans
  • cf94208: 8259395: Patching automatic module with additional packages re-creates module without "requires java.base"
  • 039affc: 8260577: Unused code in AbstractCompiler after Shark compiler removal
  • 8a9004d: 8260574: Remove parallel constructs in GenCollectedHeap::process_roots
  • 0da9cad: 8260501: [Vector API] Improve register usage for shift operations on x86
  • a61ff87: 8260685: ProblemList 2 compiler/jvmci/compilerToVM tests in Xcomp configs
  • fcfe647: 8260462: Missing in Modality.html
  • 67a34da: 8260630: Templatize literal_size
  • 6b24e98: 8259008: ArithmeticException was thrown at "Monitor Cache Dump" on HSDB
  • 69ee314: 8249867: xml declaration is not followed by a newline
  • ... and 93 more: https://git.openjdk.java.net/jdk/compare/d825339da5b20eccb9f98afa98c123cd90fbee15...master

Your commit was automatically rebased without conflicts.

Pushed as commit aec0377.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

@chhagedorn chhagedorn deleted the JDK-8257498 branch Feb 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hotspot-compiler integrated
3 participants