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 extremely rare circumstances can produce bad data. This is the default for PA-RISC-2.0 and IA-64 based machines, and for SDK 1.4.x for PA-RISC 1.1 based machines. If you ever suspect that the profile data generated using the quick value is incorrect, re-run to see whether the results can be replicated.

The thorough/strict value is the opposite of quick, and disables the use of the Interval Timer. The profiling runs will be longer, and will provide timing data with the same (relatively poor) quality as the system calls used to measure the time. The profiling intrusion and overhead will also increase. This is the default for PA-RISC-1.1 based machines for SDK versions through 1.3.x.

Do not specify this option unless you know what you are doing. The collected profile data will almost certainly have less accuracy than when collected using the quick value.

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.

Specifies which signal will cause profiling to begin (profile data collection). Please be aware that the application or the VM may already be using the sigusr signals for their own purposes; please check the documentation. Specifying a signal and a timeout (see above) 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.

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.

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.

The profile data will be written to the named file. For SDK 1.2.x and 1.3.x the default is java.eprof. For SDK 1.4.x and later, if time_on=sig... has not been specified, the default is java<pid>.eprof, where <pid> is the integer number representing the process ID of the Java™ VM process. If a signal has been specified to start profiling, several data files can be created, with names java<pid>_<t>.eprof, where <t> is the time in seconds between the application start and the profiling start.

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 default value for this option is enable. Another way of disabling inlining is to collect the profile data while running the VM in interpreted mode (-Xint), although this is usually much slower.

The consequences of inlining for the profiling are 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.

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.