
Javaパフォーマンスチューニング
第6回 HotSpot VMの特性を知る
テクニカルライター
小林聡史
2005/8/31
|
本連載の最終回は、HotSpot VMに固有の振る舞いを学びます。HotSpot VMのデフォルト設定ではパフォーマンスが思うように向上しないケースを紹介し、対処方法を説明します。また後半では、JVMのPermanent領域のチューニング方法を説明します。
| ベンチマーク・プログラムからHotSpot VMの特長を探る |
アプリケーションのチューニングの効果を比較するためにしばしば作成されるのが、簡単なベンチマーク・プログラムです。しかし、HotSpotベースのJVMでは、ベンチマークの設計のまずさが誤解を生む原因となりかねません。例えば、ベンチマークによっては、旧型のJIT(Just-In-Time)コンパイラを備えたClassic JVMの方が高速になることもあるのです。
まずは、以下のベンチマーク・プログラムをご覧ください。
public class SimpleBenchmark { |
ご覧のとおり、ループを1億回繰り返し、その経過時間を測るという簡単なベンチマークです。このプログラムをコンパイルし、デフォルトのHotSpot JVMで実行すると、以下のような結果が得られます。
$ java SimpleBenchmark |
一方、JDK 1.3以前のJVMの起動オプションに-classicを指定し、Classic JVMで実行してみます(なお同オプションはJDK 1.4以降ではサポートされていません)。
$ java -classic SimpleBenchmark |
このように、HotSpot VMはClassic JVMよりも25倍も遅いという結果が得られます。
ここで、JITコンパイルを一切行わず、すべてをインタプリタ実行するとどのような結果が得られるか試してみましょう。JVMの起動時に-Xintオプションを指定することで、純粋なインタプリタとして動作させることができます。その結果は以下のとおりです。
$ java -Xint SimpleBenchmark |
このように、上述したHotSpot VMによる結果は、インタプリタ実行時の結果とほぼ同じであることが分かります。
■HotSpot VMとClassic JVM
では、なぜこのような違いが表れるのでしょうか。その理由を探るために、HotSpot VMとClassic JVMの差を比較してみます。
| JVMの種類 | 特長 |
| Classic JVM |
JIT(Just-In-Time)コンパイラを搭載する。実行されるすべてのコードをコンパイルする |
| HotSpot VM | HotSpotコンパイラを搭載する。アプリケーションにおいて最も実行頻度の高い部分のみコンパイルする |
一般的なプログラムには、コードの20%の部分に実行時間の80%が費やされるという、いわゆる80/20の法則が当てはまります。HotSpot VMは、この80/20の法則に基づいて設計されています。つまり、同JVMでは最初はアプリケーションをインタプリタ・モードで実行し、コードの実行頻度の解析を行います。これにより、「HotSpot」すなわち実行頻度の高い部分を特定したならば、その部分についてのみバイナリ・コードへのコンパイルやインライン展開などの最適化を実施します。これに対し、Classic JVMでは、実行されるすべてのコードをコンパイルするため、コンパイル時間がオーバーヘッドとなります。
本来であれば、HotSpot VMの方がClassic JVMよりも優れたパフォーマンスを実現できるはずです。しかし上述したベンチマークの例では、ループを含むメソッドが1回しか呼び出されないため、インタプリタ・モードのままループを実行してしまうのです。
こうした場合は、JVMの起動オプションとして-XX:+UseOnStackReplacementを指定し、On Stack Replacement機能を有効にします(-XX:+UseCompilerSafepointsを同時に指定する必要があります*1)。このオプションを利用すると、メソッド呼び出しの最中であっても、インタプリタ実行からコンパイル済みバイナリの実行へ切り替えられるようになります。これにより、以下のような結果が得られます。
*1:本オプションはHP、SunのどちらのJVMでも利用可能$ java |
このように、Classic JVMより優れた結果が得られることがわかります。
■HotSpot最適化にかかる時間
上記の例のように、比較的短い時間で終了するベンチマークは「マイクロ・ベンチマーク」と呼ばれます。しかし上述したとおり、HotSpot
VMでは最適化を始める前にインタプリタ・モードでコードを実行し、HotSpotの分析に時間を費やします。そのため、マイクロ・ベンチマークでは、HotSpot
VMによる最適化の効果をほとんど得ることができません。
HotSpot VMにおいて、こうしたマイクロ・ベンチマークで十分なパフォーマンスを得るには、ベンチマーク部分をメソッドとして切り出し、それを繰り返し呼び出すようにコードを修正します。以下は、上述のベンチマークを修正した例です。
public class HotSpotBenchmark { |
このプログラムをHotSpot VMで実行すると、以下のような結果が得られます。
$ java HotSpotBenchmark |
ここで、ベンチマーク部分のメソッドはインタプリタ・モードのままで3回実行されていることに注目してください。一般には、HotSpot VMが最適化を終えるまでには1〜2分を要します。その最適化の結果、HotSpot VMではClassic JVMの80倍の高速化を達成していることが分かります。
パフォーマンス・チューニングを目的としてベンチマークを作成する際には、それがアプリケーション全体のアーキテクチャを反映できているかを見直してください。HotSpot VMの効果を高めるには、そのベンチマークが十分に長時間実行され、「HotSpot」部分が繰り返し呼び出されなくてはならないのです。
| 1/2 |
|
INDEX |
||
| Javaパフォーマンスチューニング 第6回 | ||
| Page1 ベンチマーク・プログラムからHotSpot VMの特長を探る |
||
| Page2 Permanent領域のチューニング |
||
Javaパフォーマンスチューニング バックナンバー
TechTargetジャパン
- Scalaのパッケージ、アクセス修飾子、オブジェクト継承 (2012/5/22)
インポート、パッケージオブジェクト、抽象クラス/抽象メソッド、オーバーライド、final、シールドクラスなども - 基幹系システムでCloud SQLは使えるか試してみた (2012/5/17)
サンプルとしてMRPシステムを作成して動かし、「再帰呼び出し」などのパフォーマンスを測定して検証してみます - アジャイル管理ツール9選+Pivotal Tracker入門 (2012/5/14)
群雄割拠のアジャイルプロジェクト管理ツールを9つ紹介し、特に注目を集めているPivotal Trackerの基本的な使い方を解説します - サーバサイドJSやJavaでWebアプリが作れるXPages (2012/5/11)
Notes/Dominoの資産をサーバサイドJavaScriptやJavaで操作し、HTMLやJavaScript、CSSをUIにできる技術を紹介
|
|
キャリアアップ
スポンサーからのお知らせ
- - PR -
イベントカレンダー
- - PR -

本記事は、