JDK-8261302: NMT: Improve malloc site table hashing #2473
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:
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
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):
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
The text was updated successfully, but these errors were encountered:
@tstuefe This change now passes all automated pre-integration checks.
After integration, the commit message for the final commit will be:
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.
@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.