Introduction

Garbage collection (GC) is a cornerstone of Java application performance, ensuring efficient memory management while minimizing disruptions to application execution. Speaking of which, I was recently pulled into a discussion regarding the impact of GC on latency when running the WebMethods Integration Server with large heaps (16-24GB), and someone made the comment that "normal" heap sizes are usually 8-16GB. For some perspective, I was running IS in production with 16GB heaps 20 years ago before it was even officially supported on 64-bit JVMs (after very thorough testing), so I know a little about the challenges involved. The older collectors (Parallel, CMS) required a fair amount of tuning, especially when dealing with larger heaps, to minimize pause times and maintain low latency.

To meet challenges such as handling massive transaction volumes, big-data, and AI applications, OpenJDK Java 17 and above provide three advanced garbage collectors—G1, ZGC, and Shenandoah—designed to meet the diverse needs of modern memory-intensive applications. For Java applications handling very large heaps, selecting the right GC and optimizing its configuration are critical for maintaining high performance. This blog is the first in a series where I will delve into each of these newer collectors in depth.

In addition to GC tuning, of course, proper JVM heap sizing is essential for optimal performance. A fundamental best practice is to set the initial heap size (-Xms) and the maximum heap size (-Xmx) to the same value to reduce heap resizing overhead and minimize fragmentation, ensuring more predictable performance. Naturally, hardware resources also need to be adequate with, for instance, sufficient CPU cores to handle potentially thousands of threads, between service calls and JVM internals.

While G1, ZGC, and Shenandoah are all built for scalability, their effectiveness depends on the specific workload requirements, such as latency tolerance, heap size, and throughput goals. Proper heap sizing and alignment with JVM tuning are integral to achieving consistent and reliable performance. So, let's take a closer look at these three amigos.

Comparing G1, Shenandoah, and ZGC

Overview of Garbage Collectors

G1 Garbage Collector (G1GC):

• How it works: Divides the heap into regions and prioritizes collecting regions with the most garbage, enabling predictable pause times.
• Key differentiation: Balances throughput and low-pause-time needs, making it ideal for medium to large heaps.

Z Garbage Collector (ZGC):

• How it works: Leverages colored pointers to achieve concurrent garbage collection with pause times in the millisecond range.
• Key differentiation: Designed for ultra-low latency and massive heap scalability (up to 16 TB), making it suitable for latency-critical applications.

Shenandoah Garbage Collector:

• How it works: Performs concurrent compaction alongside garbage collection, significantly reducing pause times and fragmentation.
• Key differentiation: Optimized for low-latency workloads, with a focus on reducing memory fragmentation.

Performance Comparison

Pause Times

• G1GC:

  • Pause times are configurable using -XX:MaxGCPauseMillis and generally range from a few milliseconds to hundreds of milliseconds, depending on heap size and workload.
  • Suitable for applications where predictable latency is more important than ultra-low pauses.

• ZGC:

  • Consistently delivers pause times in the millisecond range, independent of heap size, even for heaps as large as 16 TB.
  • Ideal for real-time systems where low latency is critical.

• Shenandoah:

  • Pause times are comparable to ZGC but may vary slightly based on workload.
  • Concurrent compaction significantly reduces fragmentation, ensuring pause times remain low.

Throughput

• G1GC:

  • Optimized for high throughput, as it focuses on collecting regions with the most garbage.
  • Works well for applications with moderate latency requirements and high transaction volumes.

• ZGC:

  • Throughput can be lower than G1GC due to the overhead of concurrent garbage collection.
  • Best suited for use cases where responsiveness is more critical than raw throughput.

• Shenandoah:

  • Strikes a balance between low latency and throughput but may sacrifice some throughput due to its concurrent compaction.
  • Most effective for latency-sensitive applications with predictable workloads.

Memory Footprint

• G1GC:

  • Region-based allocation can lead to fragmentation over time, requiring tuning to maintain efficiency.
  • Memory-efficient for medium to large heaps.

• ZGC:

  • Higher memory overhead due to the use of colored pointers.
  • Designed for ultra-large heaps, making it less memory-efficient for smaller heaps.

• Shenandoah:

  • Reduces fragmentation through concurrent compaction, resulting in a smaller memory footprint compared to G1GC.
  • Effective for applications with dynamic memory requirements.

Comparison Matrix

Heap Sizing Best Practices: -Xms and -Xmx

When sizing the heap for any garbage collector, it is highly recommended to set the initial heap size (-Xms) and maximum heap size (-Xmx) to the same value. This practice offers several benefits:

1. Eliminates Heap Resizing Overhead:

   • When -Xms and -Xmx are different, the JVM dynamically adjusts the heap size based on application demand. This resizing incurs additional overhead that can affect performance during runtime.

2. Minimizes Fragmentation:

   • Fixed heap sizing reduces the likelihood of fragmentation, which is especially important for G1GC and Shenandoah, as both rely on heap region management.

3. Improves Predictability:

   • A fixed heap size provides consistent memory behavior, allowing garbage collectors to operate under stable conditions.

4. Enhances Stability:

   • Fixed heap sizing ensures that memory is pre-allocated, reducing the risk of unexpected latency spikes due to resizing.

Recommended Settings:

• For G1GC: -Xms and -Xmx should be set based on expected workload and heap consumption patterns. Use monitoring tools to determine steady-state memory requirements.
• For ZGC: Fixed heap sizing (-Xms = -Xmx) is still recommended to ensure optimal memory performance, even though ZGC’s scalability minimizes resizing overhead.
• For Shenandoah: Pre-allocated heap sizing reduces compaction-related fragmentation and ensures consistent low-latency behavior.

Conclusion

OpenJDK's G1, ZGC, and Shenandoah garbage collectors each cater to specific performance needs:

• G1GC: Best for balancing predictable pause times and high throughput in medium to large heaps.
• ZGC: Excels in ultra-low latency scenarios and massive heap scalability.
• Shenandoah: Ideal for low-latency applications requiring compact and efficient heap management.

Regardless of the GC choice, setting -Xms and -Xmx to the same value is a best practice to minimize heap fragmentation, avoid resizing overhead, and ensure consistent memory behavior. Performance tuning is not a one-size-fits-all process—thorough testing under expected load conditions is essential to identify the right configuration for your application.

Until next time, happy integrating!