社団法人 子情報通信学会 THE INSTITUTE OF ELECTRONICS, INFORMATION AND COMMUNICATION ENGINEERS 信学技報 TECHNICAL REPORT OF IEICE オブジェクトの動的バージョン管理機能を持つ Java 仮想マシンのࠟ作 倉持 傑 杉山 安洋 日本大学大学院工学研究科 〒963-8642 福島県郡山市田村町徳定字中河原 1 日本大学工学 〒963-8642 福島県郡山市田村町徳定字中河原 1 E-mail: [email protected] [email protected] あらまし 実行中のソフトウェアを停止する事なく，機能のୈ加や変更を可能にするため，我々の研究室では， オブジェクトの動的バージョン管理機能について研究してきた．今回この動的バージョン管理機能を持った Java 仮想マシンをࠟ作した．本稿では，その概要と通常の Java 仮想マシンとの実行速度等の比Ԕを行う． キーワード バージョン管理，オブジェクト，Java 仮想マシン A Prototype of the Java Virtual Machine with the Dynamic Version Management Mechanism for Objects Suguru KURAMOCHI Yasuhiro SUGIYAMA Graduate School of Engineering, Nihon University Koriyama, Fukushima, 963-8642 Japan Department of Computer Science, College of Engineering, Nihon University E-mail: [email protected] Koriyama, Fukushima, 963-8642 Japan [email protected] Abstract We are developing a mechanism that allows software engineers to add and change the functionality of running software systems without stopping their execution. We developed a prototype of the Java virtual machine that includes the dynamic version management mechanism for objects. This paper will give a brief overview and the performance evaluation of the prototype system. Keyword version management，objects，Java virtual machine 1. は じ め に ことが多い．ؿ行のオンラインシステムや各種のサー ソフトウェアの開発作業においては，バグの修正 バシステムなどがその例である．しかし，ソフトウェ や機能のୈ加・変更などの理由により，多くのバージ アシステムの機能ୈ加や不良の修正のためのバージョ ョンのソースファイルが作成される．ソフトウェアの ンの入れ替え作業は，ソフトウェアを停止させて行わ リリース後も新しいバージョンをリリースするため開 れているのが現状である．そのようなバージョンの更 発は継続され，バージョンごとにソースファイルは増 新作業はソフトウェアを停止させないで行えることが え続けることとなる．しかし，多くのバージョンのソ 望ましい． ースファイルを管理することは容易ではない．そのた 我々の研究室では，ソフトウェアの実行中に，ソ め，ソースファイルのバージョン管理については古く フトウェア中のオブジェクトのバージョンを入れ替え から研究されており，数多くのバージョン管理用ツー ることにより，ソフトウェアの機能変更やバグ修正を ル が 開 発 さ れ て き た ． そ の 代 表 と し て RCS[1] や 行うための，オブジェクトの動的バージョン管理機能 SCCS[2]な ど の ツ ー ル が 挙 げ ら れ る ． こ れ ら の ツ ー ル [3]に つ い て 研 究 し て き た ． そ れ を Java ۗ ܃で 書 か れ は，ソースファイル単位でバージョン管理を行うもの た シ ス テ ム に 対 し て 実 現 す る た め の シ ス テ ム [4]が 開 であり，バージョン履歴の保存，ディスクスペースの 発されている． 節約，ソースファイル編集時の排他制御などの機能を しかし，これまでの研究では，動的バージョン管 持 っ て い る ．し か し ，バ ー ジ ョ ン 管 理 が 必 要 な も の は ， 理 シ ス テ ム 自 身 が Java ۗ ܃に よ り 実 装 さ れ て お り ， ソースファイルのみではない． 実行効率に問題があった．我々は，現在，この問題を ؼ年，ソフトウエアシステムは人間の生活に深く ӕ決するべく，動的バージョン管理の機能を持った 浸透している．それらのシステムの停止は，例え一時 Java 仮 想 マ シ ン の 開 発 を 行 っ て い る ． 本 論 文 で は ， 的なものであっても，人間生活に大きな影を与える 現在までに開発された動的バージョン管理機能を持つ Java 仮 想 マ シ ン の 概 要 と ， そ の 評 価 に つ い て 述 べ る ． 2. 動 的 バ ー ジ ョ ン 管 理 の 概 要 Java ۗ ܃の よ う な オ ブ ジ ェ ク ト 指 向 の ۗ ܃で 開 発 2.1.2. バ ー ジ ョ ン 切 り 替 え 機 能 されたソフトウェアの機能を変更するためには，その バージョン切り替え機能は，バージョン指定情報 中で使用されているオブジェクトに変更を加える必要 を元にアクセスするバージョンを切り替える機能であ がある．しかも，ソフトウェアを停止させないで機能 る．その際，指定されたバージョンが存在しない場合 変更するためには，オブジェクトへの変更を実行中に は，上記の新バージョンの生成機能を使いそのバージ 行う必要がある．我々の研究室ではオブジェクトの動 ョンを生成した後にそのバージョンへアクセスする． 的バージョン管理機能によりこれを実現している．こ れは使用中のオブジェクト自身に変更を加えるのでは 2.2. バ ー ジ ョ ン の 作 成 法 なく，オブジェクトに機能の異なる複数のバージョン また，新しいバージョンを定義する際には，全く が存在することを可能とし，それらのオブジェクトを 新֩に定義する必要はなく，古いバージョンからの変 実行中に切り替えて使用することを可能とするメカニ 更分を定義するのみで良い． ズムである． 新しいバージョンに対して，古いバージョンのメ ソッドの実行要求やインスタンス変数のアクセス要求 2.1. 代 理 オ ブ ジ ェ ク ト があった場合には，その要求が古いバージョンに対し 動的バージョン管理システムでは，複数のバージ て 転 送 (delegation)さ れ る こ と に よ り 処 理 さ れ る ． ョンを持つオブジェクトが，バージョン管理されてい ることを意ࡀすることなく，一般のオブジェクトと同 3. 動 的 バ ー ジ ョ ン 管 理 の 問 題 点 様にプログラム中で使用することができるように，代 動的バージョン管理では，上述した通り代理オブ 理オブジェクトを使用する．図 1 に示すように，ユー ジェクトを介しての間接的なアクセスを頻繁に行うこ ザプログラムと使用するオブジェクトとの間に代理オ ととなり，通常のオブジェクトに対するアクセスに比 ブジェクトを置く．ユーザプログラムは代理オブジェ べて実行効率が悪い．また，新バージョンを生成する クトをオブジェクト自身であると思ってアクセスする． 作業は決して速いものではない．さらに，新バージョ 代理オブジェクトは，ユーザプログラムからの処理依 ンが再利用している旧バージョンのメソッドを要求さ 頼を受け取り，バージョン指定情報を元に使用するオ れた場合，旧バージョンを順に調べそのメソッドが存 ブジェクトのバージョンを選択する．そして，指定さ 在する最も新しいバージョンを探す作業なども発生し， れたバージョンのオブジェクトに処理を依頼し，その こ の 作 業 も 速 い も の で は な い ． こ れ は ， Java ۗ ܃に 結果をユーザプログラムにඉす．代理オブジェクトの は も と も と 存 在 し な い delegation の 機 能 を 代 理 オ ブ ジ 機能は，新バージョンの生成とバージョン切り替え機 ェクトの機能として実装しているためである． 能の 2 つからなる． 代理オブジェクトの動作速度を向上させるために は，上記の一つ一つの処理の速度向上が必要である． バージョン指定情報 しかし，代理オブジェクトの実装を改良しても動作速 度を大幅に向上させることはできない可能性がݗい． これは，代理オブジェクトの機能の多くが，リフレク ユーザ 代理 プログラム オブジェクト ションを使用する必要があるためである．そのため， オ ブ ジ ェ ク ト の 動 的 バ ー ジ ョ ン 管 理 機 能 自 身 を Java 仮 想 マ シ ン [5]に 組 込 む こ と で ， シ ス テ ム 全 体 の 実 行 選択 効率を上げることにした． バージョン 1 バージョン 0 要求転送 4. Java 仮 想 マ シ ン の 概 要 Java 仮 想 マ シ ン に は 図 2 に 示 す よ う に 実 行 中 に 生 図 1 代 理 オ ブ ジ ェ ク ト 成されたオブジェクトを格納するヒープ領域が存在す る．また，実行時コンスタントプールと呼ばれるデー 2.1.1. 新 バ ー ジ ョ ン の 生 成 機 能 新バージョンの生成とは，バージョン指定情報に タや，メソッド情報，フィールド情報用の領域も存在 する． より選択されたバージョンが生成されていない場合 Java 仮 想 マ シ ン の 構 造 は ， 基 本 的 に は ス タ ッ ク マ （例えば，そのバージョンに対する初回アクセス時） シンであり，変数の値や一時的なڐ算結果などをスタ にそのバージョンを自動的に生成する機能である． ックに格納して処理を行う．実行中のスレッドに着目 した場合，そのバイトコードを実行するためにオペラ タグ 7 でクラスを示しており，さらにインデックス 3 ンドスタックとローカル変数が存在する．バイトコー のエントリを参照するようになっている．インデック ドの種་により，これらのどの領域に影を及ぼすか ス 3 のエントリは，タグ 1 で文字列が格納されている が決まる． ことを示している．インデックス 4 のエントリは名前 と型を示しており，その中でインデックス 5 と 6 を参 実 行 時 コンスタ メソッド フィールド ヒープ ントプール 情報 情報 領域 スレッド 2 スレッド 1 スレッド n オペランド オペランド オペランド スタック スタック スタック ローカル ローカル 変数 変数 ． ． ． ． ． 照するようになっている．インデックス 5 と 6 は，と もに文字列が格納されている．インデックス 6 のエン トリは引数，戻り値が空であることを表している． このようにたどっていくと，インデックス 1 のエ ン ト リ は Hello ク ラ ス の メ ソ ッ ド void sayHello()を 示 しているということになる． 同 様 に し て ， イ ン デ ッ ク ス 7 の エ ン ト リ は Hello ク ローカル ラ ス の 名 前 が <init>， 引 数 と 戻 り 値 が void の メ ソ ッ ド 変数 を 示 し て い る が ， イ ン デ ッ ク ス 9 の 示 す <init>は 特 殊 図 2 Java 仮 想 マ シ ン の 構 造 な表記でありコンストラクタを示すものである．つま り ， Hello()と い う コ ン ス ト ラ ク タ を イ ン デ ッ ク ス 7 は 示しているということになる． 4.1. 実 行 時 コ ン ス タ ン ト プ ー ル 実行時コンスタントプールは，定数やクラス名な どを保持するための構造体であり，可変ସの配列とな っている．参照の際には，インデックスを指定する． コンスタントプールは，もともとクラスファイル 中に存在し，クラスをロードした時点で実行時コンス タントプールとして仮想マシン上にロードされる． 実際のエントリは図 3 のようになっている． 4.2. 仮 想 マ シ ン の 実 行 例 index 1 a 2 4 index 4 c 5 index 2 index 3 7 1 6 3 9 Hello 1 明する． hello = new Hello( ); 8 sayHello hello.sayHello( ); index 7 ( )V index 8 c 下記のソースコードの一を例とし，実行例を説 5 index 5 index 6 1 3 a 2 このソースコードをコンパイルすると，次のよう 8 なバイトコードが生成される． index 9 6 1 6 <init> 1:new #2 <Class Hello > 2:dup 図 3 コ ン ス タ ン ト プ ー ル 3:invokespecial #7 <Method Hello( ) > エントリの最初の 1 バイトは常にタグとなってお 4:putfield #10 < Field Hello hello > り ，そ の エ ン ト リ が 示 す 情 報 を ࡀ 別 す る た め に 用 い る ． 5:getfield #10 < Field Hello hello > このタグの種་の例を表 1 に示す． 6:invokevirtual #1 <Method void sayHello()> 表 1 コ ン ス タ ン ト プ ー ル の タ グ これはコンパイラにより生成されたバイトコード を ， javap コ マ ン ド で 見 や す い 形 で 表 示 し た も の で あ 定数の型 CONSTANT_Class CONSTANT_Methodref CONSTANT_NameAndType 値 7 a c CONSTANT_Utf8 1 意味 クラス メソッド 名前，引数 戻り値 文字列 る ． Javap コ マ ン ド は JDK に 含 ま れ る コ マ ン ド で ク ラ スファイルに含まれる情報を表示することができるツ ー ル で あ る ． オ ペ コ ー ド の 後 の #の つ い た 数 字 は 実 行 時コンスタントプールへのインデックスであり，その オ ペ コ ー ド の 引 数 で あ る ． そ の 後 の < >の 分 は そ の インデックスが指す実行時コンスタントプールの情報 図 3 のインデックス 1 のエントリは，タグが a とな っていることからメソッドに関する情報を示すことが わかり，その中でさらに，インデックス 2 と 4 を参照 するようになっている．インデックス 2 のエントリは で あ り ， javap の つ け た コ メ ン ト で あ る ． バイトコードとヒープ領域，オペランドスタック の関係を図４を用いて説明する． ースコードを理ӕしやすいインタプリタを選択した． Kaffe を 改 造 し た 仮 想 マ シ ン を kaffe/DVM と 呼 ぶ ． hello の参照 代 理 オ ブ ジ ェ ク ト 相 当 機 能 を Kaffe/DVM に 組 み 込 hello の参照 hello の参照 むためには，新バージョンの生成機能と，バージョン 1 行目 2 行目 切り替え機能を実装する必要があるが，今回のࠟ作で は，バージョン切り替え機能のみを実装した．プログ hello の参照 3 行目 4 行目 hello の参照 6 行目 5 行目 図 4 ス タ ッ ク の 状 態 ラム中で使用するオブジェクトのバージョンを実行時 に生成することはできないが，それらのバージョンを 予め生成しておき，それらを実行時に切り替えて使用 することができる．なお，バージョンの生成機能は， 仮 想 マ シ ン の 外 で ， Java ۗ ܃の ソ ー ス コ ー ド レ ベ ルで行っている． 1 行 目 の new で は ， Hello ク ラ ス の イ ン ス タ ン ス を ヒープ領域に生成し，その参照をオペランドスタック に push し て い る ． ユーザ version 0 プログラム version 1 2 行 目 の dup で は ， 1 行 目 で オ ペ ラ ン ド ス タ ッ ク に 格 納 さ れ た 値 を コ ピ ー し ，オ ペ ラ ン ド ス タ ッ ク に push する．つまり，オペランドスタックに同じ参照が 2 つ 代理オブジェクト相当機能 存在する状態となる． 3 行 目 の invokespecial で は ， Hello ク ラ ス の コ ン ス Java 仮想マシン 図 5 JVM / DVM トラクタを呼び出している．この際，オペランドスタ ッ ク の 値 を pop す る ． こ の 場 合 は オ ペ ラ ン ド ス タ ッ ク 仮想マシン内でバージョン切り替え機能を実現 中 の Hello ク ラ ス の イ ン ス タ ン ス の 参 照 を pop す る こ するためには，アクセス先オブジェクトを動的に変更 ととなる． する必要がある．メソッド呼び出しのバイトコードで 4 行 目 は 変 数 hello に オ ペ ラ ン ド ス タ ッ ク か ら pop あ る invokevirtual が 実 行 さ れ る 際 に は ， 4.2 節 で 述 べ した値を格納する．この場合はオペランドスタック中 た通り，オペランドスタックよりオブジェクトの参照 の Hello ク ラ ス の イ ン ス タ ン ス へ の 参 照 が 変 数 hello を 得 る ． 4.2 節 の 例 で は ， getfield に よ っ て イ ン ス タ ン に格納されることとなる． ス変数中に格納されたオブジェクトの参照を得ている． 5 行 目 で は ， 変 数 hello の 値 を オ ペ ラ ン ド ス タ ッ ク そ の た め ， getfield を 実 行 す る 際 ， そ の 変 数 が バ ー に push し て い る ． 変 数 hello に は Hello ク ラ ス の イ ン ジョン管理の対象であるか否かを判定し，対象であっ スタンスへの参照が格納されているので，それがオペ た場合には，現在使用するべきバージョンのオブジェ ラ ン ド ス タ ッ ク へ push さ れ る ． ク ト の 参 照 を オ ペ ラ ン ド ス タ ッ ク に push す る 事 で ， 6 行 目 で は ， オ ペ ラ ン ド ス タ ッ ク か ら Hello ク ラ ス invokevirtual に よ る メ ソ ッ ド 呼 び 出 し が 切 り 替 え ら れ の イ ン ス タ ン ス の 参 照 を pop し ， そ の オ ブ ジ ェ ク ト の る事となり，バージョン切り替え機能を実現する事が sayHello と い う メ ソ ッ ド を 実 行 し て い る ． できる． な お ， getfield 以 外 に も aload， getstatic 等 オ ペ ラ ン 5. 仮 想 マ シ ン で の 代 理 オ ブ ジ ェ ク ト 機 能 の 実 ドスタックにオブジェクトの参照を格納する命令は存 現 在 す る た め ， そ れ ぞ れ の バ イ ト コ ー ド で getfield と 同 動的バージョン管理機能を組み込んだ仮想マシン 様の処理を行う必要がある． JVM/DVM (Java Virtual Machine / Dynamic Version Management)は ， 図 5 の よ う に 既 存 シ ス テ ム で の 代 理 6. Kaffe/DVM の ࠟ 作 オブジェクト相当の機能を持たせることで実現する． 6.1. kaffe の 構 成 今 回 の 開 発 に 用 い て い る Java 仮 想 マ シ ン は Kaffe [6] 仮 想 マ シ ン kaffe は ， kaffe， kaffevm ， kaffevm/intrp で あ る ． こ れ は ， オ ー プ ン ソ ー ス の Java 仮 想 マ シ ン 等 の モ ジ ュ ー ル か ら 構 成 さ れ て い る ．モ ジ ュ ー ル kaffe である．オープンソースなので情報が多く，開発を比 は ， kaffe コ マ ン ド に 直 結 す る 処 理 を 行 う も の で ， オ Ԕ的容易に行えると考えたためこの仮想マシンを採用 プ シ ョ ン の 判 別 や ， Kaffe の バ ー ジ ョ ン 情 報 の 出 力 な し た ． Kaffe の 仮 想 マ シ ン に は イ ン タ プ リ タ 版 と JIT ど を 担 当 す る ． こ の 中 の main 関 数 で 仮 想 マ シ ン を 実 版 が あ る ． 今 回 は ， 動 作 速 度 は JIT に 比 べ て ૺ い が ソ 際に開始するモジュールを呼び出している． モ ジ ュ ー ル kaffevm/intrp は ， Java 仮 想 マ シ ン の 実 ファイルを元に行う．この指定情報ファイルは，例え 装 で あ り intrp は ， イ ン タ プ リ タ を 表 し て い る ． 今 回 ば A クラスのバージョン 1 で稼働させる場合は A = 1 は，インタプリタを選択したのでこれを使うが，他に のように記述したテキストファイルである． kaffe/jit が 存 在 す る ． kaffevm/intrp の 中 の ， machine ハッシュテーブル更新のタイミングは，バージョ 関数によって実際の仮想マシンの動作を行う．上記の ン指定情報ファイルを変更した後にユーザにより仮想 main 関 数 に よ っ て ， こ の 関 数 machine が 呼 ば れ る ． マシンに対してシグナルを送る形とした．このシグナ 関 数 machine は ， 基 本 的 に は ル ー プ し て バ イ ト コ ー ド ルが送られるまでは，ハッシュテーブルの更新が行わ をひとつずつ実行する．そのループの中で，バイトコ れないため，バージョンも切り替わることはない．シ ードごとに分岐し，それぞれを実行する形になってい グナルが送られる以外に，仮想マシンの֬動時にもハ る． ッシュテーブルの更新は行われる． kaffevm の 中 の kaffe.def が そ の バ イ ト コ ー ド ご と の 上述のように，バージョン指定情報ファイルを元 処 理 を 担 当 す る ． つ ま り ， kaffe.def に は ， バ イ ト コ ー にハッシュテーブルを作成し，そのハッシュテーブル ドの処理がすべて定義されているのである． を 用 い て ， getfield の 引 数 を 変 更 す る こ と が 可 能 と な った．これによって，インスタンス変数に格納された バージョン管理対象のオブジェクトのバージョンを切 6.2. kaffe へ の 変 更 今回の実装では，バージョン管理されたオブジェ り替えて使用できるようになった． クトの各バージョンの参照は，それぞれ別のインスタ ン ス 変 数 へ 格 納 す る 方 式 と し た ． getfield の 引 数 は ， 6.3. 比 Ԕ 検 証 用 サ ン プ ル その変数の名前やクラス名等の情報にリンクされたイ 今 回 開 発 し た Kaffe/DVM の 実 行 効 率 を 検 証 す る た ンデックスである．このインデックスを必要なバージ め，次のようなサンプルプログラムを用意した．基本 ョンを格納する変数を表すインデックスと交換するこ 構成は，A クラスをバージョン管理対象とし，B クラ とで，オペランドスタックには切り替え後のバージョ スの中で A クラスのインスタンスを生成し，そのメ ンの参照が格納されることとなる． ソ ッ ド を 100 回 ， 150 回 ， 200 回 呼 び 出 す と い う も の kaffe kaffevm で あ る ． 対 象 の メ ソ ッ ド は ， System.out.println に よ る クラス名 バージョン管理用 出 力 ， Math.sqrt， Hashtable の 操 作 の 3 種 ་ を 用 意 し ハッシュテーブル た． 使用する System.out.println，Math.sqrt を 実 行 す る メ ソ ッ ド は ， バージョン そ れ ぞ れ 1 回 該 当 の 処 理 を 行 っ て い る ． Hashtable の 更新 シグナル A=1 バージョン B=3 指定ファイル 操 作 を す る メ ソ ッ ド に つ い て は ， Hashtable に 100 項 目 デ ー タ を ୈ 加 し ， そ の ୈ 加 し た 100 項 目 を 参 照 す る という処理を行う． 3 種་のバージョン管理対象のオブジェクトのメソ ッ ド を ， 通 常 の Kaffe 仮 想 マ シ ン ， 今 回 開 発 し た 図 6 Kaffe / DVM の 構 成 Kaffe/DVM ， 代 理 オ ブ ジ ェ ク ト を 用 い た 動 的 バ ー ジ ョ ン 管 理 シ ス テ ム DVMS で そ れ ぞ れ 実 行 し て ڐ測 し た ． そのインデックスの切り替えを実現するために， な お ， DVMS で は メ ソ ッ ド の 初 回 ֬ 動 時 に バ ー ジ ョ ハッシュテーブルを用意した．このハッシュテーブル ン生成機能が働くため，全てのڐ測は初回のメソッド は，クラス名をキーとし，使用すべきバージョンのイ 呼び出しを除外した． ン デ ッ ク ス 情 報 を 得 ら れ る も の で あ る ． getfield が 実 行 さ れ る と ，引 数 か ら た ど り ク ラ ス 名 を 得 る ．そ し て ， 6.4. 比 Ԕ 検 証 結 果 そのクラス名を元にハッシュテーブルを検索し，見つ 表 2 に，3 種་のサンプルについてڐ測した結果を かれば交換先のインデックス情報を得て，そのインデ 示 す ． こ れ は ， 各 メ ソ ッ ド を 100 回 ， 150 回 ， 200 回 ッ ク ス を getfield の 引 数 と し て 実 行 す る ． 繰 り ඉ し て 実 行 す る 時 の 処 理 時 間 を 10 回 ڐ測 し ， そ 今回ࠟ作の仮想マシンにはオプション指定するこ の平均を求めたものである． とで，バージョン管理機能の有効，無効を切り替えら System.out.println や Math.sqrt に つ い て は ， 以 前 の れ る よ う に し た ．こ れ に よ り ，デ フ ォ ル ト で は getfield システムと比Ԕして今回ࠟ作したシステムが圧倒的に を行う度にハッシュを検索する作業などは発生しない． ݗ速であるとۗえる． ハッシュテーブルの生成は，バージョン指定情報 し か し ， Hashtable に 関 し て は 以 前 の シ ス テ ム の 方 が速いという結果が得られた．これは，システムのࠟ の 実 行 時 間 の 差 を 求 め た も の で あ る ． getfield の 実 行 作構想段階では，予想していなかった結果である．そ 回 数 は ， Hashtable の サ ン プ ル 実 行 時 に 突 出 し て 多 い の 原 因 と し て ， getfield の 対 象 と な る オ ブ ジ ェ ク ト が 事 が 確 認 で き た ． こ れ に よ り ， 上 述 し た 通 り getfield バージョン管理対象であるか否かの判定をするため， の回数が多いため旧システムでのオーバーヘッドより， getfield 命 令 が 実 行 さ れ る 度 に 仮 想 マ シ ン 内 に 組 込 ん 今回のシステムの方がૺくなったとۗえる．さらに， だバージョン管理情報のハッシュテーブルに問い合わ getfiled を 一 回 処 理 す る た め の Kaffe/DVM の オ ー バ ヘ せ を 行 う た め で あ る こ と が 考 え ら れ た ． getfield の 対 ッドは，サンプルによらずほぼ一定であることも確認 象となるオブジェクトがバージョン管理の対象となっ できた． ていない場合は，以前のシステムではその処理に伴う オーバヘッドは発生しない．従って，バージョン管理 に 関 係 し な い getfield の 実 行 回 数 が 多 く な る に つ れ て ， その処理時間が問題となる． 7. ま と め と 今 後 の Ӏ 題 オブジェクトの動的バージョン管理システムの実 行効率を改善するため，バージョン切り替え機能を組 み 込 ん だ Java 仮 想 マ シ ン Kaffe/DVM を ࠟ 作 し ， そ の 表 2 平 均 処 理 時 間 メリット，デメリットを確認する事ができた． サンプル 繰りඉし プログラム 回数 println sqrt Hashtable 代理オブジェクトを用いたシステムと比Ԕし，今 Kaffe Kaffe/DVM DVMS 100 145.8 165.9 770.3 今回のࠟ作したシステムを有効に使用できるのはバー 150 219.7 247.3 1139.8 ジョン管理の対象とならないオブジェクトを対象とす 200 296.7 324.8 1520.8 る getfield が 少 な い 時 で あ る ． 100 1.3 1.4 553 150 2 2.1 827.4 200 2.5 2.9 1115.7 100 3636.6 4431.9 4245.0 150 5424.8 6630.4 6348.6 200 7265.8 8852.6 8640.1 (単 位 ： ms) 回ࠟ作したシステムが必ずしも優れている訳ではない． 今後のӀ題としては，バージョン切り替え機能の 改善と，今回は実装できなかった新バージョンの動的 生成機能の組み込みが挙げられる． バージョン切り替え機能については，今回の評価 の 対 象 と し た の は getfield の み で あ っ た ． し か し ， getstatic， aload 等 に お け る バ ー ジ ョ ン 管 理 の た め の オ ーバヘッドも考慮すると，実行速度が現状よりૺくな る事は確実である．そのため，より効率の良い方式を 再度検討する必要がある． 一 方 Hashtable 以 外 の サ ン プ ル に つ い て は ， 期 待 し た通りの結果が得られているが，これについては，バ ージョン管理されていないオブジェクトを対象とする getfield の 実 行 回 数 が 少 な い た め ， 以 前 の シ ス テ ム で のリフレクションによるオーバーヘッドよりも getfield の オ ー バ ヘ ッ ド が 少 な い た め で あ る と 考 え ら れる． 新バージョンの生成機能は，生成の方式や生成タ イミング等を検討しなければならない． また，ユーザがシステムを運用する際，システム 中で使用されている各オブジェクトのバージョンの状 態を把握できる仕組みも導入する予定である．これに より，バージョン変更作業がより容易になると考えて いる． 表 3 getfield の 実 行 回 数 と オ ー バ ヘ ッ ド 文 サンプル プログラム getfield の実行回数 (A) オーバヘッド (B) getfield 一回あたりの オーバヘッド (B)/(A) 0.014ms println 11000 158.9ms sqrt 100 1.5ms 0.015ms Hashtable 262200 4420.7ms 0.016ms この推測を検証するため，表３に各サンプルでの メ ソ ッ ド 呼 び 出 し 100 回 あ た り の getfield の 実 行 回 数 (A)と ， そ の 際 に 発 生 す る Kaffe/DVM に お け る オ ー バ ヘ ッ ド (B)を 示 す ． (B)は 表 ２ に お け る 200 回 と 100 回 献 [1] RCS, http://www.cs.purdue.edu/homes/trinkle/RCS/ [2] Rochkind, The Source Code Control System, TOSE, IEEE, SE-1, No.4, pp.364-370, 1975 [3] 杉 山 安 洋 ， Java ク ラ ス の 動 的 バ ー ジ ョ ン 管 理 の 構 想 ， 情 報 処 理 学 会 研 究 報 告 ， 97-SE-115,pp.4956,1998. [4] 杉 山 安 洋 ， 戸 勝 文 ， 動 的 バ ー ジ ョ ン 管 理 に 基 づく実行中のソフトウェア発展法，情報処理学 会 研 究 報 告 ， 98-SE-119,pp.49-56,1998. [5] テ ィ ム・リ ン ド ホ ル ム ，フ ラ ン ク・イ ェ リ ン ，Java 仮想マシン仕様 第 2 版，株式会社ピアソン・ エ デ ュ ケ ー シ ョ ン ， 2001 [6] Transvirtual Technologies, Kaffe, http://kaffe.org
© Copyright 2025 ExpyDoc
