IBM User Guide for Java V7 on Windows > Troubleshooting and support > Using diagnostic tools > Using the HPROF Profiler
Explanation of the HPROF output file
The first section of the file contains general header information such as an explanation of the options, copyright, and disclaimers. A summary of each thread follows.
You can see the output after using HPROF with a simple program, shown as follows. This test program creates and runs two threads for a short time. From the output, you can see that the two threads called apples and then oranges were created after the system-generated main thread. Both threads end before the main thread. For each thread its address, identifier, name, and thread group name are displayed. You can see the order in which threads start and finish.
THREAD START (obj=11199050, id = 1, name="Signal dispatcher", group="system") THREAD START (obj=111a2120, id = 2, name="Reference Handler", group="system") THREAD START (obj=111ad910, id = 3, name="Finalizer", group="system") THREAD START (obj=8b87a0, id = 4, name="main", group="main") THREAD END (id = 4) THREAD START (obj=11262d18, id = 5, name="Thread-0", group="main") THREAD START (obj=112e9250, id = 6, name="apples", group="main") THREAD START (obj=112e9998, id = 7, name="oranges", group="main") THREAD END (id = 6) THREAD END (id = 7) THREAD END (id = 5)The trace output section contains regular stack trace information. The depth of each trace can be set and each trace has a unique ID:
TRACE 5: java/util/Locale.toLowerCase(Locale.java:1188) java/util/Locale.convertOldISOCodes(Locale.java:1226) java/util/Locale.<init>(Locale.java:273) java/util/Locale.<clinit>(Locale.java:200)A trace contains a number of frames, and each frame contains the class name, method name, file name, and line number. In the previous example, you can see that line number 1188 of Locale.java (which is in the toLowerCase method) has been called from the convertOldISOCodes() function in the same class. These traces are useful in following the execution path of your program. If you set the monitor option, a monitor dump is produced that looks like this example:
MONITOR DUMP BEGIN THREAD 8, trace 1, status: R THREAD 4, trace 5, status: CW THREAD 2, trace 6, status: CW THREAD 1, trace 1, status: R MONITOR java/lang/ref/Reference$Lock(811bd50) unowned waiting to be notified: thread 2 MONITOR java/lang/ref/ReferenceQueue$Lock(8134710) unowned waiting to be notified: thread 4 RAW MONITOR "_hprof_dump_lock"(0x806d7d0) owner: thread 8, entry count: 1 RAW MONITOR "Monitor Cache lock"(0x8058c50) owner: thread 8, entry count: 1 RAW MONITOR "Monitor Registry lock"(0x8058d10) owner: thread 8, entry count: 1 RAW MONITOR "Thread queue lock"(0x8058bc8) owner: thread 8, entry count: 1 MONITOR DUMP END MONITOR TIME BEGIN (total = 0 ms) Thu Aug 29 16:41:59 2002 MONITOR TIME ENDThe first part of the monitor dump contains a list of threads, including the trace entry that identifies the code the thread executed. There is also a thread status for each thread where:
- R — Runnable (The thread is able to run when given the chance)
- S — Suspended (The thread has been suspended by another thread)
- CW — Condition Wait (The thread is waiting)
- MW — Monitor Wait (The monitor is waiting)
Next is a list of monitors along with their owners and an indication of whether there are any threads waiting on them.
The Heapdump is the next section. This information contains a list of the different areas of memory, and shows how they are allocated:
CLS 1123edb0 (name=java/lang/StringBuffer, trace=1318) super 111504e8 constant[25] 8abd48 constant[32] 1123edb0 constant[33] 111504e8 constant[34] 8aad38 constant[115] 1118cdc8 CLS 111ecff8 (name=java/util/Locale, trace=1130) super 111504e8 constant[2] 1117a5b0 constant[17] 1124d600 constant[24] 111fc338 constant[26] 8abd48 constant[30] 111fc2d0 constant[34] 111fc3a0 constant[59] 111ecff8 constant[74] 111504e8 constant[102] 1124d668 ... CLS 111504e8 (name=java/lang/Object, trace=1) constant[18] 111504e8CLS tells you that memory is being allocated for a class. The hexadecimal number following it is the address where that memory is allocated.
Next is the class name followed by a trace reference. Use this information to cross-reference the trace output and see when the class is called. If you refer to that particular trace, you can get the line number of the instruction that led to the creation of this object. The addresses of the constants in this class are also displayed and, in the previous example, the address of the class definition for the superclass. Both classes are a child of the same superclass (with address 11504e8). Looking further through the output, you can see this class definition and name. It is the Object class (a class that every class inherits from). The JVM loads the entire superclass hierarchy before it can use a subclass. Thus, class definitions for all superclasses are always present. There are also entries for Objects (OBJ) and Arrays (ARR):
OBJ 111a9e78 (sz=60, trace=1, class=java/lang/Thread@8b0c38) name 111afbf8 group 111af978 contextClassLoader 1128fa50 inheritedAccessControlContext 111aa2f0 threadLocals 111bea08 inheritableThreadLocals 111bea08 ARR 8bb978 (sz=4, trace=2, nelems=0, elem type=java/io/ObjectStreamField@8bac80)If you set the heap option to sites or all , you get a list of each area of storage allocated by your code. The parameter all combines dump and sites. This list is ordered starting with the sites that allocate the most memory:
SITES BEGIN (ordered by live bytes) Tue Feb 06 10:54:46 2007 percent live alloc'ed stack class rank self accum bytes objs bytes objs trace name 1 20.36% 20.36% 190060 16 190060 16 300000 byte[] 2 14.92% 35.28% 139260 1059 139260 1059 300000 char[] 3 5.27% 40.56% 49192 15 49192 15 300055 byte[] 4 5.26% 45.82% 49112 14 49112 14 300066 byte[] 5 4.32% 50.14% 40308 1226 40308 1226 300000 java.lang.String 6 1.62% 51.75% 15092 438 15092 438 300000 java.util.HashMap$Entry 7 0.79% 52.55% 7392 14 7392 14 300065 byte[] 8 0.47% 53.01% 4360 16 4360 16 300016 char[] 9 0.47% 53.48% 4352 34 4352 34 300032 char[] 10 0.43% 53.90% 3968 32 3968 32 300028 char[] 11 0.40% 54.30% 3716 8 3716 8 300000 java.util.HashMap$Entry[] 12 0.40% 54.70% 3708 11 3708 11 300000 int[] 13 0.31% 55.01% 2860 16 2860 16 300000 java.lang.Object[] 14 0.28% 55.29% 2644 65 2644 65 300000 java.util.Hashtable$Entry 15 0.28% 55.57% 2640 15 2640 15 300069 char[] 16 0.27% 55.84% 2476 17 2476 17 300000 java.util.Hashtable$Entry[] 17 0.25% 56.08% 2312 16 2312 16 300013 char[] 18 0.25% 56.33% 2312 16 2312 16 300015 char[] 19 0.24% 56.57% 2224 10 2224 10 300000 java.lang.ClassIn this example, Trace 300055 allocated 5.27% of the total allocated memory. This percentage works out to be 49192 bytes.
The cpu option gives profiling information about the processor. If cpu is set to samples, the output contains the results of periodic samples taken during execution of the code. At each sample, the code path being processed is recorded, and a report is produced similar to:
CPU SAMPLES BEGIN (total = 714) Fri Aug 30 15:37:16 2002 rank self accum count trace method 1 76.28% 76.28% 501 77 MyThread2.bigMethod 2 6.92% 83.20% 47 75 MyThread2.smallMethod ... CPU SAMPLES ENDYou can see that the bigMethod() was responsible for 76.28% of the processor execution time and was being run 501 times out of the 714 samples. If you use the trace IDs, you can see the exact route that led to this method being called.
Parent: Using the HPROF Profiler
Error 404 - Not Found Error 404 - Not Found
The document you are looking for may have been removed or re-named. Please contact the web site owner for further assistance.