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
8261075: Create stubRoutines.inline.hpp with SafeFetch implementation #2542
8261075: Create stubRoutines.inline.hpp with SafeFetch implementation #2542
Conversation
|
@AntonKozlov 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. |
Webrevs
|
@AntonKozlov 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 51 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 (@dcubed-ojdk, @tstuefe, @stefank) but any other Committer may sponsor as well.
|
I would rename the new header safefetch.hpp, just because these functions were never part of the StubRoutines namespace, and the naming is much clearer.
Good idea. It should be safefetch.inline.hpp, right? |
I don't think so? To my understanding, xxx.inline.hpp is a companion file to an xxx.hpp which you create if you want to remove some of the rarely used functions from a high traffic header. Here, we just have some independent global utility functions. |
Oh, you're right. I had an impression that there are standalone inline.hpp files, and I could not find the opposite in the Hotspot Style Guide. However, now I see inline.hpp are just the way you've described. Thanks! |
If you put non-trivial code in the header, then it should go into an .inline.hpp file (or .cpp file). From the style-guide:
It doesn't matter if there exists a .hpp file or not. However, what's non-trivial becomes a judgment call. I tend to use rule that if it uses code from another header, then it's non-trivial, and should most likely be moved out of the .hpp file. |
I suppose this file to be on the edge between trivial and not. Later, it will have a W^X transition and will include thread.hpp, I don't want to rename it again. @stefank, what do you think, should it be safefetch.inline.hpp? Or are you fine with safefetch.hpp? |
I'm fine with leaving it as safefetch.hpp. |
/integrate |
@AntonKozlov |
/sponsor |
@VladimirKempik @AntonKozlov Since your change was applied there have been 59 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit b955f85. |
I've messed up with this :( I'm trying to fix @stefank 's note #2200 (comment). I need to rename a file.hpp included in the safepoint.hpp to file.inline.hpp. This will require renaming safepoint.hpp to safepoint.inline.hpp, polluting the PR #2200 again and defeating the purpose of having this patch extracted. I think the better alternative will be a follow-up patch just renaming safepoint.hpp to safepoint.inline.hpp. I'm going to do the follow-up. Or is there a better alternative? Sorry and thanks. |
Just so that I understand. Did you really mean safepoint.hpp and not safefetch.hpp? I assume this all has to do with the fact that safefetch.hpp is going to include threadWXSetter.hpp, which you are going to change to threadWXSsetter.inline.hpp, because it includes thread.inline.hpp. If that's the case then I think the easy fix is to just rename safefetch.hpp to safefetch.inline.hpp. I don't think that will be problematic, or defeat the purpose of this patch. The previous change from stubRoutines.hpp to stubRoutines.inline.hpp has already been successfully been removed from your #2200 patch. If you create a new PR with a safefetch.hpp to safefetch.inline.hpp rename, I can review it as a trivial change and you will be able to push it immediately. Or did I misunderstand anything? Maybe you could point me to the problematic files? |
Definitely safefetch.hpp. Sorry, it seems I was thinking also about another problem at that moment :)
This is correct. My main concern was the noise I'm creating in the git repository, but I also think this is the best way in this situation. Thanks for confirmation! The bug is JDK-8263068 and PR is #2844. |
Hi,
Please reivew a small non-functional change that extracts inline SafeFetch functions to a separate file. This is preliminary work for JEP-391 integration that will reduce the size of that patch.
CC @dcubed-ojdk
Thanks!
Progress
Issue
Reviewers
Download
$ git fetch https://git.openjdk.java.net/jdk pull/2542/head:pull/2542
$ git checkout pull/2542