Java Virtual Machine Architecture analysis

First, the life cycle of the JVM:

1) The program starts executing, he runs, the program stops, and it ends. There are several programs in the execution, there are several virtual machines at work. As long as there are normal threads executing in the Java virtual machine, the Java Virtual machine will not stop.

2) The Java Virtual machine always starts with a main () method, which must be public, return void, and accept an array of strings. When the program executes, you must indicate to the Java Virtual machine The class name that contains the main () method. The Main () method is the beginning of the program, and the thread that he is executing is initialized to the program's initial thread. The other threads in the program are started by him.

3) Threads in Java are divided into two types: the daemon thread (daemon) and the normal thread (Non-daemon). A daemon thread is a thread that the Java virtual machine uses itself, such as a thread that is responsible for garbage collection, which is a daemon thread. The initial thread that contains the main () method is not a daemon thread.

4) defines a series of subsystems, memory regions, data types, and usage guidelines in the Java Virtual Machine specification. These components constitute the internal structure of the Java Virtual machine, and they not only provide a clear internal structure for the implementation of the Java Virtual machine, but also strictly stipulate the external behavior of the Java Virtual Machine implementation.

Second, the Java Virtual machine architecture:

Each Java virtual machine is owned by a classloader subsystem that loads the types (classes and interfaces) in the program and assigns a unique name. Each Java Virtual machine has an execution engine (execution engine) responsible for executing the instructions contained in the loaded class.

The execution of a program requires a certain amount of memory space, such as bytecode, additional information about the loaded class, objects in the program, parameters of the method, return values, local variables, intermediate variables to process, and so on. The Java Virtual machine stores this information in the data area.

The implementation of each Java virtual machine contains data areas, but the Java Virtual Machine specification is very abstract about the data area provisions. Many of the structural details are left to the Java Virtual Machine implementation to play by itself. The memory structures on different Java Virtual machine implementations vary widely. Some implementations may consume a lot of memory, while others may consume little memory; Some implementations may use virtual memory, while others do not. This relatively refined Java Virtual Machine Memory specification enables Java Virtual machines to be implemented on a wide range of platforms.

Part of the data area is common to the entire program, and other parts are controlled by separate threads. Each Java Virtual machine contains a method area and heap, which are shared by the entire program.

After a Java virtual machine loads and parses a class, the information that is parsed from the class file is saved in the method area (the information that holds the parsed class). Objects that are created when the program executes are saved in the heap (Save object).

When a thread is created, it is allocated only to his own PC register "PC Register" (program counter) and Java stack (Java stacks). When a thread does not fall out of the local method, its function is to save the next instruction that the thread executes in the PC register. The Java stack holds a state when a thread invokes a method, including local variables, parameters that invoke methods, return values, and intermediate variables to process. The state when the local method is called is persisted in the local method stack, possibly in registers or other non-platform independent memory.

The Java stack consists of a stack block. The stack block contains the state of the Java method call. When a thread calls a method, the Java virtual Opportunity presses a new block into the Java stack, and when the method runs at the end, the Java Virtual opportunity pops up the corresponding block and discards it.

The difference: The Java Virtual machine does not use registers to hold the computed intermediate results, but instead uses the Java stack to store the intermediate results. This is the Java Virtual Machine instructions are more compact and easier to implement a Java virtual machine on a device without a register.

Third, class loader subsystem:

There are two types of ClassLoader in a Java virtual machine: The original ClassLoader (primordial class loader) and the class loader object (class loader objects ). feature: The original ClassLoader is part of the Java virtual machine implementation, and the ClassLoader object is part of a running program. Classes loaded by different classloader are split by different namespaces.

The ClassLoader calls many of the other parts of the Java Virtual Machine and many of the classes in the Java.lang package. For example, a class loading object is an instance of the Java.lang.ClassLoader subclass, and the methods in the ClassLoader class can access the class loading mechanism in the virtual machine.

Each class that is loaded by a Java virtual machine is represented as an instance of the Java.lang.Class class. Like other objects, the ClassLoader object and the class object are stored in the heap, and the loaded information is saved in the method area.

The work that the ClassLoader does:

1. Load, connect, initialize (Loading, linking and initialization)

The class loading subsystem is not just responsible for locating and loading the class file, he does a lot of other things in the following rigorous steps:

1), Load: Find and import binary information for the specified type (class and interface)

2), Connection: verification, preparation and resolution

① validation: Ensuring the correctness of import types

② Preparation: Allocating memory for types and initializing them to default values

③ parsing: Resolving character references to direct references

3), initialize: Call Java code, initialize class variable to appropriate value

2. Original class Loader

Each Java virtual machine must implement a primitive classloader that can load classes that adhere to the class file format and are trusted. However, the specification of the Java Virtual machine does not define how the class is loaded, as determined by the Java Virtual Machine implementation itself. For a type of the given type name, the original ClassLoader must find the file with the type name plus ". Class" and load it into the virtual machine.

3. Class Loader Object

Although the ClassLoader object is part of a Java program, the three methods in the ClassLoader class can access the class-loading subsystem in the Java Virtual machine.

1), Protected final Class defineclass (...) : Use this method to enter a byte array and define a new type.

2), protected class Findsystemclass (String name): Loads the specified class and returns directly if it is already loaded.

3), Protected final void Resolveclass (Class C): The DefineClass () method simply loads a class that is responsible for subsequent dynamic joins and initializations.

4. Namespaces

When more than one class loader loads the same class, in order to ensure the uniqueness of their name, it is necessary to precede the class name with the identity of the class loader that loads the class.

Iv. Method Area:

In a Java virtual machine, information about the loaded type is saved in the method area. The organization of this information in memory is defined by the implementation of the virtual machine, for example, the virtual machine works on a "Little-endian" processor, and he can save the information in "Little-endian" format, although in Java class files they are " Big-endian "format is saved. Designers can store data in the most appropriate representation format to ensure that the program executes at the fastest possible speed. However, on a device with only a small amount of memory, the implementation of the virtual machine does not occupy a large amount of memory.

All threads in the program share a method area, so methods that access the method area information must be thread-safe. If you have two threads to load a class called Lava, then only one thread will be allowed to load the class, and the other must wait.

When the program is running, the size of the method area is variable, and the program can be extended at run time. Some implementations of a Java virtual machine can also set the initial size, minimum and maximum values of the method area through parameters.

The method area can also be garbage collected. Because the program is loaded dynamically by the ClassLoader, all classes may become non-referenced (unreferenced) (although they have been loaded, but no references!). ) status. When the class becomes this state, he may be garbage collected. Classes that are not loaded include two states, one that is really not loaded, and another that is "unreferenced".

1, type information (type information)

For each type that is loaded, the following information is stored in the Java virtual machine in the method area:

1), the full name of the type

2), the full name of the type's parent type

3), to type is a class or interface

4), type modifier

5), List of all parent interface names

The data structure saved by the type's full name is defined by the virtual machine's implementation. In addition to this, the Java Virtual machine also holds the following information for each type:

1), type of constant pool

2), type field information

3), type method information

4), All static class variables (non-volume) information

5), a reference to the ClassLoader

6), a reference to class

7), type of constant pool

A constant pool holds an ordered set of constants for all types, including direct constants (literals), constants such as strings, integers, floating-point numbers, and symbolic references to types, fields, and methods. Every persisted constant in a constant pool has an index, just like a field in an array. Because a constant pool holds a character reference to the type, field, and method used by all types, it is also the primary object of the dynamic connection.

2), type fields information (field information)

Field names, field types, modifiers for fields, and the order in which fields are defined in the class.

3), type methods information (method information)

The method name, the return value type of the method (or void), the number of method arguments, the type and their order, the field's modifier, the order in which the method is defined in the class

4), class static static variable

Class variables are shared by instances of all classes, even if they are not accessed through instances of the class. These variables are bound on the class (not on the instance of the class), so they are part of the logical data for the class. You need to allocate memory for class variables before the Java Virtual machine uses this class

The constant (final) is handled differently than this class variable. Each type is copied to its own constant pool when a constant is used. Constants are also stored in the method area like class variables, except that they are stored in a constant pool. (It is possible that class variables are shared by all instances, whereas constant pools are unique to each instance). The Non-final class variable is saved as part of the data that defines his type, and the final constant is saved as part of the data that uses his type.

5), reference to class loader

Each type that is loaded by a Java virtual machine, the virtual machine must save whether the type is loaded by the original class loader or the ClassLoader. Those types that are loaded by the ClassLoader must hold a reference to the ClassLoader. This information is used when the ClassLoader is dynamically connected. When a class references another class, the virtual machine must save that the referenced type is loaded by the same ClassLoader, which is also the process of maintaining a different namespace for the virtual machine.

6), reference to class class (function of Class.forName ())

The Java Virtual machine creates an instance of the Java.lang.Class class for each loaded type. You can also use the class method: public static class forname (String className) to find or load a class and get an instance of the corresponding class class.

2. Methods list (method Tables)

For more efficient access to all data stored in the method area, the storage structure of the data must be carefully designed. In all method areas, in addition to the original information above, there is a data structure designed to speed up access, such as a list of methods. For each non-abstract class that is loaded, the Java Virtual machine generates a list of methods that hold references to all instance methods that the class might invoke, giving an error to the methods called in the parent class.

Five, Heap:

When a Java program creates an instance or an array of a class, it allocates memory for the new object in the heap. There is only one heap in the virtual machine, and all the threads share it (the method area can also be shared!). ）。

1. Garbage collection (Garbage Collection)

Garbage collection is the primary method of releasing objects that are not referenced. It may also move objects in order to reduce the fragmentation of the heap. Garbage collection is not strictly defined in the specification of a Java virtual machine, but the implementation of defining a Java Virtual machine must somehow manage its own heap.

2. Object storage structure (representation)

The Java Virtual Machine specification does not define how objects are stored in the heap. Each object primarily stores the object variables defined in his class and in the parent class. For a reference to a given object, the virtual machine must be able to quickly navigate to the object's data. In addition, you must provide a way to object data through the object's reference method, such as a reference to an object in the method area, so that the data stored by an object often contains a pointer to the method area in some form.

1) A possible heap is designed to divide the heap into two parts: the reference pool and the object pool. A reference to an object is a local pointer to the reference pool. Each entry in the reference pool contains two parts: A pointer to the object data in the object pool and a pointer to the object class data in the method area. This design makes it easy to defragment the Java Virtual machine heap fragments. When a virtual machine moves an object in an object pool, only the pointer address in the corresponding reference pool needs to be modified. (Understand: A reference in the reference pool points to a corresponding object, the essence of moving objects is to modify the address of the reference pool!) However, each access to the object's data requires two pointers to be processed.

2) Another heap design is that a reference to an object is a pointer to a heap of data and an offset to the corresponding object. This design facilitates access to objects, but the movement of objects becomes unusually complex.

When a program attempts to convert an object to another type, the virtual machine needs to determine whether the conversion is the type of the object, or his parent type. Similar things are done when the program applies instanceof statements. When a program calls a method of an object, the virtual machine needs to be dynamically bound, and he must determine which type of method to invoke. This also requires making the above judgments.

Regardless of the design used by the virtual machine's implementation, he might save a list of similar methods for each object. Because he can raise the speed of object method calls, it is important to improve the performance of the virtual machine, but the specification of the virtual machine has no requirement to implement a similar data structure.

Objects in each Java virtual machine must be associated with one for synchronizing multi-threaded lock (mutex). At the same time, only one object can have a lock on this object. When a lock with this object, he can apply for this lock multiple times, but must also release the corresponding number of locks to really release the object lock. Many objects are not locked for the entire life cycle, so this information needs to be added only when needed. Many implementations of a Java virtual machine do not include "lock data" in the object's data, but generate the corresponding data only when needed. In addition to implementing object locking, each object is logically associated with the implementation of a "wait set". Locking helps the group thread to handle the shared data independently, without interfering with other threads. The wait set works together to accomplish the same goal for the group threads. The wait set is often implemented through the wait () and notify () methods of the object class.

Garbage collection also requires information about whether the objects in the heap are associated. The Java Virtual Machine specification states that garbage collection is a finalize method that runs an object once, but allows the Finalize method to re-reference the object, and when the object is not referenced again, it does not need to call the Finalize method again. So the virtual machine also needs to save the information that the Finalize method is running.

3. Saving arrays (array representation)

In Java, an array is an object that is completely meaningful, stored in the heap like an object, and has a reference to the Class class instance. All arrays of the same dimension and type have the same class, and the length of the array is not considered. The name of the corresponding class is represented as a dimension and the type array must hold the array's length in the heap, the array's data, and some object array type data references. Referenced by an array, the virtual machine should be able to obtain the length of an array through which the index can access specific data and be able to invoke the method defined by the object. Object is the immediate parent class for all data classes.

Java Virtual Machine Architecture analysis