HotSpot JVM Garbage Collection principle

as we know, the Sun JVM divides the garbage collector into 3 pieces of heap space: Young Gen: The younger generation, which includes 1 Eden Districts and 2 suvivor areas, the newly created objects (most of which are short cycle objects) will enter this area, where virtual opportunities are frequently garbage collected. Old Gen: older generation, when the object in young Gen long enough (after several garbage collection still exist) or young Gen space is insufficient, the object will enter old Gen, because generally is the life cycle relatively long object, As a result, the virtual machine is less likely to reclaim this memory, and once recycled, it will be a time-consuming full GC, and the virtual machine will try to recycle the area once the heap space is low. Perm Gen: Persistent generation, some constant definitions and classes, method declarations, and their bytecode will all be placed in this area.

But in general,. ，。 The JVM does not first take the initiative to release Permspace space when Permspace space is insufficient.

So when the production phase, JBoss Server, JVM Permspace to set more points .... Because there are too many classes initialized with SSH too many frames,

Http://www.blogjava.net/jiangmin/articles/86145.html

HotSpot JVM Garbage Collection principle

Objective:

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

1 Most objects will not be used by any objects in a very short time after they are created, that is, they are 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".

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

Old generation: In the "Cenozoic" in the survival of a longer period of time objects 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".

To make the collection time as short as possible, the HotSpot JVM uses a mechanism called card table, which is shown in Figure 2 to avoid traversing the entire "generational generation" every time a collection is made.

Card table in Figure 2:hotspot

The mechanism of card-table 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 a generational garbage collection is that it can be set up with different garbage collection algorithms for each generation's specific characteristics. 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 Cenozoic

The "Cenozoic" is composed of 3 parts, see Figure 3. One Eden and two living areas (Survivor space),

Figure 3: Cenozoic composition

which

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 secondary collection, where the green part is an unused object

Figure 4: Collection again and again

(ie rubbish). 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: The garbage collector After the collection is completed

Sun'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

The 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 Collectors: 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 Collection

Synchronous Collector (Mostly-concurrent Collector): for some applications, the response speed is much 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: Synchronization Collector

The synchronization collector begins with a brief pause, marking the object that can quickly determine that it is not garbage. 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 cleanup in "the Generations"

There are several features of the synchronization collector compared to the serial collector and the parallel collector.

1) require the allocation of large heap;

2 The use efficiency of discontinuous space is low;

3) In some cases can significantly shorten the main collection to make application pause time. Appendix A: References

JVM Specification Second Edition

Http://java.sun.com/docs/books/vmspec/2nd-edition/html/VMSpecTOC.doc.html