Shulou(Shulou.com)06/03 Report--

1 Overview

It is well known that Java supports platform independence, security, and network mobility. The Java platform is composed of Java virtual machine and Java core class, which provides a unified programming interface for pure Java programs, regardless of the underlying operating system. Thanks to the Java virtual machine, its so-called "compile once, run everywhere" can be guaranteed.

1.1 Java program execution process

The execution of Java programs depends on the compilation environment and the running environment. The source code is transformed into executable machine code, which is accomplished by the following process:

The core of Java technology is the Java virtual machine, because all Java programs run on the virtual machine. The operation of Java program requires the cooperation of Java virtual machine, Java API and Java Class files. The Java virtual machine instance is responsible for running a Java program. When you start a Java program, a virtual machine instance is born. When the program ends, the virtual machine instance dies.

Java is cross-platform because it has virtual machines for different platforms.

1.2 Java virtual machine

The main task of the Java virtual machine is to load the class file and execute the bytecode in it. As you can see from the following figure, the Java virtual machine contains a class loader (class loader) that loads class files from programs and API. In Java API, only the classes needed for program execution are loaded, and the bytecode is executed by the execution engine.

When the Java virtual machine is implemented by software on the host operating system, the Java program interacts with the host by calling local methods. The Java method is written in Java language, compiled into bytecode, and stored in the class file. Local methods are written in C/C++/ assembly language, compiled into processor-related machine code, stored in a dynamic link library, and are platform-specific. So the local method is to contact the connection between the Java program and the underlying host operating system.

Because the Java virtual machine does not know how a class file is created or whether it has been tampered with, it implements a class file detector to ensure that the types defined in the class file can be used safely. The class file verifier ensures program robustness through four separate scans:

Structure check of class file

Semantic checking of type data

Bytecode verification

Symbol reference verification

The Java virtual machine also performs other built-in security operations when executing bytecode, which is not only a feature of the Java programming language to ensure the robustness of Java programs, but also a feature of the Java virtual machine:

Type-safe reference conversion

Structured memory access

Automatic garbage collection

Array boundary check

Null reference check

1.3 Java virtual machine data type

The Java virtual machine performs calculations through certain data types. Data types can be divided into two types: basic types and reference types, as shown in the following figure:

But boolean is a bit special. When the compiler compiles Java source code to bytecode, it uses int or byte to represent boolean. In the Java virtual machine, false is represented by 0, while true is represented by all non-zero integers. Like the Java language, the range of the basic types of Java virtual machines is consistent everywhere, and a long is always a 64-bit binary complement signed integer in any virtual machine, regardless of the host platform.

For returnAddress, this primitive type is used to implement the finally clause in Java programs, which Java programmers cannot use, whose value points to the opcode of a virtual machine instruction.

2 architecture

In the Java virtual machine specification, the behavior of a virtual machine instance is described according to subsystem, memory area, data type and instruction respectively, which together show the internal architecture of the abstract virtual machine.

2.1 class Fil

The Java class file contains all the information about the class or interface. The "basic types" of class files are as follows:

U1 1 bytes, unsigned type

U2 2 bytes, unsigned type

U4 4 bytes, unsigned type

U8 8 bytes, unsigned type

For more information, Oracle's JVM SE7 gives the official specification: The Java ®Virtual Machine Specification

The class file contains:

ClassFile {

U4 magic; / / magic number: 0xCAFEBABE, used to determine whether it is a Java class file

U2 minor_version; / / minor version number

U2 major_version; / / Major version number

U2 constant_pool_count; / / constant pool size

Cp_info constant_ Pool [constant _ pool_count-1]; / / constant pool

U2 access_flags; / / class and interface level access flags (obtained by | operation)

U2 this_class; / / class index (points to class constants in the constant pool)

U2 super_class; / / parent index (points to class constants in the constant pool)

U2 interfaces_count; / / interface index counter

U2 interfaces [interfaces _ count]; / / Collection of interface indexes

U2 fields_count; / / Field quantity counter

Field_info fields [fields _ count]; / / Collection of field tables

U2 methods_count; / / method quantity counter

Method_info methods [methods _ count]; / / method table collection

U2 attributes_count; / / number of attributes

Attribute_info attributes [attributes _ count]; / / attribute table

}

2.2 Class Loader Subsystem

The class loader subsystem is responsible for finding and loading type information. In fact, there are two types of loaders for Java virtual machines: system loaders and user-defined loaders. The former is part of the Java virtual machine implementation, and the latter is part of the Java program.

Startup class loader (bootstrap class loader): the core library used to load Java is implemented in native code and does not inherit from java.lang.ClassLoader.

Extension class loader (extensions class loader): it is used to load the extension library of Java. The implementation of the Java virtual machine provides an extended library directory. The class loader looks for and loads the Java class in this directory.

Application class loader (application class loader): it loads the Java class based on the classpath (CLASSPATH) of the Java application. Generally speaking, it loads all the classes of Java applications. You can get it through ClassLoader.getSystemClassLoader ().

In addition to the class loader provided by the system, developers can implement their own class loader by inheriting the java.lang.ClassLoader class to meet some special needs.

The class loader subsystem involves several other components of the Java virtual machine as well as classes from the java.lang library. The methods defined by ClassLoader provide the program with an interface to access the classloader mechanism. In addition, for each loaded type, the Java virtual machine creates an instance of the java.lang.Class class for it to represent that type. Like other objects, the user-defined class loader and instances of the Class class are placed in the heap area in memory, while the loaded type information is in the method area.

In addition to locating and importing binary class files, the class loader subsystem must also be responsible for verifying the correctness of imported classes, allocating and initializing memory for class variables, and parsing symbolic references. These actions also need to be performed in the following order:

Load (find and load type binary data)

Join (perform validation: ensure the correctness of the imported type; prepare: allocate memory for class variables and initialize them to default values; parse: convert symbolic references in types to direct references)

Initialization (class variable initialization to the correct initial value)

2.3 method area

In the Java virtual machine, information about the type being loaded is stored in memory in a method area. When a virtual machine loads a type, it uses a class loader to locate the corresponding class file, then reads the class file and transfers it to the virtual machine, where the virtual machine extracts the type information and stores it in the method area. The method area can also be collected by the garbage collector because the virtual machine allows Java programs to be dynamically extended through user-defined class loaders.

The following information is stored in the method area:

The fully qualified name of this type (such as the fully qualified name java.lang.Object)

The fully qualified name of the direct superclass of this type

Is this type a class type or an interface type?

This type of access modifier (a subset of public, abstract, final)

An ordered list of fully qualified names of any direct hyperinterface

This type of constant pool (an ordered collection, including direct constants [string, integer, and floating point constants] and symbolic references to other types, fields, and methods)

Field information (field name, type, modifier)

Method information (method name, return type, number and type of parameters, modifiers)

All class (static) variables except constants

Reference to the ClassLoader class (when each type is loaded, the virtual machine must track whether it is loaded by the startup class loader or by the user-defined class loader)

A reference to the Class class (for each loaded type, the virtual machine creates an instance of the java.lang.Class class for it accordingly. For example, if you have a reference to an object of the java.lang.Integer class, you only need to call the getClass () method of the Integer object reference to get the Class object that represents the java.lang.Integer class.)

2.4 heap

All class instances or arrays created by the Java program at run time (the array is a real object in the Java virtual machine) are placed in the same heap. Because the Java virtual machine instance has only one heap space, all threads will share the heap. It should be noted that the Java virtual machine has an instruction to allocate objects in the heap, but no instruction to free memory, because the virtual machine leaves the task to the garbage collector. The Java virtual machine specification does not enforce the garbage collector, it only requires the virtual machine implementation to manage its own heap space "in some way". For example, an implementation may have only a fixed size of heap space, and when the space is filled, it simply throws an OutOfMemory exception without considering the problem of recycling garbage objects, but it conforms to the specification.

The Java virtual machine specification does not specify how Java objects are represented in the heap, which leaves it to the virtual machine implementer to decide how to design. A possible heap design is as follows:

A handle pool, an object pool. A reference to an object is a local pointer to the handle pool. The benefits of this design are good for defragmentation. When moving objects in the object pool, the handle part only needs to change the pointer to the new address of the object. The disadvantage is that each time the instance variable of the object is accessed, it is passed through a pointer twice.

2.5 Java stack

Each time it is started to a thread, the Java virtual machine assigns it a Java stack. The Java stack consists of many stack frames, and one stack frame contains the state of a Java method call. When a thread calls a Java method, the virtual machine pushes a new stack frame into the thread's Java stack, and when the method returns, the stack frame pops up from the Java stack. The Java stack stores the state of the Java method call in the thread-- including local variables, parameters, return values, and intermediate results of operations. The Java virtual machine does not have registers, and its instruction set uses the Java stack to store intermediate data. The reason for this design is to keep the instruction set of the Java virtual machine as compact as possible, and to facilitate the implementation of the Java virtual machine on a platform with few general registers. In addition, the stack-based architecture is also helpful to the code optimization of dynamic compilers and just-in-time compilers implemented by some virtual machines at run time.

2.5.1 Stack Fram

The stack frame consists of a local variable area, an Operand stack and a frame data area. When the virtual machine calls a Java method, it gets the local variable area and Operand stack size of the method from the type information of the corresponding class, allocates the stack frame memory according to this, and then presses it into the Java stack.

2.5.1.1 Local variable area

The local variable region is organized into an array counting from 0 in terms of word length. The bytecode instruction uses the data through an index starting at 0. Values of types int, float, reference, and returnAddress occupy an item in the array, while values of types byte, short, and char are converted to int values and also occupy an item before being stored in the array. However, values of types long and double occupy two consecutive items in the array.

2.5.1.2 Operand stack

Like the local variable area, the Operand stack is organized into an array in terms of word length. It is accessed through standard stack operations-stack push and stack off. Because the program counter cannot be accessed directly by the program instruction, the instruction of the Java virtual machine is to get the Operand from the Operand stack, so its operation mode is based on the stack rather than the register. The virtual machine uses the Operand stack as its workspace, because most instructions pop up data from there, perform operations, and then press the results back into the Operand stack.

2.5.1.3 frame data area

In addition to local variable areas and Operand stacks, Java stack frames require frame data areas to support constant pool parsing, normal method return, and exception dispatch mechanisms. Whenever the virtual machine wants to execute an instruction that requires constant pool data, it accesses it through a pointer to the constant pool in the frame data area. In addition to the parsing of the constant pool, the frame data area also helps the virtual machine handle the normal or abnormal termination of the Java method. If it ends normally through return, the virtual machine must restore the stack frame of the method that initiates the call, including setting the program counter to the next instruction that initiates the calling method; if the method has a return value, the virtual machine needs to push it into the Operand stack of the method that initiated the call. To handle the exception exit during the execution of the Java method, the frame data area also holds a reference to the method exception table.

2.6 Program counter

For a running Java program, each thread has its own program counter. Program counters are also called PC registers. Program counters can hold either a local pointer or a returnAddress. When a thread executes a Java method, the value of the program counter is always the address of the next instruction to be executed. The address here can be a local pointer or the offset from the method starting instruction in the method bytecode. If the thread is executing a local method, the value of the program counter is "undefined" at this time.

2.7 Local method stack

Any local method interface uses some kind of local method stack. When the thread calls the Java method, the virtual machine creates a new stack frame and pushes it into the Java stack. When it calls a local method, the virtual machine keeps the Java stack unchanged and no longer presses the new stack in the thread's Java stack. The virtual machine simply dynamically connects and directly calls the specified local method.

The method area and heap are shared by all threads in the virtual machine instance. When the virtual machine loads a class file, it parses the type information from the binary data contained in the class file and puts the type information into the method area. When the program is running, the virtual machine puts all the objects created by the program at run time on the heap.

Like other runtime memory areas, the memory area occupied by the local method stack can be dynamically expanded or shrunk as needed.

3 execution engine

In the Java virtual machine specification, the behavior of the execution engine is defined by an instruction set. The designer of the implementation engine will decide how to execute the bytecode, and the implementation can be interpreted, compiled in time, or executed directly using instructions on the chip, or a mixture of them.

The execution engine can be understood as an abstract specification, a concrete implementation, or a running instance. The abstract specification uses an instruction set to specify the behavior of the execution engine. Specific implementations may use a variety of different technologies-including a combination of software, hardware, or tree species technologies. The execution engine that is an instance of the runtime is a thread.

Each thread of a running Java program is an instance of a separate virtual machine execution engine. From the beginning to the end of a thread's life cycle, it is either executing bytecode or executing local methods.

3.1 instruction set

The byte stream of the method consists of the instruction sequence of the Java virtual machine. Each instruction contains a single-byte opcode, followed by 0 or more operands. The opcodes represent the actions that need to be performed; the operands provide the Java virtual machine with additional information needed to execute the opcodes. When a virtual machine executes an instruction, it may use an item in the current constant pool, a value in the local variable of the current frame, or a value at the top of the current frame Operand stack.

The abstract execution engine executes one bytecode instruction at a time. Each thread (execution engine instance) of the program running in the Java virtual machine performs this operation. The execution engine gets the opcode, and if the opcode has an Operand, it gets its Operand. It performs the actions specified by the opcode and the following operands, and then gets the next opcode. This process of executing bytecode continues until the thread finishes, either by returning from its initial method, or by not catching the thrown exception.

4 Local method interface

The Java native interface, also known as JNI (Java Native Interface), is prepared for portability. The local method interface allows local methods to do the following:

Pass or return data

Operation instance variable

Manipulate class variables or call class methods

Operand array

Lock objects on the heap

Load a new class

Throw an exception

Catch an exception thrown by a local method call Java method

Catch the asynchronous exception thrown by the virtual machine

Indicates that an object in the garbage collector is no longer needed

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.