-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
8327997: G1: Move G1ScanClosureBase::reference_iteration_mode to subclass #18244
Conversation
👋 Welcome back ayang! A progress list of the required criteria for merging this PR into |
@albertnetymk 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. |
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. The root cause of such movement is that we don't create an specific object of the class G1ScanClosureBase
. So we can override the method reference_iteration_mode
in its subclasses instead of G1ScanClosureBase
itself.
If we need to write so much comments to explain such movement, I suggest that we should write more comments in src/hotspot/share/memory/iterator.hpp::ReferenceIterationMode
to explain the related things clearer.
@albertnetymk 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 1 new commit pushed to the
Please see this link for an up-to-date comparison between the source branch of this pull request and the ➡️ To integrate this PR with the above commit message to the |
// Because this closure is applied on pointers residing outside the | ||
// collection set, we shouldn't do discovery, which is why this closure has | ||
// its reference-processor being null. | ||
// Strictly speaking, one can use the same iteration mode from the superclass | ||
// BasicOopIterateClosure, and the null reference-processor will treat fields | ||
// as strong references anyway, equivalent to DO_FIELDS. Here we override the | ||
// iteration mode to skip the known null-check in | ||
// InstanceRefKlass::try_discover. | ||
virtual ReferenceIterationMode reference_iteration_mode() { return DO_FIELDS; } |
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 think the comment is okay, but maybe should put more emphasis on that specifying this iteration mode allows the compiler to (more easily) compile out the check in try_discover
.
Also since this isn't the only place this (and similar) optimizations are made elsewhere too using this getter, I kind of agree with @lgxbslgx that the impact of the selection should probably be documented at the enum level (the move of the override into the leaf class here is fine with me).
Just something like "// Selection of one or the other option helps the compiler to remove unnecessary, known beforehand behavior for a given oop closure at compile time" seems sufficient to me there instead of this fairly long comment.
The exact changes can be easily gathered by searching the usages of the enum.
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 dropped the comment. This optimization, afaics, is only used/implemented in G1. Moving the comment to the enum level can be confusing, since its impact might not be visible (or even positive) for other collectors. (I inspected the generated asm of g1Remset
with and without this optimization and they are indeed different -- the one without the optimization is shorter (in terms of LOC), but it's unclear which one is faster.)
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 can see multiple references to the DO_FIELDS
value in Hotspot code in that getter in several GCs, but only grepped for it without looking into detail about the reasons.
5513c4a
to
5a15421
Compare
@albertnetymk Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See OpenJDK Developers’ Guide for more information. |
Thanks for review. /integrate |
Going to push as commit 954c50e.
Your commit was automatically rebased without conflicts. |
@albertnetymk Pushed as commit 954c50e. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Simple moving a method from super class to sub class and some documentation.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/18244/head:pull/18244
$ git checkout pull/18244
Update a local copy of the PR:
$ git checkout pull/18244
$ git pull https://git.openjdk.org/jdk.git pull/18244/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 18244
View PR using the GUI difftool:
$ git pr show -t 18244
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/18244.diff
Webrev
Link to Webrev Comment