Amazon Corretto チームは、Heapothesys を導入した。これは、アプリケーション開発者向けに設計された JVM のガベージコレクション（GC）ワークロードのコレクションであり、GC の代替アルゴリズムや構成の選択を比較し、GC のパフォーマンスやレイテンシのリグレッションを検出するためのものだ。
Heapothesys、発音は /hɪˈpɒθɪsɪs/ 、は 2 つのユーティリティで構成されている。HyperAlloc は、GC のレイテンシへの影響を詳しく調べるために Java アプリケーション上でワークロードを合成するオープンソースの GC レイテンシベンチマークだ。Extremem は、停止なしのガベージコレクションへの様々なアプローチの長所と短所を評価するテストワークロードだ。Extremem 内のワークロードは、ビジネスロジックの実行によるヒープオブジェクトの割り当てと解放を混合する。HyperAlloc の詳細については、このニュース記事で取り上げている。
HyperAlloc は、割り当て率、ヒープ占有率、JVM フラグによって定義される GC 負荷シナリオの作成とテストを行う基本的なアプリケーション特性をシミュレートする。結果として得られる JVM の停止を使用して、開発者は、アプリケーション内の GC 境界を詳しく調べるために独自の参照点を作成できる。
HyperAlloc のインスピレーションは HeapFragger に由来している。これは、Azul Systems の CTO であり共同創設者である Gil Tene 氏によって作成されたヒープフラグメンテーションを誘発するユーティリティだ。HeapFragger ほど機能が豊富ではないが、HyperAlloc は、GC の圧力の原因となる 2 つの主要な要因を評価することで、結果としてのGC割り当て率を正確に予測することに焦点を当てている。それは、ヒープ割り当て率と、ガベージコレクション中のオブジェクトスキャンプロセスの結果として得られる永続的なライブオブジェクトの総量としてあらかじめ定義されるヒープ占有だ。これら2つの要素は、特にヒープ割り当てのコマンドライン引数 : -a (デフォルト1024 MB/秒）とヒープ占有の -h (デフォルト64 MB) のセットを通じて設定される。
JVM の停止は、jHiccup のようなユーティリティを使って測定できる。これは、アプリケーションの停止や失速を測定するために設計されたオープンソースのツールだ。これは、基礎となる Java ランタイムプラットフォームに関連した「hiccups」としても知られている。
jHiccup は複数の方法で開始できる。
- Javaエージェントとして実行（例：
java -javaagent:jHiccup.jar -jar <ファイル名>.jar) - 動いているアプリケーションに注入（例：
jHiccup -p <pid>) - 既存の Java アプリケーションの便利なラッパーコマンドを使って実行（例：
jHiccup java <自分のアプリケーション> ...）
HyperAlloc と同様に、jHiccup もコマンドライン引数の完全なセットをサポートしている。
はじめに
JVM、jHiccup、および HyperAlloc をそれぞれのコマンドライン引数で構成する方法について、以下のテンプレートを検討してください。
java -Xms<バイト> -Xmx<バイト> <GC オプション> <他の JVM オプション> -Xlog:gc:<GC ログファイル> -javaagent:<jHiccup ディレクトリ>/jHiccup.jar='-a -d 0 -i 1000 -l <jHiccup ログファイル>' -jar <HyperAlloc ディレクトリ>/HyperAlloc-1.0.jar -a <MB/秒> -h <MB> -d <秒数> -c <true/false> -l <CVS 出力ファイル>
では、テンプレートを使った具体的な例として、次の2つを考えてみる。
java -Xms1g -Xmx4g -Xlog:gc:gc.log -javaagent:jHiccup.jar='-d 0 -l hiccups.hlog' -jar HyperAlloc-1.0.jar -a 65536 -h 128 -d 300 -l output.csv
java -Xms1g -Xmx4g -Xlog:gc:gc.log -javaagent:jHiccup.jar='-d 0 -l hiccups.hlog' -jar HyperAlloc-1.0.jar -a 131072 -h 128 -d 300 -l output.csv
これらの測定値のそれぞれは、1GB のヒープサイズで JVM を起動し(-Xms1g)、4 GB (-Xmx4g)まで大きくなることを許可し、gc.logファイルを作成する（-Xlog:gc:gc.log）。HyperAlloc は 300 秒間実行され、それぞれ 65536 MB/秒と 131072 MB/秒のヒープ割り当て率を使用するように設定された。
出力とデータ分析
2 つの測定が完了すると、生成された出力には次のようなものが含まれる。gc.log：関連するGC情報のロギング。hiccups.hlog：jHiccup から JVM の停止をロギング。output.csv：コマンドラインで指定されていないデフォルト値を含む、測定に使用されたすべての HyperAlloc パラメータをロギング。
結果は HistogramLogAnalyzer でプロットできる。これは、ログファイルをヒストグラム・ログ形式 （hlog）でプロットするユーティリティだ。これらのログは jHiccup や Cassandra Stress、hlog ファイル形式をサポートする他のツールによって作られる。
ヒープ割り当て速度が 65536MB/秒での測定の場合：
ヒープ割り当て速度が 131072MB/秒での測定の場合：
高いヒープ割り当て率を使用した場合の最大待ち時間の有意な差に注意だ。
jHiccup は、hlog ファイルを処理するための独自のユーティリティを提供している。2 つのそれぞれの測定値のため以下を実行する。
<jHiccup directory>/jHiccupLogProcessor -i hiccups.hlog -o out.log
これは out.log と out.log.hgrm を生成する。後者は、ハイダイナミックレンジ（HDR）ヒストグラムのプロットアプリケーションであるHdrHistogramにインポートしてプロットできる。 これは、hgrm 形式のファイルを受け入れるオンラインプロットツールだ。この方法では、hgrm 形式の出力ファイルを作成するために追加のステップが必要だ。複数のファイルをインポートして、以下のように2つの測定値のオーバーレイプロットを作成できる。
Amazon Corretto チームは、より良いモデル化と追加のアプリケーションの動作を予測するために、Heapothesys の強化に取り組んでいる。開発者はこのプロジェクトに協力し、課題やアイデアを課題リストで追跡することが推奨されている。