JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris Studio 12.3: Performance Analyzer     Oracle Solaris Studio 12.3 Information Library
search filter icon
search icon

Document Information

Preface

1.  Overview of the Performance Analyzer

2.  Performance Data

3.  Collecting Performance Data

4.  The Performance Analyzer Tool

5.  The er_print Command Line Performance Analysis Tool

6.  Understanding the Performance Analyzer and Its Data

7.  Understanding Annotated Source and Disassembly Data

How the Tools Find Source Code

Annotated Source Code

Performance Analyzer Source Tab Layout

Identifying the Original Source Lines

Index Lines in the Source Tab

Compiler Commentary

Common Subexpression Elimination

Loop Optimizations

Inlining of Functions

Parallelization

Special Lines in the Annotated Source

Source Line Metrics

Interpreting Source Line Metrics

Metric Formats

Annotated Disassembly Code

Interpreting Annotated Disassembly

Instruction Issue Grouping

Instruction Issue Delay

Attribution of Hardware Counter Overflows

Special Lines in the Source, Disassembly and PCs Tabs

Outline Functions

Compiler-Generated Body Functions

Dynamically Compiled Functions

Java Native Functions

Cloned Functions

Static Functions

Inclusive Metrics

Branch Target

Annotations for Store and Load Instructions

Viewing Source/Disassembly Without An Experiment

-func

-{source,src} item tag

-{disasm,dis} item tag

-{cc,scc,dcc} com-spec

-outfile filename

-V

8.  Manipulating Experiments

9.  Kernel Profiling

Index

How the Tools Find Source Code

In order to display annotated source code and annotated disassembly code, the Performance Analyzer and er_print utility must have access to the source code and load object files used by the program on which an experiment was run.

Load object files are first looked for in the archives directory of the experiment. If they are not found there, they are looked for using the same algorithm as source and object files, described below.

In most experiments, source and object files are recorded in the form of full paths. Java source files also have a package name which lists the directory structure to the file. If you view an experiment on the same system where it was recorded, the source files and load object can be found using the full paths. When experiments are moved or looked at on a different machine, those full paths might not be accessible.

Two complementary methods are used to locate source and object files: path mapping and searching a path. The same methods are used to find load object files if they are not found in the archives subdirectory.

You can set path maps and search paths to help the tools find the files referenced by your experiment. In the Analyzer, use the Set Data Preferences dialog box to set path maps in the Pathmaps tab, and use the Search Path tab to set the search path as described in Setting Data Presentation Options. For the er_print utility, use the pathmap and setpath directives described in Commands That Control Searching For Source Files.

Path mapping is applied first and specifies how to replace the beginning of a full file path with a different path. For example, if a file is specified as /a/b/c/sourcefile, and a pathmap directive specifies mapping /a/ to /x/y/, the file could be found in /x/y/b/c/sourcefile. A pathmap directive that maps /a/b/c/ to /x/, would allow the file to be found in /x/sourcefile.

If path mapping does not find the file, the search path is used. The search path gives a list of directories to be searched for a file with the given base name, which is sourcefile in the example above. You can set the search path with the setpath command, and append a directory to the search path with the addpath command. For Java files the package name is tried and then the base name is tried.

Each directory in the search path is used to construct a full path to try. For Java source files two full paths are constructed, one for the base name and one for the package name. The tools apply the path mapping to each of the full paths and if none of the mapped paths point to the file, the next search path directory is tried.

If the file is not found in the search path and no path mapping prefix matched the original full path, the original full path is tried. If any path map prefix matched the original full path, but the file was not found, the original full path is not tried.

Note that the default search path includes the current directory and the experiment directories, so one way to make source files accessible is to copy them to either of those places, or to put symbolic links in those places pointing to the current location of the source file.