RFR: 8293491: Avoid unexpected deoptimization in loop exit due to incorrect branch profiling [v2]

[Jie Fu]

On Mon, 12 Sep 2022 03:47:11 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Do these deoptimizations really affect performance of your program or did you just spot them when looking at the logs?
>> 
>> Such surprising deopts are actually expected with optimistic, profile guided optimizations and happen in many other scenarios as well. They are usually harmless. Also, the profile information is not necessarily incorrect but might just be outdated because we stop profiling once we reach C2. Marking all loop exits as taken seems hacky and might have unexpected side effects.
>> 
>> Also, wouldn't C2 still insert a `Deoptimization::Reason_unreached` or `Deoptimization::Reason_unstable_if` trap for subsequent instructions after the loop exit for which profiling also suggests that they were never executed?
>
> Hi @TobiHartmann and @cl4es , patch had been updated.
> Any comments?
> Thanks.

> @DamonFool I'll defer to the real C2 experts on this one. My gut feeling is that adding complexity and hard-to-prove-correct shortcuts to the JIT code in order to avoid some unnecessary deoptimizations does not have a great cost/benefit ratio. Unless this can be quantified in some convincing way (such as demonstrate significantly improved time-to-performance on some specific application) then I'd recommend against this.

Thanks @cl4es for your review.

Although I didn't see performance improvement in real programs, it does benefit to
1) Less deopt in loop exit due to incorrect branch profiling
2) Lower memory consumption (e.g, smaller code cache in use)
3) Lower power consumption (less cpu spending on compilation)

This patch is based on the assumption that for most common cases, the loop exit will be executed at least once.
And the loop detection logic has been updated to based on the flow analysis result.
So what did you mean by `hard-to-prove-correct`?
Thanks.

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

PR: https://git.openjdk.org/jdk/pull/10200