ソフトウェア障害分析のための 低侵襲な実行モニタリングツールの試作 井上研究室 嶋利 一真 ソフトウェア障害分析のための低侵襲な実行モニタリングツールの試作という題目で，井上研究室の嶋利が発表いたします．

ソフトウェア障害分析 デバッグ作業の中で最も時間がかかる段階は， 欠陥の検出，障害の分析のプロセス[1] 障害分析において，デバッグツールの使用時に おける動作の再現性は重要 ネットワーク系のシステムにおけるタイムアウト プログラムの副作用 まず，ソフトウェア障害分析について説明いたします． デバッグ作業を行うには障害の再現や，検出，修正などいくつかのプロセスがあります． その中でも一番時間がかかるのは欠陥の検出，障害の分析のプロセスとなっています． したがって，この作業をいかに効率よく行うかが重要となります． 様々なデバッグ手法で，障害に関する様々な情報を集めるために用いられますが， この際動作の再現性が重要となります． 例えば，ネットワーク系のシステムがあげられます． ネットワーク系のシステムでは，処理に一定以上の時間がかかると自動的にタイムアウト処理を行ってしまいます． したがって，このシステムをデバッグする際には，実行を停止するデバッガを使用できません． 他にもプログラムを書き換えるなどのプログラムの副作用を発生させるような処理は行うべきではありません． [1] Andreas Zeller. Why programs fail. 第2 版. O ’Reilly Japan, 2012.

従来のブレークポイント・デバッガ 標準的なブレークポイント・デバッガの利用モデル →ソフトウェアの実行を一旦停止する必要がある 従来のデバッガ 制御 状態 実行の中断・ 再開の指示 停止中のソフトウェアの 完全な内部状態 次に従来のブレークポイントデバッガについて説明します． 標準的なブレークポイントデバッガでは，まずデバッグを行う人間がデバッガに対して実行の中断や再開の指示を出し，デバッガがソフトウェアを制御します． そして，ソフトウェアがデバッガに状態を返し，停止中のソフトウェアの完全な内部状態を取得します． ただ，これにはソフトウェアの実行を一旦停止する必要があるため，先程あげたようなネットワーク系のシステムのデバッグには不向きです．

低侵襲デバッガ 本研究で提案する低侵襲デバッガの利用モデル →ソフトウェアの実行を継続したまま，情報の収集を 行える ソフトウェア 観測 収集したい 情報を指定 収集した 情報だけを返却 低侵襲 デバッガ 次に，本研究で提案する低侵襲デバッガについて説明します． 本研究で提案するデバッガでは，まず先程と同様にデバッグを行いたい人間が，収集したい情報をデバッガに対して指定します． 次に，先程はソフトウェアを制御していましたが，本デバッガでは観測点と収集したいデータの組を設置します． これにより，ソフトウェアが観測点を通過した際にその情報のみを取得します． この手法を用いることで，ソフトウェアの実行を停止したり，そのソースコードを書き換える必要はありません．

研究背景と目的 障害分析において，デバッガが実行に大きな影響を 与えないことは重要である 既存のブレークポイント・デバッガでは実行を 停止しなければならない 低侵襲な方法でモニタリングを行う ソフトウェアの実行を停止しない 元のソースコードを書き換えない 研究背景と目的をまとめます． 障害分析において，デバッガが実行に大きな影響を与えないことは重要であること，既存のブレークポイントデバッガでは実行の停止が必要です． そこで本研究では低侵襲な方法でモニタリングを行うことを提案します．低侵襲な方法とは，具体的にはソフトウェアの実行を止めないことと元のソースコードを書き換えないことを指します．

研究概要 JVM TI を用いた Java プログラム用のツールの試作 評価実験 予め収集したいデータを記述して実行するだけで データを見られるツール 評価実験 開発中のWebアプリケーションのデバッグへの利用 性能評価 次に研究概要について説明します． 本研究では，JVM TI を用いたJavaプログラム用のツールの試作を行いました． このツールは予め収集したいデータを記述して実行するだけでデータを見ることができます． 評価実験は，開発中のWebアプリケーションのデバッグへの利用と性能評価を行いました．

JVM TI とは JavaTM Virtual Machine Tool Interface 状態検査，実行制御の両方の機能を提供する Eclipse Debugger 等のデバッガにも用いられている スレッド，スタックフレーム，ヒープ，オブジェクト等の情報を 取得出来る まず，本ツール作成の際に使用したJVMTIについて説明します．JVM TIとは JavaTM Virtual Machine Tool Interface の略称です． これは，状態検査，実行制御の両方の機能を提供することが出来るため，Eclipse Debugger 等の代表的なJavaのデバッガにも用いられています． JVM TIを用いることによってスレッド，スタックフレーム，ヒープ，オブジェクト等の様々な情報を取得出来ます．

ツールの機能 指定したファイル名・行番号における基本データ型の局所変数の値，時刻情報を実行を止めずに取得 起動時のテキストファイル，もしくは外部プロセス から実行中のプログラムに設定 外部プロセスから任意のタイミングで，ログ出力の可否の切り替え 本ツールの機能について説明します． 一つ目はテキストファイルで指定したファイル名・行番号における基本データ型の局所変数情報，時刻情報を実行を止めずに取得します． 時刻情報はプログラムの特定のメソッドの実行前後の時刻情報を取得することで，特定のメソッドの実行時間を測定する際に用います． 二つ目は，外部プロセスから実行中のプログラムに設定した観測点での局所変数情報，時刻情報の取得です． 三つ目は，外部プロセスから任意のタイミングでログ出力の可否の切り替えです．これによりログの量を制御できます．

ツールの使い方 ファイル名，行番号，変数名を設定ファイルで指定 jarファイル実行時のVM引数に.dllファイル， 設定ファイルを指定 変数名は基本データ型の局所変数と時刻を取得出来る オプションのみ指定可能 jarファイル実行時のVM引数に.dllファイル， 設定ファイルを指定 “ -agentpath:ProbeJ.dll=options.txt ” 外部プロセスからコマンドを入力して， ブレークポイント処理の操作を行う Set ，Clear ，LogOn ，LogOff コマンド 次に実際のツールの使い方を説明します． まず，観測命令としてファイル名・行番号・変数名を設定ファイルで指定します．変数名は基本データ型の局所変数と時刻を取得出来るオプションのみ指定可能となっています． そして，jarファイル実行時のVM引数に.dllファイル，設定ファイルを以下の様に指定します．“ -agentpath:ProbeJ.dll=options.txt ” そして実行途中に外部プロセスからコマンドを入力して，ブレークポイント処理の操作を行うこともできます．コマンドはこの4つがあります．

ツールの使用例 行頭における変数の値の取得 設定ファイル.txt Test.java Eclipse 標準エラー出力 行頭における変数の値の取得　 設定ファイル.txt Test.java var1 66 Test.java var2 70 Test.java static void check(){ 62 long var1=200; 63 int var2=2000; 64 var1++; 65 var2++; 66 var1++; 67 var2++; 68 var1++; 69 var2++; 70 var1++; 71 var2++; } Eclipse 標準エラー出力 Test.java check line66 var1[J] is 201 Test.java check line70 var2[I] is 2003

評価実験 定性的評価：井上研究室で開発中の Webアプリケーション[2]のデバッグへの利用 定量的評価：DaCapo Benchmarks[3]を用いた 性能計測 [2] K. Ito, T. Ishio, and K. Inoue, "Web-Service for Finding Cloned Files using b-Bit Minwise Hashing", IWSC 2017 [3] Blackburn, S. M., Garner, R., Hoffman, C., Khan, A. M., McKinley, K. S., Bentzur, R., Diwan, A., Feinberg, D., Frampton, D., Guyer, S. Z., Hirzel, M., Hosking, A., Jump, M., Lee, H., Moss, J. E. B., Phansalkar, A., Stefanovic, D., VanDrunen, T., von Dincklage, D., and Wiedermann, B. The DaCapo Benchmarks: Java Benchmarking Development and Analysis, OOPSLA '06: Proceedings of the 21st annual ACM SIGPLAN conference on Object-Oriented Programing, Systems, Languages, and Applications, (Portland, OR, USA, October 22-26, 2006) 次に行った評価実験について説明します． 一つ目の評価では，定性的な評価として井上研究室で開発中のWebアプリケーション[3]のデバッグへの利用を行いました． 二つ目の評価では，定量的な評価としてDaCapo Benchmarks[4]を用いた性能計測を行いました．

評価1： Webアプリケーションの デバッグへの利用 利用者の使い方 Tomcat 上で動作する Servlet に常駐させて利用した 実行性能の低下要因として疑われた処理の実行回数と 実行時間の計測 利用者から報告された利便性 長期間実行が続いている間ログ出力を止めておける ログがサーバのディスク容量に影響を与えない サーバにアプリケーションを再設置する手間がない ログを記録する命令をソースコードに書き加える必要がなかった 評価1のWebアプリケーションのデバッグについて説明します． 利用者はTomcat 上で動作する Servlet に常駐させて本ツールを利用しました．そして，実行性能の低下要因として疑われた処理の実行回数とその実行時間の計測を行いました， その結果，利用者からいくつか利便性が報告されました． まず，長期間実行が続いている間ログ出力を止めておける点です．本手法と類似する手法としてロギングを行った場合は，ログがサーバのディスク容量に影響を与える傾向にあります． それに対して本手法では，Logのオンオフを切り替えられるコマンドがあり，うまく利用すればログがサーバのディスク容量に影響を与えないことが出来ます． また，すでに実行中のプログラムに対して引数として渡すだけで再実行できるので，ログを記録する命令をソースコードに書き加える場合と比べ，サーバにアプリケーションを再設置する手間がないという点も利便性として報告されました．

評価2：性能計測 評価2-1： DaCapo Benchmarks を用いて 通常実行時と，デバッグツール使用時の 実行時間を比較し，オーバーヘッド を計測 評価2-2： 出力にかかる時間のオーバーヘッドを計測 それぞれ10回ずつ実行し，通常実行時に対する デバッグツール使用時のオーバーヘッド O の計測を実施 次に性能計測について説明します． 評価2-1では，DaCapo Benchmarksを用いて通常実行時とデバッグツール使用時の実行時間を比較し，オーバーヘッド を計測しました． この際ブレークポイントは設置せず出力も行わないものとし，単純にツールを用いる事でのオーバーヘッドを計測しました． また，評価2-2 では，通常のJavaプログラムにおける出力と本プログラムにおける出力の時間を比較しました． そして，それぞれ10回ずつ実行し，通常実行時に対するデバッグツール使用時のオーバーヘッド O の計測を実施しました．

評価2-1: DaCapo Benchmarksを 用いた性能計測 ベンチマーク名 オーバーヘッド avrora 2% batik 3% fop 1% h2 jython 4% luindex 6% lusearch 15% pmd sunflow 24% tradebeans tradesoap 8% xalan 18% 平均7.4％，最大24%のオーバーヘッドで実行することが出来た JVM TI の設定により性能に大きな影響が出ることを確認 オーバーヘッドが大きな値になったものの原因は，JVMTIの設定によるものと考えられます． サーバアプリケーションならばこの数字は許容範囲であると考えています．

評価2-2:出力時のオーバーヘッド 小規模なプログラムにログ出力命令を埋め込んだ ログ出力なしでの実行時間は高々2ms であった 10000回 20000回 30000回 40000回 50000回 Printf　 デバッグ時[ms] 314.7 651.5 1118.5 1538.8 1942.6 デバッガ 使用時[ms] 454.9 936.7 1415.2 1930.0 2432.9 オーバー ヘッド[%] 45% 44% 27% 25% 22% 小規模なプログラムにログ出力命令を埋め込んだ ログ出力なしでの実行時間は高々2ms であった 実行時間は出力回数に大きく依存しているため， 出力を制御すればオーバーヘッドはおさえられる Printfでログを書いた場合と ブレークポイントを実行し出力

まとめと今後の課題 ブレークポイントで実行を止めない低侵襲デバッガの試作を行った デバッガの有効性を二つの評価実験で確認した 今後の課題 1つ目の評価では，サーバ型プログラムに対して， 有効なデバッグを行うことを確認できた 2つ目の評価では，平均7.4％，最大24%の オーバーヘッドでデバッガを実行できることを確認できた 今後の課題 ログ出力に対してオーバーヘッドが小さくなるように 制御を行う 今後の課題としては．ログの出力の量を制御することでロギングよりも効率的な実行ログの収集を行うこと． そして，パスワードを用いたり，重要な情報にアクセスする際の権限を設定する等でセキュリティ面の強化を行うことが課題と考えられます．