Java Mission Control tool

Versions: Java 8

Historically JVisualVM was one of Oracle references to monitor the state of the JVM. However the 7th version of Java brought an alternative called Java Mission Control.

New ebook 🔥

Learn 84 ways to solve common data engineering problems with cloud services.

👉 I want my Early Access edition

This post makes an insight on this profiling and monitoring tool. The first part shortly defines it. The second part shows, through taken screenshots, which information it exposes.

Java Mission Control defined

Java Mission Control (JMC) is a set of tools helping to analyze what happens in the JVM. It's composed of 3 parts:

JMC collects low level runtime information (heap size, CPU use, number of objects of particular class...) and exposes it through an UI. It can work locally and remotely. For this second case, it's required to configure jmxremote (e.g.: -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.port=3614 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false) when the monitored application is started. JMC interacts thus with JVM's JMX agent to discover what happens on the JVM.

Historically JMC was developped as a part of proprietary JVM called JRockit. Its initial goal was to provide a non intrusive monitoring and profiling tool for production applications running on JRockit. With the update 40th of Java 7 the JMC was moved to public JDK. JMC achieves good performances and is not intrusive because the collected events come directly from the JVM. Thanks to that it avoids the observer effect. JMC is different than other monitoring tools that use sampling or profiling techniques.

Observer effect

It occurs when the observation of a phenomenon changes the phenomenon itself. In IT we can meet observer effect when for instance:

  • we want to analyze the CPU use with the program running on the same PC and so using the analyzed CPU
  • logging the information about program execution that can slow down the whole execution time because of I/Os

Sampling and profiling in monitoring tools

We can monitor and analyze applications on runtime with either sampling or profiling approach.

Sampling consists on collecting runtime information every defined interval of time, for instance every 1 minute. As you can see, the collected information can be approximative. For example, if we have methods executed in less than 1 minute, their metrics can be missed by the sampler.

Profiling is more exact measure because it instrumentates the executed code. However it adds a bigger performance overhead than the sampling and can seriously slow down the application.

The JMC UI is launched through jmc command. We can customize some of its features, as define workspace (-data $workspace attribute) or add additional JVM arguments (-vmargs $jvmArguments attribute). The configuration can also be modified through the changes of jmc.ini file

Zoom at JMC

Now it's time to discover JMC in practice. The points below will list the main (subjectively chosen) tabs of JMC UI:

Memory pools

Generally memory pools represent the set of memory resources preallocated by the system enabling dynamic memory allocation (= memory allocated on runtime, e.g. by using C++ new operator). They can be grouped in hierarchical structures and enable the memory release for a set of objects with in just one operation.

In JVM memory pools are represented by on-heap and off-heap memory parts, as metaspace or generations (young, old).

JMC came to JDK some time ago but it still less popular than JVisualVM. But as we could see in the first part, the JMC enhances the features proposed by JVisualVM by limiting observer effect and working with Java Flight Recorder. Through the screens from the second section we could also see that the JMC proposes not only monitoring but also alerting (trigger) in different forms (e-mail, log...). This part also shown that the JMC is not a closed tool because it can be freely customized thanks to a lot of "+" buttons defined in the interface.