RFR: 8305995: Use full dominant search for regions

[Kirill A. Korinsky]

On Fri, 14 Apr 2023 16:06:05 GMT, Vladimir Kozlov <kvn 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.
>
> First, please update PR's title, it should match JBS's title.
> Second, @catap you referenced JMH benchmark. Is it already in `test/micro/org/openjdk/bench/` or it is new? Please add it if it is new.
>  
> So before 8224957 code looks through in(1) for req() > 3 (and == 2). After 8224957 we bailout for >3 inputs.
> This fix removed this restriction and we now go through all inputs for case > 3 inputs.
> It may increase compilation time for such cases significantly but on other hand it may allow reduce IR.
> 
> I assume, based on description, x4 increase is in Java heap due to not unboxing some Java objects. Or is it memory consumed by C2 Jit compiler during benchmark execution?

@vnkozlov after spending some time to simplify my benchmark and to include it into PR as the next commit, I'd like to conclude that boxing / unboxing aren't doing anything with it.

I just made a force push which contains the benchmark. JMH reports that it almost hasn't got memory footprint in runtime `≈ 10⁻³` on JDK up to  13 includes, but on JDK 15 and after that it consumes `≈ 7536`.

So, in fact it isn't x4, I was wrong on the first assumption. It is much bigger.

P.S. I've also rewrite the commit message and include issue ID into it.

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

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