(57)【特許請求の範囲】
【請求項１】
プロセッサーを用いて、リソースを参照し、かつ要求されたリース期間を指定するプロセスからの要求を受信する受信工程と、
前記プロセッサーを用いて、承認されたリース期間、前記リソースに対する共有アクセスを許可する許可工程と、
前記プロセッサーを用いて、前記プロセスに前記承認されたリース期間を通知する通知工程と、
前記プロセッサーを用いて、前記承認されたリース期間が終了した時に前記リソースの割当を解除する割当解除工程とを備えていることを特徴とする分散ガーベッジコレクションのためのリソースの管理方法。
【請求項２】
前記許可工程は、前記要求されたリース期間よりも短い期間となるように前記承認されたリース期間を決定するサブ工程を備えていることを特徴とする請求項１に記載される分散ガーベッジコレクションのためのリソースの管理方法。
【請求項３】
前記許可工程は、前記要求されたリース期間、前記リソースの大きさ、及び前記リソースのための他の承認されたリース期間の少なくとも一つに基づき、前記承認されたリース期間を決定するサブ工程を備えていることを特徴とする請求項１に記載される分散ガーベッジコレクションのためのリソースの管理方法。
【請求項４】
前記許可工程は、前記リソースがそれ以前に割り当てられなかったという決定に基づいて前記リソースを割り当てるサブ工程を備えていることを特徴とする請求項１に記載される分散ガーベッジコレクションのためのリソースの管理方法。
【請求項５】
前記許可工程は、前記リソースに対応するリファレンスカウントを増加させるサブ工程を備え、前記リファレンスカウントは、現在、どれだけ多くのプロセスが前記リソースに対するリファレンスを持っているかを示すものであることを特徴とする請求項１に記載される分散ガーベッジコレクションのためのリソースの管理方法。
【請求項６】
前記プロセスがある識別されたリソースに対するアクセスの終了を望んでいることを示す前記プロセスからの第２の要求を受信する工程と、前記識別されたリソースに対応する前記リファレンスカウントを減少させる工程とをさらに備えたことを特徴とする請求項５に記載される分散ガーベッジコレクションのためのリソースの管理方法。
【請求項７】
前記割当解除工程は、前記リソースに対する共有アクセスがもはや要求されない時に、前記リソースをリクレームするためのガーベッジコレクションプロセスを呼び出すサブ工程を備えていることを特徴とする請求項１に記載される分散ガーベッジコレクションのためのリソースの管理方法。
【請求項８】
前記割当解除工程は、前記リファレンスカウントが前記識別されたリソースに、現在、いかなるプロセスもアクセスしていないことを示している時に、前記識別されたリソースの割当を解除するためのガーベッジコレクションプロセスを呼び出すサブ工程を備えていることを特徴とする請求項６に記載される分散ガーベッジコレクションのためのリソースの管理方法。
【請求項９】
プロセッサーを用いて、あるリース期間、あるリソースに対してアクセスすることをプロセスから要求する工程と、
前記プロセッサーを用いて、前記リソースに対する共有アクセスが許可されている間、承認されたリース期間を前記プロセスから受信する工程と
前記プロセッサーを用いて、前記承認されたリース期間が終わりかけているが、前記リソースへのアクセスが完了していないという決定に基づいて、新たなリース期間の要求を前記プロセスに対して送信する工程とを備えていることを特徴とする分散ガーベッジコレクションのためのリソースの管理方法。
【請求項１０】
前記承認されたリース期間が終了する前に、前記リソースに対する共有アクセスがもはや要求されないことを示す異なる要求を送信する工程をさらに備えていることを特徴とする請求項９に記載される分散ガーベッジコレクションのためのリソースの管理方法。
【請求項１１】
リソースを参照し、かつ要求されたリース期間を指定するプロセスからの要求を受信するように構成された受信モジュールと、
承認されたリース期間、前記リソースへの共有アクセスを許可するように構成されたリソースアロケーターと、
前記プロセスに前記承認されたリース期間を通知するように構成された通知モジュールと、
前記承認されたリース期間が終了した時に前記リソースの割当を解除するように構成されたリソースディアロケーターと、を実行するよう構成可能なプロセッサーを備えていることを特徴とする分散ガーベッジコレクションのための装置。
【請求項１２】
前記リソースアロケーターは、前記要求されたリース期間よりも短い期間となるように前記承認されたリース期間を決定するように構成された決定モジュールを備えていることを特徴とする請求項１１に記載される分散ガーベッジコレクションのための装置。
【請求項１３】
前記リソースアロケーターは、前記要求されたリース期間、前記リソースの大きさ、及び前記リソースのための他の承認されたリース期間の少なくとも一つに基づき、前記承認されたリース期間を決定するように構成された決定モジュールを備えていることを特徴とする請求項１１に記載される分散ガーベッジコレクションのための装置。
【請求項１４】
前記リソースアロケーターは、前記リソースがそれ以前に割り当てられなかったという決定に基づいて前記リソースを割り当てるように構成された割当モジュールを備えていることを特徴とする請求項１１に記載される分散ガーベッジコレクションのための装置。
【請求項１５】
前記リソースアロケーターは、前記リソースに対応するリファレンスカウントを増加させるように構成された増加モジュールを備え、前記リファレンスカウントは、現在、どれだけ多くのプロセスが前記リソースに対するリファレンスを持っているかを示すものであることを特徴とする請求項１１に記載される分散ガーベッジコレクションのための装置。
【請求項１６】
前記プロセスがある識別されたリソースに対するアクセスの終了を望んでいることを示す前記プロセスからの第２の要求を受信するように構成された第２受信モジュールと、前記識別されたリソースに対応する前記リファレンスカウントを減少させるように構成された減少モジュールとをさらに備えたことを特徴とする請求項１５に記載される分散ガーベッジコレクションのための装置。
【請求項１７】
前記リソースディアロケーターは、前記リソースに対する共有アクセスがもはや要求されない時に、前記リソースをリクレームするためのガーベッジコレクションプロセスを呼び出すように構成されたインボーカーを備えていることを特徴とする請求項１１に記載される分散ガーベッジコレクションのための装置。
【請求項１８】
前記リソースディアロケーターは、前記リファレンスカウントが前記識別されたリソースに、現在、いかなるプロセスもアクセスしていないことを示している時に、前記識別されたリソースの割当を解除するためのガーベッジコレクションプロセスを呼び出すように構成されたインボーカーを備えていることを特徴とする請求項１６に記載される分散ガーベッジコレクションのための装置。
【請求項１９】
あるリース期間、あるリソースに対してアクセスすることをプロセスから要求するように構成された要求モジュールと、
前記リソースに対する共有アクセスが許可されている間、承認されたリース期間を前記プロセスから受信するように構成された受信モジュールと
前記承認されたリース期間が終わりかけているが、前記リソースへのアクセスが完了していないという決定に基づいて、新たなリース期間についての他の要求を、前記プロセスに対して送信するように構成された第２送信モジュールと、を実行するよう構成可能なプロセッサーを備えていることを特徴とする分散ガーベッジコレクションのための装置。
【請求項２０】
前記承認されたリース期間が終了する前に、前記リソースに対する共有アクセスがもはや要求されないことを示す異なる要求を送信するように構成された第２送信モジュールをさらに備えていることを特徴とする請求項１９に記載される分散ガーベッジコレクションのための装置。
【請求項２１】
コンピュータプロセッサーと、前記コンピュータプロセッサーと有効に接続されているメモリーと、前記メモリーにより前記コンピュータプロセッサー中で実行するコンピュータプロセスを備え、前記コンピュータプロセスは、リソースを参照し、かつ要求されたリース期間を指定するプロセスからの要求を受信するように構成された受信モジュールと、承認されたリース期間、前記リソースに対する共有アクセスを許可するように構成されたリソースアロケーターと、前記承認されたリース期間を通知するように構成された通知モジュールと、前記承認されたリース期間が終了した時に前記リソースの割当を解除するように構成されたリソースディアロケーターとを備えていることを特徴とする分散ガーベッジコレクションのためのコンピュータシステム。
【請求項２２】
前記リソースアロケーターは、前記要求されたリース期間よりも短い期間となるように前記承認されたリース期間を決定するように構成された決定モジュールを備えていることを特徴とする請求項２１に記載される分散ガーベッジコレクションのためのコンピュータシステム。
【請求項２３】
前記リソースアロケーターは、前記要求されたリース期間、前記リソースの大きさ、及び前記リソースのための他の承認されたリース期間の少なくとも一つに基づき、前記承認されたリース期間を決定するように構成された決定モジュールを備えていることを特徴とする請求項２１に記載される分散ガーベッジコレクションのためのコンピュータシステム。
【請求項２４】
前記リソースアロケーターは、前記リソースがそれ以前に割り当てられなかったという決定に基づいて前記リソースを割り当てるように構成された割当モジュールを備えていることを特徴とする請求項２１に記載される分散ガーベッジコレクションのためのコンピュータシステム。
【請求項２５】
前記リソースアロケーターは、前記リソースに対するリファレンスを現在有しているプロセスの数を示すように構成されたリファレンスカウントモジュールを備えていることを特徴とする請求項２１に記載される分散ガーベッジコレクションのためのコンピュータシステム。
【請求項２６】
前記コンピュータプロセスは、前記プロセスがある識別されたリソースに対するアクセスの終了を望んでいることを示す前記プロセスからの第２の要求を受信するように構成された第２受信モジュールと、前記識別されたリソースに対応する前記リファレンスカウントを減少させるように構成された減少モジュールとをさらに備えていることを特徴とする請求項２５に記載される分散ガーベッジコレクションのためのコンピュータシステム。
【請求項２７】
前記リソースディアロケーターは、前記リソースに対する共有アクセスがもはや要求されない時に、前記リソースをリクレームするためのガーベッジコレクションプロセスを呼び出すように構成されたインボーカーを備えていることを特徴とする請求項２１に記載される分散ガーベッジコレクションのためのコンピュータシステム。
【請求項２８】
前記リソースディアロケーターは、前記リファレンスカウントが前記識別されたリソースに、現在、いかなるプロセスもアクセスしていないことを示している時に、前記識別されたリソースの割当を解除するためのガーベッジコレクションプロセスを呼び出すように構成されたインボーカーを備えていることを特徴とする請求項２６に記載される分散ガーベッジコレクションのためのコンピュータシステム。
【請求項２９】
コンピュータプロセッサーと、前記コンピュータプロセッサーと有効に接続されているメモリーと、前記メモリーにより前記コンピュータプロセッサー中で実行するコンピュータプロセスを備え、前記コンピュータプロセスは、あるリース期間、あるリソースに対してアクセスすることをプロセスから要求するように構成された要求モジュールと、前記プロセスが前記リソースに対する共有アクセスを許可している間、承認されたリース期間を前記プロセスから受信するように構成された受信モジュールと、前記承認されたリース期間が終わりかけているという決定に基づいて、新たなリース期間についての他の要求を、前記プロセスに対して送信するように構成された送信モジュールとを備えていることを特徴とする分散ガーベッジコレクションのためのコンピュータシステム。
【請求項３０】
前記コンピュータプロセスは、前記承認されたリース期間が終了する前に、前記リソースに対する共有アクセスがもはや要求されないことを示す異なる要求を送信するように構成された第２送信モジュールをさらに備えていることを特徴とする請求項２９に記載される分散ガーベッジコレクションのためのコンピュータシステム。
【請求項３１】
複数のプラットフォームを有する分散処理システムにおいて、サーバープラットフォームで実行される以下の工程、すなわち、
（ａ）  第１サーバープラットフォームを用いて、システムリソースに対するリファレンス及び要求されたリース期間を含むリクエスタープラットフォームからの要求であって、前記対応するリクエスタープラットフォームが前記要求中において前記要求された期間、前記リファレンスされたシステムリソースへのアクセスをシークすることを示している要求を受信する工程と、
（ｂ）  前記第１サーバープラットフォームを用いて、
（ｉ）  前記要求された各リース期間に応答して設定される、対応する承認期間であって、要求に関連する前記リファレンスされた各システムリソースが前記プラットフォームによってアクセスされることが可能となる期間を示している承認期間を設定すること、及び
（ｉｉ）  対応するリファレンスカウンターであって、要求の受信によって決定される前記対応するシステムリソースがアクセスしている前記プラットフォームの数を示しているリファレンスカウンターを増加させること、
により前記リファレンスされた各システムリソースを割り当てる工程と、
（ｃ）  前記第１サーバープラットフォームを用いて、関連する要求に応答して、関連する要求中でリファレンスされた前記リソースのための前記承認期間を指定する前記リクエスタープラットフォームに対する応答を送信する工程と、
（ｄ）  前記第１サーバープラットフォームを用いて、
（ｉ）  リファレンスされた各システムリソースのための前記承認期間が終了した時、又は
（ｉｉ）  前記対応するリファレンスカウンターが、いかなるリクエスタープラットフォームも、現在、前記リファレンスされた各システムリソースに対するアクセスをシークしていないということを示す状態である時に、
前記リファレンスされた各システムリソースの割当を解除するためのガーベッジコレクションプロセスを起動する工程とを備えたことを特徴とする分散ガーベッジコレクションのためのプラットフォーム間に分散したリソースの割当及び割当解除方法。
【請求項３２】
（ｅ）  前記第１サーバープラットフォームを用いて、前記システムリソースに対するリファレンスを含み、かつ前記リクエスタープラットフォームが前記システムリソースに対するアクセスの終了を要求することを示している前記リクエスタープラットフォームからの新しい要求を受信する工程と、
（ｆ）  前記第１サーバープラットフォームを用いて、前記新しい要求において指定された前記リファレンスされた各システムリソースに対応する前記リファレンスカウンターを減少させる工程とをさらに備えていることを特徴とする請求項３１に記載される分散ガーベッジコレクションのためのプラットフォーム間に分散したリソースの割当及び割当解除方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、一般に、コンピューターシステムのためのガーベッジコレクションに関し、更に詳しくは、リファレンスと結合し、あるいは関連しているリソースを収集するための耐故障性の分散ガーベッジコレクションの方法に関する。
【０００２】
【従来の技術】
適切なリソース管理は、コンピュータの効率的及び効果的使用のための重要な観点である。一般に、リソース管理には、適切な時、例えば、要求者がもはやリソースを要求しない時にリソースの割り当てを解除することのみならず、要求に応じてリソース（例えば、メモリー）を割り当てることも含まれる。一般に、リソースには、コンピュータ内で実行する演算の構成要素（例えば、アプリケーション、プログラム、アプレットなど）によって引用されるデータが含まれる。
【０００３】
実際には、コンピュータ上で実行しているアプリケーションがリソースを参照するためにシークする時には、コンピュータは、アプリケーションが適切にそれらを参照することができるように、最初にリソースを割り当てるか、あるいは指定しなければならない。アプリケーションが、もはやリソースを参照しないときは、コンピュータは、再使用のためにそのリソースの割り当てを解除するか、あるいはリクレームすることができる。コンピュータ内では、各リソースは、それによってそのリソースが引用可能な唯一の「ハンドル」を持っている。そのハンドルは、アドレス、配列インデックス、特有の値、ポインター等のような、様々な方法によって与えられる。
【０００４】
リソース管理は、１台のコンピュータにとっては比較的単純である。なぜならば、アプリケーションがもはやそれらを参照しない時、あるいは停電後のように、リソースがリクレームされることができる時を示す事象は、決定することが容易だからである。多数のコンピュータを接続した分散システムのためのリソース管理は、数台の異なるコンピュータ内のアプリケーションが同一のリソースを使っていることもあるので、より困難である。
【０００５】
分散システムの分断は、不適切かつ先走ったリソースのリクレーム、あるいはリソースのリクレームの失敗の原因となる。例えば、分散システムにおいて異なるコンピュータ上で実行されている多数のアプリケーションは、他の機械上に配置されているリソースを参照するかもしれない。もし、リソースが配置されているコンピュータと、それらのリソースを参照しているアプリケーションとの間の接続が途切れるならば、コンピュータは、早まってそのリソースをリクレームすることもあり得る。代わりに、コンピュータは、アプリケーションがそのリソースにアクセスすることに失敗してから長期間経過しているにもかかわらず、永続的にそのリソースを保持することもありうる。
【０００６】
これらの問題は、ネットワークリソースを管理するためのシステムの発展をもたらし、その一つは、「分散ガーベッジコレクション」として知られている。この用語は、ネットワーク中の異なるコンピュータ上で実行されている一つのアプリケーションあるいはアプリケーション群によって用いられているリソースを自動的に管理する、分散システムのための言語又は実行時間システムによって与えられる機能を表している。
【０００７】
一般に、ガーベッジコレクションは、リソースがもはやアプリケーションのいかなる部分によっても引用されない時に、リソースは、将来の使用のために開放されるという概念を用いている。分散ガーベッジコレクションは、いかなるコンピュータ上のアプリケーションもリソースを参照しない時にリソースをリクレームすることにより、この概念を、分散コンピューティングの領域に拡張する。
【０００８】
分散ガーベッジコレクションは、割り当てられたリソースとそれらのリソースのリファレンスとの間の保全性を保持しなければならない。換言すれば、そのシステムは、ネットワーク中のいずれかのコンピュータ上で実行されているアプリケーションがそのリソースの参照を続けている時には、リソースの割り当てを解除したり、あるいはリソースを開放することが許されない。「リファレンスの保全性」と称するこのリファレンスとリソースの結合は、リファレンスが参照するリソースへのアクセスを常に承認するということことを保証するものではない。例えば、ネットワークの故障は、そのようなアクセスを不可能にする。しかしながら、保全性は、もし、そのリファレンスがいずれかのリソースへのアクセスを得るために用いられたならば、そのリソースは、そのリファレンスが最初に与えられたリソースと同一のリソースであるということを保証するものである。
【０００９】
ガーベッジコレクションが用いられる分散システムは、また、有限の未来におけるある時点においてもはや引用されなくなったリソースをリクレームしなければならない。換言すれば、そのシステムは、「記憶漏れ」に対する保証を与えなければならない。記憶漏れは、全てのアプリケーションがリソースに対するリファレンスを落としたが、例えば、いくつかのアプリケーションが未だそのリソースを参照しているという誤った決定をしたために、システムが、再使用のためにリソースをリクレームすることに失敗した時に生ずる。
【００１０】
リファレンスの保全性の故障と記憶漏れは、しばしば、リソースを引用しているアプリケーションとそれらのリソースの割当及び割当解除を管理しているガーベッジコレクションシステムとの間の分断の原因となる。例えば、リソースを参照しているアプリケーションとそのリソースを管理しているガーベッジコレクションシステムとの間のネットワーク結合の分断は、ガーベッジコレクションシステムが、リソースのリクレームをすべきか否か及びリソースをいつリクレームすべきかを決定することを妨げるかもしれない。代わりとして、ガーベッジコレクションシステムは、アプリケーションが予め定められた時間内にリソースにアクセスしなかったので、そのリソースを収集してもよいということを誤って決定するかもしれない。
【００１１】
分散ガーベッジコレクションのメカニズムが記憶漏れを起こすことなくリファレンスの保全性を保持するということを保証することを試みることにより、その分散ガーベッジコレクションのメカニズムを改善するために、多くのテクニックが用いられている。一つのありふれたアプローチは、リファレンスカウントの形式を用いている。そこでは、カウントは、各リソースを参照しているアプリケーションの数を保持している。リソースのカウントがゼロになるとき、ガーベッジコレクションシステムは、そのリソースをリクレームすることができる。
【００１２】
しかしながら、そのようなリファレンスカウントの機構は、リソースが対応するリファレンスカウンターと共に作られる時にのみ動作する。この場合、ガーベッジコレクションシステムは、追加のアプリケーションがそのリソースを参照するときには、そのリソースのリファレンスカウントを増加させ、あるアプリケーションがもはやそのリソースを参照しない時には、カウントを減少させる。
【００１３】
しかしながら、リファレンスカウントの機構は、特に、分散システムにおいて故障を生ずるという問題に直面している。そのような故障は、リソースはもはや引用されないということをガーベッジコレクションシステムに知らせるメッセージの伝達を妨げる、コンピュータもしくはアプリケーションの故障、又はネットワークの故障という形をとる。もし、メッセージがネットワークが分断しているために伝達されないならば、不要情報収集システムは、いつリソースをリクレームすべきかわからない。
【００１４】
そのような故障を避けるために、いくつかのありふれたリファレンスカウントの機構には、「キープアライブ」メッセージが含まれている。これは、また、「ピンバック」とも称されている。この機構によれば、ネットワーク中のアプリケーションは、リソースを監視しているガーベッジコレクションシステムに対してメッセージを送り、そのアプリケーションがなお通信可能であることを示す。これらのメッセージは、ガーベッジコレクションシステムがリソースに対するリファレンスを落とすのを妨げる。
【００１５】
そのような「キープアライブ」メッセージの受信の失敗は、ガーベッジコレクションシステムが、あるリソースのためのリファレンスカウントを減少させることができること、そしてすなわち、そのカウントがゼロになるときは、ガーベッジコレクションシステムは、そのリソースをリクレームするかもしれないということを意味している。しかしながら、これは、ネットワークが故障しているために、「キープアライブ」メッセージを受け取ることに失敗したことから、リファレンスカウントがゼロへ到達し、それに続いて、リソースの早まったリクレームが生ずる。これは、リファレンスの保全性の必要条件を乱すものである。
【００１６】
ガーベッジコレクションシステムにおけるリファレンスの保全性の問題を解決するために提案された他の方法は、リファレンスカウントのみならず、リソースを参照するコンピュータの各構成要素に対応する識別子もまた保持することである。Ａ．Ｂｉｒｒｅｌｌ他、「ネットワークの目的物のための分散ガーベッジコレクション」、Ｎｏ．１１６、ディジタル  システムス  リサーチ  センター、１９９３年１２月１５日参照。
【００１７】
この方法は、リファレンスカウントの機構と同一の問題に悩まされている。さらに、この方法は、分散形システム内で不必要な通信を増加させ、かつ記憶のための必要条件（すなわち、各リソースを参照するアプリケーションに対応する識別子のリスト）を追加するオーバーヘッドを付加した唯一の識別子を、各リソースを参照するコンピュータの各構成要素に与えることを必要とする。
【００１８】
【発明が解決しようとする課題】
本発明が解決しようとする課題は、記憶条件の追加や不必要な通信の増大を招くことなく、リファレンスの保全性が維持され、かつ記憶漏れを起こすことのない分散ガーベッジコレクションのためのリソースの管理方法、装置、コンピュータプログラム生産物、コンピュータシステム並びにプラットフォーム間に分散したリソースの割当及び割当解除方法を提供することにある。
【００１９】
【課題を解決するための手段】
上記課題を解決するために、本発明に係る分散ガーベッジコレクションのためのリソースの管理方法は、リソースを参照し、かつ要求されたリース期間を指定するプロセスからの要求を受信する受信工程と、承認されたリース期間、前記リソースに対する共有アクセスを許可する許可工程と、前記プロセスに前記承認されたリース期間を通知する通知工程と、前記承認されたリース期間が終了した時に前記リソースの割当を解除する割当解除工程とを備えていることを要旨とするものである。
【００２０】
また、本発明に係る他の分散ガーベッジコレクションのためのリソースの管理方法は、あるリース期間、あるリソースに対してアクセスすることをプロセスから要求する工程と、前記リソースに対する共有アクセスが許可されている間、承認されたリース期間を前記プロセスから受信する工程と、前記承認されたリース期間が終わりかけているが、前記リソースへのアクセスが完了していないという決定に基づいて、新たなリース期間の要求を前記プロセスに対して送信する工程とを備えていることを要旨とするものである。
【００２１】
本発明に係る分散ガーベッジコレクションのための装置は、リソースを参照し、かつ要求されたリース期間を指定するプロセスからの要求を受信するように構成された受信モジュールと、承認されたリース期間、前記リソースへの共有アクセスを許可するように構成されたリソースアロケーターと、前記プロセスに前記承認されたリース期間を通知するように構成された通知モジュールと、前記承認されたリース期間が終了した時に前記リソースの割当を解除するように構成されたリソースディアロケーターとを備えていることを要旨とするものである。
【００２２】
また、本発明に係る他の分散ガーベッジコレクションのための装置は、あるリース期間、あるリソースに対してアクセスすることをプロセスから要求するように構成された要求モジュールと、前記リソースに対する共有アクセスが許可されている間、承認されたリース期間を前記プロセスから受信するように構成された受信モジュールと前記承認されたリース期間が終わりかけているが、前記リソースへのアクセスが完了していないという決定に基づいて、新たなリース期間についての他の要求を、前記プロセスに対して送信するように構成された第２送信モジュールとを備えていることを要旨とするものである。
【００２３】
本発明に係る分散ガーベッジコレクションのためのコンピュータプログラム生産物は、リソースを管理するために具体化されたコンピュータで読み取り可能なコードを有するコンピュータ使用可能媒体を備えたコンピュータプログラム生産物において、前記コンピュータ使用可能媒体は、リソースを参照し、かつ要求されたリース期間を指定するプロセスからの要求を受信するように構成された受信モジュールと、承認されたリース期間、前記リソースへの共有アクセスを許可するように構成されたリソースアロケーターと、前記承認されたリース期間を通知するように構成された通知モジュールと、前記承認されたリース期間が終了した時に前記リソースの割当を解除するように構成されたリソースディアロケーターとを備えていることを要旨とするものである。
【００２４】
また、本発明に係る他の分散ガーベッジコレクションのためのコンピュータプログラム生産物は、リソースを管理するために具体化されたコンピュータで読み取り可能なコードを有するコンピュータ使用可能媒体を備えたコンピュータプログラム生産物において、前記コンピュータ使用可能媒体は、あるリース期間、あるリソースに対してアクセスすることをプロセスから要求するように構成された要求モジュールと、前記プロセスが前記リソースに対する共有アクセスを許可している間、承認されたリース期間を前記プロセスから受信するように構成された受信モジュールと、前記承認されたリース期間が終わりかけているという決定に基づいて、新たなリース期間についての他の要求を、前記プロセスに対して送信するように構成された送信モジュールとを備えていることを要旨とするものである。
【００２５】
本発明に係る分散ガーベッジコレクションのためのコンピュータシステムは、コンピュータプロセッサーと、前記コンピュータプロセッサーと有効に接続されているメモリーと、前記メモリーにより前記コンピュータプロセッサー中で実行するコンピュータプロセスを備え、前記コンピュータプロセスは、リソースを参照し、かつ要求されたリース期間を指定するプロセスからの要求を受信するように構成された受信モジュールと、承認されたリース期間、前記リソースに対する共有アクセスを許可するように構成されたリソースアロケーターと、前記承認されたリース期間を通知するように構成された通知モジュールと、前記承認されたリース期間が終了した時に前記リソースの割当を解除するように構成されたリソースディアロケーターとを備えていることを要旨とするものである。
【００２６】
また、本発明に係る他の分散ガーベッジコレクションのためのコンピュータシステムは、コンピコンピュータプロセッサーと、前記コンピュータプロセッサーと有効に接続されているメモリーと、前記メモリーにより前記コンピュータプロセッサー中で実行するコンピュータプロセスを備え、前記コンピュータプロセスは、あるリース期間、あるリソースに対してアクセスすることをプロセスから要求するように構成された要求モジュールと、前記プロセスが前記リソースに対する共有アクセスを許可している間、承認されたリース期間を前記プロセスから受信するように構成された受信モジュールと、前記承認されたリース期間が終わりかけているという決定に基づいて、新たなリース期間についての他の要求を、前記プロセスに対して送信するように構成された送信モジュールとを備えていることを要旨とするものである。
【００２７】
さらに、本発明に係る分散ガーベッジコレクションのためのプラットフォーム間に分散したリソースの割当及び割当解除方法は、複数のプラットフォームを有する分散処理システムにおいて、サーバープラットフォームで実行される以下の工程、すなわち、
（ａ）  システムリソースに対するリファレンス及び要求されたリース期間を含むリクエスタープラットフォームからの要求であって、
前記対応するリクエスタープラットフォームが前記要求中において前記要求された期間、前記リファレンスされたシステムリソースへのアクセスをシークすることを示している要求を受信する工程と、
（ｂ）  （ｉ）  前記要求された各リース期間に応答して設定される、対応する承認期間であって、要求に関連する前記リファレンスされた各システムリソースが前記プラットフォームによってアクセスされることが可能となる期間を示している承認期間を設定すること、及び
（ｉｉ）  対応するリファレンスカウンターであって、要求の受信によって決定される前記対応するシステムリソースがアクセスしている前記プラットフォームの数を示しているリファレンスカウンターを増加させること、
により前記リファレンスされた各システムリソースを割り当てる工程と、
（ｃ）  関連する要求に応答して、関連する要求中でリファレンスされた前記リソースのための前記承認期間を指定する前記リクエスタープラットフォームに対する応答を送信する工程と、
（ｄ）  （ｉ）  リファレンスされた各システムリソースのための前記承認期間が終了した時、又は
（ｉｉ）  前記対応するリファレンスカウンターが、いかなるリクエスタープラットフォームも、現在、前記リファレンスされた各システムリソースに対するアクセスをシークしていないということを示す状態である時に、
前記リファレンスされた各システムリソースの割当を解除するためのガーベッジコレクションプロセスを起動する工程とを備えたことを要旨とするものである。
【００２８】
上記構成を有する本発明に係るリソースの管理方法によれば、リファレンスの保全性は、ある一定の期間、すなわち、分散システム中のパーティ、例えば、リソースに対するリファレンスを保持しているアプリケーション及びそのリソースを管理しているガーベッジコレクションシステムが、そのリソースとそのリソースに対するリファレンスとが保証されることについて合意している期間、リソースをリースすることによって、大きな記憶漏れを伴うことなく保証される。
【００２９】
そのリース期間が終了したときには、そのリソースに対するリファレンスが継続するという保証は、消滅し、ガーベッジコレクションシステムにそのリソースをリクレームすることを許可する。なぜならば、そのリソースに対するリファレンスを保持しているアプリケーションと、そのリソースを管理しているガーベッジコレクションシステムは、有限の保証されたリース期間について合意しており、双方とも、いつそのリースが終了するか、すなわちいつその保証が終了するかを知ることができるからである。これにより、リファレンスのリース期間中はリファレンスの保全性が保証され、ネットワークエラーに起因して発生するリソースの開放失敗を回避することが可能となる。
【００３０】
【発明の実施の形態】
以下に、添付した図面の記載に基づいて、本発明の実施の形態を詳細に説明する。可能な限り、同一又は類似の部分について言及する図面及び以下の記述全体を通して、同一の参照番号を使用する。
【００３１】
本発明は、ありふれた分散処理システムの構成によって組織されたコンピュータを用いて実行することができる。しかしながら、本発明を実行するための構成と手順は、ありふれたものではない。なぜならば、それらは、リファレンスの保全性を保証し、記憶漏れを排除する分散ガーベッジコレクション機構を与えるものだからである。
【００３２】
（Ａ．総括）
分散処理システム中にある各コンピュータに配置されている方法呼出要素（以下、「ＭＩ要素」という）が、本発明に係る分散ガーベッジコレクション機構を実行する。ＭＩ要素は、好ましくは、プログラム言語ＪＡＶＡ（登録商標）によって書かれた多くのソフトウェアモジュールからなっている。
【００３３】
一般に、分散処理システム中のアプリケーションが、分散リソースに対するリファレンスを、ネームの索引あるいは他の方法によって、ある他のコールに対するリターン値として取得し、そのリソースへのアクセスをシークする時はいつでも、そのアプリケーションは、そのリソースに対し、あるいはそのリソースを管理するＭＩ要素に対してコールを行う。
【００３４】
マネージングＭＩ要素と呼ばれるこのＭＩ要素は、そのリソースに対して突出しているリファレンス数のトラックをキープする。あるリソースに対するリファレンスの数がゼロの時は、マネージングＭＩ要素は、そのリソースをリクレームすることができる。あるリソースに対するリファレンス数のカウントは、一般に、「リファレンスカウント」と呼ばれており、リファレンスカウントを増加させるコールは、「ダーティーコール」と称される。
【００３５】
アプリケーションが、もはや分散リソースを要求しない時は、アプリケーションは、そのリソースに対しあるいはマネージングＭＩ要素に対して、異なるコールを送信する。このコールの受信に基づき、マネージングＭＩ要素は、そのリソースのリファレンスカウントを減少させる。このリファレンスを落とすためのコールは、「クリーンコール」と称される。
【００３６】
本発明に係る実施の形態によれば、ダーティーコールには、リース期間と呼ばれる、そのリソースに対するリファレンスのための要求された時間間隔を含めることができる。ダーティーコールの受信に基づき、マネージングＭＩ要素は、リースが承認された期間を含んでいるリターンコールを送信する。すなわち、マネージングＭＩ要素は、突出したリファレンスの数と同様に、それらのリファレンスのためのリース期間もトラックする。その結果、あるリソースに対するリファレンスカウントがゼロになった時、あるいはそのリソースのためのリース期間が終了した時には、マネージングＭＩ要素は、そのリソースをリクレームすることができる。
【００３７】
（Ｂ．手順）
ＭＩ要素中のアプリケーションコールプロセッサーは、図１に図示されたアプリケーションコール手順１００のステップを実行する。マネージングＭＩ要素中のサーバーコールプロセッサーは、それぞれ図２〜４に図示される、手順２００、３００及び４００のステップを実行する。マネージングＭＩ要素のガーベッジコレクターは、サーバーコールプロセッサーからの命令に従って、それ以前にリファレンスと結合していたリソースをリクレームするために通常の手順を実行する。従って、ガーベッジコレクターの通常の手順については、説明を省略する。
【００３８】
（１．アプリケーションコールプロセッサー）
図１は、分散処理システム中に配置されている同一又は他のＭＩ要素によって管理されるリソースに対するリファレンスのためのアプリケーションの要求を取り扱うために、ＭＩ要素のアプリケーションプロセッサーが使用する手順１００のフロー図を示したものである。
【００３９】
アプリケーションがあるリソースに対するリファレンスを取得した後、アプリケーションコールプロセッサーは、リソースのリファレンス及び要求されたリース期間を含むダーティーコールを、そのリソースのためのマネージングＭＩ要素に対して送信する（ステップ１１０）。ダーティーコールは、リソースそれ自体に対してあるいはマネージングＭＩ要素に対して向けられる。
【００４０】
次いで、アプリケーションコールプロセッサーは、マネージングＭＩ要素からのリターンコールを待ち、そして受信する（ステップ１２０）。そのリターンコールには、ダーティーコールのリファレンスがそのリソースと結合するであろうということをマネージメントＭＩ要素が保証する期間、すなわち、承認されたリース期間が含まれている。換言すれば、マネージングＭＩ要素は、その承認期間、ダーティーコールのリファレンスに対応するリソースを収集しないことに同意する。もし、マネージングＭＩ要素が承認期間を与えないか、あるいはリースの要求を拒絶するならば、アプリケーションコールプロセッサーは、承認期間を受信するまで、別のダーティーコールを送信しなければならない。
【００４１】
アプリケーションコールプロセッサーは、アプリケーションによるそのリファレンスの使用を監視し、そのアプリケーションが、アプリケーションコールプロセッサーに対し、そのリファレンスがもはや要求されないということを明確に知らせた時、又は、そのアプリケーションプロセッサーが、自分自身でその決定を下したの時のいずれかの時（ステップ１３０）には、アプリケーションコールプロセッサーは、マネージングＭＩ要素に対してクリーンコールを送信する（ステップ１４０）。ダーティーコールに用いられた方法と同様の方法により、クリーンコールは、リファレンスされたリソースに向けられ、マネージングＭＩ要素は、クリーンコールを処理する。続いて、アプリケーションコールプロセッサーは、アプリケーションによって使用されているリファレンスのリストからそのリファレンスを削除する（ステップ１５０）。
【００４２】
もし、アプリケーションが、いまだリファレンスをやめていない（ステップ１３０）が、アプリケーションコールプロセッサーが、そのリファレンスのための承認期間が終了しそうであると判断する場合（ステップ１６０）には、次に、アプリケーションコールプロセッサは、そのリソースに対するリファレンスが、アプリケーションに代わってマネージングＭＩ要素によって保持されているということを保証するために、ステップ１１０とステップ１２０を繰り返す。
【００４３】
（２．サーバーコールプロセッサー）
ＭＩ要素のサーバーコールプロセッサーは、３つの主要な手順を実行する。すなわち、（１）ダーティーコールを処理すること、（２）入ってくるクリーンコールを処理すること、及び（３）適切なときに、リソースをリクレームするためのガーベッジコレクションサイクルを起動させること、である。
【００４４】
（ｉ．ダーティーコール）
図２は、ＭＩソフトウェア要素が管理するリファレンスされたリソースに対する要求、すなわちダーティーコールを処理するために、ＭＩ要素のサーバーコールプロセッサーが使用する手順２００のフロー図である。これらの要求は、分散処理システム中にあるＭＩ要素のアプリケーションコールプロセッサーからくるものであり、そのアプリケーションコールプロセッサーには、要求を処理するサーバーコールプロセッサーと同じＭＩ要素中のアプリケーションコールプロセッサーも含まれている。
【００４５】
最初に、サーバーコールプロセッサーは、ダーティーコールを受信する（ステップ２１０）。次いで、サーバーコールプロセッサーは、受入可能な承認期間を決定する（ステップ２２０）。承認期間は、要求されたリース期間、あるいは他の期間と同一でもよい。サーバーコールプロセッサーは、要求されたリソースの量及び同一のリソースに対してそれ以前に承認された他の多くの承認期間を含む多数の条件に基づいて適切な承認期間を決定する。
【００４６】
リソースがダーティーコールのリファレンスにより未だ割り当てられていないとサーバーコールプロセッサーが判断した時（ステップ２３０）には、サーバーコールプロセッサーは、要求されたリソースを割り当てる（ステップ２４０）。
【００４７】
次いで、サーバーコールプロセッサーは、ダーティーコールのリファレンスに対応するリファレンスカウントを増加させ（ステップ２５０）、リファレンス・リソース結合のための受入可能な承認期間を設定し（ステップ２６０）、アプリケーションプロセッサーに対し承認期間と共にリターンコールを送信する（ステップ２７０）。このようにして、サーバーコールプロセッサーは、その制御下にあるリソースに対するリファレンスに注意しながら、入ってくるダーティーコールを制御する。
【００４８】
アプリケーションは、現在のリースが終了する前に、拡張要求を伴うダーティーコールを送信することによって、リースを延長することができる。手順２００において示したように、リースを拡張するための要求は、リースのための最初の要求と全く同様に扱われる。拡張は、単に、リファレンスカウントがゼロにならない限り、ある付加的な期間、リソースはリクレームされないということを意味するにすぎない。
【００４９】
（ｉｉ．クリーンコール）
ＭＩ要素のサーバーコールプロセッサーは、また、アプリケーションコールプロセッサーから入ってくるクリーンコールも処理する。分散処理システム中のアプリケーションがもはやリソースに対するリファレンスを要求しない時は、アプリケーションは、そのリソースが再使用のためにリクレームされるように、そのリファレンスのためのリソースを管理するＭＩ要素に知らせる。図３は、ＭＩ要素のサーバーコールプロセッサーがクリーンコールを処理するために使用するステップを有する手順３００のフロー図を示している。
【００５０】
サーバーコールプロセッサーが、ＭＩ要素が管理するリソースに対するリファレンスと共にクリーンコールを受信した時（ステップ３１０）は、サーバーコールプロセッサーは、対応するリファレンスカウントを減少させる（ステップ３２０）。クリーンコールは、そのリソースを監視し、かつそのコールを処理するための手順３００を実行するとサーバーコールプロセッサーと共に、そのリソースに送信される。続いて、サーバーコールプロセッサーは、受信を承認するために、クリーンコールを送信しているＭＩ要素に対してリターンコールを送信する（ステップ３３０）。本発明に係る実施の形態によれば、リファレンスを落とすためのクリーンコールは拒絶されないが、承認されなければならない。
【００５１】
（ｉｉｉ．ガーベッジコレクション）
サーバーコールプロセッサーは、また、もはやリソースに対してリファレンスがなされないか、あるいはそのリソースのための合意されたリース期間が終了したかのいずれかを決定したそのリソースをリクレームするために、ガーベッジコレクションサイクルを起動させる。図４に示した手順４００は、サーバーコールプロセッサーがガーベッジコレクションサイクルを起動するために使用するステップのフロー図を示している。
【００５２】
サーバーコールプロセッサーは、リファレンスカウント及び承認されたリース期間を監視し、ＭＩ要素によって管理されているあるリソースについてリファレンスカウントがゼロであるか否か、あるいはあるリファレンスのための承認期間が終了したか否かを決定する（ステップ４１０）。いずれかの条件が存在するときは、サーバーコールプロセッサーは、そのリソースのガーベッジコレクションを起動する（ステップ４２０）。そうでない場合は、サーバーコールプロセッサーは、リファレンスカウントと承認されたリース期間の監視を続行する。
【００５３】
（Ｃ．コールフロー）
図５は、分散処理システム内にあるＭＩ要素間のコールの流れを模式的に表した図である。マネージングＭＩ要素５２５は、リソース５３０に対するリファレンスを監視することによって、リソース５３０を管理する（ガーベッジコレクト５０５参照）。マネージングＭＩ要素５２５は、リソースを管理するので、マネージングＭＩ要素５２５のサーバーコールプロセッサーは、ここに記載されたコールフローの処理を実行する。
【００５４】
図５は、また、アプリケーション５１０及び５４０が、それぞれ、対応するＭＩ要素５１５及び５４５を有していることを示している。各アプリケーション５１０及び５４０は、それぞれ、リソース５３０の内の一つに対するリファレンスを取得し、リファレンスが対応するリソースと結合するように、リソース５３０の内の一つに対するアクセスを取得するためにシークする。
【００５５】
アクセスを取得するために、アプリケーション５１０及び５４０は、ＭＩ要素５２５に対して、それぞれ、ダーティーコール５５１及び５７１を送信するために、それぞれ、対応するＭＩ要素５１５及び５４５を呼び出す。ＭＩ要素５１５及び５４５は、マネージングＭＩ要素５２５のような他のＭＩ要素によって管理されるリソース５３０に対してアクセスするのためのアプリケーションの要求を処理するので、ＭＩ要素５１５及び５４５のアプリケーションコールプロセッサーは、ここに記載されたコールフローの処理を実行する。
【００５６】
ダーティーコール５５１及び５７１に応答して、マネージングＭＩ要素５２５は、各ＭＩ要素５１５及び５４５に対して、それぞれ、リターンコール５５２及び５７２を送信する。ダーティーコールには、ダーティーコール５５１及び５７１のリファレンスのための承認されたリース期間を含んでいる。
【００５７】
同様に、図５は、また、マネージングＭＩ要素５２５に対して、それぞれ、クリーンコール５６１及び５８１を送信しているＭＩ要素５１５及び５４５を示している。クリーンコール５６１及び５８１は、アプリケーション５１０及び５４０が、それぞれ、クリーンコール５６１及び５８１で指定されるリソースに対するアクセスをもはや要求しないということをマネージングＭＩ要素５２５に知らせる。マネージングＭＩ要素５２５は、クリーンコール５６１及び５８１に対して、それそれ、リターンコール５６２及び５８２で応答する。リターンコール５６２及び５８２は、それが、受信したクリーンコール５６１及び５８１に対するＭＩ要素５２５からの単なる承認であるという点において、リターンコール５５２及び５７２とは異なる。
【００５８】
アプリケーション５１０及び５４０の双方とも、同一リソースに対するアクセスを要求するかもしれない。例えば、アプリケーション５４０がそれ以前に「リソース（１）」へのアクセスが承認されていた一方で、アプリケーション５１０が、「リソース（１）」に対するアクセスを要求することもある。ＭＩ要素５２５は、合意されたリース期間、アプリケーション５１０及び５４０の双方がそのリソースを使用できるようにすることによってこのような状況を処理する。すなわち、ＭＩ要素５２５は、アプリケーション５１０及び５４０の双方とも、そのリソースに対するリファレンスを落とすか、あるいは最新の合意された期間が終了したかのいずれかの事象が最初に生ずるまで、「リソース（１）」をリクレームするためにガーベッジコレクションサイクルを起動させない。
【００５９】
１より多いアプリケーションに対し、同一のリソースに対して同時にアクセスすることを許可することによって、本発明は、また、アプリケーションが、リソースに対するリファレンスを落とすように、マネージングＭＩ要素に対してクリーンコールを送信した後に、そのアプリケーションがそのリソースにアクセスすることを許可する。これは、そのリソースが他のアプリケーションによっていまなおリファレンスされているか、あるいはそのリファレンスのリースが未だに終了しておらず、それによりマネージングＭＩ要素５２５が未だにそのリソースをリクレームしていないために生ずる。しかしながら、そのリソースは、有限の期間が経過した後、すなわち、いかなるアプリケーションもリースしていない時、あるいは最新のリースが終了した時に、リクレームされることになる。
【００６０】
（Ｄ．ＭＩ要素）
図６は、本発明の実施の形態に係るＭＩ要素６００のモジュールのブロック図を示している。ＭＩ要素６００には、監視されている各リファレンスのためのリファレンス要素６０５、アプリケーションコールプロセッサー６４０、サーバーコールプロセッサー６５０及びガーベッジコレクター６６０を含めることができる。
【００６１】
リファレンス要素６０５は、好ましくは、リファレンスデータポーション６１０に備えられた表又はこれに相当する構造、リファレンスカウント６２０及び承認期間レジスター６３０で構成する。ＭＩ要素６００は、対応するリソースをリクレームするためにガーベッジコレクター６６０をいつ起動させるかを決定するために、対応するリファレンスデータポーション６１０で指定される各リファレンスのための、リファレンスカウント６２０と承認期間６３０を使用する。
【００６２】
アプリケーションコールプロセッサ６４０は、図１に示す手順１００のステップを実行するソフトウェアモジュールである。サーバーコールプロセッサー６５０は、図２〜４に示す手順２００、３００及び４００のステップを実行するソフトウェアモジュールである。ガーベッジコレクター６６０は、上述したように、サーバーコールプロセッサー６５０からの指令に応答してリソースをリクレームするソフトウェアモジュールである。
【００６３】
（Ｅ．分散処理システム）
図７は、本発明を実施するために用いられる分散処理システム５０を図示したものである。図７において、分散処理システム５０は、ネットワーク雲５５によって表現されるネットワーク配列中に接続された３つの独立で、かつ異質なプラットフォーム７００、８００及び９００を含んでいる。図７中で、雲５５によって表現されるネットワーク配列の構成及びプロトコルは、プラットフォーム７００、８００及び９００間の情報伝達を許すものである限り、重要なことではない。
【００６４】
加えて、ちょうど３つのプラットフォームを使用していることは、単なる例示にすぎないものであり、本発明が、非常に多くのプラットフォームを使用することを制限するものではない。さらに、特定のネットワーク構造は、本発明にとって重要なことではない。例えば、本発明に従って使用することができる他のネットワーク構造では、他の全てのプラットフォームが接続されるネットワークコントローラーとして、１つのプラットフォームを使用する。
【００６５】
分散処理システム５０の実施の形態において、プラットフォーム７００、８００及び９００は、それぞれ、プロセッサー７１０、８１０及び９１０、並びにメモリー７５０、８５０及び９５０を含んでいる。各プロセッサー７１０、８１０及び９１０には、それぞれ、アプリケーション７２０、８２０及び９２０、オペレーティングシステム７４０、８４０及び９４０、並びにＭＩ要素７３０、８３０及び９３０が含まれている。
【００６６】
アプリケーション７２０、８２０及び９２０は、本発明を実行するために以前に書かれかつ修正されたプログラム、あるいは本発明によって提供されるサービスを利用するために特別に書かれたプログラムのいずれでもよい。アプリケーション７２０、８２０及び９２０は、本発明に従って実行されるオペレーションを呼び出す。
【００６７】
ＭＩ要素７３０、８３０及び９３０は、図６を参照しながら前述したＭＩ要素６００に対応している。
【００６８】
オペレーティングシステム７４０、８４０及び９４０は、それぞれ、対応するプロセッサー７１０、８１０及び９１０と連結された標準的なオペレーティングシステムである。プラットフォーム７００、８００及び９００は、異質なものとすることができる。例えば、プラットフォーム７００は、プロセッサー７１０として、サン・マイクロシステムズ社製ウルトラスパークマイクロプロセッサーを有し、オペレーティングシステム７４０としてソラリスを使用する。
【００６９】
プラットフォーム８００は、プロセッサー８１０として、シリコングラフィクス社製ＭＩＰＳマイクロプロセッサーを有し、オペレーティングシステム８４０としてユニックスを使用する。最後に、プラットフォーム９００は、プロセッサー９１０としてインテル社製ペンティアムマイクロプロセッサーを有し、オペレーティングシステム９４０としてマイクロソフトウィンドウズ９５を使用する。本発明は、これに限定されるものではなく、さらに同質のプラットフォームを収容することもできる。
【００７０】
サン、サン・マイクロシステムズ、ソラリス、ジャバ及びサンロゴは、米国及び他の国におけるサン・マイクロシステムズ社の商標又は登録商標である。ウルトラスパーク及び他の全てのスパーク商標は、許諾に基づいて使用されており、米国及び他の国におけるスパークインターナショナル社の商標である。スパーク商標を付した製品は、サン・マイクロシステムズ社によって開発された構造を基礎に置いている。
【００７１】
メモリー７５０、８５０及び９５０は、関連するプラットフォームのための一般的な記憶のようないくつかの機能を与える。他の機能は、各プロセッサー７１０、８１０及び９１０による実行の前に、アプリケーション７２０、８２０及び９２０、ＭＩ要素７３０、８３０及び９３０、並びにオペレーティングシステム７４０、８４０及び９４０を記憶することである。加えて、メモリー７５０、８５０及び９５０の一部は、ネットワーク５０中の全てのプラットフォーム７００、８００及び９００が使用可能な共有メモリーを構成してもよい。
【００７２】
（Ｅ．ＭＩサービス）
本発明は、クライアント／サーバーモデルを用いて実行してもよい。クライアントは、ダーティーコールやクリーンコールのような要求を発生させ、サーバーは、その要求に対して応答する。
【００７３】
図７に示す各ＭＩ要素７３０、８３０及び９３０は、クライアント要素とサーバー要素の双方を含んでいることが望ましい。図８は、クライアントプラットフォーム１０００及びサーバープラットフォーム１１００のブロック図を示しており、図７中のプラットフォーム７００、８００及び９００のいずれか二つに当てはまる。
【００７４】
プラットフォーム１０００及び１１００は、それぞれ、メモリー１０５０及び１１５０、並びにプロセッサー１０１０及び１１１０を有している。プラットフォーム１０００及び１１００中の要素は、図７を参照しながら前述した同様の要素と同じ方法で動作する。この例では、プロセッサー１０１０は、クライアントアプリケーション１０２０を実行し、プロセッサー１１１０は、サーバーアプリケーション１１２０を実行する。プロセッサー１０１０及び１１１０は、また、それぞれ、オペレーティングシステム１０４０及び１１４０、並びにＭＩ要素１０３０及び１１３０を実行する。
【００７５】
ＭＩ要素１０３０及び１１３０は、それぞれ、サーバーコールプロセッサー１０３１及び１１３１、アプリケーションコールプロセッサー１０３２及び１１３２、並びにガーベッジコレクター１０３３及び１１３３を有してる。各ＭＩ要素１０３０及び１１３０は、また、各ＭＩ要素１０３０及び１１３０が監視する各リファレンスのための、リファレンスデータポーション１０３４及び１１３４、リファレンスカウント１０３５及び１１３５、並びに承認期間レジスター１０３６及び１１３６を含むリファレンス要素を有している。
【００７６】
アプリケーションコールプロセッサー１０３２及び１１３２は、クライアントサービスに相当し、それぞれ、サーバーサービスに相当するサーバーコールプロセッサー１０３１及び１０３２と相互に情報伝達を行う。プラットフォーム１０００及び１１００は、サーバーコールプロセッサー、アプリケーションコールプロセッサー、ガーベッジコレクター及びリファレンス要素を有しているので、いずれのプラットフォームも、クライアントあるいはサーバーとして機能することができる。
【００７７】
しかしながら、後述する議論のために、プラットフォーム１０００は、クライアントプラットフォームを示し、プラットフォーム１１００は、サーバープラットフォームを示すものとする。この例では、クライアントアプリケーション１０２０は、分散リソースに対してリファレンスを取得し、サーバープラットフォーム１１００のＭＩ要素１１３０によって管理されるリソースに対してダーティーコールを送るために、ＭＩ要素１０３０を使用する。
【００７８】
加えて、サーバープラットフォーム１１００は、サーバーアプリケーション１１２０を実行する。サーバーアプリケーション１１２０は、また、ダーティーコールを送信するためにＭＩ要素１１３０を使用する。そして、ダーティーコールは、そのダーティーコールのリソースがＭＩ要素１１３０によって管理されている時は、ＭＩ要素１１３０によって処理される。あるいは、サーバーアプリケーション１１２０は、ＭＩ要素１０３０で管理されているリソースに対してダーティーコールを送信するためにＭＩ要素１１３０を使用する。
【００７９】
従って、クライアントプラットフォーム１０００中のＭＩ要素１０３０のためのサーバーコールプロセッサ１０３１、ガーベッジコレクター１０３３及びリファレンスカウント１０３５は、使用されていないので、図８中においては陰影が付されている。同様に、サーバープラットフォーム１１００中のＭＩ要素１１３０のアプリケーションコールプロセッサー１１３２もまた、休止状態であるので、陰影が付されている。
【００８０】
クライアントアプリケーション１０２０があるリソースに対応するリファレンスを取得した時には、アプリケーションコールプロセッサー１０３２は、ダーティーコールを送信し、それをサーバーコールプロセッサー１１３１が受信する。ダーティーコールには、要求されたリース期間が含まれている。サーバーコールプロセッサー１１３１は、ダーティーコール中のリファレンスのためにリファレンスカウント１１３５を増加させ、承認期間を決定する。これに応じて、サーバーコールプロセッサー１１３１は、アプリケーションコールプロセッサー１０３０に対して承認期間と共にリターンコールを送信する。アプリケーションコールプロセッサー１０３２は、記録されている承認期間１０３５を更新するため、及びダーティーコールのリファレンスに対応するリソースをいつリクレームするかを決定するためにその承認期間を使用する。
【００８１】
サーバーコールプロセッサー１１３１は、また、それが管理するリソースのためのリファレンスに対応するリファレンスカウントと承認期間を監視する。そのリファレンスカウント１１３５の内の一つがゼロの時、又はそのリファレンスのための承認期間１１３５が終了した時のいずれかの事象が最初に生じた場合は、いつでも、サーバーコールプロセッサー１１３１は、リファレンスカウントがゼロ又は承認期間が終了したリファレンスに対応するリソースをリクレームするためにガーベッジコレクター１１３３を起動してよい。
【００８２】
本発明の実施の形態に係るリース・リファレンス機構は、プロトコルに含まれるプラットフォーム１０００及び１１００上のクロックが同期していることを要求していない。その機構は、それらが比較しうる増加期間を有することを、単に要求するだけである。リースは、特定の時刻に終了するのではなく、むしろ一定の時間間隔が経過した後に終了する。時間間隔がほぼ一致している限り、プラットフォーム１０００及び１１００は、承認されたリース期間について、およその合意が得られる。さらに、リースのためのタイミングは、コンピューターの見地からすれば、かなり長いので、クロックレートのわずかな差異は、ほとんど、あるいは全く影響がない。
【００８３】
ダーティーコールの転送時間は、プロトコルの影響を受ける。もし、ＭＩ要素１０３０がリファレンスに対するリースを保持し、更新の要求をするために、リースが終了する直前までウェイト状態であるならば、リースは、ＭＩ要素１１３０がその要求を受信する前に終了するかもしれない。もし、そうであるならば、ＭＩ要素１１３０は、更新要求を受信する前にリソースをリクレームするかもしれない。すなわち、ダーティーコールを送るときには、送り手側は、そのリソースのためのリース期間が終了する前に更新のダーティーコールがなされるように、ダーティーコールのリソースを処理しているプラットフォームへの転送時間を考慮して、要求されたリース期間に対して、時間因子を加えるべきである。
【００８４】
（Ｆ．結論）
本発明によれば、分散ガーベッジコレクション機構は、承認されたリース期間が終了した時に、リソースに対するリファレンスが終了するように、分散処理システム中のリソースに対するリファレンスに対応する承認されたリース期間を与えることによって、リファレンスの保全性を保証し、記憶漏れを排除する。その後に、そのリソースを収集するようにしてもよい。また、リソースに対するリファレンスに付与されたカウンターを参照して、リソースがもはや分散処理システム中のプロセスによってリファレンスされない時に、リソースを収集するようにしてもよい。
【００８５】
本発明は、上気した実施の形態に何ら限定されるものではなく、本発明の要旨を逸脱しない範囲で種々の改変が可能である。例えば、前述の実施の形態には、ソフトウェアが含まれているが、本発明は、ハードウェアとソフトウェアの組み合わせ、あるいはハードウェアのみで実施することができる。
【００８６】
【発明の効果】
本発明によれば、リファレンスの保全性は、ある一定の期間、すなわち、分散システム中のパーティ、例えば、リソースに対するリファレンスを保持しているアプリケーション及びそのリソースを管理しているガーベッジコレクションシステムが、そのリソースとそのリソースに対するリファレンスとが保証されることについて同意している期間、リソースをリースすることによって、大きな記憶漏れを伴うことなく保証される。
【００８７】
そのリース期間が終了したときには、そのリソースに対するリファレンスが継続するという保証は、消滅し、ガーベッジコレクションシステムにそのリソースをリクレームすることを許可する。なぜならば、そのリソースに対するリファレンスを保持しているアプリケーションと、そのリソースを管理しているガーベッジコレクションシステムは、有限の保証されたリース期間について合意しており、双方とも、いつそのリースが終了するか、すなわちいつその保証が終了するかを知ることができるからである。これにより、リファレンスのリース期間中はリファレンスの保全性が保証され、ネットワークエラーに起因して発生するリソースの開放失敗を回避することが可能となるという効果がある。
【図面の簡単な説明】
【図１】本発明の実施の形態に係る、アプリケーションコールプロセッサーによって実行されるステップを示すフロー図である。
【図２】本発明の実施の形態に係る、ダーティーコールを処理するためのサーバーコールプロセッサーによって実行されるステップを示すフロー図である。
【図３】本発明の実施の形態に係る、クリーンコールを処理するためのサーバーコールプロセッサーによって実行されるステップを示すフロー図である。
【図４】本発明の実施の形態に係る、ガーベッジコレクションプロセスを起動するためのサーバーコールプロセッサーによって実行されるステップを示すフロー図である。
【図５】分散処理システム内でのコールの好ましい流れを示す図である。
【図６】本発明に係る方法呼出作業を遂行する構成要素のブロック図である。
【図７】本発明の実施の際に用いられる分散処理システムを示す図である。
【図８】本発明の実施の形態に係る、分散処理システムのプラットフォームにおける個々のソフトウェアの構成要素を示す図である。
【図１】
0004054418.tif 000002
【図２】
0004054418.tif 000003
【図３】
0004054418.tif 000004
【図４】
0004054418.tif 000005
【図５】
0004054418.tif 000006
【図６】
0004054418.tif 000007
【図７】
0004054418.tif 000008
【図８】
0004054418.tif 000009