RFR: JDK-8326586: Improve Speed of System.map [v2]

[Thomas Stuefe]

On Tue, 27 Feb 2024 20:16:29 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Pre-existing nit pick were we supposed to say "fuss" instead of "fuzz" here?
> 
> ` // In case of OOM lets make no fuzz. Just return.`

Hah. I must have seen "hot fuzz" the day before and it stuck in my head.

> src/hotspot/share/nmt/memMapPrinter.cpp line 136:
> 
>> 134:     static uintx last = 0;
>> 135:     if (to <= _ranges[last].from) {
>> 136:       // not sequential? restart at 0
> 
> I would prefer to say something like "the range is to the right of the given section, we need to re-start the search"

okay

> src/hotspot/share/nmt/memMapPrinter.cpp line 137:
> 
>> 135:     if (to <= _ranges[last].from) {
>> 136:       // not sequential? restart at 0
>> 137:       last = 0;
> 
> If we know that the current region is to the right of the given section, couldn't we just start moving to left, one region at the time, instead of re-starting at 0?
> 
> This would be an optimization on top of your optimization, but since we are already touching this might as well consider it?

But we don't know how far away the target entry is. We know it precedes the current entry, but not the distance. This is purely theoretical, since in all scenarios we use this class for the input source is sorted. Therefore we cannot predict any likelihood of being "somewhat sorted".

And then, I have the nagging feeling that searching backward would be less cache-friendly. Since there is no pro, and only one possible con, I'd opt for keeping it this way.

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

PR Comment: https://git.openjdk.org/jdk/pull/17984#issuecomment-1968320772
PR Review Comment: https://git.openjdk.org/jdk/pull/17984#discussion_r1505423565
PR Review Comment: https://git.openjdk.org/jdk/pull/17984#discussion_r1505423243