Select the method call recording type for CPU profiling as one of
When dynamic instrumentation is enabled, JProfiler modifies filtered 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.
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 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.
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.