HotSpot VMの特性を知る

本記事は、HP-UX Developer Edgeに掲載された記事を株式会社アットマーク・アイティおよび本記事の筆者が独自の判断のもとに加筆・修正したものです。 本連載の最終回は、HotSpot VMに固有の振る舞いを学びます。HotSpot VMのデフォルト設定ではパフォーマンスが思うように向上しないケースを紹介し、対処方法を説明します。また後半では、JVMのPermanent領域のチューニング方法を説明します。 ベンチマーク・プログラムからHotSpot VMの特長を探る アプリケーションのチューニングの効果を比較するためにしばしば作成されるのが、簡単なベンチマーク・プログラムです。しかし、HotSpotベースのJVMでは、ベンチマークの設計のまずさが誤解を生む原因となりかねません。例えば、ベンチマークによっては、旧型のJIT（Just-In-Time）コンパイラを備えたClassic

[millfi]

1億回インクリメントなんてHotSpotで置換されちゃうんだから意味ないでしょ。人はなぜ極めて単純なプログラムでベンチマークするのか。

[totttte]

hotspotは関数呼ばれた回数でJIT化が決まる。　Cだと void hoge(){while(1){foo();}} はめっちゃ効率悪いけども、Javaの場合はvoid hoge(){foo();}} foo(){while(true){//anything }}の方が効率悪い場合もありえる！と。

[zetfs]

HotSpot VM

[Gln]

本来であれば、HotSpot VMの方がClassic JVMよりも優れたパフォーマンスを実現できるはずです。しかし上述したベンチマークの例では、ループを含むメソッドが1回しか呼び出されないため、インタプリタ・モードのままループ

[toton]

マイクロベンチマークと -XX:+UseOnStackReplacement