G1 GC: Humongous Objects and Humongous Allocations

For Garbage First Garbage Collector (G1 GC), any object that is more than half a region size is considered a Humongous Object.   A humongous object is directly allocated into Humongous Regions.^[1]

In this article, we will discuss the following topics:

• Humongous regions and humongous allocations
• How humongous allocations impact G1's performance?
• How to detect humongous allocations?
• Basic Investigation
• Advanced Investigation

Humongous Regions and Humongous Allocations

A humongous object is allocated directly in the humongous regions. These humongous regions are a contiguous set of regions. StartsHumongous marks the start of the contiguous set and ContinuesHumongous marks the continuation of the set.

Before allocating any humongous region, the marking threshold is checked, initiating a concurrent cycle, if necessary. Dead humongous objects are freed at the end of the marking cycle during the cleanup phase also during a full garbage collection cycle (but, a new implementation has changed this; see the next section).

Since each individual set of StartsHumongous and ContinuesHumongous regions contains just one humongous object, the space between the end of the humongous object and the end of the last region spanned by the object is unused. For objects that are just slightly larger than a multiple of the heap region size, this unused space can cause the heap to become fragmented.

How Humongous Allocations Impact G1's Performance?

In the old implementation, humongous objects are not released until after a full concurrent marking cycle.^[4]  This is far from ideal for many transaction-based enterprise applications that create short-lived (i.e., in the transaction scope) humongous objects such as ResultSet(s) generated from JDBC queries.  This results in the heap filling up relatively quickly and leads to unnecessary marking cycles to reclaim them.

A new implementation since:

java version "1.8.0_40-ea"
Java(TM) SE Runtime Environment (build 1.8.0_40-ea-b02)
Java HotSpot(TM) 64-Bit Server VM (build 25.40-b05, mixed mode)

handles humongous regions differently and can reclaim them earlier if they are short-lived (see [4] for details).

For investigating humongous allocations in G1, you should begin with the following minimal set of VM options:

• -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintReferenceGC (-XX:+UseG1GC)

Basic Humongous Allocation Investigation

For basic humongous allocations investigation, you simply add a new option:

• -XX:+PrintAdaptiveSizePolicy

This option will print out something like below:

12025.832: [G1Ergonomics (Concurrent Cycles) request concurrent cycle initiation, reason: occupancy higher than threshold, occupancy: 3660578816 bytes, allocation request: 1048592 bytes, threshold: 3650722120 bytes (85.00 %), source: concurrent humongous allocation]

From the above, we saw a humongous allocation is initiated with a request size of 1048592 bytes. Note that our region size is 1MBytes in this test. So, the request object is considered as humongous (i.e., 1048592 Bytes > half of 1 MBytes).

In the output, you can also find the following entries:

      [Humongous Reclaim: 0.0 ms]
         [Humongous Total: 54]
         [Humongous Candidate: 0]
         [Humongous Reclaimed: 0]

This shows that there are 54 humongous regions found in this GC event.   Also, none of them were reclaimed in this GC event. The reason is that the current algorithm is relatively conservative and it skips humongous objects for reclamation if there are sparse references into them.  In the case that those references belongs to sparse table entries, G1 may improve the reclamation rate by discovering if they are actually not referenced at all after iterating the table.  A performance enhancement is pending for this effort now.^[5]

Advanced Humongous Allocation Investigation

To further investigate humongous allocation in more details, you can add:

-XX:+PrintAdaptiveSizePolicy -XX:+UnlockExperimentalVMOptions -XX:+G1ReclaimDeadHumongousObjectsAtYoungGC -XX:G1LogLevel=finest -XX:+G1TraceReclaimDeadHumongousObjectsAtYoungGC

Note that the following VM options are experimental:

• G1TraceReclaimDeadHumongousObjectsAtYoungGC^[4]
• G1ReclaimDeadHumongousObjectsAtYoungGC^[3]
• G1LogLevel (i.e., [fine|finer|finest])

So, that's why we added the unlock option;

-XX:+UnlockExperimentalVMOptions

With extra printing options, you will find detailed description of humongous allocations as shown below:

3708.669: [SoftReference, 0 refs, 0.0000340 secs]3708.669: [WeakReference, 1023 refs, 0.0001790 secs]3708.669: [FinalReference, 295 refs, 0.0007020 secs]3708.670: [PhantomReference, 0 refs, 0.0000060 secs]3708.670: [JNI Weak Reference, 0.0000140 secs]Live humongous 1 region 9 size 65538 with remset 1 code roots 0 is marked 0 live-other 0 obj array 0

Live humongous 1 region 10 size 88066 with remset 1 code roots 0 is marked 0 live-other 0 obj array 0
Live humongous 1 region 15 size 262146 with remset 1 code roots 0 is marked 0 live-other 0 obj array 1
...

Finally, you can also use Java Flight Recorder (JFR) and Java Mission Control (JMC) to get information about humongous objects by showing their allocation sources with stack traces.^[7]

References

1. Garbage First Garbage Collector Tuning
2. G1GC: Migration to, Expectations and Advanced Tuning
3. Thread local allocation buffers (TLAB's)
4. Early reclamation of large objects in G1
• Introduced since 8u40 b02 and 8u45
• Was not back ported to 8u20
5. Early reclaim of large objects that are referenced by a few objects
6. G1TraceReclaimDeadHumongousObjectsAtYoungGC
• JDK-8058801
• Prints information about live and dead humongous objects
• (Before bug fix) prints that information when there is at least one humongous candidate.
• (After bug fix) prints that information even when there is no humongous candidates; it also prints humongous object size in the output
7. Java Mission Control (JMC) and Java Flight Recorder (JFR)
8. Garbage-First Garbage Collector (JDK 8 HotSpot Virtual Machine Garbage Collection Tuning Guide)
9. Other JDK 8 articles on Xml and More
10. Concurrent Marking in G1

HotSpot: GC Worker Threads Used in CMS, Parallel, and G1 GC

As discussed in [1], the Java HotSpot virtual machine includes five garbage collectors (or GC):

• Serial Collector
• Parallel Collector (or throughput collector)
• Parallel Compacting Collector
• Concurrent Mark-Sweep (CMS) Collector
• Generation First (G1) Garbage Collector

Also, in [2], we have shown how to find the default HotSpot JVM values.  Some VM options are set from command line and some are set by GC's ergonomics.  However, all VM options are printed when you execute:

• -XX:+PrintFlagsFinal

Using G1 GC as an example, it uses SurvivorRatio, but not InitialSurvivorRatio, MinSurvivorRatio, or TargetSurvivorRatio.  In this article, we will show you one way to tell which VM option is used by which GC.

GC Threads

In [3], we have discussed the difference between Parallel Collectors and Concurrent Collectors.

Parallel collectors require stop-the-world pause for the whole duration of major collection phases (mark or sweep), but employ all available cores to compress pause time. Parallel collectors usually have better throughput, but they are not a good fit for pause critical applications. 

Concurrent collectors try to do most work concurrently (though they also do it in parallel on multi-core systems), stopping the application only for short duration. Note that the concurrent collection algorithm in JRockit is fairly different from both HotSpot's concurrent collectors (CMS and G1).

There are three kinds of GC threads utilized in HotSpot for CMS, Parallel, and G1 garbage collectors:

• ParallelGCThreads
• ConcGCThreads 
• G1ConcRefinementThreads

When you use PrintFlagsFinal to print out all JVM flags for CMS, Parallel or G1 GC.  The results are as follows:

CMS
    uintx ParallelGCThreads           = 23     {product}
    uintx ConcGCThreads               = 6      {product}
    uintx G1ConcRefinementThreads     = 0      {product}


Parallel GC
    uintx ParallelGCThreads           = 23     {product}
    uintx ConcGCThreads               = 0      {product}
    uintx G1ConcRefinementThreads     = 0      {product}

G1 GC
    uintx ParallelGCThreads           = 23     {product}
    uintx ConcGCThreads               = 6      {product}
    uintx G1ConcRefinementThreads     = 23     {product}

Based on JDK-8047976,^[4] it says that GC's normally don't update flags they do not use.  That's why we see "0" in some of the printouts.  To summarize, here are the GC worker threads used in CMS, Parallel, and G1 garbage collectors:

Garbage Collector	Worker Threads Used
CMS	ParallelGCThreads ConcGCThreads
Parallel	ParallelGCThreads
G1	ParallelGCThreads ConcGCThreads G1ConcRefinementThreads

Note that the above description is valid for the following JVM version or later ones:

java version "1.8.0_40-ea"
Java(TM) SE Runtime Environment (build 1.8.0_40-ea-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.40-b16, mixed mode)

Because JDK-8047976 bug,^[4] the behavior is different if you use earlier versions.

References

1. HotSpot VM Performance Tuning Tips (Xml and More)
2. What Are the Default HotSpot JVM Values? (Xml and More)
3. JRockit: Parallel vs Concurrent Collectors (Xml and More)
4. Ergonomics for GC thread counts should update the flags
5. Tuning that was great in old JRockit versions might not be so good anymore
   
• Trying to bring over each and every tuning option from a JR configuration to an HS one is probably a bad idea.
• Even when moving between major versions of the same JVM, we usually recommend going back to the default (just pick a collector and heap size) and then redoing any tuning work from scratch (if even necessary).
6. HotSpot VM options (JDK 8)

G1 GC: What Is "to-space exhausted" in GC Log?

As shown in [1], you can enable basic garbage collection (GC) event printing using two options:

• -XX:+PrintGCTimeStamps (or -XX:+PrintGCDateStamps) 
• -XX:+PrintGCDetails

These additional printing incurs minimal overhead while provide useful information for understanding the healthiness of your running garbage collector (e.g., Generation First GC).

In this article, we will discuss the significance of to-space exhausted events in your GC logs.

What Is "to-space exhausted"?

When you see to-space exhausted messages in GC logs, it means that G1 does not have enough memory for either survived or tenured objects, or for both, and the Java heap cannot be further expanded since it is already at its max.^[5]  This event only happens in mixed GC 's when G1 tries to copy live objects from the source space to the destination space.  Note that, in G1, it avoids heap fragmentation by compaction (i.e., done when objects are copied from source region to destination region).

Example message:

5843.494: [GC pause (G1 Evacuation Pause) (mixed)... (to-space exhausted), 0.1145790 secs]

When that happens, GC pause time will be longer (i.e., since both RSet and CSet^[5] need to be re-generated) and sometimes it may require a Full GC to resolve the issue. 

A Case Study of "to-space exhausted" Events

Using a benchmark with large live data size,^[3] a "to-space exhausted" event can be triggered if there is not enough breathing room for shuffling live data objects in the Java heap.  For example, we have a test case which its live data set occupies 68% of the Java heap at run time.  In a 4-hour run, we have seen the following sequence of events:

5843.494: [GC pause (G1 Evacuation Pause) (mixed)... (to-space exhausted), 0.1145790 secs]
5848.831: [GC pause (G1 Evacuation Pause) (mixed)... (to-space exhausted), 0.0847160 secs]
5856.640: [GC pause (G1 Evacuation Pause) (mixed)... 0.0864060 secs]
5866.182: [GC pause (G1 Evacuation Pause) (mixed)... 0.0821220 secs]
5875.550: [GC pause (G1 Evacuation Pause) (mixed)... 0.0549090 secs]
5882.353: [GC pause (G1 Evacuation Pause) (mixed)... 0.0827630 secs]
5896.331: [GC pause (G1 Evacuation Pause) (mixed)... 0.0632660 secs]
5901.966: [GC pause (G1 Evacuation Pause) (mixed)... 0.5356580 secs]
5902.813: [GC pause (G1 Evacuation Pause) (mixed)... (to-space exhausted), 1.3480320 secs]
5904.162: [Full GC (Allocation Failure) ... 5.0413590 secs]

A series of "to-space exhausted" events eventually led to a Full GC.  As discussed in [4], adding -Xmn400m on the command line to the same test case further add insult to injury—instead of seeing 3 "to-space exhausted" events, now we saw 20 of them.  This is due to we have further cut down the breathing room for G1.

How to Deal with "to-space exhausted" Events?

"to-space exhausted" events happen when G1 runs out of space (either survivor space or old space; see diagram above) to copy live objects to.  When it happens, sometimes G1's ergonomics can get by the issue by dynamically re-sizing heap regions.  If not, it eventually leads to a Full GC event.

When "to-space exhausted" events happen, it could mean you have a very tight heap allocated for your application.  The easiest approach to resolve this is increasing your heap size if it's possible. Alternatively, sometimes it's possible to tune G1's mixed GC to get by (see [4]). As shown in the above section, we have a high live data occupancy (i.e., 68%) in Java heap.  However, after tuning mixed GC, we can get by with a couple of Full GC's in a 4-hour run, which yields satisfactory result.

Note that mixed GC can clean up both young and old regions. If it does not take an old region, it would be a young(-only) GC. G1's mixed GC's are meant as a replacement for Full GC's. Instead of doing all the work at once, the idea is to achieve the same task in steps. Each small steps in mixed GC is smaller than a Full GC. Because G1 does not intend to reclaim all garbage as in a Full GC event, mixed GC uses less time.  However, Full GC is a compaction event which it can walk around "to-space exhausted" issue without needing extra space.

Acknowledgement

Some writings here are based on the feedback from Thomas Schatzl and Yu Zhang. However, the author would assume the full responsibility for the content himself.

References

1. g1gc logs - basic - how to print and how to understand
2. g1gc logs - Ergonomics -how to print and how to understand
3. JRockit: How to Estimate the Size of Live Data Set
4. JDK 8: Is Tuning MaxNewSize in G1 GC a Good Idea?
5. Garbage First Garbage Collector Tuning
• Note that "to-space overflow" message was removed and only "to-space exhausted" remains.
• RSet (Remembered Set)—Tracks object references into a given region. There is one RSet per region in the heap. The RSet enables the parallel and independent collection of a region. The overall footprint impact of RSets is less than 5%.
• CSet (Collection Set)—Are the set of regions that will be collected in a GC. All live data in a CSet is evacuated (copied/moved) during a GC. Sets of regions can be Eden, survivor, and/or old generation. CSets have a less than 1% impact on the size of the JVM. 
6. HotSpot Virtual Machine Garbage Collection Tuning Guide
7. Garbage-First Garbage Collector Tuning
8. Getting Started with the G1 Garbage Collector
9. Garbage-First Garbage Collector (JDK 8 HotSpot Virtual Machine Garbage Collection Tuning Guide)
10. Other JDK 8 articles on Xml and More
11. Concurrent Marking in G1

JDK 8: Is Tuning MaxNewSize in G1 GC a Good Idea?

For a throughput GC such as Parallel GC, it often helps performance by setting MaxNewSize (or -Xmn).  For G1 GC,^[1] is it the same? The short answer is yes/no and it depends (confession: I said "no" because I haven't done enough tests to exclude it).

In this article, we will demonstrate one case that setting MaxNewSize for G1 actually hurts the application's performance.  BTW, after benchmarking G1 in JDK 7, another author has claimed that:^[14]

• There is little to gain and much to lose from setting the new generation size explicitly.

Live Data Size

To tune the heap size of a Java Application, it's important to find out what its live data size is.  To learn how to estimate a Java application's live data size, read [2].  For the benchmark we are using, its live data size is around 1400 MB. With this benchmark, we are interested in knowing how G1 performs with MaxNewSize set to 400MB and Java heap set to 2GB.

Regularly we use the following settings for the G1 tuning:

• -Xms2g -Xmx2g -XX:+UseG1GC

plus some options for mixed GC (read [3]). So, for this experiment, we have added MaxNewSize setting like this:

• -Xms2g -Xmx2g -XX:+UseG1GC -Xmn400m

This has turned out hurting the performance a lot. Note that -Xmn400m is the optimal setting of our benchmark if Parallel GC is used.

Concurrent Cycle in G1 GC

G1 has four main operations:^[5]

• A young collection
• A background, concurrent cycle
• A mixed collection
• If necessary, a full GC

Without much ado, read [5-9] for the needed background of G1 GC.

G1 is a concurrent collector.  Its concurrent cycle has multiple phases—some of which stop all application threads (denoted by STW) and some of which do not:

• Initial-mark (STW)
• Denoted by: 
• [GC pause (G1 Evacuation Pause) (young) (initial-mark)
• [GC pause (Metadata GC Threshold) (young) (initial-mark)
• The G1 GC marks the roots during this phase. This phase is piggybacked on a normal (STW) young garbage collection.
• Root Region Scan
• Denoted by: 
• [GC concurrent-root-region-scan-start]
• [GC concurrent-root-region-scan-end
• The G1 GC scans survivor regions of the initial mark for references to the old generation and marks the referenced objects. 
• This phase runs concurrently with the application (not STW) and must complete before the next STW young garbage collection can start.
• Concurrent marking
• Denoted by:
• [GC concurrent-mark-start]
• [GC concurrent-mark-end
• The G1 GC finds reachable (live) objects across the entire heap. 
• This phase happens concurrently with the application, and can be interrupted by STW young garbage collections.
• Remark (STW)
• Denoted by:
• [GC remark
• This phase is STW collection and helps the completion of the marking cycle. 
• Finds objects that were missed by the concurrent mark phase due to updates by Java application threads to objects after the concurrent collector had finished tracing that object.
• G1 GC drains SATB buffers, traces unvisited live objects, and performs reference processing.
• Cleanup (STW)
• Denoted by:
• [GC cleanup 1936M->1931M(2048M)
• Prepare for next concurrent collection by clearing data structures.
• In this final phase, the G1 GC performs the STW operations of accounting and RSet scrubbing. 
• During accounting, the G1 GC identifies completely free regions and mixed garbage collection candidates. The cleanup phase is partly concurrent when it resets and returns the empty regions to the free list.
• Concurrent cleanup:
• Denoted by:
• [GC concurrent-cleanup-start]
• [GC concurrent-cleanup-end
• In this phase, G1 reclaims regions which were found empty during marking.
• Adds empty regions to the free list—i.e., thread local free lists are merged into global free list

G1 GC uses the Snapshot-At-The-Beginning (SATB) algorithm, which takes a snapshot of the set of live objects in the heap at the start of a marking cycle.  During the concurrent cycle, young garbage collections are allowed, which are triggered when eden fills up (note that initial-mark is implemented using a young collection cycle) .

The set of live objects after marking cycle is composed of the live objects in the snapshot, and the objects allocated since the start of the marking cycle. The G1 GC marking algorithm uses a pre-write barrier to record and mark objects that are part of the logical snapshot.

After the concurrent cycle, we expect to see:^[5]

• The eden regions before the marking cycle have been completely freed and new eden regions have been  allocated
• Old regions could be more occupied because the promotion of live objects from young regions
• Some old regions are identified to be mostly garbage and become candidates in later mixed or old collection cycles

Diagnosis

The reason of setting -Xmn400m has caused the regression of G1 is:

The option has forced G1 to use a young generation space of up to 400 MB and leaves G1 just 200 MB (i.e. 2048MB - 400MB - 1400MB) breathing room for shuffling live objects around.    

The small free space has negative impact on G1's concurrent cycles, which has caused most marking cycles not being completed in time.  

Before setting -Xmn400m on the command line, we have found only one instance of aborted marking cycle, which is denoted by:

• [GC concurrent-mark-abort]

After setting it, we have seen marking cycle was aborted 105 times out of 150 instances.  The lesson we have learnt here is that for a tight heap like our benchmark, it's not a good idea to set -Xmn400m for G1.  Without setting MaxNewSize, G1's ergonomics will dynamically adjust young generation space and it turns out that G1 can do a better job in this case.

Differences between Parallel GC and G1 GC

Note that -Xmn400m is the optimal setting for our benchmark if Parallel GC is used.  When we set MaxNewSize to be 400MB for G1, our benchmark regressed.  So, what's the difference between G1 GC and Parallel GC?

Initially, G1 GC was designed to replace CMS ^[10] for its relatively lower and more predictable pause times.  This is different from the design of Parallel GC which aims for higher throughput.  To help gain higher throughput, Parallel GC tries to:

• adjust young generation as large as possible and let it run into a full GC
• In our 4-hour experiments, we usually see around 50 full GC's in Parallel GC
• However, for G1's performance tuning, we want to avoid full GC's (see [11] for how)
• Which means more frequent full GC is expected
• Note that Parallel GC's Full GC pause time is shorter than G1's in the current JDK 8 releases

To conclude, if you upgrade JDK or switch garbage collector,^[7] always re-evaluate original optimal VM settings.

Acknowledgement

Some writings here are based on the feedback from Thomas Schatzl. However, the author would assume the full responsibility for the content himself.

References

1. Garbage First Garbage Collector Tuning
2. JRockit: How to Estimate the Size of Live Data Set
3. g1gc logs - basic - how to print and how to understand
4. g1gc logs - Ergonomics -how to print and how to understand
5. Java Performance: The Definitive Guide (Strongly recommended)
6. Garbage First Garbage Collector Tuning - Oracle
7. Our Collectors by Jon Masamitsu
8. Understanding Garbage Collection
9. HotSpot VM Performance Tuning Tips
10. Understanding CMS GC Logs
11. G1 GC: Tuning Mixed Garbage Collections in JDK 8
12. G1 GC Glossary of Terms
13. Learn More About Performance Improvements in JDK 8 
14. Benchmarking G1 and other Java 7 Garbage Collectors
15. HotSpot Virtual Machine Garbage Collection Tuning Guide
16. Getting Started with the G1 Garbage Collector
17. Garbage-First Garbage Collector (JDK 8 HotSpot Virtual Machine Garbage Collection Tuning Guide)
18. Other JDK 8 articles on Xml and More
19. Tuning that was great in old JRockit versions might not be so good anymore
    
    • Trying to bring over each and every tuning option from a JR configuration to an HS one is probably a bad idea.
    • Even when moving between major versions of the same JVM, we usually recommend going back to the default (just pick a collector and heap size) and then redoing any tuning work from scratch (if even necessary).

JDK 8: Thread Stack Size Tuning

When you upgrade JDK, you should re-examine all JVM options you have set in your Java applications.  For example, let's look at thread stack size tuning specifically.  As suggested in [1], it states:

• In most applications, 128k happens to be enough for the Java thread stack.

However, after setting that, we have run into the following fatal exception:

The stack size specified is too small, Specify at least 228k
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

In this article, we will discuss thread stack size tuning in JDK 8 (i.e., HotSpot VM).

Default Thread Stack Size

When a new thread is launched, the Java virtual machine creates a new Java stack for the thread. As mentioned earlier, a Java stack stores a thread's state in discrete frames.^[3] The Java virtual machine only performs two operations directly on Java Stacks: it pushes and pops frames.

The default thread stack size varies with JVM, OS and environment variables. To find out what your default ThreadStackSize is on your platform, use:^[1]

java -XX:+PrintFlagsFinal -version

A typical value is 512k. It is generally larger for 64bit JVMs because references are 8 bytes rather than 4 bytes in size (but, you can compress oops or class pointers if you choose).^[2] For example,^[4]

In Java SE 6, the default on Sparc is 512k in the 32-bit VM, and 1024k in the 64-bit VM. On x86 Solaris/Linux it is 320k in the 32-bit VM and 1024k in the 64-bit VM.

On Windows, the default thread stack size is read from the binary (java.exe). As of Java SE 6, this value is 320k in the 32-bit VM and 1024k in the 64-bit VM.

In JDK 8, every time the JVM creates a thread, the OS allocates some native memory to hold that thread’s stack, committing more memory to the process until the thread exits. Thread stacks are fully allocated (i.e., committed, not just reserved) when they are created.

This means that if your application spawns a lot of threads, this can consume a significant amount of memory which could otherwise be used by your application or OS (or it can eventually leads to OutOfMemoryError).

You can reduce your stack size by running with the -Xss option. For example:

java -server -Xss256k

or

java -server -XX:ThreadStackSize=256 

Note that if you have installed a 64-bit VM binary for Linux, you can omit -server option.^[5]

Virtual Memory Map

In JDK 8, HotSpot installation comes with a feature named Native Memory Tracking (default: disabled).  To enable it, use:

-XX:NativeMemoryTracking=[off|detail|summary]

After enabling NMT, you can examine the memory footprint taken by either Thread or Thread Stack using:

jcmd <pid> VM.native_memory [summary | detail | baseline | summary.diff | detail.diff | shutdown] [scale= KB | MB | GB]

 For example, on a 64-bit Linux platform, here is the thread stack size before and after setting -Xss256k:

Before

 Virtual memory map:

[0x0000000040049000 - 0x000000004014a000] reserved and committed 1028KB for Thread Stack from
    [0x00002aec741ca5e4] JavaThread::run()+0x24
    [0x00002aec74083268] java_start(Thread*)+0x108

After

Virtual memory map:

[0x0000000040078000 - 0x00000000400b9000] reserved and committed 260KB for Thread Stack from
    [0x00002b02c69156e4] JavaThread::run()+0x24
    [0x00002b02c67ce338] java_start(Thread*)+0x108

Conclusions

The thread stack is used to push stacks frames in nested method calls. If the nesting is so deep that the thread runs out of space, the thread dies with a StackOverflowError.^[8] If your applications use lots of recursive algorithms or if your applications are built on top of a framework utilizing MVC design pattern such as Oracle ADF, you may want to leave StackThreadSize as defaults.

However, thread stacks are quite large, particularly for a 64-bit JVM.  In [9], Scott Oaks has advised:

• As a general rule, many applications can actually run with a 128 KB stack size in a 32-bit JVM, and a 256 KB stack size in a 64-bit JVM.
• In a 64-bit JVM, there is usually no reason to set this value unless the machine is quite strained for physical memory and the smaller stack size will prevent applications from running out of native memory. 
• On the other hand, using a smaller (e.g., 128 KB) stack size on a 32-bit JVM is often a good idea, as it frees up memory in the process size and allows the JVM to utilize a larger heap.

Finally, the total footprint of the JVM has a significant effect on its performance. So, footprint is one aspect of Java performance that should be commonly monitored.

References

1. What Are the Default HotSpot JVM Values? 
2. JDK 8: UseCompressedClassPointers vs. UseCompressedOops
3. The Java Stack 
4. Frequently Asked Questions About the Java HotSpot VM 
5. HotSpot VM Binaries: 32-Bit vs. 64-Bit 
6. How to Debug Native OutOfMemory in JRockit 
7. HotSpot: Monitoring and Tuning Metaspace in JDK 8
8. Using -Xss to adjust Java default thread stack size to save memory and prevent StackOverflowError
9. Java Performance: The Definitive Guide (Strongly recommended)
10. Java thread stack size on 64-bit linux 
11. Learn More About Performance Improvements in JDK 8 
12. HotSpot Virtual Machine Garbage Collection Tuning Guide
13. Getting Started with the G1 Garbage Collector
14. Other JDK 8 articles on Xml and More
15. Tuning that was great in old JRockit versions might not be so good anymore
    
• Trying to bring over each and every tuning option from a JR configuration to an HS one is probably a bad idea.
• Even when moving between major versions of the same JVM, we usually recommend going back to the default (just pick a collector and heap size) and then redoing any tuning work from scratch (if even necessary).
16. HotSpot VM options (JDK 8)

G1 GC: Tuning Mixed Garbage Collections in JDK 8

To tune G1 GC (Garbage First Garbage Collector),  a place to start with is [1]. For the latest information, read [2].

Assuming you have minimal knowledge of G1 GC, the focus of this article is to tune the Mixed GC for better performance.

The Need to Tune Mixed GC

G1 GC is a generational garbage collector—read [3] to learn what eden, survivor, and old generation spaces are.  It also uses region-based architecture which divides large contiguous Java heap space into multiple fixed-sized heap regions.

The destination region for a particular object depends upon the object's age; an object that has aged sufficiently is evacuated to an old generation region (or promoted); otherwise, the object is evacuated to a survivor region and will be included in the CSet^[5] of the next young or mixed garbage collection.

During young collections, G1 GC adjusts its young generation (eden and survivor sizes) to meet its pause target. During mixed collections, the G1 GC adjusts the number of old gen regions that are collected based on a target number of mixed garbage collections, the percentage of live objects in each region of the heap, and the overall acceptable heap waste percentage (see details later).

Depending on your application's workload, Full GC could be expensive in G1 GC.  Since Mixed GC collects both young and old regions, you can get better performance by tuning Mixed GC—the goal is to reduce the number of Full GC's when your applications run.

More on Mixed Garbage Collections

Upon successful completion of a concurrent marking cycle, the G1 GC switches from performing young garbage collections to performing mixed garbage collections. In a mixed garbage collection, the G1 GC optionally adds some old regions to the set of eden and survivor regions that will be collected. The exact number of old regions added is controlled by a number of flags that will be discussed later. After the G1 GC collects a sufficient number of old regions (over multiple mixed garbage collections), G1 reverts to performing young garbage collections until the next marking cycle completes.

To summarize, Mixed GC can be characterized by:

• Collecting both young and old regions
• Denoted by: [GC pause (G1 Evacuation Pause) (mixed) in the GC log file^[2]
• Only after a completed marking cycle
• A sequence of mixed GC events to collect old regions, up to 8 by default

Tuning Mixed Garbage Collections

You can play with the following options to tune Mixed GC:^[1,2,4]

• -XX:InitiatingHeapOccupancyPercent 
• Percentage of the (entire) heap occupancy to start a concurrent GC cycle. It is used by GCs that trigger a concurrent GC cycle based on the occupancy of the entire heap, not just one of the generations.  The default value is 45.
• This option can be used to change the marking threshold
• If threshold is exceeded, a concurrent marking will be initiated next.
• The higher the threshold is, the less concurrent marking cycles will be, which also means the less mixed GC evacuation will be.
• -XX:G1MixedGCLiveThresholdPercent 
• This option can be used to change the threshold which determines whether a region should be added to the CSet or not.
• Only regions whose live data percentage are less than the threshold will be added to the CSet.
• The higher the threshold (default: 65) is, the more likely a region will be added to the CSet, which also means more mixed GC evacuation and longer evacuation time will happen. 
• -XX:G1HeapWastePercent
• Amount of reclaimable space, expressed as a percentage of the heap size that G1 will stop doing mixed GC's. If the amount of space that can be reclaimed from old generation regions compared to the total heap is less than this, G1 will stop mixed GC's.
• Current default is 10%.  A lower value, say 5%, will potentially cause G1 to add more expensive region(s) to evacuate for space reclamation.
• G1 will continue triggering mixed GC if the reclaimable is higher than the waste threshold.  So, there will be more mixed GC and maybe more expensive if you set this waste threshold lower.

Besides the above-mentioned options, you may also want to tune the following ones:

• -XX:G1MixedGCCountTarget 
• Sets the target number of mixed garbage collections after a marking cycle to collect old regions with at most G1MixedGCLIveThresholdPercent live data. 
• The default is 8 mixed garbage collections. The goal for mixed collections is to be within this target number.
• -XX:G1OldCSetRegionThresholdPercent
• Sets an upper limit on the number of old regions to be collected during a mixed garbage collection cycle. The default is 10 percent of the Java heap.
• -XX:G1HeapRegionSize
• Sets the size of a G1 region. The value will be a power of two and can range from 1MB to 32MB. 
• The goal is to have around 2048 regions based on the minimum Java heap size.

Conclusion

Each application is unique, you may need to tune G1 GC in an iterative process.  Note that all of the above options are product options except G1MixedGCLiveThresholdPercent and G1OldCSetRegionThresholdPercent, which are experimental options.  Be warned that: for the experimental options, Oracle may remove them at its discretion in the future releases.  

Acknowledgement

Some writings here are based on the feedback from Thomas Schatzl and Yu Zhang. However, the author would assume the full responsibility for the content himself.

References

1. Garbage First Garbage Collector Tuning
2. g1gc logs - Ergonomics -how to print and how to understand 
3. Understanding Garbage Collection  
4. Garbage First (G1) Garbage Collection Options
5. CSet
• The G1 GC reduces heap fragmentation by incremental parallel copying of live objects from one or more sets of regions (called Collection Set (CSet)) into different new region(s) to achieve compaction.
• The goal of G1 GC is to reclaim as much heap space as possible, starting with those regions that contain the most reclaimable space (i..e, garbage first), while attempting to not exceed the pause time goal.
6. G1 GC Glossary of Terms
7. Learn More About Performance Improvements in JDK 8 
8. HotSpot Virtual Machine Garbage Collection Tuning Guide
9. Garbage-First Garbage Collector (JDK 8 HotSpot Virtual Machine Garbage Collection Tuning Guide)
10. G1 GC: Humongous Objects and Humongous Allocations (Xml and More)
11. Other JDK 8 articles on Xml and More
12. Concurrent Marking in G1

JDK 8: Revisiting ReservedCodeCacheSize and CompileThreshold

In[1], someone has commented that:

Did you specify any extra JVM parameters to reach the state of full CodeCache? Some comments on the internet indicate this happens if you specify too low "-XX:CompileThreshold" and too much bytecode gets compiled by HotSpot very early.

when the following warning was seen:

VM warning: CodeCache is full. Compiler has been disabled.

In this article, we will look at tuning CompileThreshold and ReservedCodeCacheSize in JDK 8.

CompileThreshold

By default, CompileThreshold is set to be 10,000:

     intx CompileThreshold     = 10000       {pd product}

As described in [2], we know {pd product} means "platform-dependent product option".  Our platfrom is linux-x64 and that will be used for this discussion.

Very often, you see people setting the threshold lower.  For example

-XX:CompileThreshold=8000

Why?  Since the JIT compiler does not have time to compile every single method in an application, all code starts out initially running in the interpreter, and once it becomes hot enough it gets scheduled for compilation. To help determine when to convert bytecodes to compiled code, every method has two counters:

• Invocation counter
• Which is incremented every time a method is entered
• Backedge counter
•  Which is incremented every time control flow moves from a higher bytecode index to a lower one

Whenever either counter is incremented by the interpreter it checks them against a threshold, and if they cross this threshold, the interpreter requests a compile of that method.

The threshold used for the invocation counter is called the CompileThreshold, the backedge counter uses a more complex formula derived from CompileThreshold and OnStackReplacePercentage.  So, if you set the threshold lower, HotSpot compiles methods earlier.  And, in some cases, that can help the performance of server codes.

ReservedCodeCacheSize

A code cache is where JVM uses to store the native code generated for compiled methods.  As described in [3], to improve an application's performance, you can set the "reserved" code cache size:

• -XX:ReservedCodeCacheSize=256m

when tiered compilation is enabled for the HotSpot.  Basically it sets the maximum size for the compiler's code cache.  In [4], we have shown that an application can run faster if tiered compilation is enabled in a server environment.  However, code cashe size also needs to be specified larger.

What's New in JDK 8?

We have seen people setting the following JVM options:

• -XX:ReservedCodeCacheSize=256m -XX:+TieredCompilation

or

• -XX:CompileThreshold=8000 

in JDK 7.  In JDK 8, do we still need to set them?  The answer is that it depends on the platform.  On linux-x64 platforms, those setting are no longer necessary.  Here we will describe why.

In JDK 8, it chooses the following default values for linux-x64 platforms:

    bool TieredCompilation        = true       {pd product}     
    intx CompileThreshold         = 10000      {pd product}
    uintx ReservedCodeCacheSize   = 251658240  {pd product}

When tiered compilation is enabled, two things happen:

1. CompileThreshold is ignored
2. A bigger code cache is needed.  Internally, HotSpot will set it to be 240 MB (i.e., 48 MB * 5)

That's why we say that people don't need to set the following options anymore in JDK8:

• -XX:ReservedCodeCacheSize=256m -XX:+TieredCompilation 

or

• -XX:CompileThreshold=8000

Noted that “reserved” code cache is just an address space reservation, it does not really consume any additional physical memory unless it’s used.  On 64-bit platforms, it doesn’t hurt at all to set a higher value.  However, if you have set cache size to be too small, you will definitively see the negative impact on your application's performance.

Acknowledgement

Some writings here are based on the feedback from Igor Veresov and Vladimir Kozlov. However, the author would assume the full responsibility for the content himself.

References

1. VM warning: CodeCache is full. Compiler has been disabled.
2. HotSpot: What Does {pd product} Mean?  (Xml and More)
3. Performance Tuning with Hotspot VM Option: -XX:+TieredCompilation (Xml and More) 
4. A Case Study of Using Tiered Compilation in HotSpot  (Xml and More)
5. Useful JVM Flags – Part 4 (Heap Tuning)
6. g1gc logs - Ergonomics -how to print and how to understand 
7. G1 GC Glossary of Terms
8. Learn More About Performance Improvements in JDK 8 
9. HotSpot Virtual Machine Garbage Collection Tuning Guide
10. Other JDK 8 articles on Xml and More
11. Tuning that was great in old JRockit versions might not be so good anymore
    
    • Trying to bring over each and every tuning option from a JR configuration to an HS one is probably a bad idea.
    • Even when moving between major versions of the same JVM, we usually recommend going back to the default (just pick a collector and heap size) and then redoing any tuning work from scratch (if even necessary).

HotSpot: What Are Those GC Worker Threads in G1 GC?

On the Internet, you can find some tuning guides for Garbage First Garbage Collector (G1 GC)^[1,5,8,9] and some of them may be outdated.

In this article, we try to update some of those information with the focus on thread tuning.

Ergonomics

Ergonomics for servers was first introduced in Java SE 5.0^[2]. It has greatly reduced application tuning time for server applications, particularly with heap sizing and advanced GC tuning. In many cases no tuning options when running on a server is the best tuning you can do.

Here we will focus on the number of GC worker threads chosen to run on a specific server based on the ergonomics in G1 GC.

Garbage Collector	Worker Threads Used
Parallel	ParallelGCThreads
CMS	ParallelGCThreads ConcGCThreads
G1	ParallelGCThreads ConcGCThreads G1ConcRefinementThreads

G1 Threads

In the table below, we have summarized the most important GC worker threads in Oracle's G1 GC implementation. For comparison, Parallel GC only uses ParallelGCThreads and CMS only uses ParallelGCThreads and ConcGCThreads. Be warned that these values can be changed in the future if Oracle sees appropriate.

GC thread counts are based on the number of processors (including virtual processor if hyper-threading^[3] is enabled) reported by the system. To see the number of processors you have in the system, check out the file /proc/cpuinfo. In this article, 32 processors are used in the demonstration.

Name	Controlled by	Default if Not Specified	Description
Parallel GC Threads	-XX:ParallelGCThreads	if #proc <=8, then #proc; if #proc >8, 8+(#proc-8)*(5/8)	Parallel operations
Parallel Marking Threads	-XX:ConcGCThreads	There are lot of cases, but mostly it uses max((ParallelGCThreads+2)/4, 1)
G1 Main Concurrent Mark GC Thread		1	Master concurrent thread
G1 Concurrent Refinement Thread	-XX:G1ConcRefinementThreads	ParallelGCThreads+1	The +1 is the master thread which control these worker threads.

What Are They?

G1 garbage collection cycle has multiple phases: it starts with an initial marking phase and ends with a concurrent-cleanup phase. During the cycle, there are some phases that pause all the application threads, and some that run concurrently. These GC worker threads used in G1 GC include, but not limited to:

• ParallelGCThreads
• ParallelGCThreads are the threads employed during GC pauses
• They are responsible for copying (and scanning for) live objects during stop-the-world (or STW) pauses.
• They are also employed during other STW pauses (such as Remark and Cleanup).
• ConcGCThreads
• In concurrent marking, there is one controller thread and another bunch of worker threads. The number of worker threads is set using ConcGCThreads or a fraction of ParallelGCThreads if ConcGCThreads is not set.
• Worker threads are the threads used for marking and determining the liveness of regions, which are run concurrently to the application threads.
• Increasing ConcGCThreads will make the marking cycle complete faster.
• G1ConcRefinementThreads
• G1ConcRefinementThreads are the threads used for updating remembered set while application threads are running concurrently.
• They are responsible for taking the buffers that are used to log object updates and updating the RememberedSets (or RSets)^[10] based upon the updates.
• If G1ConcRefinementThreads is not set, then its value is ParallelGCThreads + 1.
• For example, if ParallelGCThreads is 23 then we will have 24 refinement threads.
• One is used for sampling and updating the RSets of young regions (typically young regions have less cross-region references so one thread is enough); the other 23 threads fill update buffers.
• Typically they don't all run at once.
• They each have a stepped activation threshold and a thread is activated when the number of completed buffers exceeds it's activation threshold.
• They also have deactivation thresholds and when the number of filled update buffers falls below a thread's deactivation threshold, it is deactivated.

Thread Tuning

For our server with 32 processors, the number of GC worker threads chosen by G1's ergonomics are:

• # ParallelGCThreads = 23
• # ConcGCThreads = 6
• # G1ConcRefinementThreads = 23

To find out what the GC worker thread counts are for your server, you can use -XX:+PrintFlagsFinal.^[4] You can also change the default values if you see appropriate.^[6,7] For some systems, default values sometimes can be too high.

References

1. Garbage First Garbage Collector Tuning (Published August 2013)
2. Java Heap Sizing: How do I size my Java heap correctly?
3. Intel® Hyper-Threading Technology
4. What Are the Default HotSpot JVM Values?
5. Part #1 - Tuning Java Garbage Collection for HBase
6. Linux: Understanding Processor Queue in Vmstat Output
7. How to Troubleshoot High CPU Usage of Java Applications? 
8. Getting Started with the G1 Garbage Collector 
9. G1: One Garbage Collector To Rule Them All 
10. Remembered Sets (RSets) in G1 GC
• G1 GC uses independent Remembered Sets (RSets) to track references into regions. Independent RSets enable parallel and independent collection of regions because only a region's RSet must be scanned for references into that region, instead of the whole heap. To achieve the task, G1 GC uses a post-write barrier to record changes to the heap and update the RSets. 
11. D. L. Detlefs, C. H. Flood, S. Heller, and T. Printezis. Garbage-First Garbage Collection. In A. Diwan, editor, Proceedings of the 2004 International Symposium on Memory Management (ISMM 2004), pages 37-48, Vancouver, Canada. October 2004. ACM Press.
12. T. Printezis and D. L. Detlefs. A Generational Mostly-Concurrent Garbage Collector. In A. L. Hosking, editor, Proceedings of the 2000 International Symposium on Memory Management (ISMM 2000), pages 134-154,Minneapolis, MN, USA, October 2000. ACM Press. 
13. g1gc logs - how to print and how to understand - basic 
14. G1 GC Glossary of Terms
15. Garbage-First Garbage Collector (JDK 8 HotSpot Virtual Machine Garbage Collection Tuning Guide)

Understanding String Table Size in HotSpot

In JDK-6962930^[2], it requested that string table size be configurable.  The resolved date of that bug was on 04/25/2011 and it's available in JDK 7.  In another JDK bug^[3], it has requested the default size (i.e. 1009) of string table be increased.

In this article, we will examine the following topics:

• What string table is
• How to find the number of interned strings in your applications
• The tradeoff between memory footprint and lookup cost

String Table

In Java, string interning^[1] is a method of storing only one copy of each distinct string value, which must be immutable. Interning strings makes some string processing tasks more time- or space-efficient at the cost of requiring more time when the string is created or interned. The distinct values are stored in a string intern pool, which is the string table in HotSpot.

The size of the string table (i.e., a chained hash table) is configurable in JDK 7.  When the overflow chains become long, performance can degrade.  The current default size of string table is 1009 (or 1009 buckets), which is too small for applications that stress the string table.  Note that the string table itself is allocated in native memory but the strings are java objects.

Increasing the size improves performance (i..e, reducing look-up cost) but increases the StringTable size by 16 bytes on 64-bit systems, 8 bytes on 32-bit systems for every additional entry.  For example, changing the default size to 60013 increases the String Table size by 460K on 32 bit systems.

Finding Number of Interned Strings in the Applications

In HotSpot, it provides a product level option named PrintStringTableStatistics which can be used to print hash table statistics^[4].  For example, using one of our applications (hereafter will be referred as JavaApp), it prints out the following information:

StringTable statistics:
Number of buckets  : 60013
Average bucket size  : 5
Variance of bucket size : 5
Std. dev. of bucket size: 2
Maximum bucket size  : 17

You can find the above output from your manged server's log file in the WebLogic domain.  Note that we have set the following option:

• -XX:StringTableSize=60013

So, there are 60013 buckets in the hash table (or string table).

In JDK, there is also a tool named jmap which can be used to find out number of interned strings in your application.  For example, we have found the following information using:

$ jdk-hs/bin/jmap -heap 18974
Attaching to process ID 18974, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 24.0-b43

using thread-local object allocation.
Parallel GC with 18 thread(s)

Heap Configuration:
   MinHeapFreeRatio = 40
   MaxHeapFreeRatio = 70
   MaxHeapSize      = 2147483648 (2048.0MB)
   NewSize          = 1310720 (1.25MB)
   MaxNewSize       = 17592186044415 MB
   OldSize          = 5439488 (5.1875MB)
   NewRatio         = 2
   SurvivorRatio    = 8
   PermSize         = 402653184 (384.0MB)
   MaxPermSize      = 402653184 (384.0MB)
   G1HeapRegionSize = 0 (0.0MB)

Heap Usage:
PS Young Generation
<deleted for brevity>

270145 interned Strings occupying 40429904 bytes.

Therefore, we know there are around 260K interned Strings in the table.

Tradeoff Between Memory Footprint and Lookup Cost

Based on curiosity, we have tried to set the string table size to be 277331 (a prime number) to see how JavaApp performs.  Here are our findings:

• Average Response Time: +0.75%
• 90% Response Time: +0.56%

However, the memory footprint has increased:

• Total Memory Footprint: -1.03%

Finally, here is the hash table statistics based on the new size (i.e., 277331):

StringTable statistics:
Number of buckets       :  277331
Average bucket size     :       1
Variance of bucket size :       1
Std. dev. of bucket size:       1
Maximum bucket size     :       8

The conclusion is that increasing string table size from 60013 to 277331 helps JavaApp's performance a little bit at the expense of larger memory footprint.  In this case, the benefit is minimal, keeping string table size to be 60013 is good enough.

References

1. String Interning (Wikipedia)
2. JDK 6962930 : make the string table size configurable
3. JDK 8009928: Increase default value for StringTableSize
4. Java GC tuning for strings
5. All other performance tuning articles on XML and More
6. G1 GC Glossary of Terms

HotSpot VM Performance Tuning Tips

In some cases, it may be obvious from benchmarking that parts of an application need to be rewritten using more efficient algorithms^[1]. Sometimes it may just be enough to provide a more optimal runtime environment by tuning the JVM parameters.

In this article, we will show you some of the HotSpot VM performance tuning tips.

What to tune?

You can tune HotSpot performance on multiple fronts:

• Code generation^[8,10]
• Memory management

In this article, we will focus more on memory management (or garbage collector).  The goals of tuning garbage collector include:

• To make a garbage collector operate efficiently, by
• Reducing pause time or
• Increasing throughput
• To avoid heap fragmentation
• Different garbage collector uses different compaction to eliminate fragmentation
• To make it scalable for multithreaded applications on multiprocessor systems

In this article, we will cover the following tuning options:

1. Client VM or Server VM
2. 32-bit VM or 64-bit VM
3. GC strategy
4. Heap sizing
5. Further tuning

Client vs. Server VM

The HotSpot Client JVM has been specially tuned to reduce application startup time and memory footprint, making it particularly well suited for client environments. On all platforms, the HotSpot Client JVM is the default.

The Java HotSpot Server VM is similar to the HotSpot Client JVM except that it has been specially tuned to maximize peak operating speed. It is intended for long-running server applications, for which the fastest possible operating speed is generally more important than having the fastest startup time. To invoke the HotSpot Server JVM instead of the default HotSpot Client JVM, use the -server parameter; for example,

• java -server MyApp

In [7], authors have mentioned a third HotSpot VM runtime named tiered.   If you are using Java 6 Update 25, Java 7, or later, you may consider using tiered server runtime as a replacement for the client runtime.   For more details, read [8,10].

32-Bit or 64-Bit VM

The 32-bit JVM is the default for the HotSpot VM. The choice of using a 32-bit or 64-bit JVM is dictated by the memory footprint required by the application along with whether any third-party software used in the application supports 64-bit JVMs and if there are any native components in the Java application. All native components using the Java Native Interface (JNI) in a 64-bit JVM must be compiled in 64-bit mode.

Running 64-bit VM has the following advantages^[7]:

• Larger address space
• Better performance in two fronts
• 64-bit JVMs can make use of additional CPU registers
• Help avoid register spilling
• Register spilling occurs where there is more live state (i.e. variables) in the application than the CPU has registers. 

and one disadvantage:

• Increased width for oops
• Results in fewer oops being available on a CPU cache line and as a result decreases CPU cache efficiency. 
• This negative performance impact can be mitigated by setting:
• -XX:+UseCompressedOops VM command line option

Note that client runtimes are not available in 64-bit HotSpot VMs.   See [11] for more details.

GC Strategy

JVM performance is usually measured by its GC's effectiveness.  Garbage collection (GC) reclaims the heap space previously allocated to objects no longer needed. The process of locating and removing those dead objects can stall your Java application while consuming as much as 25 percent of throughput.

The Java HotSpot virtual machine includes five garbage collectors.^[27] All the collectors are generational.

• Serial Collector
• Both young and old collections are done serially (using a single CPU), in a stop-the-world fashion.
• The old and permanent generations are collected via a mark-sweep-compact collection algorithm. 
• The sweep phase “sweeps” over the generations, identifying garbage. The collector then performs sliding compaction, sliding the live objects towards the beginning of the old generation space (and similarly for the permanent generation), leaving any free space in a single contiguous chunk at the opposite end.
• When to use
• For most applications that are run on client-style machines and that do not have a requirement for low pause times
• How to select
• In the J2SE 5.0 and above, the serial collector is automatically chosen as the default garbage collector on machines that are not server-class machines. On other machines, the serial collector can be explicitly requested by using the -XX:+UseSerialGC command line option.
• Parallel Collector (or throughput collector)
• Young generation collection
• Uses a parallel version of the young generation collection algorithm utilized by the serial collector
• It is still a stop-the-world and copying collector, but performing the young generation collection in parallel, using many CPUs, decreases garbage collection overhead and hence increases application throughput.
• Old generation collection
• Uses the same serial mark-sweep-compact collection algorithm as the serial collector
• When to use
• For applications run on machines with more than one CPU and do not have pause time constraints, since infrequent, but potentially long, old generation collections will still occur. 
• Examples of applications for which the parallel collector is often appropriate include those that do batch processing, billing, payroll, scientific computing, and so on.
• How to select
• In the J2SE 5.0 and above, the parallel collector is automatically chosen as the default garbage collector on server-class machines. On other machines, the parallel collector can be explicitly requested by using the -XX:+UseParallelGC command line option.
• Parallel Compacting Collector
• Young generation collection
• Use the same algorithm as that for young generation collection using the parallel collector.
• Old generation collection
• The old and permanent generations are collected in a stop-the-world, mostly parallel fashion with sliding compaction
• The collector utilizes three phases (see [5] for more details):
• Marking phase
• Summary phase
• Compaction phase
• When to use
• For applications that are run on machines with more than one CPU and applications that have pause time constraints.
• How to select
• If you want the parallel compacting collector to be used, you must select it by specifying the command line option -XX:+UseParallelOldGC.
• Concurrent Mark-Sweep (CMS) Collector^[5,6]
• Young generation collection
• The CMS collector collects the young generation in the same manner as the parallel collector. 
• Old generation collection
• Most of the collection of the old generation using the CMS collector is done concurrently with the execution of the application. 
• The CMS collector is the only collector that is non-compacting. That is, after it frees the space that was occupied by dead objects, it does not move the live objects to one end of the old generation. 
• To minimize risk of fragmentation, CMS is doing statistical analysis of object’s sizes and have separate free lists for objects of different sizes.
• When to use
• For application needs shorter garbage collection pauses and can afford to share processor resources with the garbage collector when the application is running. (Due to its concurrency, the CMS collector takes CPU cycles away from the application during a collection cycle.)
• Typically, applications that have a relatively large set of long-lived data (a large old generation), and that run on machines with two or more processors, tend to benefit from the use of this collector. 
• Compared to the parallel collector, the CMS collector decreases old generation pauses—sometimes dramatically—at the expense of slightly longer young generation pauses, some reduction in throughput, and extra heap size requirements.
• How to select
• If you want the CMS collector to be used, you must explicitly select it by specifying the command line option -XX:+UseConcMarkSweepGC.  
• If you want it to be run in incremental mode, also enable that mode via the  –XX:+CMSIncrementalMode option.
• This feature is useful when applications that need the low pause times provided by the concurrent collector are run on machines with small numbers of processors (e.g., 1 or 2).
• ParNewGC is the parallel young generation collector for use with CMS.  To choose it, you can specify the command line option  ‑XX:+UseParNewGC.
• Generation First (G1) Garbage Collector^[31]
• Summary
• Differs from CMS in the following ways
• Compacting
• Reduce fragmentation and is good for long-running applications 
• Heap is split into regions
• Easy to allocate and resize
• Evacuation pauses 
• For both young and old regions
• Young generation collection
• During a young GC, survivors from the young regions are evacuated to either survivor regions or old regions
• Done with stop-the-world evacuation pauses
• Performed in parallel
• Old generation collection
• Some garbage objects in regions with very high live ratio may be left in the heap and be collected later
• Concurrent marking phase
• Calculates liveness information per region
• Empty regions can be reclaimed immediately
• Identifies best regions for subsequent evacuation pauses
• Remark is done with one stop-the-world puase while initial mark is piggybacked on an evacuation pause
• No corresponding sweeping phase
• Different marking algorithm than CMS
• Old regions are reclaimed by
• Evacuation pauses
• Using compaction
• Where most reclamation is done
• Remark (when totally empty)
• When to use
• The G1 collector is a server-style garbage collector, targeted for multi-processor machines with large memories. It meets garbage collection (GC) pause time goals with high probability, while achieving high throughput. 
• How to select
• If you want the G1 garbage collector to be used, you must explicitly select it by specifying the command line option -XX:+UseG1GC.  

Note that the difference between:

• -XX:+UseParallelOldGC

and

• -XX:+UseParallelGC

is that -XX:+UseParallelOldGC enables both a multithreaded young generation garbage collector and a multithreaded old generation garbage collector, that is, both minor garbage collections and full garbage collections are multithreaded. -XX:+UseParallelGC enables only a multithreaded young generation garbage collector. The old generation garbage collector used with -XX:+UseParallelGC is single threaded. 

Using -XX:+UseParallelOldGC also automatically enables -XX:+UseParallelGC. Hence, if you want to use both a multithreaded young generation garbage collector and a multithreaded old generation garbage collector, you need only specify -XX:+UseParallelOldGC.

Note that the above distinction between -XX:+UseParallelOldGC and -XX:+UseParallelGC are no longer true in JDK 7.  In JDK 7, the following three settings are equivalent:

• Default
• -XX:+UseParallelGC
• -XX:+UseParallelOldGC

They all use multithreaded collectors for both young generation and old generation.

Heap Sizing

If a heap size is small, collection will be fast but the heap will fill up more quickly, thus requiring more frequent collections. Conversely, a large heap will take longer to fill up and thus collections will be less frequent, but they may take longer.

Command line parameters that divide the heap between new and old generations usually cause the greatest performance impact.  If you increase the new generation's size, you often improve the overall throughput; however, you also increase footprint, which may slow down servers with limited memory.

For more details, you can read [12-15].

Further Tuning

HotSpot's default parameters are effective for most small applications that require faster startup and a smaller footprint.  However, more often than not, you will find default settings are not good enough and need further tuning your Java applications.  As shown in [16], there are many VM options exoosed and can be further tuned by brave souls.  I'm not going to discuss such tunings in this article.  But, I'll keep on posting articles on this blogger with VM tunings.  Stay tuned!

References

1. Java Performance Tips
2. Pick up performance with generational garbage collection
3. Java HotSpot™ Virtual Machine Performance Enhancements
4. Oracle JRockit
5. Memory Management in the Java HotSpot™ Virtual Machine
6. Understanding GC pauses in JVM, HotSpot's CMS collector
7. Java Performance by Charlie Hunt and Binu John
8. Performance Tuning with Hotspot VM Option: -XX:+TieredCompilation
9. Java Tuning White Paper
10. A Case Study of Using Tiered Compilation in HotSpot
11. HotSpot VM Binaries: 32-Bit vs. 64-Bit
12. HotSpot Performance Option — SurvivorRatio
13. A Case Study of java.lang.OutOfMemoryError: GC overhead limit exceeded
14. Understanding Garbage Collection
15. Diagnosing Java.lang.OutOfMemoryError
16. What Are the Default HotSpot JVM Values?
17. Understanding Garbage Collector Output of Hotspot VM
18. On Stack Replacement in HotSpot JVM
19. Professional Oracle WebLogic Server by Robert Patrick, Gregory Nyberg, and Philip Aston
20. Sun Performance and Tuning: Java and the Internet by Adrian Cockroft and Richard Pettit
21. Concurrent Programming in Java: Design Principles and Patterns by Doug Lea
22. Capacity Planning for Web Performance: Metrics, Models, and Methods by Daniel A. Menascé and Virgilio A.F. Almeida
23. Java Performance Tuning (Michael Finocchiaro)
24. Diagnosing Heap Stress in HotSpot
25. Introduction to HotSpot JVM Performance and Tuning
26. Tuning the JVM (video)
• Frequency of Minhor GC dictated by:
• Application object allocation rate
• Size of Eden
• Frequency of object promotion dictated by:
• Frequency of minor GCs (tenuring)
• Size of survivor spaces
• Full GC Frequency dictated by
• Promotion rate
• Size of old generation
27. JEP 173: Retire Some Rarely-Used GC Combinations
28. G1 GC Glossary of Terms
29. Learn More About Performance Improvements in JDK 8 
30. Java SE HotSpot at a Glance
31. Garbage-First Garbage Collector (JDK 8 HotSpot Virtual Machine Garbage Collection Tuning Guide)
32. Tuning that was great in old JRockit versions might not be so good anymore
    
    • Trying to bring over each and every tuning option from a JR configuration to an HS one is probably a bad idea.
    • Even when moving between major versions of the same JVM, we usually recommend going back to the default (just pick a collector and heap size) and then redoing any tuning work from scratch (if even necessary).