On Wed, 18 Mar 2026 17:52:25 GMT, Coleen Phillimore <[email protected]> wrote:
>> The case where aload_0 is the first instruction in a handler would be >> covered by exception_can_trap(), right? > > 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30171#discussion_r2957025391
