プログラムのコンパイル時には、ほとんどのコンパイラオプションを使用してデータの収集および解析を行うことができますが、収集対象とパフォーマンスアナライザでの表示対象に影響するオプションがいくつかあります。プログラムのコンパイルとリンクする際に考慮する問題は以降のサブセクションで説明します。
注釈付きの「ソース」および「逆アセンブリ」ビューにソースコードを表示し、「行」ビューにソース行を表示するには、-g コンパイラオプション (C++ でフロントエンドインライン化を有効にするには -g0) で対象のソースファイルをコンパイルし、デバッグシンボル情報を作成します。 デバッグシンボル情報の形式は、-xdebugformat=dwarf によって指定される DWARF2 です。これがデフォルトです。
DWARF 形式のデバッグ用シンボルで構築された実行可能ファイルやライブラリには、構成要素である各オブジェクトファイルのデバッグシンボルのコピーが自動的に取り込まれます。stabs 形式のデバッグ用シンボルを使用して構築された実行可能ファイルとライブラリの場合、デバッグシンボルのリンク時に –xs オプションが指定され、各種のオブジェクトファイルおよび実行可能ファイル内に stabs シンボルが残されていれば、構成要素である各オブジェクトファイルのデバッグシンボルのコピーが取り込まれます。この情報の取り込みは、オブジェクトファイルを移動したり、削除したりする必要がある場合に特に有用です。すべてのデバッグ用シンボルが実行可能ファイルとライブラリ自体にあるので、実験とプログラム関連ファイルを別の場所に容易に移動できます。
プログラムは Oracle Developer Studio コンパイラまたは GNU コンパイラを使用してコンパイルできます。ただし、GNU コンパイラは OpenMP による再構築された呼び出しスタックなどの一部の機能をサポートできません。
-g を指定してコンパイルしても、Oracle Developer Studio コンパイラの O2 と O3 の最適化レベルでの末尾呼び出し最適化を除き、最適化に変更はありません。
Java コードのソースレベル情報がサポートされています。Java ソースの場所は、ネイティブ言語の場合とは異なり、実験に記録されません。ソースを指示するために、パスマッピングを使用するか、検索パスを設定することが必要な場合もあります。詳細は、ツールがソースコードを見つけるしくみを参照してください。
データ領域プロファイリングは、メモリーアクセスをデータ構造要素によるものとします。データ領域プロファイリングを有効にするには、Oracle Developer Studio コンパイラで -xhwcprof オプションを使用して、C、C++、および Fortran 実行可能ファイルをコンパイルする必要があります。コンパイルでこのオプションを指定しない場合、「データオブジェクト」ビューと「データレイアウト」ビューには、バイナリのデータは表示されません。
メモリー領域プロファイリングを使用すると、どのメモリーアドレスでパフォーマンスがもっとも低下しているかを確認できます。メモリー領域プロファイリング用のプログラム準備に特別なコンパイラオプションは必要ありませんが、この機能は、Oracle Solaris 10 1/13 を実行している SPARC プラットフォームと、Oracle Solaris 11.2 を実行している Intel プラットフォームでのみ使用できます。詳細は、データ領域プロファイリングとメモリー領域プロファイリングを参照してください。
ヒープトレースや I/O トレースなどのパフォーマンスデータの一部の種類では、データ収集が動的にリンクされた libc に依存します。この機能は静的にリンクした場合に失われるため、Oracle Developer Studio コンパイラで -dn や -Bstatic などのオプションを使用して libc を制御しないでください。
完全に静的にリンクされたプログラム用のデータを収集しようとすると、コレクタはエラーメッセージを出力し、データを収集しません。このエラーが発生する原因は、コレクタを実行したときに、コレクタライブラリが動的に読み込まれるためです。
システムライブラリまたはコレクタライブラリ libcollector.so のいずれも静的にリンクしないでください。
通常、collect コマンドではターゲットのアドレス空間に含まれているすべての共有オブジェクトのデータが、初期ライブラリリストに含まれているものか、dlopen() によって明示的にロードされたものかにかかわらず、収集されます。ただし、特定の条件では一部の共有オブジェクトのプロファイリングが行われないことがあります。
遅延ロードによりターゲットプログラムが呼び出された場合。この場合、起動時にはライブラリがロードされず、dlopen() の呼び出しによって明示的にもロードされないため、共有オブジェクトが実験に含まれない可能性があり、共有されたオブジェクトからの PC はすべて <Unknown> 関数にマップされます。回避策として、環境変数 LD_BIND_NOW を設定すると、起動時にライブラリが強制的にロードされます。
実行可能ファイルが –B direct オプションを指定して構築された場合。この場合、オブジェクトは特に dlopen() の動的リンカーのエントリポイントへの呼び出しによって動的にロードされるため、libcollector 割り込みがバイパスされます。共有オブジェクト名が実験に含まれない可能性があり、そのオブジェクトからのすべての PC が <Unknown>() 関数にマップされます。回避策は、–B direct オプションを使用しないことです。プログラムが正常に終了すると、そのような共有オブジェクトが検出され、記録されます。
何らかのレベルの最適化を有効にしてプログラムをコンパイルすると、コンパイラにより実行順序が変更され、プログラム内の行の順序と実行順序が厳密に一致しなくなることがあります。この場合、パフォーマンスアナライザは、最適化されたコードについて収集された実験データを解析できますが、しばしば、逆アセンブリレベルでパフォーマンスアナライザが提供するデータを元のソースコード行に対応付けることが困難になります。また、コンパイラが末尾呼び出しの最適化を行う場合には、呼び出しシーケンスが予想とは異なっているように見えることがあります。詳細は、末尾呼び出しの最適化を参照してください。