RFR: 8336906: C2: assert(bb->is_reachable()) failed: getting result from unreachable basicblock [v2]

[Manuel H�ssig]

On Thu, 8 May 2025 14:54:05 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> For the test: It's a bit of a shame to have lots of separate files.

I got myself confused with class visibilities. I moved the `A` and `B` into the java test file and moved both of them one directory lower into `compiler/interpreter`. That makes it a lot cleaner.

> Or else argue why it CANNOT be done.

I looked into it some more and there are two places where we deopt and move the `bci` over to the next bytecode: when an object of an unloaded class is returned by `getstatic` (see code in the PR description) and calls (see below) and the object reference is `null`.

https://github.com/openjdk/jdk/blob/411a63ea1b0c6e8bfea219427bf1c317c5dadabf/src/hotspot/share/opto/doCall.cpp#L770-L785

Since `{d,f,i,l}return`, `{table,lookup}switch`, and `ret` require an integer on the stack but only bytecodes that push references on the stack can deopt to the next `bci`, we cannot trigger this error for those bytecodes. Now, that begs the question, whether these bytecodes should then be in `falls_through()`. I argue that they should be, since that would be the correct behavior if we deopted at such a bytecode.

> Did you go through all bytecodes we support here?

I did, but I missed `lookupswitch` and `tableswitch`. `jsr` just pushes the address of the next bytecode onto the stack. `ret` can jump to such an address, but I already added that to `falls_through()`.

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

PR Comment: https://git.openjdk.org/jdk/pull/25118#issuecomment-2866965280