HotSpot and 1.3 -Xprof Profile Output

- 33 - amounts even within one application run. But it normally indicates major bottlenecks, although sometimes a little extra work is necessary to sort out multiple identical method-name references. Using the alternative cpu=times mode, the profile output gives a different view of application execution. In this mode, the method times are measured from method entry to method exit, including the time spent in all other calls the method makes. This profile of an application gives a tree-like view of where the application is spending its time. Some developers are more comfortable with this mode for profiling the application, but I find that it does not directly identify bottlenecks in the code.

2.3.3 HotSpot and 1.3 -Xprof Profile Output

HotSpot does not support the standard Java 2 profiler detailed in the previous section; it supports a separate profiler using the -Xprof option. JDK 1.3 supports the HotSpot profiler as well as the standard Java 2 profiler detailed in the previous section. The HotSpot profiler has no further options available to modify its behavior; it works by sampling the stack every 10 milliseconds. The output, printed to standard out, consists of a number of sections. Each section lists entries in order of the number of ticks counted while the method was executed. The various sections include methods executing in interpreted and compiled modes, and VM runtime costs as well: Section 1 One-line header, for example: Flat profile of 7.55 secs 736 total ticks: main Section 2 A list of methods sampled while running in interpreted mode. The methods are listed in order of the total number of ticks counted while the method was at the top of the stack. For example: Interpreted + native Method 3.7 23 + 4 tuning.profile.ProfileTest.main 2.4 4 + 14 java.lang.FloatingDecimal.dtoa 1.4 3 + 7 java.lang.FDBigInt.init Section 3 A list of methods sampled while running in compiled mode. The methods are listed in order of the total number of ticks counted while the method was at the top of the stack. For example: Compiled + native Method 13.5 99 + 0 java.lang.FDBigInt.quoRemIteration 9.8 71 + 1 java.lang.FDBigInt.mult 9.1 67 + 0 java.lang.FDBigInt.add Section 4 A list of external non-Java method stubs, defined using the native keyword. Listed in order of the total number of ticks counted while the method was at the top of the stack. For example: Stub + native Method 2.6 11 + 8 java.lang.Double.doubleToLongBits - 34 - 0.7 2 + 3 java.lang.StrictMath.floor 0.5 3 + 1 java.lang.Double.longBitsToDouble Section 5 A list of internal VM function calls. Listed in order of the total number of ticks counted while the method was at the top of the stack. Not tuneable. For example: Runtime stub + native Method 0.1 1 + 0 interpreter_entries 0.1 1 + 0 Total runtime stubs Section 6 Other miscellaneous entries not included in the previous sections: Thread-local ticks: 1.4 10 classloader 0.1 1 Interpreter 11.7 86 Unknown code Section 7 A global summary of ticks recorded. This includes ticks from the garbage collector, thread- locking overheads, and other miscellaneous entries: Global summary of 7.57 seconds: 100.0 754 Received ticks 1.9 14 Received GC ticks 0.3 2 Other VM operations The entries at the top of Section 3 are the methods that probably need tuning. Any method listed near the top of Section 2 should have been targeted by the HotSpot optimizer and may be listed lower down in Section 3. Such methods may still need to be optimized, but it is more likely that the methods at the top of Section 3 are what need optimizing. The ticks for the two sections are the same, so you can easily compare the time taken up by the top methods in the different sections and decide which to target.

2.3.4 JDK 1.1.x -prof and Java 2 cpu=old Profile Output