RFR: 8286104: use aggressive liveness for unstable_if traps

[Xin Liu]

On Thu, 5 May 2022 05:30:06 GMT, Xin Liu <xliu at openjdk.org> wrote:

> I found that some phi nodes are useful because its uses are uncommon_trap nodes. In worse case, it would hinder boxing object eliminating and scalar replacement. Test.java of JDK-8286104 reveals this issue. This patch allows c2 parser to collect liveness based on next bci for unstable_if traps.  In most cases, next bci is closer to exits, so live locals are diminishing.  It helps to reduce the number of inputs of unstable_if traps. 
> 
> This is not a REDO of Optimization of Box nodes in uncommon_trap(JDK-8261137). Two patches are orthogonal.  I adapt test from [TestEliminateBoxInDebugInfo.java](https://github.com/openjdk/jdk/pull/2401/files#diff-49b2e38825aa4c28ca196bdc70c3cbecc2e835c2899f4f393527df4796b177ea), so part of credit goes to the original author.  I found that Scalar replacement can take care of the object `Integer ii = Integer.valueOf(value)` in original test even it can't be removed by later inliner.  I tweak the profiling data of Integer.valueOf() to hinder scalar replacement. 
> 
> This patch can cover the problem discovered by JDK-8261137. I ran the microbench and got 9x speedup on x86_64. It's almost same as JDK-8261137. 
> 
> Before:  
> 
> Benchmark               Mode  Cnt   Score   Error  Units
> MyBenchmark.testMethod  avgt   10  32.776 ± 0.075  us/op
> 
> After: 
> 
> Benchmark               Mode  Cnt   Score   Error  Units
> MyBenchmark.testMethod  avgt   10  3.656 ± 0.006  us/op
>  ```
> 
> Testing
> I ran tier1 test with and without `-XX:+DeoptimizeALot`. No regression has been found yet.

hi, Vladimir, 

I really appreciate you look into this issue.  your inputs are super helpful. 
I found that we have multiple options to attack Huawei's problem.  I have yet another idea...

C2's speculative compilation is fascinating.  The motive we would like to prune an infrequent branch should be that we can simplify IR and shrink code size. Back to Test::foo(), the else block is blank... Pruning a trivial basic block actually makes IR more complex. We should not replace a trivial basic block with unstable_if . 

What Tobias reported is a great example. C2 compiled foo() before it became mature. therefore, C2 refrained his "heroic optimization. it turns out that c2 selects CMOVE and gets simpler, faster and smaller code...

thanks,
--lx

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

PR: https://git.openjdk.java.net/jdk/pull/8545