The Influence of Method Call Recording Filters on Hotspots | ![]() ![]() |
run()
method of the AWT event dispatch thread
would be the biggest hotspots in most cases. Such a definition of a hotspot would
not be very useful.
As the other extreme one could use the unfiltered inherent time of the execution of a method for the ranking of hotspots. The unfiltered inherent time is the total time minus the time spent in all other method calls. This would not be very useful either, since the biggest hotspots will most likely always be core methods in the JRE, like string manipulation, I/O classes or core drawing routines in obscure implementation classes of the AWT.
As the above considerations make clear, the definition of a hotspot is not trivial and must be carefully considered.
Only with filters is it possible to come up with a useful definition of a hotspot. Usually, your method call recording filters will be set up in such a way that all library classes and framework classes will be filtered out. In the following discussion, we're going to assume that this is the case.
In order to be useful a hot spot must be
Which one of these viewpoints is more helpful depends on the actual situation. JProfiler's hotspot view offers both modes with the combo box in the top-right corner. The allocation hotspots views also offer this mechanism of adjusting the definition of a hotspot.
Let us profile the animated Bezier curve demo that comes with JProfiler. We will try out
different filter settings and check how they influence the list of hotspots.
In this case we consider the BezierAnim
class to be "our" code, while the
JRE classes are library classes.
We start by using the "Maximum detail" profiling setting template. Here, full instrumentation is used and no filters are applied.
As we can see, most of the hotspots are implementation classes in sun.*
implementation packages. Theses classes are never called by our code. While we could
open the backtraces and see how they have been invoked, this is cumbersome and produces
no insight into any performance problems that we might be able to solve.
In the next step, we restrict our filters so that only BezierAnim
and the java.awt.*
packages are unfiltered. This viewpoint is a little strange,
somewhat as if the java.awt.*
belonged to our code, too. But we want to show
how the inclusion of filters changes the hotspots, so we take this middle step.
We do this by customizing the "Maximum detail" profiling setting template and entering
BezierAnim, java.awt.*
as inclusive filters.
Again, there are a lot of filtered classes in the list of hotspot, but while the first two hotspots have stayed the same, the list below them is completely different to the unfiltered case.
Since we now have filters, we can change the viewpoint further by choosing the "add times to calling class" option in the top-right combo box labeled "Filtered classes".
Now, the list has changed completely and we only see unfiltered classes.
Finally, we profile with the "All features enables, high CPU profiling detail" option, where all classes in the JRE are filtered.
Any of the methods that appear in the list of hotspots have been called from our code. This is great for finding performance bottlenecks but sometimes we only want to see our own methods. Again we choose the "add times to calling class" option in the top-right combo box labeled "Filtered classes".
All but one method are directly from the BezierAnim
class. The
java.awt.EventDispatchThread.run()
method is an upward filter bag. It contains
framework calls that are executed before any method in our own code is called.
This is why it cannot be included into any of our methods.
From the above example you can see how important the filter sets and the definition of a hotspot are for the actual results in the hotspot view. The same considerations apply to the allocation hotspot view.
![]() ![]() |