overview.doc.html

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

current method <a href="Overview.doc.html#17257">(&#167;3.6)</a> for that thread. If that method is not <code>native</code>, the <code>pc</code> register 
contains the address of the Java virtual machine instruction currently being executed.
If the method currently being executed by the thread is <code>native</code>, the value of 
the Java virtual machine's <code>pc</code> register is undefined. The Java virtual machine's <code>pc</code> 
register is wide enough to hold a <code>returnAddress</code> or a native pointer on the specific 
platform.
<p><a name="6654"></a>
<h3>3.5.2    Java Virtual Machine Stacks</h3>
<a name="30934"></a>
Each Java virtual machine thread has a private <i>Java virtual machine stack</i>, created at 
the same time as the thread.<a href="#30937"><sup>3</sup></a> A Java virtual machine stack stores frames (<a href="Overview.doc.html#17257">&#167;3.6)</a>. A 
Java virtual machine stack is analogous to the stack of a conventional language such 
as C: it holds local variables and partial results, and plays a part in method invocation
and return. Because the Java virtual machine stack is never manipulated directly 
except to push and pop frames, frames may be heap allocated. The memory for a 
Java virtual machine stack does not need to be contiguous.
<p><a name="36272"></a>
The Java virtual machine specification permits Java virtual machine stacks either to be of a fixed size or to dynamically expand and contract as required by the computation. If the Java virtual machine stacks are of a fixed size, the size of each Java virtual machine stack may be chosen independently when that stack is created. A Java virtual machine implementation may provide the programmer or the user control over the initial size of Java virtual machine stacks, as well as, in the case of dynamically expanding or contracting Java virtual machine stacks, control over the maximum and minimum sizes.<a href="#36275"><sup>4</sup></a> <p>
<a name="23152"></a>
The following exceptional conditions are associated with Java virtual machine stacks:<p>
<ul><li>If the computation in a thread requires a larger Java virtual machine stack than is permitted, the Java virtual machine throws a <code>StackOverflowError</code>. <p>
<li>If Java virtual machine stacks can be dynamically expanded, and expansion is attempted but insufficient memory can be made available to effect the expansion, or if insufficient memory can be made available to create the initial Java virtual machine stack for a new thread, the Java virtual machine throws an <code>OutOfMemoryError</code>.
</ul><a name="15730"></a>
<h3>3.5.3    Heap</h3>
<a name="6655"></a>
The Java virtual machine has a <i>heap</i> that is shared among all Java virtual machine 
threads. The heap is the runtime data area from which memory for all class 
instances and arrays is allocated. 
<p><a name="21949"></a>
The heap is created on virtual machine start-up. Heap storage for objects is reclaimed by an automatic storage management system (known as a <i>garbage collector</i>); objects are never explicitly deallocated. The Java virtual machine assumes no particular type of automatic storage management system, and the storage management technique may be chosen according to the implementor's system requirements. The heap may be of a fixed size or may be expanded as required by the computation and may be contracted if a larger heap becomes unnecessary. The memory for the heap does not need to be contiguous. <p>
<a name="37329"></a>
A Java virtual machine implementation may provide the programmer or the user control over the initial size of the heap, as well as, if the heap can be  dynamically expanded or contracted, control over the maximum and minimum heap size.<a href="#30988"><sup>5</sup></a>
<p><a name="23145"></a>
The following exceptional condition is associated with the heap:<p>
<ul><li>If a computation requires more heap than can be made available by the automatic storage management system, the Java virtual machine throws an <code>OutOfMemoryError</code>.
</ul><a name="6656"></a>
<h3>3.5.4    Method Area</h3>
<a name="6657"></a>
The Java virtual machine has a <i>method area</i> that is shared among all Java virtual 
machine threads. The method area is analogous to the storage area for compiled 
code of a conventional language or analogous to the "text" segment in a UNIX process.
It stores per-class structures such as the runtime constant pool, field and 
method data, and the code for methods and constructors, including the special methods
<a href="Overview.doc.html#12174">(&#167;3.9)</a> used in class and instance initialization and interface type initialization. 
<p><a name="21952"></a>
The method area is created on virtual machine start-up. Although the method area is logically part of the heap, simple implementations may choose not to either garbage collect or compact it. This version of the Java virtual machine specification does not mandate the location of the method area or the policies used to manage compiled code. The method area may be of a fixed size or may be expanded as required by the computation and may be contracted if a larger method area becomes unnecessary. The memory for the method area does not need to be contiguous. <p>
<a name="22992"></a>
A Java virtual machine implementation may provide the programmer or the user control over the initial size of the method area, as well as, in the case of a varying-size method area, control over the maximum and minimum method area size.<a href="#31002"><sup>6</sup></a><p>
<a name="23163"></a>
The following exceptional condition is associated with the method area:<p>
<ul><li>If memory in the method area cannot be made available to satisfy an allocation request, the Java virtual machine throws an <code>OutOfMemoryError.</code>
</ul><a name="22972"></a>
<h3>3.5.5    Runtime Constant Pool</h3>
<a name="22973"></a>
A <i>runtime constant pool</i> is a per-class or per-interface runtime representation of the 
<code>constant_pool</code> table in a <code>class</code> file (<a href="ClassFile.doc.html#20080">&#167;4.4</a>). It contains several kinds of constants, 
ranging from numeric literals known at compile time to method and field references 
that must be resolved at run time. The runtime constant pool serves a function similar
to that of a symbol table for a conventional programming language, although 
it contains a wider range of data than a typical symbol table.
<p><a name="23189"></a>
Each runtime constant pool is allocated from the Java virtual machine's method area <a href="Overview.doc.html#6656">(&#167;3.5.4)</a>. The runtime constant pool for a class or interface is constructed when the class or interface is created <a href="ConstantPool.doc.html#72007">(&#167;5.3)</a> by the Java virtual machine. <p>
<a name="23215"></a>
The following exceptional condition is associated with the construction of the runtime constant pool for a class or interface:<p>
<ul><li>When creating a class or interface, if the construction of the runtime constant pool requires more memory than can be made available in the method area of the Java virtual machine, the Java virtual machine throws an <code>OutOfMemoryError</code>.
</ul><a name="23194"></a>
See <a href="ConstantPool.doc.html#67960">Chapter 5</a> for information about the construction of the runtime constant pool.<p>
<a name="15637"></a>
<h3>3.5.6    Native Method Stacks</h3>
<a name="25597"></a>
An implementation of the Java virtual machine may use conventional stacks, colloquially
called "C stacks," to support <code>native</code> methods, methods written in a language
other than the Java programming language. Native method stacks may also be 
used by the implementation of an interpreter for the Java virtual machine's instruction
set in a language such as C. Java virtual machine implementations that cannot 
load <code>native</code> methods and that do not themselves rely on conventional stacks need 
not supply native method stacks. If supplied, native method stacks are typically allocated
per thread when each thread is created.
<p><a name="36284"></a>
The Java virtual machine specification permits native method stacks either to be of a fixed size or to dynamically expand and contract as required by the computation. If the native method stacks are of a fixed size, the size of each native method stack may be chosen independently when that stack is created. In any case, a Java virtual machine implementation may provide the programmer or the user control over the initial size of the native method stacks. In the case of varying-size native method stacks, it may also make available control over the maximum and minimum method stack sizes.<a href="#36289"><sup>7</sup></a><p>
<a name="31034"></a>
The following exceptional conditions are associated with native method stacks:<p>
<ul><li>If the computation in a thread requires a larger native method stack than is  permitted, the Java virtual machine throws a <code>StackOverflowError</code>. <p>
<li>If native method stacks can be dynamically expanded and native method stack expansion is attempted but insufficient memory can be made available, or if insufficient memory can be made available to create the initial native method stack for a new thread, the Java virtual machine throws an <code>OutOfMemoryError</code>.
</ul><a name="17257"></a>
<hr><h2>3.6    Frames</h2>
<a name="1962"></a>
A <i>frame</i> is used to store data and partial results, as well as to perform dynamic linking
, return values for methods, and dispatch exceptions. 
<p><a name="15581"></a>
A new frame is created each time a method is invoked. A frame is destroyed when its method invocation completes, whether that completion is normal or abrupt (it throws an uncaught exception). Frames are allocated from the Java virtual machine stack <a href="Overview.doc.html#6654">(&#167;3.5.2)</a> of the thread creating the frame. Each frame has its own array of local variables <a href="Overview.doc.html#15722">(&#167;3.6.1)</a>, its own operand stack <a href="Overview.doc.html#28851">(&#167;3.6.2)</a>, and a reference to the runtime constant pool <a href="Overview.doc.html#22972">(&#167;3.5.5)</a> of the class of the current method. <p>
<a name="31659"></a>
The sizes of the local variable array and the operand stack are determined at compile time and are supplied along with the code for the method associated with the frame <a href="ClassFile.doc.html#1546">(&#167;4.7.3)</a>. Thus the size of the frame data structure depends only on the implementation of the Java virtual machine, and the memory for these structures can be allocated simultaneously on method invocation.<p>
<a name="15582"></a>
Only one frame, the frame for the executing method, is active at any point in a given thread of control. This frame is referred to as the <i>current frame</i>, and its method is known as the <i>current method</i>. The class in which the current method is defined is the <i>current class</i>. Operations on local variables and the operand stack are typically with reference to the current frame. <p>
<a name="23270"></a>
A frame ceases to be current if its method invokes another method or if its method completes. When a method is invoked, a new frame is created and becomes current when control transfers to the new method. On method return, the current frame passes back the result of its method invocation, if any, to the previous frame. The current frame is then discarded as the previous frame becomes the current one.<p>
<a name="30465"></a>
Note that a frame created by a thread is local to that thread and cannot be referenced by any other thread.<p>
<a name="15722"></a>
<h3>3.6.1    Local Variables</h3>
<a name="31542"></a>
Each frame <a href="Overview.doc.html#17257">(&#167;3.6)</a> contains an array of variables known as its <i>local variables</i>. The 
length of the local variable array of a frame is determined at compile time and supplied
in the binary representation of a class or interface along with the code for the 
method associated with the frame <a href="ClassFile.doc.html#1546">(&#167;4.7.3)</a>.
<p><a name="30435"></a>
A single local variable can hold a value of type <code>boolean</code>, <code>byte</code>, <code>char</code>, <code>short</code>, <code>int</code>, <code>float</code>, <code>reference</code>, or <code>returnAddress</code>. A pair of local variables can hold a value of type <code>long</code> or <code>double</code>.<p>
<a name="15724"></a>
Local variables are addressed by indexing. The index of the first local variable is zero. An integer is be considered to be an index into the local variable array if and only if that integer is between zero and one less than the size of the local variable array. <p>
<a name="29885"></a>
A value of type <code>long</code> or type <code>double</code> occupies two consecutive local variables. Such a value may only be addressed using the lesser index. For example, a value of type <code>double</code> stored in the local variable array at index <em>n</em> actually occupies the local variables with indices <em>n</em> and <em>n</em> &#32;+1; however, the local variable at index <em>n</em> &#32;+1 cannot be loaded from. It can be stored into. However, doing so invalidates the contents of local variable <em>n</em>.<p>
<a name="30397"></a>
The Java virtual machine does not require <i>n</i> to be even. In intuitive terms, values of types <code>double</code> and <code>long</code> need not be 64-bit aligned in the local variables array. Implementors are free to decide the appropriate way to represent such values using the two local variables reserved for the value.<p>
<a name="31482"></a>
The Java virtual machine uses local variables to pass parameters on method invocation. On class method invocation any parameters are passed in consecutive local variables starting from local variable <i>0</i>. On instance method invocation, local variable <i>0</i> is always used to pass a reference to the object on which the instance method is being invoked (<code>this</code> in the Java programming language). Any parameters are subsequently passed in consecutive local variables starting from local variable <i>1</i>.<p>
<a name="28851"></a>
<h3>3.6.2    Operand Stacks</h3>
<a name="31560"></a>
Each frame <a href="Overview.doc.html#17257">(&#167;3.6)</a> contains a last-in-first-out (LIFO) stack known as its <i>operand 
stack</i>. The maximum depth of the operand stack of a frame is determined at compile 
time and is supplied along with the code for the method associated with the frame 
<a href="ClassFile.doc.html#1546">(&#167;4.7.3)</a>.
<p><a name="31519"></a>
Where it is clear by context, we will sometimes refer to the operand stack of the current frame as simply the operand stack.<p>
<a name="29825"></a>
The operand stack is empty when the frame that contains it is created. The Java virtual machine supplies instructions to load constants or values from local variables or fields onto the operand stack. Other Java virtual machine instructions take operands from the operand stack, operate on them, and push the result back onto the operand stack. The operand stack is also used to prepare parameters to be passed to methods and to receive method results. <p>
<a name="15727"></a>
For example, the <i>iadd</i> instruction adds two <code>int</code> values together. It requires that the <code>int</code> values to be added be the top two values of the operand stack, pushed there by previous instructions. Both of the <code>int</code> values are popped from the operand stack. They are added, and their sum is pushed back onto the operand stack. Subcomputations may be nested on the operand stack, resulting in values that can be used by the encompassing computation. <p>
<a name="15728"></a>
Each entry on the operand stack can hold a value of any Java virtual machine type, including a value of type <code>long</code> or type <code>double</code>. <p>
<a name="15729"></a>
Values from the operand stack must be operated upon in ways appropriate to their types. It is not possible, for example, to push two <code>int</code> values and subsequently treat them as a <code>long</code> or to push two <code>float</code> values and subsequently add them with an <i>iadd</i> instruction. A small number of Java virtual machine instructions (the <i>dup</i> instructions and <i>swap</i>) operate on runtime data areas as raw values without regard to their specific types; these instructions are defined in such a way that they cannot be used to modify or break up individual values. These restrictions on operand stack manipulation are enforced through <code>class</code> file verification <a href="ClassFile.doc.html#88597">(&#167;4.9)</a>.<p>
<a name="29842"></a>
At any point in time an operand stack has an associated depth, where a value of type <code>long</code> or <code>double</code> contributes two units to the depth and a value of any other type contributes one unit.<p>
<a name="1963"></a>
<h3>3.6.3    Dynamic Linking</h3>
<a name="1913"></a>
Each frame <a href="Overview.doc.html#17257">(&#167;3.6)</a> contains a reference to the runtime constant pool <a href="Overview.doc.html#22972">(&#167;3.5.5)</a> for 
the type of the current method to support <i>dynamic linking</i> of the method code. The 
<code>class</code> file code for a method refers to methods to be invoked and variables to be 
accessed via symbolic references. Dynamic linking translates these symbolic 
method references into concrete method references, loading classes as necessary 
to resolve as-yet-undefined symbols, and translates variable accesses into appropriate
offsets in storage structures associated with the runtime location of these 
variables.
<p><a name="1972"></a>
This late binding of the methods and variables makes changes in other classes that a method uses less likely to break this code.<p>
<a name="1973"></a>
<h3>3.6.4    Normal Method Invocation Completion</h3>
<a name="1920"></a>
A method invocation <i>completes normally</i> if that invocation does not cause an exception
(<a href="Concepts.doc.html#22727">&#167;2.16</a>, <a href="Overview.doc.html#15494">&#167;3.10)</a> to be thrown, either directly from the Java virtual machine or as a 
result of executing an explicit <code>throw</code> statement. If the invocation of the current 
method completes normally, then a value may be returned to the invoking method. 
This occurs when the invoked method executes one of the return instructions 
<a href="Overview.doc.html#31293">(&#167;3.11.8)</a>, the choice of which must be appropriate for the type of the value being 
returned (if any).
<p><a name="1980"></a>
The current frame <a href="Overview.doc.html#17257">(&#167;3.6)</a> is used in this case to restore the state of the invoker, including its local variables and operand stack, with the program counter of the invoker appropriately incremented to skip past the method invocation instruction. Execution then continues normally in the invoking method's frame with the returned value (if any) pushed onto the operand stack of that frame.<p>
<a name="22091"></a>
<h3>3.6.5    Abrupt Method Invocation Completion</h3>
<a name="22092"></a>
A method invocation <i>completes abruptly </i>if execution of a Java virtual machine 
instruction within the method causes the Java virtual machine to throw an exception 
(<a href="Concepts.doc.html#22727">&#167;2.16</a>, <a href="Overview.doc.html#15494">&#167;3.10)</a>, and that exception is not handled within the method. Execution of an 
<i>athrow</i> instruction also causes an exception to be explicitly thrown and, if the 
exception is not caught by the current method, results in abrupt method invocation 
completion. A method invocation that completes abruptly never returns a value to its 
invoker.
<p><a name="22093"></a>
<h3>3.6.6    Additional Information</h3>
<a name="22094"></a>
A frame may be extended with additional implementation-specific information, 
such as debugging information.
<p><a name="16066"></a>
<hr><h2>3.7    Representation of Objects</h2>
<a name="16067"></a>
The Java virtual machine does not mandate any particular internal structure for 
objects.<a href="#31069"><sup>8</sup></a>
<p><a name="35253"></a>
<hr><h2>3.8    Floating-Point Arithmetic</h2>
<a name="35257"></a>
The Java virtual machine incorporates a subset of the floating-point arithmetic specified
in <i>IEEE Standard for Binary Floating-Point Arithmetic</i> (ANSI/IEEE Std. 
754-1985, New York).
<p><a name="35254"></a>
<h3>3.8.1    Java Virtual Machine Floating-Point Arithmetic and IEEE 754</h3>
<a name="33128"></a>
The key differences between the floating-point arithmetic supported by the Java virtual
machine and the IEEE 754 standard are:
<p><ul><li>The floating-point operations of the Java virtual machine do not throw exceptions, trap, or otherwise signal the IEEE 754 exceptional conditions of invalid operation, division by zero, overflow, underflow, or inexact. The Java virtual machine has no signaling NaN value.<p>
<li>The Java virtual machine does not support IEEE 754 signaling floating-point comparisons.<p>
<li>The rounding operations of the Java virtual machine always use IEEE 754 round to nearest mode. Inexact results are rounded to the nearest representable value, with ties going to the value with a zero least-significant bit. This is the IEEE 754 default mode. But Java virtual machine instructions that convert   values of floating-point types to values of integral types round toward zero. The Java virtual machine does not give any means to change the floating-point rounding mode.<p>
<li>The Java virtual machine does not support either the IEEE 754 single extended or double extended format, except insofar as the double and double-extended-exponent value sets may be said to support the single extended format. The float-extended-exponent and double-extended-exponent value sets, which may optionally be supported, do not correspond to the values of the IEEE 754 extended formats: the IEEE 754 extended formats require extended precision as well as extended exponent range.
</ul><a name="28905"></a>
<h3>3.8.2    Floating-Point Modes</h3>
<a name="31078"></a>
Every method has a <i>floating-point mode</i>, which is either <i>FP-strict</i> or <i>not FP-strict</i>. 
The floating-point mode of a method is determined by the setting of the 
<code>ACC_STRICT</code> bit of the <code>access_flags</code> item of the <code>method_info</code> structure <a href="ClassFile.doc.html#1513">(&#167;4.6)</a> 
defining the method. A method for which this bit is set is FP-strict; otherwise, the 
method is not FP-strict.
<p><a name="28953"></a>
Note that this mapping of the <code>ACC_STRICT</code> bit implies that methods in classes compiled by a compiler that predates the Java 2 platform, v1.2, are effectively not FP-strict.<p>
<a name="28951"></a>
We will refer to an operand stack as having a given floating-point mode when the method whose invocation created the frame containing the operand stack has that floating-point mode. Similarly, we will refer to a Java virtual machine instruction as having a given floating-point mode when the method containing that instruction has that floating-point mode.<p>
<a name="37338"></a>
If a float-extended-exponent value set is supported <a href="Overview.doc.html#28147">(&#167;3.3.2)</a>, values of type <code>float</code> on an operand stack that is not FP-strict may range over that value set except where prohibited by value set conversion <a href="Overview.doc.html#33120">(&#167;3.8.3)</a>. If a double-extended-exponent value set is supported <a href="Overview.doc.html#28147">(&#167;3.3.2)</a>, values of type <code>double</code> on an operand stack that is not FP-strict may range over that value set except where prohibited by value set conversion. <p>
<a name="33036"></a>
In all other contexts, whether on the operand stack or elsewhere, and regardless of floating-point mode, floating-point values of type <code>float</code> and <code>double</code> may only range over the float value set and double value set, respectively. In particular, class and instance fields, array elements, local variables, and method parameters may only contain values drawn from the standard value sets.<p>
<a name="33120"></a>
<h3>3.8.3    Value Set Conversion</h3>
<a name="29146"></a>