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
JDK-8276039: Remove unnecessary qualifications of java_lang_Class:: #6130
Conversation
|
Webrevs
|
That's funny. I guess java_lang_Class:
becomes a label and set_init_lock is local to the class so resolution works anyway.
@yminqi This change now passes all automated pre-integration checks. 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 27 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.
|
@vidmik is right - |
There are other similarity for static members like this in the same file: I would like to keep this as others --- maybe the original author like it used this way. |
This looks good and trivial to me.
For me the bug title is a little difficult to understand. How about changing it to something like:
typo: java_lang_Class:set_init_lock() should be java_lang_Class::set_init_lock()
@@ -1261,7 +1261,7 @@ oop java_lang_Class::process_archived_mirror(Klass* k, oop mirror, | |||
// Reset local static fields in the mirror | |||
InstanceKlass::cast(k)->do_local_static_fields(&reset); | |||
|
|||
java_lang_Class:set_init_lock(archived_mirror, NULL); | |||
java_lang_Class::set_init_lock(archived_mirror, NULL); |
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.
Rather than fixing the qualification, I would just drop the qualification completely, being consistent with most of the other similar calls in this function, including several that immediately follow.
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.
In the list of qualified uses given earlier as examples, roughly half are required because they are outside the scope of java_lang_Class, and roughly half are unnecessary. This one is unnecessary, and qualifying it makes it different from adjacent usage.
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.
Yes, not all of them are unnecessary. I just grep from the file and checked part of them, thanks! I will remove the unnecessary qualifier 'java_lang_Class::' for static functions defined in java_lang_Class.
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.
In fact class java_lang_Thread, java_lang_String maybe other classes have same usage. I will only change for class java_lang_Class in this PR.
Removing all unnecessary qualifications from java_lang_Class is a fine cleanup to do, but the issue title should now be changed to reflect that. You can use the discovery of the typo as the motivation for the broader cleanup.
Thanks,
David
@vidmik @iklam Thanks for review |
Going to push as commit cef9db9.
Your commit was automatically rebased without conflicts. |
Mailing list message from David Holmes on hotspot-runtime-dev: Hi Yumin, On 30/10/2021 2:16 am, Yumin Qi wrote:
This was not properly reviewed IMO. The "reviews" from Mikael and Ioi David |
Hi, David Thanks for your input. |
Maybe I should wait until next week to do the push. |
Mailing list message from David Holmes on hotspot-runtime-dev: On 30/10/2021 7:44 am, Yumin Qi wrote:
I was off yesterday (today is Saturday :) ) The change is simple, but the point is you should have at least had your Cheers, |
Please review,
I have no idea why this problem has not been encountered in compilation, it is obvious the usage of resolution operator :: is not complete and wrong.
Tests: mach5 tier1, tier4
Thanks
Yumin
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/6130/head:pull/6130
$ git checkout pull/6130
Update a local copy of the PR:
$ git checkout pull/6130
$ git pull https://git.openjdk.java.net/jdk pull/6130/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 6130
View PR using the GUI difftool:
$ git pr show -t 6130
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/6130.diff