Integrated: JDK-8297958: NMT: Display peak values

[Thomas Stuefe]

On Sat, 3 Dec 2022 11:32:50 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> 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.

This pull request has now been integrated.

Changeset: 336d230a
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/336d230a39e41eeed8b9d2ce3fec42e9de1d11fe
Stats:     104 lines in 5 files changed: 47 ins; 23 del; 34 mod

8297958: NMT: Display peak values

Reviewed-by: jsjolen, sjohanss

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

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