Allocation Call Tree

  The allocation call tree shows a top-down call tree cumulated for all threads and filtered according to the filter settings which is similar to the one shown in the call tree view in JProfiler's CPU section except that it shows allocations of class instances and arrays instead of time measurements.

In order to prepare an allocation call tree, you have to click on the  calculate toolbar button or choose View->Calculate Allocation Call Tree from JProfiler's main menu. If an allocation tree has already been calculated, the context sensitive menu also gives access to this action.

Before the allocation call tree is 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.

  JProfiler automatically detects Java EE components and displays the relevant nodes in the allocation call 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 allocation call tree was split. Note that HTTP nodes group request by the displayed URL.
  The allocation call tree 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 allocation call tree is chosen.

The allocation call 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 allocation call 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 allocation call 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.

A particular node is a bridge node if it would normally not be displayed in the view, but has descendant nodes that have to be displayed. The icons of bridge nodes are grayed out. For the allocation call tree view this is the case if the current node has no allocations, but there are descendant nodes that have allocations.

  When navigating through the allocation call 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 allocation call 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 allocation call 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.
 
  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.

  The tree map selector above the allocation call tree view allows you to switch to an alternate visualization: A tree map that shows all call stacks as a set of nested rectangles. Please see the help on tree maps for more information.
  If enabled in the view settings, every node in the allocation call tree has a size bar whose length is proportional to the total number of allocations including all descendant nodes and whose light-red part indicates the percentage of allocations in the current node.
  Every node in the allocation call tree has textual information attached that depends on the allocation call tree settings and shows
  • a percentage number which is calculated with respect to the root of the tree or calling node.
  • a size measurement in bytes or kB which displays the shallow size of those objects which were allocated here (depends on cumulation view setting, see below).
  • an allocation count which shows how many instances of classes and arrays have been allocated here (depends on cumulation view setting, see below).
  • 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.

The size and the allocation count are either cumulated for all calls below the associated node or not, depending on the corresponding cumulation view setting. Note that allocations performed in calls to unprofiled classes are consolidated in the first call into a filtered class.
  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 call tree 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 spot.