Memory management for JVM exploration (III)

  

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

Memory management for JVM exploration (III)