«前月 最新 翌月» 追記

netail.net

自作フリーソフトや,ゲームに関する雑記を公開してます.
日記はソフトウェア工学の論文ネタが中心です.

最近のお知らせ (古いものはこちら)


2004-10-01 古い日記からの変換データ [長年日記]

_ [work]動的解析のスケーラビリティ

AspectJ プログラムの実行時情報を集計するツールを再構築中.Ruby スクリプトでプロファイル結果→イベント列→集計情報→頂点集約→DOTという段階を踏んで Strategy パターンを適用していくインフラっぽいスクリプトを構築してみた.

生成された DOT ファイルを Graphviz のコマンドでコンパイルするところまでは自動化.コマンドは次の通り.

dot -Tsvg -o outputfile inputfile
で,とりあえずメソッド呼び出し関係とメソッド間のデータ依存関係(1個以上の引数を渡しているメソッド呼び出し,void 以外の戻り値,フィールド経由のデータ依存関係)を抽出するするスクリプトを作って動かしてみた.

800行のコードの実行履歴が4MB程度で,データ依存関係は10万くらいの辺数.さすが生データというべきか.効率の良いフィルタを作らないことには何とも使い物にならない.動的スライスの実装とかしている人たちはどうやって実装してたのだろう…….


2004-10-02 古い日記からの変換データ [長年日記]

_ [日記CGI]検索性能の改善

検索処理が妙に遅いので調べてみたら,本文 C (UTF-8) と与えられたキーワード K (EUC) のマッチ処理でUTFtoEUC(C) と K を比較していたことが判明.データを UTF に移行したときの応急処置がそのまま生きていたらしい.

C と EUCtoUTF(K) を比較するように修正したので,性能はだいぶ改善した.

_ oucc.org.uk

たまたまサイト見つけた.Oxford University Cave Club.略称は同じだが….http://www.oucc.org.uk


2004-10-04 古い日記からの変換データ [長年日記]

_ [論文][work]モデルベースでのアスペクトの競合の検出

Francis Tessier, Mourad Badri, Linda Badri:A Model-Based Detection of Conflicts BetweenCrosscutting Concerns: Towards a Formal Approach.Workshop on Aspect-Oriented Software Development 2004.

アスペクトの導入が問題を起こさないかどうか(アスペクト同士が競合しないかどうかなど)を早い段階で(モデルを作ったあたりで)検出しましょう,というもの.

基本的なアイディアとして,アスペクト同士が・同じクラスに作用するが Join Point が異なる→OK・同じクラス,同じ Join Point に作用する→危険 -- アドバイスのタイプ(before/after)が同じ場合は高リスク -- 引数が同じ場合もリスクがある・異なるクラスにしか作用しない,共通部分がない →OKといった感じの分類をして,警告を出しましょうというもの.

この情報は静的解析なので,これをベースに動的解析したりとか,他の手法と組み合わせることも考えているよう.

アプローチとしてはそれなりに単純で分かりやすい.もしソースコード上から解析するのであれば静的に Join Point の共通部分とかをテストするのが(Cflow などを含む場合は)難しそうな気はするが.

モデル記述でテストする場合,モデルの記述に必要なコストがそれなりに低くてモデルとコードの対応付けがきちんとできるのならそれなりに有用そうではある.

ただ,「競合してるかもー」と警告を出すのは簡単だけど,開発者がシステム全体で一貫した解決方法を使っているかとか,その解決方法が正しそうかどうかとかをいかに確認するかも問題になってくるだろうから,その辺で議論できたら面白そう.

_ [論文]合成可能なメタオブジェクトの記述

Philippe Mulet, Jacques Malenfant, Pierre Cointe: Towards a Methodology for Explicit Composition of Metaobjects.Proceedings of the 10th annual Conference on Object-Oriented Programming Systems, Languages, and Applications(OOPSLA95), pp.316-330, Austin, Texas, United States, 1995.

メタオブジェクトを複数使う場合の問題を解決しましょうという論文.複数のメタオブジェクトは,順番に連結されるものとすると,Trace→Delegate→(Basic) というように順番が決まる.

メソッドの呼び出し・実行を Lookup + Apply ととらえて,メタオブジェクトはそれぞれ自分の Lookup を実装するが,このときに連結先のメタオブジェクトの Lookup を利用して,Lookup 処理や,追加の処理(Delegationなど)を実装する.

メタオブジェクト間の関係の取り扱いにはSpecialization と Aggreagation の二つを考えていて,親メタオブジェクトの Self 参照が自分自身を指すか親メタオブジェクトを指すかを選択する.

Lookup が起きると,連結されたメタオブジェクトの中でメッセージを読み替えや Lookup の連鎖などが起こって,最終的に実際のオブジェクトの動作が決まる.

このアプローチでは,メタオブジェクトは,自分自身が,連結相手に対してどのように振舞うかを記述する.汎用的な Mix-in が書ける人ならちゃんと書けそう.Composition Filter では結合演算自体は外部で定義されて通常はフィルタ生成順序などで implicit に扱われる点が異なる.


2004-10-05 古い日記からの変換データ [長年日記]

_ [Java]J2SE 5.0 (JDK1.5)

J2SE 5.0 をインストールしてみた.今までは C:/ 直下にディレクトリを作っていたのに,なんと Program Files 以下にインストールされる.とても大きな進化.

_ [論文]アーキテクチャレベルでの情報可視化

Mohlalefi Sefika, Aamod Sane and Roy H. Campbell:Architecture-Oriented Visualization.Proceedings of OOPSLA96, pp.389-405, CA, USA.

情報をまとめて抽象化して提示するのが大事ですよと主張する論文.メソッド単位,クラス単位ではなくサブシステム単位などで情報を集計した結果を出すためにInstrument という名前の観測ツールをCompositeパターンで合成して使うらしい.どのクラスがどのサブシステムに対応するかは開発者が与えないといけないので手間はそれなりにかかる.

_ [論文]オブジェクトの探索

Raimondas Lencevicius, Urs Holzle, Ambuj K. Singh:Query-Based Debugging of Object-Oriented Programs.Proceedings of OOPSLA97, pp.304-317, Atlanta, GA, USA.(注: Holzle の o はウムラウトつき)

デバッグ時にオブジェクトの情報を参照したいけど普通のデバッガだと特定のインスタンスしか見れないのでクエリーにマッチするようなオブジェクトのペア(というかtuple)を取り出してきましょうという話.

クエリーかけるのに a == b かどうかの判定ができないといけないとか,属性(フィールド)の参照に副作用があってはいけないとかいう条件は付くが,(a include b) and (c include b) and (a != c) のようにしてオブジェクト b を共有しているオブジェクト a, c のペアを見つけるとか,何か色々な使い方はできる,ということらしい.筆者たちの実装では,オブジェクト集合から該当オブジェクトを探すパフォーマンスもそれほど悪くない(1秒程度で結果が表示され始める)らしい.

いつクエリーを実行して,どうデバッグに使えるのかというところについての言及はあまりなかったりするが…….条件付ブレークポイントに比べてどのくらい便利なのか?というのがいまいち見えてこなかったりする.「あるクエリーにマッチするオブジェクトのメソッドが呼ばれたなら……」という条件付ブレークポイントなんかを作れば便利?

_ [work]動的解析の高速化

プロファイル結果→イベント列→集計情報→頂点集約→DOTという段階を踏んで処理を進めていくと,各頂点が集約対象かチェック→頂点に接続した辺を操作という処理が O(V*E): Vは頂点数,Eは辺数となってしまって遅くてたまらないことが判明.(辺のつなぎ替えが集合の操作なので実はさらに遅い…)

除去されることになる頂点については,それぞれ source(V) = {V に到達する依存関係の発生頂点の集合}という集合を記憶しておいて,{除去される頂点 V → 除去されない頂点 v }の依存関係が発生したらsource(V) の各頂点 → v の辺を生成するようにした.

こうすると,ログのサイズ n に比例する時間で処理が進むのでだいぶ高速になった.集合の管理の手間があるので,厳密に O(n) とは限らないが.

とはいえ,AspectJ のコードだと,AspectJ がいっぱい依存関係を追加で生成しているようでデータ依存関係が分かりやすいとは到底いえないみたい.


2004-10-06 古い日記からの変換データ [長年日記]

_ [AspectJ]wiki

Wikiへの移行完了(アスペクト指向な wiki).変更点としては・文章の構造化・重複した記述の排除といったところ.


2004-10-07 古い日記からの変換データ [長年日記]

_ [論文]Fan-Inベースのアスペクト抽出

Marius Marin, Arie van Deursen, Leon Moonen:Identifying Aspects using Fan-In Analysis.WCRE 2004, to appear.

各メソッドがいくつのメソッドから呼ばれているかをあらわすFan-In の数値でクラスをランキングして,上位のもののうち,Setter/Getter/Utility クラスを除去した結果がアスペクトの候補としてよさそう,という論文.

Setter/Getter は基本的にシグネチャベースでフィルタしていて,いちおう実装も少しはチェックしているらしい.Utility としては toString などのメソッド名フィルタと,*Utils のようなクラス名ベースのフィルタを使っている.このあたり,少し経験的な手法ではある.

ロギングなどのあちこちにコーディングされた「大きなfootprintを持つ」アスペクトに対しては有効だが,デザインパターンの個別の実装みたいに小さなfootprintのものは見つけられなかったりする.

シンプルなわりには効いているという気はする.false positive も negative も出てくるが,コードクローン分析と組み合わせたりして使おうと考えているみたい.

_ [論文]インタフェース実装のアスペクトへの移行

Paolo Tonella, Mariano Ceccato:Migrating Interface Implementations to Aspects.Proceedings of ICSM2004, pp.220-229.

スライシングのセッションと重なってたのでチェックしないままになっていた論文.

Java で使われる *able インタフェース,呼び出し関係でグループ化したら同じクラスの他のメソッドと一緒には使われないもの,同じクラスの他のメソッドから呼ばれていないので分離しても問題ないもの,などをアスペクトとして分離してみたという話.

Java における「アスペクトっぽいもの」を重点的に取り出してみたら,実は java.util や java.awt などにたくさんその手のクラスが含まれていて,それらをアスペクトに分離するとコード行数で約10%,クラス図上での依存辺の数にして約36%減少した,とかいった実験.

呼び出し関係グラフを作ったときに同じクラス中にあるメソッドなのに同一のクラスタには含まれないものがある,というのが面白いところ.評価としてもクラス間の依存関係なんかを使っているのは今までの単なる行ベースの方法より好感が持てる.


2004-10-08 古い日記からの変換データ [長年日記]

_ [読書]プロフェッショナリズムの覚醒

倉重英樹「プロフェッショナリズムの覚醒」(ダイヤモンド社)読了.経営の話がメインな本で,さっくり読める分量だった.役立つかどうかはともかく :-)

_ [AspectJ]Wiki

・カウンタの設置

・AOPの説明に授業で使ったスライドの内容を反映

・Fragile Base Code Problemなどいくつか更新.

Wikiへの移行前より微妙にアクセス数が増えてる.


2004-10-09 古い日記からの変換データ [長年日記]

_ カメラ

部室にカメラを設置してみた.15分間隔で画像を撮影して,1MB/h で画像ファイルを生成する.カメラと新しいLANケーブルなどを買ったので微妙に出費.

アクセス方法は部員専用Wikiに掲載しておく.


2004-10-11 古い日記からの変換データ [長年日記]

_ [hyCalendar]0.9.0 リリース

スクリーンショットの撮りなおしとヘルプの更新が終わったので0.9.0としてリリース.

プログラムのどのGUIが変わったかでヘルプのどこを更新すればいいかという影響波及解析とかできないものか.ヘルプの保守というのが意外と難しい.

_ [hyCalendar]0.9向け機能追加

今のところ機能強化は次の通り.拡大率設定の保存情報が変わった(移行できない)ので0.9 にしてしまうことにした.

・検索ボタン「前へ移動」を追加

・期間予定の設定に「開始日からN日」設定を追加

・縦横別々での拡大率設定を追加.これに伴って「50〜300%」の拡大率を廃止.

・月曜始まり表示にしたとき,期間予定のカレンダー,表示セレクトカレンダーが月曜スタートになるように設定.


2004-10-12 古い日記からの変換データ [長年日記]

_ すだち

人からすだちをもらったので,果汁をしぼって蜂蜜を混ぜてお湯にといて飲む.けっこう蜂蜜を入れないと酸味が強い.レモンに近いといえば近いのだけど,レモンティーのかわりになるのかな?風味が違うから合わないのかな?

_ AOM Workshop

The 5th Aspect-Oriented Modeling WorkshopIn Conjunction with UML 2004 http://www.cs.iit.edu/~oaldawud/AOM/

Models for Non-functional Aspects of Component-Based Software (NfC'04) http://www.comquad.org/nfc04

が開催されたらしいので論文チェックなリストに追加.

_ [論文]モデルの保存

UML04 ワークショップの論文がダウンロードできる.http://uml04.ci.pwr.wroc.pl/Workshop-materials.pdf

Ragnhild Van Der Straeten:Formalizing Behaviour Preserving Dependencies in UML.Proceedings of UML04, pp.71-82.

モデルの変更前と後で何を保存しているかというのを定義しましょうという話.アクセスする属性,更新する属性が同じかどうか,メソッド呼び出しでも,完全に同じメソッド呼び出し列なのか単に到達可能なだけなのか,とかを決めておいて,Dependency relation のメタクラスをサブクラス化してOCL を関連付けることで,振る舞いの保存について制約を付けているらしい.

ちらっと見ただけなので怪しいが一貫性をチェックするツールを実装しましょうみたいな話の論文も出ているよう.MDDとかの関係で流行ってるの?

_ ナイトライダー

ナイトライダー シーズン1コンプリートボックスDVDが出るらしい.実は今まで出てなかったのに少しびっくり.amazonのページ

シーズン1だけで全話そろってるわけではないのでとりあえず見送り.


2004-10-14 古い日記からの変換データ [長年日記]

_ ESS2004

ESS2004の初日終了.MDDロボットチャレンジの企画とか,全体に参加人数が多かったりとわりと活気があるかも.

要求工学のセッションがかなりよさげだった.順序関係のグラフ表現から動的構造を抽出するというのは何かに使えるかな?使えないかな?

あとは,やっぱりアイディアはツールとして成果を人に見せられるのは重要そうだということくらい.さすがに売れるくらいの物を作ってる時間はないので作れる人と組むのがいいのかもしれないけれど.


2004-10-15 古い日記からの変換データ [長年日記]

_ ESS2004 2日目

無事終了して帰宅.クロージング後直帰してこの時間.やっぱりもう一晩泊まるような出張日程のほうが楽かも.

全体参加者が260人程度だったらしいので賑やかだった.アスペクト指向ソフトウェア開発のチュートリアルは40人程度.司会は初めてなので微妙に疲れた.発表よりは気楽だけど.

組み込み系のテスト工数の増大とかいう話は,今現在はカバレッジ向上くらいしかないような気がするけど組み込み系って電源OFF(バッテリ切れ)以外に初期化が存在しないのでパス数が発散しているようだし,アスペクトのテストも初期化タイミングはシステム開始時だけであとは状態遷移していくというので実は問題構造は似ているような似ていないような感じ.そのうち設計のパターンみたいにテストのパターンとかできるのかしら.

頭があまり働いてない気がするので後日整理してみることにする.


2004-10-16 古い日記からの変換データ [長年日記]

_ [OUCC]カメラ

部室に置いていたカメラを接続していたノートPCのACアダプタがリコール対象になっていたことが発覚したので,別のPCへ移行した.

LiveCapture2 が,FTPアップロードのパスワードを平文で保存していたことも発覚したので,ついでに,使用ツールもLiveCapture2 から ListCam へ変更した.

JPEG圧縮アルゴリズムの品質パラメータの差?から240KB/枚 → 80KB/枚 とデータ量が減少していたりと思わぬ副作用もあったりする.


2004-10-17 古い日記からの変換データ [長年日記]

_ [お出かけ]コーヒー博物館

神戸ポートアイランドにあるUCCのコーヒー博物館まで出かける.1階にある喫茶店が,トルコ風コーヒーなど変わったものも扱っていて面白い.


2004-10-19 古い日記からの変換データ [長年日記]

_ [work]Dominatorの検出

バイトコードの制御フローグラフ上で,条件分岐の結果がいつまで有効だといえるかをPostDominator(どちらに分岐しても必ず通過する最初の頂点)で判定するために,PostDominatorの計算を実装してみた.

アルゴリズムは悩んだが,実装が単純な繰り返し計算方法Keith D. Cooper, Timothy J. Harvey, Ken Kennedy:A Simple, Fast Dominance Algorithm.に掲載のものを使ってみた.文献自体はSoftware Practice and Experience にSubmitted となっているもの(Acceptedではないらしい).これ自体はDominantの計算なので,PostDominantを判定するために依存関係のたどり方だけ逆向きにして適用してみた.

パフォーマンス的には最適化の余地はあるのだが,とりあえず単純な実装で動作試験にはいちおう成功しているみたい.

_ [Java]Eclipse 3.1M2

新しく作るツールでは Java Generics が使いたいので,Eclipse のいちおう Generics 対応版である 3.1M2 を導入.

設定ダイアログの Compliance Level でソースコード,生成バイトコードを 1.5 対応にする必要はあったが,いちおう Generics 対応コードがコンパイルできているみたい.


2004-10-20 古い日記からの変換データ [長年日記]

_ [work]Subversion

ツール開発の次のステップ(制御依存&データ依存解析)に進む前に色々リファクタリング作業が必要だとわかったので,作業用に Subversion を導入してみた.

今のところローカルのリポジトリで十分なので,TortoiseSVN とかいうツールをインストールして手元でリポジトリを作って実験してみることにする.

この手のバージョン管理ツールを使うのはVisual Source Safe 以来なので,操作がちょっと不安.自動バックアップツールと組み合わせて使ってみることにする.


2004-10-21 古い日記からの変換データ [長年日記]

_ [work]制御フロー解析

Java バイトコードのうち,Finally節を実装するために生成されるJSR〜RET (BASICで言うところのGOSUB〜RETURN)の処理を実装してみた.面倒だったのでとりあえずRETからすべてのJSR へ戻るようにしただけなのだが.

テストして気付いたのだが,Eclipse 3.1M2 のJava コンパイラは JSR-RET を使わない実装に変わっているのか,以前は生成されていた RET 命令が生成されなくなっていた.

ということで,今までテストデータにしていたもの(自分自身のクラスファイル)が使えなくなってしまった.新しいテストケースだけ,別に用意しないといけない.


2004-10-22 古い日記からの変換データ [長年日記]

_ [work]制御依存解析

フロー解析が終わったのでそれをベースに依存辺を引く作業を実装.さっくり動いた.

あとはデータ依存解析だが,ここでエイリアス問題が登場するので,ちょっとアルゴリズムを調べる作業に戻る.面倒なので,とりあえず考慮しないというのも手だが.


2004-10-23 古い日記からの変換データ [長年日記]

_ AspectBench

AspectJ の言語をサポートしたコンパイラの別の実装としてAspectBench 1.0.0 がリリース.パフォーマンスとかを重視しているらしい.http://aspectbench.org

フロントエンドの言語拡張,バックエンドの最適化にそれぞれなんかフレームワークを使っているらしい.AspectJ ベースで言語を少し実験するとかの材料になるかも?

Sable Research Group とかも絡んでると書いてるのでパーサが SableCC でできてたりするのだろうか.色々気になるところはあるツール.

_ [Java]バージョンID

Serializable なクラス(独自の例外クラス)を作ったら serialVersionUID を定義しなさいと警告が出てきた.

どうやら serialver とかいうツールで作れるらしい.

serialver -classpath クラスパス クラス名

単にメソッドとかのシグネチャから計算してるみたいだけど.リファクタリングとかしたらパッケージを移動すると値が変わってしまう(ソースコードを修正しないといけない)のかな?

_ [work]バイトコードのスタック変化

Java バイトコード上でのデータ依存関係を調べるのにスタックの変化情報が必要なのだが,BCELの org.apache.bcel.generic のパッケージサマリを見るとだいたいの情報が載っていることが判明.

抽象クラスで複数の命令の処理をまとめて書かないと,オブジェクトの種類による条件分岐がえらいことなりそうだが.

_ [論文]モデルの一貫性管理

Models for Non-functional Aspects of Component-Based Software (NfC'04) の論文を消化.

Francois Mekerke, Wolfgang Theurer, and Joel Champeau:Non-functional aspects management for craft-oriented design.利害関係者ごと(あるいは開発チームごとなど)に作成したモデルをいかに一貫性を保つかが問題となるが,そこで, Facet と Pivot という二つを使ってモデルを管理しようというもの.Facet は,システムの色々な側面を表現したもので,最終的にはプロダクトとなるもの.それぞれ,external (pivot から可視)なものとinternal (外部から不可視) なもので構成される.モデル自体は,それぞれの Facet ごとに独立な構築になるみたい.で,Pivot というのが連携用の道具で,各 Facet の external な要素間での結合として,データの流れや,成立する不変条件を記述する.

Pivot を先に作って,Facet がそれぞれ何を提供すればいいか明示してから Facet を個別に定義していくような感じなのか.

_ [論文]アスペクト指向なモデリング

Aspect-Oriented Modeling Workshop の論文のうち興味を引いたもの若干をメモ.

Shin Nakajima, Tetsuo Tamai:Lightweight Formal Analysis of Aspect-Oriented Models.Aspect-Oriented Modeling Workshop 2004.

各アスペクトは,ロール同士のインタラクションとしてアスペクトを複数使ったときに正しく動くかどうか,「複数使ったときにどう動くべきか(どう重なるか)」を書いてモデルを動かしてみてチェックしましょうということになるらしい.

Mark Mahoney, Atef Bader, Tzilla Elrad:Using Aspects to Abstract and Modularize Statecharts.Aspect-Oriented Modeling Workshop 2004.

複雑なシステムのステートチャートを作るとき,直交した状態は別々のステートチャートに分離しておいて,あるステートチャートのイベントが,他のステートチャートのどのイベントとして「解釈」しうるか,という定義を付加してステートチャート間の結合を整理しようという話.

あるステートチャートでのイベント発生に他のステートの遷移を設定するというのはAspectJ の before/after の考え方にも近い概念だ,と言っている.

ステートチャート間のイベント連動をどこに書くかというのが問題のような気はするが,それ以外はわりとシンプルな感じ.

Alexis Muller:Reusing functional aspects: from composition to parameterization.Aspect-Oriented Modeling Workshop 2004.

コンポーネントの再利用のためには,関連しあったクラス群をまとめてビューとして扱うのがよい,ということでビューというのがどうあればよいか,メタモデルを定義している.

Subject-Oriented など従来のアプローチでは,再利用を狙ってシステムとは独立にモデルの設計などを行うときにシステムごとの名前の変化などが扱いづらいので,型やメソッド名のパラメータを使って制御するタイプの手法を使って作ったビューを適用していくのが良さそうだ,と言っている.


2004-10-25 古い日記からの変換データ [長年日記]

_ [Java][work]バイトコードのスタック操作情報

データ依存関係の解析のうちエイリアス解析を除いた部分をほぼ実装完了.

BCEL では StackProducer と StackConsumer というクラスが,各バイトコードごとのオペランドスタックの増加・消費値を教えてくれるので,実はそんなに実装は難しくなかったことが途中で判明.

ただし,例外が投げられたときだけ,例外の情報がスタックに詰まれるので,例外ハンドラや finally 節の実装部分だけはスタックの初期サイズが 0 でないとしてスタックの操作を見てやらないといけないらしい.


2004-10-26 古い日記からの変換データ [長年日記]

_ [work]例外ハンドラのデータ依存解析

OOPSLA 開催でまた論文リストが増えるぞっと思いながらコード書きが続く.

例外ハンドラ(catch ブロック,finally ブロック)へはどこから例外で移動してくるか分からないので,実はデータフローが決定できない.Checked Exception や Null Pointer Exception 系などは絞れないことはないのだが,あまり効果として嬉しくないので,とりあえず例外ハンドラの先頭(Handler Entry 仮頂点)ですべてのローカル変数を初期化したとみなしてデータ依存関係を整理することにした.

_ [Java]enum

enum 型が使いたくなったので Eclipse 3.1M2 で使えたのかなと思って試してみたら,まだ対応してなかった.Eclipse 3.1M2 のリリースノート

構文的には通るが型としては認識できないみたい.


2004-10-27 古い日記からの変換データ [長年日記]

_ [work]エイリアス解析の価値の謎

エイリアス識別付きのフィールド間データ依存関係の解析を実装しようとしてこける.エイリアス情報が変わるとデータフローが変わってデータフローが変わるとエイリアスの流れも変わるんでは….という疑問があるし,あまり効果的な解析方法がない.

Flow Sensitive にエイリアスを解析しようとするとメソッド呼び出し順序などが必要になってくるのだが,外部へのメソッド呼び出し時に何が起きるかは(多態性の都合で)決定できないので,外部からメソッド呼び出しを受ける可能性を考えると非現実的.

結局手抜きな実装としては,自分のメソッド内で作ったオブジェクトに対してだけ,外部から参照可能なフィールドに代入されるかメソッドの引数で外へ出て行くまでエイリアスを識別しておくということになるのだろうか.ここでも「外部から参照可能な」が曲者で,Java の private フィールドって自分自身の他のインスタンス(this.class.new したもの)からは参照できてしまう.

こうなると,ローカル変数に代入されているものだけが対象となるわけで,エイリアス解析で解決できる問題がすごく狭いような気がしてきた.

this と,それ以外(thisあるいは他のインスタンスを指す参照)はいちおう区別しておいたほうが良さそうに思えるが,それ以外の場面ではあまり真面目にエイリアス解析しないほうが幸せっぽい気がしてきた.


2004-10-28 古い日記からの変換データ [長年日記]

_ [work]過去の遺産

過去に作ったプログラムスライシングツールを使っていいですかというメールを ubc.ca の人からもらった.

Java のスライシングツールはないんだ,と言われたので調べてみたら,Code Surfer は実は C/C++ しか対応してなかったらしい.

2年も前に構築したツールなんでいい加減構造を忘れてたりして.現在作っているバイトコードの PDG 構築がうまくいったらプログラム解析部だけ差し替えて動いたらいいなぁ,と思う.

_ コメントスパム

初コメントスパム.手製スクリプトだから縁がないのかなーと思ってたのに.


2004-10-29 古い日記からの変換データ [長年日記]

_ [work]データ依存解析+エイリアス処理の実装

適当にエイリアス対応だけ実装.エイリアス区分は付けずに可能性を探索するだけだが.

とりあえず実行してもエラーは起きないので,テストケースの準備と,入出力の拡充作業に移る.