appa Instruction Set by Opcode Mnemonic | Inside the Java 2 Virtual Machine



1997 The McGraw-Hill Companies, Inc. All rights reserved. Any use of this Beta Book is subject to the rules stated in the Terms of Use.

Instruction Set by Opcode Mnemonic

Appendix A lists Java Virtual Machine instructions in alphabetical order by opcode mnemonic. All 201 instructions that may legally appear in the bytecode streams stored in Java class files are described in detail in Appendix A.

Besides the opcodes for the 201 instructions that may appear in class files, the Java Virtual Machine specification describes two other families of opcodes: the reserved opcodes and the " _quick " opcodes. None of these opcodes can legally appear in the bytecode streams of Java class files.

The Java Virtual Machine specification lists three reserved opcodes, which are shown in Table A-1. These opcodes are reserved for internal use by Java Virtual Machine implementations and tools. The specification guarantees that these three opcodes will not be part of any future extension of the Java Virtual Machine s instruction set. As you may have guessed, the intended purpose of the breakpoint opcode is to provide a way for debuggers to implement breakpoints. The intended purpose of the other two reserved opcodes, impdep1 and impdep2 , is to serve as "back doors" to implementation-dependent software functionality or "traps" to implementation-dependent hardware functionality.

Table A-1. The reserved opcodes

mnemonic	byte value
breakpoint	202 (0xca)
impdep1	254 (0xfe)
impdep2	255 (0xff)

The Java Virtual Machine specification also lists 25 " _quick " opcodes, which Sun s virtual machine implementation uses internally to speed up the interpreted execution of bytecodes. This optimization technique is described in general in this book in Chapter 8, "The Linking Model," but the individual " _quick " instructions are not described in detail in Appendix A. (The " _quick " opcodes do appear in Appendix C, which lists their mnemonics and corresponding opcode byte values.) Like the reserved opcodes, the " _quick " opcodes may not legally appear in Java class files. But unlike the reserved opcodes, the Java Virtual Machine specification leaves open the possibility that these opcodes will take on new meanings in future extensions of the instruction set.

For each instruction listed in Appendix A, you will find the following information:

the mnemonic
a short description
the opcode s byte value in decimal and hex
the format of the instruction
the operand stack before and after the instruction is executed
a description of any constraints associated with the instruction
a description of the execution of the instruction
a description of any exceptions or errors that may be thrown by the instruction

The format of each instruction appears as a list of comma-separated items next to the label "Instruction Format," with each item representing one byte in the bytecode stream. The opcode mnemonic appears first (in fixed-width font), followed by any operands (shown in italics).

For each instruction, Appendix A shows two snapshots of the operand stack. One snapshot, labelled "Before," shows the contents of the current method s operand stack just before the instruction is executed. The other snapshot, labelled "After," shows the operand stack immediately after execution of the instruction. In both snapshots, the operand stack appears as a list of comma-separated items, with each item representing one word. Although everywhere else in this book the operand stack is shown growing downwards (the top of the stack appears at the bottom of the picture), in Appendix A the operand stack is shown growing sideways , from left to right. In each snapshot, the top of the stack is the rightmost item shown. Unaffected portions of the operand stack are shown as an elipsis, "...".

For each instruction, the section labelled "Description" combines three kinds of information: constraints, the process of execution, and exceptions and errors. As mentioned in Chapter 3, "Security," Java Virtual Machine implementations are required to enforce at run-time certain constraints on the bytecodes of every method they execute. Whenever you see the word "must" in an instruction s description in Appendix A, you are reading about a constraint every implementation must enforce when executing the instruction. For example, the goto instruction, which causes an unconditional jump, may only cause a jump to another opcode of the same method. In Appendix A s description for goto , this constraint is stated as, "The target address must be the address of an opcode within the same method as the goto opcode."

The designers of each individual Java Virtual Machine implementation can decide how and when to detect violations of the bytecode constraints. If any implementation detects a constraint violation, it must report the violation by throwing a VerifyError when (and if) the running program attempts to execute the instruction.

In addition to describing the constraints placed on each instruction, Appendix A describes the process of executing each instruction and lists any errors or exceptions that may be thrown during the course of executing the instruction. Besides the errors and exceptions explicitly listed in the instruction descriptions, one other family of errors, subclasses of VirtualMachineError , can be thrown at any time as the result of executing any instruction. Four subclasses of VirtualMachineError , and the circumstances under which they will be thrown, are:

OutOfMemoryError - the virtual machine has run out of real or virtual memory, and the garbage collector can t reclaim enough space to enable the thread to continue.
StackOverflowError - a thread has exhausted its supply of memory for stack space (usually because the application has an unbounded recursion).
InternalError - the virtual machine has encountered a bug in its own implementation that prevents it from properly implementing the semantics of the Java language.
UnknownError - the virtual machine has encountered some error condition, but is unable to report the actual condition by throwing the appropriate exception or error.

- Load reference from local variable

Opcode:

25 (0x19)

Instruction Format:

aload , index

Stack:

Before:...

After: ..., value

Description:

Description:

The top word of the operand stack, count , must be an int . To execute the anewarray instruction, the Java Virtual Machine first forms an unsigned 16-bit index into the constant pool by calculating (indexbyte1 8) | indexbyte2 . The virtual machine then looks up the constant pool entry specified by the calculated index. The constant pool entry at that index must be a CONSTANT_Class_info entry. If it hasn t already, the virtual machine resolves the entry. The entry may be a class, interface, or array type.

If the resolution is successful, the Java Virtual Machine pops count and creates on the heap an array of size count of the reference type specified by the resolved CONSTANT_Class_info entry. The virtual machine initializes each array element to its default initial value ( null ) and pushes arrayref , a reference to the new array, onto the operand stack.

As a result of executing this instruction, the Java Virtual Machine may throw any of the linking errors listed in Chapter 8, "The Linking Model," as possible during resolution of a CONSTANT_Class_info entry. If resolution succeeds, but count is less than zero, the virtual machine throws NegativeArraySizeException .

For more information about the anewarray instruction, see Chapter 15, "Objects and Arrays."

areturn

- Return reference from method

Opcode:

176 (0xb0)

Instruction Format:

areturn

Stack:

Before: ..., objectref

After: [empty]

Description:

The return type of the returning method must be reference . The top word of the operand stack, objectref , must be a reference that is assignment compatible with the type represented by the returning method s descriptor. To execute the areturn instruction, the Java Virtual Machine pops objectref from the operand stack of the current frame and pushes it onto the operand stack of the invoking method s frame. The virtual machine discards any other words that may still be on the returning method s frame. If the returning method is synchronized, the monitor that was acquired when the method was invoked is released. The invoking method s frame is made current, and the virtual machine continues execution in the invoking method.

For more information about monitors , see Chapter 20, "Thread Synchronization." For more information about the areturn instruction, see Chapter 19, "Method Invocation and Return."

arraylength

- Get length of array

Opcode:

190 (0xbe)

Instruction Format:

arraylength

Stack:

Before: ..., arrayref

After: ..., length

Description:

The top word of the operand stack, arrayref , must be a reference that points to an array. To execute the arraylength instruction, the Java Virtual Machine pops arrayref and pushes the length of the array pointed to by arrayref .

If arrayref is null , the Java Virtual Machine throws NullPointerException .

For more information about the arraylength instruction, see Chapter 15, "Objects and Arrays."

astore

- Store reference or returnAddress into local variable

Opcode:

58 (0x3a)

Instruction Format:

astore , index

Stack:

Before:..., value

After: ...

Description:

Note that "Before" shows the operand stack of the frame belonging to the method containing the athrow instruction being executed. "After" shows the operand stack of the frame belonging to the method in which the catch clause is found, if a catch clause is found. If no catch clause is found, the thread exits and there are no more operand stacks for that thread.

Description:

Description:

After: ..., result

Description:

The top two words of the operand stack must be a double . To execute the dneg instruction, the Java Virtual Machine pops value , negates it, and pushes the double result . The result produced by the dneg instruction is governed by the rules of IEEE 754 floating point arithmetic.

Note that the result produced by a dneg instruction is not always the same as the number that would be produced by subtracting value from zero with the dsub instruction. The range of IEEE 754 floating point numbers includes two zeros, a positive zero and a negative zero. When value is +0.0, the result of the dneg instruction is -0.0. By contrast, when subtracting +0.0 from +0.0, the dsub instruction yields +0.0.

For more information about the dneg instruction, see Chapter 14, "Floating Point Arithmetic."

drem

- Calculate remainder of division of double s

Opcode:

115 (0x73)

Instruction Format:

drem

Stack:

Before: ..., value1.word1, value1.word2, value2.word1, value2.word2

After: ..., result.word1, result.word2

Description:

The top four words of the operand stack must be two double s, value1 and value2 . To execute the drem instruction, the Java Virtual Machine pops value1 and value2 , calculates the remainder, and pushes the double result . The remainder equals value1 - (value1 / value2) * value2 , where value1 / value2 is a truncating division, rather than the rounding division required by IEEE 754.

The behavior of drem is comparable to that of the C library function fmod() .The remainder of two double s can be calculated according to IEEE 754 floating point standard via the IEEERemainder() method of class java.lang.Math .

For more information about the drem instruction, see Chapter 14, "Floating Point Arithmetic."

dreturn

- Return double from method

Opcode:

175 (0xaf)

Instruction Format:

dreturn

Stack:

Before: ..., value.word1, value.word2

After: [empty]

Description:

The return type of the returning method must be double . The top two words of the operand stack must be a double . To execute the dreturn instruction, the Java Virtual Machine pops double value from the operand stack of the current frame and pushes it onto the operand stack of the invoking method s frame. The virtual machine discards any other words that may still be on the returning method s frame. If the returning method is synchronized, the monitor that was acquired when the method was invoked is released. The invoking method s frame is made current, and the virtual machine continues execution in the invoking method.

For more information about monitors, see Chapter 20, "Thread Synchronization." For more information about the dreturn instruction, see Chapter 19, "Method Invocation and Return."

dstore

- Store double into local variable

Opcode:

57 (0x39)

Instruction Format:

dstore , index

Stack:

Before:..., value.word1, value.word2

After: ...

Description:

Description:

The top word of the operand stack, value , must be a float . To execute the f2d instruction, the Java Virtual Machine pops float value from the operand stack, converts the float to a double , and pushes the double result .

Note that this instruction performs a widening primitive conversion. Because all float values are representable by a double , the conversion is exact.

For more information about the f2d instruction, see Chapter 11, "Type Conversion."

f2i

- Convert float to int

Opcode:

139 (0x8b)

Instruction Format:

f2i

Stack:

Before: ..., value

After: ..., result

Description:

The top word of the operand stack, value , must be a float . To execute the f2i instruction, the Java Virtual Machine pops the float value from the operand stack, converts the float to an int , and pushes the int result .

To convert the float value to int , the Java Virtual Machine first checks to see if the value equals NaN (Not a Number). If so, the int result is zero. Else, if the float value is not a positive or negative infinity, the virtual machine rounds the value towards zero using IEEE 754 round-towards-zero mode. If the resulting integral value can be exactly represented by an int , the int result is that integral value. Otherwise, the magnitude of the float value is too great be represented in an int . If value is positive, the int result is the largest positive integer representable in an int . If value is negative, the int result is the smallest negative integer representable in an int .

Note that this instruction performs a narrowing primitive conversion. Because not all float values are representable by an int , the conversion may result in a loss of magnitude and precision.

For more information about the f2i instruction, see Chapter 11, "Type Conversion."

f2l

- Convert float to long

Opcode:

140 (0x8c)

Instruction Format:

f2l

Stack:

Before: ..., value

After: ..., result.word1, result.word2

Description:

After: ..., value

Description:

Description:

The top word of the operand stack, value , must be a float . To execute the fneg instruction, the Java Virtual Machine pops value , negates it, and pushes the float result . The result produced by the fneg instruction is governed by the rules of IEEE 754 floating point arithmetic.

Note that the result produced by an fneg instruction is not always the same as the number that would be produced by subtracting value from zero with the fsub instruction. The range of IEEE 754 floating point numbers includes two zeros, a positive zero and a negative zero. When value is +0.0, the result of the fneg instruction is -0.0. By contrast, when subtracting +0.0 from +0.0, the fsub instruction yields +0.0.

For more information about the fneg instruction, see Chapter 14, "Floating Point Arithmetic."

frem

- Calculate remainder of division of float s

Opcode:

114 (0x72)

Instruction Format:

frem

Stack:

Before: ..., value1, value2

After: ..., result

Description:

The top two words of the operand stack, value1 and value2 , must be float s. To execute the frem instruction, the Java Virtual Machine pops value1 and value2 , calculates the remainder, and pushes the float result . The remainder equals value1 - (value1 / value2) * value2 , where value1 / value2 is a truncating division, rather than the rounding division required by IEEE 754.

The behavior of frem is comparable to that of the C library function fmod() .The remainder of two float s can be calculated according to IEEE 754 floating point standard via the IEEERemainder() method of class java.lang.Math .

For more information about the frem instruction, see Chapter 14, "Floating Point Arithmetic."

freturn

- Return float from method

Opcode:

174 (0xae)

Instruction Format:

freturn

Stack:

Before: ..., value

After: [empty]

Description:

The return type of the returning method must be float . The top word of the operand stack, value , must be a float . To execute the freturn instruction, the Java Virtual Machine pops float value from the operand stack of the current frame and pushes it onto the operand stack of the invoking method s frame. The virtual machine discards any other words that may still be on the returning method s frame. If the returning method is synchronized, the monitor that was acquired when the method was invoked is released. The invoking method s frame is made current, and the virtual machine continues execution in the invoking method.

For more information about monitors, see Chapter 20, "Thread Synchronization." For more information about the freturn instruction, see Chapter 19, "Method Invocation and Return."

fstore

- Store float into local variable

Opcode:

56 (0x38)

Instruction Format:

fstore , index

Stack:

Before:..., value

After: ...

Description:

Before: ..., objectref

After: ..., value.word1, value.word2

Description:

The top word of the stack, objectref , must be a reference . To execute the getfield instruction, the Java Virtual Machine first forms an unsigned 16-bit index into the constant pool by calculating (indexbyte1 8) | indexbyte2 .

The virtual machine then looks up the constant pool entry specified by the calculated index. The constant pool entry at that index must be a CONSTANT_Fieldref_info entry. If it hasn t already, the virtual machine resolves the entry, which yields the field s width and the field s offset from the beginning of the object image. If the resolution is successful, the virtual machine pops the objectref and fetches the field from the object pointed to by objectref . If the type of the field is byte , short , or char , the virtual machine sign-extends the field s value to an int and pushes the single-word int value onto the operand stack. Else, if the type is int , boolean , float , or reference , the virtual machine pushes the single-word value onto the operand stack. Otherwise, the type is long or double , and the virtual machine pushes the dual-word value onto the operand stack.

As a result of executing this instruction, the virtual machine may throw any of the linking errors listed in Chapter 8, "The Linking Model," as possible during resolution of a CONSTANT_Fieldref_info entry. As part of the process of resolving the CONSTANT_Fieldref_info entry, the virtual machine checks whether the field s access permission enables the current class to access the field. If the field is protected, the virtual machine makes certain the field is a member of the either the current class or a superclass of the current class, and that the class of the object pointed to by objectref is either the current class or a subclass of the current class. If not (or if there is any other access permission problem), the virtual machine throws IllegalAccessError . Else, if the field exists and is accessible from the current class, but the field is static, the virtual machine throws IncompatibleClassChangeError . Otherwise, if objectref is null , the virtual machine throws NullPointerException .

For more information about the getfield instruction, see Chapter 15, "Objects and Arrays."

getstatic

- Fetch static field from class

Opcode:

178 (0xb2)

Instruction Format:

getstatic , indexbyte1 , indexbyte2

Stack:

Before:...

After: ..., value

Before: ...

After: ..., value.word1, value.word2

Description:

To execute the getstatic instruction, the Java Virtual Machine first forms an unsigned 16-bit index into the constant pool by calculating (indexbyte1 8) | indexbyte2 .

The virtual machine then looks up the constant pool entry specified by the calculated index. The constant pool entry at that index must be a CONSTANT_Fieldref_info entry. If it hasn t already, the virtual machine resolves the entry. If the resolution is successful, the virtual machine fetches the value of the static field. If the type of the field is byte , short , or char , the virtual machine sign-extends the field s value to int and pushes the single-word int value onto the operand stack. Else, if the type is int , boolean , float , or reference the virtual machine pushes the single-word value onto the operand stack. Otherwise, the type is long or double , and the virtual machine pushes the dual-word value onto the operand stack.

As a result of executing this instruction, the virtual machine may throw any of the linking errors listed in Chapter 8, "The Linking Model," as possible during resolution of a CONSTANT_Fieldref_info entry. As part of the process of resolving the CONSTANT_Fieldref_info entry, the virtual machine checks whether the field s access permission enables the current class to access the field. If the field is protected, the virtual machine makes certain the field is a member of the either the current class or a superclass of the current class. If not (or if there is any other access permission problem), the virtual machine throws IllegalAccessError . Else, if the field exists and is accessible from the current class, but the field is not static, the virtual machine throws IncompatibleClassChangeError .

For more information about the getstatic instruction, see Chapter 15, "Objects and Arrays."

goto

- Branch always

Opcode:

167 (0xa7)

Instruction Format:

goto , branchbyte1 , branchbyte2

Stack:

No change

Description:

To execute the goto instruction, the Java Virtual Machine forms a signed 16-bit offset by calculating (branchbyte1 8) | branchbyte2 .

The virtual machine then calculates a target (program counter) address by adding the calculated offset to the address of the goto opcode. The target address must be the address of an opcode within the same method as the goto opcode. The virtual machine jumps to the target address and continues execution there.

For more information about the goto instruction, see Chapter 16, "Control Flow."

goto_w

- Branch always (wide index)

Opcode:

200 (0xc8)

Instruction Format:

goto_w = 200 , branchbyte1 , branchbyte2 , branchbyte3 , branchbyte4

Before: ..., value1, value2

After: ..., result

Description:

The top two words of the operand stack, value1 and value2 , must be int s. To execute the iadd instruction, the Java Virtual Machine pops value1 and value2 , adds them, and pushes the int result . If overflow occurs, result is the 32 lowest order bits of the true mathematical result represented in a sufficiently wide two s-complement format, and the sign of result is different from that of the true mathematical result.

For more information about the iadd instruction, see Chapter 12, "Integer Arithmetic."

iaload

- Load int from array

Opcode:

46 (0x2e)

Instruction Format:

iaload

Stack:

Before: ..., arrayref, index

After: ..., value

Description:

To execute the iaload instruction, the Java Virtual Machine first pops two words from the operand stack. The arrayref word must be a reference that refers to an array of int s. The index word must be an int .

The virtual machine retrieves from the arrayref array the int value specified by index and pushes it onto the operand stack.

If arrayref is null , the Java Virtual Machine throws NullPointerException . Otherwise, if index is not a legal index into the arrayref array,

The virtual machine throws ArrayIndexOutOfBoundsException .

For more information about the iaload instruction, see Chapter 15, "Objects and Arrays."

iand

- Perform boolean AND on int s

Opcode:

126 (0x7e)

Instruction Format:

iand

Stack:

Before: ..., value1, value2

After: ..., result

Description:

The top two words of the operand stack, value1 and value2 , must be int s. To execute the iand instruction, the Java Virtual Machine pops value1 and value2 , bitwise ANDs them, and pushes the int result .

For more information about the iand instruction, see Chapter 13, "Logic."

iastore

- Store into int array

Opcode:

79 (0x4f)

Instruction Format:

iastore

Stack:

Before: ..., arrayref, index, value

idiv

Stack:

Before: ..., value1, value2

After: ..., result

Description:

Description:

The top two words of the operand stack, value1 and value2 , must be int s. To execute the if_icmpne instruction, the Java Virtual Machine pops value1 and value2 off the operand stack and compares one against the other. If value1 does not equal value2 ,

The virtual machine forms a signed 16-bit offset by calculating (branchbyte1 8) | branchbyte2 . The virtual machine then calculates a target (program counter) address by adding the calculated offset to the address of the if_icmpne opcode. The target address must be the address of an opcode within the same method as the if_icmpne opcode. The virtual machine jumps to the target address and continues execution there. Otherwise, if value1 equals value2 , The virtual machine does not take the jump. It simply continues execution at the instruction immediately following the if_icmpne instruction.

For more information about the if_icmpne instruction, see Chapter 16, "Control Flow."

iinc

- Increment int local variable by constant

Opcode:

132 (0x84)

Instruction Format:

iinc , index , const

Stack:

No change

Description:

The index operand must specify a valid 8-bit unsigned index into the local variables of the current frame. To execute the iinc instruction, the Java Virtual Machine adds the 8-bit signed increment const to the local variable word specified by index.

Note that the wide instruction can precede the iinc instruction, to enable a local variable specified by a 16-bit unsigned offset to be incremented by a signed 16-bit constant.

For more information about the iinc instruction, see Chapter 12, "Integer Arithmetic."

iload

- Load int from local variable

Opcode:

21 (0x15)

Instruction Format:

iload , index

Stack:

Before:...

After: ..., value

Description:

Description:

The top word of the operand stack, value , must be an int . To execute the ineg instruction, the Java Virtual Machine pops value , negates it, and pushes the int result .

The result produced by an ineg instruction is the same number that would be produced by subtracting value from zero with the isub instruction. As a consequence, when value is the smallest negative integer that can be represented by an int , the negation overflows. For this negation, the true mathematical result is one greater than the largest positive integer that can be represented by an int , and the actual result is equal to value with no change in sign.

For more information about the ineg instruction, see Chapter 12, "Integer Arithmetic."

instanceof

- Determine if an object is of given type

Opcode:

193 (0xc1)

Instruction Format:

instanceof , indexbyte1 , indexbyte2

Stack:

Before:..., objectref

After: ..., result

Description:

The top word of the stack, objectref , must be a reference . To execute the instanceof instruction, the Java Virtual Machine first forms an unsigned 16-bit index into the constant pool by calculating (indexbyte1 8) | indexbyte2 .

The virtual machine then looks up the constant pool entry specified by the calculated index. The constant pool entry at that index must be a CONSTANT_Class_info entry. If it hasn t already, The virtual machine resolves the entry. The entry may be a class, interface, or array type. If objectref is not null and the object pointed to by objectref is an "instance of" the resolved type, The virtual machine pushes an int one result onto the operand stack. Otherwise, The virtual machine machine pushes an int zero result onto the operand stack.

To determine whether the object pointed to by objectref is an "instance of" the resolved type, The virtual machine first determines whether the object is a class instance or array. (It can t be an interface instance, because interfaces can t be instantiated.) If it is a class instance, and the resolved type is a class, not an interface, the object is "an instance" of the resolved class if the object s class is the resolved class or a subclass of the resolved class. Else, if it is a class instance, and the resolved type is an interface, not an class, the object is "an instance" of the resolved interface if the object s class implements the resolved interface. Otherwise, the object is an array. If the resolved type is a class, it must be java.lang.Object . Else, if the resolved type is an array of primitive types, the object must be an array of the same primitive type. Otherwise, the resolved type must be an array with a component type of some reference type, and the object must be an array with a component type that is an "instance of" the component type of the resolved array type. (Note that the dimension of an array doesn t enter into the instanceof check, only the component type of the array.)

For more information about the instanceof instruction, see Chapter 15, "Objects and Arrays."

invokeinterface

- Invoke interface method

Opcode:

185 (0xb9)

Instruction Format:

invokeinterface , indexbyte1 , indexbyte2 , nargs , 0

Stack:

Before:..., objectref, [arg1, [arg2 ...]]

After: ...

Description:

To execute the invokeinterface instruction, the Java Virtual Machine first forms an unsigned 16-bit index into the constant pool by calculating (indexbyte1 8) | indexbyte2 .

The virtual machine then looks up the constant pool entry specified by the calculated index. The constant pool entry at that index must be a CONSTANT_InterfaceMethodref_info entry. If it hasn t already, The virtual machine resolves the entry. The resolved method s descriptor must exactly match the descriptor of one of the methods declared in the resolved interface. The method must not be an instance initialization method, " <init ", or a class initialization method, " <clinit ."

The nargs operand is an unsigned byte that indicates the number of words of parameters required by the method being invoked (including the hidden this reference). The operand stack must contain nargs - 1 words of parameters and the objectref word. The parameter words must match the order and type of parameters required by the resolved method. The objectref word, the reference to the object upon which to invoke the instance method, must be a reference . If the resolution is successful, The virtual machine pops nargs - 1 parameter words and objectref .

To invoke the method, The virtual machine retrieves the direct reference to the instance method to invoke from a method table. It locates the method table for the class of object pointed to by objectref and searches through it for a method with a name and descriptor that matches exactly the name and descriptor of the resolved method. (If the object s class is an array type, The virtual machine uses the method table for class java.lang.Object . An array type, of course, can only implement an interface if Object itself implements the interface.)

If the method is synchronized, the Java Virtual Machine, on behalf of the current thread, acquires the monitor associated with objectref .

If the method to invoke is not native, The virtual machine creates a new stack frame for the method and pushes the new stack frame onto the current thread s Java stack. The virtual machine then places the objectref word and nargs - 1 parameter words that it popped from the operand stack of the calling method s frame into the local variables of the new stack frame. It places objectref into local variable position zero, arg1 into local variable position one, and so on. ( objectref is the hidden this reference passed to all instance methods.) The virtual machine makes the new stack frame current, sets the program counter to the address of the first instruction in the new method, and continues execution there.

If the method to invoke is native, The virtual machine invokes the native method in an implementation-dependent manner.

As a result of executing this instruction, The virtual machine may throw any of the linking errors listed in Chapter 8, "The Linking Model," as possible during resolution of a CONSTANT_InterfaceMethodref_info entry. If no method exists in the object s class with the required name and descriptor, The virtual machine throws IncompatibleClassChangeError . Else, if the method exists but is static, The virtual machine throws IncompatibleClassChangeError . Else, if the method exists, but is not public, the virtual machine throws IllegalAccessError . Else, if the method is abstract, The virtual machine throws AbstractMethodError . Else, if the method is native and the native implementation of the method can t be loaded or linked, The virtual machine throws UnsatisfiedLinkError . Otherwise, if objectref is null , The virtual machine throws NullPointerException .

For more information about the invokeinterface instruction, see Chapter 19, "Method Invocation and Return."

invokespecial

- Invoke instance method with special handling for private, superclass, and instance initialization methods

Opcode:

183 (0xb7)

Instruction Format:

invokespecial , indexbyte1 , indexbyte2

Stack:

Before:..., objectref, [arg1, [arg2 ...]]

After: ...

Description:

To execute the invokespecial instruction, the Java Virtual Machine first forms an unsigned 16-bit index into the constant pool by calculating (indexbyte1 8) | indexbyte2 .

The virtual machine then looks up the constant pool entry specified by the calculated index. The constant pool entry at that index must be a CONSTANT_Methodref_info entry. If it hasn t already, The virtual machine resolves the entry, which yields a direct reference to the method s data, including the number of words of parameters to the method, nargs . The resolved method s descriptor must exactly match the descriptor of one of the methods declared in the resolved class. The method must not be a class initialization method, " <clinit ."

The invokespecial instruction is used to invoke three special kinds of instance methods: superclass methods, private methods, and instance initialization methods. invokespecial contrasts with invokevirtual in the way it invokes an instance method. Whereas invokevirtual always selects the method to invoke at run-time based on the class of the object (dynamic binding), invokespecial normally (with one exception) selects the method to invoke at compile-time based on the type of the reference (static binding).

The one exception to invokespecial s pure static binding behavior occurs if

o the resolved method is not private and is not an instance initialization method,

o the resolved method s class is a superclass of the current method s class,

o and the ACC_SUPER flag is set in the current method s class.

In this situation, the Java Virtual Machine dynamically selects at run-time the method to invoke by finding the method in the closest superclass that has a descriptor that exactly matches the resolved method s descriptor, irrespective of the class of the resolved method. In the majority of cases, the class of the selected method will most likely be the class of the resolved method anyway, but it is possible that it could be some other class.

For example, imagine you create an inheritance hierarchy of three classes: Animal , Dog , and CockerSpaniel . Assume class Dog extends class Animal , class CockerSpaniel extends class Dog , and that a method defined in CockerSpaniel uses invokespecial to invoke a non-private superclass method named walk() . Assume also that when you compiled CockerSpaniel , the compiler set the ACC_SUPER flag. In addition, assume that when you compiled CockerSpaniel , class Animal defined a walk() method, but Dog didn t. In that case, the symbolic reference from CockerSpaniel to the walk() method would give Animal as its class. When the invokespecial instruction in CockerSpaniel s method is executed, The virtual machine would dynamically select and invoke Animal s walk() method.

Now imagine that later, you added a walk() method to Dog , and recompiled Dog , but didn t recompile CockerSpaniel . CockerSpaniel s symbolic reference to the superclass walk() method still claims Animal as its class, even though there is now an implementation of walk() in Dog s class file. Nevertheless, when the invokespecial instruction in CockerSpaniel s method is executed, The virtual machine would dynamically select and invoke Dog s implementation of the walk() method.

This special (not static binding) treatment of superclass invocations was the motivation for adding the ACC_SUPER flag to the class access_flags item of class files, and for changing the name of this opcode from its original name, invokenonvirtual , to its current name, invokespecial . If the CockerSpaniel class of the previous example had been compiled by an old compiler that didn t set the ACC_SUPER flag, The virtual machine would invoke Animal s implementation of walk() regardless of whether Dog declared a walk() . As mentioned in Chapter 6, "The Java Class File," all new Java compilers should set the ACC_SUPER flag in every class file they generate.

If the resolved method is an instance initialization method, " <init ," the method must be invoked only once on each uninitialized (except to default initial values) object. In addition, an instance initialization method must be invoked on each uninitialized object before the first backwards branch. In other words, the bytecodes of a method need not call an <init method with invokespecial right after a new instruction. Other instructions could intervene between the new and the invokespecial for the <init , but none of those instructions may branch backwards (such as a goto to the beginning of the method).

The operand stack must contain nargs - 1 words of parameters and the objectref word. The parameter words must match the order and type of parameters required by the resolved method. The objectref word, the reference to the object upon which to invoke the instance method, must be a reference . If the resolution is successful, The virtual machine pops nargs - 1 parameter words and objectref .

If the method is synchronized, the Java Virtual Machine, on behalf of the current thread, acquires the monitor associated with objectref .

If the method to invoke is native, The virtual machine invokes the native method in an implementation-dependent manner.

As a result of executing this instruction, The virtual machine may throw any of the linking errors listed in Chapter 8, "The Linking Model," as possible during resolution of a CONSTANT_Methodref_info entry. As part of the process of resolving the CONSTANT_Methodref_info entry, The virtual machine checks whether the method s access permission enables the current class to access the method. If the method is protected, The virtual machine makes certain the method is a member of the either the current class or a superclass of the current class, and that the class of the object pointed to by objectref is either the current class or a subclass of the current class. If not (or if there is any other access permission problem), The virtual machine throws IllegalAccessError . Else, if the method exists and is accessible from the current class, but the method is static, The virtual machine throws IncompatibleClassChangeError . Else, if the method is abstract, The virtual machine throws AbstractMethodError . Else, if the method is native and the native implementation of the method can t be loaded or linked, The virtual machine throws UnsatisfiedLinkError . Otherwise, if objectref is null , The virtual machine throws NullPointerException .

For more information about the invokespecial instruction, see Chapter 19, "Method Invocation and Return."

invokestatic

- Invoke a class (static) method

Opcode:

184 (0xb8)

Instruction Format:

invokestatic , indexbyte1 , indexbyte2

Stack:

Before:..., [arg1, [arg2 ...]

After: ...

Description:

To execute the invokestatic instruction, the Java Virtual Machine first forms an unsigned 16-bit index into the constant pool by calculating (indexbyte1 8) | indexbyte2 .

The operand stack must contain nargs words of parameters. The parameter words must match the order and type of parameters required by the resolved method. If the resolution is successful, The virtual machine pops the nargs parameter words.

If the method is synchronized, the Java Virtual Machine, on behalf of the current thread, acquires the monitor associated with the Class instance that represents the resolved method s class.

If the method to invoke is not native, The virtual machine creates a new stack frame for the method and pushes the new stack frame onto the current thread s Java stack. The virtual machine then places the nargs parameter words that it popped from the operand stack of the calling method s frame into the local variables of the new stack frame. It places arg1 into local variable position zero, arg2 into local variable position one, and so on. The virtual machine makes the new stack frame current, sets the program counter to the address of the first instruction in the new method, and continues execution there.

If the method to invoke is native, The virtual machine invokes the native method in an implementation-dependent manner.

As a result of executing this instruction, The virtual machine may throw any of the linking errors listed in Chapter 8, "The Linking Model," as possible during resolution of a CONSTANT_Methodref_info entry. As part of the process of resolving the CONSTANT_Methodref_info entry, The virtual machine checks whether the method s access permission enables the current class to access the method. If the method is protected, The virtual machine makes certain the method is a member of the either the current class or a superclass of the current class. If not (or if there is any other access permission problem), The virtual machine throws IllegalAccessError . Else, if the method exists and is accessible from the current class, but the method is not static, The virtual machine throws IncompatibleClassChangeError . Else, if the method is abstract, The virtual machine throws AbstractMethodError . Otherwise, if the method is native and the native implementation of the method can t be loaded or linked, The virtual machine throws UnsatisfiedLinkError .

For more information about the invokestatic instruction, see Chapter 19, "Method Invocation and Return."

invokevirtual

- Invoke instance method,dispatch based on an object s class at run-time

Opcode:

182 (0xb6)

Instruction Format:

invokevirtual , indexbyte1 , indexbyte2

Stack:

Before:..., objectref, [arg1, [arg2 ...]]

After: ...

Description:

To execute the invokevirtual instruction, the Java Virtual Machine first forms an unsigned 16-bit index into the constant pool by calculating (indexbyte1 8) | indexbyte2 .

The virtual machine then looks up the constant pool entry specified by the calculated index. The constant pool entry at that index must be a CONSTANT_Methodref_info entry. If it hasn t already, The virtual machine resolves the entry, which yields the method s method table index, index , and the number of words of parameters to the method, nargs . The resolved method s descriptor must exactly match the descriptor of one of the methods declared in the resolved class. The method must not be an instance initialization method, " <init ", or a class initialization method, " <clinit ."

To invoke the method, The virtual machine retrieves the direct reference to the instance method to invoke from a method table. It locates the method table for the class of object pointed to by objectref and looks up the direct reference that occupies method table position index . (If the object s class is an array type, The virtual machine uses the method table for class java.lang.Object .)

If the method is synchronized, the Java Virtual Machine, on behalf of the current thread, acquires the monitor associated with objectref .

If the method to invoke is native, The virtual machine invokes the native method in an implementation-dependent manner.

As a result of executing this instruction, The virtual machine may throw any of the linking errors listed in Chapter 8, "The Linking Model," as possible during resolution of a CONSTANT_Methodref_info entry. As part of the process of resolving the CONSTANT_Methodref_info entry, The virtual machine checks whether the method s access permission enables the current class to access the method. If the method is protected, The virtual machine makes certain the method is a member of the either the current class or a superclass of the current class, and that the class of the object pointed to by objectref is either the current class or a subclass of the current class. If not (or if there is any other access permission problem), The virtual machine throws IllegalAccessError . Else, if the method exists and is accessible from the current class, but the method is static, The virtual machine throws IncompatibleClassChangeError . Else, if the method is abstract, The virtual machine throws AbstractMethodError . Else, if the method is native and the native implementation of the method can t be loaded or linked, The virtual machine throws UnsatisfiedLinkError . Otherwise, if objectref is null , The virtual machine throws NullPointerException .

For more information about the invokevirtual instruction, see Chapter 19, "Method Invocation and Return."

ior

- Perform boolean OR on int s

Opcode:

128 (0x80)

Instruction Format:

ior

Stack:

Before: ..., value1, value2

After: ..., result

Description:

The top two words of the operand stack, value1 and value2 , must be int s. To execute the ior instruction, the Java Virtual Machine pops value1 and value2 , bitwise ORs them, and pushes the int result .

For more information about the ior instruction, see Chapter 13, "Logic."

irem

- Calculate remainder of division of int s

Opcode:

112 (0x70)

Instruction Format:

irem

Stack:

Before: ..., value1, value2

After: ..., result

Description:

The top two words of the operand stack, value1 and value2 , must be int s. To execute the irem instruction, the Java Virtual Machine pops value1 and value2 , calculates the integer remainder, and pushes the int result . The integer remainder equals value1 - (value1 / value2) * value2 .

The irem instruction implements Java s remainder operator: % . The irem behaves such that the Java expression shown below is always true , where n and d are any two int s:

begin

Before:..., value

After: ...

Description:

The top four words of the operand stack must be two long s, value1 and value2 . To execute the ladd instruction, the Java Virtual Machine pops value1 and value2 , adds them, and pushes the long result . If overflow occurs, result is the 64 lowest order bits of the true mathematical result represented in a sufficiently wide two s-complement format, and the sign of result is different from that of the true mathematical result.

For more information about the ladd instruction, see Chapter 12, "Integer Arithmetic."

laload

- Load long from array

Opcode:

47 (0x2f)

Instruction Format:

laload

Stack:

Before: ..., arrayref, index

After: ..., value.word1, value.word2

Description:

Description:

The top two words of the operand stack must be a long , value . To execute the lneg instruction, the Java Virtual Machine pops value , negates it, and pushes the long result .

The result produced by an lneg instruction is the same number that would be produced by subtracting value from zero with the lsub instruction. As a consequence, when value is the smallest negative integer that can be represented by an long , the negation overflows. For this negation, the true mathematical result is one greater than the largest positive integer that can be represented by an long , and the actual result is equal to value with no change in sign.

For more information about the lneg instruction, see Chapter 12, "Integer Arithmetic."

lookupswitch

- Access jump table by key match and jump

Opcode:

171 (0xab)

Instruction Format:

lookupswitch , ...0-3 byte pad... , defaultbyte1 , defaultbyte2 , defaultbyte3 , defaultbyte4 , npairs1 , npairs2 , npairs3 , npairs4 , ..match-offset pairs..

Stack:

Before:..., key

After: ...

Description:

The lookupswitch opcode is followed by zero to three bytes of padding--enough so that the byte immediately following the padding starts at an address that is a multiple of four bytes from the beginning of the method. Each padding byte is a zero. Immediately following the padding is a signed 32-bit default branch offset, default . Following default is npairs , a signed count of the number of case value/branch offset pairs embedded in this lookupswitch instruction. The value of npairs must be greater than or equal to zero. Following npairs are the case value/branch offset pairs themselves . For each pair, the signed 32-bit case value, match , precedes the signed 32-bit branch offset, offset .

The virtual machine calculates all of these signed 32-bit values from the four individual bytes as (byte1 24) | (byte2 16) | (byte3 8) | byte4 .

The top word of the operand stack, key , must be an int . To execute the lookupswitch instruction, the Java Virtual Machine pops key off the operand stack and compares it to the match values. If the key is equal to one of the match values, The virtual machine calculates a target (program counter) address by adding the signed offset that corresponds to the matching match value to the address of the lookupswitch opcode. The target address must be the address of an opcode within the same method as the lookupswitch opcode. The virtual machine jumps to the target address and continues execution there.

For more information about the lookupswitch instruction, see Chapter 16, "Control Flow."

lor

- Perform boolean OR on long s

Opcode:

129 (0x81)

Instruction Format:

lor

Stack:

Before: ..., value1.word1, value1.word2, value2.word1, value2.word2

After: ..., result.word1, result.word2

Description:

The top four words of the operand stack must be two long s, value1 and value2 . To execute the lor instruction, the Java Virtual Machine pops value1 and value2 , bitwise ORs them, and pushes the long result .

For more information about the lor instruction, see Chapter 13, "Logic."

lrem

- Calculate remainder of division of long s

Opcode:

113 (0x71)

Instruction Format:

lrem

Stack:

Before: ..., value1.word1, value1.word2, value2.word1, value2.word2

After: ..., result.word1, result.word2

Description:

The top four words of the operand stack must be two long s, value1 and value2 . To execute the lrem instruction, the Java Virtual Machine pops value1 and value2 , calculates the integer remainder, and pushes the long result . The integer remainder equals value1 - (value1 / value2) * value2 .

The lrem instruction implements Java s remainder operator, % , on long s. The lrem behaves such that the Java expression shown below is always true , where n and d are any two long s:

begin

Before:..., value.word1, value.word2

After: ...

Description:

Description:

The top word of the operand stack, objectref , must be a reference .To execute the monitorenter instruction, the Java Virtual Machine pops objectref and, on behalf of the current thread, acquires the monitor associated with objectref .

If the objectref word is null ,

The virtual machine throws NullPointerException .

For more information about the monitorenter instruction, see Chapter 20, "Thread Synchronization."

monitorexit

- Release and exit object monitor

Opcode:

195 (0xc3)

Instruction Format:

monitorexit

Stack:

Before: ..., objectref

After: ...

Description:

If the objectref word is null , The virtual machine throws NullPointerException .

For more information about the monitorexit instruction, see Chapter 20, "Thread Synchronization."

multianewarray

- Allocate new multi-dimensional array

Opcode:

197 (0xc5)

Instruction Format:

multianewarray , indexbyte1 , indexbyte2 , dimensions

Stack:

Before:..., count1, [count2,...]

After: arrayref

Description:

The dimensions operand, an unsigned byte that indicates the number of dimensions in the array to create, must be greater than or equal to one. The top dimensions words of the operand stack, count1, [count2,...] , must contain int s that have nonnegative values. Each of these words gives the number of elements in one dimension of the array. For example, consider an array declared as:

begin cc .

int[][][] example = new int[3][4][5];

end

For this array, dimensions would be equal to three and the operand stack would contain three "count" words. The count1 word would be three, count2 four, and count3 five.

To execute the multianewarray instruction, the Java Virtual Machine first forms an unsigned 16-bit index into the constant pool by calculating (indexbyte1 8) | indexbyte2 .

If the resolution is successful, the Java Virtual Machine creates the dimensions -dimensional array on the heap. The virtual machine initializes the elements of the first-dimension array with references to the second-dimension arrays; it initializes the elements of each of the second-dimension array with references to the third-dimension arrays, and so on. The virtual machine initializes the elements of the last-dimension arrays with their default initial values. Lastly, the Java Virtual Machine pushes a reference to the new dimensions -dimensional array onto the operand stack.

As a result of executing this instruction, The virtual machine may throw any of the linking errors listed in Chapter 8, "The Linking Model," as possible during resolution of a CONSTANT_Class_info entry. If resolution succeeds and the array s component type is a reference type, but the current class does not have permission to access that reference type, The virtual machine throws IllegalAccessError . Otherwise, if any of the counts popped off of the operand stack have a negative value, the Java Virtual Machine throws NegativeArraySizeException .

Note that the dimensionality of the array type specified in the resolved CONSTANT_Class_info entry need not be equal to the dimensions operand--it can also be greater than dimensions . For example, the name of the array class for a three-dimensional array of int s is " [[[I ." The actual constant pool entry referenced by a multianewarray instruction that creates a three-dimensional array of int s must have at least three dimensions, but may have more. For instance, resolved array types of " [[[I ," " [[[[I ," and " [[[[[[[[I " would all yield three-dimensional arrays of int so long as the dimensions operand is three. This flexibility in specifying multidimensional array types to the multianewarray instruction can reduce the number of entries required in the constant pool of some classes.

For more information about the multianewarray instruction, see Chapter 15, "Objects and Arrays."

new

- Create a new object

Opcode:

187 (0xbb)

Instruction Format:

new , indexbyte1 , indexbyte2

Stack:

Before:...

After: ..., objectref

Description:

To execute the new instruction, the Java Virtual Machine first forms an unsigned 16-bit index into the constant pool by calculating (indexbyte1 8) | indexbyte2 .

The virtual machine then looks up the constant pool entry specified by the calculated index. The constant pool entry at that index must be a CONSTANT_Class_info entry. If it hasn t already, The virtual machine resolves the entry. The entry must be a class type, not an interface or array type. The virtual machine allocates sufficient memory from the heap for the new object s image, and sets the object s instance variables to their default initial values. Lastly, The virtual machine pushes objectref , a reference to the new object, onto the operand stack.

As a result of executing this instruction, The virtual machine may throw any of the linking errors listed in Chapter 8, "The Linking Model," as possible during resolution of a CONSTANT_Class_info entry. If resolution succeeds, but the resolved type is an interface, abstract class, or array, The virtual machine throws an InstantiationError . Else, if the current class doesn t have permission to access the resolved class, The virtual machine throws an IllegalAccessError .

For more information about the new instruction, see Chapter 15, "Objects and Arrays."

newarray

- Allocate new array of primitive type components

Opcode:

188 (0xbc)

Instruction Format:

newarray , atype

Stack:

Before:..., count

After: arrayref

Description:

The top word of the operand stack, count , must be an int . The atype operand, which is used to indicate the array type, must take one of the values shown in Table A-2. To execute the newarray instruction, the Java Virtual Machine pops count and creates on the heap an array of size count of the primitive type specified by atype .

The virtual machine initializes each array element to its default initial value and pushes arrayref , a reference to the new array, onto the operand stack.

Table A-2. Values for atype

2 columns

Array Type atype

T_BOOLEAN 4

T_CHAR 5

T_FLOAT 6

T_DOUBLE 7

T_BYTE 8

T_SHORT 9

T_INT 10

T_LONG 11

end table

If count is less than zero, the Java Virtual Machine throws NegativeArraySizeException .

For more information about the newarray instruction, see Chapter 15, "Objects and Arrays."

nop

- Do nothing

Opcode:

0 (0x0)

Instruction Format:

nop

Before:..., objectref, value

After: ...

Before: ..., objectref, value.word1, value.word2

After: ...

Description:

To execute the putfield instruction, the Java Virtual Machine first forms an unsigned 16-bit index into the constant pool by calculating (indexbyte1 8) | indexbyte2 .

The type of the single or double-word value occupying the top of the stack must be compatible with the descriptor of the resolved field. If the resolved field s descriptor is byte , short , char , boolean , or int , the type of value must be int . If the resolved field s descriptor is long , the type of value must be long . If the resolved field s descriptor is float , the type of value must be float . If the resolved field s descriptor is double , the type of value must be double . If the resolved field s descriptor is a reference type, the type of value must be reference and must be assignment-compatible the resolved descriptor type. The objectref word must be a reference .

The virtual machine pops value and objectref and assigns value to the appropriate field in the object pointed to by objectref .

As a result of executing this instruction, The virtual machine may throw any of the linking errors listed in Chapter 8, "The Linking Model," as possible during resolution of a CONSTANT_Fieldref_info entry. As part of the process of resolving the CONSTANT_Fieldref_info entry, The virtual machine checks whether the field s access permission enables the current class to access the field. If the field is protected, The virtual machine makes certain the field is a member of the either the current class or a superclass of the current class, and that the class of the object pointed to by objectref is either the current class or a subclass of the current class. If not (or if there is any other access permission problem), The virtual machine throws IllegalAccessError . Else, if the field exists and is accessible from the current class, but the field is static, The virtual machine throws IncompatibleClassChangeError . Otherwise, if objectref is null , The virtual machine throws NullPointerException .

For more information about the putfield instruction, see Chapter 15, "Objects and Arrays."

putstatic

- Set static field in class

Opcode:

179 (0xb3)

Instruction Format:

putstatic , indexbyte1 , indexbyte2

Stack:

Before:..., value

After: ...

Before: ..., value.word1, value.word2

After: ...

Description:

To execute the putstatic instruction, the Java Virtual Machine first forms an unsigned 16-bit index into the constant pool by calculating (indexbyte1 8) | indexbyte2 .

The virtual machine pops and assigns value to the appropriate static field.

For more information about the putstatic instruction, see Chapter 15, "Objects and Arrays."

ret

- Return from subroutine

Opcode:

169 (0xa9)

Instruction Format:

ret , index

Stack:

No change

Description:

After: ..., value

Description:

To execute the sipush instruction, the Java Virtual Machine first forms an intermediate 16-bit signed integer from byte1 and byte2 by calculating (byte1 8) | byte2 .

To see how the stack changes when an instruction is modified by wide , see the entry for the unmodified instruction. The stack change for an instruction modified by wide is identical to the stack change for that same instruction unmodified.

Description:

The wide opcode modifies instructions that reference the local variables, extending the modified instruction s unsigned 8-bit local variable index to an unsigned 16-bit index. As shown above, a wide instruction comes in two formats. When the wide opcode modifies iload , fload , aload , lload , dload , istore , fstore , astore , lstore , dstore , or ret , the instruction has the first format. When the wide opcode modifies iinc , the instruction has the second format.

To execute any wide instruction, the Java Virtual Machine first forms an unsigned 16-bit index into the local variables by calculating (indexbyte1 8) | indexbyte2 . Irrespective of the opcode that wide modifies, the calculated index must be a valid index into the local variables of the current frame. If the wide opcode modifies lload , dload , lstore , or dstore , then one more than the calculated index must also be a valid index into the local variables. Given a valid unsigned 16-bit (wide) local variable index, The virtual machine executes the modified instruction using the wide index.

When a wide opcode modifies an iinc instruction, the format of the iinc instruction changes. An unmodified iinc instruction has two operands, an 8-bit unsigned local variable index , and an 8-bit signed increment const . When modified by wide , however, both the iinc instruction s local variable index and its increment are extended by an extra byte. To execute this instruction, The virtual machine forms a signed 16-bit increment by calculating (constbyte1 8) | constbyte2 .

Note that from the perspective of the bytecode verifier, the opcode modified by wide is seen as an operand to the wide opcode. The bytecodes are not allowed to treat opcodes modified by wide independently. For example, it is illegal for a goto instruction to jump directly to an opcode modified by wide .

For more information about the wide instruction, see Chapter 10, "Stack Operations."

COMPUTING MCGRAW-HILL | Beta Books | Contact Us | Order Information | Online Catalog

Computing McGraw-Hill is an imprint of the McGraw-Hill Professional Book Group.

Copyright 1997 The McGraw-Hill Companies. All rights reserved. Any use is subject to the Terms of Use; the corporation also has a comprehensive Privacy Policy governing information we may collect from our customers.