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 a local method), then the value of the PC counter always indicates the next instruction to be executed, and the Java stack contains the call state of the Java method in the thread-- Including its local variables, called simultaneous incoming parameters, its return value, calculated intermediate results, 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--– to find and load binary data

2, the connection--– performs the verification, prepares, has 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 the--– to 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.

Java Virtual machine