-
Notifications
You must be signed in to change notification settings - Fork 6.2k
8345655: Move reservation code out of ReservedSpace #22712
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
|
👋 Welcome back stefank! A progress list of the required criteria for merging this PR into |
|
@stefank 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 40 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. ➡️ To integrate this PR with the above commit message to the |
|
The dual functionality of
When reviewing this I would suggest that you compare the old code in virtualspace.cpp with the code in reservedSpace.cpp. A guide to changes in the diff: a) Whether memory reservation is for executable memory is confined to a limited number of places: The top-level memory reservation function and the function that reserves code. There's no need for other reservation places to pass in !ExecMem (or false), that is hidden from most callers. b) The old code had shared helpers to handled the case when we map anonymous memory and the case when we mapped the heap to a file. I separated the two paths. This adds a small amount of code duplication, but IMHO it makes the code easier to read and it removes a bunch of dispatch if-statements in the lower level functions. c) When starting with this patch I wanted to cleanup so that it would be slightly cleaner to pass down NMT MemTags, but I backed off because we need to make a couple of changes and fixes to NMT and CDS before that will be possible. Therefore you can see places where we don't pass down MemTags and you can see d) G1 and Shenandoah used to call one e) As a future change, I would like to remove the memory reservation overload that helps the caller guess if they want large pages or not. There's a lot of confusion around that functionality, and I would prefer to let the callers that want to set up explicit large pages make that request explicitly instead. In fact, if you check the code today you could find a place where the GC code says that it doesn't want large pages, but if you follow the code you see that it still gets it. For now I have left this "capability" as-is. f) I removed g) You will see a few changes to the include files as a result of code moving. h) I've stopped allowing 0 as an alignment argument. The required minimum alignment is i) j) I've somewhat restructured the compressed heap space reservation code. The previous code used its instance variables to keep track of previous attempts and didn't release failed reservation memory until the next attempt to reserve memory. I've moved the code to release the memory to be explicit instead. The code that reserves memory is now responsible to check if the returned I've tested this by running the full tier1-7 |
| mem_tag); | ||
| } | ||
|
|
||
| bool MemoryReserver::release(const ReservedSpace& reserved) { |
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.
Should release(release(R)) == release(R) and should release(R& r) do r = {}? Then release({}) is no-op.
In other words, instead of this:
if (rs.is_reserved()) {
MemoryReserver::release(rs);
rs = {};
}we can have
MemoryReserver::release(rs);which to me seems like a good simplification when using the API.
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.
It seems like you've explicitly decided against this in the new API, is there a particular reason for that?
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.
My reasoning was that MemoryReserver does not have the ownership of the ReservedSpace instance, so I didn't want it to be the one clearing the members. If others feel the same way as you do, then I would prefer to add a function release_and_clear to make it clearer (:)) what's going on.
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.
release_and_cleardoes sound clearer :)
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.
My preference is to stay with the current proposal and let code that requested reserve memory decide if and when the ReservedSpace should be cleared. I think it would be an easy thing to reevaluate in another RFE if we change our minds later on.
| } | ||
| }; | ||
|
|
||
| // Class encapsulating behavior specific of memory space reserved for Java heap. |
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.
"of the", "for the"
afshin-zafari
left a comment
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.
Thanks for this work.
I found no problem in logic and replacements. However, some Copyright years have to be updated:
-
New files should have only one year in Copyright text:
memoryReserver.?pp
reservedSpace.?pp -
Changed files:
cds/dynamicArchive.hpp
gc/g1/g1PageBasedVirtualSpace.hpp
gc/parallel/psVirtualspace.hpp
gc/shared/generationCounters.cpp+.hpp
memory/metaspace/virtualSpaceNode.hpp
Thanks for reviewing!
I don't think this is correct. Code was copied from other files, so I transferred the copyright from those files. When I previously have asked around about this situation, the guidance I've been given the guidance that this is preferred over only using the current year. |
|
@jdksjolen @afshin-zafari Are you OK with me pushing the code as it is right now? |
jdksjolen
left a comment
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 am okay with this, I wanted to defer an approval to see whether others would chime in. Thank you for this work.
afshin-zafari
left a comment
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.
Thanks again for this work. No comments.
|
OK. Thanks. I'll give it one more day to let any reviewers get a chance to take a look. |
|
I merged and ran tier1 internally and GHA. Thanks again for reviewing! |
|
Going to push as commit 73b5dba.
Your commit was automatically rebased without conflicts. |
The ReservedSpace class and its friends has a dual functionality of describing a reserved memory region AND it also reserves memory. I would like to split this so that the ReservedSpace classes only acts as data carrier about reserved memory and then have a more explicit API for reserving memory and baking a ReservedSpace given the outcome of the reservation.
See the first comment for the full description:
Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/22712/head:pull/22712$ git checkout pull/22712Update a local copy of the PR:
$ git checkout pull/22712$ git pull https://git.openjdk.org/jdk.git pull/22712/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 22712View PR using the GUI difftool:
$ git pr show -t 22712Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/22712.diff
Using Webrev
Link to Webrev Comment