Virtual threads are not recorded separately like platform threads, so all virtual threads are contained together in a single synthetic thread group.

By default, only mounted virtual threads are sampled. This means that blocking states of virtual threads are not captured by CPU recording. For debugging purposes, there is an option in the profiling settings to sample unmounted virtual threads.

Like for platform threads, JProfiler supports async tracking for the creation of new virtual threads. If enabled, the "Inline Async Executions" call tree analysis connects call sites with execution sites. In this case, the call site is the last profiled method before the VirtualThread instance is created. The execution site is a top-level node in the started virtual thread.

Its main view is the "Garbage collections" view that shows single garbage collections in tabular form. It shows you the triggering cause, how long the collection took, how many references were collected and what pauses were caused by the garbage collection.

If you need even more detail, each garbage collection can be expanded to show the single phases with their duration. To the right of the GC phase table, statistics about the changes in heap and metaspace are shown.

To help you analyze important garbage collections, you can set multiple filters, most conveniently with the context actions on the garbage collections table and the phase table. Filters are added as tag labels above the table and can be removed by clicking their close button.

The GC probe produces a number of GC telemetries which are available in the "Telemetries" probe view.

If you are interested in minimizing GC pauses, the "Longest pause" telemetry at the top will be the most interesting one. You can drag along the time axis of the telemetry to select the corresponding garbage collections in the "Garbage Collections" view. For better vertical resolution, you can select a single telemetry from the drop-down at the top or by clicking on the name of the telemetry.

The GC summary view shows you measurements that are aggregated over the entire recording period. Each measurement provides the number of garbage collections, as well as the average, maximum and the total values. The most important data at the top are the "Pause times" that directly affect the liveness of your application.

In the GC configuration view, you can inspect the common properties that can either be set explicitly or that are set implicitly by the garbage collector itself. These properties are common to all garbage collectors and help you understand the differences between garbage collectors.

Finally, the GC flags view gives you an idea what properties of a garbage collector can be tuned and lets you check their actual values. The "Origin" column shows you how the flag was set.

JProfiler can track remote gRPC calls between JVMs if gRPC remote request tracking is enabled.

You can then see hyperlink labels in the call tree view for incoming and outgoing calls that will take you to the corresponding call tree location. This requires that both JVMs are profiled in separate windows or snapshots are opened that were recorded during the remote call.

In the selection area, the stack trace of the selected event is shown if it was recorded. If you select multiple events, a call tree or a hot spots view is shown for them. If the selected event types have time, memory or frequency measurements, you can choose to calculate the hot spots for any of those measurements.

To avoid overloading the UI, the event table only shows a maximum of 10000 events. The analysis views operate on all events in the snapshot. Due to the nature of JFR recording, JFR snapshots can become very large, so JProfiler's event browser has been optimized for maximum speed even for extreme file sizes.

The "Hot Spots" and the "Call Tree" views are like their counterparts in the "Selection" area, but for all events of the selected event types. Also, you can add call stack filters and hot spot filters and an optional back trace part.

Any analysis view itself is calculated from all filtered events, but excluding the filter that was set in the analysis view itself. This makes the analysis view more useful because you can see what part of the total event set you have selected there.

The "Time Line" view shows a histogram of all event start times. You can select a time range with the mouse and filter the events in the table. By default, the view has a logarithmic vertical axis.

For each event column that contains a durations, memory sizes or a frequency, JProfiler adds a histogram view. Histograms show event counts on their vertical axis while the horizontal axis shows the selected measurement. Bin sizes and event counts are available from the tooltip. Event filters can be added in histogram views by selecting a range on the horizontal axis.

The view settings dialog of the event browser allows you to customize the views. For example, the scales for the columns that are currently shown can be adjusted there.

Apart from the JFR browser, a subset of JProfiler's views that match with data provided by JFR are available when opening snapshots. This is a capability that JProfiler already had before. In addition, the new garbage collector probe is now available for JFR snapshots.

Even if you are not interested in any particular JFR data, this recording mode can be useful if you are trying to obtain information about a production environment where a native profiling agent that uses the JVMTI may not be loaded. JFR snapshots can contain data about the runtime characteristics and even allow you to detect a pronounced CPU hot spot.

This is similar to the adjacent "Heap dump only" option that takes an HPROF memory snapshot without loading the profiling agent.

When you start JFR recording, a wizard is shown that lets you choose the JFR recording settings.

To avoid that the JFR recording fills up your entire hard disk, a maximum snapshot size has to be set. If exceeded, old chunks of data are discarded.

JFR configurations files are located in the "lib/jfr" directory of the JRE. They contain a high-level configuration scheme that is shown as a UI by JProfiler on the same wizard step.

In the next step of the wizard, the result of this configuration is shown as a tree of all JFR events. If you have already profiled this JRE before, JProfiler will offer you to use the last settings.

After recording is started, the JFR recording button changes to show "Stop JFR". Also, the background color of the unselected JVM entry in the table changes to show that a JProfiler JFR recording is running.

After clicking "Stop JFR", the JFR snapshot is transmitted to the local machine and opened in JProfiler. These snapshots are temporary. If you want to keep the snapshot for later analysis, you can save them with the "Save snapshot" action.

If a JVM where you have started a JFR recording in JProfiler terminates before you open it, the attach dialog will have a "Terminated JFR" entry for it, and you can use it to download the JFR snapshot that the JVM saved at exit.

If JFR recordings are running in a JVM that were not started by JProfiler, you can still open them in JProfiler. In that case, JProfiler will not show the recording wizard when you click the "Start JFR" button but a dialog where you can choose whether to start a new recording or open an existing JFR recording. Existing recordings will never be stopped by JProfiler.

When you select multiple events, the stack trace view at the bottom now shows cumulated data. For example, you can see the CPU hot spots of the selected events with backtraces.

The other available views are the "probe hot spots with backtraces" that have the payload at the top and the "probe call tree".

Scales for durations and throughputs can now be adjusted in the view settings dialog of the probe events view and the control objects view. These settings are saved separately for each probe.

Filtering in the probe events and the control objects views now works on a per-column basis. You can add multiple filters at the same time, either at the top of the table or most conveniently from the context menu, in order to use a value in the selected row. Filters are added as tag labels above the table and can be removed individually by closing them.

The probe events view now includes a histogram view for event durations and optionally a histogram view for throughputs if the probe measures memory. By default, the views are logarithmic, so you can easily spot outliers. By selecting a value range on the horizontal axis, you can add a filter for the probe events table.

You can now filter probe events by selecting a time range in the probe telemetry views. You can do that either by dragging the mouse or by using one of the selection actions in the context menu.

Probe event filters can now be set from the probe call tree and the probe hot spots view. The context menu in both tree views as well as the tool bar has an action to create a filter and switch to the probe events view.

Multiple control objects can now be selected and the associated events can be shown. This allows you to analyze events for an entire category of control objects.

Probe telemetries can be added to the VM telemetries section. Previously, you had to activate a probe and navigate to its telemetry view to see one of its telemetries. This made it difficult to compare them with the system telemetries or with telemetries from other probes. Now you can configure a session to include any number of probe telemetries directly in the VM telemetries section.

In the probe telemetry registry dialog, all available probe telemetries are listed and you can select multiple telemetries at once.

The probe telemetries are added at the bottom, but can be dragged to the desired index in the VM telemetries overview. Like the telemetries from the recording actions, probe telemetries have an inline recording button if recording is currently stopped, and the context menu allows you to navigate to the probe view.

In the full probe telemetries, you can select a time range to create a filter in the probe events view, just like in the probe view itself. After such a selection, the probe events view will be shown.

Telemetries that show rates are now shown as histograms. For example, this includes the recorded throughputs in the "Files" probe. Previously, these telemetries were shown as line graphs which did not give a sense of the total throughputs when looking at time periods much larger than a minute.

Finally, any telemetry can now be exported as SVG. The bitmap export is optionally still supported.

The current monitor snapshot also makes it possible to save this information in a JProfiler snapshot or to time the monitor snapshot programmatically. There is a new method in the controller API as well as a trigger action for this purpose.

Current monitors and current locking graph views now show java.util.concurrent locks. In attach mode, these views are now available, but only for java.util.concurrent locks.

Current monitors and locking graph views now group similar threads. This makes it easier to interpret locking situations with many threads and is important for supporting virtual threads where large numbers of threads may be active at the same time.

A "Show Source and a "Show Bytecode" action have been added to the context menu in the flame graph. As all such actions in JProfiler, the "Show Source" action will open the source file in the IDE if you are using an IDE integration.

Flame graph colorizations are now persisted, so you don't have to configure them each time again for new profiling sessions.

Finally, flame graphs can now be exported as SVG. The exported SVG has basic tooltips so you can see the method names and their times.