(57)【要約】【課題】ソケットのクローズ漏れに起因する資源不足を解消する。【解決手段】仮想マシンが生成できるソケットのオブジェクトの数に上限を設定し、ソケットのオブジェクトを生成しようとした際にその上限を超えていたならガベージコレクションを実行する。その中でソケットのオブジェクトをクローズし、ソケットにより使用されていた資源を解放する。【選択図】図９
2018206026.tif 000002
【特許請求の範囲】
【請求項１】
通信のインタフェースとしてソケットのオブジェクトを用いる情報処理装置であって、
生成されたソケットのオブジェクトの生成済み数量を管理するソケット管理手段と、
前記生成済み数量が上限値を超えていると、ガベージコレクションを実行して生成済みの前記ソケットのオブジェクトをクローズして該ソケットのオブジェクトのための資源を解放する解放手段と
を有することを特徴とする情報処理装置。
【請求項２】
請求項１に記載の情報処理装置であって、
生成されたオブジェクトは第１のメモリ領域に保存され、
前記第１のメモリ領域から第２のメモリ領域へとオブジェクトを移すプロモート手段をさらに備え、
前記解放手段による解放の対象を、前記第１のメモリ領域および前記第２のメモリ領域のいずれか一方に限定することを特徴とする情報処理装置。
【請求項３】
請求項２に記載の情報処理装置であって、
前記解放手段による解放の対象を、前記第１のメモリ領域に限定することを特徴とする情報処理装置。
【請求項４】
請求項３に記載の情報処理装置であって、
前記プロモート手段は、前記ソケットのオブジェクトについては、前記第２のメモリ領域へと移さないことを特徴とする情報処理装置。
【請求項５】
請求項２に記載の情報処理装置であって、
前記解放手段による解放の対象を、前記第２のメモリ領域に限定することを特徴とする情報処理装置。
【請求項６】
請求項１乃至５のいずれか一項に記載の情報処理装置であって、
前記ソケット管理手段および前記解放手段は、前記情報処理装置により実行される仮想マシンに含まれ、
前記ソケットのオブジェクトは、前記仮想マシンで実行されるアプリケーションのために生成されることを特徴とする情報処理装置。
【請求項７】
通信のインタフェースとしてソケットのオブジェクトを用いる情報処理装置による資源管理方法であって、
生成されたソケットのオブジェクトの生成済み数量を管理し、
前記生成済み数量が上限値を超えていると、ガベージコレクションを実行して生成済みの前記ソケットのオブジェクトをクローズして該ソケットのオブジェクトのための資源を解放する
ことを特徴とする資源管理方法。
【請求項８】
通信のインタフェースとしてソケットのオブジェクトを用いるコンピュータを、
生成されたソケットのオブジェクトの生成済み数量を管理するソケット管理手段と、
前記生成済み数量が上限値を超えていると、ガベージコレクションを実行して生成済みの前記ソケットのオブジェクトをクローズして該ソケットのオブジェクトのための資源を解放する解放手段と
して機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーションを実行する情報処理装置および資源管理方法に関する。
【背景技術】
【０００２】
従来、機器で動作するアプリケーションが使用する資源の管理が重要となっている。資源の例としては、プログラムが動作するときにデータを配置するメモリがある。また、プログラムが通信するときに使うソケットがある。これらの資源は利用できる量に限りがある。資源の管理をソフトウェアの開発者に任せると、開発の手間が増大する。そこで、アプリケーションを動作させるプラットフォームが資源の管理を担うことが一般的である。例えば、メモリ資源を管理するガベージコレクション（ｇａｒｂａｇｅ  ｃｏｌｌｅｃｔｉｏｎ；ＧＣ）という仕組みを備えたプラットフォームが一般的である。アプリケーションは使用するデータは、オブジェクトという形式でメモリ上に確保される。アプリケーションが使用を終えて参照しなくなったオブジェクトは、不要なオブジェクトであるため、ＧＣで消去される。オブジェクトの消去で解放されたメモリは、再利用できる。ＧＣはメモリだけでなく、ソケットの管理にも関係している。ソケットを作成するには、ＯＳが管理している有限の資源を必要とする。ソケットはＯＳから資源を取得してオブジェクトとして作成され、通信が終了するとクローズ（close）される。クローズすると、オブジェクトがＯＳから取得した資源は解放され、再利用できる。
【０００３】
しかし、通信エラーなどが原因で、不要となったソケットのオブジェクトがクローズされないクローズ漏れとなることがある。クローズ漏れしたソケットは資源を占有したまま残る。この状況に対応するため、ＧＣでソケットのオブジェクトを消去するときには、ソケットのクローズ状態を確認し、クローズ漏れであればクローズを実行する。ＧＣ中は他の処理の応答が遅くなるため、必要なときだけＧＣを実行することが課題となる。そこで、ＧＣを実施する機器が省電力状態になるときにＧＣを実行する仕組み（特許文献１）が考案されている。
【０００４】
特許文献１では、省電力状態になるときには機器の応答が遅くなってもよいとして、ＧＣを実行する。これにより、省電力状態から復帰後のＧＣを抑制し、機器の応答を早く保つ。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１０−２４４３４２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ソケットのクローズ漏れがある場合、省電力状態になるときにＧＣを実行するだけでは、ＧＣの実行が不十分という課題がある。ソケットはＯＳから資源を取得して作成される。クローズ漏れしたソケットをクローズしないと、資源を取得したままになってしまい、ＯＳの資源が枯渇する。この状態がいったん生じると、次の省電力状態まで、プログラムが新しい通信をするためにソケットを作成しようとしたときに、ＯＳから資源を取得できずにソケットの作成に失敗し、新しい通信ができないという問題が起こる。
【０００７】
本発明は上記の課題に鑑みてなされたものであり、ソケットのクローズ漏れに起因する資源不足を解消できる情報処理装置および資源管理方法を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記目的を達成するために本発明は以下の構成を有する。
【０００９】
通信のインタフェースとしてソケットのオブジェクトを用いる情報処理装置であって、
生成されたソケットのオブジェクトの生成済み数量を管理するソケット管理手段と、
前記生成済み数量が上限値を超えていると、ガベージコレクションを実行して生成済みの前記ソケットのオブジェクトをクローズして該ソケットのオブジェクトのための資源を解放する解放手段と
を有することを特徴とする情報処理装置。
【発明の効果】
【００１０】
本発明によれば、ソケットのクローズ漏れに起因する資源不足を解消できる。
【図面の簡単な説明】
【００１１】
【図１】情報処理装置のハードウェア構成の一例を示す概略図である。
【図２】情報処理装置上に構築するシステム構成の一例を示す模式図である。
【図３】仮想マシンが管理するメモリの領域を示す模式図である。
【図４】資源を管理する機能の構成を示す模式図である。
【図５】仮想マシン上でオブジェクトを作成する処理の流れを示すフローチャートである。
【図６】一般的な仮想マシンによるGC処理の流れを示す詳細フローチャートである。
【図７】一般的な仮想マシンがソケットを作成する処理の流れを示すフローチャートである。
【図８】一般的な仮想マシンがソケットをGCする処理の流れを示すフローチャートである。
【図９】実施例１にかかる仮想マシンがソケットを作成する処理の流れを示すフローチャートである。
【図１０】実施例１にかかる仮想マシンがソケットをGCする処理の流れを示すフローチャートである。
【図１１】実施例２にかかる仮想マシンがソケットを作成する処理の流れを示すフローチャートである。
【図１２】実施例２にかかる仮想マシンによるGC処理の流れを示す詳細フローチャートである。
【図１３】実施例３にかかるプロモートの処理の流れを示すフローチャートである。
【図１４】実施例４にかかる仮想マシンがソケットを作成する処理の流れを示すフローチャートである。
【図１５】実施例４にかかる仮想マシンによるGC処理の流れを示す詳細フローチャートである。
【発明を実施するための形態】
【００１２】
以下、本発明を実施するための形態について図面を用いて説明する。
＜実施形態１＞
本実施形態を説明するにあたって、まずシステム構成と一般的なＧＣによる資源管理方法について説明する
●ハードウェアとシステムの構成
図１は、一般的な情報処理装置１０１のハードウェア構成の一例を示す図である。図１に示すように情報処理装置１０１は、ハードウェア構成として、ＣＰＵ１１を含む。ＣＰＵ１１が、記憶部１３に記憶されている後述するアプリケーションやプログラム実行環境等の各々に対応するプログラムに基づき処理を行うことによって、後述する各機能、又はフローチャートを実現する。また、ＣＰＵ１１には、バス１０を介して、入力部１２、記憶部１３、表示部１４及び外部接続ＩＦ１５が接続されている。入力部１２は、情報を入力するキーボード及び／又はマウスあるいはタッチパネルなどである。記憶部１３は、例えば、ＲＯＭ、ＲＡＭ、ハードディスク装置等を含み、上述した各プログラム以外に、プログラムに基づく処理で用いられるデータ等を記憶する。表示部１４は、画面等を表示するディスプレイである。外部接続ＩＦ１５は、ネットワークインタフェース、外部機器との各種接続インタフェースである。
【００１３】
尚、ＣＰＵ１１はプログラムを実行することで各種の手段として機能することが可能である。なお、ＣＰＵ１１と協調して動作するＡＳＩＣなどの制御回路がこれらの手段として機能してもよい。また、ＣＰＵ１１と情報処理装置１０１の動作を制御する制御回路との協調によってこれらの手段が実現されてもよい。また、ＣＰＵ１１は単一のものである必要はなく、複数であってもよい。この場合、複数のＣＰＵ１１は分散して処理を実行することが可能である。また、複数のＣＰＵ１１は単一のコンピュータに配置されていてもよいし、物理的に異なる複数のコンピュータに配置されていてもよい。なお、ＣＰＵ１１がプログラムを実行することで実現する手段が専用の回路によって実現されてもよい。
【００１４】
次に、情報処理装置１０１上に構築するシステム構成について、図２を用いて説明する。図２は、情報処理装置１０１のシステム構成の一例を示す図である。オペレーティングシステム２０１は、システム全体の基盤となるソフトウェアである。プロセス２０２は、オペレーティングシステム２０１上でソフトウェアを動作させる実行の単位である。また資源獲得の観点から見ると、プロセスはＯＳに対して資源を要求し、資源を割り当てられる単位であり、一つのプロセス２０２が利用できる資源の量は、オペレーティングシステム２０１によって制限される。仮想マシン２０３は、オペレーティングシステム２０１上のプロセスで動作し、自身の上でアプリケーションが動作する環境を提供するソフトウェアである。アプリケーション２０４は仮想マシン２０３上で動作するアプリケーションである。プロセス２０２上では複数のソフトウェアを動作させることができる。複数のソフトウェアを一つのプロセス２０２上で動作させる利点は、プロセス２０２間の通信コストがなくなることである。図２では、一つのプロセス２０２上で仮想マシン２０３と任意のソフトウェア２０５が動作している。たとえば仮想マシン２０３と任意のソフトウェア２０５は共通のプロセスＩＤを持ち、そのプロセスＩＤでＯＳに資源を要求し、ＯＳはそのプロセスＩＤに対して上限まで資源を割り当てることができる。
【００１５】
また情報処理装置１０１は、図１に示したようなハードウェアや図２に示しがソフトウェアなどを持てばよいことから、コンピュータのほか、多機能周辺機器（ＭＦＰ）と呼ばれる画像形成装置などであってもよい。この場合には、ハードウェアとしてスキャナやプリンタなどを有し、またソフトウェアとしてスキャナやプリンタを制御し、またその機能をオペレーティングシステム２０１を介して他のプログラムに提供するためのプログラムを含む。
【００１６】
次に、情報処理装置１０１のシステム上で仮想マシン２０３がメモリを管理する仕組みについて、図３を用いて説明する。メモリの実体は、記憶部１３のＲＡＭなどである。ただしＯＳ２０１が仮想化機能を提供している場合には、各プロセスに割り当てられる資源は仮想化された仮想資源であってよい。図３は、仮想マシンが管理するメモリの領域を示す図である。メモリを管理する仕組みは、ガベージコレクション（ＧＣ）と呼ばれている。ＧＣでは、プログラムがメモリ上に確保したオブジェクトのうち、不要になったものを消去してメモリを解放する。オブジェクトの種類としては、ソケットのオブジェクト３０３、ファイルのオブジェクト３０４、文字列のオブジェクト３０５などがある。ＧＣはオブジェクトを新規に作成するためのメモリが不足したタイミングで実行される。
【００１７】
ＧＣの方式はいくつか提案されているが、ここでは世代別ＧＣについて説明する。世代別ＧＣでは、メモリ領域をＹｏｕｎｇ領域（第１のメモリ領域）３０１とＯｌｄ領域（第２のメモリ領域）３０２に分けて管理する。Ｙｏｕｎｇ領域３０１には、作られたばかりのオブジェクトが配置される。これは、オブジェクトの多くが、作成されたあとすぐに不要となるという性質を利用するためである。新しいオブジェクトをＹｏｕｎｇ領域３０１にだけ配置しておくことで、作成後すぐに不要となったオブジェクトをＹｏｕｎｇ領域３０１の走査だけで消去でき、ＧＣの遅延が抑制される。
【００１８】
Ｙｏｕｎｇ領域３０１のＧＣをＹｏｕｎｇＧＣと記す。複数回のＹｏｕｎｇＧＣでも消去されなかったオブジェクトは、Ｏｌｄ領域３０２に移動する。この移動をプロモートと記す。
【００１９】
Ｏｌｄ領域３０２を対象としてＧＣすることをＦｕｌｌＧＣと記す。ＹｏｕｎｇＧＣとＦｕｌｌＧＣの違いは、対象とするメモリ領域だけではない。メモリ領域の走査方法も違っており、ＦｕｌｌＧＣはＹｏｕｎｇＧＣよりも処理に時間がかかるという性質がある。ＧＣは例えば、仮想マシン２０３の一機能として実現され、それ自体が資源を消費するので、その実行により他のプログラムの応答性を低下させる。そのため、世代別ＧＣでは、なるべくＹｏｕｎｇＧＣだけを実行するようにして、ＧＣによる応答性の低下を抑えている。そのため、ＧＣを実行するとＹｏｕｎｇＧＣだけが実行され、ＦｕｌｌＧＣは実行されないことが多くなる。
【００２０】
次に、資源を管理する機能の構成について、図４を用いて説明する。図４は資源を管理する機能の構成を示す図である。仮想マシン２０３は、ＧＣの実行を管理するＧＣ管理部４０１を備える。また、仮想マシン２０３は、仮想マシン２０３が使用する情報処理装置１０１のソケット数を集計してソケット作成を管理するためのソケット管理部４０２を備える。また、アプリケーション２０４は、仮想マシン２０３からソケットを取得する（あるいは生成する）ソケット取得部４０３と、取得したソケットを解放する（あるいはクローズする）ソケット解放部４０４とを備える。
【００２１】
ここまで、情報処理装置１０１の構成について説明した。本実施形態で想定する仮想マシン２０３は、Ｊａｖａ（登録商標）仮想マシンである。ソケット取得部４０３はソケットクラスのコンストラクタなどが対応する。ソケット解放部４０４はソケットクラスのＡＰＩであるｃｌｏｓｅメソッドが対応する。
【００２２】
●一般的なＧＣの方法
次に、仮想マシン２０３上でオブジェクトを作成する処理の流れについて、図５を用いて説明する。図５は、仮想マシン２０３上でオブジェクトを作成する処理の流れを示すフローチャートである。
【００２３】
アプリケーション２０４、または仮想マシン２０３自身がオブジェクトの作成を開始すすると、仮想マシン２０３はオブジェクトを配置できる空きメモリがあるかを確認（或いは判定）する（ステップＳ５０１）。空きメモリがあれば、オブジェクトを作成する（ステップＳ５０２）。空きメモリがなければ、ＧＣを実行する（ステップＳ５０３）。ステップＳ５０３の詳細については図６を用いて後述する。
【００２４】
そして、ＧＣが成功したかを確認する（ステップＳ５０４）。ＧＣが成功していれば、すなわち空きメモリが増えたならステップＳ５０２を実行してオブジェクトを作成する。ＧＣが成功していなければ、オブジェクトの作成は失敗する（ステップＳ５０５）。作成が失敗すると、仮想マシン２０３上ではＥｒｒｏｒ、あるいはＥｘｃｅｐｔｉｏｎが発生する。
【００２５】
次に、一般的な仮想マシン２０３によるＧＣの処理の流れについて、図６を用いて説明する。図６は、一般的な仮想マシンによるＧＣ処理の流れを示す詳細フローチャートであり、ステップＳ５０３に対応する。
【００２６】
ＧＣは、ステップＳ５０３において、オブジェクトのサイズを指定して開始される。まずはＹｏｕｎｇ領域３０１の不要オブジェクトを消去するＹｏｕｎｇＧＣを行う（ステップＳ６０１）。そして、ステップＳ５０１と同様に、ＹｏｕｎｇＧＣによって指定されたサイズの空きメモリができたかを確認する（ステップＳ６０５）。
【００２７】
空きメモリができていれば、ＧＣは成功となる（ステップＳ６０４）。空きメモリができていなければ、Ｏｌｄ領域３０２の不要オブジェクトを消去するＦｕｌｌＧＣを実行する（ステップＳ６０２）。そして、ステップＳ５０１と同様に空きメモリができたかを確認する（ステップＳ６０６）。空きメモリができていれば、ステップＳ６０４を実行し、ＧＣは成功となる。空きメモリができていなければ、ＧＣは失敗となる（ステップＳ６０３）。
【００２８】
次に、一般的な仮想マシン２０３がソケットを作成する処理の流れについて、図７を用いて説明する。図７は、一般的な仮想マシンがソケットを作成する処理の流れを示すフローチャートである。このフローチャートの処理は、ステップＳ５０２に対応している。
【００２９】
前述の通り、ソケットはオブジェクトの一種である。ソケットはオペレーティングシステム２０１の資源を確保して作成される。ソケットは外部との通信に用いるものであり、通信が終わればｃｌｏｓｅメソッドによってクローズされるべきものである。ソケットのクローズによってオペレーティングシステム２０１から確保した資源が解放され、新しく作れるソケットの数が回復する。
【００３０】
ソケットは、アプリケーション２０４または仮想マシン２０３自身が作成する。オブジェクトの作成は、図５におけるステップＳ５０２と同様に行う（Ｓ７０１）。ソケットの作成は、ソケット管理部４０２がソケットを作成することで行われる。ソケットの作成を要求したのがアプリケーション２０４の場合は、ソケット取得部４０３がソケット管理部４０２に依頼して、ソケットが作成される。
【００３１】
作成されたソケットは、利用が終わればクローズされる。ソケットのクローズはアプリケーション２０４からソケット解放部４０４を用いて実行される。あるいは、仮想マシン２０３内部から実行される。
【００３２】
しかし、アプリケーション２０４の予期せぬ動作や、ネットワークのエラーによって、ソケットのクローズが明示的に実行されないことがある。この場合、資源の解放漏れが生じてしまい、新しく作れるソケットの数が不適切に減ってしまう。そこでＧＣでは、ソケットのオブジェクトを消去するときに、クローズされているかを確認し、未クローズならばクローズする。
【００３３】
一般的な仮想マシン２０３がソケットをＧＣする処理の流れについて、図８を用いて説明する。図８は、一般的な仮想マシンがソケットをＧＣする処理の流れを示す詳細フローチャートである。このフローチャートの処理は、ステップＳ６０１あるいはステップＳ６０２において実行される。
【００３４】
ソケットのＧＣでは、まずＧＣ管理部４０１が、ＧＣ対象のソケットがクローズ済みかどうかを確認する（ステップＳ８０１）。クローズ済みでなければ、クローズする（ステップＳ８０２）。ステップＳ８０１でクローズ済み、あるいはステップＳ８０２が完了すれば、ＧＣ管理部４０１はＧＣ対象のソケットのオブジェクトを消去し、空きメモリを作る（ステップＳ８０３）。なおＧＣ対象とは前述したＹｏｕｎｇＧＣあるいはＦｕｌｌＧＣにより対象とされる領域である。図８の処理は、例えばスリープモードなど、プロセスが停止あるはアイドル状態であるようなタイミングで実行されるため、使用中のソケットをクローズしてしまうことがない。
【００３５】
ここまで、一般的な仮想マシン２０３のＧＣの仕組みと、ソケットのオブジェクトの作成と消去について説明した。
【００３６】
●本実施形態によるＧＣの方法
ステップＳ５０１で説明したように、ステップＳ６０１のＧＣはメモリが不足するまで実行されない。そのため、ソケットのクローズ漏れが多発しつつ空きメモリが十分にある場合、ステップＳ６０１のＧＣが実行されることはなく、図８の処理も行われない。そのためメモリが不足する前にオペレーティングシステム２０１の資源が枯渇して、あるいは一プロセスに対する資源割り当ての上限を超えて、ソケットの作成に失敗する問題が生じる。
【００３７】
また、情報処理装置１０１上で動作する各プロセスが使用できる資源には限りがある。図２で示したように、プロセス２０２上で仮想マシン２０３と任意のソフトウェア２０５が動作するとき、仮想マシン２０３が資源を消費し尽くしてしまうと、同一プロセスの任意のソフトウェア２０５がソケットを作成できず、動作がおかしくなってしまうことがある。
【００３８】
そこで、ソフトウェアが使用するソケット数に上限を設けるとともに、クローズ漏れしたソケットをクローズして資源を解放する方法が必要となる。ソケット数の上限を設ける方法としては、オペレーティングシステム２０１がプロセス２０２の使用する資源量を制限する手段が知られている。しかし、この手段ではプロセス単位でしか制限できないため、同一のプロセス２０２上で動作する仮想マシン２０３と任意のソフトウェア２０５のそれぞれに対して制限することができない。
【００３９】
そこで、仮想マシン２０３が使用するソケット数に上限を設けるとともに、クローズ漏れしたソケットを解放する方法を、実施形態１として説明する。
【００４０】
●実施形態１に特徴的な処理
図９は、仮想マシン２０３がソケットを作成する処理の流れを示すフローチャートである。この処理では、仮想マシン２０３が使用するソケット数を限定することで、仮想マシン２０３と同じプロセス上で動作する任意のソフトウェア２０５が用いるソケットに影響が生じないようにしている。図９は、本実施形態においては図７に代えて実行される。
【００４１】
ソケットの生成では、生成する前に、生成済みのソケットの数量が仮想マシン２０３のソケットの上限数（すなわち上限値或いは閾値）を超えるかどうかを確認する（ステップＳ９０１）。ソケットの上限数はソケット管理部４０２に設定されている。また生成されているソケットの数を示す現在ソケット数もソケット管理部４０２に保存されている。ソケットの上限数を超えないと判定した場合は、ステップＳ７０１と同様にソケットのオブジェクトを生成する（ステップＳ９０５）。そして、ソケット管理部４０２がソケット数の集計（すなわち現在ソケット数）を１増やす（ステップＳ９０２）。
【００４２】
ステップＳ９０１で上限数を超えると判定した場合、ＧＣ管理部４０１によってステップＳ５０３と同様にＧＣを実行する。ただし、ステップＳ５０３で実行される図６のステップＳ６０１またはステップＳ６０２では、図８に代えて図１０に示す処理が実行される。図１０についてはこの後で説明する。そして、ＧＣの実行後に、ステップＳ９０１と同様に生成されているソケット数が上限数を超えるかを確認する（ステップＳ９０３）。
【００４３】
ステップＳ９０３において上限数を超えなければ、ステップＳ７０１，Ｓ９０２を実行する。ステップＳ９０３において上限数を超えるなら、ステップＳ５０５と同様にソケットのオブジェクトの作成は失敗する（ステップＳ９０４）。
【００４４】
次に、ソケットのＧＣについて、図１０を用いて説明する。図１０は、仮想マシン２０３がソケットをＧＣする処理の流れを示すフローチャートであり、図８に代えて実行される。
【００４５】
ソケットのＧＣを開始すると、ステップＳ８０１と同様に、ソケットがクローズ済みかを確認する。クローズ済みであれば、ステップＳ８０３と同様にソケットのオブジェクトを消去する。
【００４６】
クローズ済みでなければ、ステップＳ８０２と同様にソケットをクローズする。そして、ソケット数の集計（すなわち現在ソケット数）を１減らす（ステップＳ１００１）ステップＳ８０３と同様に、オブジェクトを消去する。なお図１０の処理は、対象領域にソケットが複数ある場合、そのソケットそれぞれに対して適用してもよい。このようにすれば、ステップＳ６０１、Ｓ６０２において、対象の領域から不要な（すなわち漏れた）ソケットをすべて解放できる。
【００４７】
以上、同一プロセスで動作する任意のソフトウェア２０５が使用するソケットに影響させないように、仮想マシン２０３が使用するソケット数に上限を設ける方法を説明した。さらに、上限数を超えるときにはクローズ漏れしているソケット資源を解放する方法について説明した。
【００４８】
これにより、仮想マシン２０３上でソケットのクローズ漏れが発生しても、ソケットを作成するときに資源が不足していると判断したらＧＣを実行し、クローズ漏れしたソケットをクローズすることで資源を回復させて、新しいソケットを作成できる。
【００４９】
＜実施形態２＞
ソケット数が上限に達したときのＧＣでは、クローズ漏れしたソケットをすべて解放させるために、ＦｕｌｌＧＣを実行することが好ましい。この方法について、図１１を用いて説明する。図１１は、仮想マシンがソケットを作成する処理の流れを示すフローチャートである。
【００５０】
ソケットの作成を開始すると、ステップＳ９０１と同様にソケットの上限数を超えるかを確認する。ソケットの上限数を超えなければ、ステップＳ９０５，Ｓ９０２と同様に、ソケットの作成と集計数の更新を行う。
【００５１】
ステップＳ９０１において上限数を超える場合、ＧＣが参照するフラグであるＦｕｌｌＧＣフラグをセットする（ステップＳ１１０１）。そして、ＦｕｌｌＧＣフラグを参照するＧＣを実行する（ステップＳ１１０２）。ＦｕｌｌＧＣフラグを参照するＧＣの詳細については、図１２を用いて後述する。ＧＣの実行が終われば、ＦｕｌｌＧＣフラグを解除する（ステップＳ１１０３）。
【００５２】
そして、ステップＳ９０３と同様に上限数を超えるかを確認する。上限数を超えない場合、ステップＳ９０５、ステップＳ９０２を実行して作成は完了する。上限数を超える場合、ステップＳ９０４と同様に作成は失敗する。
【００５３】
次に、ＦｕｌｌＧＣフラグを参照するＧＣの詳細について、図１２を用いて説明する。図１２は、ステップＳ１１０２におけるＧＣ処理の流れを示す詳細フローチャートである。
【００５４】
ＧＣを開始すると、ステップＳ６０１と同様にＹｏｕｎｇＧＣを実行する。ここでは例えば図１０の処理が、未開放のソケットすべてを対象として実行される。そして、ステップＳ６０５と同様に空きメモリがあるかを確認する。空きメモリがなければ、ステップＳ６０２と同様にＦｕｌｌＧＣを実行する。ここでも例えば図１０の処理が、未開放のソケットすべてを対象として実行される。そしてステップＳ６０６と同様に空きメモリがあるかを確認し、空きメモリがなければステップＳ６０３と同様にＧＣ失敗となる。空きメモリがあれば、ステップＳ６０４と同様にＧＣ成功となる。
【００５５】
ステップＳ６０５において空きメモリがある場合、ＦｕｌｌＧＣフラグがセットされているかを確認する（Ｓ１２０１）。ＦｕｌｌＧＣフラグがセットされていれば、Ｓ６０２以降を実行する。ＦｕｌｌＧＣフラグがセットされていなければ、Ｓ６０４以降を実行する。
【００５６】
以上、ソケット数が上限に達したときのＧＣにおいて、ＦｕｌｌＧＣを実行してクローズ漏れのソケットをすべて解放する方法について、実施形態２として説明した。
【００５７】
この実施形態は、機器を高負荷な環境で動作させるときに、大きな効果を発揮する。高負荷な環境では、すぐに不要となる新しいオブジェクトの作成がｙｏｕｎｇ領域３０１内で大量に生じ、ＧＣが数秒間隔で頻発する。この環境では数秒以上通信に用いられたソケットのオブジェクトは、短時間でプロモートしてｏｌｄ領域３０２に移動する。プロモートしたソケットがクローズ漏れしたま不要となっても、一般的なＧＣでは何回繰り返してもｙｏｕｎｇ領域３０１を対象にしたＧＣだけが実行され、ｏｌｄ領域３０２のクローズ漏れしたソケットがクローズされない。すると、ソケットが容易に上限数を超えてしまい、新しいソケットを作成することができなくなってしまう。このとき本実施形態を適用して対象にＯｌｄ領域を含めることで、ｏｌｄ領域３０２にあるクローズ漏れのソケットがＧＣされ、新しいソケットを作成することができる。Ｙｏｕｎｇ領域のオブジェクトはいずれＯｌｄオブジェクトに移動されると考えれば、対象領域を一方、たとえばＯｌｄ領域だけに限定してもよい。
【００５８】
なお、本実施形態では仮想マシン２０３が使用するソケット数に上限を設けているが、ソケットの上限は本実施形態に限った環境ではない。仮想マシン２０３に上限を設けなくても、プロセス２０２が作成できるソケット数には上限があるため、機器を高負荷な環境で動作させる場合には同様の問題が生じる。本実施形態ではそのような場合にもソケットを解放して資源不足を解消できる。
【００５９】
＜実施形態３＞
ＦｕｌｌＧＣは負荷が高く、実行中の機器の応答性が低下する。そのため、負荷を下げるにはＹｏｕｎｇＧＣのみでソケットのオブジェクトをすべてＧＣする方法が好ましい。その方法について、図１３を用いて説明する。図１３は、ＧＣにおけるプロモートの処理の流れを示すフローチャートである。
【００６０】
ＧＣ中にプロモートが開始されると、ＧＣ管理部４０１はプロモートしようとしているオブジェクトがソケットであるかを確認する（ステップＳ１３０１）。ソケットであれば、プロモートせずに処理は完了する。ソケットでなければ、オブジェクトをＯｌｄ領域３０２に移動する（ステップＳ１３０２）。図１３の処理は、Ｙｏｕｎｇ領域にあってプロモート対象となるオブジェクトそれぞれに対して適用される。
【００６１】
これにより、ソケットのオブジェクトはＹｏｕｎｇ領域３０１に残り続けるため、ＹｏｕｎｇＧＣを実行するだけでクローズ漏れのソケットを解放できる。
【００６２】
以上、ＹｏｕｎｇＧＣのみでソケットのオブジェクトを確実にＧＣする方法について説明した。クローズ漏れしたソケットのクローズが必要なときに、ＹｏｎｎｇＧＣのみが実行されることで、機器の応答性の低下を抑えることができる。
【００６３】
＜実施形態４＞
実施形態３では、ＹｏｕｎｇＧＣのみでソケットのオブジェクトをすべてＧＣする方法について説明した。しかし、ＹｏｕｎｇＧＣのみでソケットのリーク（漏れ）が解消されるにも関わらずＦｕｌｌＧＣを実行してしまうと、機器の応答性が低下する。そのため、ソケットを解放するためにＧＣを実行するときには、ＦｕｌｌＧＣを実行しないことが好ましい。
【００６４】
しかし、一般的なＧＣではＹｏｕｎｇＧＣとＦｕｌｌＧＣを個別に実行することはできないように実装されている。そこで、フラグを参照してＧＣの動作を切り替える方法が必要となる。この方法について、実施形態４として説明する。
【００６５】
はじめに、ソケットの作成の流れについて図１４を用いて説明する。図１４は、仮想マシンがソケットを作成する処理の流れを示すフローチャートである。
【００６６】
ソケットの作成を開始すると、ステップＳ９０１と同様に上限数の確認を行う。上限数を超えない場合、ステップＳ９０５、ステップＳ９０２と同様にソケットの作成と集計数の更新を行う。
【００６７】
上限数を超える場合、ＹｏｕｎｇＧＣフラグをセットする（ステップＳ１４０１）。そして、ＹｏｕｎｇＧＣフラグを参照するＧＣを実行する（ステップＳ１４０２）。実行が終わると、ＹｏｕｎｇＧＣフラグを解除する（ステップＳ１４０３）。
【００６８】
そして、ステップＳ９０３と同様にソケット数の確認を行う。ソケットの上限を超える場合、ステップＳ９０４と同様に作成は失敗する。上限を超えない場合、ステップＳ９０５、ステップＳ９０２と同様にソケットの作成と集計数の更新を行う。
【００６９】
次に、ＹｏｕｎｇＧＣフラグを参照するＧＣの方法について、図１５を用いて説明する。図１５は、ステップＳ１４０２に対応するＧＣ処理の流れを示す詳細フローチャートである。
【００７０】
ＧＣを開始すると、ステップＳ６０１と同様にＹｏｕｎｇＧＣを実行する。そして、ＹｏｕｎｇＧＣフラグがセットされているかを確認する（ステップＳ１５０１）。フラグがセットされていれば、ステップＳ６０４と同様にＧＣ成功とする。フラグがセットされていなければ、ステップＳ６０５と同様に空きメモリがあるかを確認する。
【００７１】
空きメモリがあれば、ステップＳ６０４と同様にＧＣ成功とする。空きメモリがなければ、ステップＳ６０２と同様にＦｕｌｌＧＣを実行する。そしてステップＳ６０６と同様に空きメモリがあるかを確認し、空きメモリがなければステップＳ６０３と同様にＧＣ失敗とする。空きメモリがあれば、ステップＳ６０４と同様にＧＣ成功とする。
【００７２】
以上、ソケット数が上限に達したときのＧＣにおいてＹｏｕｎｇＧＣのみを実行して機器の応答性の低下を防ぐ方法について、実施形態４として説明した。クローズ漏れしたソケットのクローズが必要なときに、ＦｕｌｌＧＣが実行されないようにすることで、機器の応答性の低下を抑えることができる。
【００７３】
＜その他の実施形態＞
以上、実施形態例を詳述したが、本発明は例えば、システム、装置、方法、プログラム若しくは記録媒体（記憶媒体）等としての実施態様をとることが可能である。具体的には、複数の機器（例えば、ホストコンピュータ、インタフェース機器、撮像装置、ｗｅｂアプリケーション等）から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【００７４】
また本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【００７５】
１０１  情報処理装置、２０３  アプリケーション、４０１  GC管理部、４０２  ソケット管理部、４０３  ソケット取得部、４０４  ソケット解放部
【図１】
2018206026.tif 000003
【図２】
2018206026.tif 000004
【図３】
2018206026.tif 000005
【図４】
2018206026.tif 000006
【図５】
2018206026.tif 000007
【図６】
2018206026.tif 000008
【図７】
2018206026.tif 000009
【図８】
2018206026.tif 000010
【図９】
2018206026.tif 000011
【図１０】
2018206026.tif 000012
【図１１】
2018206026.tif 000013
【図１２】
2018206026.tif 000014
【図１３】
2018206026.tif 000015
【図１４】
2018206026.tif 000016
【図１５】
2018206026.tif 000017