Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8261334

NMT: tuning statistic shows incorrect hash distribution

    XMLWordPrintable

    Details

    • Subcomponent:
    • Resolved In Build:
      b09

      Backports

        Description

        Tuning statistics for the malloc site hash map in NMT use a MallocSiteWalker to walk the malloc sites.

        There is a bug in the report code which causes hash distribution statistics displayed to be widely off:

        ```
        Hash distribution:
          1 entry: 179
          2 entries: 79
          3 entries: 66
          4 entries: 72
          5 entries: 98
          6 entries: 75
          7 entries: 55
          8 entries: 43
          9 entries: 22
         10 entries: 16
         11 entries: 5
         12 entries: 6

        ```

        This is the bucket chain length histogram. Note that the sum of all values is 716 which exceeds the table width of 511, the total number of buckets. Depending on the hash function used, the statistics may be way more off though.

        The problem is caused by a bug in the walker code where the bucket index is calculated by manually mod'ing `NativeCallStack::hash()` with table size:

        https://github.com/openjdk/jdk/blob/d0a8f2f737cdfc1ae742d47f2dd4f2bbc03f4398/src/hotspot/share/services/memTracker.cpp#L263

        which is wrong since the hash is defined as signed int. So it yields incorrect index values if the hash code is <0, compared with the regular hashcode-to-index calculation done in the table itself:

        https://github.com/openjdk/jdk/blob/d0a8f2f737cdfc1ae742d47f2dd4f2bbc03f4398/src/hotspot/share/services/mallocSiteTable.hpp#L243

        which leads the walker class to reckon that we now enter a different bucket chain and closes the former bucket chain off. Therefore, in the end, we appear to have more chains than table size would allow for.

        This is an old bug, in there since almost the start of NMT (JDK-8046598). Note that it causes the statistics to look better than it actually is, since it reports a long chain as multiple short chains.

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                stuefe Thomas Stuefe
                Reporter:
                stuefe Thomas Stuefe
                Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved: