Compiling Try/Catch/Finally on the JVM

One thing we’re currently working on, for a variety of reasons, is compiling down our in-house programming language into Java bytecode (and just for the record, I can’t make any promises about when we’ll be done or around when or even if this stuff will make it into future product releases).  Part of the fun therein is learning about the internals of the JVM, as well as finding all the crazy edge cases in your own language.  And few things are as, um, “fun” or have as many edges as try/catch/finally statements.  So rather than delving into philosophy or agile methodology this time around, I’ll go into detail on an area of the JVM that most people never have to (or probably want to) delve into.

If you’d asked me two weeks ago, I would have assumed that finally blocks are a feature implemented by the JVM:  it’s such a core language thing, it’s got to be built-in, right?  Much to my surprise, the answer is no:  finally blocks are implemented by inlining the finally code at all possible exits from the try or associated catch blocks, wrapping the whole thing in essentially a “catch(Throwable)” block that rethrows the exception when it finishes, and then adjusting the exception table such that the catch clauses skip over the inlined finally statements.  Huh?  (Small caveat:  prior to the 1.6 compiler, apparently, finally statements used sub-routines instead of full-on code inlining.  But we’re only concerned with 1.6 at this point, so that’s what this applies to).

That probably doesn’t make any sense, so let’s rewind a bit with some JVM basics around exception handling.  Exception handling is built into the JVM, and it’s done so in the form of declaring try/catch blocks within a given method.  What you’re saying is “between point A and point B, any exceptions of type E should be handled by the code at point C.”  You can have as many such declarations as you need, and when an exception is propogated to that method the JVM finds the catch block that matches based on the extent and the type of exception it handles.

So with a simple example:

public void simpleTryCatch() {
  try {
    callSomeMethod();
  } catch (RuntimeException e) {
    handleException(e);
  }
}

You might end up with bytecode like the following (I’m showing it in the format the ASM Eclipse plugin does:  it’s an invaluable tool for learning how the Java compiler works, and I find it’s formatting pretty easy to read.  The “L0” and such are code labels.):

public simpleTryCatch()V
TRYCATCHBLOCK L0 L1 L2 java/lang/RuntimeException
L0
  ALOAD 0
  INVOKEVIRTUAL test/SimpleTryCatch.callSomeMethod()V
L1
  GOTO L3
L2
  ASTORE 1
  ALOAD 0
  ALOAD 1
  INVOKEVIRTUAL test/SimpleTryCatch.handleException(Ljava/lang/RuntimeException;)V
L3
  RETURN

So we’re saying the catch statement covers the full extent of the try block (though not the GOTO statement at the end), and that on a RuntimeException we should transfer control to L2.  If the try statement complete, it jumps over the catch statement and continues on.  When the RuntimeException handler is invoked, the exception is on the top of the stack, so we store it to a local variable slot.  We then load the “this” pointer and the exception argument in order to invoke the exception handler.  The catch block then falls through to the end; if there were additional catch blocks, it would jump over them.

So let’s add in a finally block and another catch statement and see what happens to the bytecode.  Suppose we have the following totally contrived method:

public void tryCatchFinally(boolean arg) {
  try {
    callSomeMethod();
    if (arg) {
      return;
    }
    callSomeMethod();
  } catch (RuntimeException e) {
    handleException(e);
  } catch (Exception e) {
    return;
  } finally {
    callFinallyMethod();
  }
}

In this case, we end up with this far-less-obvious bytecode:

public tryCatchFinally(Z)V
TRYCATCHBLOCK L0 L1 L2 java/lang/RuntimeException
TRYCATCHBLOCK L3 L4 L2 java/lang/RuntimeException
TRYCATCHBLOCK L0 L1 L5 java/lang/Exception
TRYCATCHBLOCK L3 L4 L5 java/lang/Exception
TRYCATCHBLOCK L0 L1 L6
TRYCATCHBLOCK L3 L7 L6
TRYCATCHBLOCK L5 L8 L6
L0
  ALOAD 0
  INVOKEVIRTUAL test/SimpleTryCatch.callSomeMethod()V
L9
  ILOAD 1
  IFEQ L3
L1
  ALOAD 0
  INVOKEVIRTUAL test/SimpleTryCatch.callFinallyMethod()V
L10
  RETURN
L3
  ALOAD 0
  INVOKEVIRTUAL test/SimpleTryCatch.callSomeMethod()V
L4
  GOTO L11
L2
  ASTORE 2
L12
  ALOAD 0
  ALOAD 2
  INVOKEVIRTUAL test/SimpleTryCatch.handleException(Ljava/lang/RuntimeException;)V
L7
  ALOAD 0
  INVOKEVIRTUAL test/SimpleTryCatch.callFinallyMethod()V
  GOTO L13
L5
  ASTORE 2
L8
  ALOAD 0
  INVOKEVIRTUAL test/SimpleTryCatch.callFinallyMethod()V
  RETURN
L6
  ASTORE 3
  ALOAD 0
  INVOKEVIRTUAL test/SimpleTryCatch.callFinallyMethod()V
  ALOAD 3
  ATHROW
L11
  ALOAD 0
  INVOKEVIRTUAL test/SimpleTryCatch.callFinallyMethod()V
L13
  RETURN

So what’s going on here?  (Note that the labels are numbered in the order they’re created by the compiler, not by the order they appear in the code). First of all, you’ll notice that both exception handler blocks are now split in two, from L0 to L1 and from L3 to L4.  That’s because the range from L1 to L3 is where the finally block is inlined due to the return statement.  Since exceptions thrown during the finally block shouldn’t be caught by catch blocks associated with the same try statement, that range has to be excluded from the exception table.  The exception entries with no type declared are from the finally block.  It has to handle any exception thrown from the try statement or from the catch blocks, but it also has to exclude any inlined finally statements so that the finally block doesn’t catch exceptions thrown by that same finally block.  It has to have three splits, because in addition to the inlined finally within the try block, the catch(Exception) block also contains a return statement.  You may also be surprised to see that the finally block appears a total of five times in the code.  You’ll see the first inlined finally from L1 to L3, corresponding to the return statement in the try block.  The second finally block is a bit more confusing:  in this case it’s being inlined into the end of the first catch block, which then jumps over the finally code that’s there in the fallthrough case.  (I personally would assume that it would jump down to the fallthrough case, rather than inlining the code again).  The third time it appears is from L8 to L6, around the early return statement within the second catch block.  The fourth time the code in the finally block appears is from L6 to L11, which corresponds to the exception case:  that’s to ensure the finally block is executed in the case of an unhandled exception thrown out of the try block or any of the catch blocks.  Notice that it stores the exception as normal, performs the call in the finally statement, and then loads and rethrows the exception.  The last finally block is for the fall-through case:  it’s where the end of the try block jumps to.

If we were to have nested try/catches or try/finallys, things would get even stranger.  A return from the inner try statement needs to have both the inner and outer finally inlined into it, and the exception table needs to be set up such that exceptions thrown by the inner finally are caught by the outer catch statements and the outer finally, and exceptions thrown by the outer finally aren’t caught by anything.  At this point you can probably start imagining the kind of state your compiler needs to carry around in order to know what to to inline where and how to partition the exception table correctly.

It’s interesting, for me at least, to see how the JVM designers chose to push the finally statement into the compiler rather than building it into the VM; clearly it can be built by the compiler, thus making the VM that much simpler, it just makes life a little rougher for folks like us who are building another language on the JVM.

Knowing how things are implemented by the compiler can actually make it a little easier to figure out what happens in certain odd circumstances.  For example:

try {
  return "foo";
} finally {
  return "bar";
}

will end up returning “bar” since the finally statement is inlined before the return statement, so the return from the finally block executes first and the original return statement never does.

String value = "foo";
try {
  return value;
} finally {
  value = "bar";
}

will return “foo” since the value to return is stored in the stack prior to the finally statement executing, and then restored and returned afterwards.  (My example didn’t show that, but that’s what you’d see if you were to look at the bytecode).  So the finally block changing the “value” variable has no affect on the in-progress return statement.  And lastly, something like:

while(true) {
  try {
    return "foo";
  } finally {
    break;
  }
}
return "bar";

will return “bar”.  This one surprised even me at first, but it makes sense once you realize that a break statement is just a GOTO in bytecode, so when the finally block is inlined as part of the inner return statement, that GOTO statement executes before the RETURN instruction and completely skips over it to the end of the loop (the same logic holds true for a continue statement inside a finally block).

On our end, we’ve decided to disallow return, break, and continue statements within the finally block due to the rather unexpected semantics (and C# disallows them as well, so I feel like we’re in good company with that decision).

If anyone actually found this enlightening, I’ll consider doing some future posts about other interesting issues we’ve run into when generating bytecode, both due to the JVM itself and due to the occassional impedance-mismatch between our language and Java around things like closures and enhancements and generics.

---