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
—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
•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
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.,
78 Profiling Applications
