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 active filter sets. 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 on the method call recording tab of the profiling settings dialog. 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 hotspots 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 combo box at the top-right corner of the view allows you to treat allocations of filtered classes in two different ways:
  • show separately
    Filtered classes can contribute hotspots of their own. This is the default mode.
  • add to calling class
    Allocations of filtered classes are always added to the calling class. In this mode, a filtered class cannot contribute a hotspot, except if it has a thread entry method (run and main methods).

With these two modes you can change your viewpoint and the definition of a hotspot. Please see the help topic on hotspots and filters for a detailed discussion of this topic.

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 J2EE component types.

  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.
    • J2EE components
      the display name of the J2EE 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 percentage 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.
    • J2EE components
      the display name of the J2EE 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 J2EE components and displays the relevant nodes in the hot spot backtraces tree with special icons that depend on the J2EE component type:

 servlets
 JSPs
 EJBs

For JSPs and EJBs, JProfiler shows a display name:
  • JSPs
    the path of the JSP source file
  • EJBs
    the name of the EJB interface

If URL splitting is enabled, each request URL creates a new node with a  special icon and the prefix URL:, followed by the part of the request URL on which the hot spot backtraces tree was split. Note that URL nodes group request by the displayed URL.

You can disable both J2EE component detection as well as URL splitting on the Java Subsystems tab of the profiling settings. Also, the URL splitting method can be customized in the profiling settings or with a custom handler in the profiling API.

  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 J2EE 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. J2EE 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.
  • J2EE components
    Every node in the tree is a J2EE 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

  • unfiltered classes
    Classes which are unfiltered according to your configured filter sets are used for the construction of the hot spot backtraces tree.
  • first level calls into unfiltered classes
    Every call into a filtered class that originates from an unfiltered class is used for the construction of the hot spot backtraces tree. Further calls into filtered 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 10 levels from the main window's menu or choose the corresponding menu item from the context menu. 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.

  By marking the current state, you can follow the evolution of the allocation hotspots. 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 for this view 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 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.