Java Code To Byte Code - Part Two

Understanding how Java code is compiled into byte code and executed on a Java Virtual Machine (JVM) is critical because it helps you understand what is happening as your program executes. This understanding not only ensures that language features make logical sense but also that it is possible to understand the trade offs and side effects when making certain discussions.

This article explains how Java code is compiled into byte code and executed on the JVM. To understand the internal architecture in the JVM and different memory areas used during byte code execution see my previous article on JVM Internals.

This article is split into three parts, with each part being subdivided into sections. It is possible to read each section in isolation however the concepts will generally build up so it is easiest to read the sections. Each section will cover different Java code structures and explain how these are compiled and executed as byte code, as follows:

This article includes many code example and shows the corresponding typical byte code that is generated. The numbers that precede each instruction (or opcode) in the byte code indicates the byte position. For example an instruction such a 1: iconst_1 is only one byte in length, as there is no operand, so the following byte code would be at 2. An instruction such as 1: bipush 5 would take two bytes, one byte for the opcode bipush and one byte for the operand 5. In this case the following byte code would be at 3 as the operand occupied the byte at position 2.

try-catch-finally

When a try-catch, try-finally or try-catch-finally exception handler is compiled an exception table is added into the class file. The exception table stores per-exception handler information such as:

This contains information for each exception handler or finally block including the range over which the handler applies, what type of exception is being handled and where the handler code is.

Exceptions can be initiated by:

When an exception is thrown the JVM looks for a matching handler in the current method, if none is found the method ends abruptly popping the current stack frame and the exception is re-thrown in the calling method (the new current frame). If no exception handler is found before all frames have been popped then the thread is terminated. This can also cause the JVM itself to terminate if the exception is thrown in the last non-daemon thread, for example if the thread is the main thread.

Finally exception handlers match all types of exceptions and so always execute whenever an exception is thrown. In the case when no exception is thrown a finally block is still executed at the end of a method, this is achieved by adding the finally handler byte codes at the end of the byte code for the try block.

The following code:

public void tryCatchCatchFinally(int i) {
    try {
        i = 2;
    } catch (RuntimeException e) {
        i = 3;
    } finally {
        i = 4;
    }
}

Therefore gets compiled to:

// try block
 0: iconst_2            // load 2 onto operand stack
 1: istore_1            // store top operand to local variable 1
// finally block - no exception
 2: iconst_4            // load 4 onto operand stack
 3: istore_1            // store top operand to local variable 1
 4: goto          20    // jump to return
// catch block
 7: astore_2            // store exception to local variable 2
 8: iconst_3            // load 3 onto operand stack
 9: istore_1            // store top operand to local variable 1
// finally block - after catch block
10: iconst_4            // load 4 onto operand stack
11: istore_1            // store top operand to local variable 1
12: goto          20    // jump to return
// finally block - after exception not caught in catch block
15: astore_3            // store exception to local variable 3
16: iconst_4            // load 4 onto operand stack
17: istore_1            // store top operand to local variable 1
18: aload_3             // load local variable 3 (i.e. exception) onto operand stack
19: athrow              // throw top operand (i.e. propagate up the stack)
20: return              // return

Exception table:
   from   to   target  type
   // jump to catch block for RuntimeException
   0      2    7       Class java/lang/RuntimeException
   // jump to finally block if any exception (other than RuntimeException)
   0      2    15      any
   // jump to finally block if exception in catch block
   7      10   15      any

The example above has three entries in the exception table, as follows:

   from   to   target  type
   0      2    7       Class java/lang/RuntimeException

The from column is inclusive and the to column is exclusive so this entry describes the exception handler for RuntimeExceptions thrown by byte codes 0 and 1. The entry covers the try block and forwards execution to the catch block if there is a RuntimeException. As this is the first entry in the exception table the JVM exception handling logic will always attempt to match this first before any other handler.

   from   to   target  type
   0      2    15      any

This entry describes the exception handler for all exceptions thrown by byte codes 0 and 1. This handler is used if there is an exception that has not already been caught by the earlier exception handler for RuntimeException. This entry covers the try block and forwards execution to a special version of the finally block that executes the code in the finally block then re-throws the exception causing the stack frame to be popped allowing exception handlers higher the stack frame to handle this exception.

   from   to   target  type
   7      10    15     any

This entry describes the exception handler for all exceptions thrown by byte codes 7, 8 and 9. This entry covers any exceptions thrown during the catch block for RuntimeException it forwards execution to a special version of the finally block that executes the code in the finally block then re-throws the exception causing the stack frame to be popped allowing exception handlers higher the stack frame to handle this exception.

TODO - Add diagram for try-catch-finally

synchronized

Objects in Hotspot JVM are represented by an Ordinary Object Pointer (OOP). An OOP contains two important fields called the mark word and the klass pointer, these are referred to as the two word object header. The mark word contains information such as the identity hash value (is assigned), garbage collection age, and synchronization information such as the object's lock (i.e. monitor). The klass pointer points to an object shared by all instances of the same type that contains information about static fields and a vtable used to support method invocation.

When a thread enters a synchronised block or method, for an object, it attempts to gain ownership of the lock for that object. Since most objects are locked by at most by one thread during it's lifetime, a thread can bias an object's lock towards itself. If the thread gains ownership of the lock the mark field of the OOP is updated and biased toward that thread.

Biased locking makes it much faster for the same thread to reacquire an object's lock. A biased lock is faster because once an object lock is biased towards a thread, that thread can lock and unlock the object without resorting to expensive Compare And Swap (CAS) atomic instructions. CAS is expensive because lock instructions are atomic with respect to all other memory operations and externally visible events on a CPU. This means that lock instructions on pipelined or superscalar CPUs (all modern CPUs) have to wait for all other outstanding instructions to complete their load and store severely affecting instruction parallelism.

If another thread tries to lock the object the bias is reverted. The lock is now either rebaised or simply reverts to normal stack-locking for the remainder of the object's lifetime.

Another way to view biased locking is that the original owner simply delays unlocking the object until it encounters contention.

The mark word can contain the following different states to support synchronisation:

Neutral:
 - Unlocked

Biased:
 - Locked/Unlocked
 - Unshared

Stack-Locked:
 - Locked
 - Shared
 - Uncontended

Inflated:
 - Locked
 - Shared
 - contented

The JVM handles synchronised methods and synchronised blocks slightly differently. When a new method is executed the JVM checks if it has the synchronised keyword if it does then an attempt is made to acquire the appropriate object's lock. synchronised blocks instead use two special byte codes, as follows:

synchronized blocks are implemented as a try-finally with the monitorenter in the try block and the monitorexit in the finally block. This can be seen in the following code example:

public void synchronizedBlock(int i) {
    synchronized (this) {
        i = 1;
    }
}

This results in the following byte code:

// try block
 0: aload_0            // load this onto operand stack
 1: dup                // duplicate top item on operand stack
 2: astore_2           // store top operand as local variable 2
 3: monitorenter       // enter monitor for top operand
 4: iconst_1           // load 1 to top of operand stack
 5: istore_1           // store top operand as local variable 1
// finally block - no exception
 6: aload_2            // load local variable 2 onto operand stack
 7: monitorexit        // exit monitor for top operand
 8: goto          16   // jump to return
// finally block - after exception
11: astore_3           // store exception as local variable 3
12: aload_2            // load local variable 2 onto operand stack
13: monitorexit        // exit monitor for top operand
14: aload_3            // load local variable 3 (i.e. exception) onto operand stack
15: athrow             // throw top operand (i.e. propagate up the stack)
16: return             // return

The Object methods wait(), notify() and notifyAll() used for signaling and control flow control in a synchronised block do not have any special byte codes. Instead these are implemented directly in the JVM as native methods.

TODO - Add diagram for synchronised

method invocation

There are five types of method invocation in the JVM.

TODO - This article is a work in progress and has not yet been published!!

For more detail on the internal architecture in the JVM and different memory areas used during byte code execution see my previous article on JVM Internals