-
Enhancement
-
Resolution: Fixed
-
P4
-
21, 22
-
b20
NMT is okay for initial triaging but no help when digging deeper into compiler footprint. NMT shows how much native memory the JIT uses but lumps together footprints from concurrent compilations, making its peak values arbitrary. And we have no way to associate the NMT numbers with individual allocations.
This RFE is a proposal for a new statistic that reports memory usage per compilation. That will allow us to understand footprint issues and libc mem retention better and can be the first step in footprint reductions or, potentially, for adding a memory ceiling to C2.
Examples:
1) Enable memory statistics globally
```
java ... -XX:CompileCommand=MemStat,*.*
```
2) Enable memory statistics for j.l.String, print logs after each compilation and a final report at VM exit:
```
-XX:CompileCommand=MemStat,java.lang.String::*,print
```
- relates to
-
JDK-8318671 Potential uninitialized uintx value after JDK-8317683
- Resolved
-
JDK-8319948 jcmd man page needs to be updated
- Resolved
-
JDK-8330625 Compilation memory statistic: prevent tearing of the final report
- Resolved
-
JDK-8344009 Add by-phase accounting to compiler memory statistics
- Open
-
JDK-8318016 Per-compilation memory ceiling
- Resolved
-
JDK-8330103 Compiler memory statistics should keep separate records for C1 and C2
- Resolved
-
JDK-8319449 compiler/print/CompileCommandPrintMemStat.java fails on Graal
- Resolved
-
JDK-8337031 Improvements to CompilationMemoryStatistic
- Resolved