RFR: JDK-8297958: NMT: Display peak values [v2]

[Thomas Stuefe]

> Historical peak values can be very useful in analyzing memory footprint. 
> 
> For example, want to know how much memory the compiler needs during warmup? You have to get an NMT report at the exact time, with compile arenas at their largest combined extensions. But if we had peak values, you'd see how much the compiler needed by just looking at its arena peak size.
> 
> We already collect peak values in debug builds, but never actually display them. Since we already pay for them, we might just as well print them.
> 
> There is also a small issue that peak size and count are updated separately. It makes not much sense to treat these as independent values. Therefore this patch changes the meaning and implementation of peak count from today's "highest count" to "count at the point peak size was reached". 
> 
> How this looks like:
> 
> 
> -                        GC (reserved=425748KB, committed=94868KB)
>                             (malloc=38552KB #1086) (peak=38622KB #1409)   <<<<
>                             (mmap: reserved=387196KB, committed=56316KB) 
>  
> -                 GCCardSet (reserved=29KB, committed=29KB)
>                             (malloc=29KB #387) 
>  
> -                  Compiler (reserved=200KB, committed=200KB)
>                             (malloc=36KB #59) (peak=37KB #74)    <<<<
>                             (arena=165KB #5) (peak=6192KB #18)  <<<<
> 
> 
> 
> [0x00007f7e6b0866b0] Arena::grow(unsigned long, AllocFailStrategy::AllocFailEnum)+0x40
> [0x00007f7e6c117a29] OopMap::OopMap(int, int)+0x69
> [0x00007f7e6b2857a5] LinearScan::compute_oop_map(IntervalWalker*, LIR_Op*, CodeEmitInfo*, bool)+0x85
> [0x00007f7e6b285f2a] LinearScan::compute_oop_map(IntervalWalker*, LIR_OpVisitState const&, LIR_Op*)+0x5a
>                              (malloc=32KB type=Arena Chunk #1) (peak=288KB #9) <<<<
> 
> 
> Notes:
> 
> - This RFE just adds peak to the *debug* VM. In debug, we already have all values, its just a matter of printing them. I would love to see peak values in release builds too, but collecting them does cost one or more CAS per malloc and therefore we must analyze performance before enabling. Having them in release would also remove the remaining #ifdef ASSERT.
> 
> - I omit printing peak values when we are at peak. So if "peak" is missing, current peak is implied.
> 
> - I only print peak values in summary and detail mode, not in any of the diff modes, to keep code complexity low and because diff modes are more about baseline compare.
> 
> - In detail mode, there is a small display issue that call sites will be omitted that have no current allocations. A hypothetical call site that allocated a zillion byte, then freed them all, will not be shown even though its peak value would be interesting. That is an issue for another RFE.

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  small fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11497/files
  - new: https://git.openjdk.org/jdk/pull/11497/files/40a4dfd7..753d87da

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11497&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11497&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11497.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11497/head:pull/11497

PR: https://git.openjdk.org/jdk/pull/11497