GC、（四）GC Algorithms: Implementations

Now that we have reviewed the core concepts behind GC algorithms, let us move to the specific implementations one can find inside the JVM. An important aspect to recognize first is the fact that, for most JVMs out there, two different GC algorithms are needed – one to clean the Young Generation and another to remove garbage from the Old Generation.

You can choose from a variety of such algorithms bundled into the JVM. If you do not specify a Garbage Collection algorithm explicitly, a platform-specific default will be used. In this chapter, the working principles of each of those algorithms are explained.

For a quick cheat sheet, the following list is a fast way to get yourself up to speed with which algorithm combinations are possible. Note that this stands true for Java 8, for older Java versions the available combinations might differ a bit:

Young	Tenured	JVM options
Incremental	Incremental	-Xincgc
Serial	Serial	-XX:+UseSerialGC
Parallel Scavenge	Serial	-XX:+UseParallelGC -XX:-UseParallelOldGC
Parallel New	Serial	N/A
Serial	Parallel Old	N/A
Parallel Scavenge	Parallel Old	-XX:+UseParallelGC -XX:+UseParallelOldGC
Parallel New	Parallel Old	N/A
Serial	CMS	-XX:-UseParNewGC -XX:+UseConcMarkSweepGC
Parallel Scavenge	CMS	N/A
Parallel New	CMS	-XX:+UseParNewGC -XX:+UseConcMarkSweepGC
G1		-XX:+UseG1GC

If the above looks too complex, do not worry. In reality it all boils down to just four combinations highlighted in the table above. The rest are either deprecated, not supported or just impractical to apply in real world. So, in the following chapters we cover the working principles of the following combinations:

• Serial GC for both the Young and Old generations
• Parallel GC for both the Young and Old generations
• Parallel New for Young + Concurrent Mark and Sweep (CMS) for the Old Generation
• G1 in case of which the generations are not separated between the Young and Old

Serial GC

This Garbage Collectors combination of garbage collectors uses mark-copy in the Young Generation and mark-sweep-compact in Old generation. As the name implies – both of these collectors are single-threaded collectors, incapable of parallelizing the task at hand. Both of the collectors also trigger stop-the-world pauses, stopping all application threads.

This GC algorithm cannot thus take advantage of multiple cores commonly found in modern hardware. Independent of the number of cores available, just one is used by JVM during garbage collection.

Enabling this collector for both the Young and Old Generation is done via specifying a single parameter in the JVM startup script:

java -XX:+UseSerialGC com.mypackages.MyExecutableClass

This option is recommended and makes sense only for JVM with a couple of hundreds megabytes heap size running in a single CPU environment. For majority of the deployments this is a rare combination to find. Most server-side deployments are done on platforms with multiple cores, essentially meaning that by choosing Serial GC you are setting artificial limits on the use of system resources. This results in idle resources which otherwise could be used to reduce latency or increase throughput.

Let us now review how garbage collector logs look like when using Serial GC and what useful information one can obtain from there. For this purpose, we have turned on GC logging on the JVM using the following parameters:

–XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps

resulting in output similar to the following:

2015-05-26T14:45:37.987-0200: 151.126: [GC (Allocation Failure) 151.126: [DefNew: 629119K->69888K(629120K), 0.0584157 secs] 1619346K->1273247K(2027264K), 0.0585007 secs] [Times: user=0.06 sys=0.00, real=0.06 secs]
2015-05-26T14:45:59.690-0200: 172.829: [GC (Allocation Failure) 172.829: [DefNew: 629120K->629120K(629120K), 0.0000372 secs]172.829: [Tenured: 1203359K->755802K(1398144K), 0.1855567 secs] 1832479K->755802K(2027264K), [Metaspace: 6741K->6741K(1056768K)], 0.1856954 secs] [Times: user=0.18 sys=0.00, real=0.18 secs]

The short snippet from the GC logs exposes a lot of information about what is taking place inside the JVM. As a matter of fact, in this snippet there were two Garbage Collection events taking place, one of them cleaning the Young Generation and another taking care of the entire heap. Let’s start by analyzing the first collection that is taking place in the Young Generation.

Minor GC

Following snippet contains the information about a GC event cleaning the Young Generation:

2015-05-26T14:45:37.987-0200¹:151.126²:[GC³(Allocation Failure⁴) 151.126: [DefNew⁵:629119K->69888K⁶(629120K)⁷, 0.0584157 secs]1619346K->1273247K⁸(2027264K)⁹,0.0585007 secs¹⁰][Times: user=0.06 sys=0.00, real=0.06 secs]¹¹

1. 2015-05-26T14:45:37.987-0200 – Time when the GC event started.
2. 151.126 – Time when the GC event started, relative to the JVM startup time. Measured in seconds.
3. GC – Flag to distinguish between Minor & Full GC. This time it is indicating that this was a Minor GC.
4. Allocation Failure – Cause of the collection. In this case, the GC is triggered due to a data structure not fitting into any region in the Young Generation.
5. DefNew – Name of the garbage collector used. This cryptic name stands for the single-threaded mark-copy stop-the-world garbage collector used to clean Young generation.
6. 629119K->69888K – Usage of the Young Generation before and after collection.
7. (629120K) – Total size of the Young Generation.
8. 1619346K->1273247K – Total used heap before and after collection.
9. (2027264K) – Total available heap.
10. 0.0585007 secs – Duration of the GC event in seconds.
11. [Times: user=0.06 sys=0.00, real=0.06 secs] – Duration of the GC event, measured in different categories:
    • user – Total CPU time that was consumed by Garbage Collector threads during this collection
    • sys – Time spent in OS calls or waiting for system event
    • real – Clock time for which your application was stopped. As Serial Garbage Collector always uses just a single thread, real time is thus equal to the sum of user and system times.

From the above snippet we can thus understand exactly what was happening with the memory consumption inside JVM during the GC event. Before this collection, heap usage totaled at 1,619,346K. Out of this, the Young Generation consumed 629,119K. From this we can calculate the Old Generation usage being equal to 990,227K.

A more important conclusion is hidden in the next batch of numbers indicating that, after the collection, Young Generation usage decreased by 559,231K but total heap usage decreased only by 346,099K. From this we can again derive that 213,132K of objects were promoted from the Young Generation to the Old Generation.

This GC event is also illustrated with the following snapshots showing memory usage right before the GC started and right after it finished:

 

Full GC

After understanding the first minor GC event, lets look into the second GC event in the logs:

2015-05-26T14:45:59.690-0200¹:172.829²:[GC (Allocation Failure) 172.829: [DefNew: 629120K->629120K(629120K), 0.0000372 secs³]172.829:[Tenured⁴:1203359K->755802K⁵(1398144K)⁶,0.1855567 secs⁷]1832479K->755802K⁸(2027264K)⁹,[Metaspace: 6741K->6741K(1056768K)]¹⁰[Times: user=0.18 sys=0.00, real=0.18 secs]¹¹

1. 2015-05-26T14:45:59.690-0200 – Time when the GC event started.
2. 172.829 – Time when the GC event started, relative to the JVM startup time. Measured in seconds.
3. [DefNew: 629120K->629120K(629120K), 0.0000372 secs – Similar to the previous example, a minor garbage collection in the Young Generation happened during this event due to Allocation Failure. For this collection the same DefNew collector was run as before and it decreased the usage of the Young Generation from 629120K to 0. Notice that JVM reports this incorrectly due to buggy behavior and instead reports the Young Generation as being completely full. This collection took 0.0000372 seconds.
4. Tenured – Name of the garbage collector used to clean the Old space. The name Tenured indicates a single-threaded stop-the-world mark-sweep-compact garbage collector being used.
5. 1203359K->755802K– Usage of Old generation before and after the event.
6. (1398144K)– Total capacity of the Old generation.
7. 0.1855567 secs – Time it took to clean the Old Generation.
8. 1832479K->755802K – Usage of the whole heap before and after the collection of the Young and Old Generations.
9. (2027264K) – Total heap available for the JVM.
10. [Metaspace: 6741K->6741K(1056768K)] – Similar information about Metaspace collection. As seen, no garbage was collected in Metaspace during the event.
11. [Times: user=0.18 sys=0.00, real=0.18 secs] – Duration of the GC event, measured in different categories:
    • user – Total CPU time that was consumed by Garbage Collector threads during this collection
    • sys – Time spent in OS calls or waiting for system event
    • real – Clock time for which your application was stopped. As Serial Garbage Collector always uses just a single thread, real time is thus equal to the sum of user and system times.

The difference with Minor GC is evident – in addition to the Young Generation, during this GC event the Old Generation and Metaspace were also cleaned. The layout of the memory before and after the event would look like the situation in the following picture:

 

Parallel GC

This combination of Garbage Collectors uses mark-copy in the Young Generation and mark-sweep-compact in the Old Generation. Both the Young and Old collections trigger stop-the-world events, stopping all application threads to perform garbage collection. Both collectors run marking and copying / compacting phases using multiple threads, hence the notion ‘Parallel’. Using this approach, one can considerably reduce collection times.

The number of threads used during garbage collection is configurable via another command line option -XX:ParallelGCThreads=NNN . The default value is equal to the number of cores in your machine.

Enabling this option is done via specification of any of the following parameters combination in the JVM startup script, all of which select the same GC algorithms:

java -XX:+UseParallelGC com.mypackages.MyExecutableClass
java -XX:+UseParallelOldGC com.mypackages.MyExecutableClass
java -XX:+UseParallelGC -XX:+UseParallelOldGC com.mypackages.MyExecutableClass

Parallel Garbage Collector is suitable on multi-core machines in cases where your primary goal is to increase throughput. High throughput is achieved due effective usage of system resources:

• during collection, all cores are cleaning the garbage in parallel, resulting in shorter pauses
• between garbage collection cycles neither of the collectors is consuming any resources

On the other hand, as all phases of the collection have to happen without any interruptions, these collectors are still susceptible to long pauses during which your application threads are stopped and no actual work is being done. So in case latency is your primary goal, you should check the next combinations of garbage collectors.

Let us now review how garbage collector logs look like when using Parallel GC and what useful information one can obtain from there. For this, let’s look again at the garbage collector logs that expose once more one minor and one major GC pause:

2015-05-26T14:27:40.915-0200: 116.115: [GC (Allocation Failure) [PSYoungGen: 2694440K->1305132K(2796544K)] 9556775K->8438926K(11185152K), 0.2406675 secs] [Times: user=1.77 sys=0.01, real=0.24 secs]
2015-05-26T14:27:41.155-0200: 116.356: [Full GC (Ergonomics) [PSYoungGen: 1305132K->0K(2796544K)] [ParOldGen: 7133794K->6597672K(8388608K)] 8438926K->6597672K(11185152K), [Metaspace: 6745K->6745K(1056768K)], 0.9158801 secs] [Times: user=4.49 sys=0.64, real=0.92 secs]

Minor GC

The first of the two events indicates a GC event taking place in the Young Generation:

2015-05-26T14:27:40.915-0200¹:116.115²:[GC³(Allocation Failure⁴)[PSYoungGen⁵:2694440K->1305132K⁶(2796544K)⁷]9556775K->8438926K⁸(11185152K)⁹,0.2406675 secs¹⁰][Times: user=1.77 sys=0.01, real=0.24 secs]¹¹

1. 2015-05-26T14:27:40.915-0200 – Time when the GC event started.
2. 116.115 – Time when the GC event started, relative to the JVM startup time. Measured in seconds.
3. GC – Flag to distinguish between Minor & Full GC. This time it is indicating that this was a Minor GC.
4. Allocation Failure – Cause of the collection. In this case, the GC is triggered due to a data structure not fitting into any region in the Young Generation.
5. PSYoungGen – Name of the garbage collector used, representing a parallel mark-copy stop-the-world garbage collector used to clean the Young generation.
6. 2694440K->1305132K – usage of the Young Generation before and after collection
7. (2796544K) – Total size of the Young Generation
8. 9556775K->8438926K – Total heap usage before and after collection
9. (11185152K) – Total available heap
10. 0.2406675 secs – Duration of the GC event in seconds
11. [Times: user=1.77 sys=0.01, real=0.24 secs] – Duration of the GC event, measured in different categories:
    • user – Total CPU time that was consumed by Garbage Collector threads during this collection
    • sys – Time spent in OS calls or waiting for system event
    • real – Clock time for which your application was stopped. With Parallel GC this number should be close to (user time + system time) divided by the number of threads used by Garbage Collector. In this particular case 8 threads were used. Note that due to some activities not being parallelizable, it always exceeds the ratio by a certain amount.

So, in short, the total heap consumption before the collection was 9,556,775K. Out of this Young generation was 2,694,440K. This means that used Old generation was 6,862,335K. After the collection young generation usage decreased by 1,389,308K, but total heap usage decreased only by 1,117,849K. This means that 271,459K was promoted from Young generation to Old.

Full GC

After understanding how Parallel GC cleans the Young Generation, we are ready to look at how the whole heap is being cleaned by analyzing the next snippet from the GC logs:

2015-05-26T14:27:41.155-0200¹:116.356²:[Full GC³ (Ergonomics⁴)[PSYoungGen: 1305132K->0K(2796544K)]⁵[ParOldGen⁶:7133794K->6597672K⁷(8388608K)⁸]8438926K->6597672K⁹(11185152K)¹⁰,[Metaspace: 6745K->6745K(1056768K)]¹¹, 0.9158801 secs¹², [Times: user=4.49 sys=0.64, real=0.92 secs]¹³

1. 2015-05-26T14:27:41.155-0200 – Time when the GC event started
2. 116.356 – Time when the GC event started, relative to the JVM startup time. Measured in seconds. In this case we can see the event started right after the previous Minor GC finished.
3. Full GC – Flag indicating that the event is Full GC event cleaning both the Young and Old generations.
4. Ergonomics – eason for the GC taking place. This indicates that the JVM internal ergonomics decided this is the right time to collect some garbage.
5. [PSYoungGen: 1305132K->0K(2796544K)] – Similar to previous example, a parallel mark-copy stop-the-world garbage collector named “PSYoungGen” was used to clean the Young Generation. Usage of Young Generation shrank from 1305132K to 0, since after a Full GC the Young Generation is often left completely empty.
6. ParOldGen – Type of the collector used to clean the Old Generation. In this case, parallel mark-sweep-compact stop-the-world garbage collector named ParOldGen was used.
7. 7133794K->6597672K– Usage of the Old Generation before and after the collection
8. (8388608K) – Total size of the Old Generation
9. 8438926K->6597672K – Usage of the whole heap before and after the collection.
10. (11185152K) – Total heap available
11. [Metaspace: 6745K->6745K(1056768K)]– Similar information about Metaspace region. As we can see, no garbage was collected in Metaspace during this event.
12. 0.9158801 secs – Duration of the GC event in seconds
13. [Times: user=4.49 sys=0.64, real=0.92 secs] – Duration of the GC event, measured in different categories:
    • user – Total CPU time that was consumed by Garbage Collector threads during this collection
    • sys – Time spent in OS calls or waiting for system event
    • real – Clock time for which your application was stopped. With Parallel GC this number should be close to (user time + system time) divided by the number of threads used by Garbage Collector. In this particular case 8 threads were used. Note that due to some activities not being parallelizable, it always exceeds the ratio by a certain amount.

Again, the difference with Minor GC is evident – in addition to the Young Generation, during this GC event the Old Generation and Metaspace were also cleaned. The layout of the memory before and after the event would look like the situation in the following picture:

 

Concurrent Mark and Sweep

The official name of this garbage collectors combination is “Mostly Concurrent Mark and Sweep Garbage Collector”. It uses the parallel stop-the-world mark-copy algorithm in the Young Generation and the mostly concurrent mark-sweep algorithm in the Old Generation.

This collector was designed to avoid long pauses while collecting in the Old Generation. It achieves this by two means. Firstly, it does not compact the Old Generation but uses free-lists to manage reclaimed space. Secondly, it does most of job in the mark-and-sweep phases concurrently with the application. This means that garbage collection is not stopping the application threads completely and is using multiple threads to complete the collection. By default, the number of threads used equals ¼ of the number of physical cores of your machine.

This garbage collector can be chosen by specifying the following option on your command line:

java -XX:+UseConcMarkSweepGC com.mypackages.MyExecutableClass

This combination is a good choice on multi-core machines if your primary target is latency.  Decreasing the duration of the individual GC pause directly affects the way your application is perceived by end-users, giving them a feel of a more responsive application. As most of the time at least some part of the CPU is occupied by GC and not executing your application’s code, CMS generally provides worse throughput than Parallel GC.

As with previous GC algorithms, let us now see how this algorithm is applied in practice by taking a look at the GC logs that once again expose one minor and one major GC pause:

2015-05-26T16:23:07.219-0200: 64.322: [GC (Allocation Failure) 64.322: [ParNew: 613404K->68068K(613440K), 0.1020465 secs] 10885349K->10880154K(12514816K), 0.1021309 secs] [Times: user=0.78 sys=0.01, real=0.11 secs]
2015-05-26T16:23:07.321-0200: 64.425: [GC (CMS Initial Mark) [1 CMS-initial-mark: 10812086K(11901376K)] 10887844K(12514816K), 0.0001997 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
2015-05-26T16:23:07.321-0200: 64.425: [CMS-concurrent-mark-start]
2015-05-26T16:23:07.357-0200: 64.460: [CMS-concurrent-mark: 0.035/0.035 secs] [Times: user=0.07 sys=0.00, real=0.03 secs]
2015-05-26T16:23:07.357-0200: 64.460: [CMS-concurrent-preclean-start]
2015-05-26T16:23:07.373-0200: 64.476: [CMS-concurrent-preclean: 0.016/0.016 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]
2015-05-26T16:23:07.373-0200: 64.476: [CMS-concurrent-abortable-preclean-start]
2015-05-26T16:23:08.446-0200: 65.550: [CMS-concurrent-abortable-preclean: 0.167/1.074 secs] [Times: user=0.20 sys=0.00, real=1.07 secs]
2015-05-26T16:23:08.447-0200: 65.550: [GC (CMS Final Remark) [YG occupancy: 387920 K (613440 K)]65.550: [Rescan (parallel) , 0.0085125 secs]65.559: [weak refs processing, 0.0000243 secs]65.559: [class unloading, 0.0013120 secs]65.560: [scrub symbol table, 0.0008345 secs]65.561: [scrub string table, 0.0001759 secs][1 CMS-remark: 10812086K(11901376K)] 11200006K(12514816K), 0.0110730 secs] [Times: user=0.06 sys=0.00, real=0.01 secs]
2015-05-26T16:23:08.458-0200: 65.561: [CMS-concurrent-sweep-start]
2015-05-26T16:23:08.485-0200: 65.588: [CMS-concurrent-sweep: 0.027/0.027 secs] [Times: user=0.03 sys=0.00, real=0.03 secs]
2015-05-26T16:23:08.485-0200: 65.589: [CMS-concurrent-reset-start]
2015-05-26T16:23:08.497-0200: 65.601: [CMS-concurrent-reset: 0.012/0.012 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]

Minor GC

First of the GC events in log denotes a minor GC cleaning the Young space. Let’s analyze how this collector combination behaves in this regard:

2015-05-26T16:23:07.219-0200¹:64.322²:[GC³(Allocation Failure⁴) 64.322: [ParNew⁵:613404K->68068K⁶(613440K)⁷,0.1020465 secs⁸] 10885349K->10880154K⁹(12514816K)¹⁰,0.1021309 secs¹¹][Times: user=0.78 sys=0.01, real=0.11 secs]¹²

1. 2015-05-26T16:23:07.219-0200 – Time when the GC event started.
2. 64.322 – Time when the GC event started, relative to the JVM startup time. Measured in seconds.
3. GC – Flag to distinguish between Minor & Full GC. This time it is indicating that this was a Minor GC.
4. Allocation Failure – Cause of the collection. In this case, the GC is triggered due to a data structure not fitting into any region in Young Generation.
5. ParNew – Name of the collector used, this time it indicates a parallel mark-copy stop-the-world garbage collector used in the Young Generation, designed to work in conjunction with Concurrent Mark & Sweep garbage collector in the Old Generation.
6. 613404K->68068K – Usage of the Young Generation before and after collection.
7. (613440K)– Total size of the Young Generation.
8. 0.1020465 secs – Duration for the collection w/o final cleanup.
9. 10885349K->10880154K– Total used heap before and after collection.
10. (12514816K) – Total available heap.
11. 0.1021309 secs – The time it took for garbage collector to mark and copy live objects in the Young Generation. This includes communication overhead with ConcurrentMarkSweep collector, promotion of objects that are old enough to the Old Generation and some final cleanup at the end of the garbage collection cycle.
12. [Times: user=0.78 sys=0.01, real=0.11 secs] – Duration of the GC event, measured in different categories:
    • user – Total CPU time that was consumed by Garbage Collector threads during this collection
    • sys – Time spent in OS calls or waiting for system event
    • real – Clock time for which your application was stopped. With Parallel GC this number should be close to (user time + system time) divided by the number of threads used by the Garbage Collector. In this particular case 8 threads were used. Note that due to some activities not being parallelizable, it always exceeds the ratio by a certain amount.

From the above we can thus see that before the collection the total used heap was 10,885,349K and the used Young Generation share was 613,404K. This means that the Old Generation share was 10,271,945K. After the collection, Young Generation usage decreased by 545,336K but total heap usage decreased only by 5,195K. This means that 540,141K was promoted from the Young Generation to Old.

Full GC

Now, just as you are becoming accustomed to reading GC logs already, this chapter will introduce a completely different format for the next garbage collection event in the logs. The verbose output that follows consists of all the different phases of the mostly concurrent garbage collection in the Old Generation. We will review them one by one but in this case we will cover the log content in phases instead of the entire event log at once for more concise representation. But to recap, the whole event for the CMS collector looks like the following:

2015-05-26T16:23:07.321-0200: 64.425: [GC (CMS Initial Mark) [1 CMS-initial-mark: 10812086K(11901376K)] 10887844K(12514816K), 0.0001997 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
2015-05-26T16:23:07.321-0200: 64.425: [CMS-concurrent-mark-start]
2015-05-26T16:23:07.357-0200: 64.460: [CMS-concurrent-mark: 0.035/0.035 secs] [Times: user=0.07 sys=0.00, real=0.03 secs]
2015-05-26T16:23:07.357-0200: 64.460: [CMS-concurrent-preclean-start]
2015-05-26T16:23:07.373-0200: 64.476: [CMS-concurrent-preclean: 0.016/0.016 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]
2015-05-26T16:23:07.373-0200: 64.476: [CMS-concurrent-abortable-preclean-start]
2015-05-26T16:23:08.446-0200: 65.550: [CMS-concurrent-abortable-preclean: 0.167/1.074 secs] [Times: user=0.20 sys=0.00, real=1.07 secs]
2015-05-26T16:23:08.447-0200: 65.550: [GC (CMS Final Remark) [YG occupancy: 387920 K (613440 K)]65.550: [Rescan (parallel) , 0.0085125 secs]65.559: [weak refs processing, 0.0000243 secs]65.559: [class unloading, 0.0013120 secs]65.560: [scrub symbol table, 0.0008345 secs]65.561: [scrub string table, 0.0001759 secs][1 CMS-remark: 10812086K(11901376K)] 11200006K(12514816K), 0.0110730 secs] [Times: user=0.06 sys=0.00, real=0.01 secs]
2015-05-26T16:23:08.458-0200: 65.561: [CMS-concurrent-sweep-start]
2015-05-26T16:23:08.485-0200: 65.588: [CMS-concurrent-sweep: 0.027/0.027 secs] [Times: user=0.03 sys=0.00, real=0.03 secs]
2015-05-26T16:23:08.485-0200: 65.589: [CMS-concurrent-reset-start]
2015-05-26T16:23:08.497-0200: 65.601: [CMS-concurrent-reset: 0.012/0.012 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]

Phase 1: Initial Mark. This is one of the two stop-the-world events during CMS. The goal of this phase is to collect all Garbage Collector roots.

2015-05-26T16:23:07.321-0200: 64.42¹: [GC (CMS Initial Mark²[1 CMS-initial-mark:10812086K³(11901376K)⁴]10887844K⁵(12514816K)⁶,0.0001997 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]⁷

1. 2015-05-26T16:23:07.321-0200: 64.42 – Time the GC event started, both clock time and relative to the time from the JVM start. For the following phases the same notion is used throughout the event and is thus skipped for brevity.
2. CMS Initial Mark – Phase of the collection – “Initial Mark” in this occasion – that is collecting all GC Roots.
3. 10812086K – Currently used Old Generation.
4. (11901376K) – Total available memory in the Old Generation.
5. 10887844K – Currently used heap
6. (12514816K) – Total available heap
7. 0.0001997 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] – Duration of the phase, measured also in user, system and real time.

Phase 2: Concurrent Mark. During this phase the Garbage Collector traverses the Old Generation and marks all live objects, starting from the roots found in the previous phase of “Initial Mark”. The “Concurrent Mark” phase, as its name suggests, runs concurrently with your application and does not stop the application threads.

2015-05-26T16:23:07.321-0200: 64.425: [CMS-concurrent-mark-start]2015-05-26T16:23:07.357-0200: 64.460: [CMS-concurrent-mark¹:035/0.035 secs²][Times: user=0.07 sys=0.00, real=0.03 secs]³

1. CMS-concurrent-mark – Phase of the collection – “Concurrent Mark” in this occasion – that is traversing the Old Generation and marking all live objects.
2. 035/0.035 secs – Duration of the the phase, measuring elapsed time and wall clock time correspondingly.
3. [Times: user=0.07 sys=0.00, real=0.03 secs] – “Times” section is less meaningful for concurrent phases as it is measured from the start of the concurrent marking and includes more than just the work done for the concurrent marking.

Phase 3: Concurrent Preclean. This is again a concurrent phase, running in parallel with the application threads, not stopping them. Essentially it is another mark phase which will try to account references changed during previous mark phase.

2015-05-26T16:23:07.357-0200: 64.460: [CMS-concurrent-preclean-start]2015-05-26T16:23:07.373-0200: 64.476: [CMS-concurrent-preclean¹:0.016/0.016 secs²][Times: user=0.02 sys=0.00, real=0.02 secs]³

1. CMS-concurrent-preclean – Phase of the collection – “Concurrent Preclean” in this occasion – accounting for references being changed during previous marking phase.
2. 0.016/0.016 secs – Duration of the the phase, measuring elapsed time and wall clock time correspondingly.
3. [Times: user=0.02 sys=0.00, real=0.02 secs] – The “Times” section is less meaningful for concurrent phases as it is measured from the start of the concurrent marking and includes more than just the work done for the concurrent marking.

Just to bear in mind – in real world situation Minor Garbage Collections of the Young Generation can occur anytime during concurrent collecting the Old Generation. In such case the major collection records seen below will be interleaved with the Minor GC events covered in previous chapter.

Phase 4: Concurrent Abortable Preclean. Again, a concurrent phase that is not stopping the application’s threads. The full reasoning behind the phase is complex to say the least, but it would suffice to tell that the goal of this phase is to reduce the amount of work to be done in the next stop-the-world phase of final remark.

2015-05-26T16:23:07.373-0200: 64.476: [CMS-concurrent-abortable-preclean-start]2015-05-26T16:23:08.446-0200: 65.550: [CMS-concurrent-abortable-preclean¹:0.167/1.074 secs²] [Times: user=0.20 sys=0.00, real=1.07 secs]³

1. CMS-concurrent-abortable-preclean – Phase of the collection “Concurrent Abortable Preclean” in this occasion
2. 0.167/1.074 secs – Duration of the the phase, measuring elapsed and wall clock time respectively. It is interesting to note that the user time reported is a lot smaller than clock time. Usually we have seen that real time is less than user time, meaning that some work was done in parallel and so elapsed clock time is less than used CPU time. Here we have done a little amount of work – for 0.167 seconds of CPU time, and garbage collector threads just waited for something for almost a second, not doing any work.
3. [Times: user=0.20 sys=0.00, real=1.07 secs] – The “Times” section is less meaningful for concurrent phases, as it is measured from the start of the concurrent marking and includes more than just the work done for the concurrent marking.

Phase 5: Final Remark. This is the second and last stop-the-world phase during the event. The goal of this stop-the-world phase is to finalize marking all live objects in the Old Generations, including the references that were created/modified during previous concurrent marking phases.

Usually CMS tries to run final remark phase when Young Generation is as empty as possible in order to eliminate the possibility of several stop-the-world phases happening back-to-back.

This event looks a bit more complex than previous phases:

2015-05-26T16:23:08.447-0200: 65.550¹: [GC (CMS Final Remark²) [YG occupancy: 387920 K (613440 K)³]65.550:[Rescan (parallel) , 0.0085125 secs]⁴65.559: [weak refs processing, 0.0000243 secs]65.559⁵: [class unloading, 0.0013120 secs]65.560⁶: [scrub string table, 0.0001759 secs⁷][1 CMS-remark: 10812086K(11901376K)⁸]11200006K(12514816K) ⁹, 0.0110730 secs¹⁰] [[Times: user=0.06 sys=0.00, real=0.01 secs]¹¹

1. 2015-05-26T16:23:08.447-0200: 65.550 – Time the GC event started, both clock time and relative to the time from the JVM start.
2. CMS Final Remark – Phase of the collection – “Final Remark” in this occasion – that is marking all live objects in Old Generation, including the references that were created/modified during previous concurrent marking phases.
3. YG occupancy: 387920 K (613440 K) – Current occupancy and capacity of the Young Generation.
4. [Rescan (parallel) , 0.0085125 secs] – The “Rescan” completes the marking of live objects while the application is stopped. In this case the rescan was done in parallel and took 0.0085125 seconds.
5. weak refs processing, 0.0000243 secs]65.559 – First of the sub-phases that is processing weak references along with the duration and timestamp of the phase.
6. class unloading, 0.0013120 secs]65.560 – Next sub-phase that is unloading the unused classes, with the duration and timestamp of the phase.
7. scrub string table, 0.0001759 secs – Final sub-phase that is cleaning up symbol and string tables which hold class-level metadata and internalized string respectively. Clock time of the pause is also included.
8. 10812086K(11901376K) – Occupancy and the capacity of the Old Generation after the phase.
9. 11200006K(12514816K)– Usage and the capacity of the total heap after the phase.
10. 0.0110730 secs – Duration of the the phase.
11. [Times: user=0.06 sys=0.00, real=0.01 secs] – Duration of the pause, measured in user, system and real time categories.

After the five marking phases, all live objects in the Old Generation are marked and now garbage collector is going to reclaim all unused objects by sweeping the Old Generation:

Phase 6: Concurrent Sweep. Performed concurrently with the application, without the need for the stop-the-world pauses. The purpose of the phase is to remove unused objects and to reclaim the space occupied by them for future use.

2015-05-26T16:23:08.458-0200: 65.561: [CMS-concurrent-sweep-start]2015-05-26T16:23:08.485-0200: 65.588: [CMS-concurrent-sweep¹:0.027/0.027 secs²] [[Times: user=0.03 sys=0.00, real=0.03 secs]³

1. CMS-concurrent-sweep – Phase of the collection “Concurrent Sweep” in this occasion, sweeping unmarked and thus unused objects to reclaim space.
2. 0.027/0.027 secs – Duration of the the phase, measuring elapsed time and wall clock time correspondingly.
3. [Times: user=0.03 sys=0.00, real=0.03 secs]– “Times” section is less meaningful on concurrent phases, as it is measured from the start of the concurrent marking and includes more than just the work done for the concurrent marking.

Phase 7: Concurrent Reset. Concurrently executed phase, resetting inner data structures of the CMS algorithm and preparing them for the next cycle.

2015-05-26T16:23:08.485-0200: 65.589: [CMS-concurrent-reset-start]2015-05-26T16:23:08.497-0200: 65.601: [CMS-concurrent-reset¹:0.012/0.012 secs²] [[Times: user=0.01 sys=0.00, real=0.01 secs]³

1. CMS-concurrent-reset – The phase of the collection – “Concurrent Reset” in this occasion – that is resetting inner data structures of the CMS algorithm and preparing for the next collection.
2. 0.012/0.012 secs – Duration of the the phase, measuring elapsed and wall clock time respectively.
3. [Times: user=0.01 sys=0.00, real=0.01 secs] – The “Times” section is less meaningful on concurrent phases, as it is measured from the start of the concurrent marking and includes more than just the work done for the concurrent marking.

Just to bear in mind – in a real world situation Minor Garbage Collections in the Young Generation can occur anytime during concurrent collecting in the Old Generation. In such case the major collection records seen below will be interleaved with the Minor GC events covered in previous chapter.

G1

G1, called ‘Garbage First’ collector, uses a completely different heap layout than previous collectors. The design principles of the collector are also based on different assumptions than previous algorithms.

But when zooming out far enough, we can still say G1 is just a clever modification of the familiar mark-copy algorithm. It aims to replace CMS as a low-pause garbage collector in OpenJDK and as such sees a great deal of care nowadays. Almost every new version of Java 8 brings performance and stability improvements to G1. There are plans to make G1 the default garbage collector for the upcoming release of Java 9.

This garbage collector can be chosen by specifying the following option on your command line:

java -XX:+UseG1GC com.mypackages.MyExecutableClass

If you use the latest versions – Java 8 or 9 – G1 garbage collector can be a good choice for latency-constrained applications requiring high responsiveness. But you should test it carefully before using realistic usage scenarios as it is still not as mature and well-tested as CMS. In addition, there are limited possibilities and guidelines for tuning the performance of G1 garbage collector.

The details on the G1-specific behavior will be added to the handbook during the Q2 2015

From：https://plumbr.eu/handbook/garbage-collection-algorithms-implementations