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

Emanuel Peter epeter at openjdk.org
Thu May 8 15:04:53 UTC 2025


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

> Even though I was not able to reproduce the same crash with {d,f,i,l}return because I could not get those or the preceding bytecode to deopt, I also added them to the falls_through() function.

Basically, there are 2 cases:
- opcodes that deopt and retry: these were already there, as far as I know, and @dean-long added them in his previous patch. So here we could only take opcodes that: deopt, retry, and do not have fall-through.
- opcodes that deopt but do not retry, but skip forward to the next op, that we then have to check for fall-through. For the deopting opcode, there are 2 categories:
  - Those that put something on the stack, like `getstatic` that puts whatever it got on the stack. This constrains what opcode comes after. If it returns an object/null, you can only do `return` (ignore stack value) or `areturn` (return that stack value). But you cannot do `ireturn` because the value on the stack is an object, not int.
  - Those that put nothing on the stack. Here we would not be constrained, and could push whatever we need on the stack before that opcode. E.g. we could push an int before that opcode, and then do `ireturn`. But I'm not sure if there are any such opcodes that deopt but push nothing on the stack. Worth checking though!

Hope this case distinction helps a little, I'm not sure it is particularly clear or accurate, but these are the things I would look into if I were working on this bug :)

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

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


More information about the hotspot-dev mailing list