 |
 |
To take full advantage of HPjmeter functionality,
you can gather profiling data using -Xeprof for performance tuning and -agentlib:hprof for
memory tuning when you run your application.
 |  |  |  |  | NOTE: If you are running the HP JDK/JRE 5.0.04 or later, you can send
a signal to the running JVM to start and stop a profiling data collection
period with zero preparation and no interruption of your
application. See Profiling with Zero Preparation. |  |  |  |  |
Profiling with -Xeprof |  |
To profile an application, use the following command: $ java -Xeprof:options ApplicationClassName |
To profile an applet, use the following command: $ appletviewer -J-Xeprof:options URL |
where options is a list of key[=value] arguments separated by commas. You can also stop the JVM (kill pid) or control the profiling time using the time_on or time_slice options. See the
descriptions in the list of options. The following options are especially useful in
most cases: For CPU time, clock time,
and lock contention metrics with minimal intrusion, use -Xeprof For exact call count information
and non-array object creation profiling, use -Xeprof:inlining=disable
To see the complete list of available options,
use java -Xeprof:help -Xeprof always collects call
graph data with inclusive method times (clock and CPU), method call
count, and lock contention metrics. This option uses tracing with
reduction and collects the data separately for each thread. To see the availability of HPjmeter metrics from -Xeprof data collection, see –Xeprof and –agentlib:hprof Profiling Options and
Their Corresponding Metrics. Table 5-1 Supported -Xeprof options | time_on=integer | Specifies the time in seconds between the
application start and the time when the profile data collection will
start. If no time_on option is present, the data
collection begins at the VM initialization. | | time_on=sigusr1|sigusr2 | Specifies which signal
will cause profiling to begin (profile data collection). Be aware that the application or the VM may already
be using the sigusr signals for their own purposes. Specifying a signal and a timeout at the same time
is possible by repeating the time_on option. Only one of the two signals can be declared to use
as the signal to start profiling. During the application's run, the specified signal
can be delivered to the Java process multiple times.
| | time_slice=integer | Specifies the time in seconds between
the profiling start and the time when profiling will be terminated. When the profiling is terminated, the profile data
is written to a file. The application will continue running. If time_slice is not specified, or
if the application terminates before the specified time elapses, but
the profiling has started, the profile data will be written out after
the termination of the application.
| | time_slice=sigusr1|sigusr2 | Specifies which signal will cause
profiling termination and the profile data output.The signals for profiling start and profiling termination
can be the same. Specifying a signal and a timeout at the same time
is possible by repeating the time_slice option —
termination of profiling occurs when the first qualifying event takes
place. The application will continue running. Only one of the two signals can be declared to use
as the signal to terminate profiling. During the application's run, the signal to terminate
profiling can be delivered to the Java process multiple times. However,
profiling will only be terminated and a result file generated if profiling
is active when the termination signal is delivered.
| | file=filename | The profile data will be written
to the named file. If time_on=sig... has not been specified,
the default is filename.eprof If a signal has been specified to start profiling, several
data files can be created, with names filename_t.eprof, wheret is the time in seconds between the application start
and the profiling start.
| | inlining=disable|enable | The compiler in the HotSpot VM optimizes
Java applications by inlining frequently called methods. Execution
of an inlined method is not reported as a “call” because
the actual call has been eliminated. Instead, the time spent in an
inlined method is attributed to its “caller” The consequences
of inlining for profiling can be characterized as follows:
The obtained profile data does not reflect faithfully
all the calls within the Java code as 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 to disable inlining is to collect the
profile data while running the VM in interpreted mode (-Xint). | | ie=yes|no | Enable/disable
the profiling intrusion estimation.ie=yes, the default value, specifies that the profiler estimates the profiling
intrusion and writes the estimated values to the profile data file. HPjmeter uses
this data to compensate for intrusion, which means that the estimated
intrusion is subtracted from the CPU times before they are presented
to the user. Disabling intrusion estimation slightly reduces the size
of the data files, but will also disable the intrusion compensation
feature. This option has no impact on the actual profiling overhead. |
Profiling with Zero Preparation |  |
Zero preparation profiling is a feature of the
HP JDK/JRE 5.0.04. It is started from the command line by sending
a signal to the JVM to start eprof. Engaging zero preparation profiling
may have a short term impact on application performance as the JVM
adjusts to the demands of performing dynamic measurements. To collect profiling data without interrupting
your application, do the following from the command line: Confirm that a HP JDK/JRE 5.0.04 or later is running
the application that you want to profile, and that no -Xeprof option has been specified. Find the process ID of the running Java application. Start the profiling interval: send a signal to the
JVM by typing: kill -USR2 pid You will see the following message: eprof: starting profiling Let the profiling collection generated by the JVM continue for
the length of time that you think will be meaningful. Stop the profiling interval by sending the same signal
to the JVM: kill -USR2 pid You will see the following message: eprof: terminating profiling writing profile data to ./filename.eprof You can now open the saved file in the HPjmeter console and
view the collected metrics.
 |  |  |  |  | NOTE: For the signal to be captured by the JVM, you
must either be logged in as root, or you must be the user who started
the JVM. |  |  |  |  |
Profiling with -agentlib:hprof |  |
Java 2 introduced a profiling interface, called
JVMPI (Java Virtual Machine Profiler Interface). This interface came
with a sample profiling agent, called hprof. The Java 5.0 release introduced an improved profiling
interface, called JVMTI (Java Virtual Machine Tool Interface), which
replaces JVMPI. The hprof agent is also available with JVMTI. This agent creates profile data files that can
be interpreted after the program terminates. However, note that the
format of the files may be still evolving. Most Java versions based
on JavaSoft implementations are compatible. Currently HPjmeter can
read text and binary files. To run your application with profiling, use the
following command: $ java ... -agentlib:hprof[=options] ApplicationClassName |
To profile an applet, use the following command: $ appletviewer ... -J-agentlib:hprof[=options] URL |
The following options are useful: For performance profiling: cpu=samples,thread=y,depth=10,cutoff=0,format=a If you must have method
call counts for performance profiling: cpu=times,thread=y,cutoff=0,format=a For analyzing object allocations: heap=sites,cpu=samples,thread=y,cutoff=0,format=a For solving memory retention
problems ("memory leaks"): heap=all,thread=y,cutoff=0,format=a,doe=n Then use kill -QUIT pid (on UNIX ) to get the heap dump.
 |  |  |  |  | NOTE: Beginning with HPjmeter version 3.1, you can view binary hprof
files (format=b) in HPjmeter visualizers. |  |  |  |  |
To see the complete list of available options,
use java ... -agentlib:hprof=help To see the availability of HPjmeter metrics from hprof data collection, see –Xeprof and –agentlib:hprof Profiling Options and
Their Corresponding Metrics. For additional information on collecting
heap dump data, see (http://h18012.www1.hp.com/java/support/support_guide.html). Here are the supported -agentlib:hprof options that affect the collection of profile data: Table 5-2 Supported -agentlib:hprof options | heap=dump|sites|all | The heap dump shows all objects remaining in memory at
the time of the dump. The allocation sites show where the objects
were created during the execution of the program. Heap analysis can
be used to locate memory leaks, and the allocation sites can be used
to minimize the memory usage. To solve memory retention
problems, the best practice is to use a signal rather than the application
shutdown to obtain the heap dump. When the application shuts down,
some references go out of scope and the retention
problem may get eliminated just before the heap is dumped. Send the
signal at the moment that you suspect the application is holding references
to no longer needed objects. To keep the heap dump size
down, try to send the signal just after a full garbage collection
(use -verbose:gc to be notified about the garbage
collections). Remember that a heap dump contains all
objects, not just live objects | | cpu=samples|times|old | cpu=samples uses sampling as the collecting
technique, while cpu=times uses tracing with reduction. Typically, the times collected by cpu=samples|times are CPU virtual times. However, HP-UX 11i
versions use real CPU times rather than CPU virtual times unless sampling is used. Some implementations of cpu=times report clock time. HPjmeter tries to figure
out what times actually have been collected, but sometimes does not
do it right. cpu=samples and cpu=times output exclusive times. Collecting heap data can be very intrusive, so we
recommend that you measure the method times and heap usage at different
times. However, it may make sense to specify heap=sites and cpu=samples|times for the same run when you
want to locate the allocation sites in the call graph.
| | thread=y|n | Controls
whether the stack traces collected during program execution will be
associated with an individual thread. By default, no thread identification information
is stored (thread=n). We suggest that you always specify thread=y. With the thread identification in the profile file, HPjmeter can
calculate the thread profile data for the entire application.
| | depth=size | Controls the depth of the stack trace for
each stack trace taken. Increasing this value will make the profile data file
larger, but it enables HPjmeter to better estimate inclusive method
times and generate more complete call graphs. If you measure application performance by sampling,
the default value of 4 is too small for most applications; use values
between 6 and 12.
| | cutoff=value | This is the cut-off value for printing
the list of methods with their exclusive times or object allocation
sites. Decreasing this value will make the profile data file
slightly larger, but it enables HPjmeter to produce more complete
call graphs or heap metrics. Use a value of 0 for all applications.
| | format=a ,format=b | HPjmeter displays both ASCII and binary
format of the profile file.  |  |  |  |  | NOTE: Note that hprof does not list method arguments.
In effect, all overloaded methods are represented as just one method. |  |  |  |  |
|
Naming Profile Data Files |  |
The following table shows the file name formats
used by default when naming files containing profiling data. You may
want to follow this convention when naming profile data files, but
it is not required.
Table 5-3 Default File Name Suffixes for Profile Data | Profiling Option | File Name Suffix |
|---|
| -Xeprof | .eprof | | -agentlib:hprof | .hprof.txt |
For other file suffixes recognized by HPjmeter,
see Naming Monitoring Data Files
|
 |
|