Java Foundation-JVM

Jvm= "Java Virtual machine

One, the life cycle of a Java Virtual machine:

The life cycle of a Java virtual machine A running Java Virtual machine has a clear task: Executing a java program. He runs when the program starts, and he stops at the end of the program. You run three programs on the same machine and there are three running Java virtual machines. The Java Virtual machine always starts with a main () method, which must be public, return void, and be directly affected by an array of strings. When the program executes, you must indicate to the Java Virtual machine the class name of the replacement 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.

　　There are two types of threads in Java: 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. Of course, you can also set your own program as the daemon thread. The initial thread that contains the main () method is not a daemon thread. as long as there are normal threads executing in the Java virtual machine, the Java Virtual machine will not stop. If you have sufficient permissions, you can call the exit () method to terminate the program.

Second, the Java Virtual machine architecture:

A series of subsystems, memory regions, data types, and usage guidelines are defined in the specification of a Java virtual machine. 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.Each Java Virtual machine consists of a class loader subsystem (class loader subsystem) that is responsible for loading the types (classes and interfaces) in the program and giving unique names. 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 areas. Although the implementation of each Java virtual machine contains a data area, 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 parsed from the class file is saved in the method area.      Objects that are created when the program executes are saved in the heap. When a thread is created, it is allocated only to his own PC register "PC Register" (program counter) and Java stack (Java stacks). When the thread does not fall off with the local method, the next instruction that the thread executes is saved 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 saved in the local methods stack (native method stacks), possibly in registers or other non-platform independent memory. The Java stack consists of a stack frames (or frames). 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 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:

The ClassLoader in a Java Virtual machine is divided into two types: the original ClassLoader (primordial class loader) and the class loader object (class loader objects).

The original class loader is part of the Java Virtual Machine implementation. 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, the 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 loaded by a Java virtual machine is represented as an instance of a 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.

1. Loading, connecting, initializing (Loading, linking and initialization) class loading subsystem is not only responsible for locating and loading the class file, he has done a lot of other things according to the following strict steps:

1), Load: Find and import binary information for the specified type (class and interface), connect: Validate, prepare, and parse               ① validation: Ensure the correctness of the import type               ② prepare: Allocate memory for type and initialize to default value               ③ Parse: Resolve character reference to direct drinking 3), Initialize: Call Java code, initialize class variable to appropriate value

2. Original class loader (the primordial 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 the type of the given type name, the original-the loader 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),protectedfinal  Class defineclass (...) : Use this method to enter and exit 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),protectedfinalvoid resolveclass (class C): The DefineClass () method simply loads a class, This method is responsible for the subsequent dynamic connection and initialization.

4. Namespaces     when more than one class loader loads the same class, in order to ensure the uniqueness of their names, 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. This writing information in memory is defined by the implementation of the virtual machine, for example, the virtual machine works on a "Little-endian" processor, he can save the information in "Little-endian" format, although in the Java class file they are " Big-endian "format is saved. The designer can store the data in a format that is most suitable for the machine, ensuring 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 customize the initial size, minimum and maximum values of the method area through parameters. The     method area can also be garbage collected. Because the inside of the program is dynamically loaded by the ClassLoader, all classes may become non-referenced (unreferenced) states. 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". For more information, see the life cycle of the class in chapter seventh (the Lifetime of a 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 him.

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 tender and Nou quickly to locate the object's data.     Alternatively, 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. One possible heap design is 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. However, each access to the object's data requires processing two pointers. Demonstrates the design of this heap.      The Heapoffish applet in the Nineth chapter of "Garbage collection" demonstrates this design. 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. Demonstrates this design 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. Describes this structure. The graph shows all the data structures associated with an object reference, including: 1), a pointer to type data 2), and a list of methods for an object. The method list is an array of pointers to all of the methods that may be called objects.          The method data includes three parts: the size of the opcode stack and the local variable area of the method stack; The byte code of the method; the exception list. Objects in each Java virtual machine must be associated with a lock (mutex) for synchronizing multithreading. At the same time, only one object can have a lock on this object. When a lock has this object, he can apply for the lock multiple times, but must also release the corresponding number of locks to actually 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 finalizer method that runs an object once, but allows the finalizer 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. For more information, see "Garbage Collection" in chapter Nineth
    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 expressed as a dimension and a type.     For example, an integer data class is "[I", a byte-type three-dimensional array class named "[[[B], two-D object data class named" [[Ljava.lang.Object]. The array must hold the length of the array in the heap, the data of the array, and references to some object array type data. 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.

The physical structure of the JVM itself

This figure shows the JVM memory structure

The JVM memory structure consists of two subsystems and two components. The two subsystems are ClassLoader subsystem and executionengine (execution engine) subsystem, and two components are Runtimedataarea (runtime data region) component and Nativeinterface (local interface) component respectively.

The role of the ClassLoader subsystem:

Loads the contents of a class file into a Methodarea (method area) in Runtimedataarea, given a fully qualified name Class name (such as Java.lang.Object). Java programmers can extendsjava.lang.ClassLoader classes to write their own classloader.

The role of the Executionengine subsystem:

Executes the instructions in the classes. The core of any jvmspecification implementation (JDK) is executionengine, and the different JDK, such as Sun's JDK and IBM's JDK, depends largely on the quality of their respective executionengine.

Nativeinterface components:

Interacting with Nativelibraries is an interface for other programming language interactions. When the native method is called, it enters a completely new world that is no longer restricted by the virtual machine, so it is also easy to have nativeheapoutofmemory that the JVM cannot control.

Runtimedataarea components:

This is what we often call the JVM's memory. It is mainly divided into five parts--

1. Heap: Only one heap space exists in a Java virtual instance

2. Methodarea (method Area): The information of the loaded class is stored in Methodarea memory. When a virtual machine loads a type, it uses the class loader to locate the appropriate class file and then reads the class file contents and transfers it to the virtual machine.

3, Javastack (Java stack): The virtual machine will only perform two operations on the Javastack: stack or stack in frames

4. Programcounter (program counter): Each thread has its own PC register, which is also created when the thread starts. The contents of the PC register always point to the next hungry address where the instruction will be executed, where the address can be either a local pointer or an offset relative to the method's start instruction in the method area.

5, Nativemethodstack (local method Stack): Save Native method to enter the address of the zone

Java Foundation-JVM