(57)【要約】【課題】  ガベージコレクションを備えるオブジェクト指向プログラミング言語により実装される、ネットワーク上の複数のコンピュータ間でサービスのリクエストを仲介する装置において、ガベージコレクションの発生により通信が中断し、リアルタイム性が損なわれることを解消する。【解決手段】  リクエスト仲介装置は、リクエスト毎に一時的・反復的に生成される一時オブジェクトを再使用する手段と通信パターンを制限する手段を備え、これらの手段により、ガベージコレクションの発生を抑止しリアルタイム性を改善する。【選択図】  図２
2007086838.tif 000002
【特許請求の範囲】
【請求項１】
ガベージコレクション機能を備えるオブジェクト指向プログラミング言語によって実装されるコンピュータ間の遠隔リクエストの仲介処理をガベージコレクションを抑制して行う仲介装置であって、
前記仲介処理のために一時的に使われた一時オブジェクトのうち使用済みの一時オブジェクトを保持する一時オブジェクト格納手段と、
前記使用済みの一時オブジェクトを再利用のために初期化する一時オブジェクト管理手段と、
リクエストの種類の制限値を設定するリクエスト種類制限値設定手段と、
前記リクエストの種類の制限値によりリクエストの種類を制限するリクエスト種類制限手段と、
転送データ数の制限値を設定する転送データ数制限値設定手段と、
前記転送データ数の制限値によりリクエストによって転送されるデータ及びオブジェクトの種類及び個数を制限する転送データ数制限手段と、
同時並行使用数の制限値を設定する同時並行使用数制限値設定手段と、
前記同時並行使用数の制限値によりリクエストの同時並行使用数を制限する同時並行使用数制限手段と、
を具備することを特徴とする仲介装置。
【請求項２】
請求項１に記載の仲介装置において、更に、
前記リクエスト種類制限手段によりリクエストの種類が制限され、
前記転送データ数制限手段によりリクエストによって転送されるデータ及びオブジェクトの種類及び個数が制限され、または
前記同時並行使用数制限手段によりリクエストの同時並行使用数が制限されて、
リクエストを開始できない場合において、リクエスト処理の開始をタイムウインドウ時間の範囲内で延期するリクエスト延期手段を備える
ことを特徴とする仲介装置。
【請求項３】
請求項１に記載の仲介装置において、更に、
前記一時オブジェクト管理手段を使用するスタブコードを生成するスタブ生成手段を具備する
ことを特徴とする仲介装置。
【請求項４】
請求項１に記載の仲介装置において、更に、
一時オブジェクトを必要とするリクエスト仲介処理が開始される前に、一時オブジェクトが生成されて、前記一時オブジェクト格納手段内に事前配置される、
ことを特徴とする仲介装置。
【請求項５】
請求項１に記載の仲介装置において、
前記同時並行使用数制限手段は、クライアントの数もしくは同時に使用されるセッションの数に基づいて、同時並行使用数制限値を決定し、前記一時オブジェクト格納手段に事前配置する一時オブジェクトの最大数を決定する、
ことを特徴とする仲介装置。
【請求項６】
請求項１に記載の仲介装置において、
前記リクエスト種類制限手段により制限するリクエストの種類の制限値と、転送データ数制限手段により制限するリクエストによって転送されるデータ及びオブジェクトの種類及び個数の制限値と、同時並行使用数制限手段により制限するリクエストの同時並行使用数の制限値と、前記一時オブジェクト格納手段に事前配置する一時オブジェクトの種類及び個数は、ソースコード、インターフェース定義、サービス定義、プログラムメタ情報、コマンド行のオプション指定、設定画面、設定ファイル、コンパイルされたプログラムの中の少なくとも一つを解析することによって得ることを特徴とする仲介装置。
【請求項７】
請求項１に記載の仲介装置において、
前記一時オブジェクト管理手段は、ある一時オブジェクトが不変オブジェクトであった場合に、その一時オブジェクトを可変オブジェクトに置き換える
ことを特徴とする仲介装置。
【請求項８】
請求項１に記載の仲介装置において、更に、
ガベージコレクション抑制処理を行うモードと、ガベージコレクション抑制処理を行なわないモードを切り替える動作モード切替手段を備え、
前記動作モード切替手段が、それぞれの動作モードに応じて一時オブジェクト管理手段の使用・不使用と、リクエスト種類制限値設定手段に設定する制限値と、転送データ数制限値設定手段に設定する制限値と、同時並行使用数制限値設定手段に設定する制限値の各設定値を設定する
ことを特徴とする仲介装置。
【請求項９】
ガベージコレクション機能を備えるオブジェクト指向プログラミング言語によって実装されるコンピュータ間の遠隔リクエストの仲介処理をガベージコレクションを抑制して行う仲介装置であって、
前記仲介処理のために一時的に使われた一時オブジェクトのうち使用済みの一時オブジェクトを保持する一時オブジェクト格納手段と、
前記使用済みの一時オブジェクトを再利用のために初期化する一時オブジェクト管理手段と、
前記仲介処理で受け付けるリクエストを制限するリクエスト制限手段と
を備え、
前記リクエスト制限手段は、
リクエストの種類を制限するリクエスト種類制限手段、
リクエストによって転送されるデータ及びオブジェクトの種類及び個数を制限する転送データ数制限手段、または
リクエストの同時並行使用数を制限する同時並行使用数制限手段、
のいずれかであることを特徴とする仲介装置。
【請求項１０】
ガベージコレクション機能を備えるオブジェクト指向プログラミング言語によって実装されるコンピュータ間の遠隔リクエストの仲介処理をガベージコレクションを抑制して行う仲介装置であって、
前記仲介処理のために一時的に使われた一時オブジェクトのうち使用済みの一時オブジェクトを保持する一時オブジェクト格納手段と、
前記使用済みの一時オブジェクトを再利用のために初期化する一時オブジェクト管理手段と、
前記仲介処理で受け付けるリクエストを制限するリクエスト制限手段と
を備え、
前記リクエスト制限手段は、
リクエストの種類を制限するリクエスト種類制限手段、
リクエストによって転送されるデータ及びオブジェクトの種類及び個数を制限する転送データ数制限手段、または
リクエストの同時並行使用数を制限する同時並行使用数制限手段、
のいずれか２つであることを特徴とする仲介装置。
【請求項１１】
ガベージコレクション機能を備えるオブジェクト指向プログラミング言語によって実装されるコンピュータ間の遠隔リクエストの仲介処理をガベージコレクションを抑制して行う仲介装置におけるメモリの割り当て方法であって、
前記仲介装置が備えるべき最大のヒープメモリ量は、
仲介装置自身が初期状態で必要とするメモリ量に加えて、１のリクエストにおいて引数及び返値として転送されるデータの最大メモリ量をリクエスト種類制限値に含まれるリクエストの種類毎に足し合わせたメモリの量にセッション毎に仲介装置自身が必要とするメモリの量を加えた量に、同時並行使用数の制限値をかけ算して得られるメモリ量を割り当てる、
ことを特徴とする仲介装置におけるメモリの割り当て方法。
【請求項１２】
コンピュータ間の遠隔リクエストの仲介処理をガベージコレクションを抑制して行う仲介装置であって、
前記仲介処理のために一時的に使われた一時オブジェクトのうち使用済みの一時オブジェクトを保持する一時オブジェクト格納手段と、
前記使用済みの一時オブジェクトを再利用のために初期化する一時オブジェクト管理手段と、
リクエストの種類の制限値を設定するリクエスト種類制限値設定手段と、
前記リクエストの種類の制限値によりリクエストの種類を制限するリクエスト種類制限手段と、
転送データ数の制限値を設定する転送データ数制限値設定手段と、
前記転送データ数の制限値によりリクエストによって転送されるデータ及びオブジェクトの種類及び個数を制限する転送データ数制限手段と、
同時並行使用数の制限値を設定する同時並行使用数制限値設定手段と、
前記同時並行使用数の制限値によりリクエストの同時並行使用数を制限する同時並行使用数制限手段と、
を具備することを特徴とする仲介装置。
【請求項１３】
コンピュータ間の遠隔リクエストの仲介処理をガベージコレクションを抑制して行う仲介装置であって、
前記仲介処理のために一時的に使われた一時オブジェクトのうち使用済みの一時オブジェクトを保持する一時オブジェクト格納手段と、
前記使用済みの一時オブジェクトを再利用のために初期化する一時オブジェクト管理手段と、
前記仲介処理で受け付けるリクエストを制限するリクエスト制限手段と
を備え、
前記リクエスト制限手段は、
リクエストの種類を制限するリクエスト種類制限手段、
リクエストによって転送されるデータ及びオブジェクトの種類及び個数を制限する転送データ数制限手段、または
リクエストの同時並行使用数を制限する同時並行使用数制限手段、
のいずれかであることを特徴とする仲介装置。
【請求項１４】
コンピュータ間の遠隔リクエストの仲介処理をガベージコレクションを抑制して行う仲介装置であって、
前記仲介処理のために一時的に使われた一時オブジェクトのうち使用済みの一時オブジェクトを保持する一時オブジェクト格納手段と、
前記使用済みの一時オブジェクトを再利用のために初期化する一時オブジェクト管理手段と、
前記仲介処理で受け付けるリクエストを制限するリクエスト制限手段と
を備え、
前記リクエスト制限手段は、
リクエストの種類を制限するリクエスト種類制限手段、
リクエストによって転送されるデータ及びオブジェクトの種類及び個数を制限する転送データ数制限手段、または
リクエストの同時並行使用数を制限する同時並行使用数制限手段、
のいずれか２つであることを特徴とする仲介装置。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ガベージコレクションを備えるプログラミング言語による実行環境、もしくは使用済みメモリ管理手段を備えるハードウェアで実行されるコンピュータ間の遠隔リクエストのために、リアルタイム性を向上させてリクエスト仲介を行うリクエスト仲介装置に関するものであり、更に詳細には、ワークメモリ不足時に動作が開始されるガベージコレクションの発生を抑制して、ネットワーク上の複数のコンピュータ間で動作する分散・並列リアルタイム・アプリケーションプログラムによるシステム構築に利用される通信ミドルウェア、プログラミング言語、オペレーティングシステム、通信仲介ハードウェアの処理におけるリアルタイム性を向上させる仲介装置に関するものである。
【背景技術】
【０００２】
ネットワークもしくはバス上の複数のコンピュータ間で動作する分散／並列アプリケーション・プログラム（以下、アプリケーションと略称する）の処理においては、通信を行ってリモート（遠隔）のコンピュータ上のオブジェクトやサービスをリクエストする（リモートメソッドを呼び出す）。多くの並列アプリケーションにおけるリクエスト処理は分散アプリケーションと共通性があるため、以下では「分散」と総称する。この場合の分散アプリケーションにおける通信処理を人手で設計することは煩雑で相互運用性が限定されるため、リクエスト仲介の機能を提供するリクエスト仲介装置を利用することが一般的である。
【０００３】
本発明が対象とするリクエスト仲介装置は、分散オブジェクト、並列オブジェクト、Ｗｅｂサービス、エージェントシステム、Ｐ２Ｐシステム、音声・映像配信装置等、分散処理及び並列処理に関する高度な通信機能を有する装置である。装置の形態としては、ミドルウェア、並列／分散オペレーティングシステム（以下、ＯＳと略称する）、並列／分散言語、ライブラリが多く、ソフトウェアあるいはハードウェアによって実現される（図１）。通信ミドルウェアの例としては、ＷＥＢサービス、ＣＯＲＢＡ、ＲＭＩ、ＨＯＲＢ、Ｐ２Ｐシステムなどがある。本発明ではこれらを「リクエスト仲介装置」あるいは「仲介装置」と総称する。
【０００４】
本明細書において、リクエストという用語は、リモート手続き呼び出し（Ｒｅｍｏｔｅ  Ｐｒｏｃｅｄｕｒｅ  Ｃａｌｌ）、リモートメソッド呼び出し（Ｒｅｍｏｔｅ  Ｍｅｔｈｏｄ  Ｉｎｖｏｃａｔｉｏｎ）、リモートサービス呼び出し（Ｒｅｍｏｔｅ  Ｓｅｒｖｉｃｅ  Ｉｎｖｏｃａｔｉｏｎ）などを意味する。リクエスト仲介装置は、リクエストをサービスするアプリケーションの処理そのものではなく、クライアント・コンピュータが発行したリクエストをサーバ・コンピュータに仲介し、その返答をまたクライアント・コンピュータに伝える役割を負っている。例えば、分散オブジェクトやＷｅｂサービスの場合は、アプリケーション中に記述される遠隔コンピュータ上のセンサーの計測値の読み出しのプログラムは、「ｖａｌｕｅ  ＝  ｒｅｆ．ｇｅｔＳｅｎｓｏｒ（）」のような記述によるものとなる（図８参照）。この一行のプログラム片が仲介装置を呼び出し、ネットワークを介する比較的複雑な通信処理を自動的に行わせる。
【０００５】
リクエスト仲介の通信処理を行わず、データをパケットにより送るだけのＴＣＰやＵＤＰレベルのネットワーク・ライブラリ、分散アプリケーション自体の構成法は含まない。なお、本発明においてコンピュータとは、パソコン、サーバだけではなく、組込み機器内の小さなマイコン、同一システム内の複数の通信するコンポーネント等を広範に意味するものとする。
【０００６】
近年、機械と機械の間をネットワークで結び高度なシステムを構築する様態の分散リアルタイム・アプリケーションの開発が進んでいる。例えば、ネットワークで同期をとりながら集団で動作する人型ロボット、家庭内にリアルタイムのビデオストリームをサービスする情報家電機器、道路と交信しながら自動運転する自動車などが典型的な例である。そのような分散リアルタイム・アプリケーションのための仲介装置は、リクエストの仲介処理の際に一定の応答時間や定期的な周期を持つ通信が確実に行われるといったリアルタイム性を保証しなければならない。また、リアルタイムといわないまでも、高速な応答が必要な分散アプリケーションも多い。
【０００７】
しかし、Ｊａｖａ(登録商標）言語などの現代的なプログラミング言語で開発された仲介装置は、以下に述べる理由で応答時間や周期性を保証することができないという問題があるため、リアルタイム性が必要な分散リアルタイム・アプリケーションではＣ言語やＣ＋＋言語といった昔ながらのプログラミング言語が使用されることが多い。
【０００８】
Ｃ言語やＣ＋＋言語のプログラミング言語を使用する場合、プログラマはメモリの割り当て、メモリ使用後のメモリ返却といった操作を行う処理についても、プログラム処理の中で明示的に記述する必要がある。プログラムの作成の中で、例えばメモリの使用後に返却する指示を記述することを忘れるとメモリリークが起き、メモリ不足となってアプリケーションが異常終了する場合がある。作成したプログラムを検証する場合に、そのプログラムの処理の中でのメモリリークは発見が難しく、開発効率やシステムの安全性を大きく損なう要因である。
【０００９】
そのため、Ｊａｖａ(登録商標）言語やＣ＃言語といった現代的なプログラミング言語の実行環境では、ガベージコレクション（ＧＣ）と呼ばれるメモリ管理方式を採用している。
【００１０】
ガベージコレクション（以下、ＧＣと略称する）では、「ガベージコレクタ」が定期的に全オブジェクトをチェックし、オブジェクトが「どの参照型変数からも参照されていない」場合にはオブジェクトを削除する。これにより、当該オブジェクトが使用していたメモリ（ヒープメモリ）が開放され、再び利用可能となる。このような現代的なプログラミング言語により作成されたプログラム処理では、オブジェクトを好きなときに生成するだけでよい。
【００１１】
オブジェクトはヒープメモリ上に生成される。ヒープメモリは限られた量しかなく、ヒープメモリが不足すると、プログラム処理が異常終了する場合があるが、ＧＣは使われなくなったオブジェクトが占有するメモリを、自動的に回収して、ヒープメモリに返却するので、メモリは再利用される。このようにして、プログラマをメモリ管理から解放することによって、Ｊａｖａ(登録商標）言語を利用するプログラマの生産性は、Ｃ言語もしくはＣ＋＋言語を用いた場合に対して大幅に向上した。
【００１２】
しかし、このＧＣの処理は、言語ランライム（例えば、Ｊａｖａ仮想マシン）の裁量で発生し、プログラムの実行を中断して行われる。このため、分散リアルタイム・アプリケーションの処理においては、予測できないＧＣが発生する場合があり、通信処理を実行している際に、予測不可能な通信の中断が発生する場合があり、これが重大な事故の原因となる場合がある。
【００１３】
既存のオブジェクト指向プログラミング言語により実装された仲介装置製品であるＣＯＲＢＡ、Ｊ２ＥＥ、Ｗｅｂサービス製品などのＪａｖａによる仲介装置においては、リクエスト（リモートメソッド呼び出し）のたびにかなりの量の一時オブジェクトが生成されるため、ＧＣが頻繁に発生する。ここで、一時オブジェクトとは、リクエスト仲介処理に伴って仲介装置内で生成される全ての種類のオブジェクトを指している。具体的には、リモートのサービスを提供するサーバ・オブジェクト、通信バッファのように大きなデータから、通信相手のホスト名やユーザ名、セッション識別子、リクエスト番号といった些細なデータまで、ヒープメモリ中に格納される全てのオブジェクトを含む。これらは文字列オブジェクト、構造体的なオブジェクト、配列オブジェクトなどを用いて実装されており、セッションのたび、あるいは個々のリクエストのたびに生成され、使用後にＧＣによって回収される。一時オブジェクトの生成の際にメモリが足りないと、ＧＣが発生するので、通信が中断されることになる。一時的ではないオブジェクトとは、セッションやリクエストの寿命を越えて存続するオブジェクトで、仲介装置内では例えば起動中のサーバ・オブジェクトを記録する表の場合、仲介装置の開始と共に生成され、終了まで存続する。
【００１４】
例えば、次表は、幾つかのＪａｖａ仲介装置において、１回のリクエスト（リモートメソッド呼び出し）の間に生成される一時オブジェクト数と使用される一時メモリ量を調査した結果である。
【表１】
2007086838.tif 000003
【００１５】
更に、次表は、リクエスト２０００回あたりのＧＣの発生数を調査した結果である。このように、多くのＧＣが発生していることが分かる。
【表２】
2007086838.tif 000004
【００１６】
このように、リクエストにおける一時オブジェクトの生成は、リクエスト中にＧＣを発生させ、通信中断を引き起こす場合があるので、ＧＣ付きの実行環境で実行されるプログラミング言語で開発されたリクエスト仲介装置がリアルタイム性の必要なアプリケーションで利用されなかった大きな要因である。ハードウェアによって仲介装置を実装する場合も、使用済みメモリを管理する手段、即ちハードウェアによるＧＣが必要であり、同様の問題を含んでいる。
【００１７】
これに対して、ＧＣに起因するこの種の問題の解決を試みた幾つかの発明が提案されている。例えば、特許文献１３においては、「ｒｅｃｙｃｌｅ()メソッド」を実装することによりクラスを再利用可能にして、オブジェクトが再利用可能かどうかをＧＣのプロセスが決定できるようにすることが提案されている。これは、オブジェクトを再利用して、オブジェクトの生成を防ぐためのよい機構であるが、もし、たまたま、ガベージコレクタがリサイクル可能なオブジェクトを見つけられなかった場合、メモリ領域全体に跨るＧＣが発生してしまう。したがって、この特許文献１３の発明は、オブジェクト生成のコストを削減するにはよいが、ＧＣによる通信の中断を防ぐことはできない。
【００１８】
特許文献１０においては、メソッド呼び出しから固定・定数オブジェクトの生成を取り除く方法の発明が提案されている。この特許文献１０の発明によれば、反復的なプロセスにおけるメモリの使いすぎの問題を部分的には解決できる。しかし、ほとんどのリクエスト仲介装置においては、リクエストは多様な型を扱う動的なプロセスであり、そのプロセスにおける大部分の一時オブジェクトは、固定されているわけでも、定数でもない。
【００１９】
具体例で説明すると、ビデオ等のストリーミング配信システムは、アプリケーションに対してＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ：品質の確保された通信）を提供している。ＱｏＳ仲介装置やＯＳのドライバは、ＣＰＵ時間やネットワーク上でのバンド幅を優先的に割り当てることにより通信品質を保証する。メモリの割り当てに関しては、ＯＳが各ストリームの通信バッファ用のメモリ量をＱｏＳレベルに応じて割り当てる。この技術の適用範囲は通信データ用のバッファに限定されたものであり、リクエストの間に生成される多くの小さい一時オブジェクトを扱うことは行われていない。
【００２０】
また、幾つかの組織からリアルタイムＪａｖａの規格が提唱されている。リアルタイムＪａｖａは、多くの複雑な戦略によってこの問題に対抗している。例えば、イモータルメモリ（恒久メモリ）、スコープドメモリ（範囲化メモリ）やリアルタイムスレッドなどがあげられる。ＧＣは、リアルタイムＪａｖａのプラットフォームでも起こるため、オブジェクトを生成・廃棄する限りは、リクエスト仲介処理においてはＧＣによる通信中断の問題に突き当たる。また、普及の遅れているリアルタイムＪａｖａではない通常のＪａｖａ製品を使いたい場合も多い。
【００２１】
リアルタイムＧＣと並行ＧＣの手法は、本発明が取り組んでいる課題を解決する別のよい手段である。リアルタイムＧＣは、シングルＣＰＵ上でＧＣの時間を細分化することにより割り込み応答性能を改善する。並行ＧＣは、マルチＣＰＵシステム上でひとつのＣＰＵをＧＣ処理に割り当てることにより、他ＣＰＵがＧＣにより実行を中断することがないようにする。
【００２２】
非特許文献１においては、組込みＪａｖａアプリケーションにおいてＧＣによりリアルタイム性が欠如する問題に対処するため、オブジェクト・プーリングを中心とする設計ガイドライン、ＧＣレスＡＷＴ（Ａｂｓｔｒａｃｔ  Ｗｉｎｄｏｗｉｎｇ  Ｔｏｏｌｋｉｔ）描画ライブラリ、ＧＣレスＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）パケット・サーバを開発している。そこでは、オブジェクトはプーリングし再利用する、データの受け渡しにオブジェクトでは値型を使用する、Ｓｔｒｉｎｇなどの不変オブジェクトではなく配列などの可変オブジェクトを使用する、といったＧＣ発生を予防する基本的な手法が提案されている。
【００２３】
この提案は本発明の先行技術となるものであるが、基本的な描画ライブラリやＵＤＰパケットの受信といった基本的なレベルに留まっており、分散オブジェクトやＷｅｂサービスといった高度な通信処理に関する課題解決の方法には言及していない。サービスへのリクエストを仲介するリクエスト仲介装置は複雑であるため、単にオブジェクトをプーリングするのみでは課題は解決されない。
【００２４】
この明細書において参照として挙げられている特許文献１〜１６のその他の発明は、コンピュータシステムにおけるメモリ管理手段もしくはリアルタイム処理に関係するものである。しかし、それらは、ここで説明するＧＣ問題を解決することを意図したものではない。先行技術の動向を鑑みて、われわれはこの問題に対して、改善された方法を供給する価値は十分あると考える。
【特許文献１】特開昭６３−９３０５５号公報
【特許文献２】特開２００１−１８８７０４号公報
【特許文献３】特開２００１−２０２２８４号公報
【特許文献４】米国特許第６６７８６９７号明細書
【特許文献５】米国特許第５９５０２３１号明細書
【特許文献６】米国特許第６２７２６７４号明細書
【特許文献７】米国特許第６０５５４９２号明細書
【特許文献８】米国特許第６７５４７９６号明細書
【特許文献９】米国特許第６７５１７９０号明細書
【特許文献１０】米国特許第６７０１５２０号明細書
【特許文献１１】米国特許第６４３０５６４号明細書
【特許文献１２】米国特許第６７４８５５５号明細書
【特許文献１３】米国特許第６１３８１２７号明細書
【特許文献１４】米国特許第６６１１８９８号明細書
【特許文献１５】米国特許第６５２９９４８号明細書
【特許文献１６】米国特許第６３８１７３５号明細書
【非特許文献１】組込みＪａｖａ実用コンソーシアム, Embedded Technology 2004講演報告組込みJava リアルタイム性の確保と適用ガイドライン〜GUI/ネットワークのGCレスライブラリの実装〜講演資料  http://www.ejpc.org/et2004/et2004.htmlhttp://www.ejpc.org/et2004/et2004p2.pdf
【非特許文献２】Real-timePlatform SIG, Realtime CORBA, white paper, Object Management Group, Dec. 1996,Editor: Judy McGoogan, Lucent Technologies.
【非特許文献３】Ray Clark, E.Douglas Jensen, Doug Wells, Andy Wellings, The distributed Real-timeSpecification for Java: A Status Report, Embedded Systems Conference, March2002. JSR 50: Distributed Real-Time Specification
【発明の開示】
【発明が解決しようとする課題】
【００２５】
ところで、ＧＣを備えるオブジェクト指向のプログラミング言語を用いて開発された分散オブジェクトやＷｅｂサービス等の仲介装置では、反復的なリクエスト仲介処理中に生成される多くの一時オブジェクトのためにＧＣが発生する。ＧＣが発生するとプログラムの処理が中断され、その間、通信も中断する。
【００２６】
オブジェクトの生成を行わなければＧＣは発生しない。ＧＣが発生しなければ通信の中断も起きない。しかし、一般的には通信の内容は多様であり、内容次第でメモリの使用量は大きく異なる。また、応用によってはアプリケーションが改良されるたびにリクエストの種類や転送されるデータの種類が増えてゆく。単なるＴＣＰのパケットライブラリのような低レベルのものではＧＣの抑制は容易であるが、分散オブジェクトやＷｅｂサービスのような通信内容に意味がある仲介装置では様々なオブジェクトが生成されるため困難である。
【００２７】
本発明は、このような問題を解決するためになされたものであり、本発明の第１の課題は、一定時間内の応答通信や周期的な通信が必要な分散リアルタイム・アプリケーションのためのリクエスト仲介装置において、設計時に想定した範囲内のあらゆる通信パターンに対しリクエスト仲介処理中に通信中断が発生しないことを保証できるリクエスト仲介装置を提供することある。このようなリクエスト仲介装置のシステム構成をハードゼロＧＣシステムと称する。
【００２８】
本発明の第２の課題は、設計時に想定した範囲を逸脱する通信パターンを有するアプリケーション、あるいは、設計時に明確な範囲を想定することができないアプリケーションに対しても、通信中断を減少させるリクエスト仲介装置を提供することにある。このようなリクエスト仲介装置によると、リクエスト仲介装置における処理の特性だけではなく、アプリケーションにおける処理の特性によって通信の中断が発生しない、あるいは、アプリケーションの特性にもよるが、通信の中断がいくらか起きても良いアプリケーションに対するリクエスト仲介の処理を行うことができるリクエスト仲介装置がこれに該当する。このようなリクエスト仲介装置のシステム構成をソフトゼロＧＣシステムと称する。
【００２９】
本発明の第３の課題は、１のリクエスト仲介装置において、通信中断を抑制するモードと、通信中断の抑制機能を使用しないモードでの動作可能とした仲介装置を提供することである。これは、ひとつのアプリケーション内でも常時リアルタイム性が求められるとは限らないためである。ひとつの分散アプリケーションがリアルタイム性の必要な通信と必要ない通信を混在して使用する場合、計算資源や開発コストが倍増するが、その計算資源や開発コストの増加を軽減することできる仲介装置が提供される。
【００３０】
したがって、上記のような課題を解決する本発明の目的は、ガベージコレクションを備えるオブジェクト指向プログラミング言語の実行環境で実行されるコンピュータ間の遠隔リクエスト仲介のために、ガベージコレクションの発生を抑制し、またはガベージコレクションを発生しないようにして、リアルタイム性を向上させてリクエスト仲介を行うゼロガベージコレクション通信のための仲介装置を提供することにある。
【課題を解決するための手段】
【００３１】
上記の目的を達成するため、本発明は、第１の態様として、本発明によるゼロガベージコレクション通信のための仲介装置は、ガベージコレクション機能を備えるオブジェクト指向プログラミング言語によって実装されるコンピュータ間の遠隔リクエストの仲介処理をガベージコレクションを抑制して行う仲介装置であって、前記仲介処理のために一時的に使われた一時オブジェクトのうち使用済みの一時オブジェクトを保持する一時オブジェクト格納手段と、前記使用済みの一時オブジェクトを再利用のために初期化する一時オブジェクト管理手段と、リクエストの種類の制限値を設定するリクエスト種類制限値設定手段と、前記リクエストの種類の制限値によりリクエストの種類を制限するリクエスト種類制限手段と、転送データ数の制限値を設定する転送データ数制限値設定手段と、前記転送データ数の制限値によりリクエストによって転送されるデータ及びオブジェクトの種類及び個数を制限する転送データ数制限手段と、同時並行使用数の制限値を設定する同時並行使用数制限値設定手段と、前記同時並行使用数の制限値によりリクエストの同時並行使用数を制限する同時並行使用数制限手段と、を具備することを特徴とするものである。
【００３２】
このような態様の仲介装置においては、アプリケーションに特有な通信パターンの局所性を利用すると共に、人為的に通信パターンを制限することにより第１の課題を解決するものとしている。
【００３３】
アプリケーションでは、分野によっては、あるコンピュータがもう一方のコンピュータに通信セッションを開設し通信を始めると、同じようなリクエストを繰り返す傾向を示す場合がある。特に、機械と機械との間の通信、例えば、ロボット内部や自動車内部のコンポーネント間の通信などの組込み機器間の通信は、センサーのデータの取得といった少ない種類のリクエストの単調な繰り返しが多い。
【００３４】
このような通信には、所定のパターンがあるという特性を利用すると、メモリ使用の最適化が可能となる。つまり、同様のリクエストが繰り返されるのであれば、毎回のリクエストのたびに必要な一時オブジェクトを生成するのではなく、通信前あるいは最初の一回目に生成した一時オブジェクトを使用後に破棄せずに次回以後も使い回すことにより、ＧＣの発生を抑制することができる。以後これを「ゼロＧＣ」と呼ぶ。
【００３５】
アプリケーションによって通信パターンは大きく異なる。転送されるオブジェクトの数が多すぎる状態の通信、予想より多いクライアント・コンピュータから同時に通信が起きるといった予想外の通信が発生すると、一時オブジェクトの生成数が増えすぎてヒープメモリが枯渇する。したがって、アプリケーション毎に想定される通信パターンの範囲を決めることにより、一時オブジェクトが多く生成されないようにする。
【００３６】
例えば、制限する通信パターンの範囲としては、通信を受け付けることができるか（同時セッション数が多すぎないか）、どの種類のリクエストの通信を行うか、通信で転送されるデータの種類と数、を制限すれば十分である。これにより、本発明を適用可能なアプリケーションの分野も同時に制限を受けるが、多くのアプリケーションでは、その中の通信処理に規則性があるため、これで十分な場合も多い。
【００３７】
このように、一時オブジェクトの生成数を抑制して、ヒープメモリが枯渇することがないようにすることにより、ＧＣの発生を抑制し、さらにはＧＣを発生させないようにする方法は、１）想定内のあらゆるリクエストのパターンに対して、永久にゼロＧＣ状態を保つことが可能な解決手段（ハードゼロＧＣシステム）とするか、あるいは、アプリケーションによってはハードな解決手段では制限が強すぎて使用できない場合もあるため、２）より制限の緩い方法（ソフトゼロＧＣシステム）とするかのどちらかである。
【００３８】
そこで、本発明による仲介装置（「ゼロＧＣ通信仲介装置」）は、第１の態様として、ＧＣ機構を有するオブジェクト指向プログラミング言語で実装される通信の仲介を行うシステムにおいては、システムに備えられた処理要素（各処理手段）により、次のような処理を行う。
【００３９】
一時オブジェクトの生成が必要な場合は、オブジェクト管理手段によって一時オブジェクト格納手段を検索し、同じ型で使用済みの一時オブジェクトが格納されていれば、それを取り出して再利用し、使用後は一時オブジェクト格納手段に再度格納する。また、当該一時オブジェクトと同じ型のオブジェクトが、一時オブジェクト格納手段内に存在しない場合は、一時オブジェクト管理手段は新しいオブジェクトを生成し、使用に供する。新規に生成された一時オブジェクトは、使用後に一時オブジェクト格納手段内に格納される。ハードゼロＧＣシステムとする場合には、メモリ使用量はシステムに与えられたヒープメモリ割当量を超えることができない。
【００４０】
そこで、想定外の通信パターンによる一時オブジェクトの生成数の増えすぎを防ぐため、リクエスト種類制限手段により、リクエストの種類を制限し、データ転送数制限手段により、引数あるいは返値として転送されるデータ及びオブジェクトの種類と数を制限し、更に、同時並行使用数制限手段により、同時に発生するセッションの数を制限する。これらの制限手段による制限は、後述するように、実行時に行う形態と、開発時に行う形態がある。実行時に制限されたリクエストは、処理が延期されるか、クライアントに例外あるいはエラーとして通知される。これらの制限値の設定は、リクエストの種類の制限値は、リクエスト種類制限値設定手段により、転送データ数の制限値は、転送データ数制限値設定手段により、リクエストの同時並行使用数の制限値は、同時並行使用数制限値設定手段により、それぞれ設定する。
【００４１】
これにより、本発明による仲介装置においては、一時オブジェクトの生成の機会は管理され、想定された通信パターンの範囲内であれば、リクエストの仲介処理をいくら行ってもＧＣに起因する通信の中断が発生しない。また、想定外の通信パターンは排除される。このため、ハードゼロＧＣ状態となり、リアルタイム性の高い通信が可能となる。
【００４２】
また、本発明は、第２の態様として、本発明によるゼロガベージコレクション通信のための仲介装置は、この仲介装置において、更に、前記リクエスト種類制限手段により、リクエストの種類が制限され、前記転送データ数制限手段により、リクエストによって転送されるデータ及びオブジェクトの種類及び個数が制限され、または、前記同時並行使用数制限手段により、リクエストの同時並行使用数が制限される。リクエストを開始できない場合において、リクエスト処理の開始をタイムウインドウ時間の範囲内で延期するリクエスト延期手段を備えるように構成される。
【００４３】
これによると、リクエスト延期手段を備え、前述したような制限手段により、リクエストを受付できない場合において、リクエスト処理の開始を次の時間の範囲内で延期できるように構成される。リクエスト延期手段によってリクエストを延期することにより、リアルタイム性を確保しつつ受付拒否でサービスが利用できない機会を減少させることができる。リアルタイム性の度合いはアプリケーションによって異なるため、延期可能な時間範囲（タイムウインドウ）を調節可能とすることによって、多様なリアルタイム性に対応することができるようになる。
【００４４】
また、本発明は、第３の態様として、本発明によるゼロガベージコレクション通信のための仲介装置は、この仲介装置において、更に、前記一時オブジェクト管理手段を使用するスタブコードを生成するスタブ生成手段を具備する構成とされても良い。
【００４５】
このようなスタブコード生成手段を備えることにより、スタブコード（プロキシ、スケルトン、サロゲートとも呼ばれる）を使用して遠隔サービスを実現する仲介装置においては、一時オブジェクト管理手段を用いて、ＧＣが発生することがないコードを生成することで、ＧＣが発生することを抑制する。
【００４６】
また、本発明は、第４の態様として、本発明によるゼロガベージコレクション通信のための仲介装置は、この仲介装置において、更に、一時オブジェクトを必要とするリクエスト仲介処理が開始される前に、一時オブジェクトが生成されて、前記一時オブジェクト格納手段内に事前配置されるように構成される。
【００４７】
これにより、仲介装置においては、一時オブジェクト管理手段が、一時オブジェクト格納手段に一時オブジェクトを事前配置することにより、ランタイムのオブジェクトの配置コストを削減することができるようになる。一時オブジェクト格納手段に一時オブジェクトを事前配置する方法をとることによって、事前、あるいは最初のリクエストの間に、全ての一時オブジェクトが生成・格納されてしまい、それ以降のリクエストにおいて一時オブジェクトの生成はなくなるため、リクエスト仲介処理中のＧＣは発生しない。
【００４８】
また、本発明は、第５の態様として、本発明によるゼロガベージコレクション通信のための仲介装置は、この仲介装置において、同時並行使用数制限手段が、クライアントの数もしくは同時に使用されるセッションの数に基づいて同時並行使用数制限値を決定し、一時オブジェクト格納手段に事前配置する一時オブジェクトの最大数を決定するように構成される。
【００４９】
これにより、仲介装置において、ゼロＧＣ動作するために必要とされる一時オブジェクトの数を、通信相手の数、すなわち、同時に使用するユーザの数や同時に通信する相手の数によって決定することができ、複数のユーザや複数の通信相手のある環境に対応可能となる。ヒープメモリの量としては、１セッションで使用されるメモリ量と同時セッション数との積が最低限必要となる。
【００５０】
また、本発明は、第６の態様として、本発明によるゼロガベージコレクション通信のための仲介装置は、この仲介装置において、リクエスト種類制限手段により制限するリクエストの種類の制限値と、転送データ数制限手段により制限するリクエストによって転送されるデータ及びオブジェクトの種類及び個数の制限値と、同時並行使用数制限手段により制限するリクエストの同時並行使用数の制限値と、前記一時オブジェクト格納手段に事前配置する一時オブジェクトの種類及び個数との制限値のパラメータは、ソースコード、インターフェース定義、サービス定義、プログラムメタ情報、コマンド行のオプション指定、設定画面、設定ファイル、コンパイルされたプログラムの中の少なくとも一つを解析することによって得るように構成される。
【００５１】
このような構成により、使用される一時オブジェクトについての情報により、それぞれの制限手段における各制限値を決定することができ、更に、一時オブジェクト格納手段にどの型のオブジェクトをどれだけの数だけ事前配置するかを決定することができる。使用される一時オブジェクトについての情報は、ソースコード、インターフェース定義、サービス定義、プログラムメタ情報、コマンド行のオプション指定、設定画面、設定ファイルもしくはコンパイルされたプログラムを開発時あるいは実行初期に解析することにより得られる。リクエストが送られるサーバ・オブジェクト、リクエストが受け渡しするパラメータで使用する一時オブジェクト、仲介装置内で使用する一時オブジェクトの型と数に関する情報が得られる。
【００５２】
また、本発明は、第７の態様として、本発明によるゼロガベージコレクション通信のための仲介装置は、この仲介装置において、一時オブジェクト管理手段は、ある一時オブジェクトが不変オブジェクトであった場合に、その一時オブジェクトを可変オブジェクトに置き換えるように構成される。このような構成により、本発明による仲介装置は、不変オブジェクトの代わりとなる可変オブジェクトを提供して、当該可変オブジェクトを再利用できるようにする。
【００５３】
オブジェクト指向プログラミング言語ではオブジェクトの可変性について２種類の分類がある。ひとつは一度設定したフィールドの内容を変更可能な可変（ｍｕｔａｂｌｅ）オブジェクト、もう一つは一度設定したフィールドの内容を変更不可能な不変（ｉｍｍｕｔａｂｌｅ）オブジェクトである。Ｊａｖａの不変オブジェクトの例としてはＳｔｒｉｎｇオブジェクトやＩｎｔｅｇｅｒオブジェクトがある。Ｓｔｒｉｎｇオブジェクトの可変版としてＳｔｒｉｎｇＢｕｆｆｅｒオブジェクトが提供されている。不変オブジェクトは状態が変更できない為、再利用不可能である。このため、仲介装置を設計する際にゼロＧＣにするならば、不変オブジェクトを使用しないことが有効である。
【００５４】
ところが、アプリケーションがリクエストの引数あるいは返値に不変オブジェクトを指定したため、仲介装置が不変オブジェクトを生成しなければならないことがある。その生成を防ぐため、本発明による仲介装置においては、不変オブジェクトの代わりとなる可変オブジェクトを提供するため、一時オブジェクト管理手段が、ある一時オブジェクトが不変オブジェクトであった場合に、その一時オブジェクトを可変オブジェクトに置き換えるようにして、当該可変オブジェクトを再利用する。
【００５５】
また、本発明は、第８の態様として、本発明によるゼロガベージコレクション通信のための仲介装置は、更に、ガベージコレクション抑制処理を行うモードと、ガベージコレクション抑制処理を行なわないモードを切り替える動作モード切替手段が備えられ、動作モード切替手段が、それぞれの動作モードに応じて一時オブジェクト管理手段の使用・不使用と、リクエスト種類制限値設定手段に設定する制限値と、転送データ数制限値設定手段に設定する制限値と、同時並行使用数制限値設定手段に設定する制限値の各設定値を設定するように構成される。
【００５６】
このような構成により、本発明による仲介装置は、動作モード切替手段によって、ガベージコレクション抑制処理を行うモードと、ガベージコレクション抑制処理を行なわないモードを切り替えることができる。アプリケーションによっては、同一アプリケーション内でゼロＧＣ処理を行わない通信を行う必要がある場合があり、ひとつのアプリケーションがゼロＧＣ通信仲介装置と通常の仲介装置の両方を備えることは無駄が多い。そのために、ゼロＧＣ通信仲介装置はゼロＧＣ通信を行うモードと、ゼロＧＣ処理を行わないモードを切り替えて、アプリケーションに適切な動作モードを選択できるようにする。
【００５７】
ところで、本発明による仲介装置においては、リクエストの種類を限定するなどいくつかの制限手段を設けて、例えば、通信の仲介処理においてＧＣが発生しないことを保証するが、アプリケーションによっては、全ての制限手段により制限を課すとシステムが実現できないようになる場合がある。このため、必要に応じて、３つの制限手段の全てではなく、１つまたは２つの制限手段を利用するだけとして、より広い範囲の応用をカバーできるようにする。
【００５８】
したがって、本発明は、第９の態様として、本発明によるゼロガベージコレクション通信のための仲介装置が、ガベージコレクション機能を備えるオブジェクト指向プログラミング言語によって実装されるコンピュータ間の遠隔リクエストの仲介処理をガベージコレクションを抑制して行う仲介装置であって、前記仲介処理のために使われたオブジェクトのうち使用済みの一時オブジェクトを保持する一時オブジェクト格納手段と、前記使用済みの一時オブジェクトを再利用のために初期化する一時オブジェクト管理手段と、前記仲介処理で受け付けるリクエストを制限するリクエスト制限手段とを備え、前記リクエスト制限手段は、リクエストの種類を制限するリクエスト種類制限手段、リクエストによって転送されるデータ及びオブジェクトの種類及び個数を制限する転送データ数制限手段、またはリクエストの同時並行使用数を制限する同時並行使用数制限手段のいずれかであるように構成する。このような構成により、より広い範囲のアプリケーションをカバーするができる。
【００５９】
また、本発明は、第１０の態様として、本発明によるゼロガベージコレクション通信のための仲介装置が、ガベージコレクション機能を備えるオブジェクト指向プログラミング言語によって実装されるコンピュータ間の遠隔リクエストの仲介処理をガベージコレクションを抑制して行う仲介装置であって、前記仲介処理のために使われたオブジェクトのうち使用済みの一時オブジェクトを保持する一時オブジェクト格納手段と、前記使用済みの一時オブジェクトを再利用のために初期化する一時オブジェクト管理手段と、前記仲介処理で受け付けるリクエストを制限するリクエスト制限手段とを備え、前記リクエスト制限手段は、リクエストの種類を制限するリクエスト種類制限手段、リクエストによって転送されるデータ及びオブジェクトの種類及び個数を制限する転送データ数制限手段、またはリクエストの同時並行使用数を制限する同時並行使用数制限手段のいずれか２つであるように構成する。このような構成により、より広い範囲のアプリケーションをカバーするができる。
【００６０】
本発明は、第１１の態様として、本発明によるゼロガベージコレクション通信のための仲介装置が、当該仲介装置におけるメモリ使用量を適切に管理できるように、メモリ割り当て方法が提供される。このための本発明によるメモリ割り当て方法は、ガベージコレクション機能を備えるオブジェクト指向プログラミング言語によって実装されるコンピュータ間の遠隔リクエストの仲介処理をガベージコレクションを抑制して行う仲介装置におけるメモリの割り当て方法であって、前記仲介装置が備えるべき最大のヒープメモリ量は、仲介装置自身が初期状態で必要とするメモリ量に加えて、１のリクエストにおいて引数及び返値として転送されるデータの最大メモリ量をリクエスト種類制限値に含まれるリクエストの種類毎に足し合わせたメモリの量にセッション毎に仲介装置自身が必要とするメモリの量を加えた量に、同時並行使用数の制限値をかけ算して得られるメモリ量を割り当てる。
【００６１】
これにより、本発明による仲介装置に備えるべき最大のヒープメモリ量は計算式により求めることができ、仲介装置におけるメモリ使用量を適切に管理できるようになる。本発明による仲介装置は、実装にソフトウェアを用いるだけではなく、ハードウェアにより実装されてもよい。
【発明の効果】
【００６２】
本発明の仲介装置によれば、メモリ不足時に動作が開始されるガベージコレクションの発生を抑制して、ネットワーク上の複数のコンピュータ間で動作する分散リアルタイム・アプリケーション構築に利用される通信ミドルウェア、プログラミング言語、オペレーティングシステムの処理におけるリアルタイム性を向上させることができる。
【発明を実施するための最良の形態】
【００６３】
以下に、本発明の具体的な実施の形態を図を用いて説明する。理解を容易なものとするため説明には、Ｊａｖａ（登録商標）プログラミング言語を用いる。しかし、本発明による仲介装置は、Ｃ＃言語等ＧＣを備える他のオブジェクト指向プログラミング言語にも適用可能である。
【００６４】
本発明は、主に、通信の中断を避けなければならない分散リアルタイム・アプリケーション、通信の中断が望ましくない非リアルタイムの分散アプリケーション、処理速度や応答速度の向上のためにＧＣを避けたい分散アプリケーションにおいて使用されるミドルウェア、通信ライブラリ、言語、もしくはＯＳに適用される。
【００６５】
図１は、本発明によるゼロガベージコレクション通信のための仲介装置の位置付けを説明する図である。分散アプリケーション中の仲介装置の位置づけを示している。図１に示すように、クライアント・コンピュータ１１０とサーバ・コンピュータ１２０とが通信媒体１３０により結合され、この２つのコンピュータの間でデータ通信が行われる。通信は２台あるいはそれ以上の数のコンピュータの間で、あるいは、１台のコンピュータの中の複数の通信要素の間で行われる。通信の情報そのものは通信媒体１３０を介して伝達される。通信媒体１３０としては、例えば、複数台のコンピュータの間の通信にはネットワークが利用され、１台のコンピュータの中の複数の通信要素の間の通信にはデータバスなどが利用される。
【００６６】
ここでは説明のために、２台のコンピュータを便宜的にリクエストを発行する側のクライアント・コンピュータ１１０とリクエストを受け付けサービスする側のサーバ・コンピュータ１２０に分ける。アプリケーションは、クライアント側で動作するアプリケーション（クライアント・プログラム）１１１とサーバ側で動作するアプリケーション（サーバ・プログラム）１２１から構成される。アプリケーションの中で行う通信処理は、クライアント側仲介装置１１２とサーバ側仲介装置１２２によって仲介される。例えば、ＣＯＲＢＡにおいては、クライアント側仲介装置１１２は、クライアント側スタブおよびクライアント側通信ランタイム、サーバ側仲介装置１２２は、サーバ側スタブおよびサーバ側ランタイムから構成され、アプリケーション（クライアント・プログラム）１１１には、サーバ側スタブを呼び出すアプリケーションが、アプリケーション（サーバ・プログラム）１２１にはサービスを実行するサーバ・オブジェクトが含まれる。Ｗｅｂサービスでもビデオサーバでも同様の構成をとる。
【００６７】
図２は、本発明によるゼロガベージコレクション通信のための仲介装置のシステム構成を説明する図である。ゼロＧＣ通信仲介装置を搭載するひとつのコンピュータ上での構成例を示している。図２において、２００はサーバ側またはクライアント側の１つのコンピュータを示しており、２２０はゼロＧＣ通信仲介装置２３０によって使用される言語ランタイムである。
【００６８】
言語ランタイム２２０の例としては、「Ｊａｖａ仮想マシン」、「．ＮＥＴ  ＣＬＲ」、「ＧＮＵ  Ｍｏｎｏランタイム」などが挙げられる。中間コード実行方式、コンパイル時ネイティブコード変換方式、実行時ネイティブコード変換方式を問わない。言語ランタイム２２０は、ガベージコレクタ２２２を含んでおり、ソフトウェアまたはハードウェアで実装される。ソフトウェアで実装される場合はＯＳにより実行され、またはハードウェア上でのメモリ管理システムの中で実行される。アプリケーション２５０の実行において、その間、言語ランタイム２２０は、新しいオブジェクトをヒープメモリ２１２上に生成する。ガーベッジコレクタ２２２は、言語ランタイム２２０の裁量においてメモリの回収作業（ゴミ回収）を行う。
【００６９】
ゼロＧＣ通信仲介装置２３０は、アプリケーション２５０の処理における通信中のＧＣの発生を抑制するため、少なくとも一つの一時オブジェクト格納手段２３２と、少なくとも一つの一時オブジェクト管理手段２３４を備える。これらは、複数個の一時オブジェクト格納手段２３２と、複数個の一時オブジェクト管理手段２３４が備えられる構成であっても良い。
【００７０】
一時オブジェクト格納手段２３２は、一時オブジェクトが毎回生成されることを避けるため、ゼロＧＣ通信仲介装置２３０の実行において必要とされる一時オブジェクトを保持する。一時オブジェクト格納手段２３２の実装としては、オブジェクトが保持できればよいので、特に制限はなく、コレクションクラス、コンテナクラス、ハッシュテーブル、シングルトンオブジェクト・パターン、キャッシュ、配列、プール、インラインキャッシュ、オブジェクト中のフィールドでの保持といった手段が利用できる。
【００７１】
一時オブジェクト管理手段２３４は、一時オブジェクト格納手段２３２で格納される一時オブジェクトの管理を行う。一時オブジェクトの管理処理においては、仲介処理において一時オブジェクトが必要になった際に、一時オブジェクト格納手段２３２を検索して利用可能な一時オブジェクトを見つけ出す作業、それを再初期化して再利用に供する作業、新規の一時オブジェクトを生成する作業、使用後に不要となった一時オブジェクトを一時オブジェクト格納手段２３２に戻す作業を行う。
【００７２】
一時オブジェクト管理手段２３４の実装方法としては、この作業を専用に行うオブジェクトやコンポーネントを設ける方法、仲介装置内にインラインで直接処理を記述する方法、一時オブジェクト格納手段２３２と一体化させる方法（例えば、キャッシュは検索機能や格納機能を備える）が利用できる。なお、使用中の一時オブジェクトは必ずしも一時オブジェクト管理手段２３４から外される必要はなく、他の使用者と競合が起きなければ一時オブジェクト管理手段２３４に格納されたままになっていてもよい。
【００７３】
一時オブジェクト管理手段２３４と一時オブジェクト格納手段２３２の数と対応付けは実装の都合により任意の組み合わせが可能である。これら一時オブジェクト格納手段２３２と一時オブジェクト管理手段２３４は、仲介装置だけではなく、仲介装置を使用するアプリケーションに対しても一時オブジェクト再利用の機能を提供し、アプリケーション全体でＧＣを抑制するようにできる。
【００７４】
ゼロＧＣ通信仲介装置２３０は、図２に示すようなシステム構成では、ミドルウェアとしての実施形態を取り、言語ランタイム２２０とアプリケーション２５０の中間層で動作する。本発明の実施の形態はミドルウェアとしての実施とは限らないため、別の場合には、言語機能の一部として言語ランタイム２２０内に組み込まれたり、ＯＳ機能の一部に組み込まれたりして実施される。
【００７５】
Ｗｅｂサービスの場合はＸＭＬのパースを行い、パース結果を表すオブジェクトツリーを構築する。ツリー内の各要素オブジェクトも一時オブジェクト管理手段を用いて再利用する。
【００７６】
ゼロＧＣ通信仲介装置２３０には、リクエスト種類制限手段２３６、転送データ数制限手段２３７、同時並行使用数制限手段２３８が設けられる。これらのリクエスト種類制限手段２３６、転送データ数制限手段２３７、同時並行使用数制限手段２３８は、それぞれに、リクエストの種類、リクエストによって転送されるデータ及びオブジェクトの種類と数、同時並行セッションの使用数が、想定した範囲内に入っているように制限する制限手段である。設定した各制限値と実際の使用数との比較によって仲介するリクエストを制限する。リクエストの種類の制限値は、リクエスト種類制限値設定手段２４０により、転送データ数の制限値は、転送データ数制限値設定手段２４１により、リクエストの同時並行使用数の制限値は、同時並行使用数制限値設定手段２４２により、それぞれ設定される。制限値の設定は設定ファイル、設定ウィンドウ、あるいは、後述するように、ソースコードの解析等により行われる。
【００７７】
図３は、より好ましい実施の例として、一時オブジェクト格納手段と一時オブジェクト管理手段がガベージコレクション手段と言語ランタイムと協調する様子を説明する図である。ガベージコレクション手段であるガベージコレクタ３２２が一時オブジェクト格納手段３３２と一時オブジェクト管理手段３３４とを提供するか、あるいはガベージコレクタ３２２が一時オブジェクト格納手段３３２および一時オブジェクト管理手段３３４と協調して動作する。これにより、より効率の良いＧＣの抑制が可能となる。
【００７８】
図３に示されるように、一時オブジェクトの生成の際に、言語ランタイム３２０が一時オブジェクト管理手段３３４と協働し、新規の一時オブジェクト生成時に一時オブジェクト格納手段３３２に格納されたオブジェクトを利用するように動作する。一時オブジェクト生成の際に、言語ランタイム３２０は新規の一時オブジェクトを生成するのではなく、一時オブジェクト格納手段３３２を検索し、同じ型のオブジェクトが既に格納されている場合はそれを再利用する。ガベージコレクタ３２２はヒープメモリ３１２が逼迫し、ＧＣを行っても、なおヒープメモリが欠乏する場合には、一時オブジェクト格納手段３３２中の一時オブジェクトのいくつかを選択的に回収することができる。その実装には弱参照（ウィークリファレンス）を用いることができる。
【００７９】
次に、図４、図８、図９を用いて、リクエストを発行する側のクライアント・コンピュータ１１０を例に取り、リクエスト仲介処理の手順について説明する。サーバ側のサーバ・コンピュータ１２０についても同様である。図４には、サービスへの接続要求を仲介する処理を説明するフローチャートを示しており、図８には、アプリケーション（クライアント・プログラム）の一例を示しており、図９には、サービス要求の仲介処理における一時オブジェクトを管理する処理を示すフローチャートを示している。
【００８０】
クライアント・コンピュータ１１０において、アプリケーション（クライアント・プログラム）１１１が、図８に示すプログラムの処理の中で、リクエスト（ステップ９０１）を発行するとする。ステップ９０１の処理は、遠隔サービスへの接続であり、この処理の返値としてリファレンスを得る。この処理で、一連の遠隔セッションのためのセッション情報が作成される。次のステップ９０２およびステップ９０３の処理により、遠隔サービスをリクエストする。引数を渡すと遠隔サービスが何らかの計算を行い、返値を返す。そして、ステップ９０４の処理により、セッションを閉じる。
【００８１】
遠隔サービスへの接続処理（ステップ９０１）では、図４に示すようなサービスへの接続要求処理４００が開始される。サービスへの接続要求処理４００が開始されると、この中で、まず、同時並行使用数制限手段２３８によって同時並行使用数（セッション数）が制限値を越えていないかが確認され（ステップ４０１）、越えていない場合は同時セッション数を増加させた後（ステップ４０２）、正常時の処理として、オブジェクトを生成して、オブジェクトの処理として、セッション情報の作成、ユーザ情報の作成、ユーザ認証用暗号データの作成、リファレンス識別子の作成、通信データバッファの作成、通信用コネクションの作成などの一連の作業を行う（数が多いのでいくつかは略す）。この場合に、同型のセッション情報のオブジェクトはあるか否かを判定し（ステップ４１０）、オブジェクトがある場合は、オブジェクト内部状態の再初期化を行い（ステップ４１１）、当該オブジェクトを再利用し、また、オブジェクトがない場合には、同型のオブジェクトを生成し、初期化して利用する（ステップ４１２）。同様の処理を各オブジェクトについて行い（ステップ４２０〜ステップ４２２、ステップ４３０〜ステップ４３２）、その後、遠隔サービスへの接続を行って（ステップ４８０）、処理の結果として、呼び出し側へレファレンスを返す処理を行う（ステップ４９５）。
【００８２】
すなわち、このオブジェクトの処理では、図４に示すように、それらのデータや情報をオブジェクトとして作成する際には、一時オブジェクト管理手段に「同型のセッション情報オブジェクトはあるか？」を問い合せ（ステップ４１０）、一時オブジェクト管理手段は一時オブジェクト格納手段を検索し、あればそれを返す。接続処理は当該セッション情報オブジェクトを再初期化して使用する（ステップ４１１）。ここで再初期化は、リクエストの内容に合うようにオブジェクトの初期状態を再び作る操作である。一時オブジェクトに再初期化用メソッドを持たせて、それを呼び出すか、リフレクションを用いて状態の設定を行う。同型の一時オブジェクトが一時オブジェクト格納手段になければ、新規にオブジェクトを生成する（ステップ４１２）。このような処理を、必要な全ての一時オブジェクトに対して繰り返し行う。セッション終了時の処理（図８のステップ９０４）には、前に使用した一時オブジェクトを一時オブジェクト格納手段に格納する。また、ステップ４０１の判定処理において、同時セッション数が制限値を越える場合は、仲介装置１１２は、クライアント・プログラム１１１に失敗を返す（ステップ４９０）。
【００８３】
ここでの図４のフローチャートによる処理および図８に示すプログラム例は、説明のためにあるひとつの実施例について述べたものであり、本発明を異なる一時オブジェクトの構成を有する仲介装置に適用する場合には、図４の処理では、異なるフローチャートとなる。しかし、通信パターンを限定しつつ一時オブジェクトを再利用することで、ＧＣを抑制するという本発明の本質は変わることがない。
【００８４】
図９は、リクエスト発行の処理（ステップ９０２、ステップ９０３）の仲介を行う処理を示すフローチャートである。図８のプログラム例のステップ９０２の処理により、図９のリクエスト仲介処理１０００が呼び出される。この仲介処理１０００が開始されると、リクエスト種類制限手段２３６によって呼び出されたリクエストの種別は想定されたもの（制限数を超えないもの）であるか、想定されていないものかを確認する（ステップ１００１）。これは、ＣＯＲＢＡのように動的にリクエストの種類を拡張可能な仲介装置においては、リクエストの種類が想定外に膨らんで一時オブジェクトの種類が増えすぎないようにするために必要な処理である。なお、予めリクエストのスタブを生成しておくような静的ＣＯＲＢＡ要求、ＲＭＩやＨＯＲＢのようなシステムでは、コンパイル時にこの制限が行われるため、実行時には不要である（規定されたメソッドの種類をアクセスするスタブしか生成されない）。
【００８５】
次に、同様に転送データ数制限手段２３７によってリクエストの引数の型や数についても、想定内に収まっているか（制限数を超えないか）を確認する（ステップ１００２）。例えば、オブジェクトの配列を引数としてリクエストを行う場合、配列の要素数が想定以上に多いと一時オブジェクトの数が増えすぎてしまうため、それは避けなければならない。引数のオブジェクトの型はポリモーフィズムで多様であり得る。その場合も、あらゆる型を受け入れると一時オブジェクトの数が増えすぎてしまうため、型の種類の数を制限する必要がある。映像配信システムのようにオブジェクトの転送を行わないシステムでは、一部を省略可能である。それらの確認が終了した後、送信用のデータバッファを確保する処理（ステップ１０２０〜ステップ１０２２）、受信用データバッファの確保する処理（ステップ１０３０〜ステップ１０３２）などを行う。これらの処理についてもオブジェクトを生成し、またはオブジェクトの再利用により処理が実行される。
【００８６】
これらも一時オブジェクト管理手段と一時オブジェクト格納手段を用いて行うが、実際に必要な一時オブジェクトの種別はシステムによって異なる。このようなオブジェクトによる処理を行い、ステップ１０８０において遠隔のコンピュータにリクエストを伝達し、その結果を受け取る。返値に対しても一時オブジェクトが発生する場合は、同様に再利用を行い、呼び出したクライアント・プログラムに結果を返す（ステップ１０９５）。セッション終了時には、先に使用した一時オブジェクトは一時オブジェクト格納手段に格納されなければならない。
【００８７】
図８のプログラムが初めて実行される際には、図４もしくは図９の処理が実行される中で、一時オブジェクト格納手段中に一時オブジェクトが格納されていない場合は、一時オブジェクトの新規生成が頻繁に発生するが、図８のプログラムが２回目以降に実行される際には、一時オブジェクト格納手段に十分な一時オブジェクトが格納されており、新規生成ではなく再利用の経路が選択されることが多くなる。このように処理が継続されて、分散アプリケーションの処理が進行するにしたがって、一時オブジェクトを新規生成する機会は減り、一時オブジェクトの生成が発生しない安定状態に達する。これがゼロＧＣ状態である。
【００８８】
このようにしてゼロＧＣ状態になると、これで、仲介装置がリクエストを仲介している処理中にＧＣが発生することはなくなる。ゼロＧＣ通信仲介装置を使用するアプリケーション（クライアント・プログラム）１１１およびアプリケーション（サーバ・プログラム）１２１自身の処理においてもオブジェクト生成には気を配り、また、必要に応じて明示的なＧＣ操作を行うことが望ましい。また、メモリ使用量の記録をとって、一定メモリ使用量を超えた場合には報告をし、次回の制限値の設定に役立てることが望ましい。システムが備えるべきヒープメモリ量については後述する。
【００８９】
このような構成による仲介装置においては、システムが動作を始めてしばらくの間はメモリ使用量は増加するが、通信が予想されたパターンに達した後ではＧＣは発生しなくなり、ゼロＧＣ状態となる。したがって、ＧＣに起因する通信遅延は発生しなくなる。このため、従来の技術では不可能であったようなシステム開発が可能になる。例えば、開発効率が高く安全性の高いＧＣを備えるオブジェクト指向プログラミング言語でリアルタイム性の必要な通信処理を行うアプリケーションを実装することが可能となる。リアルタイムＧＣや並列ＧＣによる課題解決手法と比較して、本発明による解決手法は普及しているリアルタイムＧＣ・並列ＧＣを備えない言語ランタイム上で実施可能となる利点がある。
【００９０】
また、非特許文献１のＧＣレス動作用オブジェクトプーリングライブラリでは、オブジェクトが増えてプールの大きさが不足する場合には、プールをＧＣ可能時間内に拡大する手法をとるが、分散アプリケーションなどのオブジェクト指向プログラミング言語により実装される仲介装置においては、ＧＣ可能時間は仲介装置にとって不明の事であるため、その手法では想定内のあらゆる通信パターンに対しゼロＧＣを保証するという課題に対処することはできない。本発明による仲介装置では、通信には規則性があるという特性を利用して一時オブジェクト生成の機会に制限を課すことにより、このような課題を解決することができるようにしている。
【００９１】
次に、本発明による仲介装置の別の実施例について説明する。前述したように、それぞれの制限手段によって、リクエストを受付できない場合、リクエスト処理の開始を次の時間の範囲内で延期できるように、リクエスト延期手段によってリクエストを延期する構成とする。これにより、リアルタイム性を確保しつつ受付拒否でサービスが利用できない機会を減少させることができるものとなる。リアルタイム性の度合いはアプリケーションによって異なるため、延期可能な時間範囲（タイムウインドウ）を調節可能とすることによって、多様なリアルタイム性に対応することができるようになる。
【００９２】
図１４は、リクエストが制限値を越えた場合に行う延期処理を含む仲介処理を説明するフローチャートである。図１４を参照して、サービスへの接続要求処理を例にとってリクエスト延期手段による動作を説明する。リクエストの仲介処理の中で、サービスへの接続要求処理１６００が開始されると、ある制限手段により制限値を越えていないかが確認される（ステップ１６０１）。この処理では、同時セッション数を確認している。同時セッション数が制限数を超える場合には、一定時間（タイムウインドウ内で）待って（ステップ１６０２）、タイムウインドウ内において制限値が満たされたかを判断する（ステップ１６０３）。満たされなかった場合、即ち、タイムアウトした場合には、失敗を返す（ステップ１６０６）。タイムウインドウ時間の内に他のセッションが終了することにより、制限値が満たされた場合には後続の処理を行う（ステップ１６０４、ステップ１６０５、ステップ１６０７）。
【００９３】
このように、リクエスト延期処理を含む仲介処理は、サービスへの接続要求処理においても各リクエストの仲介処理においても使用が可能である。この場合、リクエスト仲介処理の前段階で延期を行う形態と、それぞれ一時オブジェクト毎に待ち行列を設けて延期を行う形態により、リクエスト延期処理を行うことができる。タイムウインドウ値の設定はアプリケーションまたは仲介装置が必要とするリアルタイム性に応じて事前に行う。
【００９４】
このようにして、リクエスト仲介処理を行う際に、制限手段によってリクエストを受付できない場合においては、リクエスト処理の開始をアプリケーションが必要とするリアルタイム性を満たす時間の範囲内で延期することにより、アプリケーション毎に必要なリアルタイム性を確保しつつ受付拒否でサービスが利用できない機会を減少させることができる。
【００９５】
次に、図１３は、本発明によるゼロガベージコレクション通信のための仲介装置の別の実施例を説明する図であり、分散アプリケーション中の仲介装置の位置づけを示している。この実施例の仲介装置は、一時オブジェクト管理手段を使用するスタブコード（プロキシ、スケルトン、サロゲートとも呼ばれる）を生成するスタブ生成手段を具備する構成である。図１３において、スタブコード生成手段は、クライアント側で実行されサーバ・オブジェクトのＡＰＩをマーシャリングする役割のクライアント側スタブコード１５１２と、サーバ側で実行され通信内容をアンマーシャリングしサーバ・オブジェクトを呼び出す役割のサーバ側スタブコード１５２２を生成する。
【００９６】
スタブコード生成に際して、スタブコード内で一時オブジェクトを生成する従来の方式ではなく、一時オブジェクト管理手段を用いて一時オブジェクトを再利用し、ＧＣが発生することがないコードを生成することにより、通信の中断を防止する。生成されたそれぞれのスタブコード（１５１２、１５２２）は、それぞれクライアント側仲介装置１５１３及びサーバ側仲介装置１５２３を呼び出して通信を行う。スタブコードはクライアントとサーバの両方に存在する場合も一方のみの場合もあるし、開発時に生成する形態と実行時に動的に生成する形態がある。
【００９７】
図５および図６のフローチャートを参照して、本発明による仲介装置の別の実施例について説明する。アプリケーションの処理が開始されて、続いて、仲介装置の初期化が開始されると（ステップ５０１）、予め想定される範囲内の数の一時オブジェクトを事前に生成して一時オブジェクト管理手段に格納する（ステップ５０２）。その際に、もし、割り当てられたヒープメモリの量が不足することが判明した場合（ステップ５０３）には、アプリケーションに異常を報告し（ステップ５０５）、早い段階において対策を施すことができるようにする。十分な量のヒープメモリ量がある場合には、正常に仲介装置の初期化が終了する（ステップ５０４）。続いて、図６に示すサービスへの接続要求処理（ステップ５１０）を開始する。
【００９８】
図５に示すような処理を行った後に、図６に示すサービスへの接続要求やサービスへの仲介処理を行う段階では、前述したように、同時セッション数が制限数を超えない場合に、同時セッション数を増加し、処理を実行する（ステップ５１１〜ステップ５１６）。通常では、図４および図９により説明したように一時オブジェクトは必要に応じて新規生成されるが、この場合において、必要な一時オブジェクトは既に一時オブジェクト格納手段に存在しているため、図６に示すサービスへの接続要求処理５１０が開始されても、ここでのセッション情報オブジェクトを取得し再利用すること（ステップ５１３），ユーザ情報オブジェクトを取得し再利用すること（ステップ５１４），データバッファオブジェクトを取得し再利用すること（ステップ５１５）等の処理は、一時オブジェクト格納手段に格納されているオブジェクトが再利用されて処理が進められ、新規な一時オブジェクトは生成することなく、処理が行われる。これにより、ＧＣが発生することが抑制され、更には、ＧＣが発生しないことが保証される。
【００９９】
このように、システムを起動した時に一時オブジェクトを生成して、事前に一時オブジェクト格納手段に格納しておくことで、実行時はそれらを生成する必要がなくなり、実行時の速度が改善する効果があるものとなる。
【０１００】
従来技術の非特許文献１のＧＣレス動作用オブジェクトプーリングライブラリでは、事前にオブジェクト生成を行いオブジェクト・プールに格納する手段を持たないため、実行時にヒープメモリが欠乏する事態が発生する場合がある。ヒープメモリを拡張することはできるが、ＯＳのメモリが足りなくなるとシステムはエラーとならざるを得ない。これに対して、本発明による仲介装置によれば、万一システムに割り当てられたメモリ量が少なすぎるといったミスがあった場合も、実行の初期に発見される効果がある。
【０１０１】
次に、本発明による仲介装置における制限手段の制限値を設定する処理について説明する。図７は、一時オブジェクトについての情報を得て制限値を決定する処理を説明するフローチャートである。図７に示す処理は、リクエスト仲介処理のサービスを開始する場合に前処理として実行される。この処理の実行により、リクエストの種類の制限値、リクエストによって転送されるデータ及びオブジェクトの種類と数の制限値、リクエストの同時並行使用数の制限値、及び、事前配置すべき一時オブジェクトの種類と数などの制限値のパラメータを得る。
【０１０２】
開発時において、または、運用開始時において、サービスへの接続要求処理４００（図４）およびリクエスト仲介処理１０００（図９）の開始前の前処理として、図７に示す処理８００を行う。この処理８００では、まず、アプリケーションのソースコード・インタフェース定義・サービス定義・プログラムメタ情報・コマンド行のオプション指定、設定画面、設定ファイル・コンパイルされたプログラムのうち一つ以上を解析する（ステップ８０１）。解析の結果、得られた情報から、リモートでサービスすべきリクエストの種類Ｒを抽出し（ステップ８０２）、リクエストによって転送されるデータ及びオブジェクトの種類と数Ｐを抽出し（ステップ８０３）、使用ユーザ数や同時セッション数Ｓを抽出する（ステップ８０４）。これらにより得られた制限値のパラメータがそれぞれの制限手段に設定される制限値となる（ステップ８０５）。これらに仲介装置が、各セッションのために内部で使用する一時オブジェクトＴ１・Ｔ２を加味すると、必要となる一時オブジェクトの種類と数が判明する。更に、事前配置（図５のステップ５０２）すべき一時オブジェクトの最大の範囲と最大メモリ量Ｍｍａｘが決定される（ステップ８０６）。これらの符号の意味は後述する。
【０１０３】
このようにして、アプリケーションがどの種類の一時オブジェクトを、どれくらいの数だけ使用するか、そして、何台のクライアントやいくつの通信相手に対して同時にサービスを提供すればよいかを知ることにより、十分なメモリを割り当てることができる。このため、メモリ使用量がシステムに与えられたメモリ割当量を超えてしまい、ＧＣが発生する状態になることを防ぐことができる。
【０１０４】
さて、アプリケーションが不変オブジェクトを生成した場合、前述したように、不変オブジェクトは状態が変更できないため、このオブジェクトは再利用不可能である。したがって、仲介装置を設計する際にゼロＧＣシステムとするには、不変オブジェクトを使用しない処理とすることが有効である。
【０１０５】
ところが、アプリケーションによっては、アプリケーションがリクエストの引数あるいは返値に不変オブジェクトを指定したため、仲介装置が不変オブジェクトを生成しなければならないことがある。例えば、図１０に示すプログラム例においては、リモートなメソッド１２０１は、引数として「ＩｍｍｕｔａｂｌｅＤａｔａ」（１２０３）クラスのオブジェクトを取る。
【０１０６】
このアプリケーションのプログラムの実行において、サーバ側仲介装置１２２（図１）は、アプリケーション（サーバ・プログラム）１２１内にあるサーバ・メソッドの実体を呼び出す際に、当該オブジェクトのコピーを引数として渡して処理させなければならない。そのオブジェクトのコピーの作成が新規の一時オブジェクトの生成になる。そのオブジェクトの新規生成を防ぐため、サーバ側仲介装置１２２は、メソッド１２０２の実行により、ＩｍｍｕｔａｂｌｅＤａｔａ（１２０３）のサブクラスである可変オブジェクトＭｕｔａｂｌｅＤａｔａ（１２０４）を合成して渡すことにより、この可変オブジェクトは再利用することができる。
【０１０７】
オブジェクト１２０３が不変オブジェクトであることは、ｆｉｎａｌフィールドの存在により検出される。オブジェクト１２０４は、オブジェクト１２０３のｆｉｎａｌフィールドからｆｉｎａｌを除去したバージョンであり、開発時あるいは実行時に合成される。これは、メソッド１２０２にあるように、返値が不変オブジェクトである場合も同様である。ｆｉｎａｌクラスであるＳｔｒｉｎｇ型のように互換性のあるサブクラスが合成できない場合は、アプリケーション開発者はＳｔｒｉｎｇＢｕｆｆｅｒ型のような可変オブジェクトを使用するよう要請される場合がある。
【０１０８】
また、基本型（例えばｉｎｔ）がオブジェクトではない言語では、基本型はヒープメモリを使用しない。一方で、多くのオブジェクト指向プログラミング言語において、設計の柔軟性のために、基本型をオブジェクトとして扱うことを可能とするラッパーオブジェクト（例えばｊａｖａ．ｌａｎｇ．Ｉｎｔｅｇｅｒ）を提供している。いくつかの言語では、ラッパーオブジェクトは不変オブジェクトである。リクエスト中でラッパーオブジェクトを転送する必要がある際は、ヒープメモリの使用を避けるために、基本型のラッパーオブジェクトを基本型に置き換える操作を行う。アプリケーション開発者は、リクエストにおいてラッパーオブジェクトではなく、基本型を使用するよう要請される場合がある。
【０１０９】
不変オブジェクトの可変オブジェクトへの置換は、オブジェクトの再使用を可能にし、ＧＣの発生を抑制することに寄与する。
【０１１０】
また、本発明を利用していない既存の仲介装置のソースコードを読み込んで、一時オブジェクトの検出、一時オブジェクトを再利用するコードへの変換、不変オブジェクトの可変オブジェクトへの変換等、本発明の適用を行う変換システムは有用である。
【０１１１】
さて、アプリケーションによっては、本発明による仲介装置のように、複数の制限手段によりいくつかの種類のリクエストが制限されて、ゼロＧＣ処理を行う通信と、ゼロＧＣ処理を行わない通信を混在させて使用したいことがある。ゼロＧＣ処理を行うかどうかは、セッション毎、リクエスト毎、通信相手毎、通信内容の重要性により、あるいは仲介装置全体で切り替えることができるように、本発明の仲介装置が構成されてもよい。このような構成により、本発明の仲介装置は、多様なアプリケーション開発の要求に対応できるものとなる。
【０１１２】
図１２は、リクエスト仲介処理においてゼロＧＣ処理を行うモードと行わないモードの切り替え処理を説明するフローチャートである。リクエスト仲介処理において、このように動作モードの切り換えを行い、それぞれの動作モードでの仲介処理を行うことができる。この場合には、アプリケーションは、仲介装置が当該リクエスト仲介処理に際してゼロＧＣ処理が必要か否かを示す状態変数を設定しておく。リクエスト仲介処理が始まると、その状態変数を用いてゼロＧＣ処理が必要であるか否かを判定し（ステップ１４０１）、必要である場合は、前述したようなゼロＧＣ処理付きのモードでリクエスト仲介処理を行う（ステップ１４０２）。必要でない場合には、ゼロＧＣ処理を行わないモードでのリクエスト仲介処理を行う（ステップ１４０３）。この、ゼロＧＣ処理を行わないモードでのリクエスト仲介処理は、従来手法によるリクエスト仲介処理である。
【０１１３】
このような動作モードの切り換えを可能にする実装は、仲介装置全体でモードの切り替えを行うことが最も簡易な実装であるが、セッション毎に動作モードを切り換えられるようにしてもよい。セッション毎に異なるモードが混在する処理を行う場合は、ゼロＧＣ処理を行わないモードがヒープメモリを消費するため、ヒープメモリをそれぞれのモードに割り当てて、リアルタイムＧＣや並行ＧＣを使用してヒープメモリの飽和を防ぐことが望ましい。
【０１１４】
本発明による仲介装置においては、ゼロＧＣ通信仲介装置がゼロＧＣ処理を行うモードとゼロＧＣ処理を行わないモードとを切り替えて混在させるモード切替手段を備えることにより、同一アプリケーション内で、ゼロＧＣ処理によりリアルタイム性の高い通信と、（制限手段によって）サービスが拒否さることがない通信とを切り替えて使用することが可能となる。このような構成にすると、ひとつのアプリケーションにおいて、ゼロＧＣ通信仲介装置と通常の仲介装置の両方を備える必要がなくなるため、計算資源や開発コストが軽減される効果がある。
【０１１５】
このように、リクエスト仲介処理において、ＧＣを発生させない方法は、あらゆるリクエストのパターンに対しても永久にゼロＧＣ状態を保つことが可能な方法（ハードゼロＧＣシステム）であるか、あるいは、アプリケーションによっては、制限手段によりリクエストが制限されるハードな解決手段では制限が強すぎて使用できない場合もあるため、より制限の緩い方法（ソフトゼロＧＣシステム）とするような構成であってもよい。
【０１１６】
図１１に示すリクエスト仲介処理においては、いくつかの制限手段を外し、引数の型と数のみによって制限する（ステップ１３０１）ようにしている。このように、リクエストの種類、転送されるオブジェクトの種類、同時セッション数に科せられた制限を緩めることにより、それらの数を制限することができないシステムにおいても、本発明による仲介装置を適用することが可能となる。
【０１１７】
アプリケーションによっては仲介装置がメモリを段々消費しても、アプリケーション自身が適当なタイミングで明示的にＧＣを行うことにより、リクエスト処理中においてゼロＧＣを保つことができる場合がある。また、ＯＳにメモリの追加を要求してもよい。そのようなアプリケーションでは、予め想定されている数より多い数のセッションを同時にサービスしたり、動的にメソッドの種類を増やしたり、あるいは、リクエストで転送されるオブジェクトの種類や数を限定しない、という柔軟性を持たせることが可能となる。
【０１１８】
さて、ここで、ハードゼロＧＣを実現するために仲介装置に割り当てるべきヒープメモリの量の算出方法について述べる。そのヒープメモリ量とは、即ち、ＧＣが発生しないことを保証するために仲介装置が必要とするメモリ量である。リクエストの種類の集合をＲ、あるリクエストにおいて引数あるいは返値及び転送されるデータ及びオブジェクトの種類と数の最大値が占めるメモリの量をＰ、セッション毎に仲介装置自身が必要とするメモリの量をＴ１、仲介装置自身が初期状態で必要とするメモリの量をＴ２、同時並行セッション数の最大制限値をＳとすると、仲介装置が最低限備えるべきヒープメモリ量Ｍｍａｘは図１５の式で表される。
【０１１９】
ヒープメモリの最大量算出式により算出した量のヒープメモリを割り当てておき、第１の態様の仲介装置のような制限手段により制限を課すことにより、ヒープメモリの使用量が割当量を超えないことが保証される。逆に、図１５の式を利用すると、割り当てられたヒープメモリ量から許される最大セッション数等を求めることも可能である。
【０１２０】
しかし、ヒープメモリの最大量を使用するのは全てのクライアントが全てのリクエストを同時に発行した極大負荷状態のみである。多くのシステムでは極大負荷状態に至ることは少ないため、ヒープメモリの最大量を備える必要はない場合もある。ハードゼロＧＣをより強く保証するため最大ヒープメモリ量に近いメモリを備えることと、ハードゼロＧＣの破れを許容してヒープメモリ量を削減することはトレードオフ関係にある。システムに適合するトレードオフ関係を把握し、仕様上十分なハードゼロＧＣ保証度に合わせた適切なヒープメモリ量を与えることもひとつの好ましい実施例である。
【０１２１】
本発明による仲介装置は、またハードウェアを用いて実装することも可能である。ハードウェアで仲介装置を実装する場合、動的に生成・消滅するオブジェクト（ハードウェアとしてはメモリ上の小領域）の効率的な管理をハードウェアでいかに実現するかが重要なポイントとなる。ハードウェア実装のためのコンポーネントおよびアーキテクチャは、図２に示されるシステム構成と同様である。ただし、オブジェクト指向言語を使用するか否かは問わない。昨今のハードウェア・ソフトウェア協調設計ツールの進歩により、一時オブジェクト格納手段や一時オブジェクト管理手段等の本発明の一部あるいは全部をハードウェア記述言語で記述し、ハードウェアに変換することは困難ではない。
【０１２２】
本発明を適用してメモリ管理を行うことにより、メモリの空き領域を大規模に回収するためのハードウェアを削減することが可能となる。また、メモリ管理のための通信の中断を抑制することが可能となる。
【産業上の利用可能性】
【０１２３】
以上に説明したように、本発明による仲介装置は、ＧＣを備えるプログラミング言語で実装されたリクエスト仲介装置、またはメモリ管理を備えるハードウェアで実装されたリクエスト仲介装置におけるリアルタイム性を大幅に向上させるため、ネットワーク上で通信を行う産業用機器、ロボット、通信デバイス、宇宙機器、自動車等で広く利用可能である。
【図面の簡単な説明】
【０１２４】
【図１】本発明によるゼロガベージコレクション通信のための仲介装置の位置付けを説明する図である。
【図２】本発明によるゼロガベージコレクション通信のための仲介装置のシステム構成を説明する図である。
【図３】一時オブジェクト格納手段と一時オブジェクト管理手段がガベージコレクション手段と言語ランタイムと協調する様子を表す図である。
【図４】サービスへの接続要求を仲介する処理を説明するフローチャートである。
【図５】事前配置を伴うシステムにおいて一時オブジェクトの事前配置と再利用を行うステップを説明する第１のフローチャートである。
【図６】事前配置を伴うシステムにおいて一時オブジェクトの事前配置と再利用を行うステップを説明する第２のフローチャートである。
【図７】一時オブジェクトについての情報を得て制限値を決定する処理を説明するフローチャートである。
【図８】アプリケーション（クライアント・プログラム）の一例を示す図である。
【図９】サービス要求の仲介処理における一時オブジェクトを管理する処理を示すフローチャートである。
【図１０】不変オブジェクトの使用例を説明する図である。
【図１１】制限を緩和したリクエスト仲介処理のステップを説明するフローチャートである。
【図１２】リクエスト仲介処理においてゼロＧＣ処理を行うモードと行わないモードの切り替え処理を説明するフローチャートである。
【図１３】スタブコードとスタブコード生成手段の位置付けを表した図である。
【図１４】リクエストが制限値を越えた場合に行う延期処理を含む仲介処理を説明するフローチャートである。
【図１５】使用する最大ヒープメモリ量を算出する式を示す図である。
【符号の説明】
【０１２５】
１１０  クライアント・コンピュータ
１１１  アプリケーション（クライアント・プログラム）
１１２  クライアント側仲介装置
１２０  サーバ・コンピュータ
１２１  アプリケーション（サーバ・プログラム）
１２２  サーバ側仲介装置
１３０  通信媒体
２００  コンピュータ
２１２  ヒープメモリ
２２０  言語ランタイム
２２２  ガベージコレクタ
２３０  ゼロＧＣ通信仲介装置
２３２  一時オブジェクト格納手段
２３４  一時オブジェクト管理手段
２３５  リクエスト延期手段
２３６  リクエスト種類制限手段
２３７  転送データ数制限手段
２３８  同時並行使用数制限手段
２３９  動作モード切替手段
２４０  リクエスト種類制限値設定手段
２４１  転送データ数制限値設定手段
２４２  同時並行使用数制限値設定手段
２５０  アプリケーション
３１２  ヒープメモリ
３２０  言語ランタイム
３２２  ガベージコレクタ
３３０  ゼロＧＣ通信仲介装置
３３２  一時オブジェクト格納手段
３３４  一時オブジェクト管理手段
３４０  アプリケーション
１５１０  クライアント・コンピュータ
１５１１  アプリケーション（クライアント・プログラム）
１５１２  クライアント側スタブコード
１５１３  クライアント側仲介装置
１５２０  サーバ・コンピュータ
１５２１  アプリケーション（サーバ・プログラム）
１５２２  サーバ側スタブコード
１５２３  サーバ側仲介装置
１５３０  通信媒体
【図１】
2007086838.tif 000005
【図２】
2007086838.tif 000006
【図３】
2007086838.tif 000007
【図４】
2007086838.tif 000008
【図５】
2007086838.tif 000009
【図６】
2007086838.tif 000010
【図７】
2007086838.tif 000011
【図８】
2007086838.tif 000012
【図９】
2007086838.tif 000013
【図１０】
2007086838.tif 000014
【図１１】
2007086838.tif 000015
【図１２】
2007086838.tif 000016
【図１３】
2007086838.tif 000017
【図１４】
2007086838.tif 000018
【図１５】
2007086838.tif 000019