RFR: JDK-8261238: NMT should not limit baselining by size threshold [v5]

[Martin Doerr]

On Tue, 23 Feb 2021 07:14:04 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> NMT is a very useful tool to detect memory leaks. Its easy to use, relatively cheap and requires almost zero setup.
>> 
>> But it artificially limits output to call sites with >1K total memory consumption. That is not helpful, as it confuses the developer and obscures possible memory leaks. It also introduces subtle display errors in that callsites suddenly seem to appear, when comparing to the baseline, with a load of >1K when in fact they had been there already when the baseline was taken.
>> 
>> I propose to remove the 1K limit completely. This will marginally increase the costs of taking "detail" NMT reports by about 210K for a single report, 420K for a report done using a baseline.
>> 
>> If this is really a problem preventing us from getting more precise NMT output (really?) there are possibilities to decrease the cost again by sharing call stacks by reference instead of copying them around. I have a patch in work which does just that (https://bugs.openjdk.java.net/browse/JDK-8261491), but I honestly think adding 200-400K *temporarily* during NMT detail reporting would not be such a big deal.
>
> 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 four additional commits since the last revision:
> 
>  - Merge
>  - Split out display changes
>  - Exclude zero-sized regions from baseline
>  - Start

I'm convinced that Thomas' version is better. Especially after his additional enhancement he has promised (JDK-8261491).
NMT should be able to dectect memory leaks caused by small allocations. So using no threshold should be default IMHO. And I prefer not to add a switch.

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

Marked as reviewed by mdoerr (Reviewer).

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