Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Decrease Your Java IDE Lag by Fine-Tuning the JVM Garbage Collector

DZone's Guide to

Decrease Your Java IDE Lag by Fine-Tuning the JVM Garbage Collector

· Performance Zone ·
Free Resource

SignalFx is the only real-time cloud monitoring platform for infrastructure, microservices, and applications. The platform collects metrics and traces across every component in your cloud environment, replacing traditional point tools with a single integrated solution that works across the stack.

Ever wondered why Eclipse/Netbeans keeps pausing for a while every now and then? Especially right when you want to show something in the code to your colleagues? It feels pretty embarrassing and awkward, doesn't it?

I found out that most of the time the IDE pauses because of Garbage Collector execution. This is a subtle little element in design of the JVM which usually does a 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 the "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 a 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
I recommend using the G1 or CMS Garbage Collector as alternatives to reduce the time that the application freezes.

You can read more here.

SignalFx is built on a massively scalable streaming architecture that applies advanced predictive analytics for real-time problem detection. With its NoSample™ distributed tracing capabilities, SignalFx reliably monitors all transactions across microservices, accurately identifying all anomalies. And through data-science-powered directed troubleshooting SignalFx guides the operator to find the root cause of issues in seconds.

Topics:

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}