On Thu, 11 Dec 2025 02:09:08 GMT, Dean Long <[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. > > @merykitty , I tried solution 1) and it seems to work, but I think I prefer > solution 2) because it aligns better with my idea from JDK-8372846 of > canonicalized exception states. If you like, I can take over this bug. @dean-long Thanks a lot, please take over this bug then. > trim stack, throw exception (move to Thread) (reexecute=true) This requires extra unconditional overhead even though safepoint rarely happens. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28597#issuecomment-3639912845
