preface

  • We’ve seen the mechanics of garbage collection (algorithms). This article will show how garbage collection algorithms are implemented in the garbage collector.

  • There are several types of garbage collectors, none of which is perfect so far (if there were, there wouldn’t be so many types). The selection of the appropriate garbage collector is generally based on the actual business scenario.

Serial collector (-xx :+UseSerialGC -XX:+UseSerialOldGC)

  • The Serial collector is a single-threaded collector. Only one garbage collector thread works, and more importantly, it must Stop The World while it works. The new generation uses the tag copy algorithm and the old generation uses the tag collation algorithm

Parallerl Scavenge(-XX:+UseParallerlGC -XX:+UseParallerlOldGC)

  • Parallerl is the multithreaded version of Serial. Jdk1.8 default garbage collector. By default, the number of collected threads is the same as the number of CPU cores. (-xx :ParallerlGCThreads) The new generation uses the tag copy algorithm and the old generation uses the tag collation algorithm

  • The hallmark of Parallerl is that it has a different focus than other collectors. Collectors such as CMS focus on the pause time of user threads (user experience), and Parallerl focuses on achieving a controllable throughput.

throughput = Run user code time Run user code time + Run garbage collection time Throughput =\dfrac{run user code time}{run user code time + run garbage collection time}

ParNew(-XX:+UseParNewGC)

  • It’s similar to Parallerl, except that ParNew works with CMS (ParNew works with the new generation, CMS works with the old generation) and the new generation uses the mark copy algorithm, and the old uses the mark collation algorithm

CMS(-XX:+UseConcMarkSweepGC)

  • A CMS is a collector whose goal is to obtain the shortest collection pause time. For the first time in HotSpot, garbage collection threads actually work (basically) at the same time as user threads. Mark clearing algorithm
  • The whole work is divided into four steps
  1. Initial mark: Suspend all other threads (STW), record GC roots directly referencing objects, very fast.
  2. Concurrent marking: Traversing the entire object graph starting with gc roots directly referencing the object. It takes a long time but does not require the user thread to be paused, and it may cause changes in the state of marked objects because the user program is still in progress.
  3. Relabelling: Corrects the part of an object that changes the state of the mark caused by a user program during concurrent marking. This part of the pause is longer than the initial marking time and much shorter than the concurrent marking time. The incremental update algorithm in tricolor is used to re-mark.
  4. Concurrent cleanup: Start user threads and clean unmarked objects at the same time. At this stage, if a new object is created, it is marked black and nothing is done.
  5. Concurrent reset: Resets the marked data during this GC.

  • As you can see, CMS features are obvious: concurrent collection, low pauses. The disadvantages are also obvious:
  1. Sensitive to CPU resources and competing with services.
  2. Floating garbage cannot be handled (garbage generated during the concurrent tagging and concurrent cleanup phases will have to wait until the next GC).
  3. Due to the use of the tag cleaning algorithm, a large amount of debris is generated. Through – XX: UseCMSCompactAtFullCollection can collect again after finishing
  4. Uncertainties in the execution process. If the garbage collection is not completed and the garbage collection is executed again,In particular, the concurrent tagging and concurrent cleanup phasesA concurrent mode failure triggers a full GC, which enters the STW and is collected by the Serial Old garbage collector.
  • Instead of shortening the total STW time, CMS actually parallelizes most of the actions to the user so that the user is essentially unaware of the pause, especially when there is a lot of memory. Small memory (1~3G), with Parallerl on the line.
  • CMS core parameters:
  1. -xx :+UseConcMarkSweepGC: starts the CMS
  2. -xx :ConcGCThreads: indicates the number of concurrent GC threads
  3. – XX: + UseCMSCompactAtFullCollection: full gc after finishing
  4. – XX: CMSFullGCsBeforeCompaction: how many times full gc after finishing a, the default is 0, representing every full gc
  5. – XX: CMSInitiatingOccupancyFraction: when to use the old s reached the proportion triggered when full gc, defaults to 92 percentage.
  6. – XX: + UseCMSInitiatingOccupancyOnly: use only set recycling threshold (- XX: CMSInitiatingOccupancyFraction), if you don’t write this parameter, the first use of a JVM Settings, subsequent automatic adjustment.
  7. -xx :+CMSScavengeBeforeRemark: Starts a minor GC before the CMS GC. The purpose is to reduce references from the older generation to the younger generation and reduce the overhead of the CMS during the tagging phase, which usually takes 80% of the time.
  8. – XX: + CMSParallelInitialMarkEnabled: initial tag is multithreaded execution, shorten the STW
  9. -xx :+ CMSPARallelEnabled: Multi-threaded execution in the re-marking phase to shorten the STW

G1(-XX:+UseG1GC)

  • The G1 collector is designed for multi-processor and high-volume machines
  • G1 divides the heap into independent regions of equal size, and the JVM can have up to 2048 regions. The size of a normal Region is equal to the heap size /2048. You can also specify the Region size with the -xx :G1HeapRegionSize parameter.
  • In G1, the concept of Cenozoic era and old age still exists, but it is not a continuous space, but a collection of regions. The default new generation is 5% of the heap. To control the initial percentage, run -xx :G1NewPercent. During operation, the system adds regions to the new generation, up to 60%. You can use -xx :G1MaxNewPercent to adjust. The ratio of Eden to Survivor in the new generation is also 8:1:1.
  • A Region that starts as a new generation may become an old age after garbage collection.
  • The G1 turnstile sets the Humongous region for large objects. The rule for determining large objects is that the object size is greater than 50% of Region size. If an object is too large, it is stored across multiple Humongous regions. Humongous will also be collected in full GC.

  • The G1 works as follows:
  1. Initial mark (same as CMS) : Suspend all other threads (STW), record GC roots directly referencing objects, very fast.
  2. Concurrent markup (same as CMS) : Traverses the entire object graph starting with GC roots referencing the object directly. It takes a long time but does not require the user thread to be paused, and it may cause changes in the state of marked objects because the user program is still in progress.
  3. Final markup (same as CMS) : An object that corrects the part of the markup state change caused by a user program during concurrent markup. This part of the pause is longer than the initial marking time and much shorter than the concurrent marking time. The incremental update algorithm in tricolor is used to re-mark.
  4. Filter recovery: First, sort the recovery value and cost of each Region. The collection schedule is based on the pause time the user wants (-xx :MaxGCPauseMillis setting). For example, if 1000 regions are full and 500ms is required, but the user expects 100ms, only 300 regions will be reclaimed.
  • The reclamation algorithms of both the new generation and the old generation are labeled replication algorithms. Data from one Region is copied to another Region. Unlike CMS, memory fragmentation is almost non-existent in G1 Region.

  • In addition, G1 maintains a priority list in the background. According to the allowed time of each reclamation, regions with high reclamation value are preferentially selected. So it’s called G1(garbage-first). For example, a Region spends 100ms to reclaim 20m and another Region50ms can reclaim 40m. G1 preferentially reclaims the latter.
  • G1 features:
  1. Parallel concurrency: Make full use of cpus and use multiple cpus to shorten STW time.
  2. Generational collection: The concept of generational collection is retained
  3. Spatial integration: G1 marks the whole as a whole and replicates the algorithm locally.
  4. Predictable pauses: Pauses are specified with the -xx :MaxGCPauseMillis setting. Of course, it’s not just a matter of setting the expected value arbitrarily, and it’s not always as short as possible. If the collection time is too short to clean up enough space, the garbage will accumulate and eventually lead to full GC, which degrades performance. A range of 100 to 300 milliseconds is generally preferred.

G1 garbage collection classification

  • YoungGC

When the Eden area is full, G1 will not immediately YoungGC and calculate the reclamation time. If the time is far shorter than the expected time, a new Region will be added and continue to be given to new objects. YoungGC is triggered when the next time is near the expected time.

  • MixedGC

Not Full GC. Heap usage rate of the old s parameter (- XX: InitiatingHeapOccupancyPercent) when triggered. Reclaim all YoungGC and part of Old and large object areas. G1 garbage collection normally starts with MixedGC. The replication algorithm is mainly used. Copy surviving objects from each Region to another Region. If there are not enough regions to carry, the Full GC will be triggered.

  • Full GC

Stop the system program. A single thread is then used to mark, clean, and tidy up. Very time consuming.

G1 Collection Parameters

  • -xx :+UseG1GC: uses the G1 collector
  • -xx :ParallelGCThreads: Specifies the number of GC threads to work on
  • -xx :G1HeapRegionSize: specifies the partition size (1MB to 32MB, the value must be the NTH power of 2). The default partition size is 2048.
  • -xx :MaxGCPauseMillis: target pause time (200ms)
  • -xx :G1NewSizePercent: New generation memory initialization space (default heap 5%, used as integer, default percentage)
  • -xx :G1MaxNewSizePercent: indicates the maximum memory space of the new generation
  • -xx :TargetSurvivorRatio: fill capacity of Survivor zone (default: 50%). If the total number of Survivor objects with ages 1, 2 and N exceeds 50%, the Survivor object with ages n or older is added to the old age
  • -xx :MaxTenuringThreshold: maximum age threshold (default 15)
  • – XX: InitiatingHeapOccupancyPercent: old s heap usage rate of parameter triggered when 45% (the default), the implementation of the new generation and the old s collect MixedGC mixed.
  • – XX: G1MixedGCLiveThresholdPercent: 85% by default. Region is reclaimed only when the number of viable objects in the region is lower than this value.
  • -xx :G1MixedGCCountTarget: In a collection process, specify several filter collection times (default 8 times). In the last filter collection stage, recycle for a while, and then suspend the collection to resume the system operation, and recycle for a while, so as not to make the system single collection time too long.
  • -xx :G1HeapWastePercent: default 5%. During MixedGC, some regions will be empty. If the number of empty regions reaches 5% of the heap memory, collection will stop immediately.

G1 optimization

The core lies in tuning the -xx :MaxGCPauseMillis parameter. Too large a setting will result in too much garbage being cleaned up, leaving Survivor in place and going straight to the old age, frequently triggering MixedGC.

G1 Suitable scenario

  1. More than 50% of the heap is occupied by live objects
  2. The speed of object assignment and promotion varies greatly
  3. Garbage collection times are particularly long, exceeding 1 second
  4. More than 8GB heap memory
  5. Pause time within 500ms
  • Parallel for 4G below, ParNew+CMS for 4-8g, G1 for 8G above, ZGC for hundreds of G above

The difference between G1 using SATB and CMS using incremental updates

SATB is more efficient than incremental updates because the deleted objects do not need to be deeply scanned again during the relabeling phase. However, incremental update will perform deep scan on GC Roots. Many objects in G1 are located in different regions, so the cost of deep scan in G1 is higher than that in CMS.