RFR: JDK-8296931: NMT tests slowed down considerably by JDK-8242181

[Christian Hagedorn]

On Mon, 14 Nov 2022 12:43:41 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> We noticed that NMT tests on our slower PPC machines started failing.
> 
> The reason is that NMT detail reports have become 2-5x slower. This is caused by us now parsing the dwarf debug information to extract source information for each PC in each call stack. That is nice but costly.
> 
> The slowdown is not limited to PPC, it affects all Elf platforms. On my Linux x64 box, runtime/NMT/VirtualAllocCommitMerge.java increased from 20 to 90 seconds.
> 
> ---
> 
> This patch simply removes source info from NMT call stacks. They are not that important for pinpointing leaks and such. I considered more involved solutions, like making them optional via an argument to the NMT report command, but decided against it. The added benefit would be small, not worth much complexity.
> 
> With this patch, on my box with -conc 4 all NMT together are about 2.5 x faster (2m56 -> 1m09).

Thanks for the closer analysis of execution time. I agree with your proposed solution and deciding against an additional option/flag, given the complexity and the limited benefit. The main purpose and motivation behind JDK-8242181 was to get the additional source information in hs_err files.

src/hotspot/share/utilities/nativeCallStack.cpp line 100:

> 98:       // Note: we deliberately omit printing source information here. NativeCallStack::print_on()
> 99:       // can be called thousands of times as part of NMT detail reporting, and source printing
> 100:       // can slow down reporting by a factor of 5 or more depending on platform (see JDK-8296931).

I'm not sure what the convention is, should we still directly refer to bug numbers in comments?

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

Marked as reviewed by chagedorn (Reviewer).

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