 |
What are filter sets?
Data collected from classes defined in packages and classes matching a
filter set for exclusive filters or failing to match the inclusive filters,
are consolidated for the
CPU profiling views,
the allocation call tree,
the allocation hot spots,
the heap walker allocation view
and the call stack information in the
monitor usage views
and are shown without further detail. Due to the considerable depth and complexity
of external class libraries, an unfiltered view of invocation and allocations trees
as well as hot spot lists is often unmanageable and would prevent access to the focal
points of your application. The more unfiltered classes you have, the greater the
CPU profiling overhead will get.
From the point of view of an unfiltered class, filter sets work in both directions:
-
upward filtering
When calling a method in an unfiltered class through methods of a number of filtered
classes, upward filtering consolidates the path through which an unfiltered method
is called into a single step. This is of utmost importance when profiling servlets, JSPs
or Enterprise Java Beans in an application server, where the entry point of
your class might be buried several hundred methods deep in the application server's
framework. Similarly, for GUI applications, the AWT call sequence is container based
which makes it next to impossible to find callbacks like
MyAction.actionPerformed or MyComponent.paint
without upward filtering of the java.awt.* and
javax.swing.* classes.
-
downward filtering
When using external class libraries, most of the time the inner details are not
important in performance analysis and optimizations, as they are delivered in
binary form and are subject to a vendor controlled update cycle. Downward filtering
consolidates a call into a filtered class into a single opaque call. This greatly
reduces unwanted detail and directs the focus to the most important parts
of your application.
|
