netail.net

_ [Java] Soot の解析中に JVM がクラッシュすることがある ▲

Soot によるバイトコード解析を全力で（-Xmx4000M -Xss2000M，-include-all -whole-program -p cg.spark:all-reachable:true）動かしてると，JVM がいきなり EXCEPTION_STACK_OVERFLOW でクラッシュする症状が発生するようです．

エラーログには，使っている Sun の 64ビット Windows 用 JVM （Java Hotspot(TM) 64-Bit Server VM build 1.6.0_01-b06, mixed mode）が標準で動かしている parallel gc が gc failed を出したと書いてあったので，とりあえず -Xincgc オプションを付けて incremental gc を有効にしたら，クラッシュの症状は出なくなりました．

_ [近況] ７月北京行きの準備 ▲

early registration が既に締め切られているような時期ながら，ポジションペーパーが無事通ったので準備開始です．

毎度のことながら，会場もしくは近くのホテルが取れるかどうかが若干不安です．

_ [読書] Why Programs Fail を読んでみました ▲

delta debugging で有名な Andreas Zeller が書いている，デバッグに話題を絞った書籍です．個人的には，これのおかげで delta debugging の考え方をようやくちゃんと理解できたので，良い本だと思います．

この本は，ユーザから観測可能なプログラムの動作不良（failure）から，それが起こるときと起こらないときの差分（cause）を調べ，そして原因となっているコード（defect）を発見する手順について述べています．

failure に至るまでのプログラムの実行を時間-メモリ空間軸（プログラムの状態）平面ととらえて，ブレークポイント，ウォッチポイント，アサーション，プログラムスライシング，ダイナミックスライシング，異常データの検出，不変条件の推定，ロギングなどが，どこを調べるために役立つかを説明しています．

この本では，デバッグのプロセスを TRAFFIC (Track the problem / Reproduce the failure / Automate and simplify / Find infection origins / Focus on likely origins / Isolate the infection chain / Correct the defect) という７つのステップに分解し，これに沿った章構成になっています．各ステップについて，具体例を示しつつ，先ほど挙げたような各種手法のどれをどう使うと良いか，またその手法を実装したツール群を紹介しています．

ツール紹介などの一方で，ソフトウェア工学の論文へのポインタもいくらか入ってます．ソフトウェアの欠陥に関連した用語の定義もしっかりしており，delta debugging やスライシングなどの解析技術についても本文中で丁寧に解説されているので，研究テーマによっては，開始地点としてこの本を使うのも良いかな？と思ったりしています．

_ [近況] 自宅用のPCを発注 ▲

とりあえず Vista を載せてみることにしました．買った机が狭かったので拡張性はあきらめて Acer の小型ケースのやつをメモリ 2GB に拡張して使用することに．

これが届いたら Volume Deskbar の Vista 対応を少しまじめに考えます．

_ [Java][論文] コンストラクタは引数なしが使いやすい ▲

Jeffrey Stylos, Steven Clarke: Usability Implications of Requiring Parameters in Objects' Constructors. Proceedings of ICSE 2007, pp. 529-539 [IEEE site]

Brian Ellis, Jeffrey Stylos, Brad Myers: The Factory Pattern in API Design: A Usability Evaluation. Proceedings of ICSE 2007, pp.302-312 [IEEE site]

いわゆるクラスライブラリ，API の使いやすさを評価しようという人々による論文２本です．

前者のほうは，何らかの引数が必要なコンストラクタを使うコードと，そうでないコード（引数なしで new した後に setFoo などとしてパラメータを与えるもの）とでどちらが使いやすいのか（短時間で使えるか），という比較を行っていて，後者のほうは，Abstract Factory って本当に分かりやすいのか，というのを調べています．

開発者は，コードを書くときに，とりあえずデフォルトコンストラクタの存在を仮定して new しようとし，コンパイルエラーが起きたのを見てから色々調べ始める，というパターンが多かったようです．なので，パラメータが必須なコンストラクタしかないクラスを使うのには，デフォルトで動くクラスを使う場合よりも時間がかかっています．

パラメータが必須ではない（デフォルト値つき）コンストラクタの場合は，与えるべきパラメータの組み合わせを理解することができ，それなりに便利なようです．

インタビューの結果によれば，実験対象となった開発者たちは，new してから setter を呼び出すほうが初期化の柔軟性が高くてうれしい，また，プロパティの値をセットしていく途中で適切なエラーコードを返せる（コンストラクタだと例外を投げるしかない）ことも良い，と答えていたようです．

Abstract Factory の場合は，コンストラクタを呼ぼうとする → コンストラクタが protected だからエラー発生 → 「サブクラスのために protected で用意してるよ」という決まり文句のコメントを見てサブクラスを探索 → でも見つからない → ようやくファクトリメソッドの存在に気づく というようなパターンにはまって時間を消費する場合があるようです．普通のコンストラクタで対応できるときはそうすべきだ（意味なく Abstract Factory パターンを導入すべきではない），と指摘しています．

_ [ツール] 使っている Soot のバージョンを上げてみました ▲

この前リリースされた 2.2.4 に移行してみました．ラベルの付与や一時変数の代入文など，どうも生成される Jimple コードが前と少し変っているみたいです．

Vista 64ビット版の JDK 1.6 上で新しいバージョンの soot を使って，メモリをとりあえず 4GB 渡してみたら（今までは 2GB），Java スライシングツールは40分かかってた PDG 構築を15分で終了しました．CPU自体の性能には極端な変化があるとは思えないので，ガベージコレクションが減った分が大きいのかもしれません．

_ [論文] 開発者はドキュメントは読んでない ▲

LaToza, T. D., Venolia, G. and DeLine, R.: Maintaining Mental Models: A Study of Developer Work Habits. Proceedings of the 28th International Conference on Software Engineering (ICSE 2006), pp.492-501, Shanghai, China, May 2006. [ACM site]

開発者の作業時間の割合を調査した論文で，納期が近づくにつれて新機能を書く時間よりバグフィクスにかかる時間のほうが増えているとか，作業に割り込みがかかると，元の作業に復帰するまでには時間がかかるといった知見を得ています．

プログラム理解に使っている時間とコードを書いてる時間には負の相関があり，開発者は，自分が書いたコードについては十分な知識を持っているからプログラム理解には時間を消費してはいないようだとしています．

設計ドキュメントはいちおう書くものの，書いたものを読み返すことはまれであり，実際には自分が相手にしているコードを読んで知識を再発見している（そしてドキュメントは陳腐化していく）としています．

D. Spinellis の Code Quality (Addison-Wesley)の 7.2 Analyzability でも「コメントはアップデートするべきだが，他人がそうしてることを期待してはいけない」と言及されていたりするのですが，ドキュメントをきちんと更新しないから読まないのか，読まれないからどうせ更新しないのか，因果関係は謎です．ただ，こういうのを読んでると，「ソースがドキュメントだ」という発言にはそれなりに説得力がある気がしてきます．