RFR: 8271055: Crash during deoptimization with "assert(bb->is_reachable()) failed: getting result from unreachable basicblock" with -XX:+VerifyStack

[Yi Yang]

Hi, I'm trying to fix JDK-8271055. The root cause is that some basic blocks are not interpreted because there is no trap bytecode inside them, these basic blocks eventually become unreachable and lead to a crash. Maybe we need to coordinate compiler and hotspot groups to fix this crash.

The attached test generates the following bytecode:

  void test();
    descriptor: ()V
    flags: (0x0000)
    Code:
      stack=2, locals=3, args_size=1
         0: iconst_1
         1: istore_1
         2: iload_1
         3: bipush        100
         5: if_icmpge     29
         8: iinc          1, 1
        11: goto          2
        14: astore_2
        15: iload_1
        16: bipush        100
        18: if_icmpge     27
        21: iinc          1, 1
        24: goto          15
        27: aload_2
        28: athrow
        29: return



Javac generates some unreachable basic blocks(BCI 14 - 28), and there is no exception table for them, VM knows nothing about them. I found the same bug report at JDK-8022186 which was marked as `Fixed`, but I think it was not properly fixed, In some similar cases, javac cannot work well, I have filed https://bugs.openjdk.java.net/browse/JDK-8271254 for another javac bug.

Going back to this bug, the proposed change is to insert a nop in empty try-block so that javac can generate the correct exception table. Now generated bytecodes look like this:

  void test();
    descriptor: ()V
    flags: (0x0000)
    Code:
      stack=2, locals=3, args_size=1
         0: iconst_1
         1: istore_1
         2: nop
         3: iload_1
         4: bipush        100
         6: if_icmpge     30
         9: iinc          1, 1
        12: goto          3
        15: astore_2
        16: iload_1
        17: bipush        100
        19: if_icmpge     28
        22: iinc          1, 1
        25: goto          16
        28: aload_2
        29: athrow
        30: return
      Exception table:
         from    to  target type
             2     3    15   any


However, this is not the end. Even if the exception table is correctly generated, VM only enters GenerateOopMap::do_exception_edge when the bytecode may be trapped. In order to setup handler block, we need to relax this restriction to allow even bytecodes such as nop to correctly enter GenerateOopMap::do_exception_edge. Otherwise, handler block will not be interpreted, its stack is problematic and finally hits the assertion.

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

Commit messages:
 - fix

Changes: https://git.openjdk.java.net/jdk/pull/4902/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4902&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271055
  Stats: 61 lines in 3 files changed: 59 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4902.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4902/head:pull/4902

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