RFR: JDK-8319314: NMT detail report slow or hangs for large number of mappings [v2]

[Gerard Ziemski]

On Sat, 4 Nov 2023 06:35:57 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> If a lot of mappings have been registered with NMT, NMT detail report may get so slow as to hang seemingly. 
>> 
>> 100 k mappings will take > 1 minute
>> 1 million mappings never returns (I canceled the test after 90 minutes)
>> 
>> We burn all the time doing a sorted insert into the target array of the MemBaseline object. That sorted insert is pointless since the source array is already sorted by region base address.
>> 
>> Omitting the pointless sort drops the runtime for 1 million mappings from > 90 minutes to 48 seconds.
>> 
>> Tests: Tested locally. GHAs (Windows error unrelated).
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix builds

I have a couple small questions/feedback - see below.

Also, you said:


100 k mappings will take > 1 minute
1 million mappings never returns (I canceled the test after 90 minutes)


What are those times now with this change?

src/hotspot/share/nmt/memBaseline.cpp line 119:

> 117:                          AllocFailStrategy::RETURN_NULL> EntryList;
> 118:   EntryList _virtual_memory_regions;
> 119:   size_t    _count;

Why are we bothering with `_count` ? I might be missing something, but I don't see it being used?

src/hotspot/share/nmt/memBaseline.cpp line 126:

> 124: #ifdef ASSERT
> 125:     , _last_base(nullptr)
> 126: #endif

Why not use:

`DEBUG_ONLY(, _last_base(nullptr))`

just like in other places where `_last_base` is used?

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

Changes requested by gziemski (Committer).

PR Review: https://git.openjdk.org/jdk/pull/16480#pullrequestreview-1720700428
PR Review Comment: https://git.openjdk.org/jdk/pull/16480#discussion_r1386845150
PR Review Comment: https://git.openjdk.org/jdk/pull/16480#discussion_r1386847227