CHAPTER 7

Compiling for the Java Virtual Machine

The Java virtual machine is designed to support the Java programming language. Sun's JDK releases and Java 2 SDK contain both a compiler from source code written in the Java programming language to the instruction set of the Java virtual machine, and a runtime system that implements the Java virtual machine itself. Understanding how one compiler utilizes the Java virtual machine is useful to the prospective compiler writer, as well as to one trying to understand the Java virtual machine itself.

Although this chapter concentrates on compiling source code written in the Java programming language, the Java virtual machine does not assume that the instructions it executes were generated from such code. While there have been a number of efforts aimed at compiling other languages to the Java virtual machine, the current version of the Java virtual machine was not designed to support a wide range of languages. Some languages may be hosted fairly directly by the Java virtual machine. Other languages may be implemented only inefficiently.

Note that the term "compiler" is sometimes used when referring to a translator from the instruction set of a Java virtual machine to the instruction set of a specific CPU. One example of such a translator is a just-in-time (JIT) code generator, which generates platform-specific instructions only after Java virtual machine code has been loaded. This chapter does not address issues associated with code generation, only those associated with compiling source code written in the Java programming language to Java virtual machine instructions.

7.1 Format of Examples

The format of the examples should be familiar to anyone who has read assembly code. Each instruction takes the form

<index> <opcode> [<operand1> [<operand2>...]] [<comment>]

8 	bipush 100		// Push int constant 100

We preface an operand representing a runtime constant pool index with a hash sign and follow the instruction by a comment identifying the runtime constant pool item referenced, as in

  10   ldc #1 			// Push float constant 100.0	

   9   invokevirtual #4		// Method Example.addTwo(II)I

7.2 Use of Constants, Local Variables, and Control Constructs

The spin method simply spins around an empty for loop 100 times:

void spin() {
    int i;
    for (i = 0; i < 100; i++) {
     	;			// Loop body is empty
    }
}

Method void spin()
   0	iconst_0		// Push int constant 0
   1 	istore_1		// Store into local variable 1 (i=0)
   2	goto 8			// First time through don't increment
   5	iinc 1 1		// Increment local variable 1 by 1 (i++)
   8	iload_1			// Push local variable 1 (i)
   9	bipush 100		// Push int constant 100
  11	if_icmplt 5		// Compare and loop if less than (i < 100)
  14	return			// Return void when done

The instruction set of the Java virtual machine distinguishes operand types by using distinct bytecodes for operations on its various data types. The method spin operates only on values of type int. The instructions in its compiled code chosen to operate on typed data (iconst_0, istore_1, iinc, iload_1, if_icmplt) are all specialized for type int.

The two constants in spin, 0 and 100, are pushed onto the operand stack using two different instructions. The 0 is pushed using an iconst_0 instruction, one of the family of iconst_<i> instructions. The 100 is pushed using a bipush instruction, which fetches the value it pushes as an immediate operand.

The Java virtual machine frequently takes advantage of the likelihood of certain operands (int constants -1, 0, 1, 2, 3, 4 and 5 in the case of the iconst_<i> instructions) by making those operands implicit in the opcode. Because the iconst_0 instruction knows it is going to push an int 0, iconst_0 does not need to store an operand to tell it what value to push, nor does it need to fetch or decode an operand. Compiling the push of 0 as bipush 0 would have been correct, but would have made the compiled code for spin one byte longer. A simple virtual machine would have also spent additional time fetching and decoding the explicit operand each time around the loop. Use of implicit operands makes compiled code more compact and efficient.

The int i in spin is stored as Java virtual machine local variable 1. Because most Java virtual machine instructions operate on values popped from the operand stack rather than directly on local variables, instructions that transfer values between local variables and the operand stack are common in code compiled for the Java virtual machine. These operations also have special support in the instruction set. In spin, values are transferred to and from local variables using the istore_1 and iload_1 instructions, each of which implicitly operates on local variable 1. The istore_1 instruction pops an int from the operand stack and stores it in local variable 1. The iload_1 instruction pushes the value in local variable 1 onto the operand stack.

The use (and reuse) of local variables is the responsibility of the compiler writer. The specialized load and store instructions should encourage the compiler writer to reuse local variables as much as is feasible. The resulting code is faster, more compact, and uses less space in the frame.

Certain very frequent operations on local variables are catered to specially by the Java virtual machine. The iinc instruction increments the contents of a local variable by a one-byte signed value. The iinc instruction in spin increments the first local variable (its first operand) by 1 (its second operand). The iinc instruction is very handy when implementing looping constructs.

The for loop of spin is accomplished mainly by these instructions:

   5	iinc 1 1		// Increment local 1 by 1 (i++)
   8	iload_1			// Push local variable 1 (i)
   9	bipush 100		// Push int constant 100
  11	if_icmplt 5		// Compare and loop if less than (i < 100)

If the spin example had used a data type other than int for the loop counter, the compiled code would necessarily change to reflect the different data type. For instance, if instead of an int the spin example uses a double, as shown,

void dspin() {
    double i;
    for (i = 0.0; i < 100.0; i++) {
        ;			// Loop body is empty
    }
}

Method void dspin()
   0 	dconst_0		// Push double constant 0.0
   1 	dstore_1		// Store into local variables 1 and 2
   2 	goto 9			// First time through don't increment
   5 	dload_1			// Push local variables 1 and 2 
   6 	dconst_1		// Push double constant 1.0 
   7 	dadd			// Add; there is no dinc instruction
   8 	dstore_1		// Store result in local variables 1 and 2
   9 	dload_1			// Push local variables 1 and 2 
  10 	ldc2_w #4 		// Push double constant 100.0 
  13 	dcmpg			// There is no if_dcmplt instruction
  14 	iflt 5			// Compare and loop if less than (i < 100.0)
  17 	return			// Return void when done

Recall that double values occupy two local variables, although they are only accessed using the lesser index of the two local variables. This is also the case for values of type long. Again for example,

double doubleLocals(double d1, double d2) {
    return d1 + d2;
}

Method double doubleLocals(double,double)
   0 	dload_1			// First argument in local variables 1 and 2
   1 	dload_3			// Second argument in local variables 3 and 4
   2 	dadd			
   3 	dreturn

The Java virtual machine's opcode size of 1 byte results in its compiled code being very compact. However, 1-byte opcodes also mean that the Java virtual machine instruction set must stay small. As a compromise, the Java virtual machine does not provide equal support for all data types: it is not completely orthogonal (see Table 3.2, "Type support in the Java virtual machine instruction set").

For example, the comparison of values of type int in the for statement of example spin can be implemented using a single if_icmplt instruction; however, there is no single instruction in the Java virtual machine instruction set that performs a conditional branch on values of type double. Thus, dspin must implement its comparison of values of type double using a dcmpg instruction followed by an iflt instruction.

The Java virtual machine provides the most direct support for data of type int. This is partly in anticipation of efficient implementations of the Java virtual machine's operand stacks and local variable arrays. It is also motivated by the frequency of int data in typical programs. Other integral types have less direct support. There are no byte, char, or short versions of the store, load, or add instructions, for instance. Here is the spin example written using a short:

void sspin() {
    short i;
    for (i = 0; i < 100; i++) {
        ;			// Loop body is empty
    }
}

Method void sspin()
   0 	iconst_0
   1 	istore_1
   2 	goto 10
   5 	iload_1			// The short is treated as though an int
   6 	iconst_1
   7	iadd
   8 	i2s		 	// Truncate int to short
   9 	istore_1
  10 	iload_1
  11 	bipush 100
  13 	if_icmplt 5
  16 	return

The long and floating-point types have an intermediate level of support in the Java virtual machine, lacking only the full complement of conditional control transfer instructions.

7.3 Arithmetic

int align2grain(int i, int grain) {
    return ((i + grain-1) & ~(grain-1));
}

   5 	iload_2			// Push grain 
   6 	iconst_1		// Push int constant 1 
   7 	isub			// Subtract; push result 
   8 	iconst_m1		// Push int constant -1 
   9 	ixor			// Do XOR; push result 

The code for the entire method follows:

Method int align2grain(int,int)
   0 	iload_1
   1 	iload_2
   2 	iadd
   3 	iconst_1
   4 	isub
   5 	iload_2
   6 	iconst_1
   7 	isub
   8 	iconst_m1
   9 	ixor
  10	iand
  11	ireturn

7.4 Accessing the Runtime Constant Pool

The ldc and ldc_w instructions are used to access values in the runtime constant pool (including instances of class String) of types other than double and long. The ldc_w instruction is used in place of ldc only when there is a large number of runtime constant pool items and a larger index is needed to access an item. The ldc2_w instruction is used to access all values of types double and long; there is no non-wide variant.

Integral constants of types byte, char, or short, as well as small int values, may be compiled using the bipush, sipush, or iconst_<i> instructions, as seen earlier (§7.2). Certain small floating-point constants may be compiled using the fconst_<f> and dconst_<d> instructions.

In all of these cases, compilation is straightforward. For instance, the constants for

void useManyNumeric() {
    int i = 100;
    int j = 1000000;
    long l1 = 1;
    long l2 = 0xffffffff;
    double d = 2.2;
    ...do some calculations...
}

Method void useManyNumeric()
   0	bipush 100		// Push a small int with bipush
   2	istore_1
   3 	ldc #1 			// Push int constant 1000000; a larger int
				// value uses ldc
   5 	istore_2
   6 	lconst_1		// A tiny long value uses short, fast lconst_1
   7 	lstore_3
   8	ldc2_w #6 		// Push long 0xffffffff (that is, an int -1); any
				// long constant value can be pushed using ldc2_w
  11	lstore 5
  13 	ldc2_w #8 		// Push double constant 2.200000; uncommon
				// double values are also pushed using ldc2_w
  16 	dstore 7
...do those calculations...

7.5 More Control Examples

As a further example, a while loop is compiled in an obvious way, although the specific control transfer instructions made available by the Java virtual machine vary by data type. As usual, there is more support for data of type int, for example:

void whileInt() {
    int i = 0;
    while (i < 100) {
        i++;
    }
}

Method void whileInt()
   0 	iconst_0
   1 	istore_1
   2 	goto 8
   5 	iinc 1 1
   8 	iload_1
   9 	bipush 100
  11 	if_icmplt 5
  14 	return

Control constructs involving other data types are compiled in similar ways, but must use the instructions available for those data types. This leads to somewhat less efficient code because more Java virtual machine instructions are needed, for example:

void whileDouble() {
    double i = 0.0;
    while (i < 100.1) {
        i++;
    }
}

Method void whileDouble()
   0 	dconst_0
   1 	dstore_1
   2 	goto 9
   5 	dload_1
   6 	dconst_1
   7 	dadd
   8 	dstore_1
   9 	dload_1
  10 	ldc2_w #4 		// Push double constant 100.1
  13 	dcmpg			// To do the compare and branch we have to use...
  14 	iflt 5			// ...two instructions
  17 	return

For instance:

int lessThan100(double d) {
    if (d < 100.0) {
        return 1;				
    } else {
        return -1;				
    }
}

Method int lessThan100(double)
   0 	dload_1
   1 	ldc2_w #4 		// Push double constant 100.0
   4 	dcmpg			// Push 1 if d is NaN or d \> 100.0;
				// push 0 if d == 100.0
   5 	ifge 10			// Branch on 0 or 1
   8 	iconst_1
   9 	ireturn
  10 	iconst_m1
  11 	ireturn

The dcmpl instruction achieves the same effect if the comparison is reversed:

int greaterThan100(double d) {
    if (d > 100.0) {
        return 1;			
    } else {
        return -1;			
    }
}

Method int greaterThan100(double)
   0 	dload_1
   1 	ldc2_w #4 		// Push double constant 100.0
   4 	dcmpl			// Push -1 if d is Nan or d < 100.0;
				// push 0 if d == 100.0
   5 	ifle 10			// Branch on 0 or -1
   8 	iconst_1
   9 	ireturn
  10 	iconst_m1
  11 	ireturn

7.6 Receiving Arguments

int addTwo(int i, int j) {
    return i + j;
}

Method int addTwo(int,int)
   0	iload_1			// Push value of local variable 1 (i)
   1	iload_2			// Push value of local variable 2 (j)
   2	iadd			// Add; leave int result on operand stack
   3 	ireturn			// Return int result

Class (static) methods do not have an instance, so for them this use of local variable zero is unnecessary. A class method starts using local variables at index zero. If the addTwo method were a class method, its arguments would be passed in a similar way to the first version:

static int addTwoStatic(int i, int j) {
    return i + j;
}

Method int addTwoStatic(int,int)
   0 	iload_0
   1	iload_1
   2 	iadd
   3 	ireturn

7.7 Invoking Methods

int add12and13() {
    return addTwo(12, 13);
}

Method int add12and13()
   0 	aload_0			 	// Push local variable 0 (this)
   1 	bipush 12			// Push int constant 12
   3 	bipush 13			// Push int constant 13
   5 	invokevirtual #4		// Method Example.addtwo(II)I
   8	ireturn			 	// Return int on top of operand stack; it is
				 	// the int result of addTwo()

Finally, addTwo is invoked. When it returns, its int return value is pushed onto the operand stack of the frame of the invoker, the add12and13 method. The return value is thus put in place to be immediately returned to the invoker of add12and13.

The return from add12and13 is handled by the ireturn instruction of add12and13. The ireturn instruction takes the int value returned by addTwo, on the operand stack of the current frame, and pushes it onto the operand stack of the frame of the invoker. It then returns control to the invoker, making the invoker's frame current. The Java virtual machine provides distinct return instructions for many of its numeric and reference data types, as well as a return instruction for methods with no return value. The same set of return instructions is used for all varieties of method invocations.

The operand of the invokevirtual instruction (in the example, the runtime constant pool index #4) is not the offset of the method in the class instance. The compiler does not know the internal layout of a class instance. Instead, it generates symbolic references to the methods of an instance, which are stored in the runtime constant pool. Those runtime constant pool items are resolved at run time to determine the actual method location. The same is true for all other Java virtual machine instructions that access class instances.

Invoking addTwoStatic, a class (static) variant of addTwo, is similar, as shown:

int add12and13() {
    return addTwoStatic(12, 13);
}

Method int add12and13()
   0 	bipush 12
   2 	bipush 13
   4 	invokestatic #3 		// Method Example.addTwoStatic(II)I
   7 	ireturn

The invokespecial instruction must be used to invoke instance initialization methods (see Section 7.8, "Working with Class Instances"). It is also used when invoking methods in the superclass (super) and when invoking private methods. For instance, given classes Near and Far declared as

class Near {
    int it;
    public int getItNear() {
        return getIt();
    }
    private int getIt() {
        return it;
    }
}
class Far extends Near {
    int getItFar() {
        return super.getItNear();
    }
}

Method int getItNear()
   0 	aload_0
   1 	invokespecial #5 		// Method Near.getIt()I
   4 	ireturn

Method int getItFar()
   0 	aload_0
   1 	invokespecial #4		// Method Near.getItNear()I
   4	ireturn

7.8 Working with Class Instances

Object create() {
    return new Object();
}

Method java.lang.Object create()
   0 	new #1 				// Class java.lang.Object
   3 	dup
   4 	invokespecial #4 		// Method java.lang.Object.<init>()V
   7 	areturn

int i;					// An instance variable
MyObj example() {
    MyObj o = new MyObj();
    return silly(o);
}
MyObj silly(MyObj o) {
    if (o != null) {
        return o;
    } else {
        return o;
    }
}

Method MyObj example()
   0 	new #2 				// Class MyObj
   3 	dup
   4 	invokespecial #5 		// Method MyObj.<init>()V
   7 	astore_1
   8 	aload_0
   9 	aload_1
  10 	invokevirtual #4 				
		// Method Example.silly(LMyObj;)LMyObj;
  13 	areturn
Method MyObj silly(MyObj)
   0 	aload_1
   1 	ifnull 6
   4	aload_1
   5 	areturn
   6 	aload_1
   7 	areturn

void setIt(int value) {
    i = value;
}
int getIt() {
    return i;
}

Method void setIt(int)
   0 	aload_0
   1 	iload_1
   2 	putfield #4 			// Field Example.i I
   5	return
Method int getIt()
   0 	aload_0
   1 	getfield #4 			// Field Example.i I
   4	ireturn

7.9 Arrays

void createBuffer() {
    int buffer[];
    int bufsz = 100;
    int value = 12;
    buffer = new int[bufsz];
    buffer[10] = value;
    value = buffer[11];
}

Method void createBuffer()
   0 	bipush 100		// Push int constant 100 (bufsz)
   2 	istore_2		// Store bufsz in local variable 2
   3 	bipush 12		// Push int constant 12 (value)
   5 	istore_3		// Store value in local variable 3
   6	iload_2			// Push bufsz...
   7	newarray int		// ...and create new array of int of that length
   9 	astore_1		// Store new array in buffer
  10 	aload_1			// Push buffer
  11 	bipush 10		// Push int constant 10
  13 	iload_3			// Push value
  14 	iastore			// Store value at buffer[10]
  15 	aload_1			// Push buffer
  16 	bipush 11		// Push int constant 11
  18 	iaload			// Push value at buffer[11]...
   19 	istore_3		// ...and store it in value
  20	return

void createThreadArray() {
    Thread threads[];
    int count = 10;
    threads = new Thread[count];
    threads[0] = new Thread();
}

Method void createThreadArray()
   0 	bipush 10			// Push int constant 10
   2 	istore_2			// Initialize count to that
   3 	iload_2				// Push count, used by anewarray
   4 	anewarray class #1 		// Create new array of class Thread
   7 	astore_1			// Store new array in threads
   8 	aload_1				// Push value of threads
   9 	iconst_0			// Push int constant 0
  10 	new #1 				// Create instance of class Thread
  13 	dup				// Make duplicate reference...
  14 	invokespecial #5 		// ...to pass to instance initialization method
					// Method java.lang.Thread.<init>()V
  17 	aastore				// Store new Thread in array at 0
  18 	return

int[][][] create3DArray() {
    int grid[][][];
    grid = new int[10][5][];
    return grid;
}

Method int create3DArray()[][][]
   0 	bipush 10			// Push int 10 (dimension one)
   2 	iconst_5			// Push int 5 (dimension two)
   3 	multianewarray #1 dim #2 	// Class [[[I, a three
					// dimensional int array;
					// only create first two 
					// dimensions
   7 	astore_1			// Store new array...
   8 	aload_1				// ...then prepare to return it
   9 	areturn

All arrays have associated lengths, which are accessed via the arraylength instruction.

7.10 Compiling Switches

int chooseNear(int i) {
    switch (i) {
        case 0:  return 0;
        case 1:  return 1;
        case 2:  return 2;
        default: return -1;
    }
}

Method int chooseNear(int)
   0	iload_1				// Push local variable 1 (argument i)
   1 	tableswitch 0 to 2: 		// Valid indices are 0 through 2
		0: 28			// If i is 0, continue at 28
	 	1: 30			// If i is 1, continue at 30
	 	2: 32			// If i is 2, continue at 32
		default:34		// Otherwise, continue at 34
  28 	iconst_0			// i was 0; push int constant 0...
  29 	ireturn				// ...and return it
  30 	iconst_1			// i was 1; push int constant 1...
  31 	ireturn				// ...and return it
  32 	iconst_2			// i was 2; push int constant 2...
  33 	ireturn				// ...and return it
  34 	iconst_m1			// otherwise push int constant -1...
  35 	ireturn				// ...and return it

Where the cases of the switch are sparse, the table representation of the tableswitch instruction becomes inefficient in terms of space. The lookupswitch instruction may be used instead. The lookupswitch instruction pairs int keys (the values of the case labels) with target offsets in a table. When a lookupswitch instruction is executed, the value of the expression of the switch is compared against the keys in the table. If one of the keys matches the value of the expression, execution continues at the associated target offset. If no key matches, execution continues at the default target. For instance, the compiled code for

int chooseFar(int i) {
    switch (i) {
        case -100: return -1;
        case 0:	   return 0;
        case 100:  return 1;
        default:   return -1;
    }
}

Method int chooseFar(int)
   0 	iload_1
   1 	lookupswitch 3: 
	 	-100: 36
	 	0: 38
	 	100: 40
	 	default:42
  36 	iconst_m1
  37 	ireturn
  38 	iconst_0
  39 	ireturn
  40 	iconst_1
  41	ireturn
  42 	iconst_m1
  43 	ireturn

7.11 Operations on the Operand Stack

public long nextIndex() { 
    return index++;
}
private long index = 0;

Method long nextIndex()
   0 	aload_0			// Push this
   1 	dup			// Make a copy of it
   2 	getfield #4 		// One of the copies of this is consumed
				// pushing long field index,
				// above the original this
   5 	dup2_x1			// The long on top of the operand stack is 
				// inserted into the operand stack below the 
				// original this
   6 	lconst_1		// Push long constant 1 
   7 	ladd			// The index value is incremented...
   8 	putfield #4 		// ...and the result stored back in the field
  11 	lreturn			// The original value of index is left on
				// top of the operand stack, ready to be returned

7.12 Throwing and Handling Exceptions

void cantBeZero(int i) throws TestExc {
    if (i == 0) {
        throw new TestExc();
    }
}

Method void cantBeZero(int)
   0 	iload_1				// Push argument 1 (i)
   1	ifne 12				// If i==0, allocate instance and throw
   4	new #1 				// Create instance of TestExc
   7 	dup				// One reference goes to the constructor
   8 	invokespecial #7 		// Method TestExc.<init>()V
  11 	athrow				// Second reference is thrown
  12 	return				// Never get here if we threw TestExc

void catchOne() {
    try {
        tryItOut();
    } catch (TestExc e) {
        handleExc(e);
    }
}

Method void catchOne()
   0 	aload_0				// Beginning of try block
   1 	invokevirtual #6 		// Method Example.tryItOut()V
   4 	return				// End of try block; normal return
   5 	astore_1			// Store thrown value in local variable 1
   6 	aload_0				// Push this
   7 	aload_1				// Push thrown value
   8 	invokevirtual #5 		// Invoke handler method: 
					// Example.handleExc(LTestExc;)V
  11 	return				// Return after handling TestExc
Exception table:
   	From 	To 	Target 		Type
     	0     	4     	5 		Class TestExc

Method void catchOne()
   0	aload_0				// Beginning of try block
   1 	invokevirtual #4 		// Method Example.tryItOut()V
   4 	return				// End of try block; normal return

Following the try block is the Java virtual machine code that implements the single catch clause:

   5 	astore_1			// Store thrown value in local variable 1
   6 	aload_0				// Push this 
   7 	aload_1				// Push thrown value
   8 	invokevirtual #5 		// Invoke handler method: 
					// Example.handleExc(LTestExc;)V
  11 	return				// Return after handling TestExc
Exception table:
   	From 	To 	Target 		Type
     	0     	4     	5 		Class TestExc

A try may have multiple catch clauses:

void catchTwo() {
    try {
        tryItOut();
    } catch (TestExc1 e) {
        handleExc(e);
    } catch (TestExc2 e) {
        handleExc(e);
    }
}

Method void catchTwo()
   0 	aload_0				// Begin try block
   1 	invokevirtual #5 		// Method Example.tryItOut()V
   4 	return				// End of try block; normal return
   5 	astore_1			// Beginning of handler for TestExc1;
					// Store thrown value in local variable 1
   6 	aload_0				// Push this
   7 	aload_1				// Push thrown value
   8 	invokevirtual #7 		// Invoke handler method:
					// Example.handleExc(LTestExc1;)V
  11 	return				// Return after handling TestExc1
  12 	astore_1			// Beginning of handler for TestExc2;
					// Store thrown value in local variable 1
  13 	aload_0				// Push this
  14 	aload_1				// Push thrown value
  15 	invokevirtual #7		// Invoke handler method:
					// Example.handleExc(LTestExc2;)V
  18 	return				// Return after handling TestExc2
Exception table:
	From 	To 	Target 		Type
     	0     	4     	5   		Class TestExc1
     	0     	4    	12   		Class TestExc2

Nested try-catch statements are compiled very much like a try statement with multiple catch clauses:

void nestedCatch() {
    try {
        try {
            tryItOut();
        } catch (TestExc1 e) {
            handleExc1(e);
        }
    } catch (TestExc2 e) {
        handleExc2(e);
    }
}

Method void nestedCatch()
   0 	aload_0				// Begin try block
   1 	invokevirtual #8 		// Method Example.tryItOut()V
   4 	return				// End of try block; normal return
   5 	astore_1			// Beginning of handler for TestExc1;
					// Store thrown value in local variable 1
   6 	aload_0				// Push this
   7 	aload_1				// Push thrown value
   8 	invokevirtual #7 		// Invoke handler method: 
					// Example.handleExc1(LTestExc1;)V
  11 	return				// Return after handling TestExc1
  12 	astore_1			// Beginning of handler for TestExc2;
					// Store thrown value in local variable 1
  13 	aload_0				// Push this
  14 	aload_1				// Push thrown value
  15 	invokevirtual #6 		// Invoke handler method:
					// Example.handleExc2(LTestExc2;)V
  18 	return				// Return after handling TestExc2
Exception table:
   	From 	To 	Target 		Type
     	0     	4     	5 		Class TestExc1
     	0    	12    	12 		Class TestExc2

As a subtle point, note that the range of a catch clause is inclusive on the "from" end and exclusive on the "to" end (§4.7.3). Thus, the exception table entry for the catch clause catching TestExc1 does not cover the return instruction at offset 4. However, the exception table entry for the catch clause catching TestExc2 does cover the return instruction at offset 11. Return instructions within nested catch clauses are included in the range of instructions covered by nesting catch clauses.

7.13 Compiling finally

void tryFinally() {
    try {
        tryItOut();
    } finally {
        wrapItUp();
    }
}

Method void tryFinally()
   0 	aload_0				// Beginning of try block
   1	invokevirtual #6 		// Method Example.tryItOut()V
   4 	jsr 14				// Call finally block
   7 	return				// End of try block
   8 	astore_1			// Beginning of handler for any throw
   9 	jsr 14				// Call finally block
  12 	aload_1				// Push thrown value
  13 	athrow				// ...and rethrow the value to the invoker
  14 	astore_2			// Beginning of finally block
  15 	aload_0				// Push this
  16 	invokevirtual #5 		// Method Example.wrapItUp()V
  19 	ret 2				// Return from finally block
Exception table:
   	From 	To 	Target 		Type
	0    	4    	8   		any

In more detail, the subroutine call works as follows: The jsr instruction pushes the address of the following instruction (return at index 7) onto the operand stack before jumping. The astore_2 instruction that is the jump target stores the address on the operand stack into local variable 2. The code for the finally block (in this case the aload_0 and invokevirtual instructions) is run. Assuming execution of that code completes normally, the ret instruction retrieves the address from local variable 2 and resumes execution at that address. The return instruction is executed, and tryFinally returns normally.

A try statement with a finally clause is compiled to have a special exception handler, one that can handle any exception thrown within the try statement. If tryItOut throws an exception, the exception table for tryFinally is searched for an appropriate exception handler. The special handler is found, causing execution to continue at index 8. The astore_1 instruction at index 8 stores the thrown value into local variable 1. The following jsr instruction does a subroutine call to the code for the finally block. Assuming that code returns normally, the aload_1 instruction at index 12 pushes the thrown value back onto the operand stack, and the following athrow instruction rethrows the value.

Compiling a try statement with both a catch clause and a finally clause is more complex:

void tryCatchFinally() {
    try {
        tryItOut();
    } catch (TestExc e) {
        handleExc(e);
    } finally {
        wrapItUp();
    }
}

Method void tryCatchFinally()
   0 	aload_0				// Beginning of try block
   1 	invokevirtual #4 		// Method Example.tryItOut()V
   4 	goto 16				// Jump to finally block
   7 	astore_3			// Beginning of handler for TestExc;
					// Store thrown value in local variable 3
   8 	aload_0				// Push this
   9 	aload_3				// Push thrown value
  10 	invokevirtual #6 		// Invoke handler method:
					// Example.handleExc(LTestExc;)V
  13 	goto 16				// Huh???1
  16 	jsr 26				// Call finally block
  19 	return				// Return after handling TestExc
  20 	astore_1			// Beginning of handler for exceptions
					// other than TestExc, or exceptions
					// thrown while handling TestExc
  21 	jsr 26				// Call finally block
  24 	aload_1				// Push thrown value...
  25 	athrow				// ...and rethrow the value to the invoker
  26 	astore_2			// Beginning of finally block
  27 	aload_0				// Push this
  28 	invokevirtual #5 		// Method Example.wrapItUp()V
  31 	ret 2				// Return from finally block
Exception table:
   	From 	To 	Target 		Type
     	0     	4     	7 		Class TestExc
     	0   	16    	20   		any

If tryItOut throws an instance of TestExc, the first (innermost) applicable exception handler in the exception table is chosen to handle the exception. The code for that exception handler, beginning at index 7, passes the thrown value to handleExc and on its return makes the same subroutine call to the finally block at index 26 as in the normal case. If an exception is not thrown by handleExc, tryCatchFinally returns normally.

If tryItOut throws a value that is not an instance of TestExc or if handleExc itself throws an exception, the condition is handled by the second entry in the exception table, which handles any value thrown between indices 0 and 16. That exception handler transfers control to index 20, where the thrown value is first stored in local variable 1. The code for the finally block at index 26 is called as a subroutine. If it returns, the thrown value is retrieved from local variable 1 and rethrown using the athrow instruction. If a new value is thrown during execution of the finally clause, the finally clause aborts, and tryCatchFinally returns abruptly, throwing the new value to its invoker.

7.14 Synchronization

A synchronized method is not normally implemented using monitorenter and monitorexit. Rather, it is simply distinguished in the runtime constant pool by the ACC_SYNCHRONIZED flag, which is checked by the method invocation instructions. When invoking a method for which ACC_SYNCHRONIZED is set, the current thread acquires a monitor, invokes the method itself, and releases the monitor whether the method invocation completes normally or abruptly. During the time the executing thread owns the monitor, no other thread may acquire it. If an exception is thrown during invocation of the synchronized method and the synchronized method does not handle the exception, the monitor for the method is automatically released before the exception is rethrown out of the synchronized method.

The monitorenter and monitorexit instructions exist to support synchronized statements. For example:

void onlyMe(Foo f) {
    synchronized(f) {
        doSomething();
    }
}

Method void onlyMe(Foo)
   0 	aload_1				// Push f	
   1 	astore_2			// Store it in local variable 2
   2 	aload_2				// Push local variable 2 (f)
   3 	monitorenter			// Enter the monitor associated with f
   4 	aload_0				// Holding the monitor, pass this and...
   5 	invokevirtual #5 		// ...call Example.doSomething()V
   8	aload_2				// Push local variable 2 (f)
   9	monitorexit			// Exit the monitor associated with f
  10	return				// Return normally
  11 	aload_2				// In case of any throw, end up here
  12 	monitorexit			// Be sure to exit monitor...
  13 	athrow				// ...then rethrow the value to the invoker
Exception table:
   	From	To 	Target 		Type
     	4     	8    	11   		any

7.15 Compiling Nested Classes and Interfaces

A full treatment of the compilation of nested classes and interfaces is outside the scope of this chapter. However, interested readers can refer to the Inner Classes Specification at http://java.sun.com/products/jdk/1.1/docs/guide/innerclasses/spec/innerclasses.doc.html.

Contents | Prev | Next | Index

The Java^TM Virtual Machine Specification
Copyright © 1999 Sun Microsystems, Inc. All rights reserved
Please send any comments or corrections to [email protected]