One of the JVM series: Java Virtual machine

What is a Java virtual machine?
Java virtual machines, literally, are like some kind of machine, but the Java virtual machine is called "virtual" because it is an abstract computer defined by a specification, so when we say Java Virtual machine, it may refer to the following three different things:
Abstract Specification
A concrete implementation
A running instance of a virtual machine

The life cycle of a Java virtual machine

When a Java program is started, a virtual machine instance is created. When the program shuts down, the virtual machine instance also dies. The Java Virtual machine calls the main () method of an initial class as a starting point for the Java program to run. In Java Virtual machine content, there are two types of threads, daemon threads and non-daemon threads . The daemon thread is typically used by the virtual machine itself, such as a garbage collection thread, not a daemon thread, such as a thread running main (). When all non-daemon threads in the program terminate, the virtual machine instance exits automatically.

Architecture of the Java Virtual machine

In the Java Virtual Machine specification, the behavior of a virtual machine instance is described in terms of subsystems, memory areas, data types, and directives. Each Java virtual machine has a class mount subsystem, which mounts the system according to the fully qualified name, and, similarly, each Java virtual machine has an execution engine that executes the instructions contained in the methods of the loaded class.

When a Java Virtual machine runs a program, it needs memory to store many things, such as bytecode, objects, local variables, intermediate results of operations, and so on. Some run-time data areas are shared by all threads in the program, and some are owned by only one thread. Each virtual machine has a method area and a heap that are shared by all the threads in the virtual machine. When the virtual machine loads a class file, the type information is stored in the method area, and the program runs the virtual opportunity to save the objects created by the runtime into the heap.

Whenever a new thread is created, it will get its own PC register and a Java stack, and if the thread is executing a Java method (not local method), then the value of the PC counter always indicates the next instruction to be executed. The Java stack contains the call state of the Java method in the thread----including its local variables, the parameters that are called simultaneous, its return value, the computed intermediate result, and so on. Local method calls are stored in a local method stack in a way that relies on a specific implementation, or a register and some other memory areas that are related to a particular implementation.

The Java stack is made up of many stack frames or frames, and a stack frame contains the call state of a Java method. When a thread calls a Java method, the virtual machine presses a new stack frame into the stack, and the stack frame pops up and discards when the method returns.

Data type

Data types can be divided into two categories: primitive and reference types, basic types holding raw values, and reference types holding reference values. The value domains of Java primitives are consistent everywhere, for example a long type is a signed integer in 64-bit twos complement representation in any virtual machine.

Note: The Boolean is somewhat special, although the Boolean is also the base type, but when compiled to bytecode, it uses int or byte to represent Boolean,false as an integer 0,true as an integer 1. In addition, the Boolean array is accessed as a byte array class.

Length of consideration

In a Java virtual machine, the most basic data unit is the word, and the virtual machine implements a minimum of 32 bits as the length of words, or a more efficient length. Word length is usually selected based on the pointer lengths of the underlying host platform.

Class Loader Subsystem

There are two kinds of loaders in the Java Virtual machine: Start the class loader and the user custom loader. The former is part of the Java Virtual Machine implementation, which is part of the Java program. Different class loaders are placed in different namespaces inside the virtual machine.

The methods defined in ClassLoader provide an interface for programs to access the class loader mechanism. Each loaded type, the Java virtual machine creates an instance of the Java.lang.Class class for it to represent the type. The user-defined class loader and instances of the class class are placed in the in-memory heap area, while the type information loaded is located in the method area.

In addition to locating and importing binary class files, class loaders also need to be responsible for the correctness of imported classes, assigning variables and initializing memory, parsing symbol references, and so on. These actions must be carried out in strict accordance with the following steps:

1. Load--------Find and load binary data

2, the connection--------to perform the verification, preparation, has been resolved (optional)

Validation: Ensure correctness of imported types

Prepare: Allocates memory for class variables and initializes them to default values

Parse: Converts a symbol reference in a type to a direct reference

3. Initialize--------Initialize the class variable to the correct initial value

Method area

In a Java virtual machine, information about the loaded type is stored in memory that is logically referred to as the method area. When a virtual machine loads a type, it first uses the class loader to locate the appropriate class file, and then reads the class file-------a linear binary data stream and transfers it to the virtual machine. The virtual machine then extracts the type information into the method area, and the static variables in the class are stored in the method area.

All threads share the method area, so their access to the method area must be thread-safe, for example, if two threads are attempting to access a class named Lava, and this class has not yet been loaded into the virtual machine, then only one thread should be loaded and the other can wait.

The method area size is not fixed and can be adjusted to suit your needs. The same method area does not have to be contiguous, the method area can be allocated freely in the same heap, or the programmer can specify the maximum size and the minimum size of the initial size of the method area.

The method area can also be garbage collected, and the virtual machine allows the user-defined class loader to dynamically extend the Java Program (reflection), so some classes also become classes that the program "no longer refer to". When a class is no longer referenced, the Java Virtual machine can unload this class.

For each type of mount, the virtual opportunity stores the following types of information in the method area:

　　　The fully qualified name of this class

The direct superclass fully qualified name of this class

Whether this class is a class type or an interface type

Access modifiers for this class

An ordered list of fully qualified names for any direct superclass

In addition to the basic type information listed above, the virtual machine has to store the following information for each mounted type

　　　　Constant pool of this type

Field information

Method information

(static) Variables for all classes except constants

A classloader reference to the class

A reference to Class

Heap

All class instances and arrays created by the Java program runtime are placed in the same heap, and only one heap space exists in a Java Virtual machine instance, so all threads share the heap. Because each Java program has a single heap space, all the threads will share the heap. However, multiple threads of the same program share the same space, in which case the synchronization of multi-threaded access Objects (heap data) needs to be considered.

The Java Virtual machine has a directive that allocates new objects in the heap, but does not release memory. Just as we cannot explicitly release an object with Java code, there is no function in the bytecode. It is the virtual machine's responsibility to decide how and when to start garbage collection. The program itself does not need to be concerned about when to recycle, and the virtual machine usually gives the task to the garbage collector.

The Java Virtual Machine specification does not specify how Java objects are represented in the heap. The internal representation of an object affects the entire heap and the design of the garbage collector, which is determined by the virtual machine's implementation.

A possible heap space is designed to divide a heap into two parts: a handle pool, an object pool, and an object reference is a local pointer to a handle pool. The handle pool is divided into two parts: A pointer to an object instance variable, and a pointer to the type of the method area. This design is a bit of the benefit of heap fragmentation, the disadvantage of each access to the object is passed two times the pointer.

Another design is to direct the object pointer to a set of data, which includes an instance of the object and a class data pointer in the method area. The pros and cons of this design are the opposite of the previous method.

A virtual machine must be able to obtain class (type) data through a reference to an object: When a program is run to convert an object reference to another type, the virtual machine needs to check whether the conversion is allowed, and whether the object being converted is determined to be the referenced type and its superclass. For example, when the program executes instanceof (), the virtual machine needs to view the class data of the object being referenced. Finally, when an instance method is called in a program, the virtual machine must be dynamically bound.

Regardless of the object representation of the virtual machine implementation, each object may have a method table, because the method table can speed up the invocation of the instance. However, the Java Virtual Machine Implementation specification does not require a method table to be used, and all implementations do not use it. and building a method table for each object will take up more memory, so the scheme is only suitable for systems with enough memory.

　　

Shows a way to associate a method table with an object reference, each containing a pointer to a special data structure located in the method area, which consists of two parts:

　　　　A pointer to the method area corresponding to the class data

Method table for this object: The method table is an array of pointers, where each item is a pointer to an instance method, and the instance method data that the method table points to includes the following information:

The size of the operand stack and local variable area of this method

The byte code of this method

Exception table

The method table contains method pointers that point to the method data for a class or its superclass declaration: that is, the method pointed to in the method table may be declared or inherited.

There is also a logical part of the object data on the heap, which is the object lock, which is a mutex object. Each object on a virtual machine has an object lock that is used to coordinate the synchronization of multiple threads accessing the same object. At any moment, only one thread can "own" this object lock, so that only this thread has access to the object's data, and other threads that want to access this object can wait until the thread that owns the lock releases the lock. ( after a thread has an object lock, you can continue to append requests to this lock.) It should be noted that the request several times, the corresponding need to release a few times, such as a thread request three times the lock, before it released three times the lock, he has been "own" this lock ). Many objects are not locked by any line loads in their life cycle, so the lock data is not required, only the lock data is assigned when the lock is first locked, the virtual machine needs to use some method to contact the object data and the corresponding lock data, for example, put the lock data in a search tree indexed by the object address.

In addition to the data required to implement the lock, each Java object is logically associated with the data that implements the wait collection. Waiting for the collection to be used in conjunction with the notification method, each class inherits three wait methods from object (three overloaded methods named Wait () and two notification methods (notify () and Notifyall ()). When a thread calls a wait method on an object, the virtual machine blocks the thread and places it in the appropriate wait collection until another thread invokes the notification method on the same object, and the virtual machine wakes one or more blocked threads at a time waiting for the collection.

The last data type-------can be part of an object image in the heap and is data related to the garbage collector. The garbage collector must track each object that is referenced in some way. This task inevitably requires some data to be appended to these objects, and the data types need to be based on the garbage collector's algorithm.

　　the internal representation of the array, and the data also has a class class instance associated with their classes. Also expressed in the heap, as with other objects, arrays also have a class class instance associated with their class, and all arrays of the same dimension and type are instances of the same class. And no matter how long it is.

The name of an array class consists of two parts: each dimension represents "[" with a square bracket, a character or string representing the element type, for example, a one-dimensional array of type int "[1", a three-dimensional array with an element type of byte "[[[[B], a two-dimensional array of type Object" [[ljava/ Lang/object ".

　　

　Program counter

For each running Java program, each of these threads has its own PC register, which is created when the thread starts, and the size of the PC register is a word length. When a thread executes a Java method, the contents of the PC register are always the next "address" to be executed. The "address" here can be a local pointer, or it can be the offset from the method's byte code in relation to the start of the method.

　　Java stack

Whenever a thread is started, the Java Virtual machine assigns it a Java stack. The Java stack saves the running state of the thread as a frame, and the virtual machine performs only two operations on the stack: a stack and a stack in frames.

Each time a thread invokes a Java method, the virtual machine presses a new frame into the Java stack of the thread. The currently used stack frame is called the current frame, and when executing this method, it uses this frame to store data such as parameters, local variables, intermediate operation results, and so on.

The Java method can be done in two ways, one by return and the other by throwing an abnormally terminated. Either way, the virtual machine pops the current stack frame out of the Java stack and releases it. In addition, all data on the Java stack is private to this thread. No thread can access the stack data of another thread.

　　Stack frame　　

Stack frames are composed of three parts: local variable area, operand stack and frame data area

When a virtual machine invokes a Java method, it obtains the size of the local variable and operand stacks of this method from the type information for the class, allocates the stack frame memory accordingly, and presses it into the Java stack.

　　　　local variable area : The local variable area of the Java stack frame is organized into an array of word lengths, starting from 0. Bytecode uses the data from the 0-based index. Values of type int,float,reference and returnaddress occupy only one item in the array, and the values of type Byte,short and char are converted to int before they are stored in the array, thus occupying one item, Values of type long and double occupy two consecutive entries in the array.

It is important to note that in Runinstancemethod (), the first parameter of a local variable is a reference reference type, which is used to represent the object itself, which is implicitly added for any instance method.

operand stacks : As with local variables, the operand stack is organized into an array of word lengths. But the difference with the former is that it is not accessed through an index, but is accessed by the stack operation of the callout---the stack and the stack.

Unlike program counters, Java virtual machines do not have registers, program counters cannot be accessed directly by program instructions, and Java Virtual machine instructions take operands from the operand stack rather than registers, so it runs on a stack-based rather than register-based basis. Demonstrates the process of adding two local variables

Frame Data area : In addition to local variables and operand stacks, Java stack frames require some data to support constant pool parsing, return of normal methods, and exception distribution mechanisms. This information is stored in the frame data area of the Java frame stack.

Most directives in Java involve constant pool entry. Some instructions simply pull data from the constant pool into the Java stack (which includes int,long,float,double and string), and some directives use data from a constant pool to indicate the class or array to be instantiated, the field to access, or the method to invoke.

When a virtual machine needs to use data in a constant pool, it accesses it through a pointer to a constant pool in the frame data area. References to types, fields, and methods in a constant pool are symbols at the beginning. When a virtual machine searches in a constant pool, the virtual machine is parsed if the type, fields, and methods encountered are still symbols.

Possible implementations of the Java stack: One possible way to allocate each frame from the heap, for example, consider the following class

　　　　

　　　　

Shows the three snapshots of the Addandprint () method. In this Java virtual machine implementation, each frame is allocated separately from the heap. In order to call the method Addtowtypes (), the Method Addandprint () first presses 1 and 88.88 into its operand stack, and then calls the Addtowtypes () method.

　　　　

The instruction to call Addtowtypes () points to the data of a constant pool, so finding the data in a constant pool is necessary and must be resolved.

The parsed constant pool data will point to the corresponding addtwotypes () information in the method area. The virtual machine needs to use this information to determine the local variable area of the Addtwotypes () and the size of the operand stack.

　　Local method Stack:

All previous runtime data areas are explicitly defined in the Java Virtual Machine specification, but the program may run with some data areas related to local methods. When a thread calls a local method, it goes into a completely new world that is not restricted by the virtual machine.

When a thread calls a Java method, the virtual opportunity creates a new stack frame and presses it into the Java stack. But it calls the local method, the virtual will keep the Java stack unchanged, no longer the thread of the Java stack into the new frame, the virtual machine is simply a dynamic link and directly invoke the use of local methods.

The following shows the process by which threads invoke local methods:

　　　　

We call two methods first, then call a local method in the second method in both methods, causing the virtual machine to use a local method stack, assuming this is a C language stack, there are two C functions, the first C function is called by the second Java method, and the first C function calls the second C function, The second C function also calls a Java method. The second C function then callbacks a Java method through the local method interface, which in turn calls a Java method.

As with other runtime memory areas, the memory area occupied by the local method stack is not a fixed size, and it can be scaled or shrunk dynamically as needed. Some implementations also allow the user or programmer to specify the initial size of the memory area and the maximum minimum.

　　　　Reference: In-depth understanding of Java Virtual Machine Second Edition

One of the JVM series: Java Virtual machine