Profiling with -Xeprof

[Back]

The HotSpot virtual machine for HP-UX SDK for Java 2 platform, release 1.2.2.05 or greater, or 1.3 beta2 or greater, supports -Xeprof. To profile your application use the following command:

java -Xeprof:<options> ApplicationClassName

To profile your applet, use:

appletviewer -J-Xeprof:<options> URL

where <options> is a list of <key>[=<value>] arguments separated by commas.

After the profiled applet or application normally terminates execution, the Java Virtual Machine writes the profile data to a file in the current directory.

We have found the following options useful in most cases:

1. For CPU time metrics with minimal intrusion:
   -Xeprof      or
   -Xeprof:ie=no
2. Exact call count information and object creation profiling:
   -Xeprof:inlining=disable      or
   -Xint -Xeprof

To see the complete list of available options, use

java -Xeprof:help

Here are the supported -Xeprof options:

• file=<filename>
  The profile data will be written to the named file. The default is java.eprof.

• times=quick|thorough
  Collect call graph with inclusive method clock and CPU times and method call count. This option uses tracing with reduction and collects the data separately for each thread, throughout the whole execution time of the program.
  The quick value instructs the profiler to use the hardware Interval Timer register for time measurement. This value results in faster profiling runs, but in very rare circumstances can produce inaccurate data. This is the default for PA RISC 2.0 based machines. If you ever suspect that the profile data generated using the quick value is incorrect then redo the run to see whether the results can be replicated.
  The thorough value is the opposite of quick, disabling the use of the Interval Timer. The profiling runs will be longer, but will provide timing data with the same quality as the system calls used to measure the time. However, the profiling intrusion and overhead also increase. This is the default for PA RISC 1.1 based machines.

• inlining=disable|enable
  The compiler in the HotSpot VM optimizes Java applications by inlining frequently called methods. Execution of inlined methods is not reported as "calls", since the actual calls have been eliminated. Instead, the time spent in an inlined method is attributed to its "caller". The consequences of inlining for the profiling can be characterized as follows:
  • The obtained profile data does not reflect faithfully all the calls within the Java code as it has been written by the programmer, but rather as it is actually executed by the VM. For most performance analysis cases, this is a desired feature.
  • As the calls within the Java application are eliminated, the corresponding calls to the profiler are eliminated too, resulting in lower profiling overhead.
  • The count of created objects cannot be reliably estimated from the call graph in the presence of inlining, because the calls to the constructors may have been inlined.
  The default value for this option is enable. Another way of disabling inlining is to collect the profile data while runnnig the VM in interpreted mode (-Xint).

• ie=yes|no
  Enable/disable the profiling intrusion estimation.
  ie=yes, the default value, specifies that the profiler estimate the profiling intrusion and write the estimated values to the profile data file. A future version of HPjmeter will be able to present the timing data as:
  • raw, meaning the data as collected,
  or
  • compensated, meaning with the estimated intrusion subtracted.
  Disabling intrusion estimation reduces the size of the data files, but will also disable the intrusion compensation feature. This option has no impact on the profiling overhead.

[Back]