@2026__ICPE__Benchmarking Change Detection Exactness and Overhead of Instrumentation and Sampling

# Benchmarking Change Detection Exactness and Overhead of Instrumentation and Sampling > [!abstract] 概要 > ソフトウェアシステムの観測性(observability)には実行時データの収集が必要である。収集はサンプリング(sampling)または計装(instrumentation)のいずれかで行われる。この 2 つの手法は、収集可能なデータ、変化検知の正確性、リソース消費の観点でのオーバーヘッドについて異なる特性を持つ。ソフトウェア開発中、これらの手法は異なるコミットやバリアント間の性能変化を検知するために使われる。これらの手法の従来の比較は測定の精度(accuracy)に注目してきたが、本研究では変化検知の正確性(exactness)に注目する。本論文は (1) サンプリングと計装の変化検知の正確性とオーバーヘッドを比較するベンチマーク、および (2) 現行ハードウェア上でのこのベンチマークの実験的評価を提示する。評価により、計装によるトレーシングのオーバーヘッドは我々の設定においてメソッド呼び出し当たり 0.5 μs であることがわかった。同時に、サンプリングは統計的有意性をもって識別できるオーバーヘッドを生じない。また、変化検知についても、サンプリングの方がはるかに効果的であることを示した。これらの測定の結果、開発者は、システムの完全な挙動をトレースする必要がある場合(例えば個々の REST リクエストを識別する必要がある場合)、または観測すべきメソッドを少数に事前選択できる場合に限り、計装を使用すべきであると結論づける。メソッドの事前選択ができず、複雑なプログラムの性能変化を得る必要がある場合、計装の高いオーバーヘッドのため、サンプリングが唯一実行可能な手法である。 ## 論文情報 - タイトル: Benchmarking Change Detection Exactness and Overhead of Instrumentation and Sampling - 著者: David Georg Reichelt(Lancaster University Leipzig / URZ Leipzig)、Juozas Skarbalius(Lancaster University Leipzig) - 媒体: Companion of the 17th ACM/SPEC International Conference on Performance Engineering(ICPE Companion '26)、2026-05-04〜05-08、Florence, Italy - DOI: https://doi.org/10.1145/3777911.3800701 - ベンチマークと測定結果の公開先: https://doi.org/10.5281/zenodo.15516538 - 実装(サンプリングラッパー SJSW): https://github.com/terahidro2003/sjsw/ ## 概要 JVM 上のソフトウェア性能を観測する際の 2 大技術であるサンプリングと計装について、測定の精度(accuracy)ではなく「性能変化を検知できるかどうか」という変化検知の正確性(change detection exactness)を軸に比較した論文。合成ベンチマークで、意図的にコントロールされた性能変化(1〜5 %)を注入した 2 つの SuT(System under Test)バージョンを用意し、F1-score で変化検知の正確性を、実行時間で計装・サンプリングそれぞれのオーバーヘッドを定量化した。計装は、実行中のプログラムに確率(probe)コードを挿入し、各メソッド呼び出しの開始・終了時刻をトレースデータとして記録する(Figure 1)。一方サンプリングは、外部プロセスが一定間隔でスタックトレースを問い合わせる方式であり、実行中のメソッドでもサンプリング時刻と重ならなければ検出されない可能性がある(Figure 2)。 **Figure 1: Instrumentation Process(hatched areas are executions of probe code)** ![[_attachments/Benchmarking-Change-Detection-Exactness-and-Overhead-of-Instrumentation-and-Sampling/fig01-instrumentation-process.png]] (Figure 1. method2 が method1 を呼び、method1 が method0 を呼ぶ入れ子のメソッド呼び出しに対し、計装が各メソッド呼び出しの前後に確率コードを挿入し、開始・終了時刻を Trace Data として記録する様子を示す。) **Figure 2: Sampling Process** ![[_attachments/Benchmarking-Change-Detection-Exactness-and-Overhead-of-Instrumentation-and-Sampling/fig02-sampling-process.png]] (Figure 2. サンプリングは外部プロセスが一定間隔でスタックトレースを問い合わせる方式であり、点線がサンプリング時刻を表す。method0 は実行されているにもかかわらずどのサンプリング時刻とも重ならず検出されない可能性があることを示す。) ## 問題設定 - **入力**: JVM 上で動作する合成ベンチマークプログラム(コールツリー深さ $d$、末端メソッド呼び出し回数 $m$)。ベースライン版と、ある 1 ノードの呼び出し回数を $\Delta$(1〜5 %)だけ増やした「遅いバージョン」のペア。 - **出力**: (1) 計装・サンプリングそれぞれのオーバーヘッド(実行時間の増分)、(2) 与えられた VM 数・イテレーション数の組み合わせでベースラインと遅いバージョンの差を検知できるかどうかを表す F1-score。 - **前提**: JVM バイトコード実行のみに着目し、JNI 呼び出しやスレッド同期は対象外とする。データ収集がディスク書き込み速度やサンプリング頻度によってボトルネック化する構成(記録の取りこぼしが起きる設定)は評価対象から除外する。 ## 提案手法 - **アーキテクチャ**: SuT はコールツリー深さ $d$ の合成メソッド群として生成する。深さは「決定ノード $d$ 層 + ルート層 + タスク層」の合計 $d+2$ 層で構成され、各決定ノードは 2 つの子を呼ぶ(Figure 3)。最下層の 2 メソッドは所定のタスクを $m/2$ 回ずつ実行し、遅いバージョンでは $m/2 \cdot (1+2\Delta)$ 回に増やす(§3.1)。 **Figure 3: Call Tree Graph($d=2$)** ![[_attachments/Benchmarking-Change-Detection-Exactness-and-Overhead-of-Instrumentation-and-Sampling/fig03-call-tree-graph.png]] (Figure 3. コールツリー深さ $d=2$ の合成 SuT の構造。ルート $m_0$ から 2 分岐を $d$ 層繰り返し、最下層の 2 メソッド(ハッチングされた $m_{21}$ が性能変化の注入対象)がそれぞれ $m/2$ 回タスクを実行する。) - **サンプリング実行基盤 SJSW**: Simple Java Sampling Wrapper(SJSW)という自作ライブラリで、async-profiler をイテレーションごとに開始・停止し、各イテレーションの JFR(Java Flight Recorder)ファイルを個別に保存する(Figure 4)。実行後、OpenJDK JMC ライブラリで各イテレーションの部分コンテキストコールツリー(CCT)を構築し、JVM 内部・ネイティブメソッドを除去したうえで全イテレーションを 1 つの CCT にマージする。 **Figure 4: Sampling VM Organization** ![[_attachments/Benchmarking-Change-Detection-Exactness-and-Overhead-of-Instrumentation-and-Sampling/fig04-sampling-vm-organization.png]] (Figure 4. SJSW が、各 VM 内の複数イテレーションについて async-profiler を起動・停止し JFR ファイルを生成、OpenJDK JMC で部分 CCT を構築後、全イテレーションを 1 つの CCT へマージする処理の流れ。) - **統計解析パイプライン**: Figure 5 に示す通り、ベースラインと遅いバージョンそれぞれを複数 VM・複数イテレーションで実行し、(a) 実行時間から計装・サンプリングのオーバーヘッドを算出、(b) サンプリング仮想測定値(Values 2 と Values 3 からの再サンプリング)から F1-score を算出する 2 系統に分岐する。 **Figure 5: Results Analysis Process** ![[_attachments/Benchmarking-Change-Detection-Exactness-and-Overhead-of-Instrumentation-and-Sampling/fig05-results-analysis-process.png]] (Figure 5. Baseline と Slow Version それぞれの Pure/Measured 実行から得た Values 1/2/3 が、Time Analysis(Overhead)と Sampling Hypothetical Measurements(Exactness / F1-Score)の 2 系統の解析に分岐する全体フロー。) - **F1-score による変化検知正確性の定義**([21] の手法を踏襲): 任意の VM 数 $i$・イテレーション数の組み合わせについて、Values2(ベースライン)・Values3(遅いバージョン)からそれぞれ VM をランダムサンプルし、変化が検知できれば true positive、できなければ false negative とする。同様に Values2 から 2 回サンプルして偽陽性・真陰性を判定する。変化の有意性判定には Mann-Whitney 検定を用いる([21] に準拠)。 ## 新規性 - 従来のサンプリング・計装比較研究(Mytkowicz et al. [2]、Ilsche et al. [3] など)は測定値の精度(accuracy: 真値への近さ・測定間の一致度)に焦点を当てていたのに対し、本研究は「性能変化を検知できるかどうか」という変化検知の正確性という異なる軸を導入した。 - MooBench [22] のような既存の計装オーバーヘッドベンチマークが単一メソッドの自己再帰呼び出しを SuT とするのに対し、本研究のベンチマークはコールツリー深さを制御変数として明示的にモデル化し、変化がコールツリーのどの深さで起きるかによる検知難度の違いを定量化できる設計になっている。 - サンプリングと計装の変化検知の正確性を同一ベンチマーク・同一統計的枠組み(F1-score・Mann-Whitney 検定)で直接比較した点。 ## 実験設定 - **実行環境**: Rocky Linux 9.4、Linux kernel 5.14.0-427.37.1.el9_4.x86_64、OpenJDK 17.0.13。単一のハードウェア・ソフトウェアスタックで実施。 - **ワークロードパラメータ**: 末端呼び出し回数 $m = 300$(先行研究 [21] における単体テストの平均規模に合わせた)。性能変化 $\Delta$ は 1〜5 %(303〜315 回呼び出し)。コールツリー深さ $d \in \{2,4,6,8\}$。 - **観測性技術パラメータ**: 計装は全レベルを逐次計装する構成(最も低オーバーヘッドの計測方式)。サンプリングは async-profiler、サンプリング間隔 1 ms・10 ms・20 ms(デフォルトは 10 ms)。 - **実験パラメータ**: VM 再起動数 $VMs = 100$、ウォームアップイテレーション $w = 50{,}000{,}000$、測定イテレーション $m = 50{,}000{,}000$(1 VM あたり)。大きな $VMs$ は 1〜5 % という小さな性能変化を検出するための統計的検出力を確保するため。 - **比較対象**: Instrumentation-USC(全レベル逐次計装)、Sampling(1 ms / 10 ms / 20 ms 間隔)、Pure(計装・サンプリングなしのベースライン実行時間)。 - **評価指標**: 変化検知の正確性は F1-score が 98 %(偽陽性・偽陰性それぞれ 2 %)に到達するために必要な最小 VM 数。オーバーヘッドはモノトニックシステムタイマーによる 1 イテレーションあたりの実行時間。 ## 実験結果 - **変化検知の正確性(§4.2)**: コールツリー深さ 2 では計装・サンプリングともに 5 % の変化を効率的に検知できる。深さ 4 では、5 % の変化検知に計装は 50 VM を要するのに対し、サンプリングは 10 VM で足りる。深さ 8・変化 1 % では計装は全く検知できない設定がある(Figure 6)。 **Figure 6: Required VMs for Change Detection** ![[_attachments/Benchmarking-Change-Detection-Exactness-and-Overhead-of-Instrumentation-and-Sampling/fig06-required-vms-change-detection.png]] (Figure 6. Instrumentation-USC・Sampling(1ms/10ms/20ms)それぞれについて、コールツリー深さ(Depth=2/4/6/8)ごとに、性能変化(Change in %, 1〜5%)を F1-score 98% で検知するために必要な VM 数を示す。計装はどの間隔のサンプリングよりも小さな変化で必要 VM 数が急増する。) - **計装の変化検知(Figure 7)**: コールツリー深さ 2 で 1 % の変化はほぼ検知できない。2 % の変化は 90 VM を超えると検知されやすくなるが、それでも F1-score 98 % には届かない。 **Figure 7: $F_1$-score for Performance Change With Call Tree Depth 2(Instrumentation)** ![[_attachments/Benchmarking-Change-Detection-Exactness-and-Overhead-of-Instrumentation-and-Sampling/fig07-f1score-instrumentation-depth2.png]] (Figure 7. 計装によるコールツリー深さ 2 での F1-score ヒートマップ。(a) 1 % 変化はほぼ全域で F1-score が低い(紫〜赤)。(b) 2 % 変化は VM 数を増やすと F1-score が高くなる(橙〜黄)が、90 VM を超えても 98% には届かない。) - **サンプリングの変化検知**: コールツリー深さ 2 では検討したすべての性能変化が検知可能。最も低いサンプリング間隔である 20 ms でも十分な VM 数・イテレーションがあれば検知できる(本文は "see Figure 7a" と参照するが、Figure 7 のキャプションは計装(Instrumentation)のヒートマップであり、この本文参照はサンプリングの図(Figure 8 系列)を指す誤記の可能性がある)。1 ms 間隔・コールツリー深さ 4 では 20 VM で検知可能(本文は "see Figure 7b" と参照。同様の参照ずれ)。サンプリングは適切な間隔を選べば 30 VM で検討した全ての性能変化を検知できる。 **Figure 8: $F_1$-score for Performance Change of 1 %(Sampling)** ![[_attachments/Benchmarking-Change-Detection-Exactness-and-Overhead-of-Instrumentation-and-Sampling/fig08-f1score-sampling-1pct.png]] (Figure 8. サンプリング(コールツリー深さ 2、1 % 変化)の F1-score ヒートマップ。横軸 VM 数、縦軸イテレーション数。同じ 1 % 変化・深さ 2 の条件で、計装(Figure 7a)よりも明らかに高い F1-score(黄色の領域が広い)を示す。) - **オーバーヘッド比較(§4.3)**: サンプリングと Pure 実行の実行時間差は視覚的にも統計的にも有意に識別できない(neglectable overhead)。計装のオーバーヘッドはコールツリー深さにほぼ線形に増加し、計装ノード数が深さに比例して増えることに対応する。オーバーヘッドはメソッド呼び出し当たり 0.3〜0.7 μs(代表値 0.5 μs)。 **Figure 9: Overhead for Different Tree Depth** ![[_attachments/Benchmarking-Change-Detection-Exactness-and-Overhead-of-Instrumentation-and-Sampling/fig09-overhead-treedepth.png]] (Figure 9. コールツリー深さ 2〜10 における実行時間(Duration/ms)。Instrumentation(USC)はほぼ線形に増加し深さ 10 で約 1000 ms に達する一方、Sampling(1ms/20ms)は Pure とほぼ重なり深さに対してほぼ一定(約 100〜200 ms)。) - **F1-score の全体傾向**: 計装・サンプリングいずれも F1-score は計装/サンプリング対象のメソッド数の増加に対して線形に低下する。 ## 考察 - 計装は少数のメソッドに絞れば正確性が高くオーバーヘッドも許容範囲だが、対象メソッドを増やすほど正確性が線形に劣化し、コールツリーが深い(=対象メソッドが多い)アプリケーション全体の計装は非現実的になる。 - サンプリングはオーバーヘッドがほぼゼロで、かつコールツリーが深い場合でも計装よりずっと少ない VM 数で性能変化を検知できるため、事前にメソッドを絞り込めない大規模アプリケーションでは唯一実行可能な選択肢になる。 - 著者は今後の方向性として、(1) 呼び出しプロファイル・履歴実行時間・バージョン管理システムの出力を使った計装対象メソッドの効率的な選択戦略、(2) サンプリングデータに静的コード解析・制御フロー解析を組み合わせてリクエスト単位にマッピングするデータ拡充、の 2 つを挙げている。 ## 強み / 弱点・課題 - **強み**: 測定精度(accuracy)ではなく変化検知の正確性(exactness)という開発時に実務上重要な軸を明示的に定義し、統計的に厳密な検証手続き(F1-score・Mann-Whitney 検定・多数の VM 再起動)で評価した点。ベンチマークと結果データを Zenodo で公開し再現性を確保している点。 - **弱点・限界(著者自身の言及)**: - 単一のハードウェア・ソフトウェアスタック(Rocky Linux 9.4 / OpenJDK 17.0.13)でのみ実験しており、他の JVM バージョン・OS・ハードウェアでは絶対値が異なりうる(§5.2 External Validity)。 - SuT は JVM メソッド呼び出しのみからなる合成ベンチマークであり、I/O やネイティブコードを含む実アプリケーションではオーバーヘッド・検知正確性の絶対値が変わりうる(相対的な傾向は転移可能と著者は主張)。 - 計装は「全レベル逐次計装」という最も低オーバーヘッドな構成のみを評価しており、静的解析によるメソッド事前選択(先行研究 [16] の手法)は比較対象に含めていない。