A detailed explanation of the Java generation collection mechanism

The Java heap is the largest piece of memory space managed by the JVM. The primary storage object instance. In Java, the heap is divided into two areas: the New Generation (young), the older generation (old). Heap size = Cenozoic + old age; (1/3 of Cenozoic Jian space, old Dajian space 2/3) The Cenozoic is also divided into Eden, from Survivor and to Survivor (8:1:1); The new generation is divided to better manage the objects in the heap memory. Convenient GC Algorithm---replication algorithm for garbage collection. The JVM only uses Eden and one piece of survivor to serve the object at a time, so whenever there is a survivor space, there is only 90% of the actual free space available for the new generation. The New Generation GC (minor GC)----------refers to the garbage collection action that occurs in the Cenozoic, because most of the Java objects are in the nature of dying, so the minor GC is very trivial and uses a replication algorithm for fast recycling. The new generation is almost everywhere where Java objects are born, and Java objects request memory and storage in this place. When the object is in Eden (which includes a survivor, if it is from), the object survives after a minor GC and can be accommodated by another survivor (here Survivor is to), The copy algorithm is used to copy the surviving objects into the to Survior area, then the Eden and from survivor areas are cleared, and the surviving objects Age +1, and the object is incremented by 1 for each GC in survivor. When the age reaches a certain value (default 15, set by setting the parameter-xx:maxtenuringthreshold), these objects will become the old age!  But not necessarily, when some of the larger objects (which need to allocate contiguous memory space) go straight into the old age. The old age GC (major GC)----------refers to the garbage collection action that occurs in the old age, which is the tag used to organize the algorithm.  The old days are almost survivor through, they are not so easy to "die", so major GC does not want to minor GC as frequently. Why does the JVM need two Survivor of space?

We know that the current mainstream virtual machine implementation has adopted the idea of generational collection, the entire heap is divided into the new generation and the old age, and the new generation is divided into Eden space, from Survivor and to Survivor three block area.

When reading a question, why does it have to be two Survivor space? The answer to this question is actually equivalent to: why not 0 or 1 Survivor spaces? Why are 2 Survivor spaces up to the requirements?

Why not a 0 Survivor space?

This question is equivalent to: why Survivor space is needed. Let's see what the garbage collection will do if there is no Survivor space: Once the new generation of GC, regardless of 3,721, the living object all into the old age, even if it in the next several GC process is very likely to be recycled. In this way the old age is quickly filled up, and the frequency of full GC is greatly increased. We know that the old age is usually planned to be much larger than the Cenozoic, and it will take a long time to collect it, and it would be even worse if the frequency of collection is fast. Based on this consideration, the virtual machine introduces the concept of "surviving zone": If the object survives after a new generation GC, let it temporarily enter the surviving area; after each GC, the age of the object is +1, until its age reaches a certain set value (such as 15 years old), the JVM thinks it is probably an "old immortal" object, it is not necessary to stay in the surviving area (and the constant duplication between the two surviving areas requires resource depletion) before it is transferred to the old age.

In summary, the purpose of setting up the Survivor space is to get those medium-life objects to be killed as much as possible in Minor GC, ultimately reducing the impact of the virtual machine's garbage collection process on the user program.

Why not a 1 Survivor space?

One of the prerequisites for answering this question is that the new generation generally uses replication algorithms for garbage collection. The original copy algorithm was to split a piece of memory into two, the GC when the surviving objects (Eden and survivor to) were copied from a space (from spaces) to another space (to space), and then the original block of memory (from space) clean, and finally swapped Logical roles from space and to space (this can be done in the next GC as well).

We know that in the HotSpot virtual machine, the default ratio of Eden space and Survivor space is 8:1. Let's see what's wrong with this 8:1 in the case where there is only one Survivor space. For illustrative purposes here, we assume that the Cenozoic is 9 MB altogether. The object takes precedence over the Eden area, triggering the first Minor GC when the Eden Space is full of 8 MB. For example, if a 0.5 Mb object survives, the 0.5 MB object will be copied from the Eden zone to the Survivor zone. After this Minor GC, the Eden area was cleaned up, the Survivor area was occupied with 0.5 MB, and 0.5 MB was left. Everything is fine here, but the problem is coming: From now on, all objects will be allocated in the remaining 0.5 MB space, and will soon find out that there is not enough space to trigger the next Minor GC. It can be seen that in this case, when the Survivor space as the object "birthplace", it is very easy to trigger the Minor GC, this 8:1 asymmetric distribution not only can not reduce the overall frequency of Minor GC, but also the GC time interval is very uneven. Set Eden:survivor to 1:1 also, each time the total size of the object 5 MB must be triggered once the Minor GC, the only change is the GC interval is relatively average.

The above discussion is based on the established fact that "the new generation uses the replication algorithm" as a precondition. If this is not the case, for example, the new generation uses the "tag-clear" or "mark-and-sweep" algorithm to move the surviving objects, as if it were really just a Survivor. As to why the mainstream virtual machine implementations don't consider this approach, I'm not quite sure that there might be some difficulty, memory fragmentation, or implementation efficiency considerations.

Why are 2 Survivor spaces up to the requirements?

The problem is clear, regardless of how the Eden and Survivor ratios are set, in the case of only one Survivor, the overall view is that the Minor GC will be triggered when the new generation of space is half full. Does it have room for ascension? For example, will always trigger Minor GC when the new generation of space is over 80%?

In fact it can be done: we can set up two Survivor spaces (from Survivor and to Survivor). For example, we set the Eden:from survivor:to Survivor space Size to 8:1: 1, the object is always born in the Eden area, and the from Survivor saves the current surviving object, to Survivor is empty. After a GC occurs:
1) The Eden area Alive Object + from Survivor stored objects are copied to the to Survivor;
2) empty Eden and from Survivor;
3) Reverse the logical relationship from Survivor and to Survivor: from change to, to change from.

As you can see, the Minor GC is triggered only when the Eden space is almost full. Eden space accounts for the vast majority of the Cenozoic, so the frequency of Minor GC is reduced. Of course, the use of two Survivor this way we also pay a certain price, such as 10% of space waste, the cost of copying objects and so on.

Category: JVM

A detailed explanation of the Java generation collection mechanism