Filters for Method Call Recording - How They Work and How They Are Configured

     


1. Introduction

Method call recording filters determine the detail level that JProfiler uses when recording call sequences in the profiled application. Filtering helps to eliminate clutter and decrease the profiling overhead for the profiled application. Also see the article on profiling settings for a discussion of profiling settings in general.

Since the internal data storage of CPU data in JProfiler is similar to the invocation tree, method call recording filters are most easily explained while looking at the call tree view. As an example, we profile the "Animated Bezier Curve" demo session that comes with JProfiler. When talking about filters, it is important to define the distinction between your code and framework or library code. Your code should be unfiltered, framework or library code should be filtered. In our example, the BezierAnim class is code written by you and the JRE is library code.

2. What are method call recording filters?

The call tree shows call sequences. Each node and each leaf of the call tree corresponds to a certain call stack that has existed one or multiple times while CPU recording was switched on. You will notice that there are different icons for nodes in the tree. Among other things, these icons serve to highlight if classes are filtered or not.

The methods of a filtered class (alternatively the class or containing package itself, depending on the aggregation level) are endpoints in the call tree, i.e. their internal call structure will not be displayed. Also, any methods in other filtered classes that are called subsequently, are not resolved. If, at any later point in the call sequence, the method of an unfiltered class is called, it will be displayed normally. In that case, the call tree shows the filtered parent method with a  special icon that indicates that it is from a filtered class and that there may be other method calls in between. The inherent time of those missing method is added to the time of the filtered parent method. In JProfiler's terminology, this is called an "upward filter bag".

3. Example with and without filters

The image below illustrates the different node types for a profiling run of the BezierAnim class:

In the above call tree, the java.* package is filtered, so only the first method in the the AWT event dispatch thread is shown. However, the AWT is a complex system and the java.awt.EventDispatchThread.run() does not call BezierAnim.paint() directly. If we switch to full instrumentation and disable all filters, the call tree looks like this:

Now, the entry method into your code - BezierAnim.paint() - is substantially more difficult to find. In cases where events are propagated through a complex container hierarchy, the call tree can become many hundreds of levels deep and it becomes next to impossible to interpret the data. In addition, calls like java.awt.Graphics2D.setPaint() show their internal structure and implementation classes. As a Java programmer who is not working on the JRE itself, you probably do not know or care that the implementation class is actually sun.java2d.SunGraphics2D. Also, the internal call structure is most likely not relevant for you, since you have no control over the implementation. It just distracts from the main goal: how to improve the performance of your code.

Not only is it easier to interpret a call tree that has proper method call recording filters, but also the profiling overhead of the profiled application is much lower. Recording the entire call tree without filters uses a lot of memory and measuring each call takes a lot of time. Both these considerations especially apply to application servers, where the surrounding framework is often extremely complex and the proportion of executed framework code to your own code might be very big.

4. Configuring method call recording filters

Method call recording filters are part of the profiling settings of a session. Please see the article on profiling settings for an explanation on how to change the profiling settings for a session. While method call recording filters can be changed during a running session, the change will only be effective when the session is restarted.

There are two alternative ways in JProfiler to specify the filtered classes:

5. View filters

In addition to the method call recording filters, there is a view filters control at the bottom of all views that display call trees. View filters are similar to inclusive filters and can be changed during a session. However, they can only reduce the recorded information by taking out classes that do not correspond to the selected view filter.

In the call tree, they have a similar behavior like the call tree collection filters. In the hot spot views, they simply hide all classes that do not correspond to the filter selection. This is very different from method call recording filters, where the hot spots themselves change with different filter settings.