Details
-
Enhancement
-
Resolution: Fixed
-
P4
-
20
-
b27
Backports
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8317541 | 17.0.10 | Goetz Lindenmaier | P4 | Resolved | Fixed | b01 |
Description
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 - when the compile arena is at its largest extension. But if we had peak values, you'd see how much the compiler needed by looking at its peak extension.
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 I propose to change the meaning and implementation of peak count from today's "highest count" to "count at the point peak size was reached".
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 I propose to change the meaning and implementation of peak count from today's "highest count" to "count at the point peak size was reached".
Attachments
Issue Links
- backported by
-
JDK-8317541 NMT: Display peak values
- Resolved
- relates to
-
JDK-8317772 NMT: Make peak values available in release builds
- Resolved
-
JDK-8320061 [nmt] Multiple issues with peak accounting
- Resolved
- links to
-
Commit openjdk/jdk17u-dev/20d41b94
-
Commit openjdk/jdk/336d230a
-
Review openjdk/jdk17u-dev/1822
-
Review openjdk/jdk/11497
(2 links to)