Tuning JRockit JVM

Analyzing and Improving Application Performance

This section describes how you can improve application performance by uncovering "hotpaths," or bottlenecks in processing, and either working around those hotpaths or eliminating them completely.

Analyzing and improving your application is a four-step process:

Alternate Methods of Analysis

The method presented here differs somewhat from the normal use of Java profilers you might have encountered. The reason for the difference is to provide a more accurate picture of what the application is doing. All kinds of profiling are intrusive, and thus change the behaviour of the application you are observing. This causes you to look at data that is not really representative of the application's behaviour.

One way to minimize the impact of profiling is to collect less data (use sampling instead of callgraph analysis), but then this data may not tell you enough to find problems. Therefore, you should can then combine the exact data with information taken during a more instrusive run. This will give you a better picture of what the application is doing. To do this, follow these steps:

First collect sampling data to find out where in the application we are spending too much time.
Next, combine this information with callgraph data to find out how we came to that location.

Note: While this method provides a good way to find out accurate profiles of your application, a more thorough analysis might still be needed.

Step 1: Find the Hotpaths

Finding Hotpaths is a two-step process:

Find the Bottleneck Methods

As their name implies, bottleneck methods are those methods that require excessive time and processing resources to execute. These bottlenecks can greatly affect system performance and need to be identified. To find bottleneck methods, do the following:

Use the Intel VTune profiling tool with JRockit to analyze performance. VTune uses features on the processor to gather information about which code the processor is currently executing. This is done after a fixed number of either clock ticks (wall clock time) or after a fixed number of instructions retired (actual instructions executed in the processor). VTune then uses this data together with symbol information from Java code to present information about where the application spends most of its time.

Note: You should use VTune only in the "sampling" mode, not the "call-graph" mode.

For more information on how to use VTune, please refer to the appropriate vendor documentation at:

http://www.intel.com/software/products/vtune/

Use the Java Virtual Machine Profiling Interface (JVMPI). JVMPI is a two-way function call interface between the Java virtual machine and an in-process profiler agent. On one hand, the VM notifies the profiler agent of various events, corresponding to, for example, heap allocation, thread start, and so on. Concurrently, the profiler agent issues controls and requests for more information through the JVMPI.

From inside VTune, start this interface by setting the -Xrunjavaperf option:

-Xrunjavaperf

To reduce the profiler overhead, use the -Xjvmpi option:

-Xjvmpi:allocs=off,monitors=off,entryexit=off.

For a list of recommended -Xjvmpi settings, please refer to Table 4.1 in Profiling and Debugging with BEA JRockit

Cluster the Bottleneck Methods Together into Hotpaths

To cluster the bottleneck methods together into hotpaths, do the following:

Run your favorite profiler, such as OptimizeIt or JProbe.

Review the call-traces produced by it.

Combine these call-traces with the bottleneck methods discovered in Find the Bottleneck Methods, above. This combination of bottleneck methods and call-traces will identify your hotpaths.

Step 2: Prioritize the Hotpaths

To prioritize the hotpaths, do the following:

Sum all of the time spent in each hotpath to compute a total hotpath time.

Remove all individual hotpaths that represent less than a prescribed percentage of the total hotpath time; for example, a good initial percentage might be 5%. This is the hotpath threshold.

Ignore any hotpath that falls below the hotpath threshold. Any hotpath time above the threshold should be optimized.

Step 3: Fix the Hotpath

You need to rely on your own judgement and knowledge of the application to fix hotpaths. Once you've identified and prioritized the hotpaths, look at each one and decide if the code is really needed or if you can make some simple changes, perhaps to the coding or to an algorithm, to avoid it or eliminate it as a hotpath. If you determine that you cannot remove the hotpath, what can you do to make it faster? Rewrite the code so it's more efficient?

Also, are you sure that anything you do will actually improve performance. Any optimization you attempt should at least double performance of the hotpath or your efforts might be wasted. For example, a performance increase of 5% or a hotpath that takes only 5% of the time is only going to improve performance .25%.

Step 4: Repeat Steps 1-3

Continue repeating the optimization process until you attain the desired system performance.