HotSpot JVM Garbage Collection principle

HotSpot JVM Garbage Collection principleObjective:This article describes the garbage collection work of Sun's hotspot Java Virtual machine. To bring more convenience and benefits to more Java enthusiasts in design, development, and deployment.Summary:The JVM specification requires that any implementation of the JVM must provide a mechanism to reclaim unused memory. This mechanism is garbage collection (Gc-garbage Collection). However, the design of garbage collection mechanism will directly affect the performance of Java applications that depend on its operation (including processing power, response time, etc.). The following chapters will detail the garbage collection mechanism in Sun's Java Virtual machine (its official name is the Sun hotsopt JVM).generation of garbage collection        hotspot The JVM uses the method of generational garbage collection. This garbage collection is not the first of the Hotspot JVM, but it is found in practice that the following two laws have been put forward at an early age. That is: 1 most objects in a very short time after the creation of the object will be no longer use it, that is not referenced by other objects. 2 Most objects that have been used (old objects) rarely refer to newly created objects. For Java applications, these two laws are always present, and some people call them "weak generational" according to these rules. Because the Java object is divided into "young" objects and "old" objects, there is not a very specific indicator but is controlled by the implementation of the JVM specification (and the JVM can also provide parameters for specific developers to set). The allocated memory heap (HEAP) in the hotspot JVM is divided into two physical areas, one is "young" and the other is the "old" area. Here I will "young" generation is called "Cenozoic", and corresponding to the "old" generation of objects called "Elder Generation". l        Cenozoic: The vast majority of newly created objects are stored here, and the area is generally relatively small and the frequency of garbage collection is relatively high. Because many objects are "dead" soon after they are created, there are very few objects that can "survive" after each "Cenozoic" garbage collection. This kind of garbage collection used in the "Cenozoic" is called Secondary garbage collection (Minor Collection). Because of the "Cenozoic" size (small, short addressing time) and the characteristics of its objects (short life, so there are a lot of garbage, each collection can release large memory space) makes the secondary garbage collection efficiency is very high. See Figure 1.   Figure 1: Generational garbage collection   l        old generation: The objects that survived for a long time in the "Cenozoic" will be promoted to "older" objects and transferred to the "elder generation" area. This area is generally larger and the rate of growth is slower than the "Cenozoic", so the primary garbage collection (Major Collection), which is responsible for the "old Generation" garbage collection, is much lower than the secondary garbage collection. The main garbage collection occurs when the objects in the "intergenerational generation" occupy a certain amount of storage space. See Figure 1. * For convenience, the secondary collection is used in the following sections to replace "secondary garbage collection" with primary collection instead of "primary garbage collection". In order to make the collection time as short as possible, the HotSpot JVM uses a mechanism called card table, shown in Figure 2, to avoid traversing the entire "generational generation" at each time of collection.”。 The card          card table mechanism in Figure 2:hotspot is to divide the "generation" into 512-byte units and each area is called a card. Each card has an identity that occupies one byte in the card table. In the process of executing Java code, once the JVM discovers that the object of the "new generation" references or releases the objects in the "Cenozoic", the JVM will place the state in the corresponding card table as the corresponding value. This will only traverse the card marked "dirty" at the time of collection so that you know which "Cenozoic" objects are referenced and cannot be recycled. The benefit of the          generational garbage collection is that it can be configured with different garbage collection algorithms based on the specific characteristics of each generation. Faster garbage collection algorithms are often used in the Cenozoic because of the high frequency of secondary collections. This algorithm has no advantage in the efficiency of memory, fortunately, the space of "Cenozoic" occupies a small proportion of the whole JVM memory heap, and it can't be a big problem to the performance. and memory efficiency of the algorithm is often used in the "Senior Generation" garbage collection. Because the "intergenerational generation" occupies a large part of the JVM heap. Although the "older generation" in the main collection of the collection time relative to the second collection is much longer, but the main collection in frequency than the collection of a lot less, so the impact on performance is not small. It is this new, "the generation" of the mutual complement is very good balance JVM garbage collection bottlenecks.the composition of the CenozoicThe "Cenozoic" is composed of 3 parts, see Figure 3. One Eden and two living areas (Survivor space), Figure 3: Cenozoic formation: L Eden: Most of the newly created objects are stored in this area. Why say the vast majority rather than all of them. The reason is that when you create a very large object, the JVM assigns it directly to the old generation rather than the new generation. The Eden area is always empty every time the collection is completed. L Survival zone: As the name suggests, objects that are not garbage collected during the garbage collection will be placed in the subregion. This means that the objects in this area have experienced at least a collection. The objects that store the surviving areas have a chance to be collected before being "promoted" to the former generation.   There is a pair of surviving areas, one of them remains empty and the other is used to store the surviving objects. Figure 4 depicts the collection process of the collection, where the green part is an unused object Figure 4: Collected (i.e. garbage) over and over again. You can see from the figure that the green part of the Eden area will be collected and the surviving objects (the white part) will be moved to 2 of the surviving areas that are not in use. The green portion of the Live Zone 1 is also an object that is not being used, and these objects will also be collected. The blue portion of the Live Zone 1, which is still referenced but not enough "old", will also move to the Live Zone 2.          The remainder of the surviving zone 1 is an object that is quoted and already "old", and they will be moved to an older generation. After the collection has been completed (see Figure 5), two surviving areas interact with the role. That is, the surviving Zone 2 will hold the surviving object, and the survival Zone 1 is not to be used. The Eden area will become empty. At the same time because of the new object moved to the generation, the generation of the space will be more objects occupy. Figure 5: After the collection is completedgarbage collectorSun's hotspot JVM provides 3 different garbage collectors. They can be used selectively according to the actual situation of the application. The following are described separately.Serial collector:Also known as the "tag-compress" collector. This collector requires the JVM to stop executing the application when it is collected. So people jokingly called this collection model Stop-the-world (stop everything). The JVM continues to perform the application after the collection is complete (see Figure 6). Figure 6: Serial collection serial collector first marks the surviving objects in the "intergenerational generation" and compresses them to the front end of the "intergenerational generation" space. Such "old generation" of the back end will become a continuous space, in order to from the "new generation" of the object of a smooth enough to "ascend" to the "Elder generation" (see Figure 7, red part of the garbage object). For most situations where a very rapid response, such as a client program, is not required, this collector is still capable. Figure 7: One-time compression for "the Next Generation"Parallel Collector:Most Java programs in the current application are running on servers with very large physical memory and multiple CPUs. In the ideal case, garbage collection should be able to effectively utilize all CPUs, instead of just one of them and the other CPUs are idle. To avoid excessive garbage collection to improve system throughput (that is, processing power), the Sun's hotsopt JVM uses a parallel collector for garbage collection in server-mode environments. Because one of the main goals of this garbage collector is to increase throughput, it is also called a throughput type collector. The parallel collector works by using all CPUs for parallel collection in the secondary collection (corresponding to the "Cenozoic"), using a serial collector in the Master collection (corresponding to the "Over Generation") (see Figure 8). Although there is no significant improvement in the master collection compared to the serial collector (since both use the same serial collector in the "generations"), the efficiency of the secondary collection is greatly improved. To improve the throughput of the system. Figure 8: Parallel CollectionSynchronization Collector ( mostly-concurrent Collector ) :For some applications, the response speed is far more important than throughput. The collector is a collector designed for low latency. In the Stop-the-world (stop All) collection mode that has been introduced, no response will be made to external requests until the garbage collection is complete, until the application is collected to continue responding to the request. This is generally not a long pause time for a second collection (because it often takes a very short time), but even if not very frequently, it can lead to a prolonged pause in the primary collection, especially when the JVM heap is allocated more heavily. To address this situation, the Sun JVM introduced the method of synchronizing collectors. This approach is also known as synchronous tagging-clear (CMS) or also called "low latency" collectors. Figure 9 shows how it works. Figure 9: The synchronization collector synchronization collector begins with a brief pause in which objects that can quickly determine not to be garbage are tagged. This is followed by the synchronization tag phase, in which the synchronization collector further marks the object being used and the application runs concurrently. The application may change the reference to some objects during the run, which makes it impossible to guarantee that all referenced objects are marked in the synchronization markup phase, and also causes the third phase-"re-tagging"-that must be done. In the re-tagging phase, the application will be put into a second pause, and the pause time synchronization collector will complete the markup for all objects. You can see that the parallel is used in the process of tagging, so the number of objects in this section is more than the markup in the initial phase. In the last phase, the synchronization collector clears the garbage objects from the "intergenerational generation" that were marked in the previous phases. However, the referenced object will not be placed in a contiguous space (see Figure 10, Orange is a garbage object, green is the collected free space). It can be seen that the free space in the "intergenerational generation" is not continuous, which will result in more time and resources to allocate space for the objects that are promoted to the "intergenerational generation". Figure 10: Synchronous scavenging in the "generational generation" compared to the serial collector and the parallel collector has several features. 1 The required heap size, 2 of the use of discontinuous space efficiency is low, 3 in some cases can significantly shorten the main collection to make applications pause time.Appendix A: ReferencesJVM Specification Second Edition http://java.sun.com/docs/books/vmspec/2nd-edition/html/VMSpecTOC.doc.html