JVM Learning Notes

the process by which the JVM executes the program:I. Loading A. class file Ii. managing and allocating memory Iii. performing garbage collection JRE (Java Runtime Environment) the runtime environment of the Java program containing the JVM [1] The JVM is a container for the Java program to run, but he is also a process of the operating system. So he also has his own running life cycle, as well as his own code and data space. The JVM is at the bottom of the entire JDK and is responsible for interacting with the operating system, shielding the operating system environment, providing a complete Java runtime environment, and therefore the virtual machine. The operating system is loaded into the JVM via Java.exe in the JDK, completing the JVM environment in 4 steps below. 1. Create the JVM mount environment and configuration 2. Load Jvm.dll3. Initialize JVM.dll and hook up to JNIEnv (JNI call Interface) Instance 4. Invokes the jnienv instance to mount and process the class. [2]Fragment RecyclingThe storage space required for an instance of the Java class is allocated on the heap. The interpreter assumes the task of allocating space for the class instance. After the interpreter has allocated storage space for an instance, it begins to record the use of the area of memory occupied by that instance. Once the object has been used, it is recycled into the heap. In the Java language, there is no other method to request and free memory for an object other than the new statement. The work of freeing and reclaiming memory is carried out by the Java operating system. This allows the designers of the Java Runtime system to determine the method of fragment reclamation themselves. In the Java interpreter and hot Java environment developed by Sun, fragment recycling is performed in the same way as a background thread. This not only provides good performance for the operating system, but also gives program designers the risk of controlling their memory usage.Storage AreaThe JVM has two types of storage: a constant buffer pool and a method area. A constant buffer pool is used to store class names, method and field names, and string constants. The method area is used to store the bytecode of the Java method. The specific implementation of these two storage areas is not explicitly specified in the JVM specification. This allows the storage layout of the Java application to be determined during operation, depending on how the platform is implemented. The JVM is a platform-independent specification that is defined for Java bytecode and is the basis for the independence of the Java platform. The JVM still has some limitations and shortcomings that need to be further perfected, but the idea of the JVM is successful anyway. Comparative analysis: If the original Java program to think of our C + + original program, the Java original program compiled after the generated bytecode is equivalent to C + + original program compiled 80x86 machine code (binary program Files), the JVM virtual machine equivalent to 80x86 computer system, The Java interpreter is equivalent to 80X86CPU. The machine code is running on the 80X86CPU, and Java bytecode is running on the Java interpreter. The Java interpreter is equivalent to "CPU" running Java bytecode, but the "CPU" is implemented by software instead of hardware. The Java interpreter is actually an application under a particular platform. As long as the interpreter program under a specific platform is implemented, Java bytecode can be run through the interpreter program on the platform, which is the root of the Java cross-platform. Currently, not all platforms have a corresponding Java interpreter program, which is why Java does not work on all platforms, it can only run in the implementation of the Java Interpreter program platform.Running Data

The JVM defines a number of data regions that are used during the execution of a program. Some of the data in this area is created when the JVM is started and destroyed when the JVM exits. While the rest of the data depends on each thread, created when threads are created, and destroyed when the thread exits. There are program counters, heaps, stacks, method areas, and run constant-time pools, respectively.

From the logical structure of the Java platform, we can never understand the JVM:

The difference between JDK and JRE can be learned from the clear view of the various logic modules contained in the Java platform

For the JVM's own physical structure, we can take a bird's eye view:

For the study of the JVM, it seems to me that so many parts are most important:

• The entire process of compiling and executing Java code
• JVM memory management and garbage collection mechanism

Learn more about these two sections below

Java code compilation is done by the Java source compiler, and the flowchart is as follows:

The execution of Java bytecode is done by the JVM execution engine, and the flowchart is as follows:

The entire process of compiling and executing Java code consists of the following three important mechanisms:

• Java source Code compilation mechanism
• Class loading mechanism
• Class execution mechanism

Java source Code compilation mechanism

Java source code compilation consists of the following three processes:

• Parse and input to symbol table
• Annotation processing
• Semantic analysis and generation of class files

The flowchart is as follows:

The resulting class file is made up of the following sections:

• Structure information. Includes the class file format version number and the number and size of each part of the information
• Meta data. The information that corresponds to the declarations and constants in the Java source code. Contains class/inherited superclass/implemented interface declaration information, domain and method declaration information, and constant pool
• Method information. Corresponds to the information in the Java source code for statements and expressions. Includes byte code, exception Processor table, evaluation stack and local variable size, type record of evaluation stack, debug symbol information

Class loading mechanism

The class loading of the JVM is done through ClassLoader and its subclasses, and the hierarchy and loading order of the classes can be described as follows:

1) Bootstrap ClassLoader

Responsible for loading all classes in Jre/lib/rt.jar in $java_home, implemented by C + +, not classloader subclasses

2) Extension ClassLoader

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

3) App ClassLoader

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

4) Custom ClassLoader

The ClassLoader that the application customizes according to its own needs, such as Tomcat and JBoss, will be implemented according to the Java EE specification itself ClassLoader

The load process checks to see if the class is loaded, the check order is bottom-up, and the custom ClassLoader to bootstrap ClassLoader-by-layer check, as long as a certain classloader is loaded as if the class has been loaded. Ensure that only all classloader of this class are loaded once. The order of loading is top-down, that is, the upper layer tries to load the class one at a level.

Class execution mechanism

The JVM is a stack-based architecture that executes class bytecode. After the thread is created, the program counter (PC) and stack (stack) are generated, and the program counter holds the offset of the next instruction to be executed in the method, and the stack frames are stored in each stack frame, and each stack frame corresponds to each call of each method, and the stack frame is made up of the local variable area and the operand stack. Local variables are used to store local variables and parameters in the method, which are used to store the intermediate results produced during the execution of the method. The structure of the stack is as follows:

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

All the memory of objects created by new is allocated in the heap, and its size can be controlled by-XMX and-XMS. The heap is divided into the Cenozoic and the old generation, and the Cenozoic is further divided into the Eden and survivor areas, and the final survivor is made up of from space and to space, and the structure diagram is as follows:

• Cenozoic. New objects are used to allocate memory in the Cenozoic, when Eden space is insufficient, the surviving objects will be transferred to the survivor, the Cenozoic size can be controlled by-xmn, you can also use-xx:survivorratio to control the proportions of Eden and survivor.
• Old generation. For storing objects that are still alive after multiple garbage collection in the Cenozoic

2) stack

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

3) Local Method stack

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

4) Method Area

Contains the class information to load, static variables, constants of the final type, properties, and method information. The JVM uses a durable generation (permanet Generation) to store the method area, which can be specified by-xx:permsize and-xx:maxpermsize to specify minimum and maximum values

Garbage collection mechanism

The JVM uses different garbage collection mechanisms for the Cenozoic and the old generation respectively

New generation of GC:

The new generation usually has a shorter survival time, so the so-called copying algorithm, based on the copying algorithm, scans the surviving object and copies it into a completely unused space, corresponding to the Cenozoic, which is copied between Eden and from space or to space. The Cenozoic uses a free pointer to control the GC trigger, the pointer keeps the last allocated object in the Cenozoic interval, and when a new object is allocated memory, it is used to check if the space is sufficient and not enough to trigger the GC. When objects are continuously allocated, the objects gradually go from Eden to Survivor, and finally to the old generation,

Using Java VISUALVM to view, can obviously observe the new generation full after the object will be transferred to the old generation, and then empty continue to load, when the old generation is full, will be reported OutOfMemory exception, as shown:

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

1) Serial GC

The entire scanning and copying process is a single-threaded way, suitable for single CPU, the new generation of small space and the demand for pause time is not very high application, is the client level of the default GC mode, can be-XX:+USESERIALGC to enforce the specified

2) Parallel Recovery GC

In the entire scanning and replication process in a multi-threaded way, for multi-CPU, the time required for a short pause on the application, the server level is the default use of GC mode, can be-XX:+USEPARALLELGC to enforce the designation, with-XX: Parallelgcthreads=4 to specify the number of threads

3) Parallel GC

Use with concurrent GC for legacy generations

GC for old generation:

The old generation and the new generation, the object survival time is longer, more stable, so the mark (Mark) algorithm for recycling, so-called Mark is to scan out the surviving objects, and then to reclaim unmarked objects, after recycling the empty space is either merged, or marked out for the next allocation, The bottom line is to reduce the loss of efficiency caused by memory fragmentation. The JVM provides a serial GC (Serial MSC), parallel GC (parallel MSC), and concurrent GC (CMS) on the execution mechanism, and the details of the algorithm need to be further studied.

The various GC mechanisms above need to be combined, as specified in the following table:

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

The first thing to note is that when tuning the JVM memory, you can't just look at the memory used by the OS-level Java process, which is not exactly the actual occupancy of the reactor memory, because this value will not change after the GC, so memory tuning should use more memory viewing tools provided by the JDK. such as Jconsole and Java VisualVM.

System-level tuning of the JVM's memory is primarily intended to reduce the frequency of GC and the number of full GC times, and excessive GC and full GC will consume a lot of system resources (mainly CPU), affecting the throughput of the system. Pay particular attention to the full GC because it organizes the entire heap, resulting in a general GC due to the following situations:

• Insufficient space for old generation
  When tuning the object in the new generation of GC as far as possible to be recycled, so that the object in the Cenozoic to survive for a period of time and do not create too large objects and arrays to avoid creating objects directly in the old generation
• Pemanet Generation Space Shortage
  Increase Perm Gen space to avoid too many static objects
• The average size of a statistically obtained GC promoted to an old generation is greater than the remaining space of the old generation
  Control the proportions of the new generation and the old generation
• System.GC () is displayed call
  Garbage collection should not be triggered manually, depending on the JVM's own mechanism

Tuning is achieved by controlling the proportions of the various parts of the heap memory and the GC strategy, and the following is a look at the consequences of bad settings for each part

1) New generation set too small

First, the new generation of GC frequency is very frequent, increase the system consumption, the second is to cause large objects directly into the old generation, occupy the old generation of residual space, induce full GC

2) New generation set too large

First, the new generation has set up the General Assembly lead to the old generation too small (heap total), thus inducing full GC; second, the new generation of GC time-consuming significantly increased

In general, the new generation of the whole heap 1/3 more appropriate

3) Survivor set too small

Causes the object to reach the old generation directly from Eden, reducing the time to live in the Cenozoic

4) Survivor set too large

Causes Eden to be too small, increasing the GC frequency

In addition, the-xx:maxtenuringthreshold=n to control the generation of survival time, as far as possible to make objects in the new generation is recycled

Learn notes from the previous blog post (c)------memory management and garbage collection There are a variety of GC strategies and combinations for both the new generation and the old generation, and choosing these strategies is a challenge for us developers, and the JVM provides two simpler GC policy settings

1) Throughput priority

The JVM chooses the corresponding GC strategy and controls the size ratio of the Cenozoic and the old generation to achieve the throughput index. This value can be set by-xx:gctimeratio=n.

2) Pause time First

The JVM takes pause time as the indicator, chooses the corresponding GC strategy and controls the size ratio of the Cenozoic and the old generation, and tries to ensure that the application stop time caused by each GC is completed within the specified value range. This value can be set by-xx:maxgcpauseratio=n.

Finally, a summary of common JVM configuration

2. Heap Settings
   • -XMS: initial Heap Size
   • -XMX: Maximum Heap Size
   • -xx:newsize=n: Setting the young generation size
   • -xx:newratio=n: Sets the ratio of the younger generation to the older generation. such as: 3, the ratio of the young generation and the old generation is 1:3, the young generation of the entire young generation of old generation and 1/4
   • -xx:survivorratio=n: The ratio of Eden in the young generation to the two survivor districts. Note that there are two survivor districts. such as: 3, indicating Eden:survivor=3:2, a Survivor area accounted for the entire young generation of 1/5
   • -xx:maxpermsize=n: Setting the persistent generation size
4. Collector Settings
   • -XX:+USESERIALGC: Setting up the serial collector
   • -XX:+USEPARALLELGC: Setting up a parallel collector
   • -XX:+USEPARALLEDLOLDGC: Setting up a parallel old generation collector
   • -XX:+USECONCMARKSWEEPGC: Setting the concurrency Collector
6. Garbage collection Statistics
   • -xx:+printgc
   • -xx:+printgcdetails
   • -xx:+printgctimestamps
   • -xloggc:filename
8. Parallel collector settings
   • -xx:parallelgcthreads=n: Sets the number of CPUs to use when the parallel collector is collected. The number of parallel collection threads.
   • -xx:maxgcpausemillis=n: Set maximum pause time for parallel collection
   • -xx:gctimeratio=n: Sets the percentage of time that garbage collection takes to run the program. The formula is 1/(1+n)
10. Concurrent collector Settings
    • -xx:+cmsincrementalmode: Set to incremental mode. Applies to single CPU conditions.
    • -xx:parallelgcthreads=n: Set the concurrency collector the number of CPUs used by the young generation collection method for parallel collection. The number of parallel collection threads.

Report:

This series of learning materials are mainly from the PPT in the http://rednaxelafx.javaeye.com/blog/656951 and "distributed Java Applications" in the section on the JVM, we recommend that you continue to further study

JVM Learning Notes