JP2011107746A - メモリ管理方法、計算機システム及びプログラム - Google Patents

Abstract

【課題】ガベージコレクションを行う複数のプログラムを従来よりも少ない物理メモリ量で安定して稼動する計算機システムを提供する。
【解決手段】メモリに格納されて演算装置で実行される複数のプログラムがそれぞれ使用する複数のメモリ領域中の不要になった領域をそれぞれ解放するメモリ管理方法であって、演算装置が、メモリ領域の解放の開始を判定する指標を取得し、前記指標と所定の閾値とを比較して、前記指標が前記閾値を超えたときに、前記複数のプログラムのうちのひとつを選択し、前記選択したプログラムが利用する前記メモリ領域の不要になった領域を回収し、前記回収した領域を解放する。
【選択図】図２

Description

本発明は、メモリ管理方法、計算機システム及びプログラムに係り、特に、オブジェクトのガベージコレクション処理に関する。

計算機システムにおいて、プログラムが使用しているメモリ上に確保されているオブジェクトの暗黙的な回収手法としてガベージコレクション(以下、「ＧＣ」という。)が知られている(例えば、非特許文献１)。ＧＣはメモリ上にある各オブジェクトに対して、プログラムから使用される可能性の有無を判定し、使用される可能性がないオブジェクト（以下、「ゴミオブジェクト」という。）を回収してメモリ上の領域を解放する処理である。ＧＣは、Java（TM）仮想マシン（以下、「JavaVM」という。）（Java並びにすべてのJava関連の商標およびロゴは、米国およびその他の国における米国Sun Microsystems, Inc.の商標または登録商標である）等で使用されている。

一般に、メモリ管理にＧＣを用いるプログラムは、メモリ領域中に空き領域がある間は新しいオブジェクトの確保を続けるのみでＧＣ処理は行わず、空き領域がなくなった時点でＧＣ処理を行う。このため、ＧＣを用いるプログラムのメモリ使用率は、ＧＣ実行後が最小であり、その後、時間経過とともに増加し、次回のＧＣの実行直前にピークに達するという特性を持つ。この特性により、ＧＣを用いるプログラムが複数台同時に稼動する場合、同時に必要とされるメモリ量は全てのプログラムのＧＣ処理実行のタイミングが同じになる場合に最大となり、逆に、プログラム間でＧＣ実行タイミングがずれるほど小さくなる傾向にある。

また、近年、ハイパーバイザーと呼ばれるソフトウェアを用いて、一つの計算機システム上で複数の仮想的な計算機システム（仮想マシン）を動作させる構成が普及し始めている。ハイパーバイザーは、仮想マシン上で稼動しているプログラムに対し、不要になった物理メモリを解放する機能を提供している。ハイパーバイザーは、解放された物理メモリを必要に応じて他の仮想マシンに割り当てることができ、これによりシステム全体としてのメモリ使用効率の向上が実現される(例えば、非特許文献２)。また、従来から広く用いられているオペレーティングシステムも一つの計算機システム上で複数のプログラムを動作させる機能を有しており、上記ハイパーバイザーと同様、実行中のプログラムに対して、不要となった物理メモリを解放する機能を提供している(例えば、非特許文献３)。

なお、本発明はメモリを適用対象とするものであるが、ログ構造ファイルシステム(例えば、非特許文献４)や追記型データベース(例えば、非特許文献５)によるディスク等の記憶装置の使用率も上述のメモリの使用率特性と同様の使用率特性を示すことが知られている。

Garbage Collection: Algorithms for Automatic Dynamic Memory Management(Richard Jones, Rafael Lins, 1996, John Wiley & Sons Inc, ISBN:978-0471941484), p183 Carl A. Waldspurger, Memory resource management in VMware ESX server, ACM SIGOPS Operating Systems Review Volume 36, Issue SI(Winter 2002), p.181-194 詳解Linuxカーネル 第3版 (Daniel P. Bovet, Marco Cesati, 2007, オライリー・ジャパン, ISBN: 978-4873113135), p377 Rosenblum, Mendel and Ousterhout, John K., The LFS Storage Manager, Proceedings of the 1990 Summer Usenix, p.315-324 Philip A. Bernstein, Nathan Goodman, Concurrency Control in Distributed Database Systems, ACM Computing Surveys (CSUR) Volume 13, Issue 2 (June 1981), p.185-221

上記従来例では、複数のプログラムを同時に稼動させる場合、全プログラムで使用するメモリ領域の量の合計に等しい物理メモリを予め用意しておくことが一般的であった。しかし、上記ＧＣの特性により、複数のプログラムがＧＣを用いており且つプログラム間でＧＣ実行タイミングが常にずれている場合は、プログラム間で不要な物理メモリを融通し合うことで性能的な劣化を伴わずに合計の物理メモリ使用量を削減することが可能である。これは、プログラムを実行するために予め用意する必要がある物理メモリ量が従来よりも少なくてすむということを意味する。

しかし、逆に、プログラム間でＧＣ実行タイミングがずれていない場合には、不要物理メモリの融通の有無によらず、従来と同量の物理メモリが必要となる。上記従来技術では複数プログラム間でのＧＣ実行タイミングを制御できなかったため、ＧＣタイミングがずれることを想定して用意する物理メモリ量を削減した場合、ＧＣタイミングが重なってしまった際にメモリ不足に陥り、著しく性能が劣化する恐れがあった。

また、ＧＣタイミングが重なった際には、上記問題に加えて、複数プログラムがＧＣ処理実行のために計算処理を停止してしまうため、応答性が低下するという問題もあった。

本発明は、上記のような課題に鑑みてなされたものであり、ＧＣを用いる複数プログラム間でＧＣ実行のタイミングを制御し、従来よりも少ない物理メモリ量で安定して稼動する計算機システムを提供することにある。

本発明は、複数プログラム合計でのメモリ使用量に関連したある指標が予め指定された閾値を越えた際に、複数のプログラムのうちのひとつでガベージコレクション処理を実行し、ガベージコレクションの後に不要となった物理メモリを解放する。

したがって、本発明によると、ガベージコレクションを用いる複数プログラムの間でＧＣ実行のタイミングを制御することで、従来よりも少ないメモリ量で安定してプログラムを稼動させることが可能である。また、ＧＣ実行のタイミングを制御することにより、複数プログラムが同時に計算処理を停止することを排除し、安定した応答性を確保することが可能である。

本発明の第１の実施形態を示し、計算機システムの構成を示すブロック図である。 本発明の第１の実施形態を示し、ＧＣ処理制御の動作概要を示す説明図である。 本発明の第１の実施形態を示し、制御情報管理テーブルの一例の説明図である。 本発明の第１の実施形態を示し、メモリ量管理テーブルの一例の説明図である。 本発明の第１の実施形態を示し、ヒープ使用量問い合わせ処理のフローチャートである。 本発明の第１の実施形態を示し、ＧＣ実行契機判定処理のフローチャートである。 本発明の第１の実施形態を示し、ＧＣを実行するJavaVMの選択処理のフローチャートである。 本発明の第１の実施形態を示し、回収処理のフローチャートである。 従来例を示し、ＧＣ実行タイミングが同一の場合のヒープ使用量とヒープ容量との関係を示すグラフである。 従来例を示し、ＧＣ実行タイミングが同一の場合のヒープ使用量とメモリ上に確保する物理的な合計容量との関係を示すグラフである。 本発明の第１の実施形態を示し、ＧＣ実行タイミングのずれによるヒープ使用量とヒープ容量との関係を示すグラフである。 本発明の第１の実施形態を示し、ＧＣ実行タイミングのずれによるヒープ使用量とメモリ上に確保する物理的な合計容量との関係を示すグラフである。 本発明の第２の実施形態を示し、制御情報管理テーブルの一例の説明図である。 本発明の第２の実施形態を示し、回収処理指示対象のＪａｖａＶＭの選択処理のフローチャートである。 本発明の第３の実施形態を示し、計算機システムの構成ブロック図である。 本発明の第３の実施形態を示し、ＧＣ処理制御の動作概要を示す説明図である。 本発明の第３の実施形態を示し、制御情報管理テーブルの一例の説明図である。 本発明の第３の実施形態を示し、処理リクエスト数管理テーブルの一例の説明図である。 本発明の第３の実施形態を示し、振分け情報管理テーブルの一例の説明図である。 本発明の第４の実施形態を示し、計算機システムの構成ブロック図である。 本発明の第４の実施形態を示し、回収処理のフローチャートである。 本発明の第５の実施形態を示し、計算機システムの構成ブロック図である。 本発明の第５の実施形態を示し、ＧＣ処理制御の動作概要を示す説明図である。 本発明の第６の実施形態を示し、計算機システムの構成ブロック図である。 本発明の第６の実施形態を示し、閾値算出処理の計算方法の概要を示す説明図である。 本発明の第６の実施形態を示し、閾値算出処理のフローチャートである。 本発明の第６の実施形態を示し、制御情報管理テーブルの一例の説明図である。 本発明の第６の実施形態を示し、メモリ量管理テーブルの一例の説明図である。 本発明の第６の実施形態を示し、ＧＣ処理制御の動作概要を示す説明図である。 本発明の第７の実施形態を示し、回収処理指示対象のＪａｖａＶＭの選択処理のフローチャートである。

以下、本発明の実施の形態について、図面を用いて詳細に説明する。なお、以下の実施形態においては、ガベージコレクションを用いるプログラムとしてＪａｖａＶＭを用いる例を示す。

＜第１実施形態＞
まず、ＧＣ実行の契機判定をＪａｖａＶＭの外部の管理プログラムが行い、契機判定の指標として複数のプログラムがそれぞれ使用するヒープ領域での合計メモリ使用量を用い、ＧＣ実行指示を通知する対象として、ＧＣ実行の契機に到達した時点で次回ＧＣ実行契機が最も近いＪａｖａＶＭを選択する場合の実施の形態について説明する。

図１は、本実施形態の計算機の構成ブロック図である。図１に示す様に、本実施形態の計算機１００は、ＣＰＵ１８１とメモリ１８２と入出力装置１８３とを備える。なお、入出力装置１８３は、ディスク装置やマウス、キーボード、ディスプレイ等を含み、図示のＪａｖａプログラム１１３は記憶媒体としてのディスク装置に格納される。

メモリ１８２上にはハイパーバイザー１７０が格納される。ハイパーバイザー１７０は、ＣＰＵ１８１により実行されることで、メモリ１８２上に複数の仮想マシン１１０（１１０Ａ、１１０Ｂ及び１１０Ｃ以下同様。）を構成する。ハイパーバイザー１７０は、仮想マシン１１０に対するＣＰＵ１８１、メモリ１８２および入出力装置１８３の割り当てを制御する。割り当ての設定は予め管理者等によりなされる。仮想マシン１１０は、割り当てられたＣＰＵ１８１、メモリ１８２および入出力装置１８３により、物理計算機システムのエミュレーションを行う。なお、物理的な計算機資源を仮想化して仮想マシンを生成する仮想化機能については、ハイパーバイザー１７０に代わって、ホストＯＳ上に仮想マシン１１０を生成することで実現しても良い。

ハイパーバイザー１７０は、物理メモリマッピング制御部１７１を含む。物理メモリマッピング制御部１７１は、ハイパーバイザー１７０が管理する仮想マシン１１０上で稼動するプログラム（JavaＶＭ１１１（１１１Ａ及び１１１Ｂ、以下同様。））が使用可能なメモリ１８２の量を制御する処理部である。仮想マシン１１０上のプログラムは、物理メモリマッピング制御部１７１に対して、自分が稼動している仮想マシン１１０に対する新たなメモリの割り当てあるいは既に割り当てられたメモリの解放を要求することが可能である。

仮想マシン１１０Ａ及び１１０Ｂ上では、オペレーティングシステム１６０（１６０Ａ及び１６０Ｂ、以下同様。）とＪａｖａＶＭ１１１が稼動する。ＪａｖａＶＭ１１１は、ＪａｖａＶＭ識別子１１６（１１６Ａ及び１１６Ｂ、以下同様。）、ヒープ領域１１２（１１２Ａ及び１１２Ｂ、以下同様。）、参照ルート１１４（１１４Ａ及び１１４Ｂ、以下同様。）、Ｊａｖａプログラム実行部１１５（１１５Ａ及び１１５Ｂ、以下同様。）、ＧＣ処理部１２０（１２０Ａ及び１２０Ｂ、以下同様。）および回収タイミング制御部１３０（１３０Ａ及び１３０Ｂ、以下同様。）から構成される。

ＪａｖａＶＭ識別子１１６は、計算機１００内の各ＪａｖａＶＭ１１１間で一意な値を識別子として保持する。ＪａｖａＶＭ識別子１１６の値は予め管理者等により設定される。ＪａｖａＶＭ１１１上では、入出力装置１８３からメモリ１８２に読み込まれたＪａｖａプログラム１１３がＪａｖａプログラム実行部１１５により実行される。なお、ＪａｖａＶＭ１１１Ａと１１１Ｂは、異なるＪａｖａプログラムをそれぞれ実行しても良い。

Ｊａｖａプログラム実行部１１５は、Ｊａｖａプログラム１１３の処理実行中に必要となったオブジェクトを、ヒープ領域１１２中に確保する。また、Ｊａｖａプログラム実行部１１５は、参照ルート１１４にヒープ領域１１２中のオブジェクトへの参照を格納し、当該オブジェクトへの操作を行う。ヒープ領域１１２に空き領域がなくなった場合、ＪａｖａＶＭ１１１はＧＣ処理部１２０を呼び出し、ＧＣ処理部１２０がヒープ領域１１２中のゴミオブジェクト（不要なオブジェクト）を回収する。

ＧＣ処理部１２０によるＧＣ処理は、参照ルート１１４から開始してヒープ領域１１２上のオブジェクトの参照関係を辿り、最後の参照先まで到達できなかったオブジェクトをゴミオブジェクトと判定して回収する。この回収はゴミオブジェクトが占有していたヒープ領域１１２を解放し、新たなオブジェクトを格納可能にする処理である。回収タイミング制御部１３０は、メモリ量送信部１３１と回収指示通知受信部１３２から構成される。

メモリ量送信部１３１は、現在のヒープ領域１１２の使用量を送信する処理部である。回収指示通知受信部１３２は、ＧＣ実行指示を受け付け、ヒープ領域１１２に対する回収処理を行う処理部である。

なお、ＪａｖａＶＭ１１１が稼動する仮想マシン１１０（１１０Ａ、１１０Ｂ）の数は必ずしも図示のように２つである必要はなく、多数の仮想マシンが存在してＪａｖａＶＭ１１１を稼動させても良い。

仮想マシン１１０Ｃ上では、オペレーティングシステム１６０Ｃ及び回収管理プログラム１４０が稼動する。回収管理プログラム１４０は各ＪａｖａＶＭ１１１のＧＣ実行タイミングを制御するプログラムであり、制御情報管理テーブル１４４、メモリ量管理テーブル１４２、メモリ量監視部１４７、ＧＣ実行ＪａｖａＶＭ選択部１４５及び回収指示通知送信部１４６から構成される。回収管理プログラム１４０は、メモリ量監視部１４７を用いて各ＪａｖａＶＭ１１１のメモリ量を問い合わせ、合計メモリ使用量が閾値を越えた場合、ＧＣ実行ＪａｖａＶＭ選択部１４５を用いてＧＣを実行させるＪａｖａＶＭ１１１を選択し、回収指示通知送信部１４６を用いて選択したＪａｖａＶＭ１１１にＧＣ実行指示を通知する。制御情報管理テーブル１４４は上記閾値を格納するテーブルである。メモリ量管理テーブル１４２は上記問い合わせ結果を格納するテーブルである。

なお、回収管理プログラム１４０は、必ずしもＪａｖａＶＭ１１１と同一の物理マシン上で稼動する必要はなく、異なる物理マシン上で稼動していてもよい。

上記ＪａｖａＶＭ１１１及び回収管理プログラム１４０は記憶媒体としてのディスク装置（入出力装置１８３）に格納されており、ＣＰＵ１８１がメモリ１８２にロードして実行する。

図２は、第１実施形態におけるＧＣ処理制御の概要を示す図である。回収管理プログラム１４０は、定期的（予め設定した周期など）に図２の処理を実行する。

まず、回収管理プログラム１４０は、メモリ量監視部１４７を用いて定期的（予め設定した周期など）にメモリ量送信部１３１に対して問い合わせを行う（S３３１）。メモリ量送信部１３１は上記問い合わせに対して現在のヒープ領域１１２の使用量であるヒープ使用量、ヒープ容量及びＪａｖａＶＭ１１１の識別子を応答する（Ｓ３２１）。

メモリ量送信部１３１からの応答結果は、メモリ量監視部１４７によりメモリ量管理テーブル１４２に格納される。メモリ量監視部１４７は、上記問い合わせ結果よりＧＣ実行の必要性があると判定した場合、回収管理プログラム１４０が管理するＧＣ実行フラグを有効な状態に設定する（S３３２）。回収管理プログラム１４０は計算機１００に対してひとつのＧＣ実行フラグを管理する。

回収管理プログラム１４０は、ＧＣ実行フラグの設定が有効または無効の何れであるかを判定する（Ｓ３３３）。この判定でＧＣ実行フラグが有効な状態である場合は、ＧＣ実行ＪａｖａＶＭ選択部１４５を用いてＪａｖａＶＭ１１１中のひとつを選択する（Ｓ３３６）。

次に、回収管理プログラム１４０は、回収指示通知送信部１４６を用いて選択したＪａｖａＶＭ中の回収指示通知受信部１３２に対してＧＣ実行指示を送信する（Ｓ３３７）。選択したＪａｖａＶＭでは、指示を受けた回収指示通知受信部１３２が、ヒープ領域１１２の回収処理を行い、物理メモリを解放する（Ｓ３２２）。

なお、上記Ｓ３３１のステップは、必ずしも回収管理プログラム１４０から全ＪａｖａＶＭ１１１に問い合わせを行う必要はなく、代わりに全ＪａｖａＶＭ１１１が定期的（所定の周期）に回収管理プログラム１４０にヒープ使用量とＪａｖａＶＭ１１１の識別子（ＪＶＭ識別子２２１）を報告することにしてもよい。
図３は、第１実施形態の制御情報管理テーブル１４４のデータ形式の一例を示す図である。制御情報管理テーブル１４４は、仮想マシン１１０Ｃの回収管理プログラム１４０によりメモリ１８２に設定されて、制御情報種別フィールド２１１と制御情報値フィールド２１２から構成される。制御情報種別フィールド２１１は、設定される制御情報の種別を格納する。制御情報値フィールド２１２は、その制御情報値を格納する。第１実施形態では、制御情報管理テーブル１４４に格納されるデータは、閾値メモリ使用量と閾値算出用サンプル数である。閾値メモリ使用量情報は、ひとつの計算機１００内の全ＪａｖａＶＭ１１１合計でのヒープ使用量の閾値を示す。閾値算出用サンプル数情報は、ＧＣ契機判定時に使用する過去のヒープ使用量増分情報の最大個数（Ｎ個）を示す。制御情報管理テーブル１４４中の値は、予め管理者等により設定される。

図４は、第１実施形態１のメモリ量管理テーブル１４２のデータ形式の一例を示す図である。メモリ量管理テーブル１４２は、ＪａｖａＶＭ識別子フィールド２２１、ヒープ容量フィールド２２２及びヒープ使用量フィールド２２３、ヒープ使用量増分フィールド２２４から構成される。

ＪａｖａＶＭ識別子フィールド２２１は、メモリ量管理テーブル１４２中の各データ列に対応するＪａｖａＶＭ１１１のＪａｖａＶＭ識別子１１６を格納する。ヒープ容量フィールド２２２は、該当するＪａｖａＶＭ１１１中のヒープ領域１１２の容量を格納する。ヒープ領域１１２の容量は、ＪａｖａＶＭ１１１がメモリ１８２上に確保したメモリ領域の値である。

ヒープ使用量フィールド２２３は、該当するＪａｖａＶＭ１１１中のヒープ領域１１２の使用量（ヒープ使用量）を格納する。即ちヒープ使用量は、Ｊａｖａプログラム実行部１１５がＪａｖａプログラム１１３を実行してヒープ領域１１２に書き込んだオブジェクトが占有するメモリ領域が、ヒープ領域１１２の使用量である。このヒープ使用量は、ＪａｖａＶＭ１１１がメモリ１８２上に確保したヒープ領域１１２のうち、実際にオブジェクトを格納している領域を示す値である。

ヒープ使用量増分フィールド２２４は、過去最大Ｎ回のヒープ使用量問い合わせ時における、該当するＪａｖａＶＭ１１１中のヒープ領域１１２の使用量の増分を格納する。上記増分は、ヒープ使用量問い合わせ処理終了後のヒープ使用量フィールド２２３の新しい値と、ヒープ使用量問い合わせ処理開始時におけるヒープ使用量フィールド２２３の古い値の差を計算することで算出される。なお、上記のＮは、制御情報管理テーブル１４４の閾値算出用サンプル数に格納されている数値である。

メモリ量管理テーブル１４２中の各列の作成及びＪａｖａＶＭ識別子フィールド２２１並びにヒープ容量フィールド２２２の設定は、予め管理者等によりなされる。また、各列のヒープ使用量フィールド２２３は予め０に初期化される。ヒープ使用量増分フィールド２２４は、管理プログラム１４０の起動時に、管理プログラム１４０により空のリストに初期化される。

次に、図２の処理中で、特に、第１の実施形態で特徴的な処理であるＳ３３１、Ｓ３３２、Ｓ３３６、Ｓ３２１について、フローチャートを用いて説明する。

まず、仮想マシン１１０Ｃの回収管理プログラム１４０のメモリ量監視部１４７によるヒープ使用量の問い合わせ処理Ｓ３３１について、詳細を図５のフローチャートを用いて説明する。

図５において、メモリ量監視部１４７は、メモリ量管理テーブル１４２に登録されている全ＪａｖａＶＭ１１１のメモリ量送信部１３１に対して、現在のヒープ使用量を問い合わせる。各ＪａｖａＶＭ１１１のメモリ量送信部１３１は、回収管理プログラム１４０のメモリ量監視部１４７からの問い合わせに対して、ヒープ使用量を取得し、回収管理プログラム１４０を実行する仮想マシン１１０Ｃにヒープ使用量とＪａｖａＶＭ１１１の識別子を応答する。

回収管理プログラム１４０のメモリ量監視部１４７は、前記メモリ量送信部１３１から問い合わせ結果を受信した後に、問い合わせ先のＪａｖａＶＭ１１１の識別子に対応するメモリ量管理テーブル１４２中のヒープ使用量フィールド２２３を問い合わせ結果で更新する。また、対応するメモリ量管理テーブル１４２中のヒープ使用量増分フィールド２２４に、ヒープ使用量フィールド２２３の増分を追加する。なお、ヒープ使用量フィールド２２３の増分は、更新後のヒープ使用量フィールド２２３―更新前のヒープ使用量フィールド２２３とする。また、データの追加によりヒープ使用量増分フィールド２２４のリストの要素数が閾値算出用サンプル数を超える場合は、閾値算出用サンプル数と同数になるまで、古い要素から順にデータをリストから削除してもよい（Ｓ３６１、Ｓ３６２）。

次に、回収管理プログラム１４０によるＧＣ実行契機判定処理Ｓ３３２の詳細を図６のフローチャートを用いて説明する。

図６において、回収管理プログラム１４０は、メモリ量管理テーブル１４２の全てのヒープ使用量２２３の合計を求め、この合計（ヒープ使用量合計値）が、制御情報管理テーブル１４４の閾値メモリ使用量の値以上になったか否かを判定する。ヒープ使用量合計値が閾値（閾値メモリ使用量）以上である場合にＧＣ実行フラグを有効な状態（例えば、「１」。）に設定し、逆にヒープ使用量合計値が閾値（閾値メモリ使用量）未満である場合はＧＣ開始フラグを無効な状態（例えば、「０」。）に設定する。

まず、回収管理プログラム１４０は、ＧＣ開始フラグを無効な状態に設定する（Ｓ３７１）。

次に、回収管理プログラム１４０は、現在のヒープ使用量合計値と閾値（閾値メモリ使用量）との比較を行う。より詳細には、回収管理プログラム１４０は、メモリ量管理テーブル１４２中の全ＪａｖａＶＭ１１１分のヒープ使用量フィールド２２３の合計値を算出することによりヒープ使用量合計値を取得し（Ｓ３７２）、次いで、制御情報管理テーブル１４４から閾値（閾値メモリ使用量）を取得し（Ｓ３７３）、その後、取得した現在のヒープ使用量合計値と閾値との比較を行う（Ｓ３７４）。

ヒープ使用量合計値が閾値以上である場合（Ｓ３７４：Ｙｅｓ）、回収管理プログラム１４０は、ＧＣ開始フラグを有効な状態に設定し（Ｓ３７５）、図６のＧＣ実行契機判定処理を終了する。

逆に、ヒープ使用量合計値が閾値未満である場合（Ｓ３７４：Ｎｏ）、回収管理プログラム１４０は、図６のＧＣ実行契機判定処理を終了する。

次に、図７に示すＧＣ実行ＪａｖａＶＭ選択部１４５によるＧＣを実行するＪａｖａＶＭの選択処理Ｓ３３６について、説明する。この処理は、ＧＣ実行ＪａｖａＶＭ選択部１４５が、メモリ量管理テーブル１４２に登録されている全ＪａｖａＶＭ１１１中で最も次回のＧＣ実行契機が近いＪａｖａＶＭ１１１を選択する処理である。本処理を、以下に詳細に説明する。

まず、ＧＣ実行ＪａｖａＶＭ選択部１４５は、メモリ量管理テーブル１４２の先頭のエントリのＪａｖａＶＭ１１１のＪａｖａＶＭ識別子２２１を変数Ｘに格納する（Ｓ３４１）。

次に、ＧＣ実行ＪａｖａＶＭ選択部１４５は、Ｘに対応するヒープ使用量増分２２４に含まれる値の平均値をヒープ使用量増分平均値Ｘ３として求める（Ｓ３４２）。

次に、ＧＣ実行ＪａｖａＶＭ選択部１４５は、メモリ量管理テーブル１４２の中に未調査のＪＶＭがあるかを判断し（Ｓ３４３）、ある場合（Ｓ３４３：Ｙｅｓ）には、Ｓ３４４の処理に進み、無い場合（Ｓ３４３：Ｎｏ）には、Ｓ３４８の処理に進む。

次に、ＧＣ実行ＪａｖａＶＭ選択部１４５は、メモリ量管理テーブル１４２上の次のエントリのＪａｖａＶＭ識別子２２１を変数Ｙに格納する（Ｓ３４４）。

次に、ＧＣ実行ＪａｖａＶＭ選択部１４５は、Ｙに対応するヒープ使用量増分２２４に含まれる値の平均値をヒープ使用量増分平均値Ｙ３として求める（Ｓ３４５）。

次に、ＧＣ実行ＪａｖａＶＭ選択部１４５は、ヒープ使用量増分平均値Ｘ３及びＹ３に格納しているＪａｖａＶＭ１１１同士の次回ＧＣ実行契機を比較する（Ｓ３４６）。この判定では、ＧＣ実行ＪａｖａＶＭ選択部１４５は、以下の式（１）及び式（２）を計算する。

（Ｘのヒープ容量２２２−Ｘのヒープ使用量２２３） /
ヒープ使用量増分平均値Ｘ３ ・・・（１）
（Ｙのヒープ容量２２２−Ｙのヒープ使用量２２３） /
ヒープ使用量増分平均値Ｙ３ ・・・（２）
式（１）の値が式（２）の値より大きい場合（Ｓ３４６：Ｙｅｓ）には、Ｓ３４７の処理に進む、即ちＧＣ実行ＪａｖａＶＭ選択部１４５は、変数Ｘの値をＹに更新し、変数Ｘ３の値をＹ３に更新する（Ｓ３４７）。なお、式（１）の値が式（２）の値以下の場合（Ｓ３４６：Ｎｏ）、Ｓ３４３の処理に戻り、メモリ量管理テーブル１４２に未処理の要素（エントリ）がなくなるまで、上記Ｓ３４３〜Ｓ３４７の処理を繰り返す。

最後に、ＧＣ実行ＪａｖａＶＭ選択部１４５は、変数Ｘに格納されているＪａｖａＶＭ１１１を選択対象に指定し（Ｓ３４８）、処理を終了する。

上記処理により、メモリ量管理テーブル１４２の先頭のエントリから順に次回ＧＣ実行契機を比較して、最も次回ＧＣ実行契機が近いＪａｖａＶＭ１１１の識別子２２１を決定することができる。

次に、回収指示通知受信部１３２による回収処理Ｓ３２２の処理の詳細を図８のフローチャートを用いて説明する。

まず、回収管理プログラム１４０からヒープ領域１１２内のゴミオブジェクトの回収を指示されたＪａｖａＶＭ１１１の識別子２２１の回収指示通知受信部１３２は、ＧＣ処理部１２０を呼び出し、ヒープ領域１１２に対するＧＣ処理を実行する（Ｓ３５１）。このＧＣ処理は、上述したように参照ルート１１４から開始してヒープ領域１１２上のオブジェクトの参照関係を辿り、最後の参照先まで到達できなかったオブジェクトをゴミオブジェクトと判定する。そして、ゴミオブジェクトが占有していたヒープ領域１１２を解放する。

続いて、回収指示通知受信部１３２は、上記Ｓ３５１で解放したヒープ領域１１２に対応するメモリ１８２（物理メモリ）を解放するため、ハイパーバイザ１７０の物理メモリマッピング制御部１７１に対して、上記ＧＣ処理で不要になった物理メモリに対して解放要求を行う（Ｓ３５２）。回収指示通知受信部１３２から解放要求を受信したハイパーバイザ１７０の物理メモリマッピング制御部１７１は、ＧＣ処理部１２０が解放したヒープ領域１１２に対応するメモリ１８２を解放し、他の仮想マシンやＯＳなどに当該記憶領域を提供することができる。

以上により、第１実施形態の計算機１００では、ＪａｖａＶＭ１１１は監視プログラム１４０を実行する仮想マシン１１０からのＧＣ実行指示を受けた際にのみＧＣ処理部１２０がＧＣ処理を行い、また監視プログラム１４０は一回のＧＣ実行契機につき１つのＪａｖａＶＭ１１１（または仮想マシン１１０）にしか指示を出さないため、前記従来例のように複数のＪａｖａＶＭ１１１が同時にＧＣ処理を実行することはない。このため、複数ＪａｖａＶＭ１１１間でＧＣ実行のタイミングは常にずれることとなり、従来よりも少ないメモリ量で安定して稼動させることが可能である。

即ち前記従来例で述べたように、複数のヒープ領域１１２で同時にＧＣ処理を行った場合は、図９Ａ、図９Ｂで示すように、メモリ１８２を実際に使用する容量は、複数のヒープ領域１１２の合計値と一致するため、各ヒープ領域１１２が確保した記憶領域をメモリ１８２に確保する必要がある。図９Ａ、図９Ｂは、５つのプログラム（Ｊａｖａプログラム１１３）がそれぞれヒープ領域を確保して時刻ｔ０から実行を開始し、時刻ｔ１でＧＣ処理を同時に開始する例を示している。なお、図９Ａ、図９Ｂの例では、計算機１００で５つのＪａｖａＶＭ（図中プログラム１〜５）が稼動している例を示す。各ＪａｖａＶＭはヒープ領域１１２の容量としてＭ１〜Ｍ５の容量をメモリ１８２に確保している。これら各ＪａｖａＶＭのヒープ領域１１２の容量Ｍ１〜Ｍ５の合計は、図９Ｂで示すように合計容量Ｍａとなる。

したがって、従来例では時刻ｔ０からは各Ｊａｖａプログラム実行部１１５が、それぞれのヒープ領域１１２にオブジェクトを徐々に書き込むためヒープ使用量は徐々に増大し、時刻ｔ１ではヒープ領域１１２の空き領域が無くなるためヒープ使用量はヒープ容量Ｍ１〜Ｍ５にそれぞれ等しくなる。この時刻ｔ１では、各ヒープ領域１１２の空き領域がなくなるため、メモリ１８２上に確保する物理的なメモリ領域の容量はヒープ容量Ｍ１〜Ｍ５の和である合計容量Ｍａが必須となる。

一方、第１実施形態では、ヒープ使用量とヒープ容量の関係が図１０Ａ、図１０Ｂで示すようになる。図１０Ａは、図９Ａと同様に、計算機１００で５つのＪａｖａＶＭ（図中プログラム１〜５）が稼動している例を示し、各ＪａｖａＶＭはヒープ領域１１２の容量としてＭ１〜Ｍ５の容量をメモリ１８２に確保している。これら各ＪａｖａＶＭのヒープ領域１１２の容量Ｍ１〜Ｍ５の合計は、図１０Ｂで示すように図９Ａと同様の合計容量Ｍａとなる。

第１実施形態では、時刻ｔ０でプログラム５のＧＣ処理が行われ、その後、時刻ｔ１でプログラム４のＧＣ処理が行われ、時刻ｔ２でプログラム３のＧＣ処理が行われ、時刻ｔ３でプログラム２のＧＣ処理が行われ、時刻ｔ４でプログラム１のＧＣ処理が行われ、各ＪａｖａＶＭのＧＣ処理のタイミングは異なっている。各プログラムはＧＣ処理後に、各Ｊａｖａプログラム実行部１１５が、それぞれのヒープ領域１１２にオブジェクトを徐々に書き込むためヒープ使用量は徐々に増大する。そして、各プログラムのＧＣ処理が行われる時刻で、各プログラムが使用するヒープ使用量の和が最大となるメモリ使用量ピークとなる。

各プログラムで使用するヒープ領域１１２の和と、実際に使用されたヒープ使用量の和の関係は、図１０Ｂのようになる。各プログラム（ＪａｖａＶＭ）でＧＣ処理を開始する時点で、ヒープ使用量の和は最大値であるＭｂとなる。そして、各プログラムでＧＣ処理が完了した後は、前記従来例の図９Ｂのようにヒープ領域１１２の全てが空き領域となることなくオブジェクトの増加につれてヒープ使用量の和も増大する。各プログラムのＧＣ処理の開始時期を異なる時刻にすることで、メモリ１８２を実際に使用するヒープ使用量の和の最大値Ｍｂは、各プログラムのヒープ領域１１２の和である合計容量Ｍａよりも小さな値となる。

したがって、本発明では、計算機１００のメモリ１８２に確保するヒープ領域１１２用の領域は、図１０Ｂのヒープ使用量の和の最大値Ｍｂを確保することで、各プログラムを実行することができる。即ちハイパーバイザ１７０の物理メモリマッピング制御部１７１は、ＪａｖａＶＭ１１１を実行する各仮想マシン１１０のヒープ領域１１２用のメモリ量として、図１０Ｂに示すヒープ領域１１２の和である合計容量Ｍａを仮想記憶領域で割り当て、メモリ１８２上には実際に使用するヒープ使用量の和の最大値Ｍｂの物理アドレスを割り当てる。

以上のように、第１実施形態によれば前記従来例よりもメモリ１８２の容量を削減して複数のＪａｖａＶＭ１１１を実行することができ、計算機１００のリソースを効率よく利用することができる。

また、第１実施形態によれば、複数のＪａｖａＶＭ１１１のうちのひとつのみにＧＣ処理の開始を指令するため、ＧＣ処理を実行するタイミングはＪａｖａＶＭ１１１毎に異なることになって、複数のＪａｖａプログラム１１３が同時に計算処理を停止することを排除し、安定した応答性を確保することができる。さらに、ＧＣ処理の開始を判定する指標として、ヒープ使用割合を用いるようにしたため、適切な時期にＧＣ処理を行うことができる。

＜第２実施形態＞
次に、図１１、図１２に本発明の第２の実施形態を示す。第２実施形態は、第１実施形態と同じ契機判定処理を行うが、ＧＣ実行指示を通知する対象は各ＪａｖａＶＭ１１１を順繰りに選択するもので、その他の構成は第１実施形態と同様である。なお、本第２実施形態では順繰りにＪａｖａＶＭ１１１を選択する手法としてラウンドロビンを用いる例を示すが、選択手法はラウンドロビン方式に限定されるものではない。

第１実施形態の図７で示した「ＧＣ実行指示を通知する対象として契機に到達した時点で次回ＧＣ実行契機に最も近いＪａｖａＶＭ」という選択処理は、次回ＧＣ実行契機に最も近いＪａｖａＶＭのヒープ領域１１２のほとんどがゴミオブジェクトで占められている場合に、特に、有効な手法である。

他方、第１の実施形態では、対象のＪａｖａＶＭ１１１のヒープ領域１１２中に不要領域がほとんどない場合には、回収処理を実行しても当該ＪａｖａＶＭ１１１のヒープ使用量は回収処理前と比べてほとんど減少しない。このため、当該ＪａｖａＶＭ１１１はその後繰り返しＧＣ指示対象に選ばれ続けることになる。

この間、他のＪａｖａＶＭ１１１のヒープ使用量も徐々にピークに近づいてゆくため、結果として、当該ＪａｖａＶＭ１１１と他のＪａｖａＶＭ１１１のヒープ使用量のピーク時を十分にずらすことができず、合計ヒープ使用量が閾値（閾値メモリ使用量）を上回る虞がある。

そこで、第２実施形態は指示対象となるＪａｖａＶＭ１１１を順繰りに選択した場合に、同一のＪａｖａＶＭが、繰り返し回収処理対象として選ばれる事態を防止することを特徴の１つとするものである。

以上の処理は、第１実施形態の制御情報管理テーブル１４４に格納するデータを後述するように変更し、第１実施形態の図２に示したＧＣ処理を実行するＪａｖａＶＭ１１１の選択処理Ｓ３３６ステップを変更することで実現される。

本第２実施形態における計算機１００の構成およびＧＣ処理の概要は、それぞれ第１実施形態の図１および図２と同様であるため省略する。

以下、第２実施形態と第１実施形態との差分箇所について、詳細に説明する。

図１１は、第２実施形態において制御情報管理テーブル１４４に格納されるデータを示す図である。第２実施形態においては、制御情報管理テーブル１４４は、閾値メモリ使用量と次回ＧＣ対象識別子の情報を含む。閾値メモリ使用量に格納されるデータは、第１実施形態の場合と同じである。次回ＧＣ対象識別子には、次回のＧＣ実行契機でＧＣ指示を出す対象のＪａｖａＶＭの識別子が格納される。次回ＧＣ対象識別子は、管理プログラム１４０の起動時に、管理プログラム１４０によりメモリ量管理テーブル１４２の先頭のＪａｖａＶＭ識別子の値に初期化される。

次に、第２実施形態におけるＧＣを実行するＪａｖａＶＭの選択処理Ｓ３３６について、詳細を図１２のフローチャートを用いて説明する。

ＧＣ実行ＪａｖａＶＭ選択部１４５は、制御情報管理テーブル１４４に格納されている次回ＧＣ対象識別子に基づいて指示対象のＪａｖａＶＭ１１１を選択し、次回ＧＣ対象識別子を、メモリ量管理テーブル１４２上にある次のエントリのＪａｖａＶＭ１１１を指すよう更新する。

まず、ＧＣ実行ＪａｖａＶＭ選択部１４５は、制御情報管理テーブル１４４から次回ＧＣ対象識別子を取得し、変数Ｘに格納する（Ｓ１３４１）。

次に、ＧＣ実行ＪａｖａＶＭ選択部１４５は、メモリ量管理テーブル１４２上でＪａｖａＶＭ識別子２２１が変数Ｘの値に該当する項目を探索する。

まず、ＧＣ実行ＪａｖａＶＭ選択部１４５は、メモリ量管理テーブル１４２の先頭のエントリを変数Ｙに格納する（Ｓ１３４２）。

次に、ＧＣ実行ＪａｖａＶＭ選択部１４５は、ＸとＹのＪａｖａＶＭ識別子２２１を比較する（Ｓ１３４３）。等しい場合（Ｓ１３４３：Ｙｅｓ）には、Ｓ１３４５の処理に進む。異なる場合（Ｓ１３４３：Ｎｏ）には、Ｓ１３４４の処理に進む、即ちＧＣ実行ＪａｖａＶＭ選択部１４５は、メモリ量管理テーブル１４２のＹの次のエントリを変数Ｙに格納し（Ｓ１３４４）、Ｓ１３４３の処理に戻る。

次に、ＧＣ実行ＪａｖａＶＭ選択部１４５は、変数Ｙの値がメモリ量管理テーブル１４２の最後のエントリか否かを判定する（Ｓ１３４５）。

最後のエントリでない場合（Ｓ１３４５：Ｙｅｓ）には、Ｓ１３４６の処理に進む、即ちＧＣ実行ＪａｖａＶＭ選択部１４５は、メモリ量管理テーブル１４２上でＹの次のエントリのＪａｖａＶＭ識別子２２１を変数Ｚに設定する（Ｓ１３４６）。

最後のエントリである場合（Ｓ１３４５：Ｎｏ）には、Ｓ１３４７の処理に進む、即ちＧＣ実行ＪａｖａＶＭ選択部１４５は、メモリ量管理テーブル１４２の先頭のエントリのＪａｖａＶＭ識別子２２１を変数Ｚに設定する（Ｓ１３４７）。

次に、ＧＣ実行ＪａｖａＶＭ選択部１４５は、制御情報管理テーブル１４４中の次回ＧＣ対象識別子を変数Ｚの値に更新し（Ｓ１３４８）、変数Ｘに格納されているＪａｖａＶＭ１１１を選択対象として指定する（Ｓ１３４９）。

以上により、第２実施形態の計算機１００では、ヒープ領域１１２のほとんどが非ゴミオブジェクトで占められているＪａｖａＶＭ１１１がＧＣの指示対象に選ばれた場合でも、ＧＣ処理を実行するＪａｖａＶＭ１１１をラウンドロビンによって順繰り（メモリ量管理テーブル１４２のエントリの順）に選択するため、次回以降のＧＣ契機においては当該ＪａｖａＶＭ１１１以外のＪａｖａＶＭ１１１がＧＣの指示対象となり、当該ＪａｖａＶＭ１１１と他ＪａｖａＶＭ１１１との間でＧＣ実行のタイミングを十分にずらすことが可能である。

このため、ヒープ領域１１２のほとんどが非ゴミオブジェクトで占められているＪａｖａＶＭ１１１が存在した場合でも、同一のＪａｖａＶＭ１１１が連続してＧＣ処理の対象に選択されるのを防ぐことができ、ＧＣ処理を効果的に実行し、少ないメモリ量で複数のＪａｖａプログラム１１３を安定して稼動させることが可能である。

＜第３実施形態＞
次に、図１３〜図１７に本発明の第３の実施形態を示す。第３実施形態では、第１実施形態に示したＧＣ実行契機の判定を、複数プログラムでの合計リクエスト処理数を用いて行う例について説明する。

第１実施形態のように、ＧＣ実行契機の判定にヒープ使用量を用いる場合、契機判定のため各ＪａｖａＶＭ１１１にヒープ使用量の問い合わせを行う必要がある。このため、ＪａｖａＶＭ１１１の内部に問い合わせに応答する処理部がない場合には制御が行えない。また、回収管理プログラム１４０がＪａｖａＶＭ１１１へ頻繁に問い合わせを行う場合では、ＪａｖａＶＭ１１１の処理性能を下げる虞がある。

これに対し、ＪａｖａＶＭ１１１に対するリクエスト処理数は、図１１の負荷分散装置を用いた構成では負荷分散装置に問い合わせを行うことで取得可能である。また、一般的なサーバアプリケーションでは、クライアントからのリクエストに応じて処理を実行するため、サーバのヒープ使用量は処理したリクエスト数に比例すると考えられる。

本実施形態は、契機の判定にヒープ使用量の代わりにリクエスト処理数を用いることで、JavaVMへの問い合わせを行うことなく制御することを可能とするものである。

図１３は、本第３実施形態の計算機２００を中心とした計算機システムの構成を示すブロック図である。第３実施形態の計算機システムでは、計算機２００が、負荷分散装置２０に接続されている。負荷分散装置２０は、ネットワークなどを介して図示しないクライアント計算機に接続され、クライアント計算機からリクエストを受け付け、計算機２００上のＪａｖａＶＭ１１１Ａ及び１１１Ｂに受け付けたリクエストを分配する装置である。

また、負荷分散装置２０は、振分け情報管理テーブル３１３３及び処理リクエスト数送信部３１３１を含む。振分け情報管理テーブル３１３３は、負荷分散装置２０が各ＪａｖａＶＭ１１１に振り分けたクライアント計算機からのリクエストの総和である総リクエスト数を格納するテーブルである。負荷分散装置２０は、各ＪａｖａＶＭ１１１にクライアント計算機からのリクエストを分配するたびに振分け情報管理テーブル３１３３の値を更新する。処理リクエスト数送信部３１３１は、振分け情報管理テーブル３１３３内の情報を送信する処理部である。

また、第３実施形態における計算機２００は、第１実施形態の計算機２００と以下の点で異なる。まず、本第３実施形態では、ＪａｖａＶＭ１１１中の回収タイミング制御部１３０がメモリ量送信部１３１を含まない。次に、回収管理プログラム１４０は、メモリ量管理テーブル１４２とメモリ量監視部１４７の代わりに、処理リクエスト数管理テーブル３１４２と処理リクエスト数監視部３１４７を含む。上記以外の点では、本第３実施形態における計算機２００は第１実施形態の計算機２００と同じである。

なお、図では省略したが、第１実施形態の場合と同じく、ＪａｖａＶＭ１１１ＢはＪａｖａＶＭ１１１Ａと同様の構成要素を含むものとし、特に必要のある場合は各機能部位の名称の末尾に添え字「Ａ」又は「Ｂ」をつけることで区別するものとする。

以下、本実施形態と第１実施形態との差分箇所について、詳細に説明する。

図１５は、第３実施形態において制御情報管理テーブル１４４に格納されるデータを示す図である。本第３実施形態においては、制御情報管理テーブル１４４は第１実施形態におけるデータの代わりに、ＧＣ実行の判定を行うための閾値として閾値リクエスト処理数の情報を含む。閾値リクエスト処理数は、ＧＣ実行後、次回のＧＣ実行までの間に処理される全ＪａｖａＶＭ１１１でのリクエスト数の合計と比較する閾値を格納する。閾値リクエスト処理数情報は、予め管理者等により設定される。

図１６は、本実施形態の処理リクエスト数管理テーブル３１４２のデータ形式の一例を示す図である。処理リクエスト数管理テーブル３１４２は、ＪａｖａＶＭ識別子フィールド３２２１、処理リクエスト数フィールド３２２２、前回ＧＣ処理時処理リクエスト数フィールド３２２３、から構成される。

ＪａｖａＶＭ識別子フィールド３２２１は、本テーブル中の各データ列に対応するＪａｖａＶＭ１１１のＪａｖａＶＭ識別子１１６を格納する。処理リクエスト数フィールド３２２２は、該当するＪａｖａＶＭ１１１が処理したリクエストの総数を格納する。前回ＧＣ処理時処理リクエスト数フィールド３２２３は、全ＪａｖａＶＭ１１１の合計処理リクエスト数が閾値を越えた直近の契機までに、該当するＪａｖａＶＭ１１１が処理したリクエストの総数を格納する。

図１７は、本実施形態の振分け情報管理テーブル３１３３のデータ形式の一例を示す図である。振分け情報管理テーブル３１３３は、ＪａｖａＶＭ識別子フィールド３３２１、処理リクエスト数フィールド３３２２、から構成される。ＪａｖａＶＭ識別子フィールド３３２１は、テーブル中の各データ列に対応するＪａｖａＶＭ１１１のＪａｖａＶＭ識別子１１６を格納する。処理リクエスト数フィールド３３２２は、該当するＪａｖａＶＭ１１１が処理したリクエストの総数を格納する。

図１４は、第３実施形態におけるＧＣ制御処理の概要を示す図である。第１実施形態の場合と同様、回収管理プログラム１４０は、定期的（例えば、所定の周期毎）に図１４の処理を実行する。

まず、回収管理プログラム１４０は、処理リクエスト数監視部３１４７を用いて負荷分散装置２０内の処理リクエスト数送信部３１３１に対して問い合わせを行い（Ｓ３３３１）、処理リクエスト数送信部３１３１は上記問い合わせに対して、振分け情報管理テーブル３１３３に格納しているＪａｖａＶＭ識別子３３２１の処理リクエスト数３３２２を応答する（Ｓ３３２１）。応答結果は、処理リクエスト数監視部３１４７により処理リクエスト数管理テーブル３１４２の処理リクエスト数フィールド３２２２に格納される。

処理リクエスト数監視部３１４７が、応答結果よりＧＣ実行の必要性があると判定した場合（Ｓ３３３２、Ｓ３３３３）、回収管理プログラム１４０はＧＣ実行ＪａｖａＶＭ選択部１４５を用いてＪａｖａＶＭ１１１中のひとつを選択する（Ｓ３３３６）。その後の処理（Ｓ３３７、Ｓ３２２）は、第１実施形態の場合と同様である。

上記Ｓ３３３２のＧＣ契機判定処理は、各ＪａｖａＶＭ１１１が前回ＧＣ契機以降に処理したリクエスト数の合計値を算出し、上記合計値が閾値を超えていた場合、ＧＣ実行契機であると判定する。各ＪａｖａＶＭ１１１が前回ＧＣ契機以降に処理したリクエスト数は、処理リクエスト数管理テーブル３１４２中の対応するＪａｖａＶＭの処理リクエスト数フィールド３２２２の値から前回ＧＣ処理時処理リクエスト数フィールド３２２３の値を引くことで取得可能である。また、上記閾値は、制御情報管理テーブル１４４の閾値メモリ使用量より取得可能である。

また、上記Ｓ３３３６の選択処理では、前回ＧＣ契機以降に処理したリクエスト数が最も多いＪａｖａＶＭ１１１を選択する。この処理は、第１実施形態のＳ３３６ステップと同様の処理を処理リクエスト数管理テーブル３１４２に対して行うことで実行可能である。なお、選択処理が終わった際に、ＧＣ実行ＪａｖａＶＭ選択部１４５は、処理リクエスト数管理テーブル３１４２中の各ＪａｖａＶＭの処理リクエスト数フィールド３２２２の値を前回ＧＣ処理時処理リクエスト数フィールド３２２３にコピーするものとする。
なお、ＧＣを実行するＪａｖａＶＭの選択手法は上記方法に限定されるものではなく、第２実施形態のようにラウンドロビン方式を用いてもよい。

以上により、本実施形態の計算機２００では、ＧＣ実行の契機を負荷分散装置２０から取得した処理リクエスト数情報に基づいて判定することで、ＪａｖａＶＭ１１１への問い合わせを行うことなく制御することが可能である。これにより、第１実施形態と同様に、少ないメモリ量で複数のＪａｖａプログラム１１３を安定して稼動させるのに加え、ＪａｖａＶＭ１１１の負荷を低減することが可能である。なお、用いる指標は、必ずしもリクエスト処理数に限定されるものではなく、他の指標を用いてもよい。

＜第４実施形態＞
次に、図１８、図１９に第４の実施形態を示す。第４実施形態は、一つのオペレーティングシステム上で稼動する複数のＪａｖａＶＭプロセスに対して制御を行う場合の実施の形態について説明する。

本第４実施形態は、第１実施形態のハイパーバイザ１７０の物理メモリマッピング制御部１７１の代わりに、オペレーティングシステム１６０の物理メモリマッピング制御部１６１を用いることで第１実施形態と同様の制御を行うものである。

図１８は、本実施形態の計算機３００の構成ブロック図である。メモリ１８２には、ＪａｖａＶＭ１１１(１１１Ａ及び１１１Ｂ)、回収管理プログラム１４０及びオペレーティングシステム１６０が格納されている。ＪａｖａＶＭ１１１及び回収管理プログラム１４０は、オペレーティングシステム１６０により管理されるプロセスとして稼動する。

オペレーティングシステム１６０は、物理メモリマッピング制御部１６１を含む。物理メモリマッピング制御部１６１は、第１実施形態の物理メモリマッピング制御部１７１と同様、オペレーティングシステム１６０が管理するプロセスが使用可能なメモリ１８２の量を制御する処理部であり、各プロセスは、物理メモリマッピング制御部１６１に対して、新たなメモリの割り当てあるいは既に割り当てられたメモリの解放を要求することが可能である。なお、物理メモリマッピング制御部１６１は、各プロセスに対して仮想記憶空間を割り当て、メモリ１８２の物理的な記憶空間と仮想記憶空間の変換を行うことができる。また、メモリ１８２の物理的な記憶空間と仮想記憶空間の変換は、ＣＰＵ１８１のハードウェアで行うようにしても良い。

第４実施形態におけるＧＣ処理の流れは、第１実施形態における図２と同様であるため省略する。本実施形態と第１実施形態で処理が異なる点は、第１実施形態の図８に示した回収処理Ｓ３２２の内容のみである。

以下、本実施形態と第１実施形態との差分箇所である回収処理Ｓ３２２について、詳細を図１９のフローチャートを用いて説明する。

まず、回収指示通知受信部１３２は、第１実施形態の場合と同様、ＧＣ処理部１２０を呼び出し、ヒープ領域１１２に対するＧＣ処理を実行する（Ｓ３５１）。次に、回収指示通知受信部１３２は、オペレーティングシステム１６０中の物理メモリマッピング制御部１６１に対して、上記ＧＣ処理で不要になった物理メモリに対する解放要求を行う（Ｓ４３５２）。

以上により、本実施形態の計算機３００では、不要物理メモリ解放処理にオペレーティングシステム１６０の物理メモリマッピング制御部１６１を用いることで、ハイパーバイザーが存在しない環境においても、複数のＪａｖａＶＭ１１１をより少ないメモリ量で安定して稼動させることが可能である。

なお、ＧＣ処理を実行するＪａｖａＶＭ１１１の選択手法には、第２実施形態と同様にして、ラウンドロビンを用いてもよい。また同様に、ＧＣ実行契機の判定に、第３実施形態と同様、クライアント計算機からの処理リクエスト数を用いてもよい。

＜第５実施形態＞
次に、図２０、図２１に本発明の第５の実施形態を示す。第５実施形態は、ＧＣ実行契機の判定に管理プログラムを用いず、代わりにＪａｖａＶＭ間の通信によりＧＣ開始の契機を判定する例を示す。

第１実施形態等のように回収管理プログラム１４０を用いる場合、管理プログラム１４０に障害が発生するとＧＣ処理の制御が不可能となるため、可用性が低くなる恐れがある。このため、本第５実施形態では管理プログラム１４０を用いずにＪａｖａＶＭ間の通信のみで契機を判定することにより、上記問題を解決することが可能である。

図２０は、本実施形態の計算機400の構成を示すブロック図である。第１実施形態の構成要素との差異は、メモリ１８２上に仮想マシン１１０Ｃ（及び仮想マシン１１０Ｃに含まれる回収管理プログラム１４０）が存在せず、代わりにＪａｖａＶＭ１１１の回収タイミング制御部１３０内に、制御情報管理テーブル１４４（１４４Ａ及び１４４Ｂ）、メモリ量管理テーブル１４２（１４２Ａ及び１４２Ｂ）、メモリ量監視部１４７（１４７Ａ及び１４７Ｂ）、ＧＣ実行ＪａｖａＶＭ選択部１４５（１４５Ａ及び１４５Ｂ）、を含む点である。上記、制御情報管理テーブル１４４、メモリ量管理テーブル１４２、に格納される値は第１実施形態の場合と同様である。また、上記メモリ量監視部１４７、ＧＣ実行ＪａｖａＶＭ選択部１４５は、第１実施形態と同様の処理を行う。

図２１は、本実施形態におけるＧＣ制御処理の概要を示す図である。ＪａｖａＶＭ１１１は実行中に定期的（所定の周期）に図２１の処理を呼び出す。

なお、図２１及び以下の説明では、ＪａｖａＶＭ１１１Ａの処理のみを説明するが、ＪａｖａＶＭ１１１Ｂも同様の契機で同様の処理を行うものとする。

まず、ＪａｖａＶＭ１１１Ａは、メモリ量管理テーブル１４２Ａ中の自身のヒープ使用量フィールド２２３を、ヒープ領域１１２Ａの現在の使用割合の値に更新し、ヒープ使用量増分フィールド２２４に、ヒープ使用量フィールド２２３の増分を追加する（Ｓ５３３１）。なお、ヒープ使用量フィールド２２３の増分は、第１実施形態と同様であり、更新後のヒープ使用量フィールド２２３―更新前のヒープ使用量フィールド２２３である。

次に、メモリ量監視部１４７Ａを用いて、ＪａｖａＶＭ１１１Ｂ中のメモリ量送信部１３１Ｂに対して問い合わせを行う（Ｓ３３１）。問い合わせを受けたメモリ量送信部１３１Ｂは上記問い合わせに対して現在のヒープ領域１１２Ｂのヒープ使用量を応答する（Ｓ３２１）。メモリ量監視部１４７Ａが、問い合わせの結果よりＧＣ実行の必要性があると判定した場合（Ｓ３３２、Ｓ３３３）、ＪａｖａＶＭ１１１ＡはＧＣ実行ＪａｖａＶＭ選択部１４５Ａを用いて、全ＪａｖａＶＭ１１１中のひとつのプロセスを選択する（Ｓ３３６）。選択されたＪａｖａＶＭ１１１が自身（すなわち、ＪａｖａＶＭ１１１Ａ）でない場合、ＪａｖａＶＭ１１１Ａは図２１の処理を終了する。逆に、選択されたＪａｖａＶＭ１１１が自身である場合、ＪａｖａＶＭ１１１Ａは回収指示通知受信部１３２Ａを用いて回収処理を実行する（Ｓ３２２）。

なお、上記Ｓ３３１、Ｓ３２１、Ｓ３３２、Ｓ３３３、Ｓ３３６、Ｓ３３２の処理は、第１実施形態の場合と同様である。

以上の処理により、本第５実施形態の計算機１００では、ＧＣ実行契機を全ＪａｖａＶＭ１１１同士の通信のみに基づいて判定することができ、これにより第１実施形態の管理プログラム１４０の障害によりヒープ領域１１２が制御不能状態に陥ることなく、より少ない物理メモリ量でありながら、安定してＪａｖａプログラム１１３を稼動させることが可能である。

なお、ＧＣを実行するＪａｖａＶＭの選択手法には、第２実施形態と同様、ラウンドロビン方式を用いてもよい。また同様に、ＧＣ実行契機の判定に、第３実施形態と同様、処理リクエスト数を用いてもよい。また、第４実施形態４と同様、ハイパーバイザーがない環境においては、オペレーティングシステム１６０の物理メモリ制御部１６１を用いてもよい。

＜第６実施形態＞
次に、図２２〜図２７に本発明の第６の実施形態を示す。本第６実施形態では、ＧＣ開始の契機を判定する指標としてヒープ使用量を用い、ＧＣ開始の契機を判定するためのヒープ使用量の閾値を、第１実施形態のように管理者等が予め設定する代わりに、計算機５００の各ＪａｖａＶＭ１１１のＧＣ処理後のヒープ使用率情報（ヒープ使用割合）を基にして、自動的に適切な閾値を算出する場合を示す。

一般に、ＧＣ実行後にも一定数のオブジェクトはゴミオブジェクトとならず非ゴミオブジェクトとしてヒープ領域１１２に残存する。ＧＣ実行後にもヒープ領域１１２に残る非ゴミオブジェクトについては、ＧＣ実行タイミングをずらしてもヒープ使用量は削減されない。このため、各ＪａｖａＶＭ１１１毎のヒープ使用量の総和である合計ヒープ使用量をＧＣ開始の指標とする場合に、合計ヒープ使用量に対する閾値を適切に算出するためには、ヒープ領域１１２に残存する非ゴミオブジェクトの容量の分を差し引く必要がある。しかし、ＧＣ処理後に残る非ゴミオブジェクトが占有するメモリ１８２の容量は各Ｊａｖａプログラム１１３の振る舞いに依存するため、適切な閾値の算出は困難である。閾値が適切な値よりも大きい場合、不必要なメモリを消費してしまい無駄が発生する。逆に、閾値が適切な値よりも小さい場合、各ＪａｖａＶＭ１１１のＧＣ実行の間隔が短くなりＪａｖａプログラム１１３の処理性能が低下する、という問題があった。

本第６実施形態は、実際にＪａｖａプログラム１１３を稼動させた際に非ゴミオブジェクトがヒープ領域１１２に残存する量を残存量情報として取得し、この残存量情報を基にＧＣ開始の契機を判定するための閾値を算出することで、上記問題を解決するものである。

本第６実施形態では、以上の効果を実現するため、第１実施形態の構成要素に加えて、閾値を算出する処理部を用いる。また、第６実施形態で実行する処理は、第１実施形態の処理に加えて、ゴミオブジェクトの回収処理の実行後にヒープ領域１１２に残った非ゴミオブジェクトの残存量情報を送受信する処理と、上記残存量情報を基に閾値を算出する処理を含む。また、第６実施形態における制御情報管理テーブル１４４とメモリ量管理テーブル１４２は、第１実施形態のデータに加えて、閾値の算出に必要となるデータを含む。

図２２は、本第６実施形態の計算機システムの構成を示すブロック図である。第１実施形態の構成要素に加え、回収管理プログラム１４０中に閾値算出処理部６１４４を含むのが特徴である。閾値算出処理部６１４４は、制御情報管理テーブル１４４及びメモリ量管理テーブル１４２に格納された値に基づき、後述するように閾値を算出する処理部である。その他の構成は第１実施形態と同様である。

図２４は、第６実施形態におけるＧＣ制御処理の概要を示す図である。第１実施形態の図２の処理に加え、ＪａｖａＶＭ１１１での回収処理Ｓ３２２後に、非ゴミオブジェクトの残存量情報を検出して管理プログラム１４０に送信する回収後ヒープ残存量送信処理Ｓ６３２２を含み、回収管理プログラム１４０での回収処理通知送信処理Ｓ３３７後に、ＪａｖａＶＭ１１１からの残存量情報を受信するヒープ残存量受信処理Ｓ６３３７と、受信した残存量情報から次回の閾値を算出する閾値算出処理Ｓ６３３８を含むのが特徴である。

図２４において、Ｓ３３１〜Ｓ３３７及びＳ３２１、Ｓ３２２は第１実施形態の図２で示した処理と同一であるため重複した説明は省略する。ＪａｖａＶＭ１１１では、回収指示通知受信部１３２による回収処理Ｓ３２２を実行した後、メモリ量送信部１３１によりＧＣ処理後のヒープ領域１１２の使用量情報（ヒープ使用量）が非ゴミオブジェクトの残存量情報として回収管理プログラム１４０に送信される（Ｓ６３２２）。

回収管理プログラム１４０では、回収処理通知送信処理Ｓ３３７の実行後に、回収指示通知送信部１４６がＪａｖａＶＭ１１１からの残存量情報を受信してメモリ量管理テーブル１４２中のＧＣ時残存量フィールド６２２４のリストに受信した残存量情報を追加した（Ｓ６３３７）後、閾値算出処理部６１４４による閾値の算出処理が行われる（Ｓ６３３８）。

以下、本実施形態と第１実施形態との差分箇所について、詳細に説明する。

図２３は、上記図２２の閾値算出処理部６１４４で行われる閾値の算出方法の概要を示したものである。閾値算出処理部６１４４が算出に用いる情報は、各ＪａｖａＶＭ１１１のヒープ領域１１２のヒープ容量（図中領域長情報（図中、ｈ））と、過去Ｎ回の当該ＪａｖａＶＭ１１１によるＧＣ実行後の非ゴミオブジェクトの残存量（図中、ｇ１、ｇ２、ｇ３、…）である。Ｊａｖａプログラム１１３の実行時のヒープ領域１１２の平均的な使用量は非ゴミオブジェクトの残存量とヒープ領域長（ヒープ容量）の間で変動するため、時間平均すると非ゴミオブジェクトの残存量とヒープ領域長のちょうど中間の値となる。閾値算出処理部６１４４は、過去Ｎ回分の残存量の平均値を算出し、この平均値を平均残存量とし、平均残存量とヒープ領域長の平均値を平均ヒープ使用量として求めることで閾値を算出する。

図２５は、第６実施形態において制御情報管理テーブル１４４に格納されるデータを示す図である。第６実施形態においては、制御情報管理テーブル１４４は閾値メモリ使用量と閾値算出用サンプル数の情報を含む。閾値メモリ使用量に格納されるデータは、第１実施形態の場合と同じである。閾値算出用サンプル数情報は、閾値算出処理部６１４４が閾値の算出に使用する過去のＧＣ時の非ゴミオブジェクトの残存量情報の最大個数（Ｎ個）を格納する。閾値算出用サンプル数情報は、予め管理者等により設定される。

図２６は、第６実施形態においてメモリ量管理テーブル１４２に格納されるデータを示す図である。第６実施形態においては、メモリ量管理テーブル１４２は第１実施形態のフィールドに加えて、ＧＣ時残存量フィールド６２２４を含む。ＧＣ時残存量フィールド６２２４は、ＪＶＭ識別子２２１に対応するＪａｖａＶＭ１１１の過去最大Ｎ回のＧＣ実行時の非ゴミオブジェクトのヒープ残存量を保持するリストを格納する。なお、上記のＮは、制御情報管理テーブル１４４の閾値算出用サンプル数に格納されている数値である。ＧＣ時残存量フィールド６２２４は、管理プログラム１４０の起動時に、管理プログラム１４０により空のリストに初期化される。また、前記Ｓ６３３７ステップの際にＧＣ時残存量フィールド６２２４のリストの要素数が閾値算出用サンプル数に達している場合は、最も古い要素を削除し、新しいデータをリストに追加する。

次に、図２４のステップ中で、特に、第６実施形態で特徴的であるＳ６３３８について、処理の詳細を図２７のフローチャートを用いて説明する。図２７は、図２４のＳ６３３８で行われる処理の詳細を示すフローチャートである。

まず、閾値算出処理部６１４４は新しい閾値を格納する変数Ｓを用意し、変数Ｓの値を０に初期化する（Ｓ６３４１）。

次に、閾値算出処理部６１４４は、メモリ量管理テーブル１４２の中に未調査のＪＶＭがあるかを判断し（Ｓ６３４２）、ある場合（Ｓ６３４２：Ｙｅｓ）には、Ｓ６３４３の処理に進み、無い場合（Ｓ６３４２：Ｎｏ）には、Ｓ６３４８の処理に進む。

次に、ＧＣ実行ＪａｖａＶＭ選択部１４５は、メモリ量管理テーブル１４２上の次のエントリのＪａｖａＶＭ識別子２２１を変数Ｙに格納する（Ｓ６３４３）。

次に、閾値算出処理部６１４４は、Ｙに対応するヒープ容量２２２を変数Ｈに設定する（Ｓ６３４４）。

次に、閾値算出処理部６１４４は、Ｙに対応するＧＣ時残存量６２２４の（Ｎ個の残存量）を変数Ｌに設定する（Ｓ６３４５）。

次に、閾値算出処理部６１４４は、変数Ｌに含まれるＮ個の残存量の平均値をＧＣ時残存量の平均値Ｇとして求める（Ｓ６３４６）。

次に、閾値算出処理部６１４４は、平均ヒープ使用量を、該当ＪａｖａＶＭ１１１のヒープ領域長を変数Ｈ、ＧＣ時残存量の平均値をＧとすると、以下に示す式（３）で算出する。

平均ヒープ使用量 ＝ （Ｈ ＋ Ｇ） ／ ２ ・・・（３）
そして、閾値算出処理部６１４４は、各ＪａｖａＶＭ１１１の平均ヒープ使用量の合計値を求めるため、変数Ｓの値を、次の（４）式のように更新する（Ｓ６３４７）。

変数Ｓ ＝ Ｓ＋（（Ｈ ＋ Ｇ） ／ ２） ・・・（４）
最後に、閾値算出処理部６１４４は、制御情報管理テーブル１４４中の閾値メモリ使用量２２３の値を変数Ｓの値に更新する（Ｓ６３４８）。

なお、閾値の算出式は上記の式（３）に限定されるものではない。

以上により、本実施形態の計算機５００では、閾値算出処理部６１４４が制御に用いる閾値情報を各ヒープ領域１１２のＧＣ処理後のヒープ領域１１２の使用率情報を基に算出することで、非ゴミオブジェクトのヒープ残存量を差し引いた適切な閾値（閾値メモリ使用量）によるＧＣ処理を実現することが可能である。

なお、上記では複数のＪａｖａＶＭ１１１の平均ヒープ使用量から閾値メモリ使用量を求めたが、上記（３）式の平均ヒープ使用量を用い、各ＪａｖａＶＭ１１１毎に閾値メモリ使用量を設定するようにしても良い。

＜第７実施形態＞
次に、図２８に本発明の第７の実施形態を示す。第７実施形態は、第１実施形態と同じ契機判定処理を行うが、ＧＣ実行指示を通知する対象を判定する指標として、各ＪａｖａＶＭ１１１のヒープ使用量２２３を用いるもので、その他の構成は第１実施形態と同様である。

第１実施形態の図７で示した「ＧＣ実行指示を通知する対象として契機に到達した時点で次回ＧＣ実行契機に最も近いＪａｖａＶＭ」という選択処理は、対象のＪａｖａＶＭ１１１のヒープ使用量２２３が小さい場合には、回収処理を実行しても合計ヒープ使用量の減少量が小さいため、頻繁な回収処理が必要となる。

第７実施形態は、ヒープ使用量２２３が大きいＪａｖａＶＭ１１１を指示対象として選択することにより、各回収契機での回収量を最大化し、効率のよい回収処理を行うことを特徴の１つとするものである。

この処理は、第１実施形態の図２に示したＧＣ処理を実行するＪａｖａＶＭ１１１の選択処理Ｓ３３６ステップを変更することで実現される。

本第７実施形態における計算機１００の構成およびＧＣ処理の概要は、それぞれ第１実施形態の図１および図２と同様であるため省略する。

以下、第７実施形態と第１実施形態との差分箇所であるＧＣを実行するＪａｖａＶＭの選択処理Ｓ３３６について、詳細を図２８のフローチャートを用いて説明する。

この処理は、ＧＣ実行ＪａｖａＶＭ選択部１４５が、メモリ量管理テーブル１４２に登録されている全ＪａｖａＶＭ１１１中で最もヒープ使用量が高いＪａｖａＶＭ１１１を選択する処理である。

まず、ＧＣ実行ＪａｖａＶＭ選択部１４５は、メモリ使用量管理テーブル１４２の先頭のエントリのＪａｖａＶＭ１１１のＪａｖａＶＭ識別子２２１を変数Ｘに格納する（Ｓ７３４１）。そして、ＧＣ実行ＪａｖａＶＭ選択部１４５は、ＪａｖａＶＭ識別子２２１に対応するヒープ使用量２２３を変数Ｘ２に格納する（Ｓ７３４２）。

次に、ＧＣ実行ＪａｖａＶＭ選択部１４５は、メモリ使用量管理テーブル１４２の中に未調査のＪＶＭがあるかを判断し（Ｓ７３４３）、ある場合（Ｓ７３４３：Ｙｅｓ）には、Ｓ３４４の処理に進み、無い場合（Ｓ７３４３：Ｎｏ）には、Ｓ７３４７の処理に進む。

次に、ＧＣ実行ＪａｖａＶＭ選択部１４５は、メモリ量管理テーブル１４２上の次のエントリのＪａｖａＶＭ識別子２２１を変数Ｙに格納する（Ｓ７３４４）。

次に、ＧＣ実行ＪａｖａＶＭ選択部１４５は、当該ＪａｖａＶＭ識別子２２１に対応するヒープ使用量２２３を変数Ｙ２に格納する（Ｓ７３４５）。

次に、ヒープ使用量Ｘ２及びＹ２に格納しているＪａｖａＶＭ１１１同士のヒープ使用量を比較する（Ｓ７３４６）。この判定では、ヒープ使用量Ｙ２が、ピープ使用量Ｘ２よりも大きいかを判断する。

ピープ使用量Ｙ２の方がＸ２より大きい場合（Ｓ７３４６：Ｙｅｓ）には、Ｓ７３４７の処理に進む、即ちＧＣ実行ＪａｖａＶＭ選択部１４５は、変数Ｘの値をＹに更新し、変数Ｘ２の値をＹ２に更新する（Ｓ７３４７）。なお、Ｙ２がＸ２以下の場合（Ｓ７３４６：Ｎｏ）、Ｓ７３４３の処理に戻り、メモリ量管理テーブル１４２に未処理の要素（エントリ）がなくなるまで、上記Ｓ７３４３〜Ｓ７３４５の処理を繰り返す。

最後に、ＧＣ実行ＪａｖａＶＭ選択部１４５は、変数Ｘに格納されているＪａｖａＶＭ１１１を選択対象に指定し（Ｓ７３４６）、処理を終了する。

上記処理により、メモリ量管理テーブル１４２の先頭のエントリから順にヒープ使用量を比較して、最もヒープ使用量が大きいＪａｖａＶＭ１１１の識別子２２１を決定することができる。

以上により、本実施形態の計算機１００では、ＧＣ実行ＪａｖａＶＭ選択部１４５が、ヒープ使用量２２３が大きいＪａｖａＶＭ１１１を指示対象として選択することにより、
各回収契機での回収量を最大化し、効率のよい回収処理を行うことが可能である。

なお、ＧＣ実行指示を通知する対象を判定する指標は、必ずしもヒープ使用量に限定されるものではなく、他の指標を用いてもよい。他の指標の例としては、ヒープ使用量から平均残存量を引いた値とすることが考えられる。なお、平均残存量は、第６実施形態と同様、当該ＪａｖａＶＭ１１１による過去Ｎ回のＧＣ実行後の非ゴミオブジェクトの残存量とする。あるいは、別の指標の例としては、各ＪａｖａＶＭ１１１のヒープ使用割合を指標とすることも考えられる。なお、ヒープ使用割合は、ヒープ使用量２２３／ヒープ容量２２２とする。

また、上記第１から第７実施形態では、メモリ１８２を適用対象とするＧＣ処理について述べたが、ログ構造ファイルシステム（例えば、非特許文献４）や追記型データベース（例えば、非特許文献５）によるディスク等の記憶装置の使用率も上述のメモリの使用率特性と同様の使用率特性を示すことが知られており、本発明を適用しても良い。

以上のように、本発明はＧＣ処理を行う計算機や計算機システムに適用することができ、特に、ＪａｖａＶＭを実行する計算機のメモリ管理方法やプログラムに適用することができる。

１００、２００、３００、４００、５００ 計算機
１８１ ＣＰＵ
１８２ メモリ
１８３ 入出力装置
１１３ Ｊａｖａプログラム
１７０ ハイパーバイザー
１７１ 物理メモリマッピング制御部
１１０ 仮想マシン
１６０ オペレーティングシステム
１１１ ＪａｖａＶＭ
１１６ ＪａｖａＶＭ識別子
１１２ ヒープ領域
１１４ 参照ルート
１１５ Ｊａｖａプログラム実行部
１２０ ＧＣ処理部
１３０ 回収タイミング制御部
１３１ メモリ量送信部
１３２ 回収指示通知受信部
１４０ 回収管理プログラム
１４４ 制御情報管理テーブル
１４２ メモリ量管理テーブル
１４７ メモリ量監視部
１４５ ＧＣ実行ＪａｖａＶＭ選択部
１４６ 回収指示通知送信部

Claims (13)

1. 演算装置とメモリを備えた計算機で、
   前記メモリに格納されて前記演算装置で実行される複数のプログラムがそれぞれ使用する複数のメモリ領域中の不要になった領域をそれぞれ解放するメモリ管理方法であって、
   前記演算装置が、前記プログラムに関連したメモリ領域の解放の開始を判定する指標をそれぞれ取得するステップと、
   前記演算装置が、前記指標の合計値と所定の閾値とを比較して、前記合計値が前記閾値を超えたときに、前記複数のプログラムのうち前記複数のプログラムよりも少ない数のプログラムを選択するステップと、
   前記演算装置が、前記選択したプログラムが利用する前記メモリ領域の不要になった領域を回収するステップと、
   前記演算装置が、前記メモリ領域のうち前記回収した領域を解放するステップと、
   を含むことを特徴とするメモリ管理方法。
2. 請求項１に記載のメモリ管理方法において、
   前記指標は、前記プログラムが実際に利用しているメモリ領域のメモリ使用量であることを特徴とするメモリ管理方法。
3. 請求項１に記載のメモリ管理方法において、
   前記指標は、前記各プログラムが、前記プログラム自身の直近の回収処理実行契機以降に受け付けたリクエストの数であることを特徴とするメモリ管理方法。
4. 請求項２に記載のメモリ管理方法において、
   前記演算装置が、前記指標の合計値と所定の閾値とを比較して、前記合計値が前記閾値を超えたときに、前記複数のプログラムのうち前記複数のプログラムよりも少ない数のプログラムを選択するステップは、
   前記演算装置が、前記各プログラムが利用するメモリ領域に空き領域がなくなる次回の契機を予測し、
   前記合計値が前記閾値を超えた時点で、前期契機が最も近いプログラムを選択することを特徴とするメモリ管理方法。
5. 請求項２に記載のメモリ管理方法において、
   前記演算装置が、前記指標の合計値と所定の閾値とを比較して、前記合計値が前記閾値を超えたときに、前記複数のプログラムのうち前記複数のプログラムよりも少ない数のプログラムを選択するステップは、
   前記指標が前記閾値を超えた時点で、前記各プログラムが利用するメモリ領域のメモリ使用量が最大のプログラムを選択することを特徴とするメモリ管理方法。
6. 請求項２に記載のメモリ管理方法において、
   前記演算装置が、前記指標の合計値と所定の閾値とを比較して、前記合計値が前記閾値を超えたときに、前記複数のプログラムのうち前記複数のプログラムよりも少ない数のプログラムを選択するステップは、
   前記指標が前記閾値を超えた時点で、前記複数のプログラムのうち前記複数のプログラムよりも少ない数のプログラムを所定順序で選択することを特徴とするメモリ管理方法。
7. 請求項１に記載のメモリ管理方法において、
   前記演算装置が、前記指標の合計値と所定の閾値とを比較して、前記合計値が前記閾値を超えたときに、前記複数のプログラムのうち前記複数のプログラムよりも少ない数のプログラムを選択するステップは、
   前記複数のプログラムとは異なる管理プログラムが実行することを特徴とするメモリ管理方法。
8. 請求項１に記載のメモリ管理方法において、
   前記演算装置が、前記指標の合計値と所定の閾値とを比較して、前記合計値が前記閾値を超えたときに、前記複数のプログラムのうち前記複数のプログラムよりも少ない数のプログラムを選択するステップは、
   前記複数のプログラム自身が実行することを特徴とするメモリ管理方法。
9. 請求項１に記載のメモリ管理方法において、
   前記複数のプログラムは、前記計算機の物理的な計算機資源を仮想化する仮想化部が生成した複数の仮想計算機上で実行され、
   前記演算装置が、前記回収した領域を解放するステップは、
   前記仮想化部が前記メモリ領域の解放を実行することを特徴とするメモリ管理方法。
10. 請求項１に記載のメモリ管理方法において、
    前記複数のプログラムは、前記計算機の物理的な計算機資源を管理するオペレーティングシステムが生成する複数のプロセスとして実行され、
    前記演算装置が、前記メモリ領域のうち前記回収した領域を解放するステップは、
    前記オペレーティングシステムが前記メモリ領域の解放を実行することを特徴とするメモリ管理方法。
11. 請求項１に記載のメモリ管理方法において、
    前記演算装置が、
    前記プログラムが利用するメモリ領域の容量と
    前記プログラムによる前記回収した領域を解放するステップ実行後の前記プログラムが利用するメモリ領域の使用量を取得し、
    当該量から前記閾値を演算するステップをさらに含むことを特徴とするメモリ管理方法。
12. 演算装置とメモリを備えて複数のプログラムを実行し、前記複数のプログラムがそれぞれ使用する複数のメモリ領域中の不要になった領域をそれぞれ解放する計算機システムであって、
    前記複数のプログラムのそれぞれに前記メモリを割り当てる物理メモリ制御部と、
    前記プログラムを実行するために利用するメモリ領域を前記複数のプログラムのそれぞれについて前記メモリに設定する実行管理部と、
    前記複数のプログラムのそれぞれが利用する前記メモリ領域の解放の開始を判定する指標を取得する回収タイミング制御部と、
    前記複数のプログラムのそれぞれが利用する前記メモリ領域のうち不要領域を検出し、当該不要領域を回収する回収処理部と、
    前記複数のプログラムの各回収タイミング制御部から前記指標をそれぞれ取得し、取得した指標の合計値と所定の閾値とを比較して、前記合計値が前記閾値を超えたときに、前記回収処理部に不要領域の回収を指令する回収管理部と、を備え、
    前記回収管理部は、
    前記取得した指標の合計値と所定の閾値とを比較して、前記合計値が前記閾値を超えたときに、前記複数のプログラムのうち前記複数のプログラムよりも少ない数のプログラムを選択し、当該選択したプログラムの前記回収処理部に不要領域の回収を指令し、
    前記回収処理部は、
    前記メモリ領域のうち不要領域を検出し、当該不要領域を回収した後に、前記物理メモリ制御部に対して前記回収した不要領域の解放を指令することを特徴とする計算機システム。
13. 計算機を制御するプログラムであって、
    前記計算機は、プログラムが格納されるメモリと、前記メモリに格納された前記プログラムを実行する演算装置と、を備え、
    前記メモリ領域の解放の開始を判定する指標を取得する手順と、
    前記指標の合計値と所定の閾値とを比較して、前記合計値が前記閾値を超えたときに、前記複数のプログラムのうち前記複数のプログラムよりも少ない数のプログラムを選択する手順と、
    前記選択したプログラムが利用する前記メモリ領域の不要になった領域を回収する手順と、
    前記メモリ領域のうち前記回収した領域を解放する手順と、
    を前記演算装置に実行させることを特徴とするプログラム。