IBM Power System POWER7 Series, Optimization And Tuning Manual

Page: 192 / 224

176
POWER7 and Optimization and Tuning Guide
Complex C++ applications or C programs that use object-based techniques might see
performance issues that are related to using many small functions of indirect calls. Unless the
compiler or optimizer can see the whole program or library, it cannot prove that it is safe to
optimize these cases. However, it is possible for the developer to manually optimize at the
source level, as the developer knows the original intent or actual usage in context.
The SCA can find and recommend solutions for many of these coding style and machine
hazards. The process generates a journal that associates performance problems (including
hazards) with specific source file and line numbers.
The SCA window has a drill-down hierarchy similar to the profile window described in
“Hotspot profiling” on page 175. The SCA window is organized as a list of problem categories,
and then nested twisties, for affected functions and source line numbers within functions.
Functions and lines are ordered by the percent of overall contribution to execution time.
Associated with each problem is a plain language description and suggested solution that
describes a source change or compiler or linker options that are expected to resolve the
problem. Clicking the line number item
jumps the source display to the associated source file
and line number for editing.
SCA uses the Feedback Directed Program Restructuring (FDPR) tool to instrument your
application (or library) for code and data flow trace while you run a workload. The resulting
FDPR journal is used to drive the SCA analysis. Running FDPR and retrieving the journal is
can be automated by clicking Profile as

Profile with Source Code Advisor.
Java (either AIX or Linux)
Focused empirical analysis of Java applications involves gathering specific types of
performance information, making and assessing changes, and repeating the process. The
specific areas to consider, the types of performance information to gather, and the tools to
use, are described in this section.
32-bit or 64-bit JDK
All other things being equal, a 64-bit JDK using -Xcompressedrefs generally has about 5%
lower performance than does a 32-bit JDK. Without the -Xcompressedrefs option, a 64-bit
JDK might have 10% or more reduced performance, which is compared to a 32-bit JDK. Give
careful consideration to the choice of a 32-bit or 64-bit JVM. It is
not a good choice to take an
application that suffers from excessive object allocation rates and switch to a 64-bit JVM
simply to allow a larger heap size. The references in the related tools and analysis techniques
information can be used to diagnose object allocation issues in an application.
For more information about this topic, see:
򐂰 “Verbose GC Log” on page 177
򐂰 7.2, “32-bit versus 64-bit Java” on page 126.
Java heap size, and garbage collection policies and parameters
The performance of Java applications is often influenced by the heap size, GC policy, and GC
parameters. Try different combinations, which are guided by appropriate data gathering and
analysis. Various tools and diagnostic options are available that can provide detailed
information about the state of the JVM. The information that is provided can be used to guide
tuning decisions to maximize performance for an application or workload.