GC easy – Universal Java GC Log Analyser

Most Java developers know that there is something called Garbage Collector in JVM, which automatically reclaims the objects from the memory that they are creating. They also think they don’t have to worry about it, as Garbage Collection is automatic and JVM takes care of it. It’s a true statement. However, there are going to be cases where a Java developer needs to ‘learn a little bit’ more about Garbage Collection, especially when their application suffers from memory problems or performance degradations. This post intends to provide a detailed overview of Java Garbage Collection and this often ignores great benefits.

What is Garbage?

Java application creates several objects to service the new incoming requests. For instance, when a customer signs on, our applications creates following objects: an HTTP request object, HTTP session object, HTTP filter object, Servlet object, customer object (which internally includes username and password string objects), a DAO object for backend database interaction, a connection object for database connection, and several such objects. 

Once the request is serviced, these newly created objects will become useless. Because these objects are specific to a particular customer sign on request, and it can’t be re-used. Now these objects are called ‘Garbage’. 

This garbage has to be removed from memory. Because your memory is a finite space, it needs to free up to service the other new incoming requests. The process of removing such unreferenced objects from memory is called ‘Garbage Collection’.

Garbage Collection Evolution

Fig: Garbage Collection Evolution

In earlier days, especially in languages like C and C++, to service the new incoming requests, developers had to manually allocate and as well deallocate memory using ‘malloc()’ and ‘free()’ APIs, respectively. Once the request is serviced, they need to write code to deallocate those objects from memory. Business applications are complex, there are multiple workflows and use cases. If a developer misses to deallocate objects in just one workflow, then those objects will start to build up in the memory, eventually causing OutOfMemoryError. Thus, OutOfMemoryError was quite pervasive in those days.

When Java was introduced in 1995, it promised automatic garbage collection. While some languages before Java also had automatic garbage collection, Java really championed it. Java developers only need to allocate objects; and deallocation is handled by the Java runtime environment. Developers love this feature because it reduces memory leaks and allows them to focus on business logic. From that point on, all modern programming languages come with this automatic garbage collection capability.

What are the Side Effects of Java Garbage Collection?

Java’s automatic garbage collection makes memory management easier, but it also introduces some trade-offs that can affect your application’s performance and cost efficiency. Here are the key side effects you should be aware of:

1. Degradation in Response Time: 

To do automatic garbage collection, Java Runtime Environment has to keep track of all the objects created in memory. It should identify what are the active objects and inactive (i.e. unreferenced) objects and sweep them out of memory. To do this, the Garbage Collector pauses your application. This pause can span from a few milliseconds to several seconds (sometimes even minutes). During the pause window, your customer transactions are not processed. Thus, your application’s response time will degrade.

2. Increase in Computing Cost:

These GC pauses don’t just affect performance, but they can also impact your cloud costs. When the application is paused, it’s not doing any useful work. But your cloud provider continues to charge for CPU and memory resources. Over time, this can result in paying for idle time. If you’re interested, here is a blog post that covers the financial impact in more detail: How GC Inefficiency Costs Enterprises Millions

3. Spike in CPU Consumption:

Garbage Collection is a highly CPU-intensive operation. Modern applications create a large number of objects. All those objects must be constantly tracked. Their incoming references, outgoing references need to be constantly checked. Unreferenced objects need to be identified and removed from memory. As a result, automatic garbage collection consumes enormous amounts of CPU cycles. If your application consumes 70% CPU, it’s likely that more than 40% of CPU cycles are consumed by Garbage Collection.

While garbage collection helps manage memory automatically, it can subtly impact your application’s responsiveness, CPU usage, and operational costs if not tuned carefully.

Garbage Collection – Life partner of your application: GC is like a life partner of your application. Seriously 😊, there are a lot of similarities:

1. The GC coexists with your application under the same roof (i.e., the JVM).
2. GC keeps cleaning up the mess (i.e., garbage) created by your application.
If the application gets aggressive and creates a lot of objects, GC will also become aggressive to free up the space in the memory.
3. Both GC and your application continuously fight for the same CPU cycles.

Just like how choosing the right life partner is essential for the happiness of your life, choosing the right Garbage Collector and GC settings is essential for a high-performing application.

JVM Memory Regions

Fig: JVM Memory Regions

To minimize these overheads, Java Garbage Collector adopted a clever strategy of breaking memory into smaller internal regions, so that the number of objects that JVM needs to scan will be limited. Here are the different JVM memory regions:

1. Young Gen

2. Old Gen

3. Metaspace

4. Others

Whenever a new object is instantiated, it will be created in the Young Gen of the JVM’s Memory. All newly created objects are stored in the Young Gen. For example, if we create Servlet, DAO, Pojos… objects to service a new transaction, once a transaction is serviced, these objects will no longer have any reference. It should be reclaimed from memory. However there are certain objects which live for a long duration, like: DB connection, Cache, Session… JVM promotes objects that live for a longer duration from the Young Gen to the Old Gen. Metaspace contains metadata definitions (i.e., class definitions ‘Customer.class’ and method definitions) that are required to execute the program. Other regions contain internal regions like GC region, Threads Region, Internals, Code Cache… – which you don’t have to go into detail, unless you are deep into JVM troubleshooting and optimization. However, if you are interested, you can learn more about JVM internal memory regions from this video clip.

What is the typical size of these Memory Regions?

It varies from application to application. However, for most applications, we can assume that Young Gen will occupy 30% of memory, Old Gen will occupy 60% of memory, Metaspace & Others Region will occupy the remaining 10%.

What is Young GC and Full GC?

There are two types of garbage collection events in the Java Virtual Machine (JVM):

 a. Young GC (aka Minor GC)

 b. Full GC (aka Major GC)

They differ in terms of which parts of memory they clean, how long they take, and how frequently they occur. Below table summarizes the differences between them:

Young GC	Full GC
Young GC scans and reclaims unreferenced objects only from the Young Generation.	Full GC event scans and reclaims unreferenced objects from Young Generation, Old Generation and Metaspace.
Young GC takes less time to complete, because it has a smaller region (i.e. Young Gen) to scan & reclaim	Full GC takes longer time to complete because it has to scan & reclaim from large regions (Young Gen, Old Gen & Metaspace).
Young GC runs more frequently, because application creates lot of short-lived objects in Young Gen	Full GC runs occasionally
Young GC is triggered when the Young Gen fills up.	Full GC is triggered when the Old Generation or Metaspace is full or when there is memory pressure across the heap.

Several JVM studies show that around 80% of objects are short-lived. That’s why Young GC handles frequent, lightweight cleanups efficiently. In contrast, Full GC performs deeper, less frequent cleanups across the entire heap, making it more impactful.

Does Young GC pause the Application?

There is a wrong education going on in the industry that Young GC don’t pause the JVM and only Full GCs do pause the JVM. It’s not true. Both Young GC and Full GC pause the JVM using the ‘stop-the-world’ mechanism.

The key difference lies in how long the pause lasts:

a) Young GC scans only the Young Generation, which is relatively small. So the pause is typically brief, often just a few milliseconds.

b) Full GC, on the other hand, scans the entire heap (Young Gen, Old Gen, and Metaspace). This makes its pauses much longer, sometimes stretching from hundreds of milliseconds to several seconds.

What happens if garbage collection doesn’t keep up?

When garbage collection doesn’t keep up with your application’s memory allocation demands, it results in both micro-level inefficiencies and macro-level failures. Here’s what starts to go wrong:

Micro-Effects

These are the first symptoms you’ll notice within the JVM when memory pressure builds up and GC can’t keep up to reclaim space efficiently.

1. Long GC Pauses: GC cycles become longer and more intrusive, as the memory fills up faster than it is reclaimed. These long GC pauses stop all application threads, freezes user transactions and introduces noticeable performance lags. Here are a few strategies to reduce long GC pauses if you’re seeing this pattern.

2. Allocation Stall: If the JVM runs out of free space for new object allocations, it leads to an allocation stall. Which means that your application is forced to pause until GC can free up sufficient memory. These stalls cause random and frustrating delays, and here are the steps to identify and fix these allocation stalls. 

3. Frequent GC Cycles: When memory pressure remains high, GC may run repeatedly with little breathing room in between. These back-to-back GC cycles reduce application uptime and drain CPU resources. If your app is spending more time in GC than doing actual work, here’s how to eliminate consecutive full GCs.

Cascading Macro-Effects

If the GC issues continue to happen, they affect your application’s stability, scalability, and reliability. Let’s take a look at what are its effects: 

1. OutOfMemoryError: If GC continues to fall short and can’t free up the memory, your application will throw an OutOfMemoryError. This kind of error destabilizes your applications’ availability, especially if it occurs in critical memory regions like heap, metaspace, or direct buffers. We have discussed different types of OutOfMemoryError, what causes each and how to resolve them in this blog.

2. High CPU: When GC continues to run frequently, it puts a heavy load on the CPU, causing spikes. This not only slows down your app but can also trigger unnecessary autoscaling or resource throttling. This post shares 5 strategies to reduce CPU consumption caused by garbage collection. 

3. Degradation in Response Time & Timeouts: When GC happens too often or takes a long time, the application threads are delayed. This results in slower response times and transaction timeouts, which hurts the user experience. The impact is especially high for systems that are Latency-sensitive.

4. Application Throughput Drops: If JVM spends too much time in GC, then there’s less time for processing transactions. As a result, your application throughput drops, lowers the number of transactions it can handle per second. During high-traffic periods, this bottleneck can severely affect your system’s performance.

Can I Force Garbage Collection in Java?

Yes, you can force garbage collection in Java, and you can request JVM to do it. But we would not suggest it, because manual GC intervention often backfires, it disrupts the JVM’s finely tuned heuristics and can introduce unnecessary pauses. To be honest, the JVM does a better job at deciding when to trigger GC, based on memory pressure, allocation patterns, and GC algorithm behavior. One can force GC in Java using below mentioned options:

1. System.gc() or Runtime.getRuntime().gc() APIs

These are standard Java API methods used to request garbage collection. Calling System.gc() or Runtime.getRuntime().gc() signals the JVM to perform garbage collection, but it is only a suggestion—not a guarantee. Most modern JVMs may ignore the request unless explicitly configured to honor it (e.g., with -XX:+ExplicitGCInvokesConcurrent). These APIs are useful in testing or controlled environments, but are generally not recommended in production, as they can cause unnecessary application pauses and interfere with the JVM’s own GC optimizations.

2. Tools (e.g., jcmd, jmap)

You can trigger garbage collection from the outside using diagnostic tools. For example:

jcmd <PID> GC.run

jmap -histo:live <PID>

These commands trigger full GC from the JVM process identified by the Process Id (i.e. PID) . Usually this approach is followed by administrators or support teams during live troubleshooting, memory analysis, or heap snapshot collection.

3. JMX (Java Management Extensions)

GCs can  also be triggerred via JMX using tools like JConsole, VisualVM, or a custom JMX client. These tools expose ‘java.lang:type=Memory’ MBean, which has an operation named ‘gc()’. Invoking this operation triggers the garbage collection in the JVM.

How Many Garbage Collection Algorithms are There in Java?

At the time of writing this post, there are 7 Garbage Collection algorithms in OpenJDK. They are:

1. Serial GC

The Serial Garbage Collector is the first GC algorithm introduced in JDK. Serial GC performs all garbage collection work on a single thread. This means it stops all application threads (stop-the-world) during garbage collection, which can lead to noticeable long pauses in the application. If you are interested, learn more about Serial GC tuning here.

Note: Since pause times are high in Serial GC, it’s not ideal to use Serial GC in our modern-day applications. 

2. Parallel GC

Unlike Serial GC, Parallel GC utilizes multiple threads to perform garbage collection phases. This allows garbage collection work to be distributed across multiple CPU cores, reducing the impact of garbage collection pauses on application performance. If you are interested, learn more about Parallel GC tuning.

Note: If your focus is to achieve better GC throughput over occasional high GC pause times, you can use Parallel GC. Parallel GC is well suited for batch applications and business applications in which consistent GC pauses at regular intervals are acceptable.

3. Concurrent Mark Sweep (CMS GC)

The Concurrent Mark-Sweep (CMS) Garbage Collector is designed to minimize the application pause times by performing most of its garbage collection work concurrently with the application threads. The primary downside of CMS is that it does not compact the heap, which will lead to fragmentation, eventually causing long GC pauses. If you are interested, learn more about CMS tuning.

Note: CMS algorithm has been deprecated in Java 9 and removed completely from Java 14. Since this algorithm is deprecated and removed, I wouldn’t use the CMS algorithm for my applications, unless there is a specific need. 

4. Garbage First (G1 GC) 

The Garbage First (G1) Garbage Collector is an adaptive algorithm. G1 divides the heap into equal-sized regions, allowing for flexible and efficient memory management. It performs most operations concurrently, reducing stop-the-world pauses. G1 aims to provide the best balance between latency and throughput, as long as your heap size is not very large. If you are interested, learn more about G1 GC tuning.

Note: Since G1 GC has become the default algorithm since Java 9 and it’s consistently enhanced over the years, I will consider using this algorithm especially if my heap size is less than 32gb.

5. Shenandoah GC 

The Shenandoah Garbage Collector is one of the latest and low-pause-time GC algorithms introduced by Red Hat for the OpenJDK. This algorithm is designed to achieve minimal pause times for applications with large heap size. Similar to G1, Shenandoah divides the heap into regions, allowing for targeted collection of memory regions with high garbage content, thus optimizing memory reclamation. If you are interested, learn more about Shenandoah GC.

Note: If your application has a large heap (say more than >32gb) and you can tolerate high CPU consumption, consider evaluating this algorithm.

6. Z Garbage Collector (ZGC)

The Z Garbage Collector (ZGC) is a scalable, low-latency garbage collection algorithm. Designed to manage very large heaps with minimal pause times, ZGC aims to keep GC pauses below 10 milliseconds, making it ideal for applications requiring consistent responsiveness and large memory allocations. Initial versions of ZGC had poor performance, but significant improvements have been made in recent versions. If you are interested, learn more about ZGC tuning here.

Note: If your application is running on a large heap and running on the latest version of Java (say > Java 21), you can consider evaluating this algorithm. However, you need to be aware of allocation stalls.

7. Epsilon GC

The Epsilon is basically a no-op GC algorithm, i.e. it will not reclaim any objects from the memory. Basically, when the heap gets full, the application will crash with an OutOfMemoryError.

Note: You can use Epsilon GC, in Performance labs to study the impact of GC pauses or for experimentation purposes but not in a production environment.

Below table summarizes each GC algorithm in nutshell:

GC Algorithm	When to use it?	Supported Java Versions	How to enable it?
Serial GC	Not recommended because of single threaded nature	Java 1.2 and above	-XX:+UseSerialGC
Parallel GC	Recommended if you want to achieve high GC throughput and OK with consistent GC pauses are regular intervals	Java 5 and above	-XX:+UseParallelGC
CMS GC	Not recommended, as it’s removed from Java 14 version.	Java 1.4.2 to 13	-XX:+UseConcMarkSweepGC
G1 GC	Recommended if heap size is <32gb and want to strike balance between throughput and pause time.	Java 7 and above	-XX:+UseG1GC
Shenandoah GC	Recommended for large heap (say more than >32gb) and can tolerate high CPU consumption	OpenJDK 8u, 11 and above	-XX:+UseShenandoahGC
ZGC	Recommended for large heap (say more than >32gb) and running on latest version of Java (say > java 21). Beware of allocation stalls.	Java 11 and above	-XX:+UseZGC
Epsilon GC	Can be used for experimentation purpose and in Performance Labs, but not in production	Java11 and above	-XX:+UseEpsilonGC

Choosing the Right Garbage Collector

You want to choose the garbage collection algorithm based on your GC tuning goal i.e. whether you want to keep low GC pause time, high GC throughput, reduce CPU consumption, … Here is a post which can assist you in choosing the right Garbage Collector algorithm for your application.

Fig: Flow chart to help you to arrive at right GC algorithm

How do different Java versions impact garbage collection?

Upgrading to new Java Versions can affect garbage collection behaviour in following ways:

1. Default GC Algorithm Evolution: Each Java version comes with a different default garbage collection algorithm, which can affect how your application behaves out of the box. For example, until Java 8 Parallel GC was the default GC algorithm, starting from Java 9, G1 GC became the default. Parallel GC and G1 GC have different behavioral characteristics. Former targets to achieve high throughput, while latter focuses on striking balance between latency & throughput. These default changes mean that simply upgrading your JDK can alter your application’s memory behavior and performance characteristics without making any code changes. To learn how the fault GC algorithm has evolved across versions, you may read this post: What is Java’s default GC algorithm?

2. GC Algorithms Introduction and Deprecation: Over time, Java has seen several GC algorithms come and go, they have been introduced, matured, deprecated, and removed. CMS GC was widely used in Java 8 and below versions for its low-pause behavior. However CMS was deprecated in Java 9 and removed in Java 14. In contrast, newer collectors like ZGC and Shenandoah GC were introduced in Java 11 and Java 12 respectively, offering ultra-low pause times and support for large heaps. These changes influence your GC tuning strategy, especially if you’re upgrading from older JDKs. 

3. Ongoing Enhancements to GC Algorithms: Even when GC algorithms remain available across versions, it keeps getting better with each release. For example, G1 GC saw major enhancements in Java 10+ with better pause-time tuning, region management, and improved logging. ZGC also evolved by adding support for class unloading, concurrent stack processing, and eventually generational support (previewed in JDK 21). These incremental upgrades mean that newer Java versions are more GC-efficient, even if you are using the same GC algorithm.

4. GC Performance Gains in Modern JDKs: Vendors like Oracle continue to reduce GC pause times, speeding up compaction, improving CPU usage, and making GC scale better on large heaps in each new Java version. Oracle’s benchmarks show big improvements in throughput and latency when moving from Java 8 to Java 17 and newer. The best part is you often see these gains just by upgrading your JDK,  no need to tweak any GC settings. You can check out Oracle’s performance studies to see the results for yourself.

What are the Benefits of Tuning Java Garbage Collection?

Tuning Garbage Collection settings provides unbelievable benefits, which are often overlooked & underestimated in the enterprises. Below are key benefits of GC Tuning:

Benefits of Garbage Collection Tuning

1. Improvement in Response Time: When GC performance improves, your overall customer facing response time also improves. This might be surprising, but it’s very true. Garbage Collection pauses your application periodically, when that pause time gets minimized, automatically your application will spend more time in processing customer transactions, which in turn will improve overall application’s response time.
2. Slash Computing Cost: When GC performance improves your application’s CPU consumption will reduce. Also, GC study will let you know whether you have over allocated your memory (which is done by most of the applications). If you cut down the memory overallocation and reduce CPU consumption, automatically you can run on a smaller number of servers/containers, which will reduce your cloud hosting bill.
3. Forecast Production Problems: Most of the APM tools, only monitors macro-metrics (i.e. CPU consumption, memory consumption, response time). These are great performance indicators, however they are reactive in nature. Only after problem surfaces in production, will their value start to go high. However, GC micro-metrics (such as GC throughput, GC pause time, Object creation rate…), will facilitate you to forecast several performance problems before they surface in the production environment.

Learn in detail about the hidden benefits of GC Tuning.

What are the Best Java GC Analysis Tools?

Several tools are available to help you analyze Java Garbage Collection (GC) logs, providing visibility into memory usage, GC frequency, pause times, and inefficiencies that impact application performance.

1. GCeasy – This tool is one of the most comprehensive tools for GC analysis. It can parse through GC logs from all major algorithms including G1, CMS, Parallel, ZGC, and Shenandoah—and presents the data as visual charts, key performance indicators, intelligent problem detection and a REST API for automation and CI/CD integration. It also can offer recommendations to improve memory allocation and reduce GC pauses. The toolset is available in both online and on-prem editions. If you are looking for performance optimization and saving money, then GCeasy is well-suited for production troubleshooting.

2. GarbageCat – If you are a developer and prefer a lightweight solution to parse your GC logs, then this command-line tool is yours. It can also generate CSV output to track key GC events like other tools. However, it does have its shortcomings. It does not have advanced visual or analytic capabilities & doesn’t support all GC log formats as well, but it is good for scripting or integrating into automated environments.

3. JClarity Censum: This is another lightweight software tool for Java GC log analysis. It is popularly known for its easy GUI interface as well as its efficiency in parsing logs. Even though the software is no longer maintained, certain legacy environments continue to employ the same in an attempt to find useful information for older applications.

4. IBM Pattern Modeling and Analysis Tool (PMAT): This tool is designed for GC logs produced by IBM JVMs, to optimize Java Heap usage. It can parse GC logs, generate detailed reports and also yield basic statistical charts of heap usage, making it suitable only for applications running on IBM’s Java implementation.

5. HP JMeter GC Viewer: This is an open-source desktop application that can read GC logs and display memory trends and pause time statistics. It works best with simpler logs, especially those from the Parallel GC algorithm, and is often used for basic memory behavior analysis.

What are the Tips for GC Tuning?

This video will provide you with firsthand insights on how industry leaders tackled GC optimization exercises, yielding measurable performance enhancements. We will break down real GC logs, demonstrate essential tools, and share expert techniques that can transform your approach to Java application performance.

Here are nine quick tips to tune your GC performance and reduce long garbage collection pause time.

Practical Tips for Tuning Garbage Collection

1. Start Tuning from Scratch: Several applications contain outdated JVM arguments, degrading the application performance. Configure only those relevant to your application’s current needs.
2. Resize Your Heap: Increasing or decreasing your heap size (-Xmx), has good potential to avoid frequent and/or long GC pauses.
3. Choose the Right GC Algorithm: Select a garbage collection algorithm that best matches your application’s workload and performance requirements.
4. Adjust Internal Memory Region Sizes: Fine-tune the sizes of young, old, metaspace memory regions to reduce GC pause times.
5. Tune GC Algorithm Settings: Configure JVM arguments specific to the chosen GC algorithm for optimal performance.
6. Address the Causes of GC Events: Analyze GC log files to identify and mitigate specific triggers for GC events.
7. Disable Explicit GC: Prevent or minimize the impact of System.gc() calls to reduce unnecessary pauses.
8. Allocate Sufficient System Capacity: Ensure your application has enough CPU, memory, and I/O resources to support efficient GC operations.
9. Reduce Object Creation Rate: Lower the frequency of GC events by minimizing memory allocation and object creation in your application.

For deep insights into these tips, refer to the ‘9 Tips to Reduce Long Garbage Collection Pauses’ post.

What are JVM arguments for garbage collection tuning?

Since the JDK has been evolving for over 30 years, there are more than 600 JVM arguments related to memory and garbage collection. Many of them are deprecated, and incorrect usage can lead to counter-productive behavior. Below are some of the most important and safe-to-use JVM arguments that help you tune Garbage Collection performance effectively:

1. -Xmx<size> & -Xms<size>

These two arguments can help set the initial and maximum heap size for your Java application. -Xmx sets the JVM’s heap memory’s upper limit, while -Xms sets the initial heap memory size. Setting them both to the same value (e.g., -Xmx4g -Xms4g) avoids heap resizing during runtime, which can improve performance by reducing GC related churn.

2. -XX:NewRatio=<ratio>

The JVM’s memory is split into two parts – the Old Generation and Young Generation. This argument -XX:NewRatio=<ratio> defines the ratio between them. For example, if the JVM argument is -XX:NewRatio=3, then it means the Old Generation will be three times larger than the Young Generation. By adjusting the ratio, we will be able to balance GC frequency and throughput, especially in workloads where short-lived vs. long-lived object distribution is skewed. Here is a case study which shows how reducing Young Generation size improved an application’s performance by several times.

3. Choice of GC Algorithm

JVM supports multiple GC algorithms, however, each is optimized for different goals like throughput, latency, or low footprint. You can select the appropriate one using these flags:

• -XX:+UseSerialGC
• -XX:+UseParallelGC
• -XX:+UseConcMarkSweepGC
• -XX:+UseG1GC
• -XX:+UseShenandoahGC
• -XX:+UseZGC
• -XX:+UseEpsilonGC (Disables GC – useful only for testing)

This post discusses how to choose the right GC algorithm. This is the critical step in tuning memory behavior.

4. GC Algorithm-Specific Settings

Once a GC algorithm has been selected, it can be tuned further to control pause times, throughput, and memory efficiency more precisely. For detailed tuning tips and parameter explanations for each GC algorithm, refer to:

• Serial GC Tuning
• Parallel GC Tuning
• CMS GC Tuning
• G1 GC Tuning
• Shenandoah GC Tuning
• ZGC Tuning

5. -Xlog:gc*:file=<gc-log-file-path>

Garbage Collection logs are very much essential for diagnosing memory issues, understanding GC behavior, and tuning JVM performance. They are the backbone of any serious GC analysis. Based on the Java version you are on, you will need to use appropriate arguments to enable GC logging:

For Java 8 and below: -XX:+PrintGCDetails -Xloggc:<gc-log-file-path>

For Java 9 and above: -Xlog:gc*:file=<gc-log-file-path>

6. -XX:ParallelGCThreads=<number> & -XX:ConcGCThreads=<number>

These arguments control the number of threads used by GC algorithms. By tuning these based on your machine’s CPU capacity, you can reduce the GC pause times and improve throughput. For more guidelines, we recommend you to read this: GC Thread Tuning – Guidelines and Impact

GC Tuning Real World Case Studies

In this section, let’s review few interesting GC Tuning real world case studies, that resulted in tremendous performance improvements:

1. Uber Saves Millions by Reducing 70,000 CPU Cores: Uber, a large ride sharing application faced high CPU utilization due to inefficient garbage collection across its Go-based microservices. They optimized their GC performance, which resulted in significant cost savings, with approximately 70,000 cores saved and up to a 65% reduction in CPU usage for some services, improving both performance and efficiency.

2. Large Automobile Manufacturer Achieves 49% Faster Response Time: One of the world’s largest automobile manufacturers optimized their middleware platform’s response time by a remarkable 49.46%. By fine-tuning their garbage collection settings without modifying a single line of code, they reduced the average response time from 1.88 seconds to 0.95 seconds. This transformation demonstrates how GC tuning can deliver substantial performance improvements cost-effectively. 

3. Robotics Application Reduces GC Pauses by 98%: Here is a case study of a Java application that manages warehouse robots. It faced slowdowns due to long GC pauses, sometimes exceeding 5 minutes. By switching the GC algorithm (from CMS GC algorithm to G1 GC), the maximum pause time was reduced to just 2.17 seconds. This significant improvement resolved slowdowns without requiring major architectural changes.

If you like, learn more about the fascinating real world GC tuning success studies. 

Conclusion

Garbage Collection optimization brings several hidden benefits to your organization. I would like to strongly encourage you to learn this lifetime skill and become a superhero in your organization.