Adjusting call tree collection options

On this tab of the profiling settings dialog, you can adjust the call tree collection method and the filter sets which are active for the session being edited. These settings influence the detail level and the execution speed of the profiled application.

Call tree collection method Select the call tree collection method for CPU profiling as one of
- dynamic instrumentation
  With dynamic instrumentation selected, JProfiler modifies the bytecode of all unfiltered classes on the fly as they are loaded by the JVM to include hooks for CPU profiling. Java core classes (java.*) cannot be profiled this way and are filtered automatically. Dynamic instrumentation is considerably faster than full instrumentation.
- sampling
  When sampling is enabled JProfiler inspects the call stacks of all threads periodically. The period between to measurements for each thread is booked to the greatest common denominator of the two class stacks. Sampling is fast even without any filters, but accuracy is low and no invocation count is displayed.
  If sampling is enabled, the sampling frequency can be adjusted with a slider. The possible range is 1 - 20 ms. A lower sampling frequency incurs a higher CPU overhead when profiling.
  
  record exact allocations is available only in combination with sampling. If this option is not selected, allocations will be reported according to the call traces recorded by the sampling procedure. This may lead to incorrect allocation spots. When record exact allocations is enabled, allocation spots are determined with an alternative method. However, there is a considerable increase in CPU and memory overhead if this option is selected.
- full instrumentation
  With full instrumentation selected, all method calls are traced by JProfiler. This allows for profiling Java core classes (java.*), but is considerably slower than dynamic instrumentation, especially for 1.4 JVMs.
  subclassmethods is available only in combination with full instrumentation and shows the concrete classes on which the methods are invoked rather than the classes where the methods are implemented.

The active filter sets panel allow you to choose whether the specified filters are to be
- exclusive
  
  In the table below, you choose the filter sets which are active for the session being edited. These filters specify the end points for CPU profiling. In packages or classes matching one of the filter sets, no further calls into other filtered classes will be resolved. If such a call sequence should reach an unfiltered class again, it will be displayed with an upward filter bag in the invocation view. In other words, methods in filtered classes are treated as "opaque methods".
  
  Filter sets can be edited on the "Filter sets" tab of JProfiler's general settings which are accessible by clicking the [General settings] button on the bottom of the dialog or invoking the context menu on the filter sets table.
  
  Click on the checkboxes in the "Apply" column to toggle filter sets. And select or deselect all filter sets at once with the buttons [Select all] and [Deselect all] or the corresponding entries in the context menu.
- inclusive
  
  Enter comma separated filters for packages and classes in the text box. Only calls into matching packages and classes will be resolved for CPU profiling.
  
  For example, if you specify com.mycorp., com.othercorp. as the inclusive filters, a call into com.mycorp.MyClass.myMethod() and all calls it makes will be measured and displayed. All calls from com.mycorp.MyClass.myMethod() that don't belong to the packages com.mycorp or com.othercorp are treated as opaque and will be displayed as endpoints in the invocation view. If such a call sequence should reach an class included in the inclusive filters again, it will be displayed with an upward filter bag.