On Tue, 2 Dec 2025 10:30:46 GMT, Quan Anh Mai <[email protected]> wrote:
> Hi, > > This PR fixes the issue of the compiler crashing with "not enough operands > for reexecution". The issue here is that during > `Parse::catch_inline_exceptions`, the old stack is gone, and we cannot > reexecute the current bytecode anymore. However, there are some places where > we try to insert safepoints into the graph, such as if the handler is a > backward jump, or if one of the exceptions in the handlers is not loaded. > Since the `_reexecute` state of the current jvms is "undefined", it is > inferred automatically that it should reexecute for some bytecodes such as > `putfield`. The solution then is to explicitly set `_reexecute` to false. > > I can manage to write a unit test for the case of a backward handler, for the > other cases, since the exceptions that can be thrown for a bytecode that is > inferred to reexecute are `NullPointerException`, > `ArrayIndexOutOfBoundsException`, and `ArrayStoreException`. I find it hard > to construct such a test in which one of them is not loaded. > > Please kindly review, thanks a lot. src/hotspot/share/opto/doCall.cpp line 958: > 956: ex_node = use_exception_state(ex_map); > 957: // The stack from before the throwing bytecode is gone, cannot > reexecute here > 958: jvms()->set_should_reexecute(false); I agree there are situations where we need to set the reexecute flag explicitly and not base it on the bytecode. I recently fixed JDK-8370766 and filed JDK-8372846 as a followup for similar issues. I need to try out your test to understand this better. Does it cause a backwards-branch safepoint? I suspect that it may not be safe to set rexeecute to false here. If reexecute is false and -XX:+VerifyStack is set, deoptimization may fail if the operands are not on the stack. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28597#discussion_r2583510384
