What's new in JProfiler

The newly supported subsystems:

• Heap dump analysis: Heap dumps can be taken in live sessions, and both new and existing snapshots can be analyzed with class histograms, biggest objects, instance queries with value filters, reference chains, paths to GC roots, dominator chains and automated heap inspections. Heap walker scripts can be used for filtering and custom grouping.
• Probe events: Individual events with back traces, event histograms and event timelines can be queried, and open control objects such as JDBC connections are listed for leak analysis together with the stack trace of the open call.
• Monitors and locks: Monitor statistics, contention timelines, locking history and lock graphs are available, as well as monitor dumps of live JVMs for deadlock analysis.
• Thread dumps can be taken, including virtual thread hierarchies.
• GC data: Individual garbage collections with causes, pause times, phases and heap usage, as well as the GC configuration and flags.
• MBean snapshots: Current JMX MBean attribute values can be captured on demand or periodically.
• Telemetries: All telemetry datasets are available, from CPU and heap usage to the probe telemetries.
• Allocation recordings: Allocation hot spots and call trees show the allocated classes and bytes per call site, including objects that have already been garbage collected.
• Method complexity analysis: A script defines the complexity of each method call, for example the size of an input collection, and curve fits relate the measured execution times to common big-O complexities.
• JavaScript origin tracking: Browser call stacks for XHR requests in the profiled application.

CPU analysis has been extended as well: agents can now select threads and thread groups, filter by thread status, attribute hot spots and call tree nodes to individual threads, and track down occasionally slow calls with outlier detection and exceptional method recording.

Triggers let agents capture data that interactive tool calls cannot catch. Actions such as thread dumps, heap dumps and MBean snapshots can fire automatically on a timer, when a heap or CPU threshold is crossed, or when a particular method is invoked. This makes it possible to record from JVM start and to watch long-running sessions for transient states like heap spikes. The same actions can also be executed directly as live actions on a running JVM.

With script probes, agents can define entirely new probes on the fly: a script probe intercepts selected methods with a snippet of Java code and records its results like a built-in probe, without any deployment step. For permanent instrumentation, agents can write custom probes that become part of the profiled application, most conveniently as embedded probes with the embedded probe API. Custom probes are recorded and analyzed in the same way as built-in probes, and the probe configuration as well as the script and custom probe APIs are exposed as MCP resources, so agents can look them up while they work.

All data is retrieved through a single query tool with jq expressions that replaces the many special-purpose tools of previous versions. The smaller, uniform set of tools makes agents more reliable: there is one way to filter, aggregate and drill into profiling data, and it works the same across all subsystems.

Setup is unchanged: configure your agent from the JProfiler UI or follow the instructions on the MCP setup page.

Expanding a container shows the managed objects directly, without any chains of framework registry internals in between. Questions like "which servlet session retains the most memory" or "which Spring application context does this object belong to" can now be answered directly in the biggest objects view.

Alternatively, the plugin can be configured in the POM:

<plugin>
  <groupId>com.jprofiler</groupId>
  <artifactId>jprofiler-maven</artifactId>
  <version>16.3</version>
  <configuration>
    <mainClass>com.example.Main</mainClass>
  </configuration>
</plugin>

Then mvn jprofiler:profile is sufficient. Further goals support headless work in CI environments: export, compare and analyze process snapshots from the command line, and set-agentpath-property prepares a property with the -agentpath VM parameter for use by other plugins. See the Maven goals documentation for details.

In Gradle, simply omitting the installation directory is sufficient:

jprofiler {
    // installDir = file('/opt/jprofiler')
}

Without installDir, the plugin downloads a JProfiler distribution whose version matches the plugin version and caches it in the Gradle user home directory. The Maven goals work the same way.

This removes any distortions of the measurement through constructor instrumentation that could disable escape analysis in the HotSpot JIT. At the same time, the recording overhead is lower.

The sampling interval is now configured in bytes with a default of 1024. On Java 8 and JVMs without the JVMTI sampling capability, the previous instrumentation-based recording is used automatically.

The same inline settings and recording options are also available for the jpenable command line tool, which attaches the profiling agent to an already running JVM. When you select offline mode, jpenable guides you through the settings with its interactive rich console.

Alternatively, you can supply the settings on the command line with --call-tree-mode, --profile, --line-numbers, --snapshot, --recording, --duration and more for non-interactive use in a CI pipeline.

The Gradle and Ant profiling tasks expose the same capability through task attributes, so you can configure offline profiling and automated recording sequences right in your build script.

The tools exposed by the MCP server have been carefully crafted and tested so that agents reliably follow a profiling workflow that mirrors how an expert would use JProfiler. The agent first sets up profiling for the target application. After the test run completes, it checks for data availability and retrieves the initial aggregated hotspot view to understand where time is being spent. From there, it drills into specific hotspots, following the call chain to the root cause.

The data at each step is carefully filtered so agents see what matters without being overwhelmed, whether they are analyzing CPU hotspots, JDBC and JPA queries, HTTP calls, MongoDB operations, or heap dumps. Beyond live profiling of local and containerized JVMs, agents can also load existing JProfiler, HPROF, or JFR snapshots for analysis.

Setup is zero-friction: the MCP server auto-installs the JProfiler binary on first use and handles licensing through the MCP protocol. You can set up your agent directly from the JProfiler UI, or follow the instructions on the MCP setup page. For the full story behind this release, see the announcement blog post.

The AI probe is event-centric. You can work with subsets of recorded events in two ways: First, when you select multiple events, the selection panel at the bottom provides CPU hot spots, probe hot spots, and a probe call tree for the current selection.

For more thorough investigations, the filter selector at the top and the various tabs in the lower section allow you to restrict the set of events in the main table and associated views.

By default, the AI probe identifies hot spots based on the specific model names that processed the request. This data is available not only in the events view, but also in the hot spot view of the AI probe, even if no events are recorded.

Model name hot spots are only one of many potentially interesting types of hot spots. In the probe settings, you can configure a script to calculate user-defined types of hot spots by entering some Java code in JProfiler's powerful script editor.

When an AI probe event is recorded, JProfiler invokes this script with a ModelRequest parameter. This parameter provides access to the request type, the model name, and all instructions along with their instruction types.

For example, you could define hot spots by grouping prompt lengths into 50-character buckets. The example below demonstrates how this is done.

Since JProfiler displays data live during recording, you can change these settings while profiling and observe the effects immediately.

With the above script, the new hot spots look like this:

By default, hot spots focus on the request duration, but you can switch the primary measurement to input tokens and output tokens as well.

This is possible both in the probe hot spots view and the probe call tree view. The probe call tree view shows a top-down view connecting method calls to probe payloads.

The probe telemetries for the AI probe show request counts, average request duration, and a combined input/output token graph separately for chat requests and embedding requests.

Each telemetry can be shown separately and can be used to select events for particular areas of interest.

To help you explore the AI probe, JProfiler now comes with an "LLM demo" session.

It uses Jlama, a cross-platform inference engine for Java 21+ and downloads a 0.5-billion-parameter model from Hugging Face to categorize LLM-related preprints from arXiv.

The demo features a UI where keywords produced by the LLM are continually inserted and you can explore the associated research papers on the right.

In addition, the UI is now fully scalable. In the general settings, you can either set a scale factor as a percentage, or set a custom UI font with an arbitrary size, and the UI will be scaled accordingly.

This capability now allows the JProfiler UI to run on Linux with all OpenJDK variants and for all HiDPI resolutions. Previously, only the JetBrains runtime was supported on Linux with HiDPI resolutions.

As a related enhancement, it is now possible to attach to Windows processes running as other users, even if JProfiler is not installed in a directory that is readable by those processes. This is especially important for attaching to Windows services.

While the table only shows a limited number of events, you can add more events when scrolling to the bottom. When sorting by a column, the entire set of filtered events is considered, not just the currently visible rows.

Totals in the table are also calculated for the entire set of filtered events.

The lower "Hot Spots" tab contains a CPU hot spots view, a probe hot spots view, and a probe call tree – similar to the "Selection" tab, but calculated for all filtered events rather than the selected rows.

In each of these views, you can use the filter button to restrict the displayed events for the main event table and all other views at the bottom. Below you can see a call stack filter in the probe call tree where the filtered node is marked with a filter icon.

Depending on the measurements performed by a probe, additional histogram views are available at the bottom. For the "Files" and the "Sockets" probes these are "Duration" and "Throughput".

Histograms can be shown with a logarithmic y-axis and support filtering by dragging a range with the mouse.

Finally, smart column management in the events view has been implemented. Based on the width of all columns and the available viewport width, JProfiler decides whether to fit the columns into the viewport or activate horizontal scrolling. Resizing columns manually disables the "fit-to-viewport" mode, which automatically reactivates if the total table width becomes smaller than the viewport.

Metric selectors are now also available on the "Selection" and "Hot Spots" tabs of the probe events view. Since "Read" and "Write" events can be filtered separately in the events view, there is a single combined "Throughput" measurement.

Support for throttle settings has been added in the JFR recording wizard. For example, the new jdk.CPUTimeSample event in Java 25 is configured via throttling. You can alternatively enter a period or an emission rate with a /s unit.

Throttle settings are also displayed in the CPU views next to the thread status selector.

For calculating data in the CPU section, the new Linux-only jdk.CPUTimeSample event (Java 25+) is now used if recorded, instead of the older jdk.ExecutionSample event. Unlike jdk.ExecutionSample, which works on all platforms, but has limitations in the number of threads it samples and the accuracy of CPU usage, jdk.CPUTimeSample uses CPU time events from the Linux kernel to collect data.

With this event, CPU profiling with JFR can now provide actionable CPU metrics on production systems where loading a JVMTI agent is not permitted.

Starting with JProfiler 16, all experimental JFR events are now shown in the event browser, such as the jdk.CPUTimeSample event.

Virtual threads are hierarchically organized within their thread containers. This is relevant when using structured concurrency, which is still a preview feature as of Java 25.

In structured concurrency, each scope creates a corresponding thread container. Since a dump may contain millions of virtual threads in deeply nested containers, virtual thread dumps can be significantly larger than platform thread dumps.

You can compare two single virtual threads or two entire thread dumps by selecting them and choosing the comparison action in the context menu.

The comparison is shown in a diff viewer in a separate window.

To copy single threads, multiple threads, or entire thread dumps to the clipboard, use the corresponding action in the context menu.

Virtual thread dumps group threads with the same stack trace in the same hierarchical position into a single node.

The context menu contains an action to show all grouped thread names.

The names of grouped threads are displayed in a separate window where you can filter for thread names of interest.

Thread grouping is also supported for platform thread dumps.

A separate dialog with a percentage breakdown of all contributing threads is shown. You can optionally select one thread and switch to the call tree for that thread in the call tree view.

The feature helps identify thread-specific performance issues. For example, you may want to isolate a misbehaving thread from a thread pool.

Many tables in JProfiler have columns containing long text that exceeds the column width. The node detail dialog shows the complete text in this case. Starting with JProfiler 16, there is a hover button that directly opens the node detail dialog and activates the correct tab if there are multiple long text columns in the table.

In the heap walker, the node detail dialog now shows the full values for string values in the reference views, not just the displayed truncated preview string.

Similar to the existing deobfuscation support when opening snapshots, the file chooser now includes a "Deobfuscate" check box when adding snapshots to the comparison window.

When selected, a dialog with a drop-down for supported obfuscators and a field for the mapping file path appears.

If different snapshot files have different mapping files, you can add the snapshots individually.

Once the mapping file is applied, all comparisons in JProfiler now show the original class and method names.

You can unpin pinned rows individually or all at once.

JProfiler 16 also introduces a sorting drop-down that offers ascending and descending sort directions and a new default sort mode where active long-lived rows are shown first, followed by recently closed rows.

The "Kafka consumer" probe measures the events that you process. For Spring Kafka, event timings are recorded.

Single events can be analyzed in the "Events" view, where values for event type, thread name, partition, key and value size are also shown.

The Kafka probes contribute several telemetries, like "Event count" and "Average listener execution time" that can also be added in the main "Telemetries" view section.

Both probes offer the same flexibility for naming hot spots and events. By default, hot spots are named with the message topic. You can use a script to build the strings for the hot spots yourself using an API provided by JProfiler. Naming hot spots is important because it determines the grouping in the hot spots view.

Optionally, you can use a different script for the naming of single events in the "Events" view. This will not affect hot spot grouping and is a way to provide more detail for debugging.

Recording events from either probe adds data in the regular call tree views in the "CPU views section". For the "Kafka producer" probe, hyperlinks are inserted into the call tree for revealing the associated call stack in the call tree view of the probe.

The Kafka consumer probe splits the call tree for Spring event listeners, so you can see the subtree for different types of messages separately. The grouping is done with the configured "hot spots" naming.

The extension adds two actions: With "Enable Profiling with JProfiler" you toggle the profiling mode, so that all debug and run actions will start profiling for Java launch configurations. With "Attach to a running JVM with JProfiler" you can use the attach mode feature for local or remote JVMs and get source code navigation into VS code.

Depending on the status of this pull request for the vscode-gradle plugin, profiling Gradle tasks is also supported by the "Enable Profiling with JProfiler" action.

The JProfiler plugin only has a few settings, notably for the location of the JProfiler executable and a setting whether to open new windows for new profiling sessions.

All other profiling settings are handled by JProfiler and stored on a per-project basis. When you start a profiling session, the session startup dialog gives you a chance to view and modify all settings in one place.

When profiling unit tests, JProfiler will automatically suggest saving and immediately opening a snapshot when the JVM exits.

Switching to VS code when working with the JProfiler UI is seamlessly possible with the "Activate IDE" action (F11).

To show the source code of a selected class or method, use the "Show source" action that is visible everywhere in JProfiler. The VS Code UI will be brought to the front, and the associated source code will be shown.

Another useful feature provided by the JProfiler VS Code plugin is that you can open JProfiler, HPROF and PHD snapshots from inside VS Code to get source code navigation from the JProfiler UI into VS Code.

For example, if you want to connect to an EC2 instance via AWS session manager, the built-in SSH client does not work because it cannot tunnel through an arbitrary proxy. In the AWS documentation, you get a list of options that you can either add to the OpenSSH config file or directly on the command line, both of which work with the new OpenSSH mode in JProfiler. This involves a ProxyCommand option that tunnels the connection through the aws executable. In the screenshot below, the "SSH options" text field contains these arguments.

The only required input for the OpenSSH mode is the host name.

In the case where you use the OpenSSH config file to define your fully configured SSH servers, you can easily select them with the "Choose" button next to the "Host" text field.

When a connection fails in such a way that disabled port forwarding may be to blame, JProfiler suggest switching to the netcat mode.

MBean snapshots can be assigned labels that are displayed in the view selector. Unwanted MBean snapshots can also be removed again.

When you take an MBean snapshot, a bookmark is added to all views that have a time axis.

If you set a filter for the displayed MBeans, only the displayed subtrees will be included in the snapshot.

In the MBean snapshot trigger action, you can set a label as well as a filter for the included MBeans as well.

The toolbar above the dump selector offers actions to label and remove selected dumps.

A trigger action has been added to take all object dumps programmatically, either in live mode or during offline profiling.

On a related note, it is now possible to label dumps in the thread dumps view as well. This can also be done via the trigger action and the Controller API.

It creates a new call tree analysis view below the main call tree view that shows a static copy of the selected root, or the entire call tree if no node was selected. All other view parameters like thread status or aggregation level are fixed in the call tree snapshot.

Unlike other call tree analyses, call tree snapshots are saved into JProfiler snapshots, because they contain separate data.

With this tool, you can manage different call tree recordings without resorting to saving full snapshots that you have to open in different JProfiler windows. Instead, you can remain in the same live session and keep different sets of recording data around.

In the call tree snapshot view, a "Calculate hot spots" analysis action is available besides the usual call tree analysis types.

The resulting hot spot view is added as a child of the call tree snapshot view and shows the static hot spots for the data in the parent view. The hot spot calculation options are still adjustable here.

In addition, the "Reload analysis" button goes back to the top level ancestor view and re-calculates all ancestor views and all descendant views for the new data. In the example below, the current data in the live call tree would be used to update the call tree view labeled "First run" and then the flame graph views labeled "Reload" and "Render".

In the script editor, objects from the com.jprofiler.api.agent.heap API are passed as an argument, and the boolean return value of the script decides whether the object is included in the new object set.

In general, the parameter is of type com.jprofiler.api.agent.heap.HeapObject but can be narrowed to a subtype if the current object set allows it. In the screenshot below, the current object set only contained java.util.HashMap$Node instances, so the parameter is of type com.jprofiler.api.agent.heap.Instance which provides access to field values.

The script selects java.util.HashMap$Node instances whose value is a java.awt.Font with a size of 12.

In addition to the filter script in the references view, JProfiler provides an inspection to filter all objects in the current object set as well an inspection which groups all objects according to the string return value of a script.

In the "Custom grouping on dumped data" script below, all regular instances are grouped by the number of strings that they reference. If the passed object is not a regular instance or if it does not reference any strings, the script returns null and the object is not included.

As for other kings of groupings, a grouping selector is shown at the top after the inspection has been calculated. When you select a group row, the current heap walker view will only show the instances that are contained in that group.

With the new "Next enabled view" and "Previous enabled view" actions, you can quickly step through all relevant views.

For live sessions, the views displaying recorded data now have a special marker in front of the view name.