Java ByteCode Part 2

原文链接http://blog.jamesdbloom.com/JavaCodeToByteCode_PartTwo.html

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:

• Part 1 - Basic Programming Concepts
  • variables
    • local variables
    • fields (

      class

       variables)
    • constant fields (

      class

       constants)

    • static

       variables
  • conditionals

    • if

      -

      else

    • switch

  • loops

    • while

      -loop

    • for

      -loop

    • do

      -

      while

      -loop
• Part 2 - Object Orientation And Safety

  • try

    -catch-finally
  • synchronized
  • method invocation
  • new (objects and arrays)
• Part 3 - Metaprogramming (future article)
  • generics
  • annotations
  • reflection

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 operand5. 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:

• Start point
• End point
• PC offset for handler code
• Constant pool index for exception class being caught

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:

• the throw keyword which is compiled to the throw bytecode
• a Java method, during which an exception with no handler was thrown by the throw bytecode
• an internal VM-internal call, for example ClassNotFoundExceptionexception thrown during dynamic linking
• a JNI call to native code

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 catchblock 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 thefinally 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 catchblock for RuntimeException it forwards execution to a special version of thefinally 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

No thread has locked this object.

Biased:
 - Locked/Unlocked
 - Unshared

A single thread has locked this object and it is biased towards that thread. This is the most efficient type of locking because it avoids the need for any atomic CAS (Compare And Swap) operations.

Stack-Locked:
 - Locked
 - Shared
 - Uncontended

The mark word points to the stack on the thread that has locked the object. This state is less efficient because locking and unlocking requires the use of an atomic operation (call CAS - Compare And Swap) to update the ownership of the lock. Although this states is less efficient it supports the lock being shared between multiple threads.

Inflated:
 - Locked
 - Shared
 - contented

One thread has locked the object and one or more threads are queued waiting to gain the thread. The mark word points to a heavy-weight objectmonitor structure that contains information about the queued threads.

The JVM handles synchronised methods and synchronised blocks slightly differently. When a new method is executed the JVM checks if it has thesynchronised 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:

monitorenter

The thread that executes this instruction attempts to gain the monitor (i.e. lock) of the reference at the top of the operand stack.

• If the entry count is zero then the thread enters the monitor and increments the entry count.
• If the thread already owns the monitor it re-enters the monitor by incrementing the entry count.
• If another thread owns the monitor the thread blocks until the monitor's entry count is zero.

monitorexit

The thread that executes this instruction decrements the entry count of the reference at the top of the operand stack. If the entry count is zero after it has been decremented that the monitor (i.e. lock) is no longer owned by the thread. Any other threads waiting to own this monitor (due to a  monitorenterinstruction) are now unblocked and can attempt to take ownership.

synchronized blocks are implemented as a try-finally with themonitorenter 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.

invokevirtual

blar blar

invokespecial

blar blar

invokestatic

blar blar

invokeinterface

blar blar

invokedynamic

blar blar

invokehandle

blar blar

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