ソフトウェアリポジトリからバグ修正コミットを特定し，バグ修正で追加された行が修正対象ソフトウェア中や大規模なソースコードの集合の中に現れるか調べるツールです．
SoichiSumiがM1の研究で作成しました．
既存ソースコード行を用いた自動バグ修正手法において，どの程度のバグが修正可能か調査するため．
入力：Gitリポジトリ，課題情報，大規模なソースコードの集合
出力：バグ修正で追加される行のうちバグ修正前リビジョンのソースコードや大規模なソースコードの集合に現れるものの割合
本ツールは以下の4ステップで動作します．
- Step1 リポジトリの課題情報と大規模なソースコードの集合をデータベースに格納
- Step2 コミットコメントに含まれる課題番号と課題情報からバグ修正コミットを取得
- Step3 バグ修正コミットで追加されたソースコード行で追加されたソースコード行を取得
- Step4 追加された行のうちバグ修正前リビジョンのソースコードや大規模なソースコードの集合に現れるものの割合を出力
- 実験上必要なタスクごとにオブジェクトに分割し，再利用しやすい設計にしました
- 調査対象リポジトリは複数あり，各リポジトリに対する処理は並列化可能です．そのためリポジトリごとにスレッドを生成し，それぞれにStep1-4を行うことにより高速化しました
- DBの管理には，DBの移動が容易なためSQLiteを用いました
- 本ツールで最も時間がかかるのは追加されたソースコード行が大規模ソースコード中にあるかどうかDBから検索する部分です．この部分を高速化するため，文字列とそのハッシュ値をDBに格納し，ハッシュ値にインデックスを張りました．検索は文字列のハッシュ値を用いて行います
5つのOSS(バグ修正コミット:8000)に対して本ツールを適用しました． 並列化・インデックスを行わなかった場合は約10時間かかるのに比べて，並列化・インデックスを行うことにより，2時間30分まで実験時間を短縮することができました． また，プロファイリングを行ったところ，検索にほとんど時間がかからなくなったことが確認できました．残りのボトルネックはソースコードの差分をとる処理やコメント文の除去処理でした． プロファイリングにはjvmmonitorを用いました．
http://www.fastpic.jp/viewer.php?file=3006110561.png