On Thu, 12 Mar 2026 05:13:45 GMT, David Holmes <[email protected]> wrote:
>> So I left this block of code that's indented but I haven't figured out what >> it means. I probably should have made this a draft PR until then but maybe >> you can help. >> >> The comment in aload_0 makes no sense. No idea why it would return and not >> be covered in an exception handler. Same with monitor_top. If the bytecode >> can throw an exception it should fall through to the code below that creates >> the exception edge. > >> 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30171#discussion_r2923516592
