The following options are available:
- Enable method call recording
When you record CPU data or allocations, JProfiler collects information about the call tree.
You might want to record allocations without the overhead of recording the allocation call stacks:
If you don't need the allocation view
in the heap walker,
the allocation call tree
and the stack trace information in the
monitor usage views,
you can switch off method call recording. This will speed up profiling considerably
and reduce memory usage.
- Method call recording type
Select the method call recording type for CPU profiling as one of
- Dynamic instrumentation
When dynamic instrumentation is enabled, JProfiler modifies profiled classes
on the fly as they are loaded by the JVM to include profiling hooks. Accuracy of non-timing
related stack information (like allocation information) is high, invocation counts are available and
Java EE payloads can be annotated in the call tree, but calls from Java core classes are not resolved.
The overhead and timing accuracy varies depending on what classes are instrumented.
Java core classes
java.*) cannot be profiled this way
and are filtered automatically.
For some native call mapping libraries like JNA, instrumenting native methods is a problem.
If you experience problems, you can switch off the instrumentation of native methods.
When sampling is enabled, JProfiler inspects the call stacks of all
threads periodically. Sampling has extremely low overhead
even without any filters. Accuracy of non-timing related stack information (like allocation
information) is low and invocation counts are not available. Only methods that take longer
than the sampling period or methods called frequently are captured by sampling.
Sampling is ideally suited for use without any method call filters. To temporarily switch off
all filters, you can use the Disable all filters for sampling setting
instead of deleting all filters in your configuration. In that way you can create a profiling
settings template that ignores your filter configuration and alternate between using filters and
using no filters at all.
If sampling is enabled, the sampling frequency can be adjusted. The default value is 5 ms.
A lower sampling frequency incurs a slightly higher CPU overhead when profiling.
Note: allocations will be reported according to the call traces
recorded by the sampling procedure. This may lead to incorrect allocation spots.
- Request tracking
Request tracking can be started and stopped
for selected tracking types in the JProfiler GUI without changing the profiling settings.
The Enable request tracking setting on this tab allows you to completely disable
request tracking for a session which will result in less instrumentation in the profiled JVM.
- Line numbers
By default, JProfiler does not resolve line numbers in call trees. If you enable
show line numbers for sampling and dynamic instrumentation,
line numbers will be recorded and shown.
If the aggregation level is set to "methods" and a method calls another method multiple
times in different lines of code,
line number resolution will show these invocations as separate method nodes
in the call tree and the
allocation call tree.
Backtraces in the hot spots views will also show line numbers.
Note that a line number can only be shown if the call to a method originates in an unfiltered class.