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.