-
Notifications
You must be signed in to change notification settings - Fork 6.1k
8272756: Remove unnecessary explicit initialization of volatile variables in java.desktop #5197
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
Conversation
…s in java.desktop
|
👋 Welcome back stsypanov! A progress list of the required criteria for merging this PR into |
|
@stsypanov The following labels 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 lists. If you would like to change these labels, use the /label pull request command. |
Webrevs
|
| Set<Integer> tags = essentialTags; | ||
| if (tags == null) { | ||
| essentialTags = tags = Set.of( | ||
| essentialTags = Set.of( |
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 is the purpose of the local tags here?
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 like there's no purpose, tags is not used after assignment
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 it's kind of a protection from a race. Yet it's possible either way: another thread could see essentialTags == null before this one initialises the field.
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 we can drop it completely.
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.
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 still suggest to remove the local tag completely.
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.
@jayathirthrao @stsypanov Looks like this was not addressed? It will be good to include it in some future cleanup.
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.
As far as I can see, it was. Line 64:
essentialTags = Set.of(
And it shows as such in the diff of the commit.
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 was the usage of the local var, the current thread was about the local var itself, it is still there.
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.
Good catch!
I missed that the local variable is still there and now it's unused, so an IDE should issue a warning about it.
|
As I can see there are a few more zero-initializations of volatiles. Are they intentionally skipped?
|
…s in java.desktop
|
@turbanoff nice catch! I've missed them in my original commit, no intention here. I've included them either. |
|
/integrate |
|
@stsypanov This PR has not yet been marked as ready for integration. |
|
|
@stsypanov 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 153 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. As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@jayathirthrao, @aivanov-jdk) but any other Committer may sponsor as well. ➡️ To flag this PR as ready for integration with the above commit message, type |
|
/integrate |
|
@stsypanov |
|
/sponsor |
|
Going to push as commit ccbce10.
Your commit was automatically rebased without conflicts. |
|
@jayathirthrao @stsypanov Pushed as commit ccbce10. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
This is a continuation of
As mentioned in JDK-6736490:
An explicit initialization of a volatile class instance variable, such as private volatile Object = null; or private volatile int scale = 0; is unnecessary since the Java spec automatically initializes objects to null and primitive type short, int, long, float and double to 0 and boolean to false. Explicit initialization of volatile variable to a value the same as the default implicit initialized value results in an unnecessary store and membar operation.
Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/5197/head:pull/5197$ git checkout pull/5197Update a local copy of the PR:
$ git checkout pull/5197$ git pull https://git.openjdk.java.net/jdk pull/5197/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 5197View PR using the GUI difftool:
$ git pr show -t 5197Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/5197.diff