-
Notifications
You must be signed in to change notification settings - Fork 6.2k
8332237: [nmt] Remove the need for ThreadStackTracker::track_as_vm() #19231
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
8332237: [nmt] Remove the need for ThreadStackTracker::track_as_vm() #19231
Conversation
|
👋 Welcome back stuefe! A progress list of the required criteria for merging this PR into |
|
@tstuefe 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 23 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 |
|
@tstuefe this pull request can not be integrated into git checkout JDK-8332237-nmt-Thread-stack-tracking-remove-track_as_vm
git fetch https://git.openjdk.org/jdk.git master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push |
|
@tstuefe To determine the appropriate audience for reviewing this pull request, one or more labels corresponding to different subsystems will normally be applied automatically. However, no automatic labelling rule matches the changes in this pull request. In order to have an "RFR" email sent to the correct mailing list, you will need to add one or more applicable labels manually using the /label pull request command. Applicable Labels
|
1a7029c to
f97592f
Compare
c86f864 to
6d1eb6c
Compare
6d1eb6c to
42c2e1d
Compare
|
Thanks to @JoKern65 for running this through the AIX CI at SAP |
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.
Hi,
I'm very happy to see this simplification being made in NMT, thank you for doing this! Code looks good to me, have you run this through any non-AIX CI?
|
/label hotspot-runtime |
Yes, it ran the full gamut of tests over at SAP. They test on a ton of platforms. |
|
@tstuefe |
Ship it! (after receiving another review) |
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.
Nice cleanup. All OK. Thanks.
|
Thanks @jdksjolen and @afshin-zafari . I'll wait the obligatory 24, and maybe for @zhengyu123 to chime in in case I got some of the history wrong. |
|
/integrate |
|
Going to push as commit 9160ef8.
Your commit was automatically rebased without conflicts. |
This PR simplifies NMT by removing a bunch of code needed only to track thread stacks on AIX (
ThreadStackTracker::track_as_vm()is actually#ifndef AIXin disguise).NMT has two ways to track thread stacks:
A) piggybacking on the virtual memory accounting
B) piggybacking on malloc accounting
(A) is done on all platforms except AIX. (B) is AIX.
This is because on AIX, thread stacks (more precisely, the boundaries of thread stacks as the JVM knows them) are not page-aligned. Therefore we track these stacks as if they had been allocated with malloc. This special handling adds a lot of complex coding to NMT.
We (@zhengyu123 and me) originally decided on this approach to keep NMT versatile and able to deal with platforms that place thread stacks wherever. Or with the hypothetical that the JVM manages its own thread stacks. The latter never manifested - for a number of reasons, the thread library tends to be better at managing thread stacks than the application.
In practice, we only ever did this for AIX. The irony is that with this method, we track stacks as if they were fully alive. So, arguably, this method is just a rather complicated way of iterating all live threads and adding up their thread stack sizes.
On all other platforms, we track thread stacks as virtual memory. For every thread stack tracked, we also query memory liveness via
os::committed_in_range(on closer inspection, another misnomer since this function does not query commit state but liveness).os::committed_in_rangeis implemented on Linux and Windows, and a fallback variant exists that just acts as if the whole range were committed.Solving the thread-stacks-not-page-aligned problem can be done in a much simpler way by aligning thread stack boundaries - for the purpose of NMT - inward to the next inner page boundaries. We pay a very small loss in fidelity. But we can now use the same method all other platforms use. We can throw away a bunch of code. And, if we ever implement
os::committed_in_rangefor AIX, we get real thread stack liveness tracking for free.Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/19231/head:pull/19231$ git checkout pull/19231Update a local copy of the PR:
$ git checkout pull/19231$ git pull https://git.openjdk.org/jdk.git pull/19231/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 19231View PR using the GUI difftool:
$ git pr show -t 19231Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/19231.diff
Webrev
Link to Webrev Comment