Who? Why? What? Fix? – System.gc()

In this article, we have attempted to answer the most common questions around System.gc() API call. We hope it may be of help.

What is System.gc()?

System.gc() is an API provided in Java, Android, C# and other popular languages. When invoked it will make its best effort to clear an accumulated unreferenced object (i.e. garbage) from memory.

Who invokes System.gc()?

System.gc() calls can be invoked from various parts of your application stack:

• Your own application developers might be explicitly calling System.gc() method.
• Sometimes System.gc() can be triggered by your 3rd party libraries, frameworks, sometimes even your application servers.
• It could be triggered from external tools (like VisualVM) through use of JMX
• If your application is using RMI, then RMI invokes System.gc() on a periodic interval.

What are the downsides of invoking System.gc()?

When System.gc() or Runtime.getRuntime().gc() API calls are invoked from your application, stop-the-world Full GC events will be triggered. During stop-the-world full GCs, the entire JVM will freeze (i.e. all the customer transactions that are in motion will be paused). Typically, these Full GCs take a long duration to complete. Thus, it has the potential to result in poor user experiences and your SLAs at unnecessary times when GC isn’t required to run.

SEE ALSO: Quarkus – what’s next for the lightweight Java framework?

JVM has sophisticated algorithms working all the time in the background doing all computations and calculations on when to trigger GC. When you invoke System.gc() call, all those computations will go for toss. What if JVM has triggered GC event just a millisecond back and once again from your application you are going invoking System.gc()? Because from your application you don’t know when GC ran.

Are there any good/valid reasons to invoke System.gc()?

We haven’t encountered that many good reasons to invoke System.gc() from the application. But here is an interesting use case we saw in a major airline’s application.

This application uses 1 TB of memory. This application’s Full GC pause time takes around 5 minutes to complete. Yes, don’t get shocked, it’s 5 minutes. (But we have seen cases of 23 minutes GC pause time as well.) To avoid any customer impact due to this pause time, this airline company has implemented a clever solution.

On a nightly basis, they take out one JVM instance at a time from their load balancer pool. Then they explicitly trigger System.gc() call through JMX on that JVM. Once the GC event is complete and garbage is evicted from memory, they put back that JVM into a load balancer pool. Through this clever solution, they have minimized customer impact caused by this 5 minutes GC pause time.

How to detect whether System.gc() calls are made from your application?

As you may notice in ‘Who invokes System.gc()?’ section, you can see System.gc() calls are made from multiple sources and not just from your application source code. Thus searching your application code ‘System.gc()’ string isn’t enough to tell whether your application is making System.gc() calls. Thus it poses a challenge: How do you detect whether System.gc() calls are invoked in your entire application stack?

This is where GC logs come in handy. Enable GC logs in your application. In fact, it’s advisable to keep your GC log enabled all the time in all your production servers, as it helps you to troubleshoot and optimize application performance. Enabling GC logs adds negligible (if at all observable) overhead. Now upload your GC log to the Garbage Collection log analyzer tool like GCeasy, HP JMeter,…. These tools generate a rich Garbage collection analysis report.

Fig: GC Causes reported by GCeasy.io tool

The above figure is an excerpt from the ‘GC Causes’ section of the report generated by GCeasy. You can see that ‘System.gc()’ call is invoked 304 times accounting for 52.42% of GC pause time.

How to remove System.gc() calls?

You can remove the explicit System.gc() call through the following solutions:

a.) Search & Replace

This might be a traditional method, but it works. 

Search in your application code base for ‘System.gc()’ and ‘Runtime.getRuntime().gc()’. If you see a match, then remove it. This solution will work if ‘System.gc()’ is invoked from your application source code. If ‘System.gc()’ is going to invoke from your 3rd party libraries, frameworks or through external sources then this solution will not work. In such circumstances, you can consider using the option outlined in #b.

SEE ALSO: Kotlin gnaws at Java’s throne

b) -XX:+DisableExplicitGC

You can forcefully disable System.gc() calls by passing the JVM argument ‘-XX:+DisableExplicitGC‘ when you launch the application. This option will silence all the ‘System.gc()’ calls that are invoked anywhere from your application stack.

c) RMI

If your application is using RMI, then you can control the frequency in which ‘System.gc()’ calls are made. This frequency can be configured using the following JVM arguments when you launch the application:

-Dsun.rmi.dgc.server.gcInterval=n

-Dsun.rmi.dgc.client.gcInterval=n

The default value for these properties in:

JDK 1.4.2 and 5.0 is 60000 milliseconds (i.e. 60 seconds)

JDK 6 and later release is 3600000 milliseconds (i.e. 60 minutes)

You might want to set these properties to a very high value so that it can minimize the impact.

The post Who? Why? What? Fix? – System.gc() appeared first on JAXenter.