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

[Vladimir Kozlov]

On Mon, 19 Sep 2022 13:01:25 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> 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.

I agree with @cl4es on this. Usually after loop you will have other code also with 0 profiling and it will be deoptimized with your changes. If you let it run in Interpreter after loop deoptimization you will get profiling for post-loop code.
There are valid cases when loop is exited on some other conditions so we never reached normal iteration exit. C2 will rotate and optimize such loops in most optimal way.   I am not sure hacking profiling only based on code shape of loop's exit is right thing to do.

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

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