JVM exploration memory management (3): jvm exploration Memory Management

JVM exploration memory management (3): jvm exploration Memory Management

In the previous section, we introduced the JVM garbage collection principles. There are also several garbage collection algorithms: tag-clearing algorithm, replication algorithm, tag sorting algorithm, and generational collection algorithm; now we will talk about the HotSpt garbage collector. This section will be just a theory.

Java Virtual Machine specifications have no specific provisions on the implementation of the garbage collector, so the Garbage Collector provided by virtual machines of different vendors and versions will be very different. The following describes only the HotSpt1.7 garbage collector.

HotSpotHeap splitting

HotSpt divides the memory space into several areas: the new generation, the old generation, and the permanent generation. In the previous section, we also mentioned that the main idea of the generational garbage collection algorithm is to group objects by their lifecycles;

 

For example, the JVM divides the heap into three major regions: Young, Old, and Perm, corresponding To objects not age. Then, it divides Young into three small blocks: Eden, hybrid vor From, and hybrid vor; objects stored in different regions are different as follows:

• Young DistrictAll newly created objects are stored in the Eden region. When the Eden is full, the minor GC will be triggered to copy the objects in the Eden to a same vor, then the other surviving vor object is copied to this directory, and the region of the same VOR is always null.
• Old DistrictIt stores objects that are still alive after minor GC is triggered when VOR is full. If the objects copied from Eden to vor cannot be saved, they can be directly stored in the Old area. When the Old zone is Full, Full GC is triggered to reclaim the entire heap memory.
• Perm ZonePerm also triggers Full GC for garbage collection.

 

Sun has suggested the size of each region. The Young region is 1/4 of the entire heap, the Young region is 1/8 of the Young region, and the visual VM tool is provided when JDK is installed, you can install the Visual GC plug-in to view the garbage collection in various regions of the JVM. You can see the memory size, GC time, used size, remaining size, and other information.

 

 

Garbage Collector

HotSpot provides seven types of garbage collectors: Serial collector, ParNew collector, Parallel Scavenge collector, Serial Old collector, Parallel Old collector, CMS collector, and G1 collector.

 

SerialThe collector is an old type of collector, but it is still a new generation of GC algorithm by default in the JVM client mode, and Serial is a single thread, it suspends all other work during garbage collection. Sum is called "Stop The World" until The collection task ends, serial then takes a lot of time to work, but it is relatively simple. In the case of a small New Generation of memory, the recovery time is still short enough to receive, basically within one second.

ParNewThe only difference between the Collector and Serial Collector is that Serial Collector is single-threaded, ParNew Collector is multi-threaded, and ParNew Collector is the default New Generation GC Algorithm in JVM Server mode.

Parallel ScavengeThe collector is also a new generation of collection algorithms. It uses the replication algorithm and parallel multithreading. Its advantage is to increase the throughput. The shorter the GC pause time, the higher the throughput,

Serial OldThe collector is an old version of Serial. It is a single thread and a "mark-organize" algorithm, which is used by virtual machines in Client mode.

Parallel OldThe collector is an old version of Parallel Scavenge. It uses multithreading and "tag-clearing algorithm ",

CMS(Concurrent Mark Sweep)The collector is based on the shortest pause time and is implemented using the "Mark clearing" algorithm. However, this collector is more complex than the previous collectors. the operation process involves the following steps:

1. initial mark (CMS initial mark)

2. concurrent mark (CMS concurrent mark)

3. Re-mark (CMS remark)

4. concurrent cleanup (CMS concurrent sweep)

During initial marking and re-marking, The system will "Stop The World". The initial mark indicates The objects that can be directly associated with GC Roots, and The concurrent mark will be used for GC Roots Tracing, re-marking fixes the tag changes caused by the continued running of the program. The problem with CMS is that CMS occupies a large amount of CPU because CMS uses the tag clearing algorithm, therefore, it may cause more fragments.

G1The algorithm exited when the collector JDK1.7 was released. It can be said that it is a relatively new technology and will not generate fragments compared to CMS G1, because it uses the "tag-sorting" algorithm, in addition, G1 can perform garbage collection without sacrificing throughput for a relatively precise space pause time. G1 divides the entire Java heap (New Generation and old generation) into multiple independent regions, track the degree of spam accumulation in these areas, and then maintain a priority list to recycle the most spam areas based on the allowed time.

 

Memory Allocation Policy

The memory allocation rule is not fixed. It depends on the parameter configuration of the Virtual Machine and the garbage collector combination used. Here we only talk about the most common memory allocation rules. Here we only talk about some theories.Next articleThe code will be used for verification.

EdenPriority allocation

In most cases, objects are allocated in the Eden region when they are created. When the space in the Eden is insufficient, the Minor GC is triggered,

Large objects directly enter the Old Age

Large objects: Java objects that require a large amount of continuous memory space are commonly used: long strings and arrays. When writing code, avoid short-lived large objects as much as possible, because large objects often cause GC.

Objects with long life cycle enter the Old Age

The idea of generational garbage collection is to manage objects separately based on their lifecycles. The virtual machine defines an object age counter for each object, the object remains alive after a Minor GC in the Eden region and is copied to the same vor. The age of the object is 1. Each time the object spends the Minor GC age in the same vor region, 1 is added, when the age reaches a certain value (15 by default), the object will be promoted to the old age. The threshold value can be set through parameters, which will be described later.

Dynamic age determination

The virtual machine cannot be changed to the old age only when it reaches the MaxTenuringThreshold age. For example, in the same age in the same vor space, the total size of all objects is greater than half of that in the same vor space, objects greater than or equal to this age can enter the old age without waiting for the specified age.

Space guarantee allocation

When the young generation experiences Minor GC, the virtual opportunity checks whether the average size of each promotion to the old age is greater than the remaining storage space in the old age. If the size of the remaining space is larger than that in the old age, the system changes to the direct Full GC, if it is small, check whether the HandlePromotionFailure setting allows guarantee failure. If it is small, only the Minor GC is performed. Otherwise, a Full GC is performed.

 

First Article address: Solinx

Http://www.solinx.co/archives/58

How to manage jvm memory

Typical settings:
• Java-Xmx3550m-Xms3550m-Xmn2g-Xss128k
-Xmx3550m: sets the maximum available JVM memory to 3550 MB.
-Xms3550m: Set JVM to enable the memory to be 3550 MB. This value can be set to the same as-Xmx to avoid JVM re-allocating memory after each garbage collection.
-Xmn2g: Set the young generation to 2 GB. Total heap size = size of the young generation + size of the old generation + size of the persistent generation. The permanent generation usually has a fixed size of 64 m. Therefore, increasing the size of the young generation will reduce the size of the old generation. This value has a great impact on the system performance. Sun officially recommends 3/8 of the total heap configuration.
-Xss128k: Set the stack size of each thread. After JDK 256, the size of each thread stack is 1 MB, and the size of each previous thread stack is K. The memory size required for more application threads is adjusted. Reduce this value to generate more threads in the same physical memory. However, the operating system still has a limit on the number of threads in a process. It cannot be generated infinitely. The experience is between 3000 and ~ About 5000.
• Java-Xmx3550m-Xms3550m-Xss128k-XX: NewRatio = 4-XX: Export vorratio = 4-XX: MaxPermSize = 16 m-XX: MaxTenuringThreshold = 0
-XX: NewRatio = 4: Set the ratio of the young generation (including Eden and two region vor regions) to the old generation (excluding the permanent generation ). If this parameter is set to 4, the ratio of the young generation to the old generation is, and the young generation accounts for 1/5 of the entire stack.
-XX: Region vorratio = 4: Set the ratio of Eden to region vor in the young generation. If this parameter is set to 4, the ratio of two vor zones to One Eden zone is, and one vor zone accounts for 1/6 of the young generation.
-XX: MaxPermSize = 16 m: sets the persistent generation size to 16 m.
-XX: MaxTenuringThreshold = 0: sets the maximum age of spam. If it is set to 0, the young generation object directly enters the old generation without going through the VOR area. For applications with many older generations, the efficiency can be improved. If this value is set to a greater value, the young generation object will be copied multiple times in the same vor area, which can increase the survival time of the young generation object, added an overview of being recycled in the young generation.

How to manage java JVM virtual memory

JVM memory management: goes deep into the garbage collector and memory allocation policies
There is a wall between Java and C ++ that is surrounded by the dynamic memory allocation and garbage collection technology. The people who look at it want to go in, but the people inside the wall want to come up with it.
Overview: when talking about Garbage Collection (GC), most people regard this technology as a companion product of the Java language. In fact, GC history is far older than Java. The Lisp, which was born in 1960 by MIT, is the first language that truly uses the dynamic memory allocation and garbage collection technology. When Lisp is still in the embryo, people are thinking about three things GC needs to do: What memory needs to be recycled? When will it be recycled? How to recycle it?
Call back the time from October 11 to the present and return to the familiar Java language. The first chapter of this article introduces each part of the Java memory runtime region, where the program counters, VM stacks, and local method stacks are generated with threads and destroyed with threads; frames in the stack are methodically launched into the stack as the method enters and exits; the amount of memory allocated in each frame is basically known when the Class file is generated (it may be optimized by JIT dynamic late compilation, but it can be considered as known during the compilation period ), therefore, the memory allocation and recovery in these regions are highly deterministic, so there is no need to consider the issue of recovery too much in these regions. The Java heap and the method area (including the runtime frequent pool) are different. We must wait until the program is actually running to know which objects will be created, the allocation and recovery of this part of memory are dynamic. The "Memory" Allocation and recovery we will discuss later only refer to this part of memory.
Reference Counting)
The original idea is that many textbooks use the following algorithm to determine whether an object is alive: Add a reference counter to the object. When there is a place to reference it, add 1 to the counter. When the reference fails, the counter minus 1. Objects whose counter is 0 at any time cannot be used again.
Objectively speaking, the reference counting algorithm is easy to implement and highly efficient in determination. In most cases, it is a good algorithm, but the reference counting algorithm cannot solve the problem of object circular reference. For example, the objects A and B have fields B and a, respectively. B = B and B. a = A. In addition, the two objects have no reference. In fact, the two objects cannot be accessed again, but the reference counting algorithm cannot recycle them.
Root search algorithm (GC Roots Tracing)
In actual production languages (Java, C #, and even the previously mentioned Lisp), the root search algorithm is used to determine whether an object is alive. The basic idea of the algorithm is to perform a downward search through a series of points called "GC Roots" as the starting point. When an object is connected to GC Roots, there is no Reference Chain, it proves that this object is unavailable. In Java, GC Roots includes:
1. Reference in VM stack (local variable in frame)
2. Static reference in the Method Area
3. References in JNI (the Native method in general)
Survival or death?