Conquering Garbage Collection: JVM Tuning for Speed#

Java Heap and Non-Heap Memory#

The JVM divides its memory primarily into heap and non-heap areas:

• Heap Memory: This is where objects are allocated. Garbage collection primarily focuses on this region.
• Non-Heap Memory: This includes method area (for class structures), code cache, and other miscellaneous memory areas required by the JVM.

JVM Heap Subdivisions#

The heap is typically divided into specific regions or “generations” to make garbage collection more efficient:

1. Young Generation: Newly created objects go here. Since most objects die young, collecting them in a separate region reduces the cost of collecting older objects repeatedly.
   • Eden Space: Where most new objects first land.
   • Survivor Spaces (S0 and S1): Object “survivors” from Eden move here, potentially multiple times, before they graduate to the Old Generation.
2. Old (Tenured) Generation: Objects that survive multiple GC cycles in the young generation graduate here. The Old Generation is typically larger and collected less frequently.

Heap Sizing#

• -Xms: Sets the initial heap size.
• -Xmx: Sets the maximum heap size.

Finding the right balance between -Xms and -Xmx is one of the foundational tuning steps because an undersized heap can cause frequent garbage collections, and an oversized heap can lead to large, time-consuming pauses.

Serial Garbage Collector (Serial GC)#

• Name: -XX:+UseSerialGC
• Target Use Case: Small foot-print applications and single-threaded environments.
• Key Characteristics:
  • Uses a single thread for both young and old generation collections.
  • Simplicity leads to small overhead.
  • Not ideal for large, multi-core environments.

Parallel Garbage Collector (Parallel GC)#

• Name: -XX:+UseParallelGC
• Target Use Case: Throughput-oriented systems where you can tolerate some pause times, as long as overall throughput is maximized.
• Key Characteristics:
  • Multiple threads to handle garbage collection in Young Generation.
  • Parallel Old Generation collection is also available.
  • Can achieve high throughput but may incur longer pauses.

Concurrent Mark Sweep (CMS) Garbage Collector#

• Name: -XX:+UseConcMarkSweepGC
• Target Use Case: Systems requiring shorter GC pauses, often used in older Java versions.
• Key Characteristics:
  • Uses multiple threads to scan “live” objects.
  • Tries to minimize pauses by running most of GC concurrently with the application.
  • Longer concurrent phases can lead to complexities like CPU overhead.

Garbage-First (G1) Garbage Collector#

• Name: -XX:+UseG1GC
• Target Use Case: Balanced approach for large heaps with predictable pause times.
• Key Characteristics:
  • Splits the heap into regions (not strictly generational, though it has a concept of young and old regions).
  • Aims to meet a user-defined pause time goal, collecting regions with the most garbage first.
  • Excellent default for many modern Java applications.

Z Garbage Collector (ZGC)#

• Name: -XX:+UseZGC (requires certain Java versions and OS support)
• Target Use Case: Very large heaps (tens or hundreds of gigabytes) with minimal pauses.
• Key Characteristics:
  • Highly concurrent; aims for sub-10ms pause times.
  • Uses colored pointers and load barriers to handle concurrency.
  • A rapidly evolving collector that can handle extremely large heaps efficiently.

Shenandoah Garbage Collector#

• Name: -XX:+UseShenandoahGC
• Target Use Case: Similar to ZGC in goals, focusing on low pause times, but with some different trade-offs and design.
• Key Characteristics:
  • Concurrent GC that attempts near-pause-less collection.
  • Uses a Brooks Pointer for concurrent marking and compaction.
  • Suitable for substantial but not necessarily massive heaps.

The best GC choice depends on your application’s needs. For general purposes, G1 is often a strong default in recent JVM releases, but you might explore ZGC or Shenandoah if you need truly minimal pause times.

Using GC Logs#

The JVM can produce logs to track all garbage collection activities. Enabling GC logs gives you insights about:

• The frequency of GC events.
• The duration of each GC event.
• The amount of memory reclaimed.
• Which collector (young or old) triggered a particular event.

Common flags for enabling GC logs:

1
-Xlog:gc*:file=gc.log:time,uptime,level,tags

You can then analyze the GC logs using tools like:

• GCViewer
• Garbage Cat

Mission Control and VisualVM#

• Java Mission Control (JMC): A powerful, official profiling tool that lets you visualize GC cycles, memory usage, CPU usage, and more.
• VisualVM: Another GUI-based tool for monitoring heap, CPU, threads, and the GC in near real time.

Performance Metrics#

Key performance metrics you should watch:

• GC Throughput: Percentage of total time spent in garbage collection vs. total run time.
• GC Pause Time: Sum of all the stop-the-world pauses. Lower is better for low-latency systems.
• Frequency of Collections: Frequent GC cycles might indicate an undersized heap or memory leaks.
• Allocation Rate: How quickly your application is allocating new objects. High allocation rates drive more frequent GCs.

1. Heap Sizing#

One of the first steps in tuning garbage collection is adjusting the heap size:

• Keep -Xms and -Xmx the same: This prevents the JVM from having to resize the heap, which can introduce extended full GCs.
• Estimate memory requirements: Observe how much memory your application needs under normal and peak load, then add a buffer.

Example:

1
-Xms2g
2
-Xmx2g

Setting both to 2GB can be a good starting point if your application typically uses around 1GB of memory. Adjust accordingly based on your observations.

2. New Generation Sizing#

• -XX and -XX (or -Xmn) control the size of the young generation. A well-sized young generation can dramatically reduce how often objects move to the old generation.
• Too small a young generation will cause frequent minor GCs. Too large a young generation might lead to longer minor GCs, though it can reduce major GCs.

Basic rule of thumb is to have the young generation be about one-third of your total heap size. However, this is highly application-specific, so always test with real workloads.

3. Choosing the Garbage Collector#

If you are using Java 8 or older, you might start with:

1
-XX:+UseG1GC

If you are on a more recent version (Java 11 or above), G1 might already be the default. You can experiment with:

1
-XX:+UseZGC

if low-latency is extremely important and your Java version supports ZGC.

4. Basic GC Logging#

Put this in your JVM options for better visibility into what’s happening:

1
-Xlog:gc*:file=gc.log:time,uptime,level,tags

Analyzing gc.log is often the first step in any GC tuning endeavor.

5. Observing GC Patterns#

Look out for:

• Long Pause Time: Possibly an indication that the Old Generation is too large or that concurrent tasks cannot keep pace with allocation.
• High Collection Frequency: May suggest the Young Generation is too small or your application is allocating objects at a remarkable rate.

1. GC Ergonomics and Goals#

Modern collectors like G1 and ZGC allow you to specify desired pause times or throughput goals. For G1, you might use:

1
-XX:MaxGCPauseMillis=200

This hints to the JVM that you want garbage collection pauses not to exceed 200ms if possible. The JVM will then adjust internal parameters (like region sizing) to try to meet that goal, though it’s not guaranteed.

2. Tuning Concurrent Threads#

Collectors such as CMS, G1, Shenandoah, and ZGC use concurrent marking threads. You can fine-tune the number of threads dedicated to concurrent operations:

1
-XX:ParallelGCThreads=8
2
-XX:ConcGCThreads=4

These values control how many threads are used during different parts of the GC cycle. Over-allocating threads can degrade overall performance if your system doesn’t have enough CPU cores to handle the extra concurrency.

3. Large Pages#

Using large memory pages can decrease the overhead of address translation:

1
-XX:+UseLargePages

However, large pages often require OS configuration. The performance benefits can be noticeable for memory-intensive apps.

4. String Deduplication#

Strings are notorious consumers of heap memory because of duplicates. G1 GC allows string deduplication:

1
-XX:+UseStringDeduplication

This can save significant memory in applications that store many repetitive string values (e.g., JSON parser data, log messages).

5. TLAB and PLAB Tuning#

• Thread Local Allocation Buffers (TLABs): Provide each thread a private area in Eden to allocate new objects without synchronization.
• Promotion Local Allocation Buffers (PLABs): During GC, to avoid locking overhead, each thread uses PLABs to store objects that are promoted to survivor space or old generation.

You can fine-tune the TLAB size:

1
-XX:TLABSize=...

But in most cases, leaving TLAB size for the JVM to auto-tune is sufficient.

6. Compressed Oops#

“Oops” stands for ordinary object pointers. Using 64-bit JVMs with heaps up to 32GB can benefit from compressed Oops:

1
-XX:+UseCompressedOops

Enabling it can reduce memory usage (by using 32-bit offsets instead of 64-bit addresses) and might improve cache utilization. This is often the default when your heap size is under a certain threshold.

1. Over-Tuning#

It is tempting to tweak every parameter, but advanced GC tuning becomes increasingly complex and might hinder performance rather than improve it. Start with a robust collector (like G1) and minimal changes, measure effects, then iterate gradually.

2. Blindly Increasing Heap Size#

Doubling or tripling the heap size might reduce GC frequency, but each full GC could take significantly longer. Abnormally large heaps also require a more powerful CPU and memory subsystems.

3. Allocation Bursts#

If your application generates huge amounts of short-lived objects in very short bursts, you might experience GC storms or frequent minor GCs. Optimize your code to reduce unnecessary allocations:

• Reuse objects where possible.
• Use efficient data structures.
• Consider object pools if appropriate.

4. Ignoring the Old Generation#

Young Generation optimizations will only take you so far if your application’s memory churn eventually ends up in the Old Generation. Monitor old gen usage and be prepared to tune or refactor code to avoid large spikes in usage.

5. Not Monitoring in Production#

Always gather performance metrics in an environment that closely resembles production or, ideally, in production with appropriate safe-guards. Testing in a small dev environment might miss real-world memory usage patterns.

Scenario 1: High Throughput Web Application#

A typical large-scale web application sees a high volume of incoming requests and spawns many short-lived objects during request processing. Here’s how you might approach the tuning:

1. Collector Choice: G1 GC for balanced throughput and moderate pause times.
2. Heap Size: Set -Xms4g -Xmx4g, leaving headroom if your application typically uses around 2–3GB.
3. Pause Time Goal:

   1
   -XX:MaxGCPauseMillis=200
   

4. Observations: Check GC logs. If you still see spikes over 300ms consistently, you may lower the throughput threads or reduce the concurrency in your application if possible. Alternatively, you could use a more concurrent collector like ZGC or Shenandoah, but only if you require extremely low pause times.

Scenario 2: Real-Time Monitoring Service#

Say you’re building a monitoring service that must process constant data streams with minimal hiccups. Overly long GC pauses could lead to data ingestion bottlenecks.

1. Collector Choice: Consider Shenandoah or ZGC if latency is your top priority.
2. Heap Size: Possibly large, e.g., 16GB or more, if you’re ingesting large amounts of data.
3. Tuning:

   1
   -XX:+UseZGC
   2
   -XX:ZCollectionInterval=60
   3
   -Xms16g
   4
   -Xmx16g
   

   Observing the GC behavior with specific logging flags is vital.
4. Further Optimization: Possibly enable string deduplication if many repeated string-based metrics are stored.

Scenario 3: Batch Processing/ETL#

For batch workloads that are not latency-sensitive but require high throughput:

1. Collector Choice: Parallel GC might shine here because it focuses on maximizing throughput.
2. Heap Size: Large enough to hold all working data comfortably, e.g., -Xms8g -Xmx8g.
3. Observations: If GC logs show short but frequent cycles, try increasing the young generation to handle heavy batch allocations.

Below is an example configuration snippet for a typical ETL batch process:

1
java \
2
    -Xms8g \
3
    -Xmx8g \
4
    -XX:+UseParallelGC \
5
    -XX:ParallelGCThreads=8 \
6
    -XX:MaxGCPauseMillis=500 \
7
    -jar your-batch-app.jar