Weird entry in the exception table for monitorenter/monitorexit

Question

I've created a simple test class with one method:
public class TestClass {
     int a = 0;
     public void test() {
          synchronized(TestClass.class) {
               a = 1;
}After opening the generated class file with Eclipse I got the next
result (I've removed the parts that are irrelevant)
public void test();
0 ldc <Class TestClass> [1]
2 dup
3 astore_1
4 monitorenter
5 aload_0 [this]
6 iconst_1
7 putfield TestClass.a : int [12]
10 aload_1
11 monitorexit
12 goto 18
15 aload_1
16 monitorexit
17 athrow
18 return
Exception Table:
[pc: 5, pc: 12] -> 15 when : any
[pc: 15, pc: 17] -> 15 when : any
I do understand that after the monitor is entered it is very important that it leaves it again with the instruction monitorexit. In normal case where no exceptions occur it will call monitorexit at the address 11. But if an exception occurs it has to make sure monitorexit is called and therefore the exception table defines in the first entry that on any exception the VM jumps to address 15. Until here everything is understandable, but what is the second entry in the exception table telling me? if an exception occurs betweern 15 and 17 then jump to 15 ... doesn't this cause an endless loop?

Answer 1

Just saw this topic, have you investigated this further? I agree it's weird, and maybe would've gotten more attention in the compiler forum, because it's not really a VM issue...
The bytecode in your OP also differs from the example given in JVMS chapter "Compiling for the Java Virtual Machine", section 7.14 Synchronization: http://java.sun.com/docs/books/jvms/second_edition/html/Compiling.doc.html#6530
In particular, the first monitorexit instruction is not covered by the "finally" handler there. In your example (and some produced with javac 1.6.0_01), it is. Now when one of the monitorexit instructions throws, the bytecode emitted by javac will keep retrying monitorexit until it finally succeeds (assumed that this is possible), only to immediately throw an exception that indicates that the monitorexit instruction failed?! I hesitate to call it a paradox for some other reason, but definitely very strange. It's also interesting to note that in all the test classes I looked at (and your example, too) a simple decrement of "end_pc" by 1 in the respective exception table entries would be sufficient to achieve a somewhat sane behaviour...