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.

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

• 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 allocation call tree is chosen.

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

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.

• 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.
  • 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.

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 filtered classes are consolidated in the first call into a filtered class.