overview.doc.html

A Java virtual machine instruction consists of an opcode specifying the operation to be performed, f

An implementation of the Java virtual machine that supports an extended floating-point
value set is permitted or required, under specified circumstances, to map a 
value of the associated floating-point type between the extended and the standard 
value sets. Such a <i>value set conversion</i> is not a type conversion, but a mapping 
between the value sets associated with the same type.
<p><a name="29147"></a>
Where value set conversion is indicated, an implementation is permitted to perform one of the following operations on a value:<p>
<ul><li>If the value is of type <code>float</code> and is not an element of the float value set, it maps the value to the nearest element of the float value set. <p>
<li>If the value is of type <code>double</code> and is not an element of the double value set, it maps the value to the nearest element of the double value set. 
<p><a name="29150"></a>
In addition, where value set conversion is indicated certain operations are required:<p>
<li>Suppose execution of a Java virtual machine instruction that is not FP-strict causes a value of type <code>float</code> to be pushed onto an operand stack that is FP-strict, passed as a parameter, or stored into a local variable, a field, or an element of an array. If the value is not an element of the float value set, it maps the value to the nearest element of the float value set.<p>
<li>Suppose execution of a Java virtual machine instruction that is not FP-strict causes a value of type <code>double</code> to be pushed onto an operand stack that is FP-strict, passed as a parameter, or stored into a local variable, a field, or an element of an array. If the value is not an element of the double value set, it maps the value to the nearest element of the double value set. 
</ul><a name="29294"></a>
Such required value set conversions may occur as a result of passing a parameter of a floating-point type during method invocation, including <code>native</code> method invocation; returning a value of a floating-point type from a method that is not FP-strict to a method that is FP-strict; or storing a value of a floating-point type into a local variable, a field, or an array in a method that is not FP-strict.<p>
<a name="33077"></a>
Not all values from an extended-exponent value set can be mapped exactly to a value in the corresponding standard value set. If a value being mapped is too large to be represented exactly (its exponent is greater than that permitted by the standard value set), it is converted to a (positive or negative) infinity of the corresponding type. If a value being mapped is too small to be represented exactly (its exponent is smaller than that permitted by the standard value set), it is rounded to the nearest of a representable denormalized value or zero of the same sign.<p>
<a name="29306"></a>
Value set conversion preserves infinities and NaNs and cannot change the sign of the value being converted. Value set conversion has no effect on a value that is not of a floating-point type.<p>
<a name="12174"></a>
<hr><h2>3.9    Specially Named Initialization Methods</h2>
<a name="16270"></a>
At the level of the Java virtual machine, every constructor <a href="Concepts.doc.html#16411">(&#167;2.12)</a> appears as an 
<i>instance initialization method</i> that has the <code></code>special name <code>&lt;init&gt;</code>. This name is 
supplied by a compiler. Because the name <code>&lt;init&gt;</code> is not a valid identifier, it cannot
be used directly in a program written in the Java programming language. 
Instance initialization methods may be invoked only within the Java virtual 
machine by the <i>invokespecial</i> instruction, and they may be invoked only on uninitialized
class instances. An instance initialization method takes on the access permissions
 <a href="Concepts.doc.html#18914">(&#167;2.7.4)</a> of the constructor from which it was derived.
<p><a name="16262"></a>
A class or interface has at most one <i>class or interface initialization method</i> and is initialized <a href="Concepts.doc.html#19075">(&#167;2.17.4)</a> by invoking that method. The initialization method of a class or interface is static and takes no arguments. It has the special name <code>&lt;clinit&gt;</code>. This name is supplied by a compiler. Because the name <code>&lt;clinit&gt;</code> is not a valid identifier, it cannot be used directly in a program written in the Java programming language. Class and interface initialization methods are invoked implicitly by the Java virtual machine; they are never invoked directly from any Java virtual machine instruction, but are invoked only indirectly as part of the class initialization process.<p>
<a name="15494"></a>
<hr><h2>3.10    Exceptions</h2>
<a name="27444"></a>
In the Java programming language, throwing an exception results in an immediate nonlocal transfer of control from the point where the exception was thrown. This transfer of control may abruptly complete, one by one, multiple statements, constructor invocations, static and field initializer evaluations, and method invocations. The process continues until a <code>catch</code> clause <a href="Concepts.doc.html#22746">(&#167;2.16.2)</a> is found that handles the thrown value. If no such clause can be found, the current thread exits. <p>
<a name="32345"></a>
In cases where a <code>finally</code> clause <a href="Concepts.doc.html#22746">(&#167;2.16.2)</a> is used, the <code>finally</code> clause is executed during the propagation of an exception thrown from the associated <code>try</code> block and any associated <code>catch</code> block, even if no <code>catch</code> clause that handles the thrown exception may be found.<p>
<a name="27504"></a>
As implemented by the Java virtual machine, each <code>catch</code> or <code>finally</code> clause of a method is represented by an exception handler. An exception handler specifies the range of offsets into the Java virtual machine code implementing the method for which the exception handler is active, describes the type of exception that the exception handler is able to handle, and specifies the location of the code that is to handle that exception. An exception matches an exception handler if the offset of the instruction that caused the exception is in the range of offsets of the exception handler and the exception type is the same class as or a subclass of the class of exception that the exception handler handles. When an exception is thrown, the Java virtual machine searches for a matching exception handler in the current method. If a matching exception handler is found, the system branches to the exception handling code specified by the matched handler.<p>
<a name="25058"></a>
If no such exception handler is found in the current method, the current method invocation completes abruptly <a href="Overview.doc.html#22091">(&#167;3.6.5)</a>. On abrupt completion, the operand stack and local variables of the current method invocation are discarded, and its frame is popped, reinstating the frame of the invoking method. The exception is then rethrown in the context of the invoker's frame and so on, continuing up the method invocation chain. If no suitable exception handler is found before the top of the method invocation chain is reached, the execution of the thread in which the exception was thrown is terminated.<p>
<a name="25062"></a>
The order in which the exception handlers of a method are searched for a match is important. Within a <code>class</code> file the exception handlers for each method are stored in a table <a href="ClassFile.doc.html#1546">(&#167;4.7.3)</a>. At run time, when an exception is thrown, the Java virtual machine searches the exception handlers of the current method in the order that they appear in the corresponding exception handler table in the <code>class</code> file, starting from the beginning of that table. Because <code>try</code> statements are structured, a compiler for the Java programming language can always order the entries of the exception handler table such that, for any thrown exception and any program counter value in that method, the first exception handler that matches the thrown exception corresponds to the innermost matching <code>catch</code> or <code>finally</code> clause. <p>
<a name="25026"></a>
Note that the Java virtual machine does not enforce nesting of or any ordering of the exception table entries of a method <a href="ClassFile.doc.html#9855">(&#167;4.9.5)</a>. The exception handling semantics of the Java programming language are implemented only through cooperation with the compiler. When <code>class</code> files are generated by some other means, the defined search procedure ensures that all Java virtual machines will behave consistently.<p>
<a name="25085"></a>
More information on the implementation of <code>catch</code> and <code>finally</code> clauses is given in &#32;<a href="Compiling.doc.html#2839">Chapter 7</a>, <a href="Compiling.doc.html#2989"></a><a href="Compiling.doc.html#2989">"Compiling for the Java Virtual Machine."</a><p>
<a name="7143"></a>
<hr><h2>3.11    Instruction Set Summary</h2>
<a name="2111"></a>
A Java virtual machine instruction consists of a one-byte <em>opcode</em> specifying the 
operation to be performed, followed by zero or more <em>operands </em>supplying arguments 
or data that are used by the operation. Many instructions have no operands and consist
only of an opcode.
<p><a name="2073"></a>
Ignoring exceptions, the inner loop of a Java virtual machine interpreter is effectively<p>
<blockquote><pre>
do {
     fetch an opcode;
     if (operands) fetch operands;
     execute the action for the opcode;
} while (there is more to do);
</pre></blockquote><a name="16703"></a>
The number and size of the operands are determined by the opcode. If an operand is more than one byte in size, then it is stored in <em>big-endian</em> order-high-order byte first. For example, an unsigned 16-bit index into the local variables is stored as two unsigned bytes, <i>byte1</i> and <i>byte2</i>, such that its value is <p>
<blockquote>(<i>byte1</i> << <code>8)&#32;|&#32;</code><i>byte2
</i></blockquote><a name="21440"></a>
The bytecode instruction stream is only single-byte aligned. The two exceptions are 
the <i>tableswitch</i> and <i>lookupswitch</i> instructions, which are padded to force internal 
alignment of some of their operands on 4-byte boundaries.
<p><a name="25234"></a>
The decision to limit the Java virtual machine opcode to a byte and to forgo data alignment within compiled code reflects a conscious bias in favor of compactness, possibly at the cost of some performance in naive implementations. A one-byte opcode also limits the size of the instruction set. Not assuming data alignment means that immediate data larger than a byte must be constructed from bytes at run time on many machines.<p>
<a name="7565"></a>
<h3>3.11.1    Types and the Java Virtual Machine</h3>
<a name="7566"></a>
Most of the instructions in the Java virtual machine instruction set encode type 
information about the operations they perform. For instance, the <i>iload</i> instruction 
loads the contents of a local variable, which must be an <code>int</code>, onto the operand stack. 
The <i>fload</i> instruction does the same with a <code>float</code> value. The two instructions may 
have identical implementations, but have distinct opcodes.
<p><a name="7572"></a>
For the majority of typed instructions, the instruction type is represented explicitly in the opcode mnemonic by a letter: <i>i</i> for an <code>int</code> operation, <i>l</i> for <code>long</code>, <i>s</i> for <code>short</code>, <i>b</i> for <code>byte</code>, <i>c</i> for <code>char</code>, <i>f</i> for <code>float</code>, <i>d</i> for <code>double</code>, and <i>a</i> for <code>reference</code>. Some instructions for which the type is unambiguous do not have a type letter in their mnemonic. For instance, <i>arraylength</i> always operates on an object that is an array. Some instructions, such as <i>goto</i>, an unconditional control transfer, do not operate on typed operands.<p>
<a name="16866"></a>
Given the Java virtual machine's one-byte opcode size, encoding types into opcodes places pressure on the design of its instruction set. If each typed instruction supported all of the Java virtual machine's runtime data types, there would be more instructions than could be represented in a byte. Instead, the instruction set of the Java virtual machine provides a reduced level of type support for certain operations. In other words, the instruction set is intentionally not orthogonal. Separate instructions can be used to convert between unsupported and supported data types as necessary.<p>
<a name="20055"></a>
<a href="Overview.doc.html#37356">Table 3.2</a> summarizes the type support in the instruction set of the Java virtual machine. A specific instruction, with type information, is built by replacing the <i>T</i> in the instruction template in the opcode column by the letter in the type column. If the type column for some instruction template and type is blank, then no instruction exists supporting that type of operation. For instance, there is a load instruction for type <code>int</code>, <i>iload</i>, but there is no load instruction for type <code>byte</code>. <p>
<a name="37350"></a>
Note that most instructions in <a href="Overview.doc.html#37356">Table 3.2</a> do not have forms for the integral types <code>byte</code>, <code>char</code>, and <code>short</code>. None have forms for the <code>boolean</code> type. Compilers encode loads of literal values of types <code>byte</code> and <code>short</code> using Java virtual machine instructions that sign-extend those values to values of type <code>int</code> at compile time or run time. Loads of literal values of types <code>boolean</code> and <code>char</code> are encoded using instructions that zero-extend the literal to a value of type <code>int</code> at compile time or run time. Likewise, loads from arrays of values of type <code>boolean</code>, <code>byte</code>, <code>short</code>, and <code>char</code> are encoded using Java virtual machine instructions that sign-extend or zero-extend the values to values of type <code>int</code>. Thus, most operations on values of actual types <code>boolean</code>, <code>byte</code>, <code>char</code>, and <code>short</code> are correctly performed by instructions operating on values of computational type <code>int</code>. 
<p><a name="37356"></a><Table Border="1">
<tr><th><b><i>opcode
</i></b>
<th><b><i><strong>byte
</strong></i></b>
<th><b><i><strong>short
</strong></i></b>
<th><b><i><strong>int
</strong></i></b>
<th><b><i><strong>long
</strong></i></b>
<th><b><i><strong>float
</strong></i></b>
<th><b><i><strong>double
</strong></i></b>
<th><b><i><strong>char
</strong></i></b>
<th><b><i><strong>reference
</strong></i></b>
<tr><td><a name="37392"></a>
<i>Tipush</i>
<td><a name="37394"></a>
<i>bipush</i>
<td><a name="37396"></a>
<i>sipush</i>
<td><a name="37398"></a>

<td><a name="37400"></a>

<td><a name="37402"></a>

<td><a name="37404"></a>

<td><a name="37406"></a>

<td><a name="37408"></a>


<tr><td><a name="37410"></a>
<i>Tconst</i>
<td><a name="37412"></a>

<td><a name="37414"></a>

<td><a name="37416"></a>
<i>iconst</i>
<td><a name="37418"></a>
<i>lconst</i>
<td><a name="37420"></a>
<i>fconst</i>
<td><a name="37422"></a>
<i>dconst</i>
<td><a name="37424"></a>

<td><a name="37426"></a>
<i>aconst</i>

<tr><td><a name="37428"></a>
<i>Tload</i>
<td><a name="37430"></a>

<td><a name="37432"></a>

<td><a name="37434"></a>
<i>iload</i>
<td><a name="37436"></a>
<i>lload</i>
<td><a name="37438"></a>
<i>fload</i>
<td><a name="37440"></a>
<i>dload</i>
<td><a name="37442"></a>

<td><a name="37444"></a>
<i>aload</i>

<tr><td><a name="37446"></a>
<i>Tstore</i>
<td><a name="37448"></a>

<td><a name="37450"></a>

<td><a name="37452"></a>
<i>istore</i>
<td><a name="37454"></a>
<i>lstore</i>
<td><a name="37456"></a>
<i>fstore</i>
<td><a name="37458"></a>
<i>dstore</i>
<td><a name="37460"></a>

<td><a name="37462"></a>
<i>astore</i>

<tr><td><a name="37464"></a>
<i>Tinc</i>
<td><a name="37466"></a>

<td><a name="37468"></a>

<td><a name="37470"></a>
<i>iinc</i>
<td><a name="37472"></a>

<td><a name="37474"></a>

<td><a name="37476"></a>

<td><a name="37478"></a>

<td><a name="37480"></a>


<tr><td><a name="37482"></a>
<i>Taload</i>
<td><a name="37484"></a>
<i>baload</i>
<td><a name="37486"></a>
<i>saload</i>
<td><a name="37488"></a>
<i>iaload</i>
<td><a name="37490"></a>
<i>laload</i>
<td><a name="37492"></a>
<i>faload</i>