HPjmeter uses heuristic algorithms to help you
find 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 find 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 which 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 the number of bytes that would
be reclaimed. It is up to you to check if the presented objects are
still needed by the application, and how the critical references should
be removed.
Printable version
