RFR: 8305995: Use full dominant search for regions [v2]

[Kirill A. Korinsky]

On Fri, 14 Apr 2023 18:16:35 GMT, Kirill A. Korinsky <duke at openjdk.org> wrote:

>> This is a fix for the regression introduced by da43cb5e463069cf4dafb262664f0d3d7c2e0eac in fix 8224957.
>> 
>> This regression was found while attempting to migrate an application from JDK 1.8 to JDK 17, by running internal benchmarks, and while investigating abnormal memory usage for about 4 times more from one of them.
>> 
>> The regression appears in the JMH benchmark, which builds a huge tree which contains boxed integers from 0 to a few thousand. A tree has very complex structure and the same objects are reused a lot.
>> 
>> When an `integer` is found it's collected as `Integer` and unboxed inside the collector callback.
>> 
>> This benchmark was run with `ParallelGC` on different JVMs: `JDK 1.8.0_362`, `JDK 11.0.18`, `JDK 13.0.13`, `JDK 15.0.9`, `JDK 17.0.6`, `JDK 19.0.2` and `JDK 20`. This allows to see that something has changed between 13 and 15, and that the memory footprint for this code has increased from `3152` to `11828` bytes per operation.
>> 
>> After that I've done a `git bisect` which allows me to locate the introducer.
>> 
>> So the current fix reduces the memory footprint on the local root 425ef0685c584abec80454fbcccdcc6db6558f93 to `2960` bytes per operation.
>
> Kirill A. Korinsky has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8305995: Use full dominant search for regions
>   
>   This is a fix for the regression introduced by
>   da43cb5e463069cf4dafb262664f0d3d7c2e0eac in fix 8224957.
>   
>   This regression was found while attempting to migrate an application
>   from JDK 1.8 to JDK 17, by running internal benchmarks, and while
>   investigating abnormal memory usage for about 4 times more from one of
>   them.
>   
>   The regression appears in provided JMH benchmark, which builds a RB-tree
>   based map which contains 780 entries with primitive integers.
>   
>   This benchmark was run with `ParallelGC` on different JVMs: `JDK
>   1.8.0_362`, `JDK 11.0.18`, `JDK 13.0.13`, `JDK 15.0.9`, `JDK 17.0.6`,
>   `JDK 19.0.2` and `JDK 20`. This allows to see that something has changed
>   between 13 and 15, and that the memory footprint for this code has
>   increased from nothing `≈ 10⁻³ ` to `7536` bytes per operation.
>   
>   Proposed fix reduces the memory footprint expected value.

Renamed. I've run it as `make test TEST="micro:RBTreeSearch" MICRO_OPTIONS="-prof gc"` and have an output on my branch:

Benchmark                                 Mode  Cnt   Score    Error   Units
RBTreeSearch.search                      thrpt   12   0.079 ±  0.013  ops/us
RBTreeSearch.search:·gc.alloc.rate       thrpt   12  ≈ 10⁻⁴           MB/sec
RBTreeSearch.search:·gc.alloc.rate.norm  thrpt   12   0.003 ±  0.001    B/op
RBTreeSearch.search:·gc.count            thrpt   12     ≈ 0           counts

if I revert my changes by `git diff ..origin/master -- src/hotspot/share/opto/node.cpp | patch -p1` for example and re-run test I do have an output:

Benchmark                                 Mode  Cnt     Score    Error   Units
RBTreeSearch.search                      thrpt   12     0.044 ±  0.009  ops/us
RBTreeSearch.search:·gc.alloc.rate       thrpt   12   209.072 ± 42.450  MB/sec
RBTreeSearch.search:·gc.alloc.rate.norm  thrpt   12  5024.005 ±  0.001    B/op
RBTreeSearch.search:·gc.count            thrpt   12    17.000           counts
RBTreeSearch.search:·gc.time             thrpt   12    17.000               ms


As you may see memory footprint quite different.

As test machine I use right now macOS 12.6.3. I may find some linux, but I doubt that this logic is os specific.

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

PR Comment: https://git.openjdk.org/jdk/pull/13453#issuecomment-1509101903