1. method calls
   
   • method calls (show filtered classes separately)
     The displayed hot spots are calculated from method calls. Filtered classes can contribute hotspots of their own. This is the default mode.
   • method calls (add filtered classes to calling class)
     The displayed hot spots are are calculated from method calls. Calls to 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).

   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.

   Note: The notion of a method hot spot is relative. Method 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 calls into other filtered methods are attributed to their own time. 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 hotspots and filters for a detailed discussion.

2. J2EE related calls
   
   • JDBC calls
     The displayed hot spots are JDBC calls. JDBC call recording has to be enabled in the profiling settings.
   • JMS calls
     The displayed hot spots are JMS calls. JMS call recording has to be enabled in the profiling settings.
   • JNDI calls
     The displayed hot spots are JNDI calls. JNDI call recording has to be enabled in the profiling settings.
   • URL invocations
     The displayed hot spots are URL invocations. URL call tree splitting has to be enabled in the profiling settings. URL splitting can be customized in the profiling settings or by registering a custom handler with the profiling API. In the profiling settings you can also specify if all URLs or only URLs which lead to the invocation of an unfiltered class (the default setting) should be displayed.

   Depending on your selection of the aggregation level, the hot spot backtraces can be aggregated into classes or packages. The J2EE-related hot spots themselves do not change for different aggregation levels.

   For the J2EE related hot spot types, please see the help on the Java subsystems tab of the profiling settings for more information on how these calls are recorded.

• If a J2EE-related hot spot type is selected, the recorded data for the call is displayed. For method call hot spots types, 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 inherent time in ms or µs of how much time has been spent in the hot spot together with a bar whose length is proportional to this value. All calls into this method are summed up regardless of the particular call sequence.

  If the method belongs to an unfiltered class, this time does not include calls into other methods. If the method belongs to a filtered class, this time includes calls into other filtered methods.

• the invocation count of the hot spot.

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 entry in the backtrace tree has textual information attached to it which depends on the hot spot view settings.

• a percentage number which is calculated with respect either to the total time or the called method.
• a time measurement in ms or µs of how much time has been contributed to the parent hot spot on this 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.
• an invocation count which shows how often the hot spot has been invoked on this path.

  Note: This is not the number of invocations of 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.

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

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