RFR: JDK-8262165: NMT report should state how many callsites had been skipped [v2]

[Thomas Stuefe]

> (This is a breakout from JDK-8261238, which seems to be stuck in review (https://github.com/openjdk/jdk/pull/2428). I factor out the display changes, which hopefully are non-controversial enough to get upstream easily.)
> 
> NMT silently omits call sites in its report whose allocation rate is too small to get over certain, hidden, thresholds:
> a) there is a hard wired threshold of 1K in the baseline collector
> b) we also skip all sites whose size is less than what the unit is (eg scale=G, we skip all allocations < 1G
> 
> NMT report should state how many call sites had been omitted.
> 
> ----
> 
> The patch adds a counter in the NMT reporter to count omitted call sites, then prints that counter out. 
> 
> In base report, just a generic message is shown to notify the user that categories > scale are ignored:
> 
> 
> thomas at mainframe$ jcmd Interl VM.native_memory scale=m
> 2847:
> 
> Native Memory Tracking:
> 
> (Omitting categories weighting less than 1MB)
> 
> Total: reserved=5540MB, committed=147MB
> -                 Java Heap (reserved=3996MB, committed=34MB)
>                             (mmap: reserved=3996MB, committed=34MB) 
> <skip>
> 
> 
> In detail report, the total count of omitted call sites is displayed at the bottom:
> 
> 
> thomas at mainframe$ jcmd Interl VM.native_memory scale=m detail
> 2847:
> 
> <skip>
> 
> [0x00007f4e062e3e6b] os::reserve_memory(unsigned long, bool, MEMFLAGS)+0x16b
> [0x00007f4e05ac4f47] MmapArrayAllocator<unsigned char>::allocate(unsigned long, MEMFLAGS)+0x127
> [0x00007f4e05ac4cb2] G1FromCardCache::initialize(unsigned int)+0xe2
> [0x00007f4e05a863f1] G1CollectedHeap::initialize()+0x3c1
>                              (reserved=1MB, committed=1MB Type=GC)
> 
> (183 call sites weighting less than 1MB each omitted.)
> 
> 
> 
> Note: this patch only takes care of the sites omitted due to the scale threshold (b). It does not count how many sites had been omitted due to the baseline threshold (a). Since I still hope to remove that threshold completely with JDK-8261238, I did not put any work toward modifying the output here.
> 
> ----
> 
> Tests: I manually ran runtime/NMT tests.

Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge
 - feedback aleksey
 -  JDK-8262165

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2687/files
  - new: https://git.openjdk.java.net/jdk/pull/2687/files/a6bbf78a..31ff1eb9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2687&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2687&range=00-01

  Stats: 183730 lines in 5840 files changed: 108394 ins; 53031 del; 22305 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2687.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2687/head:pull/2687

PR: https://git.openjdk.java.net/jdk/pull/2687