Full GC

Full GC is a collection of the entire heap, including the new generation, the old generation, the permanent generation (in JDK 1.8 and later, the permanent generation will be removed and replaced with metaspace), and so on

What is the difference between RednaxelaFX Major GC and Full GC? What are the trigger conditions? – Zhihu has an answer to this question about GC classification:

In the implementation of HotSpot VM, there are actually two types of GC exactly:

  • Partial GC: does not collect patterns for the entire GC heap
    • Young GC: Collect only Young Gen’s GC, otherwise known as “Minor GC”.
    • Old GC: Only Old Gen GC is collected. Only the concurrent collection of the garbage collector CMS is in this mode
    • Mixed GC: Collects GC for all young Gen and part of old Gen. Only garbage collector G1 has this mode
  • Full GC: Collects all parts of the heap, including the new generation, old generation, and permanent generation (in JDK 1.8 and later, permanent generation was removed and replaced with metaspace metspace)

Trigger conditions for Full GC

The trigger conditions for Full GC may not be the same for different garbage collectors. According to the serial GC implementation of HotSpot VM, the trigger conditions are:

  • When preparing to trigger a Young GC, if the statistics show that the average promotion size of the previous young GC is larger than the remaining space of the current Old Gen, it will not trigger the Young GC but will trigger the full GC (because in the HotSpot VM GC, With the exception of concurrent collections from CMS, GCS that collect old Gen collect the entire GC heap at the same time, including Young Gen, so there is no need to prepare a separate Young GC beforehand.)

  • If there is a perm Gen, a full GC will also be triggered when the perm generation allocates space but runs out of space

  • System.gc(), heap dump with GC, both trigger full GC by default.

The trigger conditions for other non-concurrent GCS in HotSpot VM are a little more complicated, but the general principle is the same.

The Parallel Avenge collector, by default, executes a Young GC before firing the Full GC, and allows the application to run a little bit between GCS. In order to reduce the pause time of Full GC (because Young GC cleans up dead young Gen objects as much as possible, reducing full GC’s workload). The VM parameter that controls this behavior is: -xx :+ScavengeBeforeFullGC.

The trigger conditions for concurrent GC are different. Take THE CMS GC as an example, it mainly checks the usage of old Gen periodically, but when the usage exceeds the trigger ratio, the CMS GC will start a concurrent collection of old Gen.

Minor GC

Minor GC is commonly known as the garbage collection of the New generation (the new generation is divided into one Eden zone and two Survivor zones). The Minor GC is also covered by Oracle senior researcher Yudi Zheng in his Geek Time column, Taking Apart the Java Virtual Machine in Depth, as follows:

The trigger condition

What happens when Eden runs out of space? At this point, the Java virtual machine triggers a Minor GC to collect the new generation’s garbage, and the surviving objects are sent to the Survivor zone.

Minor GC is triggered when the New generation Eden field is full

The Minor GC process

As mentioned above, there are two Survivor zones in the new generation, and we use from and to to refer to them respectively. Where to points to an empty Survivor zone.

When a Minor GC occurs, surviving objects in the Eden region and Survivor region pointed to by FROM are copied (using a mark-copy algorithm here) into Survivor region pointed to by TO. The FROM and TO Pointers are then swapped to ensure that the next Minor GC, The Survivor zone to points to is still empty.

Note: From and to are just two Pointers that change, and the to pointer to the Survivor zone is empty

Conditions for Survivor zone objects to be promoted to older age objects

The Java virtual machine records how many times objects in the Survivor zone are copied back and forth. If an object has been copied 15 times (corresponding to the vm parameter -xx :+MaxTenuringThreshold) then the object will be promoted to old age. So only 15 is recorded at most). In addition, if a single Survivor zone is already 50% occupied (corresponding to the VM parameter: -xx :TargetSurvivorRatio), objects with higher replication times will also be promoted to the old age.

When a portion of a Survivor zone is promoted to the old age, the old age usage usually increases.

Note:

During a Minor GC, Survivor may not be sufficient to accommodate Eden and surviving objects in another Survivor. If the Survivor overflows, excess objects will be moved to the older generation, which is called Premature Promotion. This results in an increase of short-term survivable objects in the older generation, which may cause serious performance problems. Further, during the Minor GC, if the old age is too Full to hold any more objects, the Minor GC is usually followed by a Full GC, which results in traversing the entire Java heap, known as Promotion Failure. As for the solution, this involves tuning the application, which is not described here. If you are interested, please refer to the relevant resources

Minor GC problems and card table analysis

One problem with Minor GC is that older objects may refer to younger objects, and when marking a living object, you need to scan the older object, and if the object has a reference to the younger object, that reference is also counted as GC Roots. It’s like doing a full heap scan.

How does the JVM avoid Minor GC scanning the full heap

HotSpot’s solution is a technology called card tables. As shown below:

Card table of the specific strategy is to old s space into several size of 512 b card, and maintain a card table, the card table is an array of bytes, the province each element of the array corresponds to a card, is actually a logo, this logo delegates if corresponding card may be pointing in the direction of new generation object reference, if possible, So we consider the card to be dirty. As shown above, card Table 3 is marked as dirty.

During Minor GC, instead of scanning the entire age, we can look for dirty cards in the card table and add references from the old age to the new age to Minor GC Roots. When all dirty cards have been scanned, the Java virtual machine will clear out the identification bits of all dirty cards. In this way, VMS swap space for time, avoiding full table scan

A note on the Major GC

In addition to Full and Minor GC, there is another term called “Major GC” :

Major GC is usually equivalent to full GC, collecting the entire GC heap, but due to the development of HotSpot VM over the years, the interpretation of various terms has become completely confused. When someone says “Major GC”, be sure to ask whether they mean full GC or old GC

The above is the authoritative statement about Major GC by R University. There is another popular theory on the Internet that the Major GC is a collection of old garbage.

summary

The above content is basically a summary of the Full GC and Minor GC from R University’s Zhhu answer and geek Time column “In Depth Dismantling the Java Virtual Machine”.

Take the network, and then feedback of the network, I am for THE JVM is dregs level players, if there is a mistake, welcome to teach

References & acknowledgements

  • What is the difference between a Major GC and a Full GC? What are the trigger conditions? – Answer by RednaxelaFX
  • Geek Time: Taking Apart Java Virtual Machines in Depth
  • Talk about GC optimization of Java application from practical cases – Meituan technical team
  • 原 文-Minor GC vs Major GC vs Full GC