Java Mission Control: Flight Recordings and Heap Analysis

Java Mission Control (JMC) is the JDK’s built-in profiling and diagnostics tool that most developers overlook. It ships with the JDK, costs nothing, and provides capabilities that rival expensive commercial profilers. The flight recorder captures low-overhead profiling data in production, while the heap analysis tools dig into memory issues without the overhead of heap dumps.

This is not a flashy tool. The interface looks dated and the learning curve is steep. But when you need to understand what your JVM is actually doing in production, JMC delivers insights that no other tool can match without significant cost or overhead.

Introduction

Java Mission Control (JMC) is the JDK’s built-in profiling and diagnostics tool that most developers overlook. It ships with the JDK, costs nothing, and provides capabilities that rival expensive commercial profilers. The flight recorder captures low-overhead profiling data in production environments where aggressive profiling is not an option. The heap analysis tools dig into memory issues without the latency hit of standalone heap dump tools. The automated analysis view surfaces JVM configuration problems, excessive garbage collection, and lock contention without requiring you to know exactly what to look for. For teams that cannot afford YourKit or JProfiler, JMC is the answer to problems those tools solve—provided you are willing to invest the time to learn its dated interface.

The tool is not flashy. The UI looks like it was designed a decade ago, and in some ways it was—the JMC 8 release that coincided with Java 11 brought significant capabilities but kept much of the original design. The learning curve is real: automated analysis views, memory inspector, code flame graphs, thread state analysis, and heap dump analysis with allocation sites are all powerful but not discoverable. Running the automated analysis first, then diving into specific views, is the workflow that makes sense for most investigations.

This guide covers JMC architecture, how to enable and control flight recordings via JCMD and JMX, and how to use each analysis view effectively. You will learn to correlate flight recorder data with application logs, identify JIT compilation hotspots, diagnose lock contention, and find memory leaks using allocation site information that JMC captures but jmap does not. Production failure scenarios show how JMC data has diagnosed issues ranging from JIT deoptimization to classloader memory leaks that were invisible to other monitoring tools.

When to Use JMC / When Not to Use JMC

JMC excels in production environments where you cannot afford the overhead of aggressive profiling. The flight recorder runs at less than 2% CPU impact even with detailed event capture. It works well for correlating application behavior with specific operations, understanding JIT compilation effectiveness, and identifying lock contention in concurrent applications.

Avoid JMC when you need to profile very short-running applications—the overhead of starting the JVM itself dominates. For quick development-cycle checks during coding, lightweight tools like VisualVM or async-profiler give faster feedback. If you need allocation profiling with object retention details, YourKit or JProfiler offer more intuitive interfaces for that analysis.

JMC also requires JDK distribution rather than JRE, and some organizations struggle with the licensing implications of using Oracle JDK features in production. OpenJDK builds with JMC support exist, but the flight recorder implementation quality varies.

JMC Architecture

graph TD
    subgraph "JMC Client"
        JMCUI[JMC UI<br/>Flight Recorder Browser<br/>Heap Dump Analyzer]
    end

    subgraph "JMX/RMI Connection"
        JMX[JMX MBean Server<br/>Remote JVM Connection]
    end

    subgraph "JVM Internals"
        FR[Flight Recorder<br/>Event Buffer<br/>Continuous/Profiling Mode]
        CP[Code Cache<br/>Compilation Events]
        GC[GC Events<br/>Heap Statistics]
        TH[Thread Events<br/>Allocation Profiling]
    end

    JMCUI <-->|"JMX/RMI"| JMX
    JMX --> FR
    JMX --> CP
    JMX --> GC
    JMX --> TH

The flight recorder runs inside the JVM as a native agent, buffering events in a circular log. When you connect with JMC, it downloads and parses this buffer. For continuous monitoring, events can stream to a flight recording file that you analyze later.

## Enabling Flight Recordings

Flight recordings work through JCMD commands or JMX beans. Here is how to trigger recordings on a running JVM:

```bash
# Check available flight recorder commands
jcmd <pid> JFR.check

# Start a 60-second recording
jcmd <pid> JFR.start name=profile duration=60s filename=profile.jfr

# Start continuous recording with 1GB buffer
jcmd <pid> JFR.start name=continuous settings=profile \
    maxsize=1GB maxage=6h filename=continuous.jfr

# Dump running recording
jcmd <pid> JFR.dump name=profile filename=profile-dump.jfr

# Stop recording
jcmd <pid> JFR.stop name=profile

For JVM startup recordings, add these flags:

# Enable flight recorder on startup
java -XX:StartFlightRecording=\
disk=true,\
dumponexit=true,\
filename=/var/log/myapp.jfr,\
maxsize=512M,\
maxage=2d,\
settings=profile \
-jar your-application.jar

The settings=profile argument uses the built-in profiling template. For lower overhead, use settings=default. You can create custom templates with the JMC GUI.

Analyzing Flight Recordings

Open the .jfr file in JMC. The main views you will use:

Automated Analysis View lists detected problems like excessive garbage collection, JVM configuration issues, and lock contention. This is where to start even before diving into details. The analysis flags things like “High GC frequency” or “Excessive hprof dump size” that correlate with performance issues.

Memory view shows allocation rates, object statistics, and GC causes. Look at the “Allocation in new generation” graph to see if allocation patterns match your expectations. Sudden spikes in allocation often correlate with specific application operations.

Code view displays the hottest methods and call trees. Sort by “CPU Usage” to find methods that consume the most CPU time. The “Compile” events show JIT compilation activity—frequent deoptimization or recompilation indicates unstable JIT optimization.

Thread view reveals thread states, lock contention, and I/O waits. The “Lock Instances” section shows which objects have threads waiting to acquire them. This is invaluable for diagnosing concurrency bottlenecks.

Heap Dump Analysis with JMC

JMC can trigger and analyze heap dumps without the latency hit of tools like jmap. The advantage is that JMC’s heap dump shows allocation sites—where each object was created—which significantly speeds up memory leak diagnosis.

# Trigger heap dump through JMX
jcmd <pid> GC.heap_dump filename=heapdump.hprof

# Analyze in JMC by opening the .hprof file
# Or use jmap for simple histograms
jmap -histo <pid> | head -50

In JMC’s heap dump view, the “Allocations” tab shows the allocation site for each object. This tells you exactly which code path created leaked objects, not just that they exist.

Production Failure Scenarios

Scenario 1: Identifying JIT Compilation Hotspots

A latency-sensitive service shows occasional 100ms+ pauses that do not correlate with GC. Flight recorder data reveals the pauses occur during JIT deoptimization—methods that the JIT compiler optimized aggressively are being reverted. This typically happens when JIT assumptions prove wrong, like classes loading that invalidate type profiles.

The solution involves identifying the affected methods and either fixing the code that triggers deoptimization or adding guards that stabilize JIT behavior.

Scenario 2: Finding Memory Leaks with Allocation Analysis

A service that runs fine for hours starts exhibiting high memory usage and eventually crashes with OutOfMemoryError. Heap dump analysis in JMC shows unexpected classloaders holding references, or a cache implementation growing without bounds.

The allocation site information points directly to the problematic code rather than the symptom location.

Scenario 3: Diagnosing Lock Contention

An application with multiple threads shows low CPU utilization despite high load. Flight recorder data reveals threads spending significant time blocked on locks. The thread view shows which locks are contended and which code paths acquire them.

This points to opportunities for reducing lock granularity or using concurrent data structures.

Trade-off Table

Feature	JMC Flight Recorder	async-profiler	YourKit/JProfiler
Overhead	2-5% typical	1-3%	5-15%
Allocation profiling	Yes	Yes	Yes
Allocation sites	Yes	Yes	Yes
Continuous recording	Yes	No	No
Heap dumps	Yes (with sites)	No	Yes
Interface quality	Poor	Good	Excellent
Cost	Free with JDK	Free	Commercial

Implementation Snippets

Programmatic Flight Recording Control

import jdk.jfr.*;
import java.lang.reflect.*;

public class FlightRecorderController {

    public static void startRecording(String name, Duration duration)
            throws Exception {
        // Use reflection for newer JFR APIs
        Class<?> flightRecorderClass =
            Class.forName("jdk.jfr.FlightRecorder");
        Method getFlightRecorder =
            flightRecorderClass.getMethod("getFlightRecorder");
        Object recorder = getFlightRecorder.invoke(null);

        Class<?> recordingOptionsBuilderClass =
            Class.forName("jdk.jfr.RecordingOptionsBuilder");
        Object builder = recordingOptionsBuilderClass
            .getConstructor(String.class)
            .newInstance(name);

        Method withDuration =
            recordingOptionsBuilderClass.getMethod("withDuration", Duration.class);
        withDuration.invoke(builder, duration);

        Method build = recordingOptionsBuilderClass.getMethod("build");
        Object options = build.invoke(builder);

        Class<?> flightRecorderClass2 =
            Class.forName("jdk.jfr.FlightRecorder");
        Method startRecording =
            flightRecorderClass2.getMethod("startRecording", options.getClass());
        startRecording.invoke(recorder, options);
    }

    public static void dumpRecording(String filename) throws Exception {
        Class<?> flightRecorderClass =
            Class.forName("jdk.jfr.FlightRecorder");
        Method getFlightRecorder =
            flightRecorderClass.getMethod("getFlightRecorder");
        Object recorder = getFlightRecorder.invoke(null);

        Method stopRecording =
            flightRecorderClass.getMethod("stop", String.class);
        Object recording = stopRecording.invoke(recorder, filename);

        Method dump = recording.getClass().getMethod("dump", String.class);
        dump.invoke(recording, filename);
    }
}

Connecting to JMC Programmatically

import javax.management.*;
import java.lang.management.*;

public class JmcConnection {

    public static void main(String[] args) throws Exception {
        // Connect to local or remote JVM via JMX
        String url = "service:jmx:rmi:///jndi/rmi://localhost:7091/jmxrmi";
        JMXServiceURL serviceUrl = new JMXServiceURL(url);
        JMXConnector connector =
            JMXConnectorFactory.connect(serviceUrl);
        MBeanServerConnection mbsc =
            connector.getMBeanServerConnection();

        // Access flight recorder MXBean
        ObjectName name = new ObjectName(
            "jdk.management.jfr:type=FlightRecorder");
        JmxFlightRecorderMXBean frBean =
            JmxFlightRecorderMXBean.cast(
                mbsc.getObjectInstance(name));

        // Check recording status
        System.out.println("Recordings: " + frBean.getRecordings());
    }
}

Observability Checklist

Before considering profiling complete, verify these points. Flight recordings captured the relevant time window during actual production load. The recording settings matched your information needs—profile settings capture more detail but use more overhead. The JVM had sufficient buffer space—recording data lost to buffer overflow reduces analysis quality. You have matched the production environment closely enough that findings apply.

Also confirm that your JVM flags did not disable JMC or flight recorder, some security policies restrict flight recorder access, and JDK version matches between recording and analysis.

Security and Compliance Notes

Flight recordings contain sensitive data. Method names, class names, and stack traces reveal application internals that you may not want exposed. The string pool in recordings can contain user data, passwords in memory, or other sensitive content.

Restrict JMX access to flight recorder MBeans. Use authentication and TLS for JMX connections in production. Do not transfer flight recordings over untrusted networks without encryption.

Compliance teams may require handling flight recordings as sensitive operational data. Include them in your data classification and handling procedures.

Common Pitfalls / Anti-Patterns

The biggest mistake is using settings=profile when settings=default suffices. The profiling template adds significant overhead and storage costs for data you often do not need. Start with default and only use profile when investigating specific issues.

Another common error is analyzing recordings from unrepresentative periods. A recording captured during application warmup shows different behavior than steady state. Always capture recordings during actual production conditions.

Forgetting to increase the buffer size loses data. With insufficient buffer, old events are discarded before you can download them. Monitor buffer utilization when setting up continuous recording.

Finally, using JMC against a different JDK version than the recording JVM can cause parsing errors or missing data. Always match versions when possible.

Quick Recap Checklist

• Enable flight recorder with -XX:StartFlightRecording or JCMD
• Use settings=default for continuous production recording
• Run automated analysis first to identify obvious issues
• Use Memory view for allocation patterns, Code view for CPU hotspots
• Correlate JMC data with application logs and metrics
• Protect flight recordings—they expose internal application details
• Match JDK versions between recording and analysis

Interview Questions

Further Reading

• JDK Mission Control Documentation — Official Oracle documentation for JMC and JFR
• Java Flight Recorder API — Complete JFR API reference for programmatic control
• JMC GitHub Repository — OpenJDK Mission Control source code and community contributions
• JDK Mission Control YouTube Channel — Video tutorials and demos from the JMC team
• Troubleshooting Java with JMC — Oracle guide on using JMC for JVM troubleshooting

Conclusion

Java Mission Control and Java Flight Recorder together provide production-safe profiling with minimal overhead. Enable flight recorder with -XX:StartFlightRecording or through JCMD for continuous monitoring. Use the automated analysis view first to identify obvious issues, then dive into Memory, Code, and Thread views for detailed investigation.

JMC excels at correlating application behavior with JVM internals like JIT compilation, GC activity, and lock contention. The built-in nature of JFR means it works without additional agent installation. For performance troubleshooting in production, JMC and JFR should be your first tools before reaching for third-party profilers with higher overhead.