JP2002505469A - 分散処理システムにおけるグループメンバシップのリースのための方法、装置及びプロダクト - Google Patents

Abstract

(57)【要約】 【目的】分散型処理システムにおいてグループメンバシップをリースするためのシステムを提供すること。 【解決手段】リモートオブジェクトは、アクティベーショングループから所定時間の間、アクティベーショングループのメンバシップをリクエストする。このリクエストに応えて、アクティベーショングループは、適当なリースピリオドを決定し、そのリースピリオドの間、リモートオブジェクトは、アクティベーショングループのメンバとなり、アクティベーショングループの他のオブジェクトと同一アドレス空間で走行する。

Description

【発明の詳細な説明】

【０００１】 関連出願 参考として示すが、本出願は、1996年10月11日出願の米国特許出願No.08/729,
421の一部継続出願である。 参考として以下に示した米国特許出願は、本出願の拠となるものである。 1998年2月26日出願の米国特許仮出願No.60/076,048、発明の名称「分散コンピ
ュータシステム」。 同日出願の米国特許出願No.09/044,923、発明の名称「記憶領域をリースする ための方法及び装置」（代理人整理番号No.06502.0011-01000）。 同日出願の米国特許出願No.09/044,838、発明の名称「分散システムにおける 委譲認証のリースに用いられる方法、装置及びプロダクト」（代理人整理番号No
.06502.0011-02000）。 同日出願の米国特許出願No.09/044,916、発明の名称「故障検知のためのリー ス」（代理人整理番号No.06502.0011-04000）。 同日出願の米国特許出願No.09/044,933、発明の名称「イベントに基づくシス テムにおける振るまい転送方法」（代理人整理番号no.06502.0054-00000）。 同日出願の米国特許出願No.09/044,919、発明の名称「オブジェクトの据え置 き型再構築と分散システムにおけるイベント通知用の遠隔ロード」（代理人整理
番号No.06502.0062-01000）。 同日出願の米国特許出願No.09/044,938、発明の名称「遠隔メソッド呼出用の 方法及び装置」（代理人整理番号No.06502.0102-00000）。 同日出願の米国特許出願No.09/045,652、発明の名称「遠隔メソッドを識別す るための決定論的ハッシュのための方法及びシステム」（代理人整理番号No.065
02.0103-00000）。 同日出願の米国特許出願No.09/044,790、発明の名称「分散システムにおける 遠隔オブジェクトのステータスを判断するための方法及び装置」（代理人整理番
号No.06502.0104-00000）。 同日出願の米国特許出願No.09/044,930、発明の名称「分散システムにおいて 遠隔手続コールに関連付けられた処理を実行するためのダウンロード可能なスマ
ートプロキシ」（代理人整理番号No.06502.0105-00000）。 同日出願の米国特許出願No.09/044,917、発明の名称「遠隔メソッドの停止及 び継続」（代理人整理番号No.06502.0106-00000）。 同日出願の米国特許出願No.09/044,835、発明の名称「データベースにおける マルチエントリ及びマルチテンプレートのマッチングのための方法及びシステム
」（代理人整理番号No.06502.0107-00000）。 同日出願の米国特許出願No.09/044,839、発明の名称「データベースにおける インプレイス・モディフィケーションのための方法及びシステム」（代理人整理
番号No.06502.0108）。 同日出願の米国特許出願No.09/044,945、発明の名称「データベースにおける タイプセイフ属性マッチングのための方法及びシステム」（代理人整理番号No.0
6502.0109-00000）。 同日出願の米国特許出願No.09/044,931、発明の名称「分散システムにおける ダイナミック検索サービス」（代理人整理番号No.06502.0110-00000）。 同日出願の米国特許出願No.09/044,939、発明の名称「分散型システムにおけ るデバイスとの情報通信用のダウンロード可能なコードを配信するための装置及
び方法」（代理人整理番号No.06502.0112-00000）。 同日出願の米国特許出願No.09/044,826、発明の名称「検索サービスへのアク セスを容易にするための方法及びシステム」（代理人整理番号No.06502.0113-00
000）。 同日出願の米国特許出願No.09/044,932、発明の名称「分散システムにおいて ダイナミックに情報をベリファイするための装置及び方法」（代理人整理番号No
.06502.0114-00000）。 1998年2月26日出願の米国特許出願No.09/030,840、発明の名称「ネットワーク
上においてダイナミックな分散コンピューティングをするための方法及び装置」
。 同日出願の米国特許出願No.09/044,936、発明の名称「永続的な共有メモリ空 間のための対話型設計ツール」（代理人整理番号No.06502.0116-00000）。 同日出願の米国特許出願No.09/044,934、発明の名称「多相型トークンに基づ く制御」（代理人整理番号No.06502.0117-00000）。 同日出願の米国特許出願No.09/044,915、発明の名称「スタックに基づくアク セス制御」（代理人整理番号No.06502.0118-00000）。 同日出願の米国特許出願No.09/044,944、発明の名称「スタックに基づく安全 性要求」（代理人整理番号No.06502.0119-00000）。 同日出願の米国特許出願No.09/044,837、発明の名称「安全性要求のメソッド の指定」（代理人整理番号No.06502.0120-00000）。

【０００２】 Ａ．発明の属する技術分野 本発明は、データ処理システムに関し、更に詳しくは、データ処理システムに
おけるオブジェクトのグループメンバシップのリースに関する。

【０００３】 Ｂ．関連技術の説明 完全なリソース管理は、コンピュータを効率的且つ効果的に利用するためには
重要な要素である。一般的には、リソース管理は、リクエストに応じたリソース
（例えば、メモリ）の割当と、リクエスタがもはやリソースを要求しない場合等
における適当なタイミングでのリソースの割当解除とを含む。一般的には、リソ
ースは、コンピュータ内で実行されるコンピュータ演算可能なエンティティ（例
えば、アプリケーション、プログラム、アプレット等）により参照されるデータ
を保持する。

【０００４】 実際には、コンピュータ上で実行するアプリケーションがリソースを参照する
ためにシークする時に、アプリケーションが完全にそれらを参照することができ
るようにするために、コンピュータは、まず最初にリソースを割当又は指定しな
ければならない。アプリケーションがもはやリソースを参照しない時は、コンピ
ュータは、リソースを再使用するために割当解除又は再生することができる。コ
ンピュータの各リソースは、特定の"ハンドル"を有しており、これによって、リ
ソースは参照可能なのである。ハンドルは、種々の方法、例えば、アドレス、配
列インデックス、ユニーク値、ポインタ等により実装することができる。

【０００５】 リソース管理は、単一コンピュータでは比較的簡単であるが、その理由は、リ
ソースが再生されえる時、例えば、アプリケーションがもはやそれらを参照しな
くなった場合や電源に異常が発生した場合を示すイベントが判断しやすいからで
ある。複数コンピュータを連結した分散システム用のリソース管理は、より難し
いが、その理由は、種々の異なるコンピュータのアプリケーションが同一のリソ
ースを使用するからである。

【０００６】 分散システムにおけるディスコネクトにより、不完全で時期尚早なリソースの
再生がなされたり、リソース再生に障害が発生することがある。例えば、分散型
システムの異なるコンピュータ上で動作する複数アプリケーションは、他のマシ
ン上に配置されたリソースを参照することもできる。リソースが配置されている
コンピュータと、それらのリソースを参照するアプリケーションとの間のコネク
ションが絶たれると、コンピュータは時期尚早にリソースを再生することになる
。或いは、コンピュータは、アプリケーションがリソースへのアクセスを失敗す
ると、延長ピリオドになっても永久にリソースを維持することになる。

【０００７】 これらの問題を解決するために、ネットワークリソースを管理するためのシス
テムが開発され、その一つが"分散型ガベージコレクション"として周知である。
分散型ガベージコレクションは、言語又はランタイムシステムにより提供される
機能を、ネットワークの種々のコンピュータにおいて動作する単一又はグループ
のアプリケーションにより使用されるリソースを自動的に管理する分散型システ
ム用に記述したものである。

【０００８】 一般的には、ガベージコレクションは、リソースがもはやアプリケーションの
どの部分からも参照されなくなったときに、リソースを後の使用のために解放さ
せるという概念を用いている。分散型ガベージコレクションは、分散型コンピュ
ーティングの領域にこの概念を拡張して、あらゆるコンピュータ上のアプリケー
ションが一つもリソースを参照しなくなったときにリソースを再生する。

【０００９】 分散型ガベージコレクションは、割当リソースとそれらのリソースへのリファ
レンスとの間の保全性を維持しなければならない。換言すれば、ネットワークの
コンピュータ上で走行するアプリケーションがそのリソースを参照し続ける限り
、システムはリソースの解放又は割当解除を行うことを許可されていない。この
リファレンス−リソースのバインドは、"リファレンスの保全性"と称されるが、
リファレンスが参照するリソースに当該リファレンスが常にアクセスすることを
許可することを保障するものではない。例えば、ネットワーク障害によりアクセ
スが不可能となる。しかしながら、保全性は、リファレンスを使用してあらゆる
リソースへアクセスすることができるならば、リファレンスが最初に付与された
リソースと同一リソースとなることを保障する。

【００１０】 ガベージコレクションを使用する分散型システムは、更に、リソースが制限時
間内に参照されない場合には、リソースを再生しなければならない。換言すれば
、システムは、"メモリリーク"に対し保障しなければならない。メモリリークは
、全てのアプリケーションがリソースに対するリファレンスを怠ったときに発生
するものであるが、例えば、いくつかのアプリケーションがそのリソースを参照
中であるという誤った判断が原因になって、システムは再使用を目的とするリソ
ースの再生に失敗する。

【００１１】 リファレンスの保全性の故障及びメモリリークは、リソースを参照するアプリ
ケーションと、それらのリソースの割当・割当解除を管理するガベージコレクシ
ョンシステムとの間のディスコネクトに起因することが多い。例えば、リソース
を参照するアプリケーションと、上述のリソースを管理するガベージコレクショ
ンシステムとの間のネットワークコネクション内のディスコネクトは、ガベージ
コレクションシステムがそのリソースを再生すべきか否か・いつ再生すべきかと
いうことを判断するのを妨害する。あるいは、ガベージコレクションシステムは
、アプリケーションが所定時間内にリソースにアクセスしなかったということを
理由として、誤ってそのリソースを収集してしまうという判断をすることもある
。分散型ガベージコレクションのメカニズムを改良するために、多くの技術が利
用されており、例えば、メモリリークを発生させずにリファレンスの保全性を維
持するメカニズムを確保しようとの試みがなされている。従来のアプローチの一
つとして、参照回数を数えるという形態を利用したものがあるが、そのカウント
は、互いのリソースを参照しているアプリケーションの数を数えることによって
なされるものである。リソースのカウント数がゼロになった時にガベージコレク
ションシステムはそのリソースを再生することができる。しかしながら、このよ
うなリファレンスカウント概念による機能は、リソースが対応するリファレンス
カウンタにより生成された場合にのみ有効である。この場合におけるガベージコ
レクションシステムは、リソースのリファレンスカウントをそのリソースを参照
するアプリケーションの数が追加されるに従って増加させ、アプリケーションが
そのリソースを参照しなくなったときに減少させるというものである。

【００１２】 しかしながら、リファレンスカウント概念は、とりわけ、分散型システム内で
起こり得る故障に直面しやすいという問題を引き起こす。このような故障は、リ
ソースが参照されなくなったガベージコレクションシステムを通知するメッセー
ジの配信を妨害するというコンピュータ・アプリケーションの故障又はネットワ
ークの故障という形態をとることができる。メッセージがネットワークのディス
コネクトにより配信されなかった場合には、ガベージコレクションシステムは、
いつそのリソースを再生すべきかが判断できなくなる。

【００１３】 このような故障を防止するため、従来のリファレンスカウント概念は、"キー プアライブ"のメッセージを含み、それは、"ピングバック"とも称される。この 概念によれば、ネットワーク内のアプリケーションは、リソースを監視するガベ
ージコレクションシステムにメッセージを送信し、アプリケーションがまだ通信
可能であることを示す。これらのメッセージは、ガベージコレクションシステム
がリソースへの参照を抜かしてしまうのを防止する。このような"キープアライ ブ"のメッセージの受信の故障により、ガベージコレクションシステムは、リソ ースへのリファレンスカウントを減少させることができ、そのカウントがゼロに
なると、ガベージコレクションシステムはリソースを再生する。しかしながら、
このことは、ネットワークの故障に端を発した後、"キープアライブ"のメッセー
ジの受信の失敗に起因してリファレンスカウントがゼロになり、結局、時期尚早
のリソース再生という結果を招く。従って、リファレンスの保全性は確保されな
い。

【００１４】 ガベージコレクションシステムにおけるリファレンスの保全性に関する問題を
解決するために、リファレンス回数を保持するだけでなく、更に、リソースを参
照するコンピュータ演算可能な各エンティティに対応する識別子を保持するとい
う他の手法が提案されている。例えば、エイ・ ビレル等による"ネットワーク オブジェクト用の分散型ガベージコレクション"（No.116デジタルシステムリサ ーチセンター、1993年12月15日）を参照されたい。この方法は、上述のリファレ
ンスカウント概念と同様の問題を有するものである。更に、この方法によれば、
各リソースを参照するコンピュータ演算可能な各エンティティ用のユニーク識別
子の追加が必要となり、これにより、分散型システム内の通信を不必要に増加さ
せるオーバーヘッドを追加することになり、記憶領域（すなわち、各リソースを
参照するアプリケーションに対応する識別子リスト）の追加が必要となる。

【００１５】 （発明の開示） 本発明によれば、リファレンスの保全性は、所定ピリオドの間、リソースをリ
ースすることにより、コスト高を招くメモリリークを起こすことなく保障される
。その間、分散型システム内の集合、例えば、リソースへのリファレンスを管理
するアプリケーション、そのリソースを管理するガベージコレクションシステム
等がそのリソースを承認すると、そのリソースへのリファレンスが保障される。
リースピリオドの終わりには、リソースへのリファレンスを継続する保障がなく
なり、ガベージコレクションシステムはリソースを再生することが可能になる。
リソースへのリファレンスを保持するアプリケーションとリソースを管理するガ
ベージコレクションシステムとが保障且つ制限されたリースピリオドを承認する
ため、両者は、リース及び保障がいつ終了するかを認識することができる。これ
により、リファレンスのリース期間内においては、リファレンスの保全性が保障
され、ネットワークエラーによるリソース解放の失敗の原因となることが回避さ
れる。

【００１６】 本発明に係る他の実施の形態は、以下に具体化して示すとともに広範囲にわた
って説明するように、グループメンバシップをリースする方法を提供するもので
ある。この方法は、アクティベーショングループ及びリースピリオドを指定する
リモートオブジェクトからリースリクエストを受信するリースリクエスト受信工
程と、リースピリオドを決定するリースピリオド受信工程であって、当該リース
ピリオドの間においては、前記アクティベーショングループの他のオブジェクト
と同一アドレス空間に、前記リモートオブジェクトが関連付けられ且つそこを走
行するリースピリオド受信工程とを有するものである。

【００１７】 （発明を実施するための最良の形態） 以下に、本発明の一実施の形態の詳細について添付図面を参照して説明する。
図面及び以下の説明において同一又は略同一の要素を参照する場合には、全体を
通してできる限り同一の符号を用いる。 本発明は、従来の分散型プロセッシングシステムのアーキテクチャに基づいて
構成されたコンピュータに実装することができる。しかしながら、本発明の実装
するためのアーキテクチャ及び手順は、従来のものとは異なる。その理由は、そ
のアーキテクチャ及び手順がリファレンスの保全性を保障するとともに、メモリ
リークを排除するからである。

【００１８】Ａ．概要 分散型プロセッシングシステム内の各コンピュータに配置されたメソッド呼出
（MI）コンポーネントは、本発明に係る分散型ガベージコレクション概念を実装
するものである。MIコンポーネントは、数多くのソフトウエアモジュールからな
り、これらのモジュールは、できればJAVA^TMプログラミング言語によって記述さ
れたものがよい。

【００１９】 一般的に、分散型プロセッシングシステム内のアプリケーションが、他のコー
ルに対する返り値としての名前の検索により、或いは、他の方法によって、分散
型リソースへのリファレンスを取得し、当該リソースへアクセスするためにシー
クするたびに、そのアプリケーションは、リソース又はそのリソースを管理する
MIコンポーネントに対してコールする。そのMIコンポーネントは、管理用MIコン
ポーネントと称され、そのリソースへの未処理のリファレンスの数を見失わない
ように監視する。リソースへのリファレンスの数がゼロになると、管理用MIコン
ポーネントは、リソースを再生することができる。リソースへのリファレンス数
は、一般的に、"リファレンスカウント"と称され、リファレンスカウントを増加
させるコールは、"ダーティーコール"と称される。

【００２０】 アプリケーションが分散型リソースをもはや要求しない場合には、リソース又
は管理用MIコンポーネントに異なったコールを送信する。このコールを受信する
と、管理用MIコンポーネントは、そのリソース用のリファレンスカウントを減少
させる。リファレンスをドロップさせるこのコールは、"クリーンコール"と称さ
れる。

【００２１】 本発明の一実施形態によれば、ダーティーコールは、リソースへのリファレン
スのために、リクエストされたタイムインターバル及びコールされたリースピリ
オドを含むことができる。ダーティーコールを受信すると、管理用MIコンポーネ
ントは、リースが許可されるピリオドを示すリターンコールを送信する。従って
、管理用MIコンポーネントは、未処理のリファレンスの数と同様に、それらのリ
ファレンスのためのリースピリオドを監視する。その結果、リソースへのリファ
レンスカウントがゼロになったとき、又は、リソースへのリースピリオドが終了
したときに、管理用MIコンポーネントは、そのリソースを再生することができる
。

【００２２】Ｂ．手順 MIコンポーネント内のアプリケーションコールプロセッサは、図１に示したア
プリケーションコール手順１００を実行する。管理用MIコンポーネント内のサー
バコールプロセッサは、図２から図４に示した手順２００、３００、４００の各
工程を実行する。管理用MIコンポーネントのガベージコレクタは、従来の手順を
実行してサーバコールプロセッサからの命令に基づいて既にリファレンスにバイ
ンドされたリソースを再生する。ガベージコレクタの従来の手順については説明
を省略する。

【００２３】 １．アプリケーションコールプロセッサ 図１は、分散型プロセッシングシステム内に配置された同一又は他のMIコンポ
ーネントにより管理されるリソースへのリファレンス用のアプリケーションリク
エストを処理するために、MIコンポーネントのアプリケーションコールプロセッ
サが用いる手順１００のフローチャートを示したものである。

【００２４】 アプリケーションがリソースへのリファレンスを取得した後、アプリケーショ
ンコールプロセッサは、ダーティーコールを送信するが、このダーティーコール
は、そのリソース用の管理用MIコンポーネントに対するリソースへのリファレン
ス、リクエストされたリースピリオドを含む（ステップ１１０）。ダーティーコ
ールは、リソース又は管理用MIコンポーネントに対するものであればよい。

【００２５】 アプリケーションコールプロセッサは、次に、管理用MIコンポーネントコンポ
ーネントからのリターンコールを待ち、これを受信する（ステップ１２０）。リ
ターンコールは、許可されたリースピリオドを含み、この間、管理用MIコンポー
ネントは、ダーティーコールのリファレンスが、そのリソースへバインドされる
のを保障する。換言すれば、管理用MIコンポーネントは、許可ピリオドにおいて
は、ダーティーコールのリファレンスに対応するリソースを収集しないことに応
じる。管理用MIコンポーネントが許可ピリオドを配信しない場合又はリース用の
リクエストを拒否した場合には、アプリケーションコールプロセッサは、許可ピ
リオドを受信するまで他のダーティーコールを送信しなければならない。

【００２６】 アプリケーションコールプロセッサは、アプリケーションによるリファレンス
の使用を監視し、リファレンスがもはや必要ではなくなったことをアプリケーシ
ョンがアプリケーションコールプロセッサに明示的に通知する場合又はアプリケ
ーションコールプロセッサがこの決定をそれ自身で行う場合に（ステップ１３０
）、アプリケーションコールプロセッサは、クリーンコールを管理用MIコンポー
ネントへ送信する（ステップ１４０）。ダーティーコールに用いられる方法と同
様の方法で、クリーンコールは、リファレンスされたリソースに対して行うこと
ができ、管理用MIコンポーネントがクリーンコールを処理することになる。その
後に、アプリケーションコールプロセッサは、リファレンスのリストからアプリ
ケーションにより用いられているリファレンスを削除する（ステップ１５０）。

【００２７】 アプリケーションがリファレンスを終えていない場合には（ステップ１３０）
、アプリケーションコールプロセッサは、リファレンスに対する許可ピリオドが
終了しかけているか否かを判断し（ステップ１６０）、アプリケーションコール
プロセッサは、工程１１０から１２０までを繰り返し実行して、アプリケーショ
ンのかわりに管理用MIコンポーネントにより、リソースへのリファレンスが管理
されることを確保する。

【００２８】２．サーバコールプロセッサ MIコンポーネントのサーバコールプロセッサは、３つの主要手順、すなわち、
（１）ダーティーコールの処理、（２）到来するクリーンコールの処理、（３）
適当な時期にリソースを再生するためにガベージコレクションサイクルの初期化
を実行する。

【００２９】 （i）ダーティーコール 図２は、リソースをリファレンスするリクエスト、例えば、MIソフトウエアコ
ンポーネントが管理するダーティーコールを処理するために、MIコンポーネント
のサーバコールプロセッサが使用する手順２００のフローチャートである。これ
らのリクエストは、分散型プロセッシングシステムのMIコンポーネントのアプリ
ケーションコールプロセッサから到来し、その分散型プロセッシングシステムは
、リクエストを処理するサーバコールプロセッサと同一のMIコンポーネントのア
プリケーションコールプロセッサを含む。

【００３０】 まず、サーバコールプロセッサは、ダーティーコールを受信する（ステップ２
１０）。サーバコールプロセッサは、次に、受け入れ可能な許容ピリオドを決定
する（ステップ２２０）。許容ピリオドは、リクエストされたリースピリオド又
は他のタイムピリオドと同一でもよい。サーバコールプロセッサは、要求された
リソースの量と、同一のリソース用に前に許可された他の許可ピリオドの数とに
基づいて、適当な許可ピリオドを決定する。

【００３１】 サーバコールプロセッサは、リソースが未だダーティーコールのリファレンス
に割り当てられていないと判断する場合には（ステップ２３０）、サーバコール
プロセッサは、要求されたリソースを割り当てる（ステップ２４０）。

【００３２】 サーバコールプロセッサは、次に、ダーティーコールのリファレンスに対応す
るリファレンスカウントを増加し（ステップ２５０）、受入可能な許可ピリオド
をリファレンス−リソースのバインドに設定し（ステップ２６０）、許可ピリオ
ドと一緒にリターンコールをアプリケーションコールプロセッサに送信する（ス
テップ２７０）。このようにして、サーバコールプロセッサは、その制御下でリ
ソースへのリファレンスについて到来するダーティーコールを制御する。

【００３３】 アプリケーションは、現在のリースが終了する前にダーティーコールを延長リ
クエストと一緒に送信することによってリースを延長することができる。手順２
００に示したように、リースを延長するためのリクエストは、リース用の初期化
リクエストと同様に取り扱われる。延長は、リソースがリファレンスカウントが
ゼロにならない限り、ただ単にタイムインターバルの追加によっては再生されな
いことを意味する。

【００３４】 （ii）クリーンコール MIコンポーネントのサーバコールプロセッサは、アプリケーションコールプロ
セッサから到来するクリーンコールをも処理する。分散型プロセッシングシステ
ム内のアプリケーションがもはやリソースへのリファレンスを要求しなくなった
場合には、アプリケーションは、そのリファレンス用にリソースを管理するMIコ
ンポーネントに、そのリソースが再生して再使用できることを通知する。

【００３５】 サーバコールプロセッサは、MIコンポーネントが管理するリソースへのリファ
レンスとクリーンコールとを受信して（ステップ３１０）、対応するリファレン
スカウントを減少させる（ステップ３２０）。クリーンコールは、リソースに送
信されるが、その際、サーバコールプロセッサはリソースを監視し、コール処理
のための手順３００が実行される。その後、サーバコールプロセッサは、クリー
ンコールを送信したMIコンポーネントに、受信承認としてリターンコールを送信
する。本発明の実装形態によれば、リファレンスをドロップさせるクリーンコー
ルを拒否できないが、承認しなければならない。

【００３６】 （iii）ガベージコレクション サーバコールプロセッサは、リソースを再生するためにガベージコレクション
サイクルの初期化をも行う。このため、より多くのリファレンスがリソースに対
してなされていないか又はリソースへの合意済みリースピリオドが終了したかを
判断する。図４に示した手順４００は、サーバコールプロセッサがガベージコレ
クションサイクルを初期化するために用いるステップのフローチャートである。

【００３７】 サーバコールプロセッサは、リファレンスカウントと許可されたリースピリオ
ドとを監視し、MIコンポーネントによって管理されるリソースへのリファレンス
カウントがゼロなのか又はリファレンス用の許可ピリオドが終了したのかを判断
する（ステップ４１０）。どちらかの状態が存在する場合には、サーバコールプ
ロセッサは、そのリソースのガベージコレクションを初期化する（ステップ４２
０）。そうでない場合には、リファレンスカウントと許可されたリースピリオド
とを監視し続ける。

【００３８】Ｃ．コールフロー 図５は、分散型プロセッシングシステムのMIコンポーネントにおけるコールフ
ローを説明するための図である。管理用MIコンポーネント５２５は、リソース５
３０へのリファレンスを監視することによりリソース５３０を管理する（ガベー
ジコレクト５０５参照）。管理用MIコンポーネント５２５がリソースを管理する
ため、管理用MIコンポーネント５２５のサーバコールプロセッサは、このコール
フロープログラムのオペレーションを実行する。

【００３９】 図５は、アプリケーション５１０，５４０がそれぞれ対応するMIコンポーネン
トコンポーネント５１５，５４５を有することをも示す。各アプリケーション５
１０，５４０は、リソース５３０のうちいずれかへのリファレンスを取得し、シ
ークしてリソース５３０のうちいずれかとのアクセスを取得し、これにより、リ
ファレンスは対応するリソースへバインドされることになる。アクセスを取得す
るために、アプリケーション５１０，５４０は、それぞれ対応するMIコンポーネ
ント５１５，５４５を呼出し、それぞれダーティーコール５５１，５７１をMIコ
ンポーネント５２５へ送信する。MIコンポーネント５１５，５２５は、管理用MI
コンポーネント５２５等の他のMIコンポーネントにより管理されるリソース５３
０へのアクセスを行うためにアプリケーションリクエストを処理するため、MIコ
ンポーネント５１５，５４５のアプリケーションコールプロセッサは、このコー
ルフロープログラムのオペレーションを実行する。

【００４０】 ダーティーコール５５１，５７１に応答して、管理用MIコンポーネント５２５
は、それぞれリターンコール５５２，５７２を、それぞれMIコンポーネント５１
５，５４５に送信する。ダーティーコールは、ダーティーコール５５１，５７１
のリファレンス用に許可されたリースピリオドを含む。

【００４１】 同様に、図５は、更に、クリーンコール５６１，５８１をそれぞれ管理用MIコ
ンポーネント５２５に送信するMIコンポーネント５１５，５４５を示す。クリー
ンコール５６１，５８１は、アプリケーション５１０，５４０がそれぞれクリー
ンコール５６１，５８１内で指定されたリソースへのアクセスをもはや要求しな
いということを、管理用MIコンポーネント５２５に対して通知する。管理用MIコ
ンポーネント５２５は、クリーンコール５６１，５８１に対してそれぞれリター
ンコール５６２，５８２を用いて応答する。リターンコール５６２，５８２は、
リターンコール５５２，５７２とは異なり、MIコンポーネント５２５が受信した
クリーンコール５６１，５８１の単なる受信承認に過ぎない。

【００４２】 アプリケーション５１０，５４０は、両者とも、同一リソースへのアクセスを
要求することができる。例えば、アプリケーション５１０は、"リソース(1)"へ のアクセスをリクエストすることができるが、一方でアプリケーション５４０が
、以前にそのリソースへのアクセスが許可されていたということがある。MIコン
ポーネント５２５は、一致したリースピリオドの間、アプリケーション５１０，
５４０の両者に対して有効なリソースを作ることにより、この状況を処理する。
従って、MIコンポーネント５２５は、アプリケーション５１０，５４０の両者が
リソースへのリファレンスをドロップさせるか、最新の一致したピリオドが終了
するかのいずれかが発生するまでは、"リソース(1)"を再生するためにガベージ コレクションサイクルを初期化しないことになる。

【００４３】 同一のリソースへ同時にアクセスするために複数のアプリケーションを許可す
ることによって、本発明は、リソースへのリファレンスをドロップさせる管理用
MIコンポーネントへクリーンコールを送信した後に、アプリケーションがリソー
スへアクセスすることをも許可する。これが発生するのは、リソースが依然とし
て他のアプリケーションによって参照されているか、又は、リファレンスのリー
スがまだ終了していないために管理用MIコンポーネント５２５がまだリソースを
再生していないからである。しかしながら、リソースは、より多くのアプリケー
ションがどれもリースを保持しない場合又は最後のリースが終了した場合に、制
限ピリオドの後、再生されることになる。

【００４４】Ｄ．MIコンポーネント 図６は、本発明の一実施形態に係るMIコンポーネント６００を構成するモジュ
ールのブロック図である。MIコンポーネント６００は、監視されるリファレンス
用のリファレンスコンポーネント６０５、アプリケーションコールプロセッサ６
４０、サーバコールプロセッサ６５０及びガベージコレクタ６６０を含むことが
できる。

【００４５】 リファレンスコンポーネント６０５は、リファレンスデータポーション６１０
、リファレンス６２０、許可ピリオドレジスタ６３０を備えたテーブル又はこれ
と同様の構造体から構成される。MIコンポーネント６００は、対応するリファレ
ンスデータポーション６１０内で指定された各リファレンス用にリファレンスカ
ウント６２０と許可ピリオド６３０とを使用して、対応するリソースを再生する
には、いつガベージコレクタ６６０を初期化すればよいかを判断する。

【００４６】 アプリケーションコールプロセッサ６４０は、ソフトウエアモジュールであり
、図１に示した手順１００の各ステップを実行する。サーバコールプロセッサ６
５０は、ソフトウエアモジュールであり、図２から図４に示した手順２００，３
００，４００の各ステップを実行する。ガベージコレクタ６６０は、ソフトウエ
アモジュールであり、上述したようにサーバコールプロセッサ６５０からの命令
に応じてリソースを再生する。

【００４７】Ｅ．分散型プロセッシングシステム 図７は、本発明を実装するのに使用可能な分散型プロセッシングシステム５０
を示したものである。図７においては、分散型プロセッシングシステム５０は、
３つの独立した異種のプラットフォーム１００，２００，３００を含み、これら
は、ネットワーク雲５５によって表されるネットワークコンフィギュレーション
内で連結されている。図７の雲５５により表されるネットワークコンフィギュレ
ーションの構成及びプロトコルは、プラットフォーム７００，８００，９００の
間での情報通信が可能である限り余り重要ではない。加えて、これらの３つのプ
ラットフォームは、説明のために例示したものであるため、本発明におけるプラ
ットフォームの使用を特定数に限定するものではない。更に、本発明については
、専用のネットワークアーキテクチャは重要ではない。例えば、本発明に従って
使用可能な他のネットワークアーキテクチャとしては、あらゆるプラットフォー
ムが連結可能なネットワークコントローラのような単一のプラットフォームを使
用するものでもよい。

【００４８】 分散型プロセッシングシステム５０の実装においては、プラットフォーム７０
０，８００，９００は、各々、プロセッサ７１０，８１０，９１０をそれぞれ備
えるほか、メモリ７５０，８５０，９５０をそれぞれ備える。各プロセッサ７１
０，８１０，９１０の各々には、アプリケーション７２０，８２０，９２０、オ
ペレーティングシステム７４０，８４０，９４０、MIコンポーネント７３０，８
３０，９３０がそれぞれ含まれる。

【００４９】 アプリケーション７２０，８２０，９２０は、プログラムにより構成でき、こ
のプログラムは、予め作成されたものを本発明に従って作動するように修正され
たものか又は本発明によって得られるサービスの効果を得るべく専用に作成され
たものであればよい。

【００５０】 MIコンポーネント７３０，８３０，９３０は、図６を参照して説明したように
MIコンポーネント６００に対応している。

【００５１】 オペレーティングシステム７０，８４０，９４０は、それぞれ対応するプロセ
ッサ７１０，８１０，９１０に連結された標準オペレーティングシステムである
。プラットフォーム７００，８００，９００は、異種でもよい。例えば、プラッ
トフォーム７００は、プロセッサ７１０としてサンマイクロシステムズ インコ
ーポレーテッド製のUltraSparc（登録商標）マイクロプロセッサを備え、Solari
s（登録商標）オペレーティングシステム７４０を使用している。プラットフォ ーム８００は、プロセッサ８１０としてシリコングラフィックス インコーポレ
ーテッド製のMIPSマイクロプロセッサを備え、Unixオペレーティングシステム８
４０を使用している。そして、プラットフォーム９００は、プロセッサ９１０と
してインテル コーポレーテッド製のペンティアムマイクロプロセッサを備え、
マイクロソフトウインドウズ９５オペレーティングシステム９４０を使用してい
る。本発明は、これに限定されるものではなく、異種のプラットフォームを適用
することも可能である。

【００５２】 Sun、Sun Microsystems、Solaris、Java、the SunLogoは、米国又はその他の 国におけるサンマイクロシステムズ インコーポレーテッドの商標又は登録商標
である。UltraSparc及び他の全てのSPARC商標は、米国又はその他の国において ライセンス契約の下で使用されており、スパークインターナショナル インコー
ポレーテッドの商標である。SPARC商標を付した製品は、サンマイクロシステム ズ インコーポレーテッドにより開発されたアーキテクチャに基づいたものであ
る。

【００５３】 メモリ７５０，８５０，９５０は種々の機能、例えば、関連付けられたプラッ
トフォーム用の全体の記憶領域を提供する。他の機能は、各プロセッサ７１０，
８１０，９１０による実行前に、アプリケーション７２０，８２０，９２０、MI
コンポーネント７３０，８３０，９３０及びオペレーティングシステム７２０，
８４０，９４０を記憶することである。加えて、メモリ７５０，８５０，９５０
の各部分は、ネットワーク５０の全プラットフォーム７００，８００，９００に
有効な共有メモリからなる。

【００５４】Ｅ．メソッド呼出サービス 本発明はクライアント／サーバモデルを使用して実装することができる。クラ
イアントは、ダーティーコール、クリーンコール等のリクエストを生成し、サー
バはリクエストに対して応答を返す。

【００５５】 図７に示したMIコンポーネント７３０，８３０，９３０の各々は、クライアン
トコンポーネントとサーバコンポーネントの両者を含む。図８は、クライアント
プラットフォーム１０００及びサーバプラットフォーム１１００のブロック図で
あり、図７に示したプラットフォーム７００，８００，９００のうちいずれか２
つに適用される。

【００５６】 プラットフォーム１０００，１１００は、それぞれメモリ１０５０，１１５０
、プロセッサ１０１０，１１１０を保持する。プラットフォーム１０００，１１
００に含まれる要素は、図７を参照して説明した要素と同様の手法で機能する。
この例においては、プロセッサ１０１０は、クライアントアプリケーション１０
２０を実行し、プロセッサ１１１０は、サーバアプリケーション１１２０を実行
する。プロセッサ１０１０，１１１０は、更に、それぞれオペレーティングシス
テム１０４０，１１４０及びMIコンポーネント１０３０，１１３０を実行する。

【００５７】 MIコンポーネント１０３０，１１３０は、各々、サーバコールプロセッサ１０
３１，１１３１、アプリケーションコールプロセッサ１０３２，１１３２、ガベ
ージコレクタ１０３３，１１３３を含む。MIコンポーネント１０３０，１１３０
は、その各々が監視する各リファレンスとして、リファレンスデータポーション
１０３４，１１３４、リファレンスカウント１０３５，１１３５、許可ピリオド
レジスタ１０３６，１１３６を含むリファレンスコンポーネントをも含む。

【００５８】 アプリケーションコールプロセッサ１０３２，１１３２は、それぞれクライア
ントサービスを象徴し、これらの各々は、サーバサービスを象徴するサーバコー
ルプロセッサ１０３１，１１３１の各々と情報通信を行う。プラットフォーム１
０００，１１００は、サーバコールプロセッサ、アプリケーションコールプロセ
ッサ、ガベージコレクタ、リファレンスコンポーネントを保持しているため、プ
ラットフォームは、クライアント又はサーバのいずれかとして動作可能である。

【００５９】 しかしながら、以下の説明においては、プラットフォーム１０００はクライア
ントプラットフォームと呼ばれ、プラットフォーム１１００はサーバプラットフ
ォームと呼ばれる。この例においては、クライアントアプリケーション１０２０
は、分散型リソースへのリファレンスを取得するとともにMIコンポーネント１０
３０を使用してサーバプラットフォーム１１００のMIコンポーネントにより管理
されるリソースへダーティーコールを送信する。

【００６０】 更に、サーバプラットフォーム１１００は、サーバアプリケーション１１２０
を実行することができる。サーバアプリケーション１１２０は、MIコンポーネン
ト１１３０を使用してダーティーコールを送信することもでき、このダーティー
コールは、ダーティーコールのリソースがMIコンポーネント１１３０により管理
される場合に、MIコンポーネント１１３０によって処理される。

【００６１】 従って、クライアントプラットフォーム１０００のMIコンポーネント１０３０
用のサーバコールプロセッサ１０３１、ガベージコレクタ１０３３及びリファレ
ンスカウンタ１０３５は、アクティブではなく、図８においては陰を付けて表示
されている。同様に、サーバプラットフォーム１１００のMIコンポーネント１１
３０のアプリケーションコールプロセッサ１１３２も休止中であるため陰を付し
て表示されている。

【００６２】 クライアントアプリケーション１０２０がリソースに対応するリファレンスを
取得する場合には、アプリケーションコールプロセッサ１０３２は、ダーティー
コールを送信し、サーバコールプロセッサ１１３１がこれを受信する。ダーティ
ーコールは、リクエストされたリースピリオドを含む。サーバコールプロセッサ
１１３１は、ダーティーコール内のリファレンス用にリファレンスカウント１１
３５を増加し、許可ピリオドを決定する。これに応答して、サーバコールプロセ
ッサ１１３１は、リターンコールを許可ピリオドとともに、アプリケーションコ
ールプロセッサ１０３０へ送信する。アプリケーションコールプロセッサ１０３
２は、許可ピリオドを使用して記録された許可ピリオド１０３５を更新し、いつ
ダーティーコールのリファレンスに対応するリソースを再生するかを決定する。

【００６３】 サーバコールプロセッサ１１３１は、更に、それが管理するリソースへのリフ
ァレンスに対応するリファレンスカウントと許可ピリオドとを監視する。リファ
レンスカウント１１３５のうちの一つがゼロになるか、又は、リファレンス用の
許可ピリオド１１３５が終了するかのいずれか最初のイベントが起こった時に、
サーバコールプロセッサ１１３１は、ガベージコレクタ１１３３を初期化して、
ゼロのリファレンスカウント又は終了した許可ピリオドを保持するリファレンス
に対応するリソースを再生することができる。

【００６４】 本発明の一実施形態によるリースされたリファレンスの概念は、プラットフォ
ーム１０００，１１００のプロトコル上でクロックの同期を必要としない。その
概念は、それらが同等の増加周期であることを要求するに過ぎない。リースは、
特定のタイミングでは終了しないが、特定のタイムインターバルで終了するもの
である。そのインターバルがほぼ正確に一致している限り、プラットフォーム１
０００，１１００は、許可されたリースピリオドについてほぼ正確に一致する。
更に、コンピュータ周期におけるリースタイミングは比較的長いため、クロック
速度のモニタ差異は殆どないか又は影響がない。

【００６５】 ダーティーコールの転送時間は、プロトコルに影響を及ぼす。MIコンポーネン
ト１０３０がリファレンス用のリースを保持し、リースが終了して更新リクエス
トをする直前までウエイトするとすれば、リースは、MIコンポーネント１１３０
がリクエストを受信する前に終了する。そうだとすれば、MIコンポーネント１１
３０は、更新リクエストを受信する前にリソースを再生することができる。従っ
て、ダーティーコールを送信する場合には、リソースへのリースピリオドが終了
する前に、更新されたダーティーコールが作成されるようにするために、送信元
では、ダーティーコールのリソースを処理するプラットフォームへの転送時間を
考慮に入れて、リクエストされたリースピリオドにタイムファクターを追加すべ
きである。

【００６６】Ｆ．結論 本発明による分散型ガベージコレクションの概念によれば、分散型プロセッシ
ングシステムのリソースへのリファレンスに対応する許可されたリースピリオド
を配信することにより、リファレンスの保全性が保障され、メモリリークが排除
される。具体的には、許可されたリースピリオドが終了したときに、リソースへ
のリファレンスを付すことによってなされる。その後、リソースは収集される。
リソースは、分散型プロセッシングシステムのプロセスによってリファレンスさ
れなくなった場合に、リソース用にリファレンスに割り当てられたカウンタへの
リファレンスとともに収集することもできる。

【００６７】本発明の変形例 上述したリーステクニックは、ガベージコレクションに関するものである。し
かしながら、以下に説明するように、本発明の他の実施形態もまた、アクティベ
ーショングループのオブジェクトメンバシップを統制するのに使用可能である。

【００６８】 Java^TMプログラミング環境("典型的な分散型システム")を利用する分散型シス
テムにおいては、オブジェクトは、リモート呼出可能なメソッドを保持する。こ
ららのメソッドは、カリフォルニア州のマウンテンビューにあるサンマイクロシ
ステムズ インコーポレーテッド製のJavaソフトウエア開発キットの一部として
販売されているJava^TMリモートメソッド呼出システム（RMI）を使用するクライ アントによって呼び出すことができる。典型的な分散型システムにおいては、ク
ライアントがリモートオブジェクト上でメソッドを呼び出す場合に、オブジェク
トはリモートマシン上のメモリ内に存在しない場合がある。この場合には、RMI のアクティベーションデーモンとして知られるリモートマシン上のコンポーネン
トがJava^TM仮想マシン（JVM）を始動させる。Java仮想マシンもまた、Javaソフ トウエア開発キットの一部として配布され、その詳細については、本出願につい
て参照されるアジソンウェズレイ社（1997）発行のリンドホルム、イェリン共著
のJava仮想マシン仕様に説明されている。"アクティベーションオブジェクト"に
より、オブジェクトは、補助記憶装置からメモリへ移送され、リクエストされた
メソッドが呼び出される。注目すべきは、オブジェクト及びJVMは、両者共、単 一アドレス空間で走行することである。メモリに存在しないリモートオブジェク
トのメソッドがクライアントによりコールされる度に、このプロセスが繰り返し
なされる。典型的な分散型システムの詳細については、既に参照文献として紹介
した審査に係属中の米国特許出願No. 、発明の名称「分散型システムにお けるダイナミック検索サービス」に説明されている。

【００６９】 オブジェクトを一度にそれら自身のアドレス空間へ移送する欠点は、能率が上
がらないことである。各オブジェクトが別個のアドレス空間へロードされるため
、ロードされたオブジェクトは、他のロードされたオブジェクトにアクセスする
ためにプロセス境界を横断しなければならない。この横断には多くの処理時間が
かかる。従って、プロセス境界を横断するのを回避するとともに局所的リファレ
ンスを容易にするには、関連オブジェクトを同一アドレス空間へロードするのは
、有益である。他の実施形態においては、関連オブジェクトは、オブジェクトグ
ループ又はオブジェクトセットにグループ分けされる。グループのオブジェクト
が互いに関連付けられるため、同一のJVM上で走行することは効率的であり、そ の結果、同一同一アドレス空間となる。同一のJVM上で走行させることにより、 関連オブジェクトは、互いにより効率的にアクセスすることができる（すなわち
、プロセス境界の横断がなくなる）。

【００７０】 関連オブジェクトがグループ化された状況では、クライアントプログラムがリ
モートオブジェクト上のメソッドを呼び出す場合に、アクティベーションデーモ
ンは、当該リモートオブジェクトがアクティベーショングループとして知られる
リモートオブジェクトグループのメンバであるか否かを判断する。オブジェクト
がアクティベーショングループに属し、そのグループがメモリ内にまだロードさ
れていない場合には、アクティベーションデーモンは、JVMを始動させ、オブジ ェクトをJVMの当該アドレス空間へロードする。その後の当該アクティベーショ ングループの他のオブジェクト上でのメソッドの呼出により、アクティベーショ
ンデーモンは、これらのオブジェクトを同一アドレス空間へロードする。リクエ
ストされたオブジェクトが一旦JVMにロードされると、アクティベーションデー モンは、オブジェクトを活性化させ、リクエストされたメソッドが呼び出される
。

【００７１】 JVM内に関連するオブジェクトを一緒にグループ化することの欠点は、特定の オブジェクトがアクティベーショングループの有用リソースを独占し、他のグル
ープメンバに悪影響を与えることである。例えば、カーソルオブジェクトを使用
するディスプレイの共有エリアを抜き出す複数オブジェクトを保持するホワイト
ボードプログラムにおいては、カーソルオブジェクトは、誰かが使用したがって
いるオブジェクトのアクティベーショングループへロードされる。カーソルオブ
ジェクトを誰かが使用したがっているオブジェクトと同一のアドレス空間へ配置
することにより、カーソルは、コマンドに対して素早く応答することができるが
、その理由は、カーソルオブジェクトは、プロセス境界を横断することなくアク
セスされるからである。しかしながら、誰かが使用したがっているカーソルオブ
ジェクトを特定のオブジェクトが独占し、そのことが他のオブジェクトに悪影響
を与える場合に問題が起こる。

【００７２】 当該他の実施形態によれば、リーステクニックをアクティベーショングループ
に配置されたオブジェクトに適用することにより、当該独占による脅威を排除す
る。リースにより、アクティベーショングループのオブジェクトは、一つも他の
オブジェクトを独占しないということが保障される。例えば、各オブジェクトは
、アクティベーショングループ（すなわち、アクティベーショングループ内にメ
ンバシップを獲得する）に加わるためにリースをリクエストしなければならない
。アクティベーショングループは、それ自身は、リースをどれくらいの時間長さ
許可するかを決定する。ホワイトボードプログラムに対しては、アクティベーシ
ョングループは、非常に短いリースを許可することになる。これにより、オブジ
ェクトが一つもカーソルオブジェクトを独占しないことが保障され、各オブジェ
クトのリースが終了した場合には当該オブジェクトは、アクティベーショングル
ープから追い出される。

【００７３】 当該他の実施形態においては、オブジェクトは、アクティベーショングループ
のメンバとなるべきリースをリクエストする。オブジェクトは、メンバシップと
なる所定時間（リースピリオド）を指定しなければならない。また、オブジェク
ト（アクティベーショングループオブジェクト）により表現され且つ管理される
アクティベーショングループは、リースをどのくらいの時間長さ許可するかを決
定する。所定時間に加えて、リースリクエストは、オブジェクトが正確なリース
を欲しがっているか否かの表示を保持する。リースをリクエストする場合には、
オブジェクトは、正確なリースピリオドをリクエストすることができる。この場
合には、許可されたリースピリオドがリクエストされた完全なリースピリオドで
ある場合にのみ、アクティベーショングループは、オブジェクトに対するリース
を許可することになる。

【００７４】 全オブジェクトは、アクティベーショングループ内のリースにより統制される
。リースが終了した場合でさえ、オブジェクトが異なるアクティベーショングル
ープのメンバになるためのリクエストをするまで、オブジェクトにはそれ自体の
アクティベーショングループのメンバシップが与えられている。

【００７５】 一旦、オブジェクトがアクティベーショングループからリースをリクエストす
ると、アクティベーショングループは、オブジェクトにリースオブジェクトを返
す。このリースオブジェクトは、リース時間の決定メソッド、リース更新メソッ
ド及びリースのキャンセルメソッドを含む。オブジェクトは、クラスのインスタ
ンスであり、より多くのファンクションを提供するために多くの手法で拡張する
ことができるが、ベーシッククラスは以下の表１のように定義される。

【表１】

【００７６】 このクラスは、期間取得メソッド、更新メソッド及びリカバリメソッドを含む
。"期間取得"メソッドを呼び出すことにより、許可されたリースピリオドの長さ
をオブジェクトに配信する。このピリオドは、アクティベーショングループによ
り許可された最新のリースを表している。しかしながら、リース上で未処理とな
っている時間量の決定は、クライアントの応答性によるところとなる。

【００７７】 "更新"メソッドは、リモートオブジェクトがリースを更新するのを許可するも
のであり、オリジナルリースリクエストを再初期化することなく、より多くの時
間を要求することができる。クライアントがリースの更新を所望する場合として
は、オリジナルリースが不十分になった場合（すなわち、リモートオブジェクト
がより多くのメンバシップを要求する場合）や、一部のリースのみが許可された
場合（すなわち、要求されたリースより少ない場合）がある。

【００７８】 オブジェクトは、更新メソッドを使用して、追加的なリースピリオドを要求す
るか又は多くの追加のリースピリオドが許可されるまで、継続的に更新メソッド
を何度も呼び出す。更新メソッドには戻り値がない。更新が許可されると、新た
なリースピリオドは、コールがなされたリースオブジェクトに反映される。アク
ティベーショングループがリースを更新することができない場合又は更新しよう
としない場合には、その原因がそのコールがなされたリースオブジェクトに示さ
れる。

【００７９】 オブジェクトは、当該オブジェクトがアクティベーショングループから抜け出
そうとする場合に"キャンセル"メソッドを呼び出させるが、リース上にはまだ時
間が残っている。キャンセルメソッドにより、アクティベーショングループは、
当該アクティベーショングループからオブジェクトを除去することができる。そ
の結果、当該オブジェクトはプロセス境界を横断することなく当該アクティベー
ショングループの全オブジェクトにアクセスすることができない。これに対し、
リースの終わりにおいては（すなわち、正常終了）、アクティベーショングルー
プは、オブジェクトを追い出すことを承知している。この場合、オブジェクトは
、リースの正常切断の際にアクティベーショングループに通知する義務はない。

【００８０】 図９は、本発明の他の実施形態による使用に好適なデータ処理システム９００
０を示す。データ処理システム９０００は、ネットワーク９００６を介して第二
コンピュータシステム９００４に連結されたコンピュータシステム９００２を含
む。ネットワーク９００６は、ローカルエリアネットワーク、ワイドエリアネッ
トワーク又はインターネットであればよい。

【００８１】 コンピュータシステム９００２は、メモリ９００８、補助記憶デバイス９０１
０、中央処理ユニット（CPU）９０１２、入力デバイス９０１６、ビデオディス プレイ９０１４を含む。メモリ９００８は、更に、Java^TMランタイムシステム９
０４２を含み、Java^TMランタイムシステム９０４２は、Java仮想マシン（JVM） 、RMI９０４６及びアクティベーショングループ９０４０を含む。アクティベー ショングループ９０４０は、未だ活性化されない状態で第二記憶デバイス９０１
０に残っているものに関連付けられるいくつかのオブジェクト９０４８を保持す
ることができる。加えて、メモリ９００８は、JVM９０２４、RMI９０２６及びア
クティベーショングループ９０１８を含むJavaランタイムシステム９０２２、及
び、アクティベーションデーモン９１００、JVM９０１４及びRMI９０１６を含む
Javaランタイムシステム９１０２を含む。アクティベーションデーモン９１００
は、アクティベーショングループ９０４０又はアクティベーショングループ９０
１８のいずれかの一部分となるべきメモリへそれらを移送することにより、活性
化オブジェクト９０４８に応答可能である。

【００８２】 コンピュータシステム９００４は、メモリ９０５０、補助記憶デバイス９０５
２、CPU９０５４、入力デバイス９０５８及びビデオディスプレイ９０５６を含 む。メモリ９０５０は、更に、JVM９０６４、RMI9066及びクライアントプログラ
ム９０４０を含むJavaランタイムシステム９０６２を含み、クライアントプログ
ラム９０６０は、RMI９０６６へのコールを介してリモートオブジェクト（例え ば、オブジェクト９０４８の一つ）のメソッドの呼出をリクエストすることがで
きる。データ処理システム９０００及びコンピュータ９００２，９００４が追加
の又は異なるコンポーネントを保持可能であることは、いわゆる当業者にとって
は周知である。

【００８３】 上述した当該他の実施形態の要旨は、メモリに記憶させたものとして説明した
が、いわゆる当業者にとっては、これらの要旨を他のコンピュータ読取可能な媒
体、例えば、補助記憶装置（ハードディスク、フロッピーディスク、コンパクト
ディスク・読出オンリメモリ）；インターネットからの伝送波、又はランダムア
クセスメモリや読出オンリメモリ等の他の媒体、に記憶させても、又は、これら
から読み出してもよいことは周知である。更に、当該他の実施形態はJava^TMプロ
グラミング環境で動作するものとして説明したが、いわゆる当業者にとっては、
当該他の実施形態が他の環境においても同様に動作することは周知である。

【００８４】 図１０は、新たなアクティベーショングループのメンバになるためにオブジェ
クトにより実行されるステップのフローチャートを示す。例えば、アクティベー
ショングループ９０４０のオブジェクトは、アクティベーショングループ９０１
８のメンバになろうとする。オブジェクトは、処理を実行する際にアクティベー
ショングループ９０１８（すなわち、グラフィック関連の処理）に関連付けられ
ることを欲し、しかも、グラフィックオペレーションを実行するオブジェクトを
保持するアクティベーショングループ内で走行することにより局所的リファレン
スの利点を獲得することを欲するからである。新たなアクティベーショングルー
プのメンバになるためには、オブジェクトはリースリクエストをアクティベーシ
ョングループ９０１８へ送信する（ステップ１０００４）。このステップにおい
ては、オブジェクトはリースリクエストをアクティベーショングループへ送信す
る。そのアクティベーショングループは、オブジェクトであり、リクエストされ
たリースピリオドを含むパラメータの数を通過させる。

【００８５】 リースリクエストを送信した後、オブジェクトは、リースが成功したかどうか
をリースオブジェクトを受信したか否かを判断することにより判断する（ステッ
プ１０００６）。リースが成功した場合には、オブジェクトは、アクティベーシ
ョンデーモン９１００へアクティベーショングループ９０１８との新たな関連づ
けを通知する（ステップ１０００８）。アクティベーションデーモンへ通知する
場合、オブジェクトは、リースオブジェクトの複製を配信する。このリースオブ
ジェクトの複製は、リースピリオドの長さを判断するのにアクティベーションデ
ーモンによって使用可能である。アクティベーションデーモンに通知した後、オ
ブジェクトアクティベーショングループ９０１８の一部として走行する（ステッ
プ１００１０）。このステップにおいては、オブジェクトが活性化されると、オ
ブジェクトは、Javaランタイムシステム９０２２上で実行されることになる。暫
くの後、オブジェクトは、アクティベーショングループの一部としてより多くの
時間が必要か否かを判断する（ステップ１００１２）。オブジェクトがより多く
の時間を必要とするならば、オブジェクトは、リースリクエストを介して返され
るリースオブジェクト上で更新メソッドを呼び出す（ステップ１００１４）。そ
の後、オブジェクトは、更新リクエストが成功したか否かを判断する（ステップ
１００１６）。成功した場合には、処理はステップ１００１０へ続く。成功しな
かった場合には、処理が終了する。

【００８６】 オブジェクトがより多くの時間を必要としない場合には、オブジェクトにリー
スを中断させるために、リースオブジェクト上でキャンセルメソッドを呼び出す
（ステップ１００１８）。このステップは、リースをキャンセルし、その結果、
アクティベーショングループ内のオブジェクトのメンバシップをキャンセルする
。次に、オブジェクトは、他のアクティベーショングループ、おそらくはアクテ
ィベーショングループ９０４０に対するリースを取得する。そのリースはそこか
ら到来するものである。オブジェクトが他のアクティベーショングループへ加わ
わらない場合には、オブジェクトは次の機会に活性化され、アクティベーション
デーモンは、オブジェクトを、そのデーモン自体のアクティベーショングループ
のメンバにすることになる。

【００８７】 図１１は、オブジェクトを活性化する場合、例えば、クライアントプログラム
９０６０がRMI９０６６を呼び出してリモートオブジェクト（すなわち、オブジ ェクト９０４８の一つ）上でメソッドを呼び出すような場合に、アクティベーシ
ョンデーモンによって実行されるステップのフローチャートを示したものである
。アクティベーションデーモン９１００によって最初に実行されるステップは、
RMI９１０６からのリクエストを受信することである（ステップ１１００２）。R
MI９１０６は、クライアント９０６０からのリモートメソッドコールの結果とし
て呼び出すことができる。クライアント９０６０がリモートメソッドを呼び出す
場合には、RMI９０６６を介して行う。RMI９０６６がリモートメソッドを呼び出
した後、呼出用に使用したスタブは、情報通信用オブジェクトのネットワークポ
ートを、アクティベーションデーモン９１００へのリファレンスとともに保持す
る。従って、リモートメソッドを呼び出すためのリクエストを受信する場合には
、RMI９０６６は、まず最初に、オブジェクトネットワークポートを介してメソ ッドを呼び出そうとする。成功した場合には、オブジェクトは、RMI９０６６を 介したメソッドの一つの最後の呼出以降ずっと、そのアクティブ状態が維持され
るとともに、それがメモリに存在している状態が維持される。しかしながら、こ
れが失敗した場合には、RMI９０６６は、RMI９１０６を介してリクエストをアク
ティベーションデーモン９１００へ送信する。その理由は、オブジェクトを活性
化する必要があるからである。

【００８８】 RMI９１０６からのリクエストを受信した後、アクティベーションデーモンは 、オブジェクト用のリースが終了したか否かを判断する（ステップ１０００４）
。当該他の実施形態においては、各オブジェクトはアクティベーショングループ
のメンバであり、通常は、未処理のリースを有することができる。アクティベー
ションデーモン９１００は、コンピュータ９００２内において、全オブジェクト
についての当該各オブジェクトが関連付けられる対応するアクティベーショング
ループに対するマッピング状態を維持する。アクティベーションデーモンがリー
スが終了したと判断した場合には、アクティベーションデーモンは、リクエスト
されたオブジェクトをそれ自身のアクティベーショングループへ配置する（ステ
ップ１１００６）。このステップにおいては、アクティベーションデーモンは、
リクエストされたオブジェクトがそれ自身のアクティベーショングループのメン
バであることの表示を保存する。オブジェクトをそれ自身のアクティベーション
グループへ配置した後、アクティベーションデーモンは、JVMを始動させオブジ ェクトを活性化する（ステップ１１００８）。このステップにおいては、アクテ
ィベーションデーモンは、JVMを始動させ、補助記憶装置９０１０からJVMのアド
レス空間へオブジェクトをロードする。更に、アクティベーションデーモンオブ
ジェクト上でリクエストされたメソッドを呼び出す。

【００８９】 アクティベーションデーモンにより、リースが終了していないと判断された場
合には、アクティベーションデーモンは、オブジェクトがメンバであるアクティ
ベーショングループが現在JVMを走行中であるか否かを判断する（ステップ１１ ０１０）。終了したと判断された場合には、アクティベーションデーモンは、ア
クティベーショングループ用にJVMを始動させ（ステップ１１０１２）、アクテ ィベーションデーモンは、次に、オブジェクトを活性化させる（ステップ１００
１４）。このステップにおいては、アクティベーションデーモンにより、補助記
憶装置からのオブジェクトがメモリ（始動したJVMのアドレス空間）へ移送され 、リクエストされたメソッドが呼び出される。

【００９０】 図１２は、オブジェクトがリースをリクエストする場合に、アクティベーショ
ングループにより実行されるステップのフローチャートを示す（すなわち、９０
１８）。アクティベーショングループにより実行される最初のステップは、リク
エストの優先順位を確認するためのリースリクエストのパラメータを検査するこ
とである（ステップ１２００４）。上述したように、パラメータは、リクエスト
されたリースピリオド及び正確なリースの表示を含む。

【００９１】 パラメータを検査した後、アクティベーショングループは、リクエストが完全
であるか否かを判断する（ステップ１２００６）。例えば、アクティベーション
グループは、所望のリースピリオドが指定されたことを確認し、正確なリースが
リクエストされた場合には、アクティベーショングループは、当該アクティベー
ショングループがリクエストを許可できるか否かを判断する。例えば、アクティ
ベーショングループは、オブジェクトがリクエストした正確なリースに当てられ
る所定時間の間、リースを許可しようとしない。アクティベーショングループが
、リースリクエストが不完全であると判断した場合には、アクティベーショング
ループは、エラーを表示する例外オブジェクトを返し（ステップ１２００８）、
処理は終了する。

【００９２】 リクエストが完全である場合には、アクティベーショングループは、十分なリ
ースピリオドであるか判断する（ステップ１２０１０）。アクティベーショング
ループは、次に、リースオブジェクトを生成し、それをリモートオブジェクトに
返す（ステップ１２０１２）。

【００９３】 以上の本発明の実施形態の説明は、説明及び開示を目的としたものである。本
発明は、開示された詳細な形態により用い尽くされるものではなく、また、これ
に限定されるものではない。上述した開示を考慮すれば種々の変形例や改変は可
能であり、また、このような変形例や改変は、本発明の実施形態から必要に応じ
て導き出される。例えば、上述した実施形態は、ソフトウエアを含むものである
が、本発明は、ハードウエアとソフトウエアとの組合せにおいて又はハードウエ
アのみにおいて、実装することができる。本発明の範囲は、特許請求の範囲及び
関連するその他の記載によって定義される。

【図面の簡単な説明】 本明細書に組み込まれてその一部をなす添付図面は、本発明の実施形態を図示
するとともに、本明細書の説明と一体となって、本発明の利点及び趣旨を説明す
るためのものである。

【図１】 図１は、本発明の一実施の形態に係るアプリケーションコールプロセッサによ
って実行される工程のフローチャートである。

【図２】 図２は、本発明の一実施の形態に係るダーティーコールを処理するサーバコー
ルプロセッサによって実行される工程のフローチャートである。

【図３】 図３は、本発明の一実施の形態に係るクリーンコールを処理するサーバコール
プロセッサによって実行される工程のフローチャートである。

【図４】 図４は、本発明の一実施の形態に係るガベージコレクション処理を初期化する
サーバコールプロセッサによって実行される工程のフローチャートである。

【図５】 図５は、分散型プロセッシングシステムにおけるコールの好適なフローを示し
た図である。

【図６】 図６は、本発明に係るメソッド呼出サービスに実装されるコンポーネントを示
したブロック図である。

【図７】 図７は、本発明の一実施形態において使用される分散型プロセッシングシステ
ムの構成を示した図である。

【図８】 図８は、本発明の一実施形態に係る分散型プロセッシングシステムのプラット
フォームに含まれる個々のソフトウエアコンポーネントを示した図である。

【図９】 図９は、本発明の他の実施形態において使用されるデータプロセッシングシス
テムを示した図である。

【図１０】 図１０は、本発明の他の実施形態に係り、アクティベーショングループを変更
する場合にオブジェクトによって実行される工程を示したフローチャートである
。

【図１１】 図１１は、図９のアクティベーションデーモンにより実行される工程を示した
フローチャートである。

【図１２】 図１２は、本発明の他の実施形態に係り、リモートオブジェクトがアクティベ
ーショングループのメンバシップをリクエストする場合にアクティベーショング
ループによって実行される工程を示したフローチャートである。

【手続補正書】特許協力条約第３４条補正の翻訳文提出書

【提出日】平成１２年４月１８日（２０００．４．１８）

【手続補正１】

【補正対象書類名】明細書

【補正対象項目名】特許請求の範囲

【補正方法】変更

【補正内容】

【特許請求の範囲】

【手続補正２】

【補正対象書類名】明細書

【補正対象項目名】０００１

【補正方法】変更

【補正内容】

【０００１】 （関連出願） 参考のために示すが、本出願は、1998年11月3日に発行された米国特許No.5,83
2,529号、発明の名称「分散型ガベージコレクションのための方法、装置及びプ ロダクト」の関連出願である。また、本出願は、2000年1月18日に発行された米 国特許No.6,016,500号、発明の名称「故障検知のためのリース」の関連出願であ
る。

【手続補正３】

【補正対象書類名】明細書

【補正対象項目名】０００２

【補正方法】変更

【補正内容】

【０００２】 （背景技術） Ａ．発明の属する技術分野 本発明は、データ処理システムに関し、更に詳しくは、データ処理システムに
おけるオブジェクトのグループメンバシップのリースに関する。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ) ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ， ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，Ｄ Ｋ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ， ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，Ｌ Ｔ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ， ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，Ｕ Ａ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＷ (71)出願人 2550 Ｇａｒｃｉａ Ａｖｅｎｕｅ，ＭＳ ＰＡＬ１−521，Ｍｏｕｎｔａｉｎ Ｖ ｉｅｗ，Ｃａｌｉｆｏｒｎｉａ 94043− 1100，Ｕｎｉｔｅｄ Ｓｔａｔｅｓ ｏｆ Ａｍｅｒｉｃａ (72)発明者 ウォールラス アン エム アメリカ合衆国、01450 マサチューセッ ツ州、グロトン、ノースウッズ ロード ９ (72)発明者 シェフラー ロバート アメリカ合衆国、02144 マサチューセッ ツ州、サマビレ、ノース ストリート 96 (72)発明者 アーノルド ケネス シー アール シー アメリカ合衆国、02173 マサチューセッ ツ州、レキシントン、ムーン ヒル ロー ド ７ Ｆターム(参考） 5B045 EE23 GG01 GG06 5B060 AA10 AC06 5B098 AA10 GD00 GD03 GD11 GD14 GD15 GD22

Claims (1)

【特許請求の範囲】
1. 【請求項１】 オブジェクトのアクティベーショングループ及びリクエスト
   されたリースピリオドを指定するリースリクエストをリモートオブジェクトから
   受信するリースピリオド受信工程と、 前記リモートオブジェクトが前記アクティベーショングループのメンバとなる
   時間長さであるリースピリオドを決定するリースピリオド決定工程と、からなる
   ことを特徴とする処理システムにおけるデータ処理方法。