📄 overview.doc.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>VM Spec Structure of the Java Virtual Machine</title>
</head>
<body BGCOLOR=#eeeeff text=#000000 LINK=#0000ff VLINK=#000077 ALINK=#ff0000>
<table width=100%><tr>
<td><a href="VMSpecTOC.doc.html">Contents</a> | <a href="Concepts.doc.html">Prev</a> | <a href="ClassFile.doc.html">Next</a> | <a href="Lindholm.INDEX.html">Index</a></td><td align=right><i><i>The Java<sup><font size=-2>TM</font></sup> Virtual Machine Specification</i></i></td>
</tr></table>
<hr><br>
<a name="2839"></a>
<p><strong>CHAPTER 3 </strong></p>
<a name="3446"></a>
<h1>Structure of the Java Virtual Machine</h1>
<hr><p>
<a name="15377"></a>
This book specifies an abstract machine. It does not document any particular
implementation of the Java Virtual Machine, including Sun's.
<p><a name="16937"></a>
To implement the Java Virtual Machine correctly, you need only be able to read the Java <code>class</code> file format and correctly perform the operations specified therein. Implementation details that are not part of the Java Virtual Machine's specification would unnecessarily constrain the creativity of implementors, and will only be provided to make the exposition clearer. For example, the memory layout of runtime data areas, the garbage-collection algorithm used, and any optimizations of the bytecodes (for example, translating them into machine code) are left to the discretion of the implementor. <p>
<a name="12237"></a>
<hr><h2>3.1 Data Types</h2>
<a name="15063"></a>
Like the Java language, the Java Virtual Machine operates on two kinds of types:
<i>primitive types</i> and <i>reference types</i>. There are, correspondingly, two kinds of values
that can be stored in variables, passed as arguments, returned by methods, and operated upon: <i>primitive values</i> and <i>reference values</i>.
<p><a name="15114"></a>
The Java Virtual Machine expects that nearly all type checking is done at compile time, not by the Java Virtual Machine itself. In particular, data need not be tagged or otherwise be inspectable to determine types. Instead, the instruction set of the Java Virtual Machine distinguishes its operand types using instructions intended to operate on values of specific types. For instance, <code>iadd</code>, <code>ladd</code>, <code>fadd</code>, and <code>dadd</code> are all Java Virtual Machine instructions that add two numeric values, but they require operands whose types are <code>int</code>, <code>long</code>, <code>float</code>, and <code>double</code>, respectively. For a summary of type support in the Java Virtual Machine's instruction set, see <a href="Overview.doc.html#7565">§3.11.1</a>.<p>
<a name="15118"></a>
The Java Virtual Machine contains explicit support for objects. An object is either a dynamically allocated class instance or an array. A reference to an object is considered to have Java Virtual Machine type <code>reference</code>. Values of type <code>reference</code> can be thought of as pointers to objects. More than one reference may exist to an object. Although the Java Virtual Machine performs operations on objects, it never addresses them directly. Objects are always operated on, passed, and tested via values of type <code>reference</code>. <p>
<a name="22239"></a>
<hr><h2>3.2 Primitive Types and Values</h2>
<a name="3560"></a>
The primitive data types supported by the Java Virtual Machine are the <i>numeric
types</i> and the <code>returnAddress</code> type. The numeric types consist of the <i>integral types</i>:
<p><ul><a name="3577"></a>
<li><code>byte</code>, whose values are 8-bit signed two's-complement integers
<a name="11455"></a>
<li><code>short</code>, whose values are 16-bit signed two's-complement integers
<a name="11456"></a>
<li><code>int</code>, whose values are 32-bit signed two's-complement integers
<a name="11457"></a>
<li><code>long</code>, whose values are 64-bit signed two's-complement integers
<a name="3601"></a>
<li><code>char</code>, whose values are 16-bit unsigned integers representing Unicode version 1.1.5 characters <a href="Concepts.doc.html#25310">(§2.1)</a>
</ul><a name="22892"></a>
and the <i>floating-point types</i>:
<p><ul><a name="11786"></a>
<li><code>float</code>, whose values are 32-bit IEEE 754 floating-point numbers
<a name="11787"></a>
<li><code>double</code>, whose values are 64-bit IEEE 754 floating-point numbers
</ul><a name="14456"></a>
The values of the <code>returnAddress</code> type are pointers to the opcodes of Java Virtual Machine instructions. Only the <code>returnAddress</code> type is not a Java language type.<p>
<a name="16125"></a>
<h3>3.2.1 Integral Types and Values</h3>
<a name="16126"></a>
The values of the integral types of the Java Virtual Machine are the same as those for
the integral types of the Java language <a href="Concepts.doc.html#19511">(§2.4.1)</a>:
<p><ul><a name="16139"></a>
<li>For <code>byte</code>, from -<code>128</code> to <code>127</code> (-27 to 27-1), inclusive
<a name="16140"></a>
<li>For <code>short</code>, from -<code>32768</code> to <code>32767</code> (-215 to 215-1), inclusive
<a name="16141"></a>
<li>For <code>int</code>, from -<code>2147483648</code> to <code>2147483647</code> (-231 to 231-1), inclusive
<a name="16142"></a>
<li>For <code>long</code>, from -<code>9223372036854775808</code> to <code>9223372036854775807</code> (-263 to 263-1), inclusive
<a name="16143"></a>
<li>For <code>char</code>, from <code>'u0000'</code> to <code>'uffff'</code>; <code>char</code> is unsigned, so <code>'uffff'</code> represents <code>65535</code> when used in expressions, not -<code>1</code>
</ul><a name="16133"></a>
<h3>3.2.2 Floating-Point Types and Values</h3>
<a name="15092"></a>
The values of the floating-point types of the Java Virtual Machine are the same as
those for the floating-point types of the Java language <a href="Concepts.doc.html#19511">(§2.4.1)</a>. The floating-point
types <code></code><code>float</code> and <code>double</code> represent single-precision 32-bit and double-precision 64-
bit format IEEE 754 values as specified in <i>IEEE Standard for Binary Floating-Point
Arithmetic</i>, ANSI/IEEE Std. 754-1985 (IEEE, New York).
<p><a name="15094"></a>
The IEEE 754 standard includes not only positive and negative sign-magnitude numbers, but also positive and negative zeroes, positive and negative <i>infinities</i>, and a special <i>Not-a-Number</i> (hereafter abbreviated NaN) value that is used to represent the result of certain operations such as dividing zero by zero. Such values exist for both <code>float</code> and <code>double</code> types.<p>
<a name="15097"></a>
The finite nonzero values of type <code>float</code> are of the form <i>s</i> xfa <i>m</i> xfa 2<i>e</i>, where <i>s</i> is +1 or -1, <i>m</i> is a positive integer less than 224, and <i>e</i> is an integer between -149 and 104, inclusive. The largest positive finite floating-point literal of type <code>float</code> is <code>3.40282347e+38F</code>. The smallest positive nonzero floating-point literal of type <code>float</code> is <code>1.40239846e</code>-<code>45F</code>.<p>
<a name="15098"></a>
The finite nonzero values of type <code>double</code> are of the form <i>s</i> xfa <i>m</i> xfa 2<i>e</i>, where <i>s</i> is +1 or -1, <i>m</i> is a positive integer less than 253, and <i>e</i> is an integer between -1075 and 970, inclusive. The largest positive finite floating-point literal of type <code>double</code> is <code>1.79769313486231570e+308</code>. The smallest positive nonzero floating-point literal of type <code>double</code> is <code>4.94065645841246544e</code>-<code>324</code>.<p>
<a name="15099"></a>
Floating-point positive zero and floating-point negative zero compare as equal, but there are other operations that can distinguish them; for example, dividing <code>1.0</code> by <code>0.0</code> produces positive infinity, but dividing <code>1.0</code> by <code>-0.0</code> produces negative infinity.<p>
<a name="15101"></a>
Except for NaN, floating-point values are <i>ordered</i>. When arranged from smallest to largest, they are negative infinity, negative finite values, negative zero, positive zero, positive finite values, and positive infinity.<p>
<a name="15103"></a>
NaN is <i>unordered</i>, so numerical comparisons have the value false if either or both of their operands are NaN. A test for numerical equality has the value false if either operand is NaN, and a test for numerical inequality has the value true if either operand is NaN. In particular, a test for numerical equality of a value against itself has the value false if and only if the value is NaN.<p>
<a name="16403"></a>
IEEE 754 defines a large number of distinct NaN values but fails to specify which NaN values are produced in various situations. To avoid portability problems, the Java Virtual Machine coalesces these NaN values together into a single conceptual NaN value.<p>
<a name="15107"></a>
<h3>3.2.3 The <code>returnAddress</code> Type and Values</h3>
<a name="15108"></a>
The <code>returnAddress</code> type is used by the Java Virtual Machine's <i>jsr</i>, <i>ret</i>, and <i>jsr_w</i>
instructions. The values of the <code>returnAddress</code> type are pointers to the opcodes
of Java Virtual Machine instructions. Unlike the numeric primitive types, the
<code>returnAddress</code> type does not correspond to any Java data type.
<p><a name="22909"></a>
<h3>3.2.4 There Is No <code>boolean</code> Type</h3>
<a name="22914"></a>
Although Java defines a <code>boolean</code> type, the Java Virtual Machine does not have
instructions dedicated to operations on <code>boolean</code> values. Instead, a Java expression
that operates on <code>boolean</code> values is compiled to use the <code>int</code> data type to represent
<code>boolean</code> variables.
<p><a name="22912"></a>
Although the Java Virtual Machine has support for the creation of arrays of type <code>boolean</code> (see the description of the <i>newarray</i> instruction), it does not have dedicated support for accessing and modifying elements of <code>boolean</code> arrays. Arrays of type <code>boolean</code> are accessed and modified using the <code>byte</code> array instructions.<a href="#24357"><sup>1</sup></a><p>
<a name="23440"></a>
For more information on the treatment of <code>boolean</code> values in the Java Virtual Machine, see Chapter <a href="Compiling.doc.html#2839">7</a>, <a href="Compiling.doc.html#2989">"Compiling for the Java Virtual Machine."</a><p>
<a name="15079"></a>
<hr><h2>3.3 Reference Types and Values</h2>
<a name="15127"></a>
There are three kinds of <code>reference</code> types: class types, interface types, and array
types, whose values are references to dynamically created class instances, arrays, or
class instances or arrays that implement interfaces. A <code>reference</code> value may also be
the special null reference, a reference to no object, which will be denoted here by
<code>null</code>. The <code>null</code> reference initially has no runtime type, but may be cast to any type
<a href="Concepts.doc.html#22930">(§2.4)</a>.
<p><a name="15881"></a>
<hr><h2>3.4 Words</h2>
<a name="15882"></a>
No mention has been made of the storage requirements for values of the various
Java Virtual Machine types, only the ranges those values may take. The Java Virtual Machine does not mandate the size of its data types. Instead, the Java Virtual
Machine defines an abstract notion of a <i>word</i> that has a platform-specific size. A
word is large enough to hold a value of type <code>byte</code>, <code>char</code>, <code>short</code>, <code>int</code>, <code>float</code>, <code>reference</code>, or <code>returnAddress</code>, or to hold a native pointer. Two words are large
enough to hold values of the larger types, <code>long</code> and <code>double</code>. Java's runtime data
areas are all defined in terms of these abstract words.
<p><a name="15883"></a>
A word is usually the size of a pointer on the host platform. On a 32-bit platform, a word is 32 bits, pointers are 32 bits, and <code>long</code>s and <code>double</code>s naturally take up two words. A naive 64-bit implementation of the Java Virtual Machine may waste half of a word used to store a 32-bit datum, but may also be able to store all of a <code>long</code> or a <code>double</code> in one of the two words allotted to it.<p>
<a name="15884"></a>
The choice of a specific word size, although platform-specific, is made at the implementation level, not as part of the Java Virtual Machine's design. It is not visible outside the implementation or to code compiled for the Java Virtual Machine.<p>
<a name="15885"></a>
Throughout this book, all references to a word datum are to this abstract notion of a word.<p>
<a name="1732"></a>
<hr><h2>3.5 Runtime Data Areas</h2>
<a name="6648"></a>
<h3>3.5.1 The <code>pc</code> Register</h3>
<a name="11384"></a>
A Java Virtual Machine can support many threads of execution at once <a href="Concepts.doc.html#24465">(§2.17)</a>.
Each Java Virtual Machine thread  has its own <code>pc</code> (program counter) register. At any
point, each Java Virtual Machine thread is executing the code of a single method,
the current method <a href="Overview.doc.html#17257">(§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 one word wide, the width guaranteed to hold a <code>returnAddress</code> or a
native pointer on the specific platform.
<p><a name="6654"></a>
<h3>3.5.2 Java Stack</h3>
<a name="15731"></a>
Each Java Virtual Machine thread <a href="Concepts.doc.html#24465">(§2.17)</a> has a private <i>Java stack</i>, created at the
same time as the thread. A Java stack stores Java Virtual Machine frames (<a href="Overview.doc.html#17257">§3.6)</a>.
The Java stack is equivalent 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 stack is never manipulated directly except to push and pop
frames, it may actually be implemented as a heap, and Java frames may be heap
allocated. The memory for a Java stack does not need to be contiguous.
<p><a name="22169"></a>
The Java Virtual Machine specification permits Java stacks to be of either a fixed or a dynamically varying size. If the Java stacks are of a fixed size, the size of each Java 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 stacks, as well as, in the case of dynamically expanding or contracting Java stacks, control over the maximum and minimum Java stack sizes. <p>
<a name="23152"></a>
The following exceptional conditions are associated with Java stacks:<p>
<ul><a name="21922"></a>
<li>If the computation in a thread requires a larger Java stack than is permitted, the Java Virtual Machine throws a <code>StackOverflowError</code>.
<a name="23127"></a>
<li>If Java stacks can be dynamically expanded, and Java stack 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 stack for a new thread, the Java Virtual Machine throws an <code>OutOfMemory</code>-<code>Error</code>.
</ul><a name="21864"></a>
In Sun's JDK 1.0.2 implementation of the Java Virtual Machine, the Java stacks are discontiguous and are independently expanded as required by the computation. The Java stacks do not contract, but are reclaimed when their associated thread terminates or is killed. Expansion is subject to a size limit for any one Java stack. The Java stack size limit may be set on virtual machine start-up using the "<code>-oss</code>" flag. The Java stack size limit can be used to limit memory consumption or to catch runaway recursions. <p>
<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 threads <a href="Concepts.doc.html#24465">(§2.17)</a>. The
heap is the runtime data area from which memory for all class instances and arrays
is allocated.
<p><a name="21949"></a>
The Java heap is created on virtual machine start-up. Heap storage for objects is reclaimed by an automatic storage management system (typically 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 Java 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 Java heap does not need to be contiguous. <p>
<a name="22930"></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.<p>
<a name="23145"></a>
The following exceptional condition is associated with the Java heap:<p>
<ul><a name="23149"></a>
<li>If a computation requires more Java heap than can be made available by the automatic storage management system, the Java Virtual Machine throws an <code>OutOfMemoryError</code>.
</ul><a name="21994"></a>
Sun's JDK 1.0.2 implementation of the Java Virtual Machine dynamically expands its Java heap as required by the computation, but never contracts its heap. Its initial and maximum sizes may be specified on virtual machine start-up using the "<code>-ms</code>" and "<code>-mx</code>" flags, respectively. <p>
<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 threads
<a href="Concepts.doc.html#24465">(§2.17)</a>. The method area is analogous to the storage area for compiled code of a
conventional language, or to the "text" segment in a UNIX process. It stores per-
class structures such as the constant pool, field and method data, and the code for
methods and constructors, including the special methods <a href="Overview.doc.html#12174">(§3.8)</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 garbage-collected heap, simple implementations may choose to neither garbage collect nor 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.<p>
<a name="23163"></a>
The following exceptional condition is associated with the method area:<p>
<ul><a name="22069"></a>
<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="22050"></a>
Sun's JDK 1.0.2 implementation of the Java Virtual Machine dynamically expands its method are as required by the computation, but never contracts. No user control over the maximum or minimum size of the method area is provided.<p>
<a name="22972"></a>
<h3>3.5.5 Constant Pool</h3>
<a name="22973"></a>
A <i>constant pool</i> is a per-class or per-interface runtime representation of the
<code>constant_pool</code> table in a Java <code>class</code> file (<a href="ClassFile.doc.html#20080">§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 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 constant pool is allocated from the Java Virtual Machine's method area <a href="Overview.doc.html#6656">(§3.5.4)</a>. The constant pool for a class or interface is created when a Java <code>class</code> file for the class or interface is successfully loaded <a href="Concepts.doc.html#19175">(§2.16.2)</a> by a Java Virtual Machine. <p>
<a name="23215"></a>
The following exceptional condition is associated with the creation of the constant pool for a class or interface:<p>
<ul><a name="23220"></a>
<li>When loading a <code>class</code> file, if the creation of the 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>
Constant pool resolution, a runtime operation performed on entries in the constant pool, has its own set of associated exceptions. See Chapter <a href="ConstantPool.doc.html#67469">5</a> for information about the runtime management of the constant pool.<p>
<a name="15637"></a>
<h3>3.5.6 Native Method Stacks</h3>
<a name="17255"></a>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -