Reading Profiling Histograms

There are two kinds of histograms available:

Threads Histogram. A presentation of all threads created by the application.
The horizontal bars represent the lifetime of the threads, with respect to the lifetime of the whole application.
Thread Groups Histogram. A presentation of all thread groups created by the application.
The horizontal bars represent the lifetime of the thread groups, with respect to the lifetime of the whole application. The lifetime of the thread group is defined as the time span between the creation of the first thread belonging to the group and the death of the last thread belonging to the group.

Not all profile data files contain information about the times when the threads are created and terminated. If such information is unavailable, the metric header will contain “times not to scale)” meaning that only the order of the threads creation and termination events are shown.

If the profile data contains adequate information, the bars are displayed using colors describing thread states; otherwise the bars are grey. There are a few coloring schemas used by HPjmeter, depending on the profiling option and platform used. You can double click on the thread (or thread group) bar to pop up the thread spectrum.

The next section presents a detailed description of the reported thread states.

Key to Thread States Reported by `-Xeprof`

The image in the next figure presents a sample thread spectrum. A thread spectrum is obtained when you double-click the thread name in a threads histogram.

Figure 5-1 Pie Chart Showing Percent Time Spent in Various States for a Given Thread

The values are shown as the percentage of the total thread lifetime (i.e., the clock time elapsed between the thread creation and the thread completion).

Table 5-5 Key to Default Color Representation of Thread States in Histograms

Lock Contention. Time wasted trying to acquire a Java lock while it was acquired by another thread. More precisely, it is the summary time measured from the moment the thread requests a Java lock until the lock is actually granted.

CPU. Time spent running on any of the computer's processors. This includes Java code, the native code (if any), and the time spent in the virtual machine by this thread. If there's no Profiler Overhead state listed in the legend, the CPU time consumed by the profiler is also included.

Profile Overhead. Estimated time used by the profiler to collect the profile data. In most cases, the profiler overhead is proportional to the CPU time spent in Java, but also depends on the frequency of Java method calls. This state will not be shown if the profile data file does not contain the profiler overhead data.

I/O. Time spent while executing a synchronous input or output operation called directly from Java code, using one of the standard library classes. This includes all kind of I/O, in particular the network (socket) operations.

Sleeping. Time spent while the thread was suspended by the java.lang.Thread.sleep method.

Waiting. Time spent while the thread was suspended by the java.lang.Object.wait method.

Native Idle. Non-CPU-consuming time spent while the thread was in a non-Java code (i.e., using JNI). The thread could be sleeping, running a non-Java I/O operation, waiting for a child process or being suspended by the OS for a similar reason. HPjmeter is not able to identify the exact state of the thread in such circumstances, since the native code remains unprofiled, and the amount of time spent in this state is always estimated.

Garbage Collection. Time spent while the thread was suspended by the virtual machine because the (non-concurrent) garbage collector needed to run. If there are many running threads, and the garbage collection pauses are short, this time may be larger than the actual time spent in the garbage collector. This is because all threads must be suspended before the garbage collection may start.

Unknown. The thread state could not be determined. If the lifetime of the thread was extremely short, HPjmeter may not be able to show any other states but Unknown.

Starvation. The time wasted while the thread was theoretically able to run (was in the “runnable” state), but actually did not run. The reasons for starvation can be within the Java VM or within the operating system. Most typical situations resulting in starvation are listed below:

A traditional, non-concurrent garbage collector was running (only if the specific Garbage Collection state is not listed) at that time.
There were more threads ready to run (within all applications present in the system) than the number of available CPUs.
The operating system (for example, virtual memory) overhead or failure to schedule the threads “fairly”
Virtual machine operations, such as class loading, or method de-optimization.

Interpreting the Histogram Presentation

You can assess the scalability of the application from the spectrum of a typical “working” thread from your application.

A large amount of lock contention (red) indicates that scalability will be a problem. You need to change the inter-thread communication mechanism to reduce the lock contention.
A large amount of waiting (green) may indicate that the load on the application can be increased. This is because in a typical server application the threads use the Java wait method to wait for the data to process.

A large amount of starvation (white) indicates that the ratio of the active threads to the number of CPUs is too large. You can probably decrease the number of threads without negatively affecting the performance or throughput.




	TIP: To best view the relative amount of starvation for a particular thread, highlight the thread by clicking on it once, or double-click to reveal the thread pie chart for that thread. Starvation is represented by the “empty” slice of the pie.




	NOTE: Be careful when analyzing the spectrum of a thread group. A thread group may contain several threads with completely different roles within the application. Mixing them up and analyzing just the summary may make little sense. User-defined thread groups that contain only carefully selected threads (usually sharing the same code) are well suited for spectrum analysis.

Reading Profiling Histograms

Technical documentation

» Table of Contents

» Glossary

» Index

Key to Thread States Reported by `-Xeprof`

Interpreting the Histogram Presentation

Reading Profiling Histograms

Technical documentation

» Table of Contents

» Glossary

» Index

Key to Thread States Reported by -Xeprof

Interpreting the Histogram Presentation

Key to Thread States Reported by `-Xeprof`