HPjmeter 4.3 User's Guide

Searching the Trees
The search functions work in trees basically the same way they work for other metrics, but there
are a few special considerations for searching call graph trees.
• Occasionally, not all nodes found in a search will be accessible (visible). You'll be notified
about such situations in the status bar at the bottom of the window. A node will be inaccessible:
◦ if no path exists from the root to the node using only arcs with values above the current
cut-off value (see Tree Pruning (page 91)), or
◦ if no path exists from the root to the node at all. This can happen when you change the
roots of the tree (see Using Sub-Trees (page 91)).
• After a search, all found accessible nodes can be made visible by expanding the tree to show
the nodes. Occasionally, if the search yielded many results, this creates a tree that is too large
to be conveniently navigated, even if you use the Find Next Selected command.
You may then want to use Tree→Collapse All to fold down the tree alternately with Find Next
Selected. This will expand the tree to show only the current node, rather than all selected
nodes.
• The trees showing different metrics may expand differently, even if the same node is
found.
◦
◦ For trees with time, the tree expands along the path from the root that shows the maximum
time (more precisely, the path that maximizes the minimum arc time existing in the path).
◦ The tree with call counts expands showing the callers that made the most calls to the
found node and, recursively, its selected caller.
◦ Finally, the object reference tree expands showing the shortest path from the root to the
found node.
Using Heuristics to Locate Possible Hot Spots
HPjmeter uses heuristic algorithms to help you locate some of the application's hot spots. Remember
that these are only hints - nothing can replace your in-depth analysis of the application.
You can locate the heuristic displays in the Estimate menu. They include: Inline Candidates,
Exceptions Thrown, and Memory Leaks.
Candidates for inlining are those methods that were called many times and seem to have relatively
short and simple code. HPjmeter cannot see the source or object code for the methods, so it makes
a guess. It is up to you to check if the inlining makes sense and will actually improve the
performance.
The profile data does not contain any information about the thrown exceptions. However, HPjmeter
assumes than whenever an exception object was created, the application did so with the intention
of throwing this exception.
Although the profile data does not contain information about created exception objects either,
HPjmeter looks for invocations of methods that look like exception initializers. It is up to you to
check if the found methods really create exception objects, and that the created exception objects
are actually thrown.
The term “memory leaks” is not technically correct, for Java has automatic memory management.
By this term we mean the objects that are held unintentionally in memory because other objects
keep references to them. This is usually caused by careless programming.
A heuristic approach to detecting “memory leaks” is difficult, because it is next to impossible to
guess a programmer's intentions. HPjmeter tries to locate objects with the following property: the
object is kept “alive” by a single reference, and removing this reference would entail freeing (i.e.,
garbage-collecting) a substantial amount of bytes. The list of such objects is presented along with
92 Profiling Applications