4. OProfile results with JIT samples

After profiling a Java (or other supported VM) application, the OProfile JIT support creates ELF binaries from the intermediate files that were written by the agent library. The ELF binaries are named <tgid>.jo. With the symbol information stored in these ELF files, it is possible to map samples to the appropriate symbols.

The usual analysis tools (opreport and/or opannotate) can now be used to get symbols and assembly code for the instrumented VM processes.

Below is an example of a profile report of a Java application that has been instrumented with the provided agent library.

$ opreport -l /usr/lib/jvm/jre-1.5.0-ibm/bin/java
CPU: Core Solo / Duo, speed 2167 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Unhalted clock cycles) with a unit mask of 0x00 (Unhalted core cycles) count 100000
samples  %        image name               symbol name
186020   50.0523  no-vmlinux               no-vmlinux               (no symbols)
34333     9.2380  7635.jo                  java                     void test.f1()
19022     5.1182  libc-2.5.so              libc-2.5.so              _IO_file_xsputn@@GLIBC_2.1
18762     5.0483  libc-2.5.so              libc-2.5.so              vfprintf
16408     4.4149  7635.jo                  java                     void test$HelloThread.run()
16250     4.3724  7635.jo                  java                     void test$test_1.f2(int)
15303     4.1176  7635.jo                  java                     void test.f2(int, int)
13252     3.5657  7635.jo                  java                     void test.f2(int)
5165      1.3897  7635.jo                  java                     void test.f4()
955       0.2570  7635.jo                  java                     void test$HelloThread.run()~


Depending on the JVM that is used, certain options of opreport and opannotate do NOT work since they rely on debug information (e.g. source code line number) that is not always available. The Sun JVM does provide the necessary debug information via the JVMTI[PI] interface, but other JVMs do not.

As you can see in the opreport output, the JIT support agent for Java generates symbols to include the class and method signature. A symbol with the suffix ˜<n> (e.g. void test$HelloThread.run()˜1) means that this is the <n>th occurrence of the identical name. This happens if a method is re-JITed. A symbol with the suffix %<n>, means that the address space of this symbol was reused during the sample session (see Section 6, “Overlapping symbols in JITed code”). The value <n> is the percentage of time that this symbol/code was present in relation to the total lifetime of all overlapping other symbols. A symbol of the form <return_val> <class_name>$<method_sig> denotes an inner class.