JVM memory management mechanism and garbage collection mechanism

From the logical structure of the Java platform, we can see the JVM from the following illustration:

From the above, you can see clearly the various logical modules contained in the Java platform and the difference between the JDK and the JRE.

For the physical structure of the JVM itself, we can look at the following image:

For the study of the JVM, it seems to me that these are the most important parts: the entire process of compiling and executing Java code JVM memory management and garbage collection mechanism

These two sections are studied in detail below

Java code compilation is done by the Java source compiler, and the flowchart looks like this:

The execution of Java bytecode is done by the JVM execution engine, and the flowchart looks like this:

The entire process of compiling and executing Java code includes the following three important mechanisms: Java source compilation mechanism class loading mechanism class execution mechanism

Java source Code compilation mechanism

Java source code compilation consists of the following three processes: parsing and input to symbol table annotation processing semantic analysis and generating class files

The flowchart looks like this:

The last generated class file consists of the following parts: structure information. Includes the class file format version number and the number and size of each part of the information meta data. Corresponds to the information declared and constants in the Java source code. Contains declaration information, domain and method declaration information, and constant pool method information for the class/inherited superclass/implementation interface. Corresponds to the information in the Java source code for statements and expressions. Contains bytecode, exception handler table, evaluation stack and local variable area size, evaluation stack type record, debug symbol information

class loading mechanism

Class loading of the JVM is done through ClassLoader and its subclasses, and the hierarchy of classes and loading order can be described in the following illustration:

1) Bootstrap ClassLoader

Responsible for loading all class in Jre/lib/rt.jar in $java_home, implemented by C + +, not ClassLoader subclass

2) Extension ClassLoader

Some jar packages that are responsible for loading extensions in the JAVA platform, including the jar packages in Jre/lib/*.jar or-djava.ext.dirs specified directories in $java_home

3) App ClassLoader

Responsible for documenting the jar package and class in the directory specified in Classpath

4) Custom ClassLoader

ClassLoader that belong to the application to customize according to their own needs, such as Tomcat, JBoss will be implemented according to the Java EE specification ClassLoader

The load process checks to see if the class is loaded, the check order is bottom-up, from custom ClassLoader to Bootstrap ClassLoader, and as long as a classloader is loaded, the class is considered loaded. Ensure that only all classloader of this class are loaded once. The order of loading is from top to bottom, which is to try to load this class from the top level.

class execution mechanism

The JVM is based on the stack architecture to execute class byte code. After the thread is created, both the program counter (PC) and stack (stack) are generated. The program counter holds the offset of the next instruction to be executed in the method, the stack holds each stack frame, each stack frame corresponds to each method of each call, and the stack frame has the local variable area and the operation number stack two parts, The local variable area is used to store the local variables and parameters in the method, and the operand stack is used to store the intermediate results produced during the execution of the method. The structure of the stack is shown in the following illustration:

JVM Memory Composition Structure

The JVM stack consists of heaps, stacks, local method stacks, method areas, and so on, as shown in the following chart:

1) Heap

The memory of all objects created through new is allocated in the heap, and its size can be controlled by-XMX and-XMS. The heap is divided into cenozoic and old generations, and the Cenozoic is further divided into the Eden and survivor areas, and the final survivor consists of from and to spaces, as shown in the chart below:

Cenozoic. New objects are used to allocate memory, Eden, when the space is insufficient, will be the survival of the object transferred to the survivor, the Cenozoic size can be controlled by-XMN, can also use-xx:survivorratio to control the proportion of Eden and survivor old generation. For storing objects that are still alive after multiple garbage collections in the Cenozoic.

2) stack

Each thread executes each method by requesting a stack frame in the stack, each of which includes a local variable area and an operand stack to hold the temporary variables, parameters, and intermediate results during this method invocation

3) Local Method stack

Used to support the execution of the native method, storing the state of each native method call

4) Method Area

The class information, static variables, final type constants, properties, and method information to be loaded are stored. The JVM uses a persistent generation (permanet Generation) to store the method area, specifying the minimum and maximum values through-xx:permsize and-xx:maxpermsize

garbage collection Mechanism

The JVM uses different garbage collection mechanisms for the Cenozoic and the old generations, respectively.

The new generation of GC:

The new generation usually has a short survival time, so based on the copying algorithm for recycling, the so-called copying algorithm is to scan the surviving object, and copied to a novel completely unused space, corresponding to the Cenozoic, that is, between Eden and from spaces or to spaces copy. The new generation uses idle pointers to control GC triggers, and the pointer retains the position of the last allocated object in the Cenozoic interval, and the GC is triggered to check if the space is sufficient when a novel object is to allocate memory. When the object is continuously allocated, the object is gradually from Eden to survivor, and finally to the old generation,

With the Java VISUALVM to view, can obviously observe the Cenozoic after the full, will transfer objects to the old generation, and then empty continue to load, when the old generation is full, will report outofmemory Anomaly, as shown in the following figure:

The JVM provides a serial GC (serial GC), a parallel recovery GC (Parallel scavenge), and a parallel GC (PARNEW) on the execution mechanism

1) Serial GC

The whole process of scanning and copying is done in a single-threaded way, which is applicable to single CPU, small Cenozoic space and not very high for pause time requirements, is the client-level default GC method, which can be enforced by-XX:+USESERIALGC to specify

2) Parallel Recovery GC

In the entire scanning and replication process in a multi-threaded manner, suitable for multiple CPUs, short pause time applications, is the server level by default GC method, can be-XX:+USEPARALLELGC to force the designation, with-XX: Parallelgcthreads=4 to specify the number of threads

3) Parallel GC

Used in conjunction with the old generation's concurrent GC

The GC of the old generation:

The old generation and the Cenozoic are different, the object survival time is relatively long, more stable, so using the mark (Mark) algorithm for recycling, the so-called mark is to scan out the surviving objects, and then to recycle the unmarked objects, after the recovery of the space to use out or merge, or marked out for the next time to allocate, In short, you want to reduce the loss of efficiency caused by memory fragmentation. The JVM provides serial GC (serial MSC), parallel GC (parallel MSC) and concurrent GC (CMS) on the execution mechanism, and details of the algorithm need to be further studied.

The various GC mechanisms listed above are required to be combined, and are specified in the following table:

Specify the way	The new Generation GC method	Old Generation GC method
-xx:+useserialgc	Serial GC	Serial GC
-xx:+useparallelgc	Parallel Recovery GC	Parallel GC
-xx:+useconemarksweepgc	Parallel GC	Concurrent GC
-xx:+useparnewgc	Parallel GC	Serial GC
-xx:+useparalleloldgc	Parallel Recovery GC	Parallel GC
-xx:+ USECONEMARKSWEEPGC -xx:+useparnewgc	Serial GC	Concurrent GC
Unsupported combinations	1,-XX:+USEPARNEWGC-XX:+USEPARALLELOLDGC 2,-XX:+USEPARNEWGC-XX:+USESERIALGC