On Thu, 19 Mar 2026 00:30:44 GMT, Dean Long <[email protected]> wrote:
>> Yes, aload_0 can trap so it'll get to this switch statement. But if we find >> an aload_0, it'll return and not create an exception edge to any containing >> handlers. This claims so the monitor analysis works, but honestly no idea >> why. >> >> I commented out this entire switch statement looking for some test case >> where something unexpected would happen but there were no test failures. >> >> It seems like this return here is wrong (?) > > The return for aload_0 looks correct to me. This ignores the > Bytecodes::can_trap() and treats it as false, because aload_0 cannot trap. > Even the the fast bytecodes that can trap advance the bci first, so it is the > next instruction (like getfield) that is used to find the handler. > What does this have to do with monitors? Maybe nothing. I couldn't find > anything to explain the reference to monitor analysis. > It would be tempting to change the Bytecodes::can_trap() table to use "false" > for aload_0, but then something else might break. It's also unclear if a > single "can trap" value makes sense for fast bytecodes that fuse two > operations into one. Okay this explanation helps with aload_0 in the switch statement. Rewriting is ambiguous - I was thinking of the rewriter and that didn't help. So it makes sense that the aload_0 should exit because it says it can trap but it cannot trap (unless it's the first instruction in the exception handler and the condition above handles that). The monitorexit and monitorenter can trap with async exceptions so I don't know why we exit the do_exception_edge() method for them. The comments seem to think they can't trap if the monitors match but it's ignoring async exceptions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30171#discussion_r2960112688
