All you need to know about System.gc()

In this article, we have attempted to answer 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 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:

a). Your own application developers might be explicitly calling System.gc() method.
b). Sometimes System.gc() can be triggered by your 3rd party libraries, frameworks, sometimes even your application servers.
c). It could be triggered from external tools (like VisualVM) through use of JMX
d). 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, entire JVM will freeze (i.e. all the customer transaction that are in motion will be paused). Typically, these Full GCs take long duration to complete. Thus, it has potential to result in poor user experiences and your SLAs at unnecessary times when GC aren’t required to be run.

JVM has sophisticated algorithm working all the time in 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 GC event is complete and garbage is evicted from memory, they put back that JVM in to 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 can noticed in ‘Who invokes System.gc()?’ section, you can see System.gc() calls to be 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 to detect whether System.gc() calls are invoked in your entire application stack?

This is where GC logs comes 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 rich Garbage collection analysis report.

Fig: GC Causes reported by GCeasy.io tool

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

How to remove System.gc() calls?
You can remove explicit System.gc() call through 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 invoked from your 3rd party libraries, frameworks or through external sources then this solution will not work. In such circumstance you can consider using the option outlined in #b.

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 is 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.