The metrics you choose to view depend on your application domain, your code, the demands for the application, and the operating environment. Probably you should look at all of the available ones, and at least analyze a few of the topmost entries.
HPjmeter presents all metrics sorted in decreasing order of resources used. This places the largest "resource abusers" right at the top of the screen. Evaluate them, knowing your application and its characteristics. Use your intuition. If you find anything suspicious, take your time to analyze and find the cause.
Depending on the Java platform and the profiling options you used, some of the metrics may not be available. Sometimes it might be worthwhile to run and profile the application on a different platform, if it will give you more or better profiling data.
Under the Guess menu there are two items: Inline Candidates, and Lock Contention. The 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.
For lock contention,
HPjmeter tries to locate methods in which threads are delayed.
HPjmeter does not know whether a method
is synchronized,
or contains a synchronized statement,
so it makes a guess.
It is up to you to check if synchronization exists at that location
in your program and whether the execution of the application is
indeed suffering from serious lock contention at that location.