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

[Manuel Hässig]

On Fri, 9 May 2025 23:56:14 GMT, Dean Long <dlong at openjdk.org> wrote:

> so it's probably better to treat jsr the same as goto and add it to falls_through.

I added `jsr` to `falls_through()`.

> The comment justifying this logic claims the compiler can emit debug information with the "after" state instead of the "before" state. If this is not true, then we can remove this VerifyStack logic. If it is true, it would be good to understand exactly under what circumstances it can happen.

Isn't this just what is happening in this particular bug? But it is not the debug info that is emitted before or after and only the `bci` that is rarely advanced. Granted, I have not been able to look into that in depth, because I am unfamiliar with those debuginfo emitting codepaths, but a cursory look seemed to suggest that it is always emitted at the end of `PhaseOutput::Process_OopMap_Node` which would be the same for all bytecodes.

> It seems like it would be safe to skip the falls_through/try_next_mask logic for the top frame if we are reexecuting at the current bci, but that is a riskier change.

I agree, but I don's see a good way to find out if the `bci` has been moved. A hacky solution might be to check if the deopt reason is `assert_null_or_unreachable0` since the `bci` is only moved in some deopts with that reason.

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

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