-
Notifications
You must be signed in to change notification settings - Fork 5.7k
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-8261302: NMT: Improve malloc site table hashing #2473
JDK-8261302: NMT: Improve malloc site table hashing #2473
Conversation
👋 Welcome back stuefe! A progress list of the required criteria for merging this PR into |
Webrevs
|
b8e11af
to
309d6c0
Compare
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 good to me.
@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 20 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 |
Thanks Zhengyu. |
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.
LGTM, except for the one comment I added (it's not a "must", it's a "please").
@@ -28,6 +28,14 @@ | |||
#include "utilities/globalDefinitions.hpp" | |||
#include "utilities/nativeCallStack.hpp" | |||
|
|||
static unsigned calculate_hash(address stack[NMT_TrackingStackDepth]) { |
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 know it doesn't change anything semantically, but I'd like to see the int type specifier.
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.
Sure, I'll change it before pushing.
Thanks Lucy! |
/integrate |
@tstuefe Since your change was applied there have been 20 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit a3d6e37. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
While looking at NMT tuning statistics, I saw longish bucket chains in the malloc site table and looked whether this can be improved.
The current hash algorithm uses the 32bit masked sum of all stack entries as hash.
I first experimented with different hash algorithms on different platforms (x86 and ppc, the latter because it has uniform op sizes) and did actually not find a noticeable improvement over what NMT does now. It seems that using the raw code pointers as base for the hash gives us already enough entropy. Avg load factor of the table always hovered around what was expected. Regardless of the hash I tried I was not able to get rid of the few longer chains.
The biggest improvement brought an experimental table size increase: currently the table size is 511 pointer slots (~4K). Quadrupling the size would bring the load factor down to 1-2. However, there is this comment in mallocSiteTable.hpp:
jdk/src/hotspot/share/services/mallocSiteTable.hpp
Line 118 in 5183d8a
wich claims that a load factor of 6 is what is aimed for and deemed acceptable. So I am not going to touch that here (even though 4 or 12K more may be an okay price to pay for more efficient lookups.
With that out of the way, there are still small things we can improve about the hash function:
Since the vast majority of
NativeCallStack
objects will always need a hash code, it makes no sense to delay its calculation. By doing the hash code calculation in the constructor we can makeNativeCallStack::hash()
a simple inline getter.When calculating the hash code, I also omitted the "if stack address is 0 stop" logic. The vast majority of call stacks have the full size and nothing much is gained from omitting those 0 values from the hash code calculation.
See difference (linux x86):
Before:
hash() getter is not inlined; it queries the hash code each time and, when calculating it, uses simple adds interspersed with conditional jumps because of the "if stack address is 0 stop" logic.
With this patch, the
NativeCallStack::hash()
gets inlined at the call sites to a simple load.The hash calculation gets now inlined into the constructor and uses a series of simple adds now:
Thanks, Thomas
Progress
Issue
Reviewers
Download
$ git fetch https://git.openjdk.java.net/jdk pull/2473/head:pull/2473
$ git checkout pull/2473