Java语法（四）JVM Spec (3) Structure

摘自The Java^TM Virtual Machine Specification

 

 

3.1 Data Types        数据在内存中是一堆二进制字符串，指定类型后，按照类型规则解析后，值才能确定

        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 reference. 

        The returnAddress type is used by the Java Virtual Machine's jsr, ret, and jsr_w instructions. The values of the returnAddress type are pointers to the opcodes of Java Virtual Machine instructions. 并且它的值是不能被运行中的程序所修改的。Unlike the numeric primitive types, the returnAddress type does not correspond to（不符合） any Java data type. 

        JVM为运行一个程序定义了几种数据区(Data Area)，包括：pc寄存器、JVM堆栈、堆、方法区(Method Area)、运行时常量池(Runtime Constant Pool)以及本机方法堆栈(Native Method Stacks)，

        The values of the returnAddress type are pointers to the opcodes of Java Virtual Machine instructions. Only the returnAddress type is not a Java language type.

 

3.4 Words

        A word is large enough to hold a value of type byte, char, short, int, float, reference, or returnAddress, or to hold a native pointer. Two words are large enough to hold values of the larger types, long and double. Java's runtime data areas are all defined in terms of these abstract words.         

        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 longs and doubles naturally take up two words. (***重点***)        

 

3.5.1 The pc Register

        Each Java Virtual Machine thread has its own pc (program counter) register. At any point, each Java Virtual Machine thread is executing the code of a single method。

        If that method is not native, the pc register contains the address of the Java Virtual Machine instruction currently being executed. 

        If the method currently being executed by the thread is native, the value of the Java Virtual Machine's pc register is undefined. 

        The Java Virtual Machine's pc register is one word wide, the width guaranteed to hold a returnAddress or a native pointer on the specific platform. 

 

 

3.5.2 Java Stack

        Each Java Virtual Machine thread (§2.17) has a private Java stack, created at the same time as the thread. A Java stack stores Java Virtual Machine frames (§3.6). 

        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. 

        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. 

 

        The following exceptional conditions are associated with Java stacks:

                If the computation in a thread requires a larger Java stack than is permitted, the Java Virtual Machine throws a StackOverflowError. 

                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 OutOfMemoryError. 

                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 "-oss" flag. The Java stack size limit can be used to limit memory consumption or to catch runaway recursions.         

 

3.5.3 Heap

        The Java Virtual Machine has a heap that is shared among all threads (§2.17). The heap is the runtime data area from which memory for all class instances and arrays is allocated. 

        The Java heap is created on virtual machine start-up. Heap storage for objects is reclaimed by an automatic storage management system (typically a garbage collector); 

        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. 

 

        The following exceptional condition is associated with the Java heap:

                If a computation requires more Java heap than can be made available by the automatic storage management system, the Java Virtual Machine throws an OutOfMemoryError. 

                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 "-ms" and "-mx" flags, respectively. 

 

3.5.4 Method Area

        The Java Virtual Machine has a method area that is shared among all threads (§2.17). 

        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 (§3.8) used in class and instance initialization and interface type initialization. 

        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连续. 

        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.

        The following exceptional condition is associated with the method area:

                If memory in the method area cannot be made available to satisfy满意的 an allocation request, the Java Virtual Machine throws an OutOfMemoryError. 

                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.

 

3.5.5 Constant Pool

        A constant pool is a per-class or per-interface runtime representation of the constant_pool table in a Java class file (§4.4). 

        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. 

        Each constant pool is allocated from the Java Virtual Machine's method area (§3.5.4). The constant pool for a class or interface is created when a Java class file for the class or interface is successfully loaded (§2.16.2) by a Java Virtual Machine. 

 

3.5.6 Native Method Stacks

        An implementation of the Java Virtual Machine may use conventional stacks, colloquially called "C stacks," to support native methods, methods written in languages other than Java. 

        A native method stack may also be used to implement an emulator for the Java Virtual Machine's instruction set in a language such as C. 

        Implementations that do not support native methods, and that do not themselves rely on conventional stacks, need not supply native method stacks. If supplied, native method stacks are typically allocated on a per thread basis when each thread is created. 

        The Java Virtual Machine specification permits native method stacks to be of either a fixed or a dynamically varying size. 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.

 

 

 

3.6 Frames（？？？？？什么意思）

A Java Virtual Machine frame is used to store data and partial局部 results, as well as to perform dynamic linking, to return values for methods, and to dispatch派遣 exceptions. 

A new frame is created each time a Java method is invoked. A frame is destroyed when its method completes, whether that completion is normal or abnormal (by throwing an exception). Frames are allocated from the Java stack (§3.5.2) of the thread creating the frame. Each frame has its own set of local variables (§3.6.1) and its own operand stack (§3.6.2). 

Note that (请注意)a frame created by a thread is local to that thread and cannot be directly referenced by any other thread.

 

3.6.1 Local Variables

        On each Java method invocation, the Java Virtual Machine allocates a Java frame (§3.6), which contains an array of words known as its local variables. Local variables are addressed as word offsets from the base of that array.

3.6.2 Operand Stacks

 

        On each Java method invocation, the Java Virtual Machine allocates a Java frame (§3.6), which contains an operand stack. Most Java Virtual Machine instructions take values from the operand stack of the current frame, operate on them, and return results to that same operand stack. The operand stack is also used to pass arguments to methods and receive method results. 

 

3.6.3 Dynamic Linking

        A Java Virtual Machine frame contains a reference to the constant pool for the type of the current method to support dynamic linking of the method code. The class 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. 

3.6.4 Normal Method Completion

A method invocation completes normally if that invocation does not cause an exception (§2.15, §3.9) to be thrown, either directly from the Java Virtual Machine or as a result of executing an explicit throw statement.

3.6.5 Abnormal Method Completion

 

3.11 Instruction Set Summary

A Java Virtual Machine instruction consists（包含） of a one-byte opcode specifying the operation to be performed, followed by zero or more operands supplying arguments or data that are used by the operation. Many instructions have no operands操作数 and consist only of an opcode操作码. 

 

 

 

opcode          int                float                 reference  

Tload            iload          fload                aload          //Load a local variable onto the operand stack

Tstore        store                fstore        astore  //Store a value from the operand stack into a local variable

Tipush  bipush  sipush                        //Load a constant onto the operand stack

//Load a constant onto the operand stack: bipush, sipush, ldc, ldc_w,, iconst_<i>, fconst_<f>

//Arithmetic Instructions

        Add: iadd, ladd, fadd, dadd. 

        Subtract: isub, lsub, fsub, dsub. 

        Multiply: imul, lmul, fmul, dmul. 

        Divide: idiv, ldiv, fdiv, ddiv. 

        Remainder: irem, lrem, frem, drem. 余数

        Negate: ineg, lneg, fneg, dneg. 非

        Shift: ishl, ishr, iushr, lshl, lshr, lushr. 移动

        Bitwise OR: ior, lor. 按位取或

        Bitwise AND: iand, land. 按位取与

        Bitwise exclusive OR: ixor, lxor. 按位取异或（排斥的或）

        Local variable increment: iinc. 

 

3.11.5 Object Creation and Manipulation

Although both class instances and arrays are objects, the Java Virtual Machine creates and manipulates class instances and arrays using distinct sets of instructions: 

        Create a new class instance: new. 

        Create a new array: newarray, anewarray, multianewarray. 

        Access fields of classes (static fields, known as class variables) and fields of class instances (non-static fields, known as instance variables): getfield, putfield, getstatic, putstatic. 

        Load an array component onto the operand stack: baload, caload, saload, iaload, laload, faload, daload, aaload. 

        Store a value from the operand stack as an array component: bastore, castore, sastore, iastore, lastore, fastore, dastore, aastore. 

        Get the length of array: arraylength. 

        Check properties of class instances or arrays: instanceof, checkcast. 

3.11.6 Operand Stack Management Instructions

A number of instructions are provided for the direct manipulation of the operand stack: pop, pop2, dup, dup2, dup_x1, dup2_x1, dup_x2, dup2_x2, swap. 

Tconst    iconst  lconst  fconst  dconst   aconst          

 

3.11.7 Control Transfer Instructions（控制转移指令，if else switch等）

        The control transfer instructions conditionally or unconditionally cause the Java Virtual Machine to continue execution with an instruction other than the one following the control transfer instruction. They are: 

        Conditional branch: ifeq, iflt, ifle, ifne, ifgt, ifge, ifnull, ifnonnull, if_icmpeq, if_icmpne, if_icmplt, if_icmpgt, if_icmple, if_icmpge, if_acmpeq, if_acmpne, lcmp, fcmpl, fcmpg, dcmpl, dcmpg. 

        Compound conditional branch: tableswitch, lookupswitch. 

        Unconditional branch: goto, goto_w, jsr, jsr_w, ret. 

 

3.11.8 Method Invocation and Return Instructions

        Four instructions invoke methods: 

        Invoke an instance method of an object, dispatching on the (virtual) type of the object: invokevirtual. This is the normal method dispatch in Java. 

        Invoke a method that is implemented by an interface, searching the methods implemented by the particular runtime object to find the appropriate method: invokeinterface. 

        Invoke an instance method requiring special handling, either an instance initialization method <init>, a private method, or a superclass method: invokespecial. 

        Invoke a class (static) method in a named class: invokestatic. 

        The method return instructions, which are distinguished by return type, are ireturn (used to return values of type byte, char, short, or int), lreturn, freturn, dreturn, and areturn. In addition, the return instruction is used to return from methods declared to be void. 

 

3.12 Public Design, Private Implementation

        It is important to understand where the line between the public design and the private implementation lies. The Java Virtual Machine must be able to read class files, and it must exactly implement the semantics of the Java Virtual Machine code therein. One way of doing this is to take this document as a specification and to implement that specification literally. But it is also perfectly feasible and desirable for the implementor to modify or optimize the implementation within the constraints of this specification. So long as the class file format can be read, and the semantics of its code are maintained-维持, the implementor may implement these semantics in any way. What is "under the hood" is the implementor's business, as long as the correct external interface is carefully maintained