On Thu, 12 Mar 2026 10:01:10 GMT, Dean Long <[email protected]> wrote:
>>> In that case, "monitor matching" that the comment below is talking about >>> would have failed. But this is all existing behavior that this PR does not >>> change. >> >> Yes existing behaviour but I'm trying to point out that there may be more >> missing "exception edges". But I have to say I do not at all understand >> what this code is actually doing. Any bytecode can throw due to async >> exceptions under the right circumstances (these days only single-stepping or >> at a breakpoint?). > > 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 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30171#discussion_r2955250187
