chap05.html

Inside the java virtualMachine,深入研究java虚拟机

<FONT FACE="Courier New"><P>java Echo Greetings, Planet.</P>
</FONT><P><FONT FACE="Courier New">end</FONT></P>
<P>The first word in the command, &quot;<FONT FACE="Courier New">java</FONT>,&quot; indicates that the Java Virtual Machine from Sun韘 JDK should be run by the operating system. The second word, &quot;<FONT FACE="Courier New">Echo</FONT>,&quot; is the name of the initial class. <FONT FACE="Courier New">Echo</FONT> must have a public static method named <FONT FACE="Courier New">main()</FONT> that returns <FONT FACE="Courier New">void</FONT> and takes a <FONT FACE="Courier New">String</FONT> array as its only parameter. The subsequent words, &quot;<FONT FACE="Courier New">Greetings, Planet.</FONT>,&quot; are the command line arguments for the application. These are passed to the <FONT FACE="Courier New">main()</FONT> method in the <FONT FACE="Courier New">String</FONT> array in the order in which they appear on the command line. So, for the above example, the contents of the <FONT FACE="Courier New">String</FONT> array passed to main in <FONT FACE="Courier New">Echo</FONT> are:</P>
<P><FONT FACE="Courier New">arg[0]</FONT> is <FONT FACE="Courier New">"Greetings,"</FONT></P>
<P><FONT FACE="Courier New">arg[1]</FONT> is <FONT FACE="Courier New">"Planet."</FONT></P>
<P>The <FONT FACE="Courier New">main()</FONT> method of an application韘 initial class serves as the starting point for that application韘 initial thread. The initial thread can in turn fire off other threads.</P>
<P>Inside the Java Virtual Machine, threads come in two flavors: <I>daemon</I> and <I>non-daemon</I>. A daemon thread is ordinarily a thread used by the virtual machine itself, such as a thread that performs garbage collection. The application, however, can mark any threads it creates as daemon threads. The initial thread of an application--the one that begins at <FONT FACE="Courier New">main()</FONT>--is a non-daemon thread.</P>
<P>A Java application continues to execute (the virtual machine instance continues to live) as long as any non-daemon threads are still running. When all non-daemon threads of a Java application terminate, the virtual machine instance will exit. If permitted by the security manager, the application can also cause its own demise by invoking the <FONT FACE="Courier New">exit()</FONT> method of class <FONT FACE="Courier New">Runtime</FONT> or <FONT FACE="Courier New">System</FONT>.</P>
<P>In the <FONT FACE="Courier New">Echo</FONT> application above, the <FONT FACE="Courier New">main()</FONT> method doesn韙 invoke any other threads. After it prints out the command line arguments, <FONT FACE="Courier New">main()</FONT> returns. This terminates the application韘 only non-daemon thread, which causes the virtual machine instance to exit.</P>
<H3><EM><P>The Architecture of the Java Virtual Machine</P>
</EM></H3><P>In the Java Virtual Machine specification, the behavior of a virtual machine instance is described in terms of subsystems, memory areas, data types, and instructions. These components describe an abstract inner architecture for the abstract Java Virtual Machine. The purpose of these components is not so much to dictate an inner architecture for implementations. It is more to provide a way to strictly define the external behavior of implementations. The specification defines the required behavior of any Java Virtual Machine implementation in terms of these abstract components and their interactions.</P>
<P>Figure 5-1 shows a block diagram of the Java Virtual Machine that includes the major subsystems and memory areas described in the specification. As mentioned in previous chapters, each Java Virtual Machine has a <I>class loader subsystem</I>: a mechanism for loading types (classes and interfaces) given fully qualified names. Each Java Virtual Machine also has an <I>execution engine</I>: a mechanism responsible for executing the instructions contained in the methods of loaded classes.</P>
<P><IMG SRC="fig5-1.gif" tppabs="http://www.pbg.mcgraw-hill.com/betabooks/venners/images/fig5-1.gif" ALT="Figure 5-1"></P>

<P>When a Java Virtual Machine runs a program, it needs memory to store many things, including bytecodes and other information it extracts from loaded class files, objects the program instantiates, parameters to methods, return values, local variables, and intermediate results of computations. The Java Virtual Machine organizes the memory it needs to execute a program into several <I>runtime data areas</I>.</P>
<P>Although the same runtime data areas exist in some form in every Java Virtual Machine implementation, their specification is quite abstract. Many decisions about the structural details of the runtime data areas are left to the designers of individual implementations.</P>
<P>Different implementations of the virtual machine can have very different memory constraints. Some implementations may have a lot of memory in which to work, others may have very little. Some implementations may be able to take advantage of virtual memory, others may not. The abstract nature of the specification of the runtime data areas helps make it easier to implement the Java Virtual Machine on a wide variety of computers and devices.</P>
<P>Some runtime data areas are shared among all of an application韘 threads and others are unique to individual threads. Each instance of the Java Virtual Machine has one <I>method area</I> and one <I>heap</I>. These areas are shared by all threads running inside the virtual machine. When the virtual machine loads a class file, it parses information about a type from the binary data contained in the class file. It places this type information into the method area. As the program runs, the virtual machine places all objects the program instantiates onto the heap. See Figure 5-2 for a graphical depiction of these memory areas.</P>
<P><IMG SRC="fig5-2.gif" tppabs="http://www.pbg.mcgraw-hill.com/betabooks/venners/images/fig5-2.gif" ALT="Figure 5-2"></P>

<P>As each new thread comes into existence, it gets its own <I>pc register</I> (program counter) and <I>Java stack</I>. If the thread is executing a Java method (not a native method), the value of the pc register indicates the next instruction to execute. A thread韘 Java stack stores the state of Java (not native) method invocations for the thread. The state of a Java method invocation includes its local variables, the parameters with which it was invoked, its return value (if any), and intermediate calculations. The state of native method invocations is stored in an implementation-dependent way in <I>native method stacks</I>, as well as possibly in registers or other implementation-dependent memory areas.</P>
<P>The Java stack is composed of <I>stack frames</I> (or <I>frames</I>). A stack frame contains the state of one Java method invocation. When a thread invokes a method, the Java Virtual Machine pushes a new frame onto that thread韘 Java stack. When the method completes, the virtual machine pops and discards the frame for that method.</P>
<P>The Java Virtual Machine has no registers to hold intermediate data values. The instruction set uses the Java stack for storage of intermediate data values. This approach was taken by Java韘 designers to keep the Java Virtual Machine's instruction set compact and to facilitate implementation on architectures with few or irregular general purpose registers.</P>
<P>See Figure 5-3 for a graphical depiction of the memory areas the Java Virtual Machine creates for each thread. These areas are private to the owning thread. No thread can access the pc register or Java stack of another thread.</P>
<P><IMG SRC="fig5-3.gif" tppabs="http://www.pbg.mcgraw-hill.com/betabooks/venners/images/fig5-3.gif" ALT="Figure 5-3"></P>

<P>Figure 5-3 shows a snapshot of a virtual machine instance in which three threads are executing. At the instant of the snapshot, threads one and two are executing Java methods. Thread three is executing a native method.</P>
<P>In Figure 5-3, as in all graphical depictions of the Java stack in this book, the stacks are shown growing downwards. The &quot;top&quot; of each stack is shown at the bottom of the figure. Stack frames for currently executing methods are shown in a lighter shade. For threads that are currently executing a Java method, the pc register indicates the next instruction to execute. In Figure 5-3, such pc registers (the ones for threads one and two) are shown in a lighter shade. Because thread three is currently executing a native method, the contents of its pc register--the one shown in dark gray--is undefined.</P>
<H3><P>Data Types</P>
</H3><P>The Java Virtual Machine computes by performing operations on certain types of data. Both the data types and operations are strictly defined by the Java Virtual Machine specification. The data types can be divided into a set of <I>primitive types</I> and a <I>reference type</I>. Variables of the primitive types hold <I>primitive values</I>, and variables of the reference type hold <I>reference values</I>. Reference values refer to objects, but are not objects themselves. Primitive values, by contrast, do not refer to anything. They are the actual data themselves. You can see a graphical depiction of the Java Virtual Machine韘 families of data types in Figure 5-4.</P>
<P><IMG SRC="fig5-4.gif" tppabs="http://www.pbg.mcgraw-hill.com/betabooks/venners/images/fig5-4.gif" ALT="Figure 5-4"></P>

<P>All the primitive types of the Java programming language, except <FONT FACE="Courier New">boolean</FONT>, are primitive types of the Java Virtual Machine. When a compiler translates Java source code into bytecodes, it uses <FONT FACE="Courier New">int</FONT>s or <FONT FACE="Courier New">byte</FONT>s to represent <FONT FACE="Courier New">boolean</FONT>s. In the Java Virtual Machine, <FONT FACE="Courier New">false</FONT> is represented by integer zero and <FONT FACE="Courier New">true</FONT> by any non-zero integer. Operations involving <FONT FACE="Courier New">boolean</FONT> values use <FONT FACE="Courier New">int</FONT>s. Arrays of <FONT FACE="Courier New">boolean</FONT> are accessed as arrays of <FONT FACE="Courier New">byte</FONT>, though they may be represented on the heap as arrays of <FONT FACE="Courier New">byte</FONT> or as bit fields.</P>
<P>The primitive types of the Java programming language other than <FONT FACE="Courier New">boolean</FONT> form the <I>numeric types </I>of the Java Virtual Machine. The numeric types are divided between the <I>integral types</I>: <FONT FACE="Courier New">byte</FONT>, <FONT FACE="Courier New">short</FONT>, <FONT FACE="Courier New">int</FONT>, <FONT FACE="Courier New">long</FONT>, and <FONT FACE="Courier New">char</FONT>, and the<I> floating-point types</I>: <FONT FACE="Courier New">float</FONT> and <FONT FACE="Courier New">double</FONT>. As with the Java programming language, the primitive types of the Java Virtual Machine have the same range everywhere. A <FONT FACE="Courier New">long</FONT> in the Java Virtual Machine always acts like a 64-bit signed twos complement number, independent of the underlying host platform.</P>
<P>The Java Virtual Machine works with one other primitive type that is unavailable to the Java programmer: the <FONT FACE="Courier New">returnValue</FONT> type. This primitive type is used to implement <FONT FACE="Courier New">finally</FONT> clauses of Java programs. The use of the <FONT FACE="Courier New">returnValue</FONT> type is described in detail in Chapter 18, &quot;Finally Clauses.&quot;</P>
<P>The reference type of the Java Virtual Machine is cleverly named <FONT FACE="Courier New">reference</FONT>. Values of type <FONT FACE="Courier New">reference</FONT> come in three flavors: the <I>class type</I>, the <I>interface type</I>, and the <I>array type</I>. All three types have values that are references to dynamically created objects. The class type韘 values are references to class instances. The array type韘 values are references to arrays, which are full-fledged objects in the Java Virtual Machine. The interface type韘 values are references to class instances that implement an interface. One other reference value is the <FONT FACE="Courier New">null</FONT> value, which indicates the <FONT FACE="Courier New">reference</FONT> variable doesn韙 refer to any object.</P>
<P>The Java Virtual Machine specification defines the range of values for each of the data types, but does not define their sizes. The number of bits used to store each data type value is a decision of the designers of individual implementations. The ranges of the Java Virtual Machines data type韘 are shown in Table 5-1. More information on the floating point ranges is given in Chapter 14, &quot;Floating Point Arithmetic.&quot;</P>
<P>Table 5-1. Ranges of the Java Virtual Machine韘 data types</P>
<P><TABLE WIDTH="500">
<TR><TD VALIGN="TOP"><STRONG>Type</STRONG></TD><TD VALIGN="TOP"><STRONG>Range</STRONG></TD></TR>
<TR><TD VALIGN="TOP"><FONT FACE="Courier New">byte</FONT></TD><TD VALIGN="TOP">8-bit signed two's complement integer (-2<SUP>7</SUP> to 2<SUP>7</SUP> - 1, inclusive)</TD></TR>
<TR><TD VALIGN="TOP"><FONT FACE="Courier New">short</FONT></TD><TD VALIGN="TOP">16-bit signed two's complement integer (-2<SUP>15</SUP> to 2<SUP>15</SUP> - 1, inclusive)</TD></TR>
<TR><TD VALIGN="TOP"><FONT FACE="Courier New">int</FONT></TD><TD VALIGN="TOP">32-bit signed two's complement integer (-2<SUP>31</SUP> to 2<SUP>31</SUP> - 1, inclusive)</TD></TR>
<TR><TD VALIGN="TOP"><FONT FACE="Courier New">long</FONT></TD><TD VALIGN="TOP">64-bit signed two's complement integer (-2<SUP>63</SUP> to 2<SUP>63</SUP> - 1, inclusive)</TD></TR>
<TR><TD VALIGN="TOP"><FONT FACE="Courier New">char</FONT></TD><TD VALIGN="TOP">16-bit unsigned Unicode character (0 to 2<SUP>16 </SUP>- 1, inclusive)</TD></TR>
<TR><TD VALIGN="TOP"><FONT FACE="Courier New">float</FONT></TD><TD VALIGN="TOP">32-bit IEEE 754 single-precision float</TD></TR>
<TR><TD VALIGN="TOP"><FONT FACE="Courier New">double</FONT></TD><TD VALIGN="TOP">64-bit IEEE 754 double-precision float</TD></TR>
<TR><TD VALIGN="TOP"><FONT FACE="Courier New">returnValue</FONT></TD><TD VALIGN="TOP">address of an opcode within the same method</TD></TR>
<TR><TD VALIGN="TOP"><FONT FACE="Courier New">reference</FONT></TD><TD VALIGN="TOP">reference to an object on the heap, or <FONT FACE="Courier New">null</FONT></TD></TR>
</TABLE>
<H3><P>Word Size</P>
</H3><P>The basic unit of size for data values in the Java Virtual Machine is the <I>word</I>--a fixed size chosen by the designer of each Java Virtual Machine implementation. The word size must be large enough to hold a value of type <FONT FACE="Courier New">byte</FONT>, <FONT FACE="Courier New">short</FONT>, <FONT FACE="Courier New">int</FONT>, <FONT FACE="Courier New">char</FONT>, <FONT FACE="Courier New">float</FONT>, <FONT FACE="Courier New">returnValue</FONT>, or <FONT FACE="Courier New">reference</FONT>. Two words must be large enough to hold a value of type <FONT FACE="Courier New">long</FONT> or <FONT FACE="Courier New">double</FONT>. An implementation designer must therefore choose a word size that is at least 32 bits, but otherwise can pick whatever word size will yield the most efficient implementation. The word size is often chosen to be the size of a native pointer on the host platform.</P>
<P>The specification of many of the Java Virtual Machine韘 runtime data areas are based upon this abstract concept of a word. For example, two sections of a Java stack frame--the local variables and operand stack--are defined in terms of words. These areas can contain values of any of the virtual machine韘 data types. When placed into the local variables or operand stack, a value occupies either one or two words.</P>
<P>As they run, Java programs cannot determine the word size of their host virtual machine implementation. The word size does not affect the behavior of a program. It is only an internal attribute of a virtual machine implementation.</P>
<H3><P>The Class Loader Subsystem</P>
</H3><P>The part of a Java Virtual Machine implementation that takes care of finding and loading types is the <I>class loader subsystem</I>. Chapter 1, &quot;Introduction to Java韘 Architecture,&quot; gives an overview of this subsystem. Chapter 3, &quot;Security,&quot; shows how the subsystem fits into Java韘 security model. This chapter describes the class loader subsystem in more detail and show how it relates to the other components of the virtual machine韘 internal architecture.</P>