IBM Power7 - Locking Analysis

182 POWER7 and POWER7+ Optimization and Tuning Guide
Example B-15 contains a shell program to collect a profile on Linux using Oprofile. The
resulting profile might be similar to the previous example profile on AIX, indicating substantial
time in spin locking and in GC. Depending on some specifics of the Linux system, however,
the locking impact can appear in routines in the libj9thr24.so shared object, as compared to
the AIX spin locking seen in libj9jit24.so. In some cases, an environment variable setting
might be necessary to indicate the location of the JVMTI library that is needed for running
Oprofile with Java:
򐂰 Linux 32-bit: LD_LIBRARY_PATH=/usr/lib/oprofile
򐂰 Linux 64-bit: LD_LIBRARY_PATH=/usr/lib64/oprofile
Example B-15 Linux shell to collect a profile using Oprofile
#!/bin/ksh
# Use --no-vmlinux if we either have a compressed kernel or do not care about the kernel symbols.
# Otherwise, use "opcontrol --vmlinux=/boot/vmlinux", for example.
opcontrol -–no-vmlinux
# Stop data collection and remove daemon. Make sure we start from scratch.
opcontrol -–shutdown
# Load the Oprofile module if required and makes the Oprofile driver interface available.
opcontrol -–init
# Clear out data from current session.
# opcontrol -–reset
# Select the performance counter that counts non-idle cycles and generates a sample after 500,000
# such events.
opcontrol -e PM_RUN_CYC_GRP1:500000
# Start the daemon for data collection.
opcontrol --start
# Run the Java program. "-agentlib:jvmti_oprofile" allows Oprofile to resolve the jitted methods.
java -Xms10m -Xmx10m -agentlib:jvmti_oprofile ProfileTest
# Stop data collection.
opcontrol --stop
# Flush the collected profiling data.
opcontrol --dump
# Generate a summary report at the module level.
opreport > ProfileTest_summary.log
# Generate a long report at the function level.
opreport -l > ProfileTest_long.log
Locking analysis
Locking bottlenecks are fairly common in Java applications. Collect locking information to
identify any bottlenecks, and then take appropriate steps to eliminate the problems. A
common case is when older java/util classes, such as Hashtable, do not scale well and cause
a locking bottleneck. An easy solution is to use java/util/concurrent classes instead, such
as ConcurrentHashMap.