(57)【要約】【課題】改良されたメモリ・リーク検出および修復の方法、システム、および装置を提供すること。【解決手段】本発明では、メモリ内に作成されたオブジェクト・インスタンスのエージング値を確定でき、実行プロセスでオブジェクト・インスタンスを参照した場合はエージング値をリセットする。一方、直前のガーベッジ・コレクション・パス以降に実行プロセスでオブジェクト・インスタンスが参照されなかった場合は、ガーベッジ・コレクション・パスの間にエージング値が増分される。重要なのは、エージング値がしきい値を超えるとオブジェクト・インスタンスをロイター・オブジェクトとして処理できることである。処理のステップには、さらにメモリ内の少なくとも１つのキャッシュをクリアするステップと、前記オブジェクト・インスタンスをロイター・オブジェクトとしてログ・ファイルで報告するステップを含めてもよい。さらに、オブジェクト・インスタンスが指定された除外クラスに属する場合は処理のステップを省略できる。【選択図】図２
2005108235.tif 000002
【特許請求の範囲】
【請求項１】
実行プロセスからアクセスされ、メモリ内の他のオブジェクト・インスタンスから参照されるオブジェクト・インスタンスを格納するように構成された前記メモリに関連付けられた自律的ガーベッジ・コレクタと、
前記自律的ガーベッジ・コレクタに関連付けられた追跡ポリシーであって、前記メモリ内のオブジェクト・インスタンスが前記実行プロセスのいずれからもアクセスされていない場合に前記オブジェクト・インスタンスがロイター・オブジェクトと見なされるいくつかのガーベッジ・コレクション状態に対するエージングしきい値を指定する、追跡ポリシーと
を含む、自律的メモリ・リーク検出および修復のシステム。
【請求項２】
前記メモリが仮想マシンを介して管理されるヒープである、請求項１に記載の自律的メモリ・リーク検出および修復のシステム。
【請求項３】
前記自律的ガーベッジ・コレクタに、前記メモリ内のオブジェクト・インスタンスに関連するエージング値を管理し、かつ前記エージング値を前記エージングしきい値と比較してロイター・オブジェクトを特定するように修正されたMark and Sweepガーベッジ・コレクタを含む、請求項１に記載の自律的メモリ・リーク検出および修復のシステム。
【請求項４】
前記追跡ポリシーは、ロイター・オブジェクトを検出したときに適用する少なくとも１つの処置の仕様をさらに含む、請求項１に記載の自律的メモリ・リーク検出および修復のシステム。
【請求項５】
前記追跡ポリシーは、オブジェクト・インスタンスがロイター・オブジェクトとしてラベル付けされないための除外クラスのリストをさらに含む、請求項１に記載の自律的メモリ・リーク検出および修復のシステム。
【請求項６】
メモリ内に作成されたオブジェクト・インスタンスのエージング値を確定するステップと、
前記オブジェクト・インスタンスが実行プロセスから参照された場合に前記エージング値をリセットするステップと、
直前のガーベッジ・コレクション状態以降に前記オブジェクト・インスタンスが実行プロセスから参照されていない場合にガーベッジ・コレクション状態の間に前記エージング値を増分するステップと、
前記エージング値がしきい値を超えた場合に前記オブジェクト・インスタンスをロイター・オブジェクトとして処理するステップと
を含む、メモリ・リーク検出および修復の方法。
【請求項７】
前記確定ステップは、さらに
前記メモリ内の同等のオブジェクト・インスタンスを突きとめるステップと、
前記メモリ内の前記同等のオブジェクト・インスタンスをロイター・オブジェクトとして処理するステップと
を含む、請求項６に記載のメモリ・リーク検出および修復の方法。
【請求項８】
前記処理ステップは、メモリ内の少なくとも１つのキャッシュをクリアするステップと、前記オブジェクト・インスタンスをロイター・オブジェクトとしてログ・ファイルで報告するステップとのうち少なくとも１つのステップを含む、請求項６に記載のメモリ・リーク検出および修復の方法。
【請求項９】
前記オブジェクト・インスタンスが指定された除外クラスに属する場合に、前記処理するステップを差し控えるステップをさらに含む、請求項６に記載のメモリ・リーク検出および修復の方法。
【請求項１０】
メモリ内に作成されたオブジェクト・インスタンスに関連するエージング値を管理するようにMarkand Sweepガーベッジ・コレクション・プロセスを修正するステップと、
エージング値が所定のしきい値を超える前記オブジェクト・インスタンスの選択されたインスタンスをロイター・オブジェクトとして処理するステップと
を含む、自律的メモリ・リーク検出および修復の方法。
【請求項１１】
前記処理するステップに、前記オブジェクト・インスタンスの選択されたインスタンスのエージング値が所定のしきい値を超える場合に、除外クラスに属さない前記オブジェクト・インスタンスの前記選択されたインスタンスをロイター・オブジェクトとして処理するステップを含む、請求項１０に記載のメモリ・リーク検出および修復の方法。
【請求項１２】
前記処理のステップに、メモリ内の少なくとも１つのキャッシュをクリアするステップと、前記オブジェクト・インスタンスをロイター・オブジェクトとしてログ・ファイルで報告するステップとを含む、請求項１０に記載のメモリ・リーク検出および修復の方法。
【請求項１３】
メモリ内に作成されたオブジェクト・インスタンスのエージング値を確定するステップと、
前記オブジェクト・インスタンスが実行プロセスから参照された場合に前記エージング値をリセットするステップと、
直前のガーベッジ・コレクション状態以降に前記オブジェクト・インスタンスが実行プロセスから参照されていない場合にガーベッジ・コレクション状態の間に前記エージング値を増分するステップと、
前記エージング値がしきい値を超えた場合に前記オブジェクト・インスタンスをロイター・オブジェクトとして処理するステップと
をマシンに実行させるための命令のルーチン・セットを含む、メモリ・リーク検出および修復のためのコンピュータ・プログラムを格納したマシン可読ストレージ。
【請求項１４】
前記確定のステップは、
前記メモリ内の同等のオブジェクト・インスタンスを突きとめるステップと、
前記メモリ内の前記同等のオブジェクト・インスタンスをロイター・オブジェクトとして処理するステップと
をさらに含む、請求項１３に記載のメモリ・リーク検出および修復のためのコンピュータ・プログラムを格納したマシン可読ストレージ。
【請求項１５】
前記処理のステップに、メモリ内の少なくとも１つのキャッシュをクリアするステップと、前記オブジェクト・インスタンスをロイター・オブジェクトとしてログ・ファイルで報告するステップを含む、請求項１３に記載のメモリ・リーク検出および修復のためのコンピュータ・プログラムを格納したマシン可読ストレージ。
【請求項１６】
前記オブジェクト・インスタンスが指定された除外クラスに属する場合に、前記処理のステップを差し控えるステップをさらに含む、請求項１３に記載のメモリ・リーク検出および修復のためのコンピュータ・プログラムを格納したマシン可読ストレージ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はメモリ・リークの分野に関し、より詳細にはメモリ・リークを修復するガーベッジ・コレクションに関する。
【背景技術】
【０００２】
ソフトウェア開発者は数十年もの間メモリ・リークに悩まされており、その結果、バグのあるクラッシュしやすいソフトウェア・アプリケーションが広く配布される場合がある。特に、手動のメモリ割り当てが可能であるが割り当てメモリの解放（de-allocation）も手動で行わなければならないプログラミング言語に関して、メモリ・リークはソフトウェア開発段階で第一に対処すべき実行時の重要なバグであることがわかっている。メモリ・リークが大きな問題になるにつれて、開発販売されるソフトウェア開発ツールすべてが専らメモリ・リークの問題に対処するようになってきた。
【０００３】
メモリ・リークは、広義には、以前に割り当てられたメモリが使用されなくなっても解放されないために、割当て可能なメモリが次第に失われていく現象とされる。通常、メモリは寿命の短いデータに対して予約される。寿命を終えた場合は、予約されたメモリを割り当て可能なメモリのプールに返し、後で必要なときに使用できるようにしておく必要がある。重要なのは、メモリ・リークが修復されないと、最終的には他のプロセスから要求されたメモリを調達できなくなることである。
【０００４】
コンピュータ・プログラミング言語理論学者は、メモリ・リークの問題への対応が重要であると認識し、ガーベッジ・コレクションの概念を展開してきた。ガーベッジ・コレクションとは、割り当てられたメモリを自動的に解析し、関連するプロセスの動作で不要になったデータを格納している割り当て済みのメモリ領域を特定する機能である。ＪＡＶＡ（商標）プログラミング言語などのようなオブジェクト指向プログラミング言語のコンテキストでは、メモリ内のオブジェクトが対応するアプリケーションからアクセスされなくなると、こうした「デッド」オブジェクト（"dead" object）に割り当てられたメモリを割り当て可能なメモリのプールに返すことができる。
【０００５】
よく知られているガーベッジ・コレクション・アルゴリズムの１つである「Mark andSweep」ガーベッジ・コレクション・アルゴリズムは、ＪＡＶＡ仮想マシン（ＪＶＭ）の最新のリリースで採用されている。図１は、従来のよく知られているMarkand Sweepガーベッジ・コレクション・プロセスのフロー・チャートである。ブロックＳ１１０から開始し、判断のブロックＳ１２０に進み、メモリ・ブロック（通常はヒープ）の割り当て要求に対してメモリ割り当てエラーが発生したかどうかを判断する。発生している場合は、ブロックＳ１３０でヒープ内の最初のオブジェクトを取り出して解析する。判断のブロックＳ１４０で、オブジェクトがルートから到達可能、つまりオブジェクトが実行プロセスのアクティブな状況（activeaspect）の中でアクセスされるように構成されていると判断した場合は、ブロックＳ１５０でオブジェクトにライブ（alive）とマーク付けする。
【０００６】
続いて判断のブロックＳ１６０で、メモリ内に他にも解析するオブジェクトが残っている場合は、ブロックＳ１７０でヒープ内の次のオブジェクトを取り出して解析する。オブジェクトを取り出すと、ブロック１３０〜１７０のプロセスが繰り返され、ヒープ内のすべてのオブジェクトについてプロセスが完了するまで続く。判断のブロック１６０で、ヒープ内に解析するオブジェクトがなくなると、ブロック１８０でヒープ内のマークされていないオブジェクトがすべて削除される。こうして、基盤となるメモリをメモリのプールに返し、新しい割り当て要求に備えることができる。最後に、ブロック１９０でプロセスが終了する。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
図１のMark and Sweepアルゴリズムが、メモリ内に存在するが実行プロセスのアクティブな状況からアクセスできなくなっているオブジェクトは孤立したメモリ・ブロックであり、割り当てを解除すべきであるという見解に基づくことは、当業者なら理解されよう。しかし、こうした論法では前述の状況が意図的にプログラミングした構成の結果であるという可能性は無視される。さらに、Markand Sweepプロセスではロイター・オブジェクト（loiterering object）、つまりヒープ内の他のライブ・オブジェクトから参照されるが使用されなくなったオブジェクトは考慮されない。しかし、多くの場合にロイター・オブジェクトはメモリ・リークの基盤となり得る。
【課題を解決するための手段】
【０００８】
本発明は、メモリ・リークの検出と修復に関する技術の欠点に対処し、自律的メモリ・リーク検出および修復のための新しい自明でない方法、システム、および装置を提供する。本発明の好ましい態様として、自律的メモリ・リーク検出および修復のシステムには、実行プロセスからアクセスされ、メモリ内の他のオブジェクト・インスタンスから参照され得るオブジェクト・インスタンスを格納するように構成されたメモリに関連する自律的ガーベッジ・コレクタを含めることができる。本システムには、さらに自律的ガーベッジ・コレクタに関連する追跡ポリシー（tracing policy）を含めてもよい。本追跡ポリシーは、前記メモリ内のオブジェクト・インスタンスが前記実行プロセスのいずれからもアクセスされていない場合に前記オブジェクト・インスタンスがロイター・オブジェクト（loiterer）と見なされるいくつかののガーベッジ・コレクション・パスに対するエージングしきい値を指定することができる。
【０００９】
特に、メモリは仮想マシンを介して管理するヒープでもよい。さらに、自律的ガーベッジ・コレクタには、メモリ内のオブジェクト・インスタンスに関連するエージング値を管理し、このエージング値をエージングしきい値と比較してロイター・オブジェクトを特定するように修正されたMark and Sweepガーベッジ・コレクタを含んでよい。最後に、本追跡ポリシーは、ロイター・オブジェクトを検出した場合に適用する少なくとも１つの処置の仕様と、どのオブジェクト・インスタンスがロイター・オブジェクトとしてのラベル付けから除外されたかに基づいた除外クラスのリストとを含んでよい。
【００１０】
メモリ・リークの検出および修復の方法には、メモリ内に作成されたオブジェクト・インスタンスのエージング値を確定するステップと、実行プロセスからオブジェクト・インスタンスを参照した場合にエージング値をリセットするステップとを含めることができる。一方、直前のガーベッジ・コレクション・パス以降に実行プロセスでオブジェクト・インスタンスが参照されなかった場合は、ガーベッジ・コレクション・パスの間にエージング値が増分される。エージング値がしきい値を超えた場合にオブジェクト・インスタンスがロイター・オブジェクトとして処理されることは重要である。本発明の好ましい一態様では、設定のステップにメモリ内の同等のオブジェクト・インスタンスを突きとめるステップと、メモリ内の同等のオブジェクト・インスタンスをロイター・オブジェクトとして処理するステップとを含めることができる。ただし、オブジェクト・インスタンスが指定された除外クラスに属する場合は、処理のステップを省略できる。
【００１１】
処理のステップそれ自体には、さらにメモリ内の少なくとも１つのキャッシュをクリアするステップと、前記オブジェクト・インスタンスをロイター・オブジェクトとしてログ・ファイルで報告するステップを含めてもよい。特に前者のステップでは、メモリの使用量がその上限に近づくと、キャッシュ内のオブジェクトの参照を解除して直ちに解放できるようにする。そのために、特に仮想マシンの場合は、キャッシュおよびオブジェクト・プールの優先順位リストを確定できる。さらに具体的に言えば、優先順位リストはプロパティ・ファイルの形で確定できる。ヒープの使用量がその上限に近づいた場合、例えばメモリ割り当てエラーが増大した場合は、プロパティ・ファイル内のリストに基づいてキャッシュ内のオブジェクトの参照を選択的に解除できる。
【００１２】
本発明のその他の態様については、一部をこの後で説明するが、一部は上の説明から明らかであり、本発明の実施によっても理解できる。本発明の態様は、特許請求の範囲に詳細に記載する要素と組合せによって実現され、達成される。以上の一般的な説明と以下の詳細な説明は、いずれも例示および説明のみを目的としたものであり、本発明の特許請求の範囲を限定するものでないことは言うまでもない。
【００１３】
この明細書に引用され、その重要な要素となる添付の図面は、本発明の実施形態と内容を図示しており、本発明の原理を説明するものである。ここに示す実施形態は現時点で好ましいものであるが、本発明がこのとおりの配置や機器に限定されないことは言うまでもない。
【発明を実施するための最良の形態】
【００１４】
本発明は、自律的メモリ・リーク検出および修復のシステム、方法、および装置である。本発明により、メモリ内の他のライブ・オブジェクトから参照されているが他には使用されていないメモリ内のオブジェクトに基づいて、メモリ内のロイター・オブジェクトを特定できる。オブジェクトは、事前に指定した設定に基づいて修復のプロセスから除外してもよい。さらに、ロイター・オブジェクトを検出した場合は、事前に指定した設定の条件に応じて様々な処置を適用できる。処置は、ヒープ・ダンプによるロイター・オブジェクトの報告からガーベッジ・コレクションによるロイター・オブジェクトの解放まで多岐にわたる。
【００１５】
図２は、本発明による配置の好ましい態様に従って構成された自律的ガーベッジ・コレクション・システムを示すブロック図である。本システムの中心には、ここに記載する本発明に従ってプログラミングされた自律的ガーベッジ・コレクション・プロセス３００を含むことができる。自律的ガーベッジ・コレクション・プロセス３００は、追跡ポリシー３１０ならびにメモリ３２０と、例えば仮想マシンのヒープと連動できる。メモリ３２０は、複数のオブジェクト３３０を格納するように構成できる。各オブジェクトは、エージング値３４０とライブ値３５０に関連付けることができる。エージング値３４０は、オブジェクト３３０が最後に参照されてから実行された自律的ガーベッジ・コレクション・プロセス３００のパス数を指定できる。一方、ライブ値３５０にはオブジェクト３３０がメモリ３２０内の別のオブジェクトから参照されているかどうかを指定できる。
【００１６】
追跡ポリシー３１０は、自律的ガーベッジ・コレクション・プロセス３００で基準となるいくつかの可変要素を指定できる。例えば、追跡ポリシー３１０は本発明のメモリ・リーク検出および修復のプロセスが有効か無効かの指示３９０を含めることができる。例えば、本発明のプロセスによって仮想マシンでのアプリケーション実行に待ち時間が発生する場合に、実行速度が問題であれば自律的ガーベッジ・コレクション・プロセスを無効にするのが有利な場合もある。追跡ポリシーは再利用しきい値３８０も指定できる。これを超えてエージングされたオブジェクト３３０はロイター・オブジェクトと見なされる。
【００１７】
重要なのは、ロイター・オブジェクトを検出した場合に、そのオブジェクトに対して追跡ポリシー３１０で指定した様々な修復処置３７０を適用できることである。処置３７０は、ヒープ・ダンプによるロイター・オブジェクトの報告からロイター・オブジェクトのヒープからの強制的な解放まで多岐にわたる。さらに、オブジェクトのエージング値が再利用しきい値３８０を超えても、すべてのロイター・オブジェクトに対して修復処置を適用する必要はない。特に、追跡ポリシーの一連の除外クラス３６０で指定したクラスに属するオブジェクトについては修復処置を省略できる。このように、ソフトウェア開発の過程でメモリ内に同じクラスの複数インスタンスの作成が予期される場合、ロイタリング（loitering）は前提（presupposition）にならない。
【００１８】
図２のガーベッジ・コレクション・プロセス３００の操作を詳細に示す上で、図３〜６は全体として図２のシステムで使用する自律的ガーベッジ・コレクション・プロセスを示している。まず、図３で開始のブロックＳ３０５から判断のブロックＳ３１０に進み、メモリ内に新しいオブジェクト・インスタンスが作成されている場合は、ブロックＳ３１５で、関連するエージング値をリセットする。さらに、判断のブロックＳ３２０でメモリ内に既に存在している他のオブジェクト・インスタンスが新しいオブジェクト・インスタンスと同等かどうかを判断する。同等である場合は、ブロックＳ３２５で、既存のオブジェクト・インスタンスがロイター・オブジェクトの可能性のあるものとしてラベル付けされ、追跡ポリシーで推奨する処置に従って処理された後、ブロックＳ３３０でプロセスを終了できる。
【００１９】
次に図４を見ると、ブロックＳ３３５から判断のブロックＳ３４０に進み、メモリ内に配置されたオブジェクト・インスタンスがアクティブ・プロセスから参照されている場合は、ブロックＳ３４５でそのオブジェクト．インスタンスに関連するエージング値をリセットし、ブロックＳ３５０でプロセスが終了する。図５に示す中心的なガーベッジ・コレクション・プロセスの間に、メモリ内の各オブジェクト・インスタンスのエージング値が照会されることにより、ガーベッジ・コレクション・プロセスの多くの実働サイクルにわたってアクティブなプロセスから参照されていないオブジェクト・インスタンスが特定できることは重要である。こうした特定可能なオブジェクトは、ロイター・オブジェクトと見なされ、対応する処置が適用される。
【００２０】
図５を詳しく見ると、開始のブロックＳ３５５から判断のブロックＳ３６０に進み、メモリ割り当てエラーを検出した場合はブロックＳ３６５でヒープ内の最初のオブジェクト・インスタンスを解析する。特に判断ブロックＳ３７０で、オブジェクト・インスタンスがルートから「到達」可能、つまりメモリ内の別のオブジェクト・インスタンスがこのオブジェクト・インスタンスへの参照を保持している場合は、ブロックＳ３７５でオブジェクト・インスタンスに「ライブ」とマーク付けする。さらに、判断のブロックＳ３８０で、このオブジェクト・インスタンスがロイター・オブジェクトとして処理されない除外クラスのメンバーかどうかを判断する。メンバーでない場合は、オブジェクトに関連するエージング値を増分する。
【００２１】
判断のブロックＳ３９０でメモリ内に他にも解析すべきオブジェクト・インスタンスが残っている場合は、ブロックＳ３９５でヒープ内の次のオブジェクト・インスタンスを取り出してブロックＳ３６５〜３９５のプロセスを繰り返す。ヒープ内に解析すべきオブジェクト・インスタンスが残っていない場合は、ブロックＳ４００でマークされていないすべてのオブジェクトをヒープから解放し、対応するメモリを割り当て可能な状態に戻す。さらに、ブロックＳ４０５で、ロイター・オブジェクトである可能性のあるオブジェクト・インスタンスを処理する。
【００２２】
さらに詳細には、図６に示すように、開始のブロックＳ４１０から判断のブロックＳ４２０に進み、まずメモリが上限に達したかどうかを判断する。達している場合はメモリ割り当てエラーが発生している。達していない場合は、ブロックＳ４７０でプロセスが終了する。達している場合は、ブロックＳ４３０でプロパティ・ファイル内の最初のオブジェクトを選択し、ブロックＳ４４０で選択されたオブジェクトの参照を解除する。ここで、選択されたオブジェクトがオブジェクト・キャッシュの場合は、それに格納されている情報は本質的に余剰であり、その参照を解除しても結果としてほとんど影響がないことは言うまでもない。次に、判断のブロックＳ４５０でプロパティ・ファイル内に他にもオブジェクトが残っている場合は、ブロックＳ４６０でプロパティ・ファイル内の次のオブジェクトを取り出し、再びブロックＳ４４０で選択されたオブジェクトの参照を解除する。プロパティ・ファイル内に選択するオブジェクトがなくなるまでこのプロセスを継続する。オブジェクトがなくなると、ブロックＳ４７０でプロセスが終了する。
【００２３】
本発明は、ハードウェア、ソフトウェア、あるいはハードウェアとソフトウェアの組合せによって実現される。本発明の方法とシステムの実施態様は、１つのコンピュータ・システムによる集中方式でも、相互に接続された複数のコンピュータ・システムに様々な要素が散在する分散方式でも実現可能である。ここに記載する方法を実施するために採用したコンピュータ・システムまたはそれ以外の装置は、いずれの種類でもここに記載する機能の実施に適している。
【００２４】
ハードウェアとソフトウェアの一般的な組合せは汎用のコンピュータ・システムとコンピュータ・プログラムであり、プログラムはロードされ、実行されると、ここに記載する方法を実施するようにコンピュータ・システムを制御する。本発明をコンピュータ・プログラム製品に埋め込み、ここに記載する方法を実施できるすべての機能を備え、コンピュータ・システムにロードされたときにこうした方法を実施できるようにすることもできる。
【００２５】
本発明のコンテキストにおけるコンピュータ・プログラムまたはアプリケーションとは、特定の機能を直接実施するか、ａ）別の言語、コード、表記法への変換またはｂ）別の形態による再生あるいはその両方の後に実施する情報処理能力をシステムに提供するための任意の言語、コード、表記法による任意の表現の命令セットを意味している。重要なのは、本発明がその精神と本質的な属性を逸脱することなく他の特定の形で具体化できることである。したがって、本発明の範囲については、前述の明細書でなく特許請求の範囲を参照するものとする。
【図面の簡単な説明】
【００２６】
【図１】当技術分野でよく知られているMark and Sweepガーベッジ・コレクション・プロセスを示すフロー・チャートである。
【図２】本発明による配置の好ましい態様に従って構成された自律的ガーベッジ・コレクション・システムを示すブロック図である。
【図３】全体として、図２のシステムで使用する自律的ガーベッジ・コレクション・プロセスを示すフロー・チャートである。
【図４】全体として、図２のシステムで使用する自律的ガーベッジ・コレクション・プロセスを示すフロー・チャートである。
【図５】全体として、図２のシステムで使用する自律的ガーベッジ・コレクション・プロセスを示すフロー・チャートである。
【図６】全体として、図２のシステムで使用する自律的ガーベッジ・コレクション・プロセスを示すフロー・チャートである。
【符号の説明】
【００２７】
３１０  追跡ポリシー
３２０  メモリ
３３０  複数のオブジェクト
３４０  エージング値
３５０  ライブ値
３６０  除外クラス
３７０  修復の処置
３８０  再利用しきい値
３９０  リーク検出および修復のプロセスが有効か無効かの指定
【図１】
2005108235.tif 000003
【図２】
2005108235.tif 000004
【図３】
2005108235.tif 000005
【図４】
2005108235.tif 000006
【図５】
2005108235.tif 000007
【図６】
2005108235.tif 000008