How GCeasy and FastThread are compared to JVisualVM?

A potential customer asked us this question: “How GCEasy & FastThread are compared to JVisualVM?”. As it was a great question, here was our answer:

1. Intelligence

FastThread and GCEasy apply several intelligence patterns to detect the problems in the Garbage Collection logs and Thread Dumps. FastThread can point out which line of code is causing to CPU spike, which line of code is making the application unresponsive. GCEasy can figure out whether an application is suffering from Memory Leak or any other GC problems. Visual VM is capable of capturing thread dump and memory information. But not analyzing it.

It’s a difference between X-ray machine (jvisualVM) and a Doctor (GCeasy & FastThread). X-ray machine captures the data, whereas you need a doctor to detect whether the bone is broken? Where is it broken? How badly it’s broken? What kind of treatment should be given?

2. Richness in Data

GCEasy & FastThread provides rich information that JVisualVM doesn’t provide. How long did your GC pause? How many times GC run? What is your object promotion rate from Young Generation to Old Generation? How many GC runs did those object survive? How many objects reclaimed from each specific generation after GC? How many GC threads were active on every GC run? In G1 GC logs, there are several sub-phases, none of those metrics are reported by JVisualVM. If you want to tune your JVM, you need these metrics.

3. Scalability

With our REST API, you can analyze enumerable number of JVMs in an automated manner, whereas with JVisualVM you have to manually connect to every single JVM, capture the metrics and then you have to analyze it.

4. Overhead

FastThread & GCEasy doesn’t add any overhead to your JVM, as it’s analysis is based on the logs generated by the JVM, whereas JVisualVM adds overhead to your JVM. It has to connect to your JVM in real-time to report the metrics.

5. Security

In order for JVisualVM to work with remote machines, JMX or Jstatd connections has to be opened up. It’s a security risk for few organizations for open up these two connectivities from the production environment.

In certain enterprises for the safety reasons, only JRE is installed in the production environment. JVisualVM is only present in JDK and not in JRE.