Azul Systemsは本日、jHiccupのリリースを発表した。これはJavaランタイムプラットフォームで動作するアプリケーションのポーズとストール（もしくは"hiccup"（一時的中断））を測定するために作られたオープンソースのツールだ。この新しいツールはAzulのJitterMeterと多少機能がオーバーラップしているが、グラフィカルな出力を生成するExcelベースのツールが加わっている。今後チャートを生成するJavaベースのツールも計画されている。それに加えて、jHiccupはアプリケーションを非常に簡単にラップすることができる。アプリケーションの起動に使っているjava -c コマンドの前に、jHiccupを加えるだけでよい。
jHiccupはランタイムプラットフォームの応答時間変動を捕捉し、ログに記録し、"Hiccup chart" で表示する。このツールはアプリケーションコードによる遅延を測定するのではなく、ストール時に動作しているアプリケーションスレッドに対して現われて影響を及ぼす、ランタイムプラットフォームによって引き起こされるストールを捕捉する。このために使われている手法はかなりシンプルだ。jHiccupはアプリケーションにスレッドを1つ追加する。これは1ms間スリープして起き上がり、最後に起き上がってからの時間を調べる。もし1ms以上であればそれを内部に記録する。こうすることで、できる限り最善レスポンス時間のベースラインを与えてくれる。
以下に挙げた2つの "Hiccup chart" を見るとわかりやすいだろう。最初のチャートは何も動かしていないシステムにおけるアイドルアプリケーションを示している。チャートの上にはjHiccupシステムの観測結果を実行全体のパーセントで示している。下のチャートでは、さらに10,000ポイントのパーセントサンプルに基づいた詳細なパーセントを示している。（アプリケーションに対して）システムがビジーになると、スケジューラはその分アプリケーション時間をストールするため、ストール数が増加する。
次のチャートはCMSコレクタを用いたHotspotで動作する電話課金アプリケーションの実例を示している。これをGCログと関連付けることによって、ここで観測されているのはマイナーそしてメジャーなGCイベントであることがわかる。CMSは世代別コレクタであり、オブジェクトを若い世代と古い世代に分け、より若いオブジェクトを優先的に回収する。このアプリは電話アプリの典型とも言えるもので、数秒間続いて終了するセッションを多数追跡するため、若い世代にハードタイム処理がある。この結果、セッションは若い世代にあるものが回収される傾向にある。大きなスパイクはおそらく古い世代のポーズだろう。
jHiccupは、特定のパフォーマンス問題のうちどれだけがアプリケーション自体によるものなのか、そして、どれだけがJVMやOS、Hypervisor（使われていれば）、ハードウェアなど別の要因によるものなのかを示すことで、あなたが時間をかけてチューニングすべき場所を簡単に見つける方法を提供してくれる。このツールはwww.azulsystems.com/resources/Javatoolsからフリーでダウンロードでき、Creative Commonsライセンスのもとオープンソースとしてリリースされる。