インテル® VTune™ Amplifier XE 2013 における Java* サポートの再開

この記事は、インテル® ソフトウェア・サイトに掲載されている「Java support is back in VTune Amplifier XE」の日本語参考訳です。

---

旧インテル® VTune™ パフォーマンス・アナライザーのユーザーの皆さんは、Java* アプリケーションのプロファイルをサポートしていたことを記憶されているでしょう。最初のインテル® VTune™ Amplifier XE ではこの機能はサポートされなくなりましたが、それ以来、インテル® VTune™ Amplifier XE で Java* をサポートして欲しいという多くの要望が寄せられました。純粋な Java* アプリケーションおよび Java* とネイティブ C/C++ が混在するアプリケーションのプロファイルが再び必要になっているためです。

この要望に応じて、2012 年 9 月、新たにリリースされたインテル® VTune™ Amplifier XE 2013 では、JIT アプリケーションのプロファイルのサポートに加えて、Java* アプリケーションのプロファイルがサポートされました。

なぜ Java* アプリケーションのプロファイルが必要になったのでしょうか。パフォーマンス・プロファイルの主な目的は、多くの CPU 時間を費やしている関数やコードの場所を特定して、コンピューティング・リソースを効率良く使用しているかを調べることです。Java* コードの実行がマネージドランタイム環境で制御されたとしても、データ管理の点からはネイティブ言語を使用して記述されたプログラムほど効果はありません。

例えば、データマイニング Java* アプリケーションのパフォーマンスを意識するのであれば、ターゲット・プラットフォームのメモリー・アーキテクチャー、キャッシュ階層、メモリーレベルへのアクセスのレイテンシーを考慮する必要があります。

プラットフォームのマイクロアーキテクチャーという点で見ると、Java* アプリケーションのプロファイルはネイティブ・アプリケーションのプロファイルに似ていますが、大きな違いが 1 つあります。それは、プログラムのソースコードに対するタイミングメトリックを確認するためには、プロファイル・ツールは JVM でコンパイルまたはインタープリターで翻訳されたバイナリーコードのパフォーマンス・メトリックを、オリジナルの Java* または C/C++ ソースコードにマップできなければならない点です。

インテル® VTune™ Amplifier XE 2013 の hotspot 解析を使用すると、最もホットなメソッドのリストとタイミングメトリックおよびコールスタックが表示されます。スレッドのワークロード配分もタイムライン・ビューに表示されることに注意してください。スレッドに名前を付けると、最もリソースを消費しているコードがどこで実行されたかを特定するのに便利です。

プラットフォームにおける最高のパフォーマンスを目指す開発者は、Java* プロジェクトのパフォーマンス・クリティカルなモジュールを、C やアセンブリーのようなネイティブ言語で記述してコンパイルする手法を用いることがあります。このプログラミング手法を用いることで、ベクトル・コンピューティング (SIMD ユニットと命令セットにより実装) のような強力な CPU リソースを使用することができます。

この場合、大部分の処理を行うことが期待される、計算を多用する関数が hotspot としてプロファイル結果に表示されます。しかし、hostpot 関数だけでなく、それらの関数が JNI インターフェイスで呼び出された Java* コードの位置を特定したいこともあるでしょう。混在言語のアルゴリズム実装におけるクロスランタイム呼び出しのような処理をトレースすることは課題の 1 つです。

混在コードのプロファイル結果の解析をサポートするため、インテル® VTune™ Amplifier XE 2013 は、Java* のコールスタックと後続の C/C++ 関数のネイティブなコールスタックを「スティッチ」します (1 つにまとめます)。逆のコールスタックのスティッチも同様に行われます。

このツールの最も高度な使用法は、プラットフォームに搭載されている CPU のマイクロアーキテクチャー向けに Java* アプリケーションをプロファイルして最適化することです。Java* や JVM テクノロジーはマシン・アーキテクチャー固有のコーディングからプログラマーを解放するように意図されているため、これは逆説的に思えるかもしれませんが、Java* コードが現在のインテル® アーキテクチャー向けに最適化されれば、将来の世代の CPU でも、おそらくこの利点は維持されます。

インテル® VTune™ Amplifier XE 2013 は、最先端のハードウェア・イベントベースのプロファイル・テクノロジーを提供します。これにより、CPU のパイプラインのハードウェア・イベントをモニターし、CPU の効率良い命令実行を制限するコードの落とし穴を特定します。ハードウェア・パフォーマンス・メトリックが利用でき、アプリケーションのモジュール、関数、Java* コードのソース行に対して表示することができます。

また、スタックを含むハードウェア・イベントベースのサンプリング・コレクションも利用できます。ドライバーやシステムのミドルウェア層で呼び出された関数の呼び出しパスを調べる必要があるときに役立ちます。

パフォーマンス解析は、インテル® VTune™ Amplifier 2013 の GUI またはコマンドライン・ツールを使用して簡単に設定できます。1 つの方法として、バッチファイルや実行可能なスクリプトで java コマンドを指定する方法があります。
例えば、run.cmd ファイルに次のコマンドを指定します。

java.exe -Xcomp -Djava.library.path=mixed_dll\ia32 -cp C:\Design\Java\mixed_stacks MixedStacksTest 3 2

コマンドを追加したら、インテル® VTune™ Amplifier XE 2013 プロジェクトのプロジェクト設定で、起動するアプリケーションに run.cmd ファイルのパスを指定します。さらに、マネージドコードのプロファイルとして [Auto(自動)] を選択し、子プロセスの解析を行うように指定 ([Analyze child processes] をチェック) します。これで解析の準備は完了です。

同様に、コマンドライン・ツールで解析を設定することもできます。例えば、hotspot 解析で次のコマンドを使用します。

amplxe-cl –collect hotspots -- run.bat

または

amplxe-cl –collect hotspots -- java.exe -Xcomp -Djava.library.path=mixed_dll\ia32 -cp C:\Design\Java\mixed_stacks MixedStacksTest 3 2

Java* アプリケーションをしばらく実行する必要がある場合や、解析を開始するときに起動できない場合、Windows* ではツールを Java* プロセスにアタッチすることもできます。ターゲットタイプを [Attach To Process (プロセスにアタッチ)] に変更して、プロセス名または PID を追加します。

Java* アプリケーションのプロファイルで問題が発生することがあります。JVM は、バイナリーコードの処理に特殊な手法を用いているため、実行された命令のアドレスとソース行番号が完全に一致しないことがあります。その結果、次のソースコード行にずれてしまいます。ループの場合、タイムメトリックが上にずれます。この点を覚えておいて、疑わしい結果に注意してください。

JVM は、パフォーマンス上の理由により、ほとんど呼ばれなかったメソッドをコンパイルする代わりにインタープリターで翻訳することがあります。ツールは、このような呼び出しを復元したコールスタックで「!Interpreter」としてマークします。インタープリターで翻訳された呼び出しの名前を識別する機能は、将来の製品アップデートで実装される予定です。

これらの関数を名前でスタックに表示するには、“–Xcomp” オプションを使用して JVM でコンパイルします。しかし、実行中に多くの小さな関数やほとんど使用されない関数が呼び出された場合、タイミング特性は顕著に変わります。コンパイル段階のインライン展開により、一部の関数はスタックに表示されない場合があることに注意してください。

インテル® VTune™ Amplifier XE 2013 の最初のリリースには、次のような制限事項があります。

• すべての Java* ランタイム環境 (JRE) をサポートすることは困難であるため、現時点では Oracle* Java* 6 および 7 のみサポートしています。
• Java* アプリケーションのプロファイルは hotspot 解析とハードウェア・イベントベースの解析 (ライト hotspot 解析) でサポートされていますが、コンカレンシー解析では (オペレーティング・システムの同期オブジェクトを呼ばない) 一部の組込み Java* 同期プリミティブを認識できません。その結果、一部のタイミングメトリックがコンカレンシー解析およびロックと待機の解析で正しく動作しません。
• Linux* ではツールを Java* プロセスにアタッチできません。現在は、Windows* でのアタッチのみサポートしています。
• Java* ソースコードのコレクション制御用のユーザー API を提供する専用ライブラリーはありません。ただし、JNI 呼び出しで __itt 呼び出しをラップしてネイティブ API を適用することはできます。

Java* サポート機能は現在も開発を継続しています。Java* ランタイムおよび Java* 仮想マシンは、新しい JDK アップデートのリリースごとに変更されるため、スタックのアンワインドや JVM からのシンボルの取得で問題に直面する可能性があります。その場合は、インテルのサポートチームにお問い合わせください。

異なるプラットフォームで Java* または混在アプリケーションをプロファイルするときに考慮すべき点の詳細なリストを以下に示します。

Java* VM の動作を変更する追加の Oracle* JDK Java* VM コマンドライン・オプション

• Linux* x86 では、サーバー Java* VM の代わりにクライアント Oracle* JDK Java* VM を使用します。つまり、Oracle* JDK Java* VM コマンドライン・オプションとして “-client” を明示的に指定するか、“-server” を指定しません。
• Linux* x64 では、インタープリターで翻訳したメソッドとコンパイルバージョンのオンザフライ置換をオフにするコマンドライン・オプション ‘-XX:-UseLoopCounter’ を指定します。
• Windows* では、JIT コンパイルでスタックウォークがより適切に行われるように、’-Xcomp’ を指定します。

注: JVM が最初にインタープリターで翻訳した関数をコンパイルするように指定すると、アプリケーションのタイミングが変更されることがあります。また、小さな関数やほとんど使用されない関数をコンパイルすると、インタープリターで翻訳した場合よりもパフォーマンスが低下します。

Linux* でスタック・アンワインド・モードを「コレクション後」に変更する方法

• インテル® VTune™ Amplifier XE 2013 のツールバーで [New Analysis (新しい解析)] ボタンをクリックします。
• [Hotspots (hotspot)] 解析タイプを選択して右クリックします。
• コンテキスト・メニューで [Copy from current (現在からコピー)] を選択します。
• [Custom Analysis (カスタム解析)] ダイアログの [Stack unwinding mode (スタック・アンワインド・モード)] ドロップダウン・リストで [After collection (コレクション後)] を選択して [OK] ボタンをクリックします。
• 新しい解析タイプを使用してコレクションを開始します。

* その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

コンパイラーの最適化に関する詳細は、最適化に関する注意事項を参照してください。