On Wed, 18 Mar 2026 17:56:32 GMT, Coleen Phillimore <[email protected]> wrote:
>> About aload_0, it seems to be marked "can trap" because `aload_0; >> _fast_igetfield` can be rewritten to `_fast_iaccess_0`. This iterator is >> returning java_code() not the raw fast bytecodes, so effectively seeing >> `aload_0; _getfield ` instead. A real aload_0 can't trap, only a fast >> bytecode can. What this has to do with monitor analysis, I assume it is >> because synchonized blocks use exception handlers and we want to treat only >> the _getfield in the pair as "can trap" and not the aload_0, but it's not >> clear to me what could go wrong if also treated the aload_0 as "can trap". >> The _monitor_top check is basically saying if _monitor_top > 0 then >> monitorexit can't throw an exception because it has a matching monitorenter. > >> Any bytecode can throw due to async exceptions under the right circumstances >> (these days only single-stepping or at a breakpoint?). > > The change in at_safepoint_no_async() disables throwing an async exception at > any bytecode that cannot trap. I don't know about breakpoints. Do they need > to disable async exceptions too? > > > JRT_ENTRY(void, InterpreterRuntime::_breakpoint(JavaThread* current, Method* > method, address bcp)) > JvmtiExport::post_raw_breakpoint(current, method, bcp); > JRT_END > The _monitor_top check is basically saying if _monitor_top > 0 then > monitorexit can't throw an exception because it has a matching monitorenter. But with async exceptions, the monitorenter/monitorexit bytecodes can trap at that bci before the bytecode is executed when single stepping. So I'm starting to believe that the entire switch statement needs to be removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30171#discussion_r2955937921
