RFR: 8286104: use aggressive liveness for unstable_if traps

[Xin Liu]

On Fri, 6 May 2022 21:44:55 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> And I am not clear what you mean in 2. Re-execution in Interpreter will be done according to information in uncommon trap (bci).

first, I have to admit that I overlook the fact that reexecution will update MDO of if bytecode.  

For item 2:  reexecution in interpreter takes the other path, or next bci.  Here is my thought: when HotSpot reinterprets the original bc, it must take the unstable path, otherwise this deoptimization shouldn't happen in the first place.  In this patch,  I just shift bci of uncommon_trap to next_bci, not only in IR, but also in ScopeDesc!  Interpreter will start over with the shifted bci.  

Here is what I generated for the unstable_if of [Test::foo ](https://bugs.openjdk.java.net/browse/JDK-8276998?focusedCommentId=14492303&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14492303) using this patch. please note that the bci changed from 11 to 21.  The message pasted in [JDK-8276998](https://bugs.openjdk.java.net/browse/JDK-8276998) was from my initial patch. I retained bci for uncommon_trap initially. I think this change is simpler. 


02f     call,static  wrapper for: uncommon_trap(reason='unstable_if' action='reinterpret' debug_id='0')
        # Test::foo @ bci:21 (line 67) L[0]=_ L[1]=_ L[2]=#0
        # OopMap {off=52/0x34}
034     stop    # ShouldNotReachHere

I admit my change misses to update MDO in deoptimization. I think it's fine because HotSpot won't recompile this method again until interpreter evaluates it thousands of times. The MDO still gets updated.

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

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