107

限られた保存領域を使用する Java プログラムの実行トレース記録手法
嶋利 一真 石尾 隆

井上 克郎

本研究では，ソフトウェアの内部状態の分析を行うための，限られた保存領域を効率的に使用する実行トレースの記録手法を提案する．提案手法はプログラムの各命令が使用したデータの最新の系列を，命令ごとに一定個数記録するような領域を個別に作成する．命令ごとの記録個数を調整することで，開発者が保有する保存領域に応じた実行トレースの記録が可能となる．

In this paper, we propose a method to collect an execution trace to analyze the internal states of softwarewith a planned amount of storage. The method uses separated data buﬀers to record the actual values usedby individual instructions. Changing the buﬀer size of each instruction, the method can record an execution
trace using a limited size storage.

ギングによって記録されるのは開発時点で選定され1 まえがきたデータのみであり，実際のデバッグにあたって必要デバッグとは，外部から観察できるソフトウェア障な変数の値がログに含まれていない場合も多い [12]．

害の症状から，その原因となるソースコード内の欠陥デバッグの効率的な実施を可能とするためには，プロを突き止める活動である [13]．効果的なデバッグの実グラムの実行を網羅的に観測，記録する手法が必要で施において重要となるのが，ソースコード中に書かある．

れた命令の実行順序や変数の値の観測である [10]．特デバッグに必要となる変数の値を自動的に，かつ網に，障害が発生する場合としない場合のソフトウェア羅的に収集する方法の 1 つとして，プログラムの実の実行を観測し，実行中の様々な時点で条件分岐や変行中のメモリ状態を時系列で完全に記録する Omni-数の値にどのような違いがあるかを調査することがscient Debugging [7] が提案されている．しかし，こ有効である [2] [5]．のアプローチは Java プログラムを対象にした場合開発者がソフトウェアの実行の様子を観測する手で，実行 1 秒あたり 10 MB 程度の実行トレースデー段として，ソフトウェアの処理の進行状況を示すメッタの記録を必要とする [9]．また，実行トレース全体セージや重要なデータをプログラムの外部に出力するの大きさは，解析対象となるソフトウェアの規模や実ロギング処理が広く用いられている [6]．しかし，ロ行する機能の種類によって大きく異なる [3]．そのたAn execution trace recording method using a limited
size storage for Java.
Kazumasa Shimari, Katsuro Inoue, 大阪大学大学院情報科学研究科, Graduate School of Information Scienceand Technology, Osaka University.
Takashi Ishio, 奈良先端科学技術大学院大学先端科学技術研究科, Graduate School of Science and Technology,
Nara Institute of Science and Technology.
コンピュータソフトウェア, Vol.36, No.4 (2019),pp.107–113.
[研究論文 (レター)] 2018 年 11 月 06 日受付.

め，開発者が現在直面しているバグに対して手法の適用が可能であるのか判断することが難しい．
本研究は，実行トレース記録に使用される保存領域の大きさを開発者が制御可能とし，かつ，デバッグに必要となる命令の実行順序や変数の値を可能な限り網羅的に収集する方法として，プログラムにおける各命令が使用したデータをそれぞれ最新 k 回だけ保存する実行トレース記録手法を提案する．通常の実行108

コンピュータソフトウェア

トレースには，重要な機能を持たないユーティリティ行トレースを保存した後，他の解析を行う前にフィル関数の実行の繰り返しなどが含まれる [3]．本研究でタリングを行うことを前提とした分析を行っていた．

はそのような繰り返し実行される命令について記録

本研究では，繰り返しのデータの除去を，プログラムするデータ量に上限を設けることで，限られた保存領の実行中に行うことを提案している．

域でプログラム全体の変数情報を記録する．具体的にHirzel ら [4] は，実行トレースの効果的なサンプリ

は，観測対象の命令ごとに大きさ k のバッファを個ング方法として，データの観測を行う実行区間，行わ別に準備し，実行回数が k より少ない命令に対するない実行区間を切り替える Bursty Tracing 手法を提観測値はすべて保存し，それを超えて実行された命令案した．この方式は，観測頻度を均等に低くする通常に関しては最新 k 回分の観測値のみを保持する．観のサンプリングよりも，プログラムの実行経路につい測範囲となるプログラムを構成する命令の数を実行て多くの情報を取得することが可能である．しかし，前に数え挙げておくことで，開発者が保有する保存領サンプリングで得られるデータはプロファイリング対域に応じて k の値を設定し，実行トレースを記録す象に大きく依存しており，デバッグに必要なデータをることが可能となる．

収集できない可能性もあるほか，収集するデータ量の上限をプログラムの実行前に設定することはできな

2 関連研究いという制約もある．

2. 1 実行トレースの削減手法
プログラムの実行トレースのデータ量がソースコー

2. 2 低オーバーヘッドの動的解析ド等と比べて大きくなる要因の 1 つは，プログラム実行トレースの収集には一定のコストがかかるたが繰り返し同じ命令を実行することにある．実行ト

め，特定の解析目的に対して，実行時間あるいは解析レースを削減するために，繰り返しの実行が互いに類に伴うデータ量を最小限にするような解析技術が提似している，あるいは重要度が低いと仮定した，デー案されている．たとえば Liu ら [8] は，バッファオー

タ圧縮やサンプリングの適用が提案されている．

バーフローやメモリリークなどの欠陥検出を目的とWang ら [11] は，プログラムがアクセスしたメモして，通常は軽量なメモリ監視を実行し，疑わしい挙

リアドレスの系列からなる実行トレースを，データ動に対して詳細情報の収集を行う解析手法を提案し圧縮によって効果的に保存する方式を提案している．ている．Zhang ら [14] は動的にデータ依存関係解析

プログラムの多くは繰り返し同じ命令を実行するが，を実行するにあたって，プログラムの実行トレースをそれらの命令の多くが配列等の連続的なデータに対そのまま保存するのではなく，実行中にプログラムスする同一の操作になることから，差分エンコーディン

ライスに変換しメモリに保持することで，記録量を大グが高い圧縮率を達成できることを示した．しかし，幅に削減できることを示している．これらの手法は，この手法で記録可能なのはデータ依存関係と呼ばれそれぞれ，実行に伴うオーバーヘッドを削減するが，るデータの流れのみであり，本研究のような変数の具本研究が対象としているような命令の実行順序や具体的な値の記録にはそのまま適用できない．また，圧体的な変数の値の取得という目的とは異なる．

縮後のデータの大きさがソフトウェアに依存するという課題も残されている．

3 提案手法

Cornelissen ら [3] は，メソッド呼び出しの系列から本研究は，Java バイトコードの命令ごとに最新 kなる実行トレースに対して，実際に使用できるデータ回の実行に関する具体的なデータ値を記録する手法

量の目標値が設定された場合，重要な機能を持たないを提案する．最新の実行を残すことで，プログラムのユーティリティ関数の呼び出しの繰り返しを除去する

クラッシュなどが生じた場合には，異常な動作の値がことが，単純なサンプリングよりも情報量を保つ傾向記録として残る可能性が高い．一方で，プログラムのにあることを報告した．一方で，この研究は完全な実実行開始時などに一度だけ実行されるような処理もVol. 36 No. 4 Nov. 2019109

破棄されないため，プログラム実行時の環境設定などの確認も可能である．

3. 1 実行トレースのモデル
本研究で取り扱う実行時情報は，Omniscient De-

経過時間void methodA (int var) { 1var = methodB(var);2while (var > 0)
357var = methodC(var);
64System.out.println(var);
8}9時系列による記録

bugging の実装の 1 つである松村らの手法 [15] に基づくものである．この手法は，Java プログラムの任

図1

1 提案手法に2 よる記録76894 5 6 7 8 9提案手法による記録イメージ

意の時点での挙動を確認するために，メソッドの境界を超えて受け渡されたすべてのデータの値を Java バ録するというものである．プログラムの実行中に，観イトコードの命令単位で記録する．具体的には，メ測地点 p ごとに長さ k のバッファを用意して，観測ソッド呼び出し命令の実行開始および完了，メソッド値と，実行全体での観測順序の情報を，メモリ内に保実行の開始および完了におけるすべての実引数・仮引持する．プログラムの終了時に，Java 仮想マシンの数・戻り値・例外の値，フィールドおよび配列の読みシャットダウンフック機構を利用して，蓄積したデー

書き命令の実行における対象オブジェクト，添え字，タをまとめて保存する．なお，従来研究，たとえば松読み書きされた値を記録する．ここで，オブジェクト

村ら [15] の実行トレースは，すべての観測値を時系列については，参照を区別するための ID 値を保存するで単純に保存することに相当する．

ものとする．また，引数や戻り値のないメソッドの呼提案手法の特徴を図 1 の例を用いて説明する．プび出しについては，呼び出しの開始や終了の発生をログラムの各行の右側にある 1 から 9 までの数字が，記録するために，それぞれ 1 個のデータを記録する．

ある 1 回の実行における命令の実行順序であり，実これらの値には，たとえばフィールドに書き込んだ値行トレースとして保存する観測値を表現しているととそこから読み出した値の組のように，冗長な情報もする．実行トレースの保存領域が限られている場合，含まれるが，複数のスレッドによる同時操作の発生可

一般的なサーバ等での時系列に基づくロギングであ

能性や，観測範囲外となるネイティブコードやライブれば，最新の観測値から順に保存領域の容量分だけラリからのアクセスの可能性も考慮して，それぞれ個記録するため，保存容量の大きさが 6 であれば，図 1別に記録を行う．ローカル変数の値は，メソッドの外の下側にあるように記録が行われる．それに対して，部から受け取ったデータから計算によって再現可能で提案手法は同じ容量を，図 1 の右側にあるように，6あるため，引数等を除くローカル変数の操作は記録し個の観測地点それぞれに対し，1 つの観測値を保存すない．

るために使用する．これにより，ループで繰り返し実本研究では，このような実行トレースを観測値の行された命令の観測値は最新の値を除いて破棄する系列として表現する．観測値はそれぞれ，観測地点ことになるが，プログラムの先頭部分などの実行回数の ID p，命令を実行したスレッドの ID t，観測されが少ない観測地点における情報を完全に保持する．

た値 v の 3 つ組 ⟨p, t, v⟩ として考える．観測地点は，プログラムが持つ観測地点の数 m はプログラムデータ授受を引き起こした Java バイトコードの命令の Java バイトコードから静的に数え挙げができるたとデータの種別を識別する．1 つの命令でも，たとえめ，実行トレースの保存に必要な保存領域の大きさば引数と戻り値という異なる値が観測されるものでN = k × m を事前に知ることができる．Java では動あれば，それぞれ異なる観測地点とみなす．

的にバイトコードを生成する技術も利用されているが，通常の利用であればプログラム中の大きな割合を3. 2 実行トレースの記録方法占めることはなく，m に余裕を持たせた見積もり値

提案手法は，観測地点 p が同一であるような観測の設定が可能であると考えている．

値は最新の k 個だけを残すように実行トレースを記コンピュータソフトウェア

110
表1avrorabatik
fop
jythonluindexlusearch

クラス
527
1,122
1,198
2,244
231
199

ベンチマークプログラムおよび実行トレースの規模

メソッド
3,456
9,163
10,401
23,342
2,467
2,140

観測地点数
87,736
218,775
318,795
670,054
73,094
58,127

実行された観測地点数
38,772
72,630127,226
214,300
25,83816,256

観測値の総数
7,880,412,751
601,350,099
325,806,544
5,461,124,807
1,542,871,620
5,503,253,333

データ量
117.4 GB
9.0 GB
4.9 GB
81.4 GB
23.0 GB
82.0 GB

提案手法の実装は GitHub に公開されている †1 ．

り，事前にどのデータを必要とするか分からない状況

この実装では，Java プログラムがクラスをロードすでの有用性を評価する．後者は，実行トレースを系列る際にバイトコード変換を実行し，対象プログラムにとしてみたときに，データの流れに関する順序関係が対して観測地点 ID を割り当てながら，観測のための正しく保存されているかどうかを評価する．

命令を埋め込む．観測地点 ID およびスレッド ID の実行トレースの計測には，DaCapo Benchmarks [1]保存にそれぞれ 4 バイト，値の保存に 8 バイトを使用のバージョン 9.12-bach に収録された 14 個のベンチするため，1 つの観測値あたり 16 バイトの保存領域マークのうち，動作が確認できた 6 個を使用した．実を必要とする．実際にはプログラムの命令情報など，行トレースは，ベンチマーク内部での標準ライブラリ付加的な情報も出力するが，それらの量はプログラムへの呼び出し等を含んでいるが，Java 標準ライブラとしてロードされたクラスの数，バイトコード命令のリ内部の動作は記録していない．表 1 に，各ベンチ量にのみ依存して決まる．実行時には順序の保存のマークのプログラム規模と実行トレースの大きさをために 8 バイトのインデクスを同時に保存するため，示す．クラス数は，ベンチマークの実行のためにロー記録する観測値 1 つあたり 24 バイトのメモリと，そドされたクラスから，Java 標準ライブラリ（java,れらを管理する配列等を使用する．

javax, sun などのパッケージ名で識別されるもの）

文字列データに関しては，観測値として記録されたを除いた数である．メソッド数，観測地点数は，それオブジェクトについて，一定の長さまでの固定長の記らのクラスに対して数え挙げた値であり，実行されな録と内容のハッシュ値の記録によって，一定の範囲でかったメソッド，命令に対応するものも含んでいる．

有用な情報を保存することが考えられる．ただし，プ観測値の総数は，完全な実行トレースを記録した場合ログラム中で使用される文字列の種類は多岐にわたの値であり，データ量は 1 観測値 16 バイトとして完るため，文字列の適切な保存方法は今後の課題とし，全な実行トレースを保存した場合の値である．

現在の実装では，文字列の内容に関しては可変長データを用いて完全に保存するようになっている．

提案手法のパラメータである k の値として16, 32, 64, 128, 256 を使用する．それぞれの k の値に対しての提案手法の記録データ量を図 2 に示す．図4 評価

中の ALL は，完全な実行トレースを保存した場合提案手法によって記録される実行トレースが，限らのデータ量である．提案手法は観測地点 1 つあたりれた保存領域でどれだけの情報を保存可能か，以下の16 バイトの観測値を k 個保持することから，観測地2 つの観点から評価する．

点数が最大の jython を k = 256 で実行した場合で，1. 観測値が完全に保存される観測地点の割合

観測地点数 670, 054 × 256 × 16 = 2.7 × 109 となり，2. データ依存関係が保存される割合

最大で約 2.6 GB の実行トレースを収集することに前者は開発者がランダムに観測地点を選んだ場合になるが，すべての観測地点が実行されるわけではない

その地点に関するデータがすべて揃っている確率であために，実際の値はそれよりも小さくなっている．提†1 https://github.com/takashi-ishio/selogger,
develop branch, commit 2519626.

案手法で k = 256 とした際の記録データ量は，完全な実行トレースを記録した場合と比較して平均で 1.0

Vol. 36 No. 4 Nov. 2019

巨大な実行トレースとなるようなプログラムの実行

1000000

記録量（MB）

111

avroraであっても，1%以下の限られたデータで，多くの文100000

batik

10000

fopについて完全な情報を参照することができる．これjythonに対して Latest-of-All は，約 10%の命令に関しての1000

luindexlusearch

100

みデータを保存しており，ほとんどの文に関しては，利用者は完全な観測値を参照できない．

101163264128
バッファサイズk256ALL4. 2 データ依存関係の正確さ
提案手法がデータの流れに関する順序関係を正しく

図2

提案手法の実行トレースのデータ量保存しているかどうかを評価するために，提案手法の実行トレースから算出したデータ依存関係を完全な実

avrora100.0%

観測地点の割合（%）

90.0%

batik

80.0%

ここでのデータ依存関係は，フィールドあるいは配列

fop

70.0%
60.0%

jython50.0%

luindex

40.0%
30.0%

lusearch

20.0%
10.0%
0.0%

16

32

64

128

バッファサイズk

図3

行トレースから算出したデータ依存関係と比較する．

256

Latest-per-Location(6ベンチマークの平均値)
Latest-of-All(6ベンチマークの平均値)

観測値が完全に保存される観測地点の割合（ヒープ領域）を経由してデータを受け渡す，代入命令と参照命令の組とする．なぜなら，これらは単純なメソッド呼び出しの系列やメソッド内部の静的解析からは得られないためである．フィールドに関しては，代入命令 d がオブジェクト obj のフィールド f に対して値 v を書き込んだ後，その値が上書きされることなく参照命令 u で読みだされたとき，つまり u が%以下である．

オブジェクト obj のフィールド f から値 v を読みだ使用できる保存領域が制限された環境での性能したときに，d から u へのデータ依存関係が存在すのベースラインとして，時系列に基づく方式，すると考える．配列に関しても同様に，読み書きされた

なわち実行トレース全体における最新 N 個の観

添え字をフィールド f のかわりに用いて，個々の要測値を保存する方法を用いる．以降，提案手法を素を区別したデータ依存関係を抽出する．書き込んだ

Latest-per-Location，ベースラインとなるこの方式

値と読み込んだ値を比較することで，代入命令の実行を Latest-of-All と記載して区別する．

が記録されなかった場合や，実行の観測範囲外のコードから値の書き換えが行われた場合などに対応する．

4. 1 観測値が完全に保存される観測地点の割合

完全な実行トレースから求めたデータ依存関係の観測地点ごとに保存する観測値の個数 k を変化さ集合を正解として，Latest-per-Location と Latest-せたとき，それぞれのベンチマークで実行された観of-All の 2 手法で得られた実行トレースから得られ測地点のうち，完全なデータを保存できる（すなわるデータ依存関係の適合率と再現率，F 値を求めた．

ち実行回数が k 以下である）観測地点の割合の変化

表 2 に，すべてのベンチマークから得られたデータを図 3 に示す．また，同図は Latest-per-Location，依存関係の和集合を用いて算出した結果を示す．

Latest-of-All の 2 手法における 6 つのベンチマークの値の平均も示している．

Latest-per-Location は，繰り返し実行されるデータ読み書き命令の実行の一部を記録しないため，それ提案手法である Latest-per-Location は，k = 16によるデータ依存関係の誤検出や欠落が発生する．特のときで 60%，k = 256 のときで 74%の命令に関しに，オブジェクトの状態遷移を表現するグローバル変て完全なデータを保存し，残る命令に関しては最新の数のように，多数の場所で，ある一定の範囲の値の代k 回のデータを保存する．したがって，従来手法では入，参照が行われるようなフィールドが，多数の誤検出コンピュータソフトウェア

112
表2k16
3264128256

提案手法によって得られるデータ依存関係の正確さ（全ベンチマークの合計）

正解の
依存関係
52,06152,06152,06152,06152,061

Latest-per-Location
依存関係
適合率
再現率
42,6030.914
0.748
45,1150.903
0.782
47,4720.892
0.813
49,8260.881
0.843
51,941
0.872
0.870

F値
0.823
0.838
0.851
0.861
0.871

依存関係
3,010
3,144
3,938
4,043
4,054

Latest-of-All
適合率
再現率
1.000
0.058
1.000
0.060
1.000
0.0761.000
0.078
1.000
0.078

F値
0.109
0.114
0.141
0.144
0.144と欠落の原因となる．たとえば，ベンチマーク avrora

行トレース記録手法を提案した．観測地点ごとに最新に含まれる avrora.arch.legacy.LegacyInterpreter クk 個の観測値を保持することで，完全な実行トレース

ラスは，与えられたプログラムを実行するインタプの 1%程度のデータ記録量でも，60%から 74%の観測リタの実装であり，100 以上のメソッドがプログラム地点に対して完全な観測値を保持し，また，フィールカウンタに関するフィールド（pc, nextP C ）を繰り

ドや配列に関するデータ依存関係の多くを追跡可能返し操作していた．それぞれの代入，参照命令の実行である．

回数が多いことから，Latest-per-Location では命令

本研究の結果をもとに，開発者が多くの環境で常にの実行順序が十分に保存されず，多数のデータ依存関実行トレースを収集し続けられるようなデバッグ環係が欠落するとともに，同一の値を使用した異なる境を構築することが今後の課題である．また，デバッ命令の実行を誤ってデータ依存関係として検出する

グに適した適切な文字列データの記録方法の実現や，ことにつながった．ただし，このような誤検出の要因データ依存関係などをより高い精度で保存できるよは少数のフィールドに限られており，全体での適合率

うに静的解析を活用することも今後の課題として挙は 0.9 以上，再現率は 0.8 前後と，保存するデータげられる．

を 1%に抑えた状態でも高い数値を保つことが確認できた．一方で Latest-of-All は最新の実行トレースの謝辞 本研究は科研費 JP18H04094，JP18H03221，JP15H02683 の助成を得た．

みを保持するため，誤ったデータ依存関係が認識されることはないが，プログラム全体でみるとほとんどの参 考 文 献

データ依存関係を破棄してしまうため，プログラム全[ 1 ] Blackburn, S. M., Garner, R., Hoﬀman, 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., vonDincklage, D., and Wiedermann, B.: The DaCapo
Benchmarks: Java Benchmarking Development andAnalysis, Proc. of the 21st ACM SIGPLAN Conference on Object-Oriented Programming, Systems,Languages, and Applications, 2006, pp. 169–190.
[ 2 ] Cleve, H. and Zeller, A.: Locating Causes ofProgram Failures, Proc. of the 27th International
Conference on Software Engineering, ACM Press,2005.
[ 3 ] Cornelissen, B., Moonen, L., and Zaidman,
A.: An assessment methodology for trace reduction techniques, Proc. of the 24th IEEE International Conference on Software Maintenance, 2008,
pp. 107–116.
[ 4 ] Hirzel, M. and Chilimbi, T.: Bursty Tracing:
A Framework for Low-Overhead Temporal Profiling, Proc. of the 4th ACM Workshop on FeedbackDirected and Dynamic Optimization, 2001.

体の調査には不向きである．
表 3 は，k = 16 におけるベンチマークごとの詳細な結果である．k の値が変わってもベンチマークごとの傾向は変わらなかったため，他の k の値に関する結果は省略する．この結果から，どのベンチマー
クに関しても提案した実行トレースの削減手法が高い数値を示しており，Latest-per-Location が実行トレースの削減手法として有望であることが分かる．な
お，lusearch の適合率・F 値が N/A となったのは，Latest-of-All の手法ではフィールド・配列に関するデータ依存関係が得られなかったためである．

5 まとめと今後の課題
本研究では，ソフトウェアの詳細な内部状態の観測を行う手段として，使用する保存領域を制御可能な実Vol. 36 No. 4 Nov. 2019表3
ベンチマークavrorabatik
fopjythonluindexlusearch113

提案手法によって得られるデータ依存関係の正確さ（ベンチマーク別, k = 16）
正解の依存関係
4,325
7,054
13,906
20,4604,098
2,218

Latest-per-Location
依存関係
適合率
再現率
3,269
0.904
0.683
6,366
0.951
0.858
12,1430.968
0.845
15,3420.849
0.637
3,6990.952
0.859
1,784
0.915
0.736

[ 5 ] Johnson, N. M., Caballero, J., Chen, K. Z.,
McCamant, S., Poosankam, P., Reynaud, D., andSong, D.: Diﬀerential Slicing: Identifying Causal
Execution Diﬀerences for Security Applications,
Proc. of the 32nd IEEE Symposium on Security andPrivacy, Ieee, May 2011, pp. 347–362.
[ 6 ] Kabinna, S., Bezemer, C.-P., Shang, W., andHassan, A. E.: Logging Library Migrations: A Case
Study for the Apache Software Foundation Projects,
Proc. of the 13th International Conference on Mining Software Repositories, 2016, pp. 154–164.
[ 7 ] Lewis, B.: Debugging Backwards in Time,CoRR, cs.SE/0310016, 2003.
[ 8 ] Liu, T., Curtsinger, C., and Berger, E. D.:
DoubleTake: Fast and Precise Error Detection via
Evidence-based Dynamic Analysis, Proc. of the 38th
International Conference on Software Engineering,
2016, pp. 911–922.
[ 9 ] Pothier, G., Tanter, E., and Piquer, J.: Scalable Omniscient Debugging, Proc. of the 22nd
ACM SIGPLAN Conference on Object-Oriented
Programming Systems and Applications, 2007,
pp. 535–552.
[10] Spinellis, D.: Eﬀective Debugging: 66 SpecificWays to Debug Software and Systems, AddisonWesley Professional, 2016.
[11] Wang, T. and Roychoudhury, A.: Using Compressed Bytecode Traces for Slicing Java Programs,Proc. of the 26th International Conference on Software Engineering, 2004, pp. 512–521.
[12] Yuan, D., Zheng, J., Park, S., Zhou, Y., andSavage, S.: Improving Software Diagnosability via
Log Enhancement, ACM SIGARCH Computer Architecture News, Vol. 39, No. 1(2011), pp. 3–14.
[13] Zeller, A.: Why Programs Fail, Morgan Kaufmann, second edition, 2009.
[14] Zhang, X., Gupta, R., and Zhang, Y.: EﬃcientForward Computation of Dynamic Slices Using Reduced Ordered Binary Decision Diagrams, Proc. ofthe 26th International Conference on Software Engineering, 2004, pp. 502–511.
[15] 松村俊徳, 石尾隆, 鹿島悠, 井上克郎: REMViewer:
複数回実行された Java メソッドの実行経路可視化ツー
ル, コンピュータソフトウェア, Vol. 32, No. 3(2015),

F値
0.778
0.902
0.902
0.728
0.903
0.816

依存関係
28950
2,149137385
0Latest-of-All
適合率
再現率
1.000
0.067
1.000
0.007
1.000
0.155
1.000
0.007
1.000
0.094
N/A
0.000

F値
0.125
0.014
0.268
0.013
0.172
N/A

pp. 137–148.

嶋利一真2017 年大阪大学基礎工学部情報科学科卒業．現在，大阪大学大学院情報科学研究科博士前期課程 2 年．プロ
グラム解析に関する研究に従事．
石 尾 隆

2003 年大阪大学大学院基礎工学研究科博士前期課程修了．2006 年同大学
大学院情報科学研究科博士後期課程修了．同年日本学術振興会特別研究員（PD）．2007 年大阪大学大学院情報科学研究科助教．2017 年奈良先端科学技術大学院大学情報科学研究科准教授．2018 年奈良先端科学技術大学院大学先端科学技術研究科准教授．博士（情報科学）．プログ
ラム解析，プログラム理解に関する研究に従事．
井上克郎

1979 年大阪大学基礎工学部情報工学科卒業．1984 年同大学大学院博士課程修了．同年同大学基礎工学部助手．

1984〜1986 年ハワイ大学マノア校情報工学科助教授．1989 年大阪大学基礎工学部講師．

1991 年同助教授．1995 年同教授．2002 年大阪大学
大学院情報科学研究科教授．工学博士．ソフトウェア
工学，特に，ソフトウェア開発手法，プログラム解
析，再利用技術の研究に従事．