JVM exceptions are weird: a decompiler perspective

6 comments

• Joker_vD 3 minutes ago

  Doesn't JRE has some limited form of decompilation in its JIT, as a pre-pass? IIRC, it reconstructs the basic blocks and CFG from the bytecode and does some minor optimizations before going on to regalloc and codegen.

• marginalia_nu an hour ago

  On the subject

    void foo() {
      for (;;) {
        try { return; } 
        finally { continue; }
      }
    }
  

  is my favorite cursed Java exceptions construct.
  [-]

  • cerved 31 minutes ago

    To anyone wondering, I believe it's cursed because the finally continue blocks hijacks the try return, so the for loop never returns

  • bear8642 9 minutes ago

    This is exceedingly nasty. Well Done!

• pron an hour ago

  Nice post!

  A minor point:

  > monitors are incompatible with coroutines

  If by coroutines the author meant virtual threads, then monitors have always been compatible with virtual threads (which have always needed to adhere to the Thread specification). Monitors could, for a short while, degrade the scalability of virtual threads (and in some situations even lead to deadlocks), but that has since been resolved in JDK 24 (https://openjdk.org/jeps/491).

  [-]

  • PhilipRoman 19 minutes ago

    I think it's coroutines as in other JVM languages like Kotlin, where yielding may be implemented internally as return (due to lack of native coroutine support in JVM).

    Holding a lock/monitor across a yield is a bad idea for other reasons, so it shouldn't be a big deal in practice.