Thursday, 11 February 2016

Decrease your Java IDE lagging by fine tuning JVM Garbage Collector

Ever wondered why Eclipse/Netbeans keeps pausing for a while every now an then? Especially right at the time when you want to show something in the code to your dear colleages? It feelt embarrassing and awkward, didn’t it?

I found out that most of the time the IDE pauses because of Garbage Collector execution. The subtle little element in design of JVM, which usually does great job in relieving us developers from worrying about memory consumption, and most people are just happy that it does its job well and ignore it most of the time. However, the consequences of running Garbage Collector may surprise us if we simply ignore it.

In short, when GC is running, it pauses execution of the application until it is done freeing the memory. This is for sure unacceptable for real-time systems, where Java is certainly not the number one option. But even in non-critical huge desktop applications, which modern Java IDEs certainly are, the GC may stop the whole application for several seconds. And this may happen several times during the day. You can imagine that with productivity tools like IDEs, this is simply dragging down their “productivity” effect.

A solution is to do some tweaking:

  • increase memory for JVM on which the IDE is running (beware that this only reduces frequency of GC being called, but prolongs the execution time of a single GC run – it takes longer to collect garbage from bigger pile…)
  • switch default GC engine for a more concurrent engine, which tries to collect garbage continually even between stop-everything-until-done executions of complete GC

The first option is well known to majority of Java programmers – just define reasonable values for MaxPermSize and the family.

The second option, however, is not so well known. The point is that Oracle Java Hotspot JVM provides several alternative GC engines, which we can choose from. And they, unlike the default one, provide continuous garbage collection even between the big GC executions that slow everything down.

G1 Garbage Collector

You may enable it simply with this command line param:


G1 has also an interesting option to limit the length of GC processing, therefore limiting the length of the pause due to GC.


I recommend setting this to 2000, as 2 second pause is usually acceptable while working with IDE. Mind that this is only a soft hint for G1 collector – it will not be respected if a GC cycle requires more time, but in most cases G1 should respect it.

CMS Garbage Collector

In some benchmarks, older CMS collector outperforms the newer G1 collector.
You may enable it instead of G1 with these options:


Special Eclipse tweaking

GC tweaking really helped to improve performance of my Netbeans installation. However, to be honest, with Eclipse IDE, GC tweaking is only one of many steps to optimize the performance, and it is unfortunately only a minor one. What helps a lot more are tweaks in configuration, like turning off some validations in the code, reducing size of console output. In my case, console output was freezing Eclipse so much, that I needed to redirect standard output of my application server to a file and bypass the console completely.