Allocation Hot Spots View

The allocation hot spots view shows a list of methods where objects of a selected class have been allocated. Only methods which contribute at least 0.1% of the total number of allocations are included. The methods are filtered according to the filter settings. This view is similar to the hot spots view in JProfiler's CPU section except that it shows allocations of class instances and arrays instead of time measurements.

Note: The notion of a hot spot is relative. Hot spots depend on the filter sets that you have enabled in the filter settings. Filtered methods are opaque, in the sense that they include allocations performed in calls into other filtered methods. If you change your filter sets you're likely to get different hot spots since you are changing your point of view. Please see the help topic on hot spots and filters for a detailed discussion.

In order to prepare allocation hot spots, you have to click on the calculate toolbar button or choose View->Calculate Allocation Hot Spots from JProfiler's main menu. If allocation hot spots have already been calculated, the context sensitive menu also gives access to this action.

Before the allocation hot spots are calculated, the allocation options dialog is shown. The class or package selection as well as the selected liveness mode are displayed at the top of the allocation call tree view.

The hot spot calculation options can be selected in the drop-down list above the table labeled "Hot spot options". The allocated memory calculation section lets you calculate hot spots from

Self
This is the default option and is preferable in most situations. Hot spots are calculated based on their cumulated self allocated memory, excluding calls to other recorded methods.
Total
With this option, hot spots will be calculated based on the total allocated memory that you see in the call tree. Methods near the top of the call stack will always be the top hot spots.

Hot spots can be different, depending on how unprofiled classes are handled:

Show separately
The displayed hot spots are calculated from all method calls in the call tree. Unprofiled classes are measured if they are called directly from profiled classes, so they can contribute hot spots of their own. This is the default mode.
Add to calling class
Calls to unprofiled classes are always added to the calling class. In this mode, an unprofiled class cannot contribute a hot spot, except if it is a thread entry method (run and main methods).

Depending on your selection of the aggregation level, the method hot spots will change. They and their hot spot backtraces will be aggregated into classes or packages or filtered for Java EE component types.

By setting a view filter, you can analyze hot spots in selected packages. The cutoff will then be calculated relative to the set of filtered classes. In that way, hot spots may be shown that are otherwise below the cutoff threshold.

Note: The notion of a method hot spot is relative. Method hot spots depend on the filter sets that you have enabled in the filter settings. Filtered methods are opaque, in the sense that calls into other filtered methods are attributed to their own allocated memory. If you change your filter sets you're likely to get different method hot spots since you are changing your point of view. Please see the help topic on hot spots and filters for a detailed discussion.

Every hot spot is described in several columns:

a name which depends on the aggregation level:
- methods
  a method name that is either fully qualified or relative with respect to to the calling method.
- classes
  a class name.
- packages
  a package name.
- Java EE components
  the display name of the Java EE component.
the percentage of all allocations together with a bar whose length is proportional to this value.
the number of allocations.

The hot spot list can be sorted on all columns.

If you click on the handle on the left side of a hot spot, a tree of backtraces will be shown. Every node in the backtrace tree has textual information attached to it which depends on the allocation hot spots view settings.

the percentage of all allocations. This value is calculated with respect either to the parent hot spot or the called method. The percentage base can be changed in the allocation hot spots view settings.
the number of allocations that are contributed to the hot spot along this call path. If enabled in the view settings, every node in the hot spot backtraces tree has a size bar whose length is proportional to this number.
Note: This is not the number of allocations in this method.
a name which depends on the aggregation level:
- methods
  a method name that is either fully qualified or relative with respect to to the calling method.
- classes
  a class name.
- packages
  a package name.
- Java EE components
  the display name of the Java EE component.
a line number which is only displayed if
- the aggregation level is set to "methods"
- line number resolution has been enabled in the profiling settings
- the calling class is unfiltered
Note that the line number shows the line number of the invocation and not of the method itself.

JProfiler automatically detects Java EE components and displays the relevant nodes in the hot spot backtraces tree with special icons that depend on the Java EE component type:

servlets

JSPs

EJBs

For certain classes, JProfiler shows a display name:

JSPs
the path of the JSP source file
EJBs
the name of the EJB interface
RMI proxies
the name of the remote interface
Web service proxies
the QName of the end point

If HTTP splitting is enabled in the servlet probe each request URL creates a new node with a

special icon and the prefix HTTP:, followed by the part of the request URL on which the hot spot backtraces tree was split. Note that HTTP nodes group request by the displayed URL.

The allocation hot spots view has an aggregation level selector. It allows you to switch between

methods
Every node in the tree is a method call. This is the default aggregation level. Special Java EE component methods have their own icon (see above) and display name, the real class name is appended in square brackets.
classes
Every node in the tree is a single class. Java EE component classes have their own icon (see above) and display name, the real class name is appended in square brackets.
packages
Every node in the tree is a single package. Sub-packages are not included.
Java EE components
Every node in the tree is a Java EE component. If the component has a separate display name, the real class names are omitted.

When you switch between two aggregation levels, JProfiler will make the best effort to preserve your current selection. When switching to a a more detailed aggregation level, there may not be a unique mapping and the first hit in the hot spot backtraces tree is chosen.

The hot spot backtraces tree doesn't display all method calls in the JVM, it only displays

profiled classes
Classes which are profiled according to your configured filter sets are used for the construction of the hot spot backtraces tree.
first level calls into unprofiled classes
Every call into a filtered class that originates from a profiled class is used for the construction of the hot spot backtraces tree. Further calls into unprofiled classes are not resolved. This means that a filtered node can include information from other filtered calls. Filtered nodes are painted with a red marker in the top left corner.
thread entry methods
The methods Runnable.run() and the main method are always displayed, regardless of the filter settings.

When navigating through the hot spot backtraces tree by opening method calls, JProfiler automatically expands methods which are only called by one other method themselves.

To quickly expand larger portions of the hot spot backtraces tree, select a method and choose View->Expand Multiple Levels from the main window's menu or choose the corresponding menu item from the context menu. A dialog is shown where you can adjust the number of levels (20 by default) and the threshold in per mille of the parent node's value that determines which child nodes are expanded.

If you want to collapse an opened part of the hot spot backtraces tree, select the topmost method that should remain visible and choose View->Collapse All from the main window's menu or the context menu.

If a method node is selected, the context menu allows you to quickly add a method trigger for the selected method with the

add method trigger action. A dialog will be displayed where you can choose whether to add the method interception to an existing method trigger or whether to create a new method trigger.

Nodes in the hot spot backtraces tree can be hidden by selecting them and hitting the DEL key or by choosing Hide Selected from the context menu. Percentages will be corrected accordingly as if the hidden node did not exist.

When you hide a node, the toolbar and the context menu will get a Show Hidden action. Invoking this action will bring up a dialog where you can select hidden elements to be shown again.

For method, class or package nodes, the context menu and the View menu have an Add Filter From Selection entry. The sub-menu contains actions to add appropriate filters as well as an action to add an ignored method entry.

If a node is excluded, you will get options to add a profiled package, otherwise you will get options to add a compact or ignored filter. These actions are not available for classes in the "java." packages.

By marking the current state, you can follow the evolution of the allocation hot spots. This is particularly useful for quickly finding the origin of memory leaks. Marking the current values can be achieved by

choosing View->Mark Current Values from JProfiler's main menu
choosing the corresponding toolbar entry
choosing Mark Current Values from the context menu

Upon marking, a fourth column labeled Difference appears with all values initially set to zero. With each subsequent calculation of the allocation hot spots, the column's values track the difference of the allocation count with respect to the point in time where the mark was set. The graphical representation of the percentage column shows the marked state in green and positive differences in red.

By default, the difference column is sorted on the absolute values in it, this can be changed in the allocation hot spots view settings dialog.

You can remove the mark by

choosing View->Remove Mark from JProfiler's main menu
choosing Remove Mark from the context menu

If garbage collected objects are shown, you can reset the accumulated data by clicking on the reset action in the toolbar or choosing the the Reset Garbage Collector History menu item in the View or context menu. All garbage collector data will be cleared and the view will be empty for the "Garbage collected objects" mode until further objects are garbage collected and a new allocation call tree or allocation hot spots are calculated. Note that you can force garbage collection by clicking on the garbage collector tool bar button or by selecting Profiler->Run Garbage Collector from JProfiler's main menu.

Only recorded objects will be displayed in the allocation hot spots view. See the memory section overview for further details on allocation call stack recording.

The View->Take Heap Snapshot For Selection menu item and the corresponding toolbar entry take a new snapshot, switch to the heap walker view and create an object set with the currently selected class and allocation hot spot.