(57)【要約】  プロセッサとメモリとを有するコンピュータにおいて、メモリ割り当ての成功または失敗の蓋然性についての判定結果が、メモリ割り当てが成功する蓋然性が高いことを示す場合に、プロセッサは、メモリ割り当ての要求に応じてメモリ割り当てを試みる。上記判定結果は、プロセッサが１つ以上の特定の処理のそれぞれを実行するのにかかる時間に基づく。逆に、判定結果が、メモリ割り当てが失敗する蓋然性が高いことを示す場合に、プロセッサは、メモリ割り当てを試みずにメモリ割り当て失敗の旨の応答を行う。または、判定結果が、メモリ割り当てが失敗する蓋然性が高いことを示す場合に、プロセッサは、メモリ割り当てが成功する蓋然性が高いことを示す場合に実行されるメモリ割り当ての試みに対して、遅延させてメモリ割り当てを試みる。
2013051154.tif 000002
【特許請求の範囲】
【請求項１】
プロセッサとメモリとを有するコンピュータにおける、前記プロセッサによって実行されるメモリ割り当て制御方法であって、
前記プロセッサが１つ以上の特定の処理のそれぞれを実行するのにかかる時間に基づく、メモリ割り当ての成功または失敗の蓋然性についての判定結果が、メモリ割り当てが成功する蓋然性が高いことを示す場合に、メモリ割り当ての要求に応じてメモリ割り当てを試み、
前記判定結果が、メモリ割り当てが失敗する蓋然性が高いことを示す場合に、メモリ割り当てを試みずにメモリ割り当て失敗の旨の応答を行うか、または、前記メモリ割り当てが成功する蓋然性が高いことを示す場合に実行されるメモリ割り当ての試みに対して、遅延させてメモリ割り当てを試みる、
ことを特徴とするメモリ割り当て制御方法。
【請求項２】
前記１つ以上の特定の処理は、
前記メモリの使用量または使用率を示す値を、前記要求を受け付けた後に取得する処理と
前記プロセッサの負荷を示す値を、前記要求を受け付けた後に取得する処理
の少なくとも一方を含み、
前記判定結果は、
前記１つ以上の特定の処理に含まれる各特定の処理について、当該特定の処理を前記プロセッサが実行するのにかかる時間が、当該特定の処理に応じて決められた第１の閾値より長い、という第１の条件と、
前記メモリの使用量または使用率が第２の閾値を超えているという第２の条件と、前記プロセッサの負荷が第３の閾値を超えているという第３の条件の論理積と
の論理和が真のとき、メモリ割り当てが失敗する蓋然性が高いことを示す
ことを特徴とする請求項１に記載のメモリ割り当て制御方法。
【請求項３】
前記１つ以上の特定の処理は、所定範囲内の過去に前記メモリに対する割り当て要求に応じて前記プロセッサがメモリ割り当てを試みた処理を含み、
前記判定結果は、前記プロセッサが前記メモリ割り当てを前記所定範囲内の過去において試みたときに結果を得るのにかかった時間が閾値より長いとき、メモリ割り当てが失敗する蓋然性が高いことを示す
ことを特徴とする請求項１に記載のメモリ割り当て制御方法。
【請求項４】
メモリ割り当てが失敗する蓋然性が高いことを前記判定結果が示す場合に前記メモリ割り当てを試みる処理を遅延させる遅延時間の長さが、前記所定範囲の長さ以上である
ことを特徴とする請求項３に記載のメモリ割り当て制御方法。
【請求項５】
１≦α≦βとして、
前記１つ以上の特定の処理は、過去に前記プロセッサが実行した複数回のメモリ割り当ての試みのうち、現在に近い方からβ回の試みを含み、
前記判定結果は、前記β回の試みのうち少なくともα回の試みのそれぞれにおいて、前記プロセッサが結果を得るのにかかった時間が閾値より長いとき、メモリ割り当てが失敗する蓋然性が高いことを示す
ことを特徴とする請求項１に記載のメモリ割り当て制御方法。
【請求項６】
前記閾値は、前記プロセッサが過去に前記メモリ割り当てを試みたときの、要求されたメモリサイズに応じた値である
ことを特徴とする請求項３から５のいずれか１項に記載のメモリ割り当て制御方法。
【請求項７】
前記メモリ割り当てを試みた結果、前記メモリ割り当てに失敗した場合に、
前記メモリ割り当ての試みが失敗したことが判明するのにかかった時間が閾値より長ければ、メモリ割り当て失敗の旨の応答を行い、
前記時間が前記閾値より短く、かつ、前記メモリ割り当てを試みた回数が所定の回数に達していなければ、前記メモリ割り当てを再度試み、
前記メモリ割り当てを試みた前記回数が前記所定の回数に達してもなお、前記メモリ割り当てに成功しなければ、メモリ割り当て失敗の旨の応答を行う
ことを特徴とする請求項１から６のいずれか１項に記載のメモリ割り当て制御方法。
【請求項８】
前記メモリ割り当てを試みた結果、前記メモリ割り当てに失敗した場合に、
前記メモリ割り当てを試みた回数が所定の回数に達していなければ、前記メモリ割り当てを再度試み、
前記メモリ割り当てを試みた前記回数が前記所定の回数に達してもなお、前記メモリ割り当てに成功しなければ、メモリ割り当て失敗の旨の応答を行う
ことを特徴とする請求項１から６のいずれか１項に記載のメモリ割り当て制御方法。
【請求項９】
前記メモリ割り当てのためのライブラリ関数またはシステムコールを呼び出す第１のコードと、前記第１のコードを呼び出す第２のコードとを含むアプリケーションプログラムを、前記プロセッサが実行し、
前記プロセッサが、前記第２のコードの実行の過程において前記第２のコードからの前記第１のコードの呼び出しを実行することにより、前記メモリ割り当ての要求が発行され、
前記プロセッサは、呼び出された前記第１のコードの実行を開始することにより、前記メモリ割り当ての要求を受け付け、
前記プロセッサは、呼び出された前記第１のコードの実行の過程において前記ライブラリ関数または前記システムコールを呼び出すことにより、前記メモリ割り当てを試みる
ことを特徴とする請求項１から８のいずれか１項に記載のメモリ割り当て制御方法。
【請求項１０】
前記メモリ割り当てのためのライブラリ関数またはシステムコールを呼び出すアプリケーションプログラムを、前記プロセッサが実行し、
前記プロセッサが、前記アプリケーションプログラムの実行の過程において前記ライブラリ関数または前記システムコールを呼び出すことにより、前記メモリ割り当ての要求が発行され、
前記プロセッサは、呼び出された前記ライブラリ関数または前記システムコールの実行を開始することにより、前記メモリ割り当ての要求を受け付ける
ことを特徴とする請求項１から６のいずれか１項に記載のメモリ割り当て制御方法。
【請求項１１】
プロセッサとメモリとを有するコンピュータにおける前記プロセッサに、
前記プロセッサが特定の処理を実行するのにかかる時間に基づく、メモリ割り当ての成功または失敗の蓋然性についての判定結果が、メモリ割り当てが成功する蓋然性が高いことを示す場合に、メモリ割り当ての要求に応じてメモリ割り当てを試み、
前記判定結果が、メモリ割り当てが失敗する蓋然性が高いことを示す場合に、メモリ割り当てを試みずにメモリ割り当て失敗の旨の応答を行うか、または、前記メモリ割り当てが成功する蓋然性が高いことを示す場合に実行されるメモリ割り当ての試みに対して、遅延させてメモリ割り当てを試みる、
ことを含む処理を実行させるためのプログラム。
【請求項１２】
メモリと、
前記メモリ上に動的に割り当てられる領域を用いてプログラムを実行するプログラム実行部と、
前記プログラムとは別のプログラムによる特定の処理を実行する特定処理実行部と、
前記プログラム実行部からメモリ割り当ての要求を受け付ける要求受付部と、
前記特定の処理を前記特定処理部が実行するのにかかる時間に基づく、メモリ割り当ての成功または失敗の蓋然性についての判定結果が、メモリ割り当てが成功する蓋然性が高いことを示す場合に、メモリ割り当ての要求に応じてメモリ割り当てを試み、前記判定結果が、メモリ割り当てが失敗する蓋然性が高いことを示す場合に、メモリ割り当てを試みずにメモリ割り当て失敗の旨の応答を行うか、または、前記メモリ割り当てが成功する蓋然性が高いことを示す場合に実行されるメモリ割り当ての試みに対して、遅延させてメモリ割り当てを試みるメモリ割り当て制御部
を備える情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はメモリ割り当ての技術に関する。
【背景技術】
【０００２】
コンピュータにおけるメモリ割り当てに関しては、いくつかの研究テーマがある。例えば、動的に割り当てられたメモリが解放されないと、メモリリークが生じる。そのため、メモリリークの防止または監視に関する技術が研究されている。例えば、計算機システムを連続して使用する場合に、メモリリークによる計算機のデッドロックなどを回避することを目的として、次のような技術が提案されている。【０００３】
ある計算機システムにおける情報取得処理部は、ＯＳ（Operating System）管理テーブルから、メモリ使用量とＣＰＵ（Central Processing Unit）負荷を定期的に取得する。そして、情報取得処理部は、メモリ負荷履歴情報領域とＣＰＵ負荷履歴情報領域に、取得したメモリ使用量とＣＰＵ負荷を、取得時刻とともに記憶する。【０００４】
また、情報解析処理部は、メモリ負荷履歴情報からメモリリークの発生を検知すると、メモリ使用量がメモリ使用限界の閾値に達する到達時刻を予測する。さらに、情報解析処理部は、ＣＰＵ負荷履歴情報から、上記到達時刻の直前で負荷の少ない時間帯を予測し、予測した時間帯に回復処理を行うよう、回復処理実行部をセットする。【０００５】
また、有限のメモリリソースを効率よく利用するためのメモリ割り当ての仕方も研究テーマの一つである。例えば、画像処理のための構成の一例として、パイプライン形態等で連結された画像処理モジュールに対応する複数のスレッドを並列に実行させて画像処理を行う構成が考えられる。この構成において、記憶リソースが一時的に不足しても画像処理全体を継続させることを可能とすることを目的として、次のような方法が提案されている。【０００６】
当該方法は、各モジュールに対応するスレッドからメモリ取得が要求される毎に、要求されたメモリ領域が確保可能か判定することを含む。当該方法はさらに、要求されたメモリ領域が確保可能であれば、メモリ領域を割り当てることを含む。また、当該方法は、要求されたメモリ領域が確保可能でなければ、要求元スレッドの動作を停止させ、待ち行列に取得要求情報を登録することを含む。【０００７】
また、当該方法は、任意のスレッドからメモリ解放が要求されると、要求されたメモリ領域を解放することを含む。当該方法はさらに、待ち行列の先頭に登録された取得要求情報から順に、次の一連の処理を行うことを含む。具体的には、当該一連の処理とは、待ち行列中の取得要求情報が要求するメモリ領域を確保可能か判定し、当該メモリ領域が確保可能であれば待ち行列から取得要求情報を取り出し、スレッドの動作停止状態を解除し、メモリ領域を割り当てる処理である。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００４−５３０５号公報
【特許文献２】特開２００７−３２３３９３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
コンピュータは、効率よく動作することが望ましい。しかし、ある種の条件下では、メモリ割り当ての要求に応じてメモリ割り当てを試みる処理自体が、コンピュータの効率を悪化させる要因になり得る。【００１０】
本発明は、１つの側面では、コンピュータの効率を悪化させないように、適切にメモリ割り当てを制御することを目的とする。
【課題を解決するための手段】
【００１１】
一態様によれば、プロセッサとメモリとを有するコンピュータにおける、前記プロセッサによって実行されるメモリ割り当て制御方法が提供される。
前記メモリ割り当て制御方法は、前記プロセッサが１つ以上の特定の処理のそれぞれを実行するのにかかる時間に基づく、メモリ割り当ての成功または失敗の蓋然性についての判定結果が、メモリ割り当てが成功する蓋然性が高いことを示す場合に、メモリ割り当ての要求に応じてメモリ割り当てを試みることを含む。【００１２】
前記メモリ割り当て制御方法はさらに、前記判定結果が、メモリ割り当てが失敗する蓋然性が高いことを示す場合に、メモリ割り当てを試みずにメモリ割り当て失敗の旨の応答を行うか、または、前記メモリ割り当てが成功する蓋然性が高いことを示す場合に実行されるメモリ割り当ての試みに対して、遅延させてメモリ割り当てを試みることを含む。
【発明の効果】
【００１３】
上記メモリ割り当て制御方法によれば、メモリ割り当てを試みる処理の実行に起因するコンピュータの効率悪化が回避される。
【図面の簡単な説明】
【００１４】
【図１】第１実施形態のメモリ割り当て制御方法の２つの例を示すフローチャートである。
【図２】第１実施形態のコンピュータのブロック構成図である。
【図３】第１〜第３実施形態に共通のコンピュータのハードウェア構成図である。
【図４】第２実施形態と第３実施形態に共通のコンピュータのブロック構成図である。
【図５】第２実施形態におけるメモリ割り当て制御方法を説明する図である。
【図６】第２実施形態で使われるデータを示す図である。
【図７】第２実施形態と第３実施形態に共通のシステム試験のフローチャートである。
【図８】第２実施形態における低負荷時の情報取得処置のフローチャートである。
【図９】第２実施形態と第３実施形態に共通の試験実行処理のフローチャートである。
【図１０】第２実施形態におけるメモリ取得処理のフローチャートである。
【図１１】第３実施形態で使われるデータを示す図である。
【図１２】第３実施形態における低負荷時の情報取得処置のフローチャートである。
【図１３】第３実施形態におけるメモリ取得処理のフローチャートである。
【発明を実施するための形態】
【００１５】
以下、実施形態について詳細に説明する。具体的には、まず第１〜第３実施形態に共通の目的について説明する。その後、図面を参照しながら第１〜第３実施形態の詳細を説明する。
【００１６】
具体的には、図１〜２を参照して、第１実施形態について説明する。次に、図３を参照して、第１〜第３実施形態に共通のコンピュータのハードウェア構成について説明する。その後、図４〜１０を参照して、第２実施形態について説明する。なお、図４〜１０のうち、図４、７および９は、第２実施形態と第３実施形態の共通点を示す。さらに、図１１〜１３を参照して、第３実施形態について説明する。最後に、その他の変形例についても説明する。
【００１７】
さて、上述のとおり、ある種の条件下では、メモリ割り当て（memory allocation）の要求に応じてメモリ割り当てを試みる処理自体が、コンピュータの効率を悪化させる要因になり得る。場合によっては、単なる効率の悪化ではすまず、コンピュータがストールしたりハングしたりすることもあり得る。そこで、第１〜第３実施形態は、いずれも、効率悪化、ストール、ハングなどを避けるように、適切にメモリ割り当てを制御することを目的とする。
【００１８】
以下では、上記の「ある種の条件」の具体例を説明する。また、なぜ当該条件下ではメモリ割り当てを試みる処理自体が、コンピュータの効率を悪化させる要因になり得るのかについても説明する。
【００１９】
上記の「ある種の条件」は、メモリ割り当てに失敗する見込みが高いことを示す条件であり、換言すれば、コンピュータの負荷が高いことを示す条件である。当該条件がより具体的にはどのように表されるかは、実施形態によって異なっていてよい。
【００２０】
高い確率でメモリ割り当てが失敗しそうなほどにコンピュータの負荷が高い状況下で、もしコンピュータがメモリ割り当てを試みると、コンピュータの効率が悪化するおそれがある。場合によっては、単に効率が悪化するだけでなく、コンピュータがストールしたりハングしたりすることもあり得る。理由は以下のとおりである。
【００２１】
アプリケーションがメモリ割り当てを要求する場合、アプリケーションから、ｍａｌｌｏｃ（）などのメモリ割り当てのためのライブラリ関数、または、ｍｍａｐ（）などのメモリ割り当てのためのシステムコールが呼び出される。なお、メモリ割り当てのためのライブラリ関数の内部では、メモリ割り当てのためのシステムコールが呼び出される。
【００２２】
そして、ライブラリ関数を介してメモリ割り当てが要求されるにしろ、アプリケーションからシステムコールが直接呼び出されるにしろ、メモリ割り当てのためには、ＣＰＵなどのプロセッサ資源が消費される。なぜなら、メモリ割り当ては、例えば、割り当て可能なメモリ領域を探索する処理など、いくつかの処理を含むからである。
【００２３】
場合によっては、ＣＰＵだけでなく、仮想アドレスと物理アドレスとの間の関係を管理するＭＭＵ（Memory Management Unit）などの、他のハードウェア資源がさらに消費されることもあり得る。負荷が高い場合にさらに資源が消費されると、効率悪化、ストール、ハングなどが生じ得る。
【００２４】
例えば、メモリ割り当てのためのカーネルプロセスにＣＰＵ時間が割かれる結果、ユーザプロセスにＣＰＵ時間がほとんど割り当てられなくなるかもしれない。その結果、ユーザプロセスの進捗が妨げられて効率が悪化するかもしれないし、レスポンスが非常に悪化するかもしれない。
【００２５】
また、メモリの使用量が多いという意味で負荷が高い場合、要求されたサイズのメモリが使用可能な状態にあるとは限らない。その結果、割り当て可能なメモリ領域が見つからず、メモリ割り当てが失敗するかもしれない。あるいは、割り当て可能なメモリ領域が見つかるまでに長時間を要するかもしれず、その結果、システム全体の効率が悪化するかもしれない。
【００２６】
一方で、メモリ割り当てが失敗した場合に再度メモリ割り当てを試みるための、リトライ制御が組み込まれたシステムもある。リトライ制御の結果として、リトライが無駄に行われる可能性がある。つまり、メモリ割り当ての試みが失敗する見込みが高いのにメモリ割り当ての試みが繰り返されるせいで、繰り返しのたびに試みが失敗し、結果的に無駄に資源が消費される可能性がある。リトライのためにさらにプロセッサ資源が消費されると、さらに効率が悪化したり、コンピュータがストールまたはハングしたりするおそれがある。
【００２７】
また、ある種のＯＳには、「ＯＯＭキラー（Out Of Memory killer）」と呼ばれる機能が実装されている。ＯＯＭキラー機能を持つＯＳにおいては、メモリが不足しているときにメモリ割り当てが要求されると、ＯＳは、何らかのプロセスに「ＳＩＧＴＥＲＭ」シグナルまたは「ＳＩＧＫＩＬＬ」シグナルを送って、当該プロセスを強制終了させることがある。
【００２８】
つまり、「メモリの使用量が多い」という意味で負荷が高い場合、メモリ割り当てを試みる処理は、実行中の何らかのプロセスを強制終了させる要因になり得る。もし、ＯＳが、強制終了させる対象のプロセスを不適切に選択してしまうと、コンピュータがストールまたはハングするおそれもある。
【００２９】
以上のように、コンピュータの負荷が高い状況下でメモリ割り当てを試みる処理は、効率悪化、ストール、ハングなどの各種の問題の要因となり得る。特に、比較的大きなサイズのメモリの割り当てが要求された場合は、小さなサイズのメモリの割り当てが要求された場合と比べて、効率悪化、ストール、ハングなどの問題が生じやすい。
【００３０】
例えば、あるＯＳにより定義されるページサイズは、４ＫＢ（キロバイト）である。ページサイズを超えるような比較的大きなサイズのメモリの割り当てが要求される場合には、数十Ｂ（バイト）から数百Ｂ程度の比較的小さなサイズのメモリの割り当てが要求される場合よりも、問題が生じやすい。
【００３１】
例えば、フォトレタッチアプリケーションや動画編集アプリケーションなどのアプリケーションは、大量のメモリを使用する。したがって、これらのアプリケーションでは、メモリ割り当てを試みる処理に起因する効率悪化等の問題が生じ得る。
【００３２】
また、サーバなどの様々なコンピュータ製品の性能は、製品の開発中や市場投入後など適宜の時期に試験される。例えば、各種の試験のためのシステム試験プログラムが、サーバの性能評価のために実行されることがある。
【００３３】
システム試験は、コンピュータの性能を試験することを目的とするので、システム試験プログラムの実行により、コンピュータには比較的大きな負荷がかかる。そして、ある種の試験では、比較的大きなサイズのメモリの割り当てが要求される。
【００３４】
したがって、システム試験の実行中には、高負荷状況下で比較的大きなサイズのメモリの割り当てが要求されることも、しばしば起こり得る。しかし、上述の理由から、高負荷状況下でメモリ割り当てを試みる処理によって、効率悪化、ストール、ハングなどの問題が生じることがある。これらの問題が生じると、効率よくコンピュータの性能を試験することができない。
【００３５】
以上のように、メモリ割り当ての際に何らかの問題が生じることがある。そして、メモリ割り当てを試みる処理に起因して発生し得るこれらの問題は、メモリリークを防止または監視するための技術では、防止することが難しい。また、これらの問題は、画像処理アプリケーションのような特定のアプリケーションにおいてのみ起こり得るのではなく、任意のアプリケーションで起こり得る。
【００３６】
また、動的メモリ割り当ての効率化のためにメモリプールが使われることもあるが、メモリプールを使用するだけでは、上記の問題は解決しきれない。なぜなら、メモリプールが使われる場合にも、メモリ割り当ての要求に応じてプロセッサ資源が消費されるからである。
【００３７】
また、メモリ資源の枯渇を防ぐことを主目的とする方法だけでは、メモリ割り当てを試みる処理に起因して生じ得る効率悪化、ストール、ハングなどの問題を解決することは、難しい。
【００３８】
例えば、メモリ資源の枯渇への対策として、以下の（１−１）〜（１−３）のような方法が考えられる。しかし、（１−１）〜（１−３）の方法では、メモリ資源の枯渇をある程度は防ぐことができるものの、上述のような問題を解決することは難しい。
【００３９】
（１−１）アプリケーションが使用するメモリの量を、システムが有するメモリの容量に合わせる方法。
（１−２）アプリケーションが使用するメモリの量に合わせて、予めシステムにメモリを備えておく方法。
（１−３）複数のアプリケーションがそれぞれ使用するメモリの容量を、アプリケーション間での情報の共有により動的に管理する方法。
【００４０】
例えば、（１−１）の方法は、より具体的には、メモリが不足する場合には複数のアプリケーションの同時実行を制限する方法であってもよい。あるいは、（１−１）の方法は、具体的には、アプリケーションのパラメタを調整する方法であってもよい。例えば、アプリケーションが具体的にはシステム試験プログラムである場合、試験用の各種パラメタを適宜チューニングすることで、システム試験で用いるメモリ容量が調節されてもよい。
【００４１】
また、（１−２）の方法は、具体的には例えば、メモリモジュールの増設により実現されてもよい。（１−１）と（１−２）のいずれの方法も、メモリ資源の枯渇を防ぐための方法の例である。
【００４２】
しかし、アプリケーションが使用するメモリの容量が事前には不明なこともある。例えば、アプリケーションが使用するメモリの容量が、アプリケーションの実行のたびに大きく異なるかもしれない。また、同時に実行されるアプリケーションの数は、場合によって大きく変動し得る。さらに、使用するメモリの量を調整するためのパラメタを持たないアプリケーションもある。
【００４３】
そこで、（１−３）のような方法が考えられる。例えば、複数のアプリケーションからアクセス可能な共通のメモリ領域、または、複数のアプリケーションからアクセス可能な共有ファイルが、（１−３）の管理のために使われてもよい。そして、コンピュータ全体で使用可能なメモリの容量と、個々のアプリケーションが現在使用中のメモリの容量が、上記の共通のメモリ領域または共有ファイルに記録されてもよい。すると、新たに割り当て可能なメモリの容量が計算可能となる。
【００４４】
よって、各アプリケーションは、上記の共通のメモリ領域または共有ファイルを参照することにより、当該アプリケーション自体が要求するメモリの容量を適切に調整する。また、各アプリケーションは、メモリの取得と解放に応じて、上記の共通のメモリ領域または共有ファイルを更新する。
【００４５】
しかし、（１−１）〜（１−３）のような方法には、以下のような欠点がある。そのため、（１−１）〜（１−３）のような方法では、メモリ割り当てを試みる処理に起因する効率悪化、ストール、ハングなどの問題を防ぐことが難しい。
【００４６】
例えば、（１−１）〜（１−３）の方法では、ＯＳによってＩＯ（input/output）処理やページ処理のために一時的に使用されているメモリ領域の容量を考慮に入れることが難しい。その結果、メモリの割り当てが失敗することがある。
【００４７】
例えば、ＯＳは、ディスク装置に対するＩＯ処理に関して、アプリケーションにとってのレイテンシを短縮するために、メモリをバッファ領域（つまりキャッシュ）として使用することがある。バッファ領域として一時的に利用されるメモリ領域は、例えばディスク装置へデータが実際に書き出された後、解放されて、アプリケーションから使用可能になる。しかし、あるアプリケーションがメモリ割り当てを要求したときには、偶然、大量のメモリがディスクＩＯのためのバッファ領域として利用されているかもしれない。つまり、メモリ割り当てが要求されたとき、偶然一時的に、コンピュータが、要求されたメモリサイズの割り当てができない状況に陥っていることがあり得る。
【００４８】
また、新たに割り当て可能なメモリ領域が、物理メモリ上に存在するページ内では見つからない場合、ＯＳによっては、エラーを返すことがある。つまり、この場合、要求されたメモリ割り当ては失敗する。あるいは、ＯＳによっては、ページイン（page in）のための処理を行ってから、ページインによって物理メモリ上に読み込まれたページ内に、要求されたサイズの領域を割り当てることもあり得る。この場合、メモリ割り当てには時間がかかる。
【００４９】
さらに、ＯＳのメモリ管理の実装にもよるが、今まで使用されていたメモリ領域が解放されてから、当該メモリ領域がアプリケーションから使用可能なメモリ領域（つまり新たに割り当て可能なメモリ領域）としてＯＳに「回収」されるまでに、多少の時間がかかることがある。つまり、どのプロセスによっても実際には使われていないのに割り当て不能な状態のメモリ領域が、一時的には存在し得る。
【００５０】
例えば以上のような、ＯＳのメモリ管理に関連して起こり得る一時的な状況の変化を考慮に入れることは、上記の（１−１）〜（１−３）の方法では難しい。なぜなら、（１−１）と（１−２）の方法は、既知の情報（例えばコンピュータが有するメモリの物理的な容量や、既知のパラメタの値など）に基づく方法だからである。また、（１−３）の方法は、個々のアプリケーションによって認識することのできる情報に基づく方法だからである。つまり、（１−３）の方法では、アプリケーション自体が管理しているわけではない情報（すなわち、ＯＳ内部でのメモリ管理の状況）が考慮に入れられていない。
【００５１】
さらに、（１−３）の方法には、「資源共有のための余計なコストがかかる」という欠点と、「アプリケーション間でのメモリ管理のために共有されている情報の精度が、場合によっては落ちてしまう」という欠点もある。
【００５２】
例えば、上記のように（１−３）の方法では、メモリ使用量の一元管理のために、複数のアプリケーションからアクセス可能な、共通のメモリ領域または共有ファイルが使われてもよい。しかし、共通のメモリ領域または共有ファイルのような共有資源を使用するためには、共有資源に関する排他制御が必要である。具体的には、プロセス間の排他制御やスレッド間の排他制御が必要である。
【００５３】
また、ときには、アプリケーションが、動的に取得したメモリを解放する前に、異常終了することもある。すると、（１−３）の方法では、共通のメモリ領域または共有ファイルに記録されている情報の精度が劣化してしまう。なぜなら、（１−３）の方法では、共有される情報は個々のアプリケーションによって更新されるからである。
【００５４】
仮に、アプリケーションの異常終了に起因するメモリリークをＯＳが検出可能であるとし、しかも、ＯＳは検出したメモリ領域を使用可能な状態に復旧することが可能であるとしても、（１−３）の方法では共有される情報の精度が落ちることがある。なぜなら、共通のメモリ領域または共有ファイル上の情報は、ＯＳによって更新されるのではなく、個々のアプリケーションによって更新されるからである。
【００５５】
したがって、たとえＯＳによってメモリリークが検出されて実際にはメモリが使用可能な状態に復旧したとしても、異常終了したアプリケーションが使用していたメモリの容量に関する情報は更新されない。その結果、アプリケーション間で共有される情報の精度は落ち、他のアプリケーションは、不正確な情報に基づいてメモリの割り当てを要求することになる。
【００５６】
そして、以上の例示から理解されるように、（１−１）〜（１−３）の方法では、ＣＰＵなどのプロセッサの負荷は、メモリ割り当てに際して何ら考慮されない。また、（１−３）の方法では、共有される情報に関する排他制御のために、むしろ余計な負荷がＣＰＵに生じる。さらに、上記のとおり、ＯＳのメモリ管理に関連して起こり得る一時的な状況の変化を考慮に入れることは、（１−１）〜（１−３）の方法では難しい。
【００５７】
したがって、メモリ資源の枯渇を防ぐことを主目的とする（１−１）〜（１−３）の方法では、メモリ割り当てを試みる処理自体に起因する効率悪化、ストール、ハングなどの問題は、防ぎきれない。そこで、以下に述べる第１〜第３実施形態は、メモリ割り当てを試みる処理自体に起因する効率悪化、ストール、ハングなどの問題を防ぐことを目的とする。換言すれば、第１〜第３実施形態は、効率悪化、ストール、ハングなどの問題を引き起こさないように、適切にメモリ割り当てを制御することを目的とする。
【００５８】
さて、続いて第１実施形態について図１〜２を参照して説明する。
図１は、第１実施形態のメモリ割り当て制御方法の２つの例を示すフローチャートである。図１の２つのフローチャートＦ１とＦ２は、いずれも、メモリとプロセッサを有するコンピュータにおけるプロセッサが実行するメモリ割り当て制御方法の例を示す。プロセッサは、プログラムを実行することにより、フローチャートＦ１またはＦ２に示すように動作する。
【００５９】
なお、メモリは、例えば、ＤＲＡＭ（Dynamic Random Access Memory）であってもよい。プロセッサは、例えば、１つまたは複数のＣＰＵを有するコンピュータにおける、個々の各ＣＰＵであってもよい。
【００６０】
図１に関して、まず、フローチャートＦ１による処理を説明し、次に、フローチャートＦ１との違いを中心にして、フローチャートＦ２による処理を説明する。その後、第１実施形態の利点について説明してから、フローチャートＦ１とＦ２の詳細に関して何点か補足する。
【００６１】
ステップＳ１０１でプロセッサは、メモリ割り当ての要求を受け付ける。そして、次のステップＳ１０２でプロセッサは、ある判定条件が成立するか否かを判断する。
判定条件は、メモリ割り当てに失敗する見込みが高いときに成立するように（つまり、コンピュータの負荷が高いときに成立するように）、予め適切に定義される。具体的には、判定条件は、プロセッサが１つ以上の特定の処理のそれぞれを実行するのにかかる時間に関する条件である。なお、ここでの「時間」は、より具体的には、ＣＰＵ時間ではなく実時間のことである。
【００６２】
換言すれば、ステップＳ１０２では、メモリ割り当ての成功または失敗の蓋然性についての判定結果が得られる。当該判定結果は、上記のとおり、プロセッサが１つ以上の特定の処理のそれぞれを実行するのにかかる時間に基づく。上記判定条件が真のとき、判定結果は、メモリ割り当てが失敗する蓋然性が高いことを示す。逆に、上記判定条件が偽のとき、判定結果は、メモリ割り当てが成功する蓋然性が高いことを示す。
【００６３】
コンピュータの負荷が高いほど、特定の処理をプロセッサが実行するのにかかる時間が長い。よって、プロセッサが１つ以上の特定の処理のそれぞれを実行するのにかかる時間に関する条件が、メモリ割り当てに失敗する見込みの高さを判断するための判定条件として利用可能である。なお、判定条件のより具体的な例については後述する。
【００６４】
判定条件が成立しなければ、処理はステップＳ１０３に移行する。すなわち、判定結果が、メモリ割り当てが成功する蓋然性が高いことを示す場合、処理はステップＳ１０３に移行する。
【００６５】
逆に、判定条件が成立すれば、処理はステップＳ１０５に移行する。すなわち、判定結果が、メモリ割り当てが失敗する蓋然性が高いことを示す場合、処理はステップＳ１０５に移行する。
【００６６】
ステップＳ１０３でプロセッサは、ステップＳ１０１で受け付けたメモリ割り当ての要求に応じて、メモリ割り当てを試みる。続いて、次のステップＳ１０４でプロセッサは、ステップＳ１０３でメモリ割り当てを試みた結果を返す。そして、フローチャートＦ１の処理は終了する。
【００６７】
他方、ステップＳ１０５でプロセッサは、決められた時間だけ待つ。そして、決められた時間が経過すると、処理はステップＳ１０３に移行する。つまり、メモリ割り当てが成功する蓋然性が高いことを示す場合に実行されるメモリ割り当ての試みに対して、遅延させてメモリ割り当てを試みるための制御の一例が、ステップＳ１０５に示されている。当該制御における遅延時間は、上記の「決められた時間」である。
【００６８】
さて、図１のフローチャートＦ１とＦ２において、ステップＳ１０１〜Ｓ１０４は共通である。違いは、判定条件が成立する場合の動作である。フローチャートＦ２の処理では、判定条件が成立する場合、処理がステップＳ１０２からステップＳ１０６へと移行する。
【００６９】
そして、ステップＳ１０６でプロセッサは、メモリ割り当ての要求に対して割り当て失敗という結果を返す。すなわち、ステップＳ１０６でプロセッサは、メモリ割り当てを試みずにメモリ割り当て失敗の旨の応答を行う。
【００７０】
以上のフローチャートＦ１とＦ２に示したメモリ割り当て制御方法のいずれによっても、判定条件が適切に定められていれば、メモリ割り当てを試みる処理自体に起因する効率悪化、ストール、ハングなどの問題を防ぐことができる。なぜなら、「メモリ割り当てがどのような条件下で要求されようとも常にメモリ割り当てがすぐに試みられる」というわけではないからである。つまり、メモリ割り当ての試みは、場合に応じて、適宜、延期または防止される。
【００７１】
フローチャートＦ１によれば、判定条件が成立する状況下では、メモリ割り当てが要求されても、すぐにメモリ割り当てが試みられるのではなく、決められた時間が経過した後でメモリ割り当てが試みられる。例えば、決められた時間が経過するまでに、ディスクＩＯのためにＯＳにより一時的に使われていたバッファ領域が解放されて使用可能になる可能性がある。よって、メモリ割り当ての試みを延期することで、メモリ割り当てが成功する確率が高まることがある。
【００７２】
また、フローチャートＦ２によれば、判定条件が成立する状況下では、たとえメモリ割り当てが要求されようとも、メモリ割り当ては試みられず、失敗という結果が返される。メモリ割り当て自体が試みられなければ、当然、メモリ割り当ての試みに起因する問題も生じない。
【００７３】
つまり、メモリ割り当てを試みる処理自体がコンピュータの効率を悪化させかねないような状況を示すように、判定条件が適切に定められていれば、当該状況下では、メモリ割り当てを試みる処理が防止または延期される。その結果、メモリ割り当てを試みる処理の実行に起因する、コンピュータの効率悪化、ストール、ハングなどの問題は回避される。このように、第１実施形態によれば、適切にメモリ割り当てが制御される。
【００７４】
ところで、上記のフローチャートＦ１とＦ２のいずれに関しても、処理の詳細は様々に変形可能である。以下に、処理の詳細に関して、いくつかの観点から、例を示す。
例えば、フローチャートＦ１またはＦ２の処理をプロセッサに実行させるためのプログラムコードは、アプリケーションプログラム、ライブラリ関数、システムコール（換言すればカーネル関数）、フック関数などの様々なレベルに実装され得る。
【００７５】
例えば、アプリケーションプログラムが、メモリ割り当てのためのライブラリ関数またはシステムコールを呼び出す第１のコードと、第１のコードを呼び出す第２のコードを含んでいてもよい。第１のコードは、メモリ割り当てのために当該アプリケーションで使われるラッパ（wrapper）である。
【００７６】
例えば、第１のコードは、アプリケーションのサブルーチンのコードであってもよい。その場合、第２のコードは、アプリケーション内から当該サブルーチンを呼び出すコードである。具体的には、第２のコードは、アプリケーションのメインルーチンのコードであってもよいし、第１のコードとは別のサブルーチンのコードであってもよい。
【００７７】
あるいは、第１のコードは何らかのクラスのコンストラクタであってもよい。その場合、第２のコードは、明示的または暗黙的に当該コンストラクタを呼び出すステートメントである。
【００７８】
そして、上記のような第１と第２のコードを含むアプリケーションプログラムをプロセッサが実行すると、フローチャートＦ１またはＦ２の処理が以下のようにして実現される。
【００７９】
プロセッサが、第２のコードの実行の過程において第２のコードからの第１のコードの呼び出しを実行することにより、メモリ割り当ての要求が発行される。そして、第２のコードからの第１のコードの呼び出しにより、プロセッサは第１のコードの実行を開始する。
【００８０】
ここで、プロセッサは、呼び出された第１のコードの実行を開始することにより、ステップＳ１０１のようにメモリ割り当ての要求を受け付ける。つまり、第１のコードは、フローチャートＦ１またはＦ２の動作を記述したコードである。
【００８１】
したがって、ステップＳ１０３の動作は、具体的には次のようにして実現される。すなわち、プロセッサは、第２のコードから呼び出された第１のコードの実行の過程において、ライブラリ関数またはシステムコールを呼び出すことにより、ステップＳ１０３でメモリ割り当てを試みる。
【００８２】
また、ステップＳ１０４では、ライブラリ関数またはシステムコールからの返り値（または当該返り値から第１のコードにしたがって生成される返り値）が、第１のコードから第２のコードへと返される。例えば、メモリ割り当てが成功した場合は、割り当てられたメモリ領域の先頭を指すポインタが、ステップＳ１０４で返されてもよい。
【００８３】
また、ステップＳ１０３でメモリ割り当てが失敗したときには、ステップＳ１０４でＮＵＬＬポインタが返されてもよいし、さらに、エラーコードを示す「ｅｒｒｎｏ」などの所定の変数に所定の値が設定されてもよい。あるいは、ステップＳ１０３でメモリ割り当てが失敗したときには、ステップＳ１０４で例外が投げられて（thrown）もよい。その場合、第２のコードは、例外をつかまえる（catch）ためのコードを含む。
【００８４】
同様に、ステップＳ１０６では、割り当て失敗という結果が、第１のコードから第２のコードへと返される。例えば、ステップＳ１０６では例外が投げられてもよい。または、ステップＳ１０６の処理は、ＮＵＬＬポインタを返すとともに、エラーコードを示す所定の変数に所定の値を設定する処理であってもよい。
【００８５】
あるいは、フローチャートＦ１またはＦ２の動作は、具体的には、メモリ割り当てのためのライブラリ関数またはシステムコールのレベルにおいて実装されてもよい。
例えば、プロセッサは、メモリ割り当てのためのライブラリ関数またはシステムコールを呼び出すアプリケーションプログラムを実行してもよい。すると、プロセッサは、アプリケーションプログラムの実行の過程において、ライブラリ関数またはシステムコールを呼び出す。
【００８６】
この呼び出しにより、メモリ割り当ての要求が発行される。また、この呼び出しにより、プロセッサは、ライブラリ関数またはシステムコールの実行を開始する。そして、プロセッサは、呼び出されたライブラリ関数またはシステムコールの実行を開始することにより、ステップＳ１０１のようにメモリ割り当ての要求を受け付ける。
【００８７】
また、ステップＳ１０４では、ステップＳ１０３におけるメモリ割り当ての試みの結果が、呼び出されたライブラリ関数またはシステムコールから、呼び出し元（caller）のアプリケーションプログラムに返される。同様に、ステップＳ１０６では、割り当て失敗という結果が、呼び出されたライブラリ関数またはシステムコールから、呼び出し元のアプリケーションプログラムに返される。
【００８８】
例えば、上記の例と同様に、ステップＳ１０４では、メモリ領域の先頭を指すポインタまたはＮＵＬＬポインタが、アプリケーションプログラムに返されてもよい。また、ステップＳ１０６では、ＮＵＬＬポインタが返されてもよいし、例外が投げられてもよい。さらに、ステップＳ１０６では、エラーコードを示す所定の変数に所定の値が設定されてもよい。
【００８９】
あるいは、メモリ割り当てのためのライブラリ関数またはシステムコールをフックする、フック関数が定義されていてもよい。そして、フローチャートＦ１またはＦ２の動作は、具体的には、当該フック関数に記述されていてもよい。
【００９０】
例えば、プロセッサは、メモリ割り当てのためのライブラリ関数またはシステムコールの呼び出しを含むアプリケーションプログラムを実行してもよい。すると、プロセッサは、アプリケーションプログラムの実行の過程においてライブラリ関数またはシステムコールを呼び出す。
【００９１】
この呼び出しはフックされ、プロセッサはフック関数の実行を開始する。なお、（２−１）と（２−２）のどちらの観点から見ても、プロセッサがフローチャートＦ１またはＦ２にしたがって動作することは同じである。
【００９２】
（２−１）プロセッサは、ライブラリ関数またはシステムコールの実行を開始することにより、ステップＳ１０１でメモリ割り当ての要求を受け付ける。続いて、プロセッサは、フック関数の実行を開始する。
（２−２）プロセッサは、フック関数の実行を開始することで、フック関数の内部において、ステップＳ１０１のようにメモリ割り当ての要求を受け付ける。
【００９３】
また、ステップＳ１０２以降の処理は、（２−１）と（２−２）のどちらの観点でも共通である。具体的には、プロセッサは、フック関数を実行することにより、判定条件が成立するか否かをステップＳ１０２で判断する。
【００９４】
もし判定条件が成立しなければ、プロセッサは、フック関数から本来のライブラリ関数またはシステムコールに制御を戻す。そして、プロセッサは、アプリケーションプログラムから呼ばれた本来のライブラリ関数またはシステムコールを実行することにより、ステップＳ１０３でメモリ割り当てを試みる。その後、ステップＳ１０４では、メモリ割り当てが成功したか否かを示す結果（例えば上記の例と同様のポインタ）が、アプリケーションプログラムに返される。
【００９５】
逆に、判定条件が成立する場合は、プロセッサは、フローチャートＦ１にしたがって、決められた時間だけステップＳ１０５で待ってから、フック関数から本来のライブラリ関数またはシステムコールに制御を戻してもよい。その後のステップＳ１０３とＳ１０４の処理は、判定条件が成立しない場合と同様である。あるいは、判定条件が成立する場合にプロセッサは、フローチャートＦ２にしたがって、割り当て失敗という結果をステップＳ１０６でフック関数から返してもよい。
【００９６】
ところで、上記のとおり、ステップＳ１０２の判定条件は、プロセッサが１つ以上の特定の処理のそれぞれを実行するのにかかる時間に関する条件である。例えば、上記の「１つ以上の特定の処理」は、下記（３−１）と（３−２）の処理のうち、少なくとも一方を含んでいてもよい。
【００９７】
（３−１）メモリの使用量または使用率を示す値を、ステップＳ１０１で要求を受け付けた後に取得する処理。
（３−２）プロセッサの負荷を示す値（例えばＣＰＵ使用率）を、ステップＳ１０１で要求を受け付けた後に取得する処理。
【００９８】
上記の（３−１）と（３−２）の処理は、具体的には、ＯＳにより提供されるコマンドをプロセッサが実行する処理であってもよい。例えば、「ｔｏｐ」コマンド、「ｖｍｓｔａｔ」コマンド、「ｆｒｅｅ」コマンド、「ｕｐｔｉｍｅ」コマンドなどが利用可能である。あるいは、（３−１）と（３−２）の処理は、これらのコマンドの内部から呼ばれるシステムコールを実行する処理であってもよい。
【００９９】
例えば、（３−１）の処理の結果、メモリの使用率が高いことが判明したとし、さらに、（３−２）の処理の結果、ＣＰＵ使用率も高いことが判明したとする。その場合、明らかにコンピュータは高負荷状況にある。
【０１００】
また、（３−１）の処理や（３−２）の処理をプロセッサが実行するのにかかる時間も、コンピュータの負荷の状況の指標になり得る。例えば、コンピュータ全体の負荷が高いときにプロセッサがあるコマンドを実行するのにかかる時間は、コンピュータ全体の負荷が低いときにプロセッサが同じコマンドを実行するのにかかる時間よりも長い。
【０１０１】
そこで、ステップＳ１０２の判定条件は、以下の（４−１）〜（４−３）の条件の組み合わせにより示されてもよい。
【０１０２】
（４−１）上記の「１つ以上の特定の処理」に含まれる各特定の処理について、当該特定の処理をプロセッサが実行するのにかかる時間が、当該特定の処理に応じて決められた第１の閾値より長い。
（４−２）メモリの使用量または使用率が第２の閾値を超えている。
（４−３）プロセッサの負荷が第３の閾値を超えている。
【０１０３】
具体的には、判定条件は、（４−１）の条件と、（４−２）の条件と（４−３）の条件の論理積との、論理和であってもよい。その場合、判定条件は、形式的には以下のように定義される。
【０１０４】
まず、式（１）のように、１つ以上の特定の処理の集合を「Ｐ」とする。式（１）において１≦Ｎである。
【０１０５】
【数１】
2013051154.tif 000003
【０１０６】
また、集合Ｐに属する１つの特定の処理ｐｊ（１≦ｊ≦Ｎ）をプロセッサが実行するのにかかる時間を、「ｔ（ｐｊ）」とする。すると、（４−１）の条件は、閾値Ｔ１からＴＮを用いて、式（２）の条件Ｃ１のように表せる。なお、閾値Ｔ１からＴＮは、互いに異なっていてもよいし、同じ値であってもよい。
【０１０７】
【数２】
2013051154.tif 000004
【０１０８】
そして、（３−１）の処理から判明するメモリの使用量を「ｍ」とし、メモリの使用量に関する閾値を「Ｍ」とする。あるいは、（３−１）の処理から判明するメモリの使用率を「ｍ」とし、メモリの使用率に関する閾値を「Ｍ」とする。すると、（４−２）の条件は、式（３）の条件Ｃ２のように表せる。
【０１０９】
【数３】
2013051154.tif 000005
【０１１０】
また、（３−２）の処理から判明するプロセッサの負荷を「ｕ」とし、プロセッサの負荷に関する閾値を「Ｕ」とする。すると、（４−３）の条件は、式（４）の条件Ｃ３のように表せる。
【０１１１】
【数４】
2013051154.tif 000006
【０１１２】
そして、図１のステップＳ１０２の判定条件は、式（２）〜（４）の条件Ｃ１〜Ｃ３を用いて式（５）のように表される条件Ｃであってもよい。
【０１１３】
【数５】
2013051154.tif 000007
【０１１４】
なお、式（５）に示すように判定条件Ｃに関しては条件Ｃ２と条件Ｃ３の論理積が使われる。つまり、条件Ｃ２と条件Ｃ３の双方が成立するか否かが判断される。他方、上記の「１つ以上の特定の処理」は、必ずしも（３−１）と（３−２）の処理を双方とも含む必要はなく、少なくとも一方を含んでいれば十分である。その理由は、以下のとおりである。
【０１１５】
メモリの使用量または使用率が低ければ、メモリ割り当ての試みは、ＣＰＵの負荷によっては時間がかかるかもしれないが、成功する見込みが高い。また、ＣＰＵの負荷が低ければ、ＯＳによって一時的に使われているメモリを解放するための処理が順調に進捗すると予測されるので、メモリ割り当ての試みが成功する見込みは高い。よって、条件Ｃ２と条件Ｃ３の一方だけが成立しても、「メモリ割り当ての試みが失敗する見込みが高い」とは言えない。
【０１１６】
他方、「プロセッサがある１つの処理を実行するのにかかる時間が、当該処理を実行するのにかかる標準的な時間と比べて随分と長い」という事実は、コンピュータ全体が高負荷状態に陥っていることを示唆するのに十分な証拠たり得る。したがって、上記の「１つ以上の特定の処理」は、（３−１）と（３−２）の処理の少なくとも一方を含んでいれば十分である。
【０１１７】
もちろん、上記の「１つ以上の特定の処理」が（３−１）と（３−２）の処理の双方を含むことは、好ましい。なぜなら、コンピュータ全体が高負荷状態に陥っているか否かを示す証拠の数が増えるので、図１のステップＳ１０２における判断が一層正確になるからである。
【０１１８】
ところで、上記の「１つ以上の特定の処理」は、（３−１）または（３−２）の処理を含むのではなく、所定範囲内の過去にメモリに対する割り当て要求に応じてプロセッサがメモリ割り当てを試みた処理を含んでいてもよい。この場合、判定条件は、「プロセッサがメモリ割り当てを所定範囲内の過去において試みたときに結果を得るのにかかった時間が、閾値より長い」という条件であってもよいし、当該条件と他の何らかの条件との論理和であってもよい。
【０１１９】
例えば、式（１）においてＮ＝１の場合に、判定条件Ｃは、式（２）の条件Ｃ１であってもよい。つまり、Ｎ＝１の場合に、判定条件Ｃは、式（６）のとおりであってもよい。この場合、唯一の特定の処理ｐ１は、所定範囲内の過去にメモリに対する割り当て要求に応じてプロセッサがメモリ割り当てを試みた処理である。
【０１２０】
【数６】
2013051154.tif 000008
【０１２１】
あるいは、Ｎの値によらず、判定条件Ｃは式（７）のとおりであってもよい。なお、式（７）における特定の処理ｐ１は、所定範囲内の過去にメモリに対する割り当て要求に応じてプロセッサがメモリ割り当てを試みた処理であるものとする。
【０１２２】
【数７】
2013051154.tif 000009
【０１２３】
また、式（７）における条件Ｃ４は、任意の条件であってよい。例えば、１＜Ｎの場合、条件Ｃ４は、残りの特定の処理ｐ２〜ｐＮをプロセッサが実行するのにそれぞれかかる時間ｔ（ｐ２）〜ｔ（ｐＮ）の関数であってもよい。
【０１２４】
なお、所定範囲内の過去にメモリに対する割り当て要求に応じてプロセッサがメモリ割り当てを試みた処理が、「特定の処理」として扱われる場合、図１のステップＳ１０５における「決められた時間」の長さは、「所定範囲」の長さ以上であることが好ましい。理由は以下のとおりである。
【０１２５】
式（６）または式（７）の条件Ｃが適切な判定条件であるためには、「所定範囲」の長さは、コンピュータ全体の負荷の状況が大きく変わらない程度の長さであることが望ましい。換言すれば、「所定範囲」は、あまり長くないことが望ましい。
【０１２６】
判定条件Ｃは、「メモリ割り当てを仮に現時点でプロセッサが試みたとすると、試みが失敗する見込みが高いか否か」を推測するための条件なので、あまり古いデータが判定条件Ｃに使われることは好ましくない。よって、「所定範囲」は、あまり長くないことが望ましい。
【０１２７】
他方、ステップＳ１０５における「決められた時間」は、ある程度長いことが望ましい。なぜなら、ステップＳ１０５の処理の目的は、メモリ割り当ての試みが失敗しそうなほどの非常に高い負荷が、メモリ割り当ての試みが成功する見込みが十分にありそうな程度の負荷にまで減少するまで、メモリ割り当ての試みを延期することだからである。「決められた時間」は、この目的を達するように、ある程度長く設定されることが好ましい。
【０１２８】
このように、「所定範囲」は、あまり長くないことが望ましく、「決められた時間」は、ある程度長いことが望ましい。よって、「決められた時間」は、「所定範囲」以上に長いことが望ましい。
【０１２９】
以上の説明は、以下のように換言することもできる。
ステップＳ１０２からステップＳ１０５に処理が移行するのは、現時点でのメモリ割り当ての試みの成否の推測に役立つほどの近い過去に、メモリ割り当ての試みが失敗している場合である。この場合に、もしステップＳ１０５での待ち時間が当該失敗から現在までの経過時間より短い時間しかなければ、そのような短時間では、コンピュータ全体の負荷が十分に軽減される見込みは薄い。したがって、ステップＳ１０５の後のステップＳ１０３での試みは失敗する可能性が高い。
【０１３０】
つまり、「所定範囲」より短いような待ち時間は、無駄な資源消費を抑制するには不十分な長さである場合が多い。よって、高負荷状況下での無駄な資源消費を抑制し、メモリ割り当ての試みが成功する可能性を高めるためには、ステップＳ１０５の「決められた時間」は、「所定範囲」以上であるような十分な長さに設定されることが好ましい。
【０１３１】
ところで、上記の「１つ以上の特定の処理」は、式（１）のＮに関して１≦α≦β≦Ｎを満たす適宜のαとβを用いて、以下のように決められていてもよい。具体的には、「１つ以上の特定の処理」は、過去にプロセッサが実行した複数回のメモリ割り当ての試みのうち、現在に近い方からβ回の試みを含んでもよい。
【０１３２】
例えば、簡単のため、β＝Ｎとすると、判定条件は、「上記のβ回の試みのうち少なくともα回の試みのそれぞれにおいて、プロセッサが結果を得るのにかかった時間が閾値より長かった」という条件であってもよい。例えば、α＝２かつβ＝３の場合は、判定条件Ｃは、３入力の多数決関数ｆと閾値Ｔを用いて式（８）のように表される。
【０１３３】
【数８】
2013051154.tif 000010
【０１３４】
なお、過去にプロセッサがメモリ割り当てを試みた処理が「特定の処理」として扱われる場合、プロセッサが特定の処理を実行するのにかかった時間とは、換言すれば、メモリ割り当ての試みが成功したか否かが判明するのにかかった時間である。ここで、当該時間と比較される上記の閾値（例えば、式（６）もしくは（７）における閾値Ｔ１、または式（８）における閾値Ｔ）は、プロセッサが過去にメモリ割り当てを試みたときの、要求されたメモリサイズに応じた値であってもよい。なぜなら、要求されたメモリサイズに応じて、メモリ割り当てを試みる処理にかかる時間が異なることがあるからである。
【０１３５】
例えば、要求されたメモリサイズが非常に大きければ、割り当て可能なメモリ領域を探索するために比較的長い時間がかかるかもしれない。すると、たとえ割り当て自体は１回の試みで成功するとしても、プロセッサがメモリ割り当てを試みて、割り当てに成功するまでにかかる時間は、比較的長いかもしれない。
【０１３６】
他方、小さなサイズのメモリの割り当てが要求された場合は、探索も短時間で済むことが多い。よって、プロセッサがメモリ割り当てを試みて、割り当てに成功するまでにかかる平均的な時間は、比較的短い。
したがって、メモリサイズに応じた閾値が使われてもよい。
【０１３７】
ところで、プロセッサは、ステップＳ１０３でメモリ割り当てを試みた結果、メモリ割り当てに成功すれば、ステップＳ１０４で割り当て成功という結果を返す。また、プロセッサは、ステップＳ１０３でメモリ割り当てを試みた結果、メモリ割り当てに失敗した場合には、単純にステップＳ１０４のように結果を返してもよいが、その代わりに、次の（５−１）〜（５−３）のように場合に応じて異なる動作をしてもよい。
【０１３８】
（５−１）メモリ割り当ての試みが失敗したことが判明するのにかかった時間が閾値より長ければ、プロセッサがステップＳ１０４で割り当て失敗という結果を返す。
（５−２）メモリ割り当ての試みが失敗したことが判明するのにかかった時間が閾値より短く、かつ、メモリ割り当てを試みた回数が所定の回数に達していなければ、プロセッサがメモリ割り当てを再度試みる。
（５−３）メモリ割り当てを試みた回数が所定の回数に達してもなお、メモリ割り当てに成功しなければ、プロセッサが割り当て失敗という結果を返す。
【０１３９】
なお、単にメモリ割り当ての試みが失敗するだけでなく、メモリ割り当ての試みが失敗したという結果が判明するのにすら長い時間がかかるということは、コンピュータ全体の負荷が非常に高いことの証左である。よって、（５−１）と（５−２）のように、時間の長さに応じてプロセッサが動作してもよい。
【０１４０】
あるいは、プロセッサは、ステップＳ１０３でメモリ割り当てを試みた結果、メモリ割り当てに失敗した場合に、次の（６−１）〜（６−２）のように動作してもよい。
【０１４１】
（６−１）メモリ割り当てを試みた回数が所定の回数に達していなければ、プロセッサがメモリ割り当てを再度試みる。
（６−２）メモリ割り当てを試みた回数が所定の回数に達してもなお、メモリ割り当てに成功しなければ、プロセッサが割り当て失敗という結果を返す。
【０１４２】
なお、プロセッサは、（５−２）や（６−１）のような再度の試みを実行する前に、適宜の時間待つことが好ましい。
【０１４３】
続いて、図１のフローチャートＦ１またはＦ２にしたがって動作するコンピュータの構成について説明する。図２は、第１実施形態のコンピュータのブロック構成図である。
図２のコンピュータ１００は、情報処理装置の一種である。コンピュータ１００は、メモリ１０１と、プログラム実行部１０２と、特定処理実行部１０３と、要求受付部１０４と、判断部１０５と、メモリ割り当て制御部１０６を有する。また、コンピュータ１００は、判断部１０５が用いる１つ以上のパラメタ１０７を記憶している。
【０１４４】
メモリ１０１は、例えばＤＲＡＭであってもよい。
プログラム実行部１０２は、メモリ１０１上に動的に割り当てられる領域を用いて、プログラムを実行する。プログラム実行部１０２が実行するプログラムは、例えば、ユーザアプリケーションであってもよく、当該プログラムは、メモリ割り当てを要求するためのコードを含む。
【０１４５】
特定処理実行部１０３は、プログラム実行部１０２が実行する上記プログラムとは別のプログラムによる、１つ以上の特定の処理を実行する。なお、「１つ以上の特定の処理」については、図１のステップＳ１０２の判定条件に関して説明したとおりである。
【０１４６】
例えば、上記（３−１）の処理が特定の処理である場合、特定処理実行部１０３は、（３−１）の処理を実行する。例えば、特定処理実行部１０３は、所定のコマンドまたはシステムコールを実行することで、（３−１）の処理を実行してもよい。
【０１４７】
あるいは、上記（３−２）の処理が特定の処理である場合、特定処理実行部１０３は、（３−２）の処理を実行する。例えば、特定処理実行部１０３は、所定のコマンドまたはシステムコールを実行することで、（３−２）の処理を実行してもよい。
【０１４８】
または、上記のように、所定範囲内の過去にメモリに対する割り当て要求に応じてプロセッサがメモリ割り当てを試みた処理が、特定の処理であることもある。この場合、特定処理実行部１０３は、メモリ割り当てのためのライブラリ関数またはシステムコールを実行することで、特定の処理を実行してもよい。
【０１４９】
要求受付部１０４は、図１のステップＳ１０１で、プログラム実行部１０２からメモリ割り当ての要求を受け付ける。
そして、判断部１０５は、判定条件が成立するか否かをステップＳ１０２において判断する。判定条件は、上記のとおり、１つ以上の特定の処理のそれぞれを特定処理実行部１０３が実行するのにかかる時間に関する条件である。換言すれば、判断部１０５は、メモリ割り当ての成功または失敗の蓋然性についての判定結果を得る。
【０１５０】
また、判断部１０５による判断は、１つ以上のパラメタ１０７に基づく。パラメタ１０７の例は、例えば、式（２）〜（４）および（６）〜（８）中の閾値である。
メモリ割り当て制御部１０６は、判断部１０５による判断結果に応じて動作する。なお、図２では判断部１０５とメモリ割り当て制御部１０６を分けて図示しているが、メモリ割り当て制御部１０６が判断部１０５を含んでいてもよい。
【０１５１】
具体的には、判定条件が成立しない場合、メモリ割り当て制御部１０６は、メモリ割り当ての要求に応じてステップＳ１０３でメモリ割り当てを試み、ステップＳ１０４で結果を返す。
【０１５２】
逆に、判定条件が成立する場合、メモリ割り当て制御部１０６は、フローチャートＦ１にしたがってステップＳ１０５で決められた時間だけ待ってから、ステップＳ１０３でメモリ割り当てを試みる。すなわち、ステップＳ１０２での判定結果が、メモリ割り当てが失敗する蓋然性が高いことを示す場合、メモリ割り当て制御部１０６は、遅延させたメモリ割り当ての試みを実行する。
【０１５３】
あるいは、判定条件が成立する場合、メモリ割り当て制御部１０６は、フローチャートＦ２にしたがって、メモリ割り当ての要求に対して、ステップＳ１０６で割り当て失敗という結果を返す。すなわち、ステップＳ１０２での判定結果が、メモリ割り当てが失敗する蓋然性が高いことを示す場合、メモリ割り当て制御部１０６は、メモリ割り当てを試みずにメモリ割り当て失敗の旨の応答を行う。
【０１５４】
メモリ割り当てが成功したか否かという結果は、メモリ割り当て制御部１０６からプログラム実行部１０２へと返される。もしメモリ割り当てが成功すれば、プログラム実行部１０２は、割り当てられたメモリ１０１上の領域を使ってプログラムを実行する。
【０１５５】
なお、図２では、メモリ割り当て制御部１０６と特定処理実行部１０３の間および特定処理実行部１０３とメモリ１０１の間が破線で結ばれている。また、メモリ割り当て制御部１０６とメモリ１０１の間が１点鎖線で結ばれている。この線の種類の違いは、「特定の処理」の違いを示す。
【０１５６】
つまり、メモリ割り当てを試みる処理自体が特定の処理である場合は、メモリ割り当て制御部１０６は、ステップＳ１０３で特定処理実行部１０３を呼び出すことによって、メモリ割り当てを試みる。そして、メモリ割り当てのための実際の具体的な処理（例えば、割り当て可能なメモリ領域を探索する処理）は、特定処理実行部１０３が行う。また、メモリ割り当ての試みが成功したか否かという結果は、特定処理実行部１０３からメモリ割り当て制御部１０６へと返される。したがって、メモリ割り当て制御部１０６は、特定処理実行部１０３から返された結果を、ステップＳ１０４でプログラム実行部１０２に返す。
【０１５７】
逆に、メモリ割り当てを試みる処理自体が特定の処理ではない場合、メモリ割り当て制御部１０６自体が、ステップＳ１０３でメモリ割り当てのための実際の具体的な処理を行ってもよい。または、メモリ割り当て制御部１０６は、メモリ割り当てのためのシステムコールを呼び出すことによって、ステップＳ１０３でメモリ割り当てを試みてもよい。この場合、図２には不図示のシステムコール実行部が、メモリ割り当て制御部１０６からの呼び出しに応じて、メモリ割り当てのための実際の具体的な処理を実行してもよい。
【０１５８】
ところで、図２のコンピュータ１００は、具体的には、例えば図３に示すハードウェアにより実現されてもよい。図３は、第１〜第３実施形態に共通のコンピュータのハードウェア構成図である。
【０１５９】
図３のコンピュータ２００は、ＣＰＵ２０１、ＲＡＭ（Random Access Memory）２０２、ＲＯＭ（Read Only Memory）２０３、通信インタフェイス２０４、入力装置２０５、出力装置２０６、記憶装置２０７、および記憶媒体２１０の駆動装置２０８を有する。また、コンピュータ２００中のこれらのコンポーネントは、バス２０９に接続されている。
【０１６０】
ＣＰＵ２０１は、プログラムをＲＡＭ２０２にロードし、ＲＡＭ２０２をワーキングエリアとしても使用しながら、プログラムを実行する。なお、図３には１つのＣＰＵ２０１のみが図示されているが、コンピュータ２００は、複数のＣＰＵ２０１を含むマルチプロセッサシステムであってもよい。
【０１６１】
ＲＡＭ２０２は、例えばＤＲＡＭであってもよい。また、ＣＰＵ２０１にＭＭＵが内蔵されていてもよい。あるいは、ＣＰＵ２０１の外部にＭＭＵがあってもよく、ＲＡＭ２０２は、ＭＭＵを介してバス２０９に接続されていてもよい。ＲＯＭ２０３は、例えば、フラッシュメモリなどのＥＥＰＲＯＭ（Electrically Erasable Programmable Read-Only Memory）であってもよい。
【０１６２】
なお、ＣＰＵ２０１が実行するプログラムは、予めＲＯＭ２０３または記憶装置２０７に記憶されていてもよい。記憶装置２０７は、例えばＨＤＤ（Hard Disk Drive）であってもよい。
【０１６３】
あるいは、プログラムは、プログラム提供者２１２により提供され、ネットワーク２１１と通信インタフェイス２０４を介してコンピュータ２００にダウンロードされ、記憶装置２０７に記憶されてもよい。プログラム提供者２１２は、例えば他のコンピュータである。
【０１６４】
また、プログラムは、コンピュータ読み取り可能な可搬型の記憶媒体２１０に記憶されて提供されてもよい。プログラムは、駆動装置２０８にセットされた記憶媒体２１０から、駆動装置２０８により読み取られる。読み取られたプログラムは、その後、一旦記憶装置２０７にコピーされてからＲＡＭ２０２にロードされてもよいし、直接ＲＡＭ２０２にロードされてもよい。記憶媒体２１０としては、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）などの光ディスク、光磁気ディスク、磁気ディスク、不揮発性の半導体メモリカードなどが利用可能である。
【０１６５】
通信インタフェイス２０４は、例えば、有線ＬＡＮ（Local Area Network）インタフェイス装置、無線ＬＡＮインタフェイス装置、または、両者の組み合わせである。また、入力装置２０５は、例えば、キーボード、マウスやタッチスクリーンなどのポインティングデバイス、マイク、またはそれらの組み合わせである。出力装置２０６は、例えば、ディスプレイ、スピーカ、またはそれらの組み合わせである。ディスプレイは、タッチスクリーンであってもよい。
【０１６６】
また、ＲＡＭ２０２、ＲＯＭ２０３、記憶装置２０７、および記憶媒体２１０は、いずれも、コンピュータ読み取り可能な記憶媒体の例である。これらのコンピュータ読み取り可能な記憶媒体は、有形の（tangible）記憶媒体であり、信号搬送波のような一時的な（transitory）媒体ではない。
【０１６７】
なお、図２と図３の関係は以下のとおりである。
図２のメモリ１０１は図３のＲＡＭ２０２に対応する。図２のプログラム実行部１０２、特定処理実行部１０３、要求受付部１０４、判断部１０５、およびメモリ割り当て制御部１０６は、図３のＣＰＵ２０１がプログラムを実行することで実現される。
【０１６８】
また、図２のパラメタ１０７は、図３のＲＡＭ２０２に記憶される。より具体的には、パラメタ１０７は、例えば、ＲＯＭ２０３、記憶装置２０７、または記憶媒体２１０に、プログラムとともに予め記憶されていてもよく、その後、ＲＡＭ２０２に読み込まれてもよい。
【０１６９】
あるいは、パラメタ１０７は、プログラム提供者２１２から、ネットワーク２１１と通信インタフェイス２０４を介してプログラムとともにダウンロードされてもよく、その後、ＲＡＭ２０２に読み込まれてもよい。または、入力装置２０５から与えられる指示に応じて、ＲＡＭ２０２上にパラメタ１０７が設定されてもよい。
【０１７０】
続いて、第２実施形態について図４〜１０を参照して説明する。図４は、第２実施形態と第３実施形態に共通のコンピュータのブロック構成図である。
図４のコンピュータ３００は、具体的には図３のコンピュータ２００により実現されてもよい。図４では、コンピュータ３００が有するコンポーネントが、アプリケーション３０１とＯＳ３０２とハードウェア３０３の３つの層に分かれて図示されている。なお、第２実施形態におけるアプリケーション３０１は、コンピュータ３００の性能を試験するためのシステム試験プログラムである。また、ハードウェア３０３は、具体的には、図３に示した各種のハードウェア装置を含む。
【０１７１】
そして、アプリケーション３０１の層には、システム試験部３０４がある。システム試験部３０４は、ＣＰＵ２０１がアプリケーション３０１を実行することにより実現される。より詳しくは、システム試験部３０４は、試験制御部３０５と、ＣＰＵ試験実行部３０６と、メモリ試験実行部３０７と、ディスク試験実行部３０８と、ネットワーク試験実行部３０９と、情報取得部３１０と、メモリ取得部３１１を含む。システム試験部３０４内の各部の動作の詳細は、フローチャートとともに後述する。
【０１７２】
また、アプリケーション３０１の層には、システム試験部３０４が使用する管理表３１２と定数データ３１３がある。管理表３１２と定数データ３１３の第２実施形態における具体例は、図６とともに後述する。
【０１７３】
管理表３１２は、ＣＰＵ２０１がアプリケーション３０１を実行することにより、図３のＲＡＭ２０２上に生成される。他方、定数データ３１３は、例えば、ＲＯＭ２０３、記憶装置２０７、または記憶媒体２１０に、プログラムとともに予め記憶されていてもよく、その後、ＲＡＭ２０２に読み込まれてもよい。
【０１７４】
あるいは、定数データ３１３は、プログラム提供者２１２から、ネットワーク２１１と通信インタフェイス２０４を介してプログラムとともにダウンロードされてもよく、その後、ＲＡＭ２０２に読み込まれてもよい。または、定数データ３１３は、ユーザ定義可能であってもよい。つまり、入力装置２０５からの入力に応じて、定数データ３１３が設定され、ＲＡＭ２０２に記憶されてもよい。
【０１７５】
また、ＯＳ３０２の層には、ＣＰＵ負荷測定部３１４と、メモリ使用量測定部３１５と、時間測定部３１６と、メモリ取得・解放部３１７と、カーネル３１８と、ドライバ３１９がある。
【０１７６】
ＣＰＵ負荷測定部３１４とメモリ使用量測定部３１５は、ＯＳ３０２により提供される所定のコマンド（例えば「ｔｏｐ」コマンド）システムコールをＣＰＵ２０１が実行することにより、実現される。
【０１７７】
時間測定部３１６は、プロセスの開始時刻と終了時刻を取得して、プロセスの実行にかかる時間の長さを測定する。時間測定部３１６による時刻取得機能は、例えば、現在時刻を取得するためのライブラリ関数またはシステムコールをＣＰＵ２０１が実行することにより、実現されてもよい。
【０１７８】
なお、時間測定部３１６は十分に細かい時間分解能を持つものとする。換言すれば、時間測定部３１６は、計算されたプロセスの実行時間がゼロにならないような、十分な精度の時刻を取得することができるものとする。
【０１７９】
メモリ取得・解放部３１７は、要求に応じて、メモリ（具体的には図３のＲＡＭ２０２）を取得する（つまり、メモリを割り当てる）。また、メモリ取得・解放部３１７は、要求に応じて、割り当て済みのメモリを解放する。
【０１８０】
メモリ取得・解放部３１７は、具体的には、メモリの割り当てと解放のためのライブラリ関数（例えばｍａｌｌｏｃ（）関数とｆｒｅｅ（）関数）をＣＰＵ２０１が実行することにより、実現されてもよい。あるいは、メモリ取得・解放部３１７は、メモリの割り当てと解放のためのシステムコールをＣＰＵ２０１が実行することにより、実現されてもよい。
【０１８１】
なお、メモリの割り当てと解放のためのライブラリ関数は、いずれもシステムコールの呼び出しを含む。つまり、メモリ取得・解放部３１７は、具体的には、カーネル３１８を呼び出すことにより、メモリを割り当てたり解放したりする。
【０１８２】
ライブラリ関数の実装にもよるが、例えば、ｍａｌｌｏｃ（）関数は、システムコールであるｍｍａｐ（）関数の呼び出しを含んでいてもよい。また、ｆｒｅｅ（）関数は、システムコールであるｍｕｍａｐ（）関数の呼び出しを含んでいてもよい。
【０１８３】
ドライバ３１９は、ハードウェア３０３（例えば、入力装置２０５、出力装置２０６、記憶装置２０７、駆動装置２０８など）のためのデバイスドライバである。
なお、図２と図４の関係は次のとおりである。
【０１８４】
図４のハードウェア３０３は、図２のメモリ１０１と同様のメモリ（例えば図３のＲＡＭ２０２）を含む。また、図４のＣＰＵ試験実行部３０６、メモリ試験実行部３０７、ディスク試験実行部３０８、およびネットワーク試験実行部３０９は、それぞれ、図２のプログラム実行部１０２と同様にメモリ割り当てを要求することがある。
【０１８５】
図４のメモリ取得部３１１は、図２の要求受付部１０４、判断部１０５、およびメモリ割り当て制御部１０６と類似の処理を実行する。図２のパラメタ１０７に相当する種々の値は、管理表３１２と定数データ３１３に記憶される。
【０１８６】
また、第２実施形態においては、図４のＣＰＵ負荷測定部３１４とメモリ使用量測定部３１５が図２の特定処理実行部１０３に対応する。後述の第３実施形態においては、図４のメモリ取得・解放部３１７が図２の特定処理実行部１０３に対応する。
【０１８７】
続いて、図５を参照して、第２実施形態におけるメモリ割り当て制御方法の概要について説明する。第２実施形態では、図１のフローチャートＦ２と類似の方法をメモリ取得部３１１が実行することにより、メモリ割り当てが制御される。
【０１８８】
第１実施形態に関して説明したとおり、フローチャートＦ２のステップＳ１０２の判定条件は、プロセッサが１つ以上の特定の処理のそれぞれを実行するのにかかる時間に関する条件である。そして、第２実施形態では、具体的には、特定の処理の数は２である。つまり、第１実施形態に関して説明した式（１）と（２）におけるＮの値は、第２実施形態では２である。そして、第２実施形態では、式（５）の判定条件Ｃが利用される。より具体的に説明すれば以下のとおりである。
【０１８９】
第２実施形態における第１の特定の処理は、上記（３−１）と同様の、メモリ資源の使用量を示す値を取得する処理である。具体的には、第１の特定の処理は、図４のメモリ使用量測定部３１５が、メモリ（つまり図３のＲＡＭ２０２）の使用量を示す値を取得する処理である。
【０１９０】
以下では説明の便宜上、メモリ使用量測定部３１５により得られた値を「ｕ＿ｍｅｍ」と表記する。使用量ｕ＿ｍｅｍは、式（３）の「ｍ」に相当する。
また、第２の特定の処理は、上記（３−２）と同様の、ＣＰＵ資源の使用量（つまりCＣＰＵ２０１の負荷）を示す値を取得する処理である。具体的には、第２の特定の処理は、図４のＣＰＵ負荷測定部３１４が、図３のＣＰＵ２０１の使用量を示す値を取得する処理である。なお、ＣＰＵ２０１の使用量は、具体的には、ＣＰＵ時間で表されてもよいし、ＣＰＵ使用率で表されてもよい。
【０１９１】
以下では説明の便宜上、ＣＰＵ負荷測定部３１４により得られた値を「ｕ＿ｃｐｕ」と表記する。使用量ｕ＿ｃｐｕは、式（４）の「ｕ」に相当する。
図４の時間測定部３１６は、メモリ使用量測定部３１５が第１の特定の処理を実行するのにかかる時間を測定する。以下では説明の便宜上、測定された時間を「ｔ＿ｍｅｍ」と表記する。測定時間ｔ＿ｍｅｍは、式（２）の「ｔ（ｐ１）」に相当する。
【０１９２】
また、時間測定部３１６は、ＣＰＵ負荷測定部３１４が第２の特定の処理を実行するのにかかる時間も測定する。以下では説明の便宜上、測定された時間を「ｔ＿ｃｐｕ」と表記する。測定時間ｔ＿ｃｐｕは、式（２）の「ｔ（ｐ２）」に相当する。
【０１９３】
ところで、第２実施形態では、測定時間ｔ＿ｍｅｍに関する閾値ＴＨ＿ＭＥＭと、測定時間ｔ＿ｃｐｕに関する閾値ＴＨ＿ＣＰＵが、予め計算されて管理表３１２に記憶されている。閾値ＴＨ＿ＭＥＭとＴＨ＿ＣＰＵは、それぞれ、式（２）の「Ｔ１」と「Ｔ２」に相当する。
【０１９４】
また、第２実施形態では、メモリ使用量ｕ＿ｍｅｍに関する閾値ＨＩ＿ＭＥＭと、ＣＰＵ使用量に関する閾値ＨＩ＿ＣＰＵが、予め決められて定数データ３１３としてコンピュータ３００に記憶されている。閾値ＨＩ＿ＭＥＭとＨＩ＿ＣＰＵは、それぞれ、式（３）の「Ｍ」と式（４）の「Ｕ」に相当する。
【０１９５】
図５の説明図４００は、あり得る１６のケースを説明する図である。図５において、１列目はケース番号を示す。
また、２列目は、メモリ取得部３１１による判断の結果（すなわち、メモリ割り当ての可否についての予測）を示す。メモリ取得部３１１は、図２の判断部１０５と類似の方法により、判定条件が成立するか否かを判断する。
【０１９６】
判定条件が成立しない場合とは、メモリ割り当てが成功する見込みが高い場合であり、換言すれば、「メモリは割り当て可能である」とメモリ取得部３１１が予測する場合である。この場合は、図５では２列目に「可」と表記されている。
【０１９７】
逆に、判定条件が成立する場合とは、メモリ割り当てが失敗する見込みが高い場合であり、換言すれば「メモリは割り当て不能である」とメモリ取得部３１１が予測する場合である。この場合は、図５では２列目に「否」と表記されている。
【０１９８】
また、３列目には、ＴＨ＿ＭＥＭ＜ｔ＿ｍｅｍならば「大」と表記されており、ｔ＿ｍｅｍ≦ＴＨ＿ＭＥＭならば「小」と表記されている。そして、４列目には、ＨＩ＿ＭＥＭ＜ｕ＿ｍｅｍならば「大」と表記されており、ｕ＿ｍｅｍ≦ＨＩ＿ＭＥＭならば「小」と表記されている。
【０１９９】
また、５列目には、ＴＨ＿ＣＰＵ＜ｔ＿ｃｐｕならば「大」と表記されており、ｔ＿ｃｐｕ≦ＴＨ＿ＣＰＵならば「小」と表記されている。そして、６列目には、ＨＩ＿ＣＰＵ＜ｕ＿ｃｐｕならば「大」と表記されており、ｕ＿ｃｐｕ≦ＨＩ＿ＣＰＵならば「小」と表記されている。
【０２００】
したがって、３〜６列目の値の組み合わせとして、１６（＝２４）パターンが存在する。図５では、これら１６パターンそれぞれについてのメモリ取得部３１１の判断結果が、２列目に「可」または「否」と表されている。
【０２０１】
具体的には、１〜４番のケースに示すように、測定時間ｔ＿ｍｅｍと測定時間ｔ＿ｃｐｕの双方が「大」の場合、コンピュータ３００は、所定のコマンドの実行にすら長時間かかってしまうほどの高負荷状態である。したがって、１〜４番のケースでメモリ取得部３１１は、「メモリは割り当て不能である」と予測する。
【０２０２】
また、５、９、１３番のケースに示すように、メモリ使用量ｕ＿ｍｅｍとＣＰＵ使用量ｕ＿ｃｐｕの双方が「大」の場合も、メモリ取得部３１１は、「メモリは割り当て不能である」と予測する。なぜなら、空きメモリが少なく、しかもＣＰＵ２０１の負荷も高いからである。
【０２０３】
なお、現在使用中のメモリの中には、例えばＯＳがディスクＩＯ用のバッファとして一時的に利用している領域もあるかもしれない。そして、一時的に使用されているバッファ領域は、少し時間が経てばＯＳにより解放されて、アプリケーションから使用可能な状態になる可能性がある。しかし、ＣＰＵ２０１の負荷が高い場合、バッファ領域を解放してアプリケーションから使用可能な状態にするための処理をＣＰＵ２０１が実行し始めるまでの待ち時間も、当該処理をＣＰＵ２０１が実行するのにかかる時間も、比較的長い。つまり、割り当て可能なメモリが増えるまでにかかる時間が比較的長い。
【０２０４】
よって、ＣＰＵ使用量ｕ＿ｃｐｕが「大」の場合は、「一時的に使用されているバッファ領域を解放する処理をＣＰＵ２０１が実行することでメモリ使用量が減り、その結果、新たなメモリ割り当てが成功する見込みが高まる」ということは、期待しづらい。したがって、５、９、１３番のケースでメモリ取得部３１１は、上記のとおり「メモリは割り当て不能である」と予測する。
【０２０５】
逆に、たとえ測定されたメモリ使用量ｕ＿ｍｅｍ自体が「大」であっても、ＣＰＵ使用量ｕ＿ｃｐｕが「小」ならば、少し時間が経てばメモリ割り当てが成功する可能性がある。よって、６、１０、１４番のケースでは、メモリ取得部３１１は、「メモリは割り当て可能である」と予測する。
【０２０６】
なお、後述のとおり第２実施形態ではリトライ制御が行われる。よって、「リトライのための待ち時間が経過するうちに、ＯＳによる処理が進捗して、使用可能なメモリが増える」と考えられる。したがって、６、１０、１４番のケースのように、少し時間が経てばメモリ割り当てが成功する見込みが高くなりそうならば、メモリ取得部３１１は、「メモリは割り当て可能である」と予測する。
【０２０７】
なお、第２実施形態では、メモリ取得部３１１は、「メモリ使用量測定部３１５が測定したメモリ使用量ｕ＿ｍｅｍのうち、実際にどの程度の量がＯＳにより一時的に使用されているのか」ということを確認はしない。もしメモリ取得部３１１がそのような確認を行えば、予測の正確さは向上するだろうが、その代わり、確認のためのオーバヘッドが生じる。そのため、第２実施形態では、オーバヘッドと予測の正確さのバランスを考慮して、メモリ取得部３１１は、上記のような確認は行わない。
【０２０８】
また、７、１１、１５番のケースのように、たとえ測定されたＣＰＵ使用量ｕ＿ｃｐｕが「大」であっても、測定されたメモリ使用量ｕ＿ｍｅｍが「小」ならば、メモリ取得部３１１は、「メモリは割り当て可能である」と予測する。なぜなら、メモリ使用量ｕ＿ｍｅｍが「小」なので、空きメモリが十分に存在しているからである。
【０２０９】
なお、ＣＰＵ使用量ｕ＿ｃｐｕが「大」なので、メモリ割り当てのための処理をＣＰＵ２０１が実際に開始することができるまでに、少々の待ち時間が生じる可能性はある。しかし、空きメモリは存在しているので、メモリ割り当てのための処理をＣＰＵ２０１が実際に開始すれば、メモリ割り当てが成功する見込みは高い。したがって、メモリ取得部３１１は、「メモリは割り当て可能である」と予測する。
【０２１０】
また、８、１２、１６番のケースのように、ＣＰＵ使用量ｕ＿ｃｐｕとメモリ使用量ｕ＿ｍｅｍがともに「小」ならば、空きメモリ自体も存在しており、ＣＰＵ２０１は比較的すぐにメモリ割り当てのための処理の実行を開始することができる。そして、メモリ割り当てが成功する見込みは高い。したがって、メモリ取得部３１１は、「メモリは割り当て可能である」と予測する。
【０２１１】
なお、以上説明した第２実施形態におけるメモリ割り当て制御方法の詳細は、図１０のフローチャートとともに後述する。
さて、図６は、第２実施形態で使われるデータを示す図である。図６には、図４の管理表３１２と定数データ３１３の具体例として、管理表５０１と定数データ５０２が例示されている。
【０２１２】
管理表５０１は、３種類の処理のそれぞれについての、処理の実行にかかる時間に関する基準値と閾値を含む。図６の例では、基準値と閾値の双方の単位はμｓ（マイクロ秒）である。
【０２１３】
具体的には、管理表５０１の１行目には、メモリ使用量測定部３１５がメモリ使用状況を認識する（すなわち、メモリ使用量ｕ＿ｍｅｍの値を取得する）のにかかる時間ｔ＿ｍｅｍに関して、基準値ＲＥＦ＿ＭＥＭと閾値ＴＨ＿ＭＥＭが記憶されている。なお、閾値ＴＨ＿ＭＥＭは、図５の３列目に関して前述した閾値である。
【０２１４】
また、管理表５０１の２行目には、ＣＰＵ負荷測定部３１４がＣＰＵ負荷状況を認識する（すなわち、ＣＰＵ使用量ｕ＿ｃｐｕの値を取得する）のにかかる時間ｔ＿ｃｐｕに関して、基準値ＲＥＦ＿ＣＰＵと閾値ＴＨ＿ＣＰＵが記憶されている。なお、閾値ＴＨ＿ＣＰＵは、図５の５列目に関して前述した閾値である。
【０２１５】
そして、管理表５０１の３行目には、メモリ取得・解放部３１７がカーネル３１８を呼び出して行うメモリ割り当ての試みにかかる時間に関して、基準値ＲＥＦ＿ＡＬＬＯＣと閾値ＴＨ＿ＡＬＬＯＣが記憶されている。閾値ＴＨ＿ＡＬＬＯＣは、図１０とともに後述するリトライ制御で参照される。また、閾値ＴＨ＿ＡＬＬＯＣは、第１実施形態に関して説明した（５−１）と（５−２）の閾値の例でもある。
【０２１６】
また、定数データ５０２は、リトライ制御が有効か否かを、真（true）または偽（false）の値によって示す、リトライ有効性フラグＲＴ＿ＦＬＡＧを含む。そして、定数データ５０２には、リトライ有効性フラグＲＴ＿ＦＬＡＧが真のときに参照される、リトライ待ち時間ＲＴ＿ＷＡＩＴとリトライカウンタの初期値ＲＴ＿ＣＮＴも含まれる。
【０２１７】
さらに、定数データ５０２は、図５に関して説明した、メモリ使用量の判定閾値ＨＩ＿ＭＥＭと、ＣＰＵ負荷の判定閾値ＨＩ＿ＣＰＵも含む。
また、詳しくは後述するが、管理表５０１における３つの閾値は、それぞれ対応する基準値に係数を掛けることにより計算される。定数データ５０２は、それらの係数も含む。
【０２１８】
具体的には、定数データ５０２は、メモリ使用状況の認識にかかる時間に関する係数ＣＯ＿ＭＥＭと、ＣＰＵ負荷状況の認識にかかる時間に関する係数ＣＯ＿ＣＰＵと、メモリ割り当ての試みにかかる時間に関する係数ＣＯ＿ＡＬＬＯＣを含む。詳しくは図８とともに後述するとおり、管理表５０１中の閾値は、これらの係数を用いて、式（９）〜（１１）のように基準値から計算される。
【０２１９】
TH_MEM=REF_MEM×CO_MEM                (9)
TH_CPU=REF_CPU×CO_CPU                (10)
TH_ALLOC=REF_ALLOC×CO_ALLOC          (11)
以上の３つの係数は、例えば予備実験などに基づいて、予め適宜の値に設定されていてもよい。あるいは、入力装置２０５からの入力に基づいて係数の値が決められてもよい。
【０２２０】
また、詳しくは図８とともに後述するが、管理表５０１中の基準値ＲＥＦ＿ＡＬＬＯＣを取得するために、メモリ取得・解放部３１７は、ある所定サイズＳＺのメモリの割り当てを試みる。その所定サイズＳＺの値も、定数データ５０２に含まれる。例えば、ＯＳ３０２により定義されるページサイズが、所定サイズＳＺとして定数データ５０２に設定されていてもよい。
【０２２１】
さて、以下では図７〜１０のフローチャートを参照して、第２実施形態のコンピュータ３００の動作についてさらに詳しく説明する。
図７は、第２実施形態と第３実施形態に共通のシステム試験のフローチャートである。例えば、システム試験の開始を命じる入力を図３の入力装置２０５が受け付けると、図４の試験制御部３０５が図７の処理を開始する。
【０２２２】
ステップＳ２０１で試験制御部３０５は、初期化を実行する。具体的には、試験制御部３０５は、管理表３１２を初期化する。例えば、第２実施形態では、管理表３１２は具体的には管理表５０１である。よって、試験制御部３０５は、管理表５０１中の６つの値をすべてゼロに初期化してもよい。
【０２２３】
また、定数データ３１３は、図７のシステム試験の実行中には変化しないデータだが、定数データ３１３の少なくとも一部は、ユーザ定義可能であってもよい。例えば、定数データ３１３を指定する入力を入力装置２０５がユーザから受け付けてもよく、試験制御部３０５は、入力された値を定数データ３１３として設定し、ＲＡＭ２０２に定数データ３１３を記憶してもよい。あるいは、試験制御部３０５は、予め設定された定数データ３１３のファイルを、ＲＯＭ２０３、記憶装置２０７、または記憶媒体２１０などから、ＲＡＭ２０２へと読み込んでもよい。
【０２２４】
次に、ステップＳ２０２で試験制御部３０５は、情報取得部３１０に「低負荷時の情報取得処理」を実行させる。具体的には、情報取得部３１０は、第２実施形態では図８のフローチャートにしたがって動作し、第３実施形態では図１２のフローチャートにしたがって動作する。いずれの実施形態においても、情報取得部３１０は、コンピュータ３００全体の負荷が低いときに各種の情報を取得し、取得した情報を使って管理表３１２中の様々な値を設定する。
【０２２５】
その後、ステップＳ２０３で試験制御部３０５は、ハードウェア３０３の構成に応じて、試験対象の装置と試験条件を決定する。ステップＳ２０３の詳細は任意である。
例えば、ハードウェア３０３が４つのＣＰＵ２０１を含む場合、試験制御部３０５は、４つすべてのＣＰＵ２０１を試験対象の装置として決定してもよい。同様に、ＲＡＭ２０２が２つのＤＩＭＭ（Dual In-line Memory Module）上に分散している場合、試験制御部３０５は、２つのＤＩＭＭを試験対象の装置として決定してもよい。
【０２２６】
また、ハードウェア３０３がメモリコントローラまたはＭＭＵを含む場合、試験制御部３０５は、メモリコントローラまたはＭＭＵを試験対象の装置として決定してもよい。そして、ハードウェア３０３が通信インタフェイス２０４を含む場合、試験制御部３０５は、通信インタフェイス２０４を試験対象の装置として決定してもよい。同様に、ハードウェア３０３が記憶装置２０７を含む場合、試験制御部３０５は、記憶装置２０７を試験対象の装置として決定してもよい。
【０２２７】
さらに、試験制御部３０５は、試験対象の装置の仕様などに応じて、試験条件を決定する。例えば、コンピュータ３００のＣＰＵ２０１が、シングルコアＣＰＵの場合は、試験制御部３０５は、シングルコアＣＰＵ用の条件を適用して試験を行うことを決定してもよい。また、試験制御部３０５は、ＲＡＭ２０２の容量に応じて、ＲＡＭ２０２の試験に適用する条件を決定してもよい。
【０２２８】
そして、試験対象の装置と試験条件が決定されると、処理はステップＳ２０４に移行する。ステップＳ２０４で試験制御部３０５は、試験対象の装置の中から、未試験の装置を選択する。
【０２２９】
次のステップＳ２０５で試験制御部３０５は、ステップＳ２０４で選択した装置の試験を、適宜の試験実行部に実行させる。
具体的には、試験制御部３０５は、ステップＳ２０４でＣＰＵ２０１を選択した場合、ＣＰＵ試験実行部３０６に試験を実行させる。また、試験制御部３０５は、ステップＳ２０４でＲＡＭ２０２を選択した場合、メモリ試験実行部３０７に試験を実行させる。
【０２３０】
あるいは、試験制御部３０５は、ステップＳ２０４で記憶装置２０７を選択した場合、ディスク試験実行部３０８に試験を実行させる。また、試験制御部３０５は、ステップＳ２０４で通信インタフェイス２０４を選択した場合、ネットワーク試験実行部３０９に試験を実行させる。
【０２３１】
なお、ＣＰＵ試験実行部３０６と、メモリ試験実行部３０７と、ディスク試験実行部３０８と、ネットワーク試験実行部３０９は、いずれも、図９のフローチャートにしたがって試験を実行する。そして、試験制御部３０５が適宜の試験実行部に試験の実行を命令した後、あるいは、命令を受けた試験実行部が試験の実行を完了した後に、処理はステップＳ２０６へと移行する。
【０２３２】
試験制御部３０５が適宜の試験実行部に試験の実行を命令した後すぐに、ステップＳ２０５からステップＳ２０６へ処理が移行する場合、複数の試験実行部による試験が並列に実行される。逆に、試験制御部３０５からの命令を受けた試験実行部が試験の実行を完了した後に、ステップＳ２０５からステップＳ２０６へ処理が移行する場合、複数の試験実行部による試験は、１つずつ順番に実行される。
【０２３３】
さて、ステップＳ２０６で試験制御部３０５は、ステップＳ２０３で決定したすべての試験対象装置を選択したか否かを判断する。そして、未選択の試験対象装置が残っていれば、処理はステップＳ２０４に戻る。逆に、すべての試験対象装置が選択済みならば、図７のシステム試験も終了する。
【０２３４】
図８は、第２実施形態における低負荷時の情報取得処置のフローチャートである。図８の処理は、図７のステップＳ２０２から呼び出される。
なお、説明の簡単化のため、システム試験は他のユーザアプリケーションの実行中には実行されないものとする。すると、ステップＳ２０２の実行時点でのコンピュータ３００の負荷は低い。したがって、図８の処理によって、情報取得部３１０は、コンピュータ３００の負荷が低いときに各種情報を取得することができる。
【０２３５】
ステップＳ３０１で情報取得部３１０は、メモリ使用量測定部３１５と時間測定部３１６を呼び出し、メモリ使用状況を示す値を取得するのにかかる時間を認識する。ステップＳ３０１の詳細は、例えば次の（７−１）〜（７−４）のようであってもよい。
【０２３６】
（７−１）時間測定部３１６が現在時刻を取得する。
（７−２）メモリ使用量測定部３１５が、メモリ使用量を測定する。
（７−３）メモリ使用量測定部３１５が（７−２）の測定を完了すると、時間測定部３１６が再び現在時刻を取得する。
（７−４）時間測定部３１６が、（７−３）で取得した時刻から（７−１）で取得した時刻を引くことにより、（７−２）の測定にかかった時間を測定し、測定した時間を情報取得部３１０に返す。
【０２３７】
続いてステップＳ３０２において情報取得部３１０は、ステップＳ３０１で測定された時間（すなわち（７−４）で時間測定部３１６から得られた時間）を、基準値ＲＥＦ＿ＭＥＭとして管理表５０１に格納する。
【０２３８】
また、次のステップＳ３０３で情報取得部３１０は、定数データ５０２を参照して係数ＣＯ＿ＭＥＭを読み取り、式（９）にしたがって閾値ＴＨ＿ＭＥＭを計算する。そして、情報取得部３１０は、計算した閾値ＴＨ＿ＭＥＭを管理表５０１に格納する。
【０２３９】
次に、ステップＳ３０４で情報取得部３１０は、ＣＰＵ負荷測定部３１４と時間測定部３１６を呼び出し、ＣＰＵ負荷状況を示す値を取得するのにかかる時間を認識する。ステップＳ３０４の詳細は、例えば次の（８−１）〜（８−４）のようであってもよい。
【０２４０】
（８−１）時間測定部３１６が現在時刻を取得する。
（８−２）ＣＰＵ負荷測定部３１４が、ＣＰＵ使用量（例えば、ＣＰＵ使用率により表される）を測定する。
（８−３）ＣＰＵ負荷測定部３１４が（８−２）の測定を完了すると、時間測定部３１６が再び現在時刻を取得する。
（８−４）時間測定部３１６が、（８−３）で取得した時刻から（８−１）で取得した時刻を引くことにより、（８−２）の測定にかかった時間を測定し、測定した時間を情報取得部３１０に返す。
【０２４１】
続いてステップＳ３０５において情報取得部３１０は、ステップＳ３０４で測定された時間（すなわち（８−４）で時間測定部３１６から得られた時間）を、基準値ＲＥＦ＿ＣＰＵとして管理表５０１に格納する。
【０２４２】
また、次のステップＳ３０６で情報取得部３１０は、定数データ５０２を参照して係数ＣＯ＿ＣＰＵを読み取り、式（１０）にしたがって閾値ＴＨ＿ＣＰＵを計算する。そして、情報取得部３１０は、計算した閾値ＴＨ＿ＣＰＵを管理表５０１に格納する。
【０２４３】
次に、ステップＳ３０７で情報取得部３１０は、メモリ取得・解放部３１７と時間測定部３１６を呼び出し、所定サイズのメモリの割り当てを試みるのにかかる時間を認識する。ステップＳ３０７の詳細は、例えば次の（９−１）〜（９−６）のようであってもよい。
【０２４４】
（９−１）情報取得部３１０が、定数データ５０２を参照してメモリサイズＳＺを認識する。
（９−２）時間測定部３１６が現在時刻を取得する。
（９−３）情報取得部３１０が、認識したサイズＳＺのメモリの割り当てをメモリ取得・解放部３１７に要求する。
（９−４）メモリ取得・解放部３１７は、要求されたサイズＳＺのメモリの割り当てを試み、試みの結果（例えばポインタ）を情報取得部３１０に返す。
（９−５）メモリ取得・解放部３１７が（９−４）の試みを完了すると、時間測定部３１６が再び現在時刻を取得する。
（９−６）時間測定部３１６が、（９−５）で取得した時刻から（９−２）で取得した時刻を引くことにより、（９−４）のメモリ割り当ての試みにかかった時間を測定し、測定した時間を情報取得部３１０に返す。
【０２４５】
続いてステップＳ３０８において情報取得部３１０は、ステップＳ３０７で測定された時間（すなわち（９−６）で時間測定部３１６から得られた時間）を、基準値ＲＥＦ＿ＡＬＬＯＣとして管理表５０１に格納する。
【０２４６】
また、次のステップＳ３０９で情報取得部３１０は、定数データ５０２を参照して係数ＣＯ＿ＡＬＬＯＣを読み取り、式（１１）にしたがって閾値ＴＨ＿ＡＬＬＯＣを計算する。そして、情報取得部３１０は、計算した閾値ＴＨ＿ＡＬＬＯＣを管理表５０１に格納する。
【０２４７】
最後に、ステップＳ３１０で情報取得部３１０は、ステップＳ３０７で取得したメモリを解放するためにメモリ取得・解放部３１７を呼び出す。そして、メモリ取得・解放部３１７がメモリを解放する。
【０２４８】
以上のようにして、図８の処理により、管理表５０１には、コンピュータ３００の実情に応じた値が設定される。なお、説明の簡単化のため、図８の処理においてはステップＳ３０７でメモリ割り当てが成功すると仮定している。なぜなら、図８の処理はコンピュータ３００が低負荷のときに実行されるので、ほとんどの場合、メモリ割り当ては成功するからである。しかし、実施形態によっては、もちろん、メモリ割り当てが失敗する場合のためのエラー処理がさらに行われてもよい。
【０２４９】
続いて、図７のステップＳ２０５から呼び出される試験実行処理について説明する。図９は、第２実施形態と第３実施形態に共通の試験実行処理のフローチャートである。
ステップＳ２０５に関して説明したように、図９の処理は、ステップＳ２０４で選択された装置に応じて、ＣＰＵ試験実行部３０６、メモリ試験実行部３０７、ディスク試験実行部３０８、またはネットワーク試験実行部３０９のいずれかによって実行される。以下では説明の便宜上、これらの試験実行部に共通の動作については、例えば「試験実行部が初期化を実行する」のように、単に「試験実行部」と表現することがある。
【０２５０】
さて、ステップＳ４０１で試験実行部は、初期化を実行する。例えば、試験制御部３０５からの指示、または入力装置２０５を介してユーザから与えられる指示にしたがって、試験実行部は、試験内容、試験方法、試験条件などに応じた初期化（例えばパラメタの初期設定）を実行する。
【０２５１】
そして、次のステップＳ４０２で試験実行部は、メモリ使用量（より具体的には、試験実行部が動的に割り当てを要求するメモリ領域のサイズ）を決定する。メモリ使用量は、例えば、図７のステップＳ２０３で試験制御部３０５により決定された試験条件に応じて決められる。
【０２５２】
例えば、メモリ試験実行部３０７は、メモリ（具体的にはＲＡＭ２０２）を試験するために、メモリを使用する。また、ＣＰＵ試験実行部３０６も、例えばＣＰＵ２０１内のキャッシュメモリの試験のために、あるいは、ＣＰＵ２０１による計算結果を一時的に格納するために、ＲＡＭ２０２上のメモリ領域の割り当てを要求することがある。
【０２５３】
また、ディスク試験実行部３０８も、例えば、記憶装置２０７とＲＡＭ２０２の間でのデータ転送のスループットを試験するために、ＲＡＭ２０２上のメモリ領域の割り当てを要求することがある。ネットワーク試験実行部３０９も、例えば、通信インタフェイス２０４の試験において送信バッファまたは受信バッファとして利用するために、ＲＡＭ２０２上のメモリ領域の割り当てを要求することがある。
【０２５４】
以上のように、ステップＳ４０２では、試験実行部が、適宜、メモリ使用量を決定する。
次に、ステップＳ４０３で試験実行部は、定数データ３１３中のリトライカウンタの初期値ＲＴ＿ＣＮＴを読み取り、リトライカウンタに初期値ＲＴ＿ＣＮＴを設定する。例えば、初期値ＲＴ＿ＣＮＴは、２から５程度の比較的小さな数であってもよい。
【０２５５】
次に、ステップＳ４０４で試験実行部は、ステップＳ４０２で決定したメモリ使用量を指定して、メモリ取得部３１１を呼び出す。すると、メモリ取得部３１１がメモリ取得処理を実行する。
【０２５６】
具体的には、第２実施形態では、メモリ取得部３１１は、図１０のフローチャートにしたがってメモリ取得処理を実行する。第３実施形態では、メモリ取得部３１１は、図１３のフローチャートにしたがってメモリ取得処理を実行する。
【０２５７】
以下では説明の便宜上、第２実施形態と第３実施形態のいずれにおいても、ステップＳ４０４のメモリ取得処理の結果は、（１０−１）〜（１０−２）のとおりとする。なお、終了コードは、例えば、ライブラリで定義されている「ｅｒｒｎｏ」などの所定の変数により表されてもよい。
【０２５８】
（１０−１）メモリ割り当てが成功すれば（つまり、ステップＳ４０２で決定されたサイズのメモリが成功裡に取得されれば）、正常終了を示す値が終了コードとして設定され、取得されたメモリ領域の先頭アドレスを指すポインタが試験実行部に返される。
（１０−２）メモリ割り当てが失敗すれば、異常終了を示す値が終了コードとして設定され、ＮＵＬＬポインタが試験実行部に返される。
【０２５９】
さて、ステップＳ４０４のメモリ取得処理の後、ステップＳ４０５で試験実行部は、終了コードが正常と異常のいずれを示すかを判断する。終了コードが正常を示す場合、処理はステップＳ４０６に移行する。逆に、終了コードが異常を示す場合、処理はステップＳ４０８に移行する。
ステップＳ４０６で試験実行部は、割り当てに成功したメモリを使用して、適宜の試験を実行する。
例えば、ＣＰＵ試験実行部３０６は、ＣＰＵ２０１内のプロセッサコアやキャッシュメモリを試験する。また、メモリ試験実行部３０７は、メモリ（具体的にはＲＡＭ２０２）に対するリード操作およびライト操作を実行することで、ＲＡＭ２０２のチップが搭載されたＤＩＭＭ、メモリコントローラ、ＭＭＵ、メモリバスなどを試験する。
【０２６０】
ディスク試験実行部３０８は、記憶装置２０７（具体的には例えばＨＤＤ）に対するリード操作およびライト操作を実行することで、ＨＤＤの磁気ディスク媒体、ＨＤＤコントローラ、ＩＯバスなどを試験する。また、ネットワーク試験実行部３０９は、通信インタフェイス２０４を用いてネットワーク２１１へデータを送信したり、通信インタフェイス２０４を用いてネットワーク２１１からデータを受信したりする。それにより、ネットワーク試験実行部３０９は、ネットワークコントローラやネットワーク伝送路を試験する。
【０２６１】
試験の終了後、ステップＳ４０７で試験実行部は、ステップＳ４０４で取得されたメモリを解放するよう、メモリ取得・解放部３１７に要求する。そして、図９の試験実行処理も終了する。
【０２６２】
他方、ステップＳ４０４でメモリが取得されなかった場合は、ステップＳ４０８で試験実行部が定数データ３１３中のリトライフラグＲＴ＿ＦＬＡＧの値を読み取る。そして、リトライフラグＲＴ＿ＦＬＡＧが、「リトライが有効である」と示していれば、処理はステップＳ４０９に移行する。逆に、リトライフラグＲＴ＿ＦＬＡＧが、「リトライが無効である」と示していれば、図９の試験実行処理は終了する。
【０２６３】
ステップＳ４０９で試験実行部は、リトライカウンタをデクリメントする。そして、次のステップＳ４１０で試験実行部は、リトライカウンタの値がゼロか否かを判断する。
リトライカウンタの値がゼロの場合、図９の試験実行処理は終了する。逆に、リトライカウンタの値が１以上の場合、処理はステップＳ４１１に移行する。
【０２６４】
ステップＳ４１１で試験実行部は、定数データ３１３中のリトライ待ち時間ＲＴ＿ＷＡＩＴの値を読み取る。そして、試験実行部は、リトライ待ち時間ＲＴ＿ＷＡＩＴだけ待つ。リトライ待ち時間ＲＴ＿ＷＡＩＴが経過すると、処理はステップＳ４０４に戻る。
【０２６５】
なお、仮に、メモリ割り当ての失敗の直後に再度メモリ割り当てが試みられるとすると、コンピュータ３００の状況はほとんど変化していないため、メモリ割り当てが再度失敗する可能性が非常に高い。そこで、リトライによる割り当て成功の見込みを高めるため、試験実行部は、ステップＳ４１１のように所定の時間ＲＴ＿ＷＡＩＴだけ待つ。
【０２６６】
続いて、第２実施形態において図９のステップＳ４０４から呼び出されるメモリ取得処理について説明する。図１０は、第２実施形態におけるメモリ取得処理のフローチャートである。
【０２６７】
ステップＳ５０１でメモリ取得部３１１は、メモリ使用量測定部３１５と時間測定部３１６を呼び出し、メモリ使用状況を示す値を取得するのにかかる時間を認識する。ステップＳ５０１の詳細は、例えば、図８のステップＳ３０１と同様であってもよい。つまり、メモリ使用状況を示す値ｕ＿ｍｅｍをメモリ使用量測定部３１５が取得するとともに、取得にかかる時間（すなわち図５の測定時間ｔ＿ｍｅｍ）を時間測定部３１６が測定する。
【０２６８】
ただし、ステップＳ５０１では、測定された時間ｔ＿ｍｅｍが時間測定部３１６からメモリ取得部３１１に返される点が、ステップＳ３０１と異なる。また、ステップＳ５０１では、メモリ使用量測定部３１５が、測定したメモリ使用量（すなわち図５の使用量ｕ＿ｍｅｍ）をメモリ取得部３１１に通知する。
【０２６９】
続いてステップＳ５０２でメモリ取得部３１１は、ＣＰＵ負荷測定部３１４と時間測定部３１６を呼び出し、ＣＰＵ負荷状況を示す値を取得するのにかかる時間を認識する。ステップＳ５０２の詳細は、例えば、図８のステップＳ３０４と同様であってもよい。つまり、ＣＰＵ負荷状況を示す値ｕ＿ｃｐｕをＣＰＵ負荷測定部３１４が取得するとともに、取得にかかる時間（すなわち図５の測定時間ｔ＿ｃｐｕ）を時間測定部３１６が測定する。
【０２７０】
ただし、ステップＳ５０２では、測定された時間ｔ＿ｃｐｕが時間測定部３１６からメモリ取得部３１１に返される点が、ステップＳ３０４と異なる。また、ステップＳ５０２では、ＣＰＵ負荷測定部３１４が、測定したＣＰＵ使用量（すなわち図５の使用量ｕ＿ｃｐｕ）をメモリ取得部３１１に通知する。
【０２７１】
そして、ステップＳ５０３でメモリ取得部３１１は、ステップＳ５０１とＳ５０２で認識した２つの時間の長さがともに基準外であるか否かを判断する。つまり、メモリ取得部３１１は、管理表５０１から閾値ＴＨ＿ＭＥＭとＴＨ＿ＣＰＵを読み出し、式（１２）が成立するか否かを判断する。
(TH_MEM<t_mem)∧(TH_CPU<t_cpu)=true          (12)
【０２７２】
なお、図５に示すとおり、図５のケース番号が１〜４番のいずれかの場合に、式（１２）が成立し、ケース番号５〜１６番の場合には式（１２）が成立しない。式（１２）が成立する場合、処理はステップＳ５０４に移行する。逆に、式（１２）が成立しない場合、処理はステップＳ５０５に移行する。
【０２７３】
ステップＳ５０４でメモリ取得部３１１は、異常終了を示す値を終了コードとして設定し、試験実行部への返り値としてＮＵＬＬポインタを設定する。そして、メモリ取得処理は終了する。
【０２７４】
また、ステップＳ５０５でメモリ取得部３１１は、メモリ使用量とＣＰＵ負荷がともに大きいか否かを判断する。つまり、メモリ取得部３１１は、定数データ５０２内の判定閾値ＨＩ＿ＭＥＭとＨＩ＿ＣＰＵを読み出し、式（１３）が成立するか否かを判断する。
(HI_MEM<u_mem)∧(HI_CPU<u_cpu)=true          (13)
【０２７５】
なお、ステップＳ５０５で判断が下されるのは、図５のケース番号が５〜１６番のいずれかの場合である。そして、５〜１６番のケースの中で式（１３）が成立するのは、図５に示すとおり、５番、９番、または１３番の場合のみである。
【０２７６】
式（１３）が成立する場合、処理はステップＳ５０４に移行する。逆に、式（１３）が成立しない場合、処理はステップＳ５０６に移行する。
なお、ステップＳ５０３とＳ５０５は、図１のステップＳ１０２に対応する。そして、ステップＳ５０３またはＳ５０５からステップＳ５０４への移行は、ステップＳ１０２からステップＳ１０６への移行に対応する。また、ステップＳ５０４はステップＳ１０６に対応する。
【０２７７】
以上の対応関係から明らかなように、図１のステップＳ１０１における要求の受け付けは、図９のステップＳ４０４からの図１０の処理の呼び出しに対応する。つまり、第２実施形態では、メモリ取得部３１１が試験実行部からステップＳ１０１でメモリ割り当ての要求を受け付ける。
【０２７８】
さて、式（１３）が成立しない場合、ステップＳ５０６でメモリ取得部３１１は、定数データ５０２中のリトライカウンタの初期値ＲＴ＿ＣＮＴを読み取り、リトライカウンタに初期値ＲＴ＿ＣＮＴを設定する。例えば、初期値ＲＴ＿ＣＮＴは、２から５程度の比較的小さな数であってもよい。
【０２７９】
なお、第２実施形態では、図９のステップＳ４０３と図１０のステップＳ５０６で同じ初期値ＲＴ＿ＣＮＴが使われる。しかし、実施形態によっては、定数データ５０２において、ステップＳ４０３用の初期値とステップＳ５０６用の初期値が別々に定義されていてもよい。
【０２８０】
続いて、ステップＳ５０７でメモリ取得部３１１は、メモリ取得・解放部３１７と時間測定部３１６を呼び出す。具体的には、メモリ取得部３１１は、試験実行部から指定されたサイズのメモリの割り当てをメモリ取得・解放部３１７に試みさせるとともに、その試みにかかる時間を時間測定部３１６に測定させる。
【０２８１】
なお、メモリ取得部３１１からのメモリ取得・解放部３１７の呼び出しは、具体的には、例えば、ｍａｌｌｏｃ（）などのメモリ割り当てのためのライブラリ関数の呼び出しにより実現されてもよい。また、時間測定部３１６によって測定される時間は、換言すれば、アプリケーションからのライブラリ関数の呼び出しの時点から、ライブラリ関数からアプリケーションに返り値が返る時点までにかかる時間である。
【０２８２】
そして、ステップＳ５０７でメモリ取得・解放部３１７がメモリ割り当てを試みた後、ステップＳ５０８でメモリ取得部３１１は、メモリ割り当てが成功したか否かを判断する。
【０２８３】
例えば、メモリ取得・解放部３１７は、メモリ割り当てに成功すると、割り当てたメモリ領域の先頭を指すポインタをメモリ取得部３１１に返すとともに、正常終了を示す値を終了コードとして設定してもよい。また、メモリ取得・解放部３１７は、メモリ割り当てに失敗すると、ＮＵＬＬポインタをメモリ取得部３１１に返すとともに、異常終了を示す値を終了コードとして設定してもよい。したがって、メモリ取得部３１１はステップＳ５０８において、メモリ取得・解放部３１７からの返り値、終了コード、または、その双方を用いることにより、メモリ割り当てが成功したか否かを判断することができる。
【０２８４】
そして、ステップＳ５０７でメモリ割り当てが成功した場合、処理はステップＳ５０８からステップＳ５０９へと移行する。逆に、ステップＳ５０７でメモリ割り当てが失敗した場合、処理はステップＳ５０８からステップＳ５１０へと移行する。
【０２８５】
ステップＳ５０９でメモリ取得部３１１は、正常終了を示す値を終了コードとして設定する。また、メモリ取得部３１１は、試験実行部への返り値として、メモリ取得・解放部３１７からの返り値（すなわち、メモリ取得・解放部３１７により取得されたメモリ領域を指すポインタ）を設定する。そして、メモリ取得処理は終了する。
【０２８６】
さて、メモリ割り当てが失敗した場合、ステップＳ５１０でメモリ取得部３１１は、管理表５０１から閾値ＴＨ＿ＡＬＬＯＣを読み出し、ステップＳ５０７で時間測定部３１６により測定された時間を閾値ＴＨ＿ＡＬＬＯＣと比較する。測定された時間が閾値ＴＨ＿ＡＬＬＯＣ以下の場合、リトライの余地があるか否かの判断のため、処理はステップＳ５１１に移行する。
【０２８７】
逆に、測定された時間が閾値ＴＨ＿ＡＬＬＯＣよりも長い場合、メモリ取得部３１１は、リトライの余地がないと判断する。そして、処理はステップＳ５１５に移行する。
なぜなら、測定された時間が閾値ＴＨ＿ＡＬＬＯＣよりも長い場合とは、メモリ割り当て自体が失敗するだけではなく、メモリ割り当てが失敗したことが判明するのにすら長時間がかかる場合だからである。このように失敗の判明までにすら長時間がかかる理由は、コンピュータ３００全体の負荷が非常に高いためだと推測される。
【０２８８】
そして、コンピュータ３００の負荷が非常に高い場合には、たとえメモリ取得・解放部３１７が再びメモリ割り当てを試みても、失敗する可能性が高い。したがって、ステップＳ５０７で測定された時間が閾値ＴＨ＿ＡＬＬＯＣよりも長い場合、メモリ取得部３１１は、リトライの余地がないと判断する。
【０２８９】
さて、ステップＳ５１１でメモリ取得部３１１は、定数データ５０２中のリトライフラグＲＴ＿ＦＬＡＧの値を読み取る。そして、リトライフラグＲＴ＿ＦＬＡＧが、「リトライが有効である」と示していれば、処理はステップＳ５１２に移行する。逆に、リトライフラグＲＴ＿ＦＬＡＧが、「リトライが無効である」と示していれば、処理はステップＳ５１５に移行する。
【０２９０】
ステップＳ５１２でメモリ取得部３１１は、リトライカウンタをデクリメントする。そして、次のステップＳ５１３でメモリ取得部３１１は、リトライカウンタの値がゼロか否かを判断する。
【０２９１】
リトライカウンタの値がゼロの場合、処理はステップＳ５１５に移行する。逆に、リトライカウンタの値が１以上の場合、処理はステップＳ５１４に移行する。
ステップＳ５１４でメモリ取得部３１１は、定数データ３１３中のリトライ待ち時間ＲＴ＿ＷＡＩＴの値を読み取る。そして、メモリ取得部３１１は、リトライ待ち時間ＲＴ＿ＷＡＩＴだけ待つ。リトライ待ち時間ＲＴ＿ＷＡＩＴが経過すると、処理はステップＳ５０７に戻る。
【０２９２】
なお、ステップＳ５１４でメモリ取得部３１１が所定時間ＲＴ＿ＷＡＩＴだけ待つ理由は、図９のステップＳ４１１に関して説明した理由と同様である。
また、第２実施形態では、図９のステップＳ４０８と図１０のステップＳ５１１で同じリトライフラグＲＴ＿ＦＬＡＧが参照され、図９のステップＳ４１１と図１０のステップＳ５１４で同じリトライ待ち時間ＲＴ＿ＷＡＩＴが参照される。しかし、実施形態によっては、定数データ５０２において、ステップＳ４０８用とステップＳ５１１用のリトライフラグが別々に定義されていてもよい。同様に、定数データ５０２において、ステップＳ４１１用とステップＳ５１４用のリトライ待ち時間が別々に定義されていてもよい。
【０２９３】
さて、メモリ取得部３１１は、リトライの余地がないとステップＳ５１０、Ｓ５１１、またはＳ５１３で判断した場合、ステップＳ５１５において次のように動作する。すなわち、メモリ取得部３１１は、異常終了を示す値を終了コードとして設定する。また、メモリ取得部３１１は、メモリ割り当てのためのライブラリ関数の返り値（すなわち、メモリ取得・解放部３１７からの返り値であるＮＵＬＬポインタ）を、試験実行部への返り値として設定する。そして、メモリ取得処理は終了する。
【０２９４】
なお、図１０のステップＳ５０７でのメモリ取得・解放部３１７の呼び出しによるメモリ割り当ての試みは、図１のステップＳ１０３に相当する。そして、ステップＳ５０９とＳ５１５は、図１のステップＳ１０４に相当する。
【０２９５】
ある観点から見れば、図１のフローチャートＦ２の処理は、図１０の処理においてリトライが行われない場合（例えば、リトライフラグＲＴ＿ＦＬＡＧによりリトライが無効にされているか、または、リトライカウンタの初期値ＲＴ＿ＣＮＴが１の場合）の例である。別の観点から見れば、図１０の処理は、図１のフローチャートＦ２のステップＳ１０３とＳ１０４の間にリトライ制御が追加された処理である。
【０２９６】
以上説明した第２実施形態によれば、メモリ割り当ての試みが失敗しそうな高負荷状況下では、たとえメモリ割り当てが要求されても、メモリ割り当ては試みられない。よって、高負荷状況下でのメモリ割り当ての試みに起因する効率悪化、ストール、ハングなどの問題が軽減される。したがって、第２実施形態によれば、効率よく順調にシステム試験が実行される。
【０２９７】
続いて、図１１〜１３を参照して第３実施形態について説明する。第３実施形態でも図４のコンピュータ３００が使われる。コンピュータ３００のハードウェア構成は、例えば図３のようであってもよい。
【０２９８】
ただし、第３実施形態では、図４の管理表３１２と定数データ３１３として、具体的には、図６の管理表５０１と定数データ５０２ではなく、図１１の管理表６０１と定数データ６０２が使われる。
【０２９９】
また、情報取得部３１０とメモリ取得部３１１の動作が、第２実施形態と第３実施形態では異なる。つまり、図８と図１０のフローチャートの処理は、第３実施形態では、図１２と図１３のフローチャートの処理に置き換えられる。
その他の点は、第２実施形態と同様である。よって、以下では、第２実施形態との共通点に関しては説明を省略する。
【０３００】
図１１は、第３実施形態で使われるデータを示す図である。図１１の管理表６０１は、複数のメモリサイズのそれぞれについて、メモリ割り当ての試みにかかる時間の基準値および閾値、前回の実際の試みで測定された時間、ならびに、メモリ割り当てのためのライブラリ関数の最終呼び出し時刻を含む。
【０３０１】
メモリサイズの個数は任意であるが、第３実施形態では説明の便宜上、４とする。サイズ番号１は、４ＫＢ以下のサイズを示す。例えば、ＯＳ３０２が規定するページサイズが４ＫＢの場合、図１１に示すように、ページサイズ以下のサイズが、最も小さいサイズとして定義されてもよい。
【０３０２】
また、サイズ番号２は、４ＫＢより大きく、４００ＫＢ以下のサイズを示す。サイズ番号３は、４００ＫＢより大きく、４０ＭＢ（メガバイト）以下のサイズを示す。サイズ番号４は、４０ＭＢより大きいサイズを示す。
【０３０３】
管理表６０１は、各サイズ番号ｊ（１≦ｊ≦４）について、ｊ番のサイズのメモリの割り当ての試みにかかる時間に関する、基準値ＲＥＦｊと閾値ＴＨｊを含む。また、管理表６０１は、各サイズ番号ｊ（１≦ｊ≦４）について、ｊ番のサイズのメモリの割り当り当てが前回試みられたときにかかった時間ＰＲＥＶｊと、そのメモリ割り当て試みのためにライブラリ関数が呼び出された時刻ＬＴｊも含む。
【０３０４】
図１１の例では、基準値ＲＥＦｊと、閾値ＴＨｊと、実際に測定された時間ＰＲＥＶｊの単位は、いずれもμｓである。また、最終呼び出し時刻ＬＴｊは、ｍｓ（ミリセカンド）単位の精度で、例えば「ｙｙｙｙ／ｍｍ／ｄｄ  ｈｈ：ｍｍ：ｓｓ．ｓｓｓ」形式で表されていてもよいし、これとは別の精度で表されていてもよい。
【０３０５】
なお、以上のような管理表６０１は、図７のステップＳ２０１において、例えば次のように初期化されてもよい。基準値ＲＥＦｊと閾値ＴＨｊと前回測定された時間ＰＲＥＶｊは、ゼロに初期化されてもよい。また、最終呼び出し時刻ＬＴｊは、時刻として無効な特殊な値（例えば、全ビットが０にリセットされた値）に初期化されてもよい。
【０３０６】
また、定数データ６０２は、図６の定数データ５０２と同様に、リトライ有効性フラグＲＴ＿ＦＬＡＧと、リトライ待ち時間ＲＴ＿ＷＡＩＴと、リトライカウンタの初期値ＲＴ＿ＣＮＴを含む。
【０３０７】
また、定数データ６０２は、定数データ５０２と同様に、メモリ割り当ての試みにかかる時間に関する係数ＣＯ＿ＡＬＬＯＣを含む。ただし、第３実施形態では、係数ＣＯ＿ＡＬＬＯＣの用途が第２実施形態とは異なる。詳しくは図１２とともに後述するとおり、第３実施形態では、管理表６０１中の閾値ＴＨｊが、式（１４）〜（１７）のように基準値ＲＥＦｊから計算される。
TH1=REF1×CO_ALLOC          (14)
TH2=REF2×CO_ALLOC          (15)
TH3=REF3×CO_ALLOC          (16)
TH4=REF4×CO_ALLOC          (17)
【０３０８】
また、詳しくは図１３とともに後述するとおり、第３実施形態では、前回のメモリ割り当ての試みの際に測定された時間ＰＲＥＶｊが閾値ＴＨｊと比較されることがある。しかし、あまりにも古いデータを用いた比較は、不適切な判断の要因になりかねない。そこで、定数データ６０２により、メモリ割り当てのためのライブラリ関数の前回の呼び出しからの有効期間ＶＡＬＩＤ＿ＤＵＲも定義される。有効期間ＶＡＬＩＤ＿ＤＵＲは、時間の長さを示す。
【０３０９】
さらに、定数データ６０２は、各サイズ番号ｊ（１≦ｊ≦４）について、ｊ番のメモリサイズの代表値ＳＺｊも含む。例えば、図１１の例では、１番のメモリサイズの代表値ＳＺ１は、１番のメモリサイズの上限値の４ＫＢである。
【０３１０】
同様に、２番のメモリサイズの代表値ＳＺ２は、２番のメモリサイズの上限値の４００ＫＢであり、３番のメモリサイズの代表値ＳＺ３は、３番のメモリサイズの上限値の４０ＭＢである。また、４番のメモリサイズの代表値ＳＺ４は、例えば４ＧＢ（ギガバイト）である。
【０３１１】
さて、以下では図１２〜１３のフローチャートを参照して、第３実施形態のコンピュータ３００の動作についてさらに詳しく説明する。なお、上述のとおり、図７と図９のフローチャートは第２実施形態と第３実施形態で共通である。第２実施形態との相違点は、第３実施形態では、図７のステップ２０２から図８の処理ではなく図１２の処理が呼び出され、図９のステップＳ４０４から図１０の処理ではなく図１３の処理が呼び出される点である。
【０３１２】
図１２は、第３実施形態における低負荷時の情報取得処置のフローチャートである。図１２の処理は、図７のステップＳ２０２から呼び出される。
なお、説明の簡単化のため、システム試験は他のユーザアプリケーションの実行中には実行されないものとする。すると、ステップＳ２０２の実行時点でのコンピュータ３００の負荷は低い。したがって、図１２の処理によって、情報取得部３１０は、コンピュータ３００の負荷が低いときに各種情報を取得することができる。
【０３１３】
また、図８に関する仮定と同様に、説明の簡単化のため、図１２の処理においても、メモリ割り当ての試みは成功するものと仮定する。しかし、実施形態によっては、もちろん、メモリ割り当てが失敗する場合のためのエラー処理がさらに行われてもよい。
【０３１４】
さて、ステップＳ６０１で情報取得部３１０は、管理表６０１のサイズ番号を示すインデックス変数ｊを１に初期化する。
そして、次のステップＳ６０２で情報取得部３１０は、定数データ６０２を参照し、ｊ番目のメモリサイズの代表値ＳＺｊを読み取る。
【０３１５】
続いて、ステップＳ６０３で情報取得部３１０は、メモリ取得・解放部３１７と時間測定部３１６を呼び出す。具体的には、メモリ取得部３１１は、読み取ったサイズＳＺｊのメモリの割り当てをメモリ取得・解放部３１７に試みさせるとともに、その試みにかかる時間を時間測定部３１６に測定させる。ステップＳ６０３の詳細は、要求されるメモリサイズ以外は、図８のステップＳ３０７と同様である。
【０３１６】
次に、ステップＳ６０４で情報取得部３１０は、ステップＳ６０３で測定された時間を、ｊ番目のメモリサイズの測定時間の基準値ＲＥＦｊとして管理表６０１に格納する。
また、次のステップＳ６０５で情報取得部３１０は、定数データ６０２を参照して係数ＣＯ＿ＡＬＬＯＣを読み取り、式（１４）〜（１７）のいずれかにしたがって閾値ＴＨｊを計算する。そして、情報取得部３１０は、計算した閾値ＴＨｊを管理表６０１に格納する。
【０３１７】
そして、ステップＳ６０６で情報取得部３１０は、ステップＳ６０３で取得したメモリを解放するためにメモリ取得・解放部３１７を呼び出す。すると、メモリ取得・解放部３１７がメモリを解放する。
【０３１８】
その後、ステップＳ６０７で情報取得部３１０は、インデックス変数ｊの値が、図１１の管理表６０１において定義されているメモリサイズの個数（説明の便宜上、この個数を「Ｑ」と表記する）に達したか否かを判断する。なお、図１１の例ではＱ＝４である。
【０３１９】
もし、ｊ＝Ｑであれば、図１２の処理は終了する。逆に、ｊ＜Ｑであれば、処理はステップＳ６０８に移行する。
ステップＳ６０８で情報取得部３１０は、変数ｊを１だけインクリメントする。そして、処理はステップＳ６０２に戻る。
【０３２０】
以上のようにして、図１２の処理により、１≦ｊ≦Ｑを満たすすべてのｊについて、管理表６０１には基準値ＲＥＦｊと閾値ＴＨｊが設定される。
続いて、第３実施形態において図９のステップＳ４０４から呼び出されるメモリ取得処理について説明する。図１３は、第３実施形態におけるメモリ取得処理のフローチャートである。なお、ステップＳ４０４では、試験実行部がステップＳ４０２で決定したサイズのメモリの割り当てが要求される。以下では説明の便宜上、要求されるメモリサイズを「ｓｚ＿ｒｅｑ」と表記する。
【０３２１】
ステップＳ７０１でメモリ取得部３１１は、試験実行部から要求されたメモリサイズｓｚ＿ｒｅｑに対応する前回の呼び出し時刻ＬＴｊ（１≦ｊ≦Ｑ）が有効か否かを判断する。
【０３２２】
例えば、要求されたメモリサイズｓｚ＿ｒｅｑが１００ＫＢとする。この場合、図１１の管理表６０１によれば、要求されたメモリサイズｓｚ＿ｒｅｑは、サイズ番号２の範囲に含まれる。よって、メモリ取得部３１１は、管理表６０１から前回の呼び出し時刻ＬＴ２を読み出す。
【０３２３】
そして、メモリ取得部３１１は、読み出した時刻ＬＴｊ（上記のｓｚ＿ｒｅｑ＝１００ＫＢの例ではｊ＝２）が有効か否かを判断する。なお、図１３についての以下の説明において、添え字「ｊ」は、要求されたメモリサイズｓｚ＿ｒｅｑに対応するメモリサイズの番号を示す。
【０３２４】
図１１に関して説明したとおり、各最終呼び出し時刻ＬＴｊは、時刻として無効な特殊な値（例えば、全ビットが０にリセットされた値）に初期化される。したがって、ｊ番のサイズのメモリの割り当てが最初に試験実行部から要求された場合には、メモリ取得部３１１が読み出した時刻ＬＴｊは、時刻として無効な特殊な値に設定されている。時刻ＬＴｊが、時刻として無効な特殊な値に設定されている場合、当然、時刻ＬＴｊは無効である。
【０３２５】
また、たとえ時刻ＬＴｊが時刻として意味のある値に設定されているとしても、時刻ＬＴｊが古すぎるならば、時刻ＬＴｊは無効である。よって、時刻ＬＴｊが、時刻として意味のある値に設定されている場合、メモリ取得部３１１は、定数データ６０２から有効期間ＶＡＬＩＤ＿ＤＵＲを読み出すとともに、現在時刻を取得する。例えば、メモリ取得部３１１は、時間測定部３１６を呼び出すことで、時間測定部３１６の時刻取得機能により、現在時刻を取得してもよい。
【０３２６】
そして、メモリ取得部３１１は、現在時刻と時刻ＬＴｊの差分を計算し、計算した差分を有効期間ＶＡＬＩＤ＿ＤＵＲと比較する。
もし、差分が有効期間ＶＡＬＩＤ＿ＤＵＲを越えていれば、メモリ取得部３１１は、「時刻ＬＴｊは無効な時刻（つまり古い時刻）である」と判断する。逆に、差分が有効期間ＶＡＬＩＤ＿ＤＵＲ以内ならば、メモリ取得部３１１は、「時刻ＬＴｊは有効な時刻（つまり新しい時刻）である」と判断する。
【０３２７】
そして、時刻ＬＴｊが有効な場合（すなわち、時刻ＬＴｊが、時刻として意味を持つ値であって、しかも新しい有効な時刻である場合）、前回測定された時間ＰＲＥＶｊを用いた判定を実行するために、処理はステップＳ７０２に移行する。逆に、時刻ＬＴｊが無効な場合（すなわち、時刻ＬＴｊが、時刻として意味を持たない特殊な値に設定されているか、または、無効な古い時刻である場合）、メモリ割り当てを試みるため、処理はステップＳ７０４へ移行する。
【０３２８】
ステップＳ７０２でメモリ取得部３１１は、「前回の測定時間ＰＲＥＶｊが、時間の長さとして有効であり、かつ、閾値ＴＨｊ以下である」という条件が成立するか否かを判断する。
【０３２９】
図１１に関して説明したように、前回の測定時間ＰＲＥＶｊは、サイズ番号ｊの範囲に含まれる或るサイズのメモリの割り当てが時刻ＬＴｊに試みられたときに、その試みにかかった時間である。換言すれば、前回の測定時間ＰＲＥＶｊは、第３実施形態における「特定の処理」の実行にかかった時間である。
【０３３０】
すなわち、ステップＳ７０２でメモリ取得部３１１は、図１のステップＳ１０２と類似の判断を行う。具体的には、メモリ取得部３１１は、前回の測定時間ＰＲＥＶｊが、時間の長さとして有効な値に設定されているか否かをまず判断する。
【０３３１】
後述のとおり、ｊ番目のメモリサイズに関しての前回のメモリ割り当ての要求に対して、リトライカウンタの初期値ＲＴ＿ＣＮＴの回数だけメモリの割り当てを試みてもなお、割り当てが成功しなかった場合、前回測定時間ＰＲＥＶｊは、無効な値に設定される。よって、メモリ取得部３１１はまず、前回の測定時間ＰＲＥＶｊが、時間の長さとして有効な値に設定されているか否かを判断する。
【０３３２】
そして、もし前回の測定時間ＰＲＥＶｊが、時間の長さとして有効な値に設定されていれば、メモリ取得部３１１はさらに、前回の測定時間ＰＲＥＶｊが、同じメモリサイズに対応する閾値ＴＨｊ以下か否かを判断する。
【０３３３】
前回の測定時間ＰＲＥＶｊが、時間の長さとして有効であり、かつ、閾値ＴＨｊ以下の場合は、メモリ割り当ての試みが成功する見込みは高い。なぜなら、この場合、前回の測定時間ＰＲＥＶｊは、「有効期間ＶＡＬＩＤ＿ＤＵＲ以内の近い過去に実行されたメモリ割り当ての試みが、閾値ＴＨｊ以下の比較的短い時間で完了している」という事実を示すからである。この事実から、「コンピュータ３００の負荷は、最近は、極端に高くはない」と考えられる。よって、処理はステップＳ７０４に移行する。
【０３３４】
逆に、前回の測定時間ＰＲＥＶｊが、時間の長さとして無効な値に設定されているか、または、閾値ＴＨｊより長い場合、メモリ割り当ての試みが失敗する見込みが高い。なぜなら、時間の長さとして無効な値に設定された前回の測定時間ＰＲＥＶｊは、「有効期間ＶＡＬＩＤ＿ＤＵＲ以内の近い過去に実行されたメモリ割り当ての試みが、リトライにもかかわらず最終的に失敗した」という事実を示すからである。また、閾値ＴＨｊより長い前回の測定時間ＰＲＥＶｊは、「有効期間ＶＡＬＩＤ＿ＤＵＲ以内の近い過去に実行されたメモリ割り当ての試みが、最終的には成功したものの、長時間かかった」という事実を示すからである。これらの事実から、「コンピュータ３００の負荷は、最近は非常に高いので、今すぐメモリ割り当てを試みても、おそらく試みは失敗する」と考えられる。よって、処理はステップＳ７０３に移行する。
【０３３５】
ステップＳ７０３でメモリ取得部３１１は、所定時間待つ。具体的には、メモリ取得部３１１は定数データ６０２中のリトライ待ち時間ＲＴ＿ＷＡＩＴの値を読み取る、そして、メモリ取得部３１１は、リトライ待ち時間ＲＴ＿ＷＡＩＴだけ待つ。リトライ待ち時間ＲＴ＿ＷＡＩＴが経過すると、処理はステップＳ７０４に移行する。
【０３３６】
なお、以上の説明から理解されるとおり、ステップＳ７０１とＳ７０２は、図１のステップＳ１０２に対応する。つまり、第３実施形態における「特定の処理」は、有効期間ＶＡＬＩＤ＿ＤＵＲ以内に実行されたメモリ割り当ての試みであり、第３実施形態における判定条件は式（６）の条件Ｃである。
【０３３７】
そして、ステップＳ７０１またはＳ７０２からステップＳ７０４への移行は、ステップＳ１０２からステップＳ１０３への移行に対応する。また、ステップＳ７０３はステップＳ１０５に対応する。つまり、ステップＳ７０２からステップＳ７０３への移行は、ステップＳ１０２からステップＳ１０５への移行に対応する。
【０３３８】
そして、以上の対応関係から明らかなように、図１のステップＳ１０１における要求の受け付けは、図９のステップＳ４０４からの図１３の処理の呼び出しに対応する。つまり、第３実施形態では、メモリ取得部３１１が試験実行部からステップＳ１０１でメモリ割り当ての要求を受け付ける。
【０３３９】
さて、ステップＳ７０４でメモリ取得部３１１は、定数データ６０２中のリトライカウンタの初期値ＲＴ＿ＣＮＴを読み取り、リトライカウンタに初期値ＲＴ＿ＣＮＴを設定する。例えば、初期値ＲＴ＿ＣＮＴは、２から５程度の比較的小さな数であってもよい。
【０３４０】
なお、第３実施形態では、図９のステップＳ４０３と図１３のステップＳ７０４で同じ初期値ＲＴ＿ＣＮＴが使われる。しかし、実施形態によっては、定数データ６０２において、ステップＳ４０３用の初期値とステップＳ７０４用の初期値が別々に定義されていてもよい。
【０３４１】
続いて、ステップＳ７０５〜Ｓ７０７でメモリ取得部３１１は、試験実行部から指定されたサイズｓｚ＿ｒｅｑのメモリの割り当てをメモリ取得・解放部３１７に試みさせるとともに、その試みにかかる時間を時間測定部３１６に測定させる。
【０３４２】
具体的には、まずステップＳ７０５で、メモリ取得部３１１からの呼び出しに応じて、時間測定部３１６が現在時刻を取得する。時間測定部３１６は、取得した現在時刻をメモリ取得部３１１に通知する。
【０３４３】
次に、ステップＳ７０６でメモリ取得部３１１がメモリ取得・解放部３１７を呼び出す。メモリ取得部３１１によるメモリ取得・解放部３１７の呼び出しは、具体的には、例えば、ｍａｌｌｏｃ（）などのメモリ割り当てのためのライブラリ関数の呼び出しにより実現されてもよい。呼び出されたメモリ取得・解放部３１７は、試験実行部により指定されたサイズｓｚ＿ｒｅｑのメモリの割り当てを試みる。
【０３４４】
そして、ステップＳ７０７で、メモリ取得部３１１が時間測定部３１６を呼び出し、時間測定部３１６は再び現在時刻を取得する。また、時間測定部３１６は、ステップＳ７０５とＳ７０７で取得した２つの時刻の差分を計算し、計算した差分をメモリ取得部３１１に通知する。
【０３４５】
その後、ステップＳ７０８でメモリ取得部３１１は、ステップＳ７０６でのメモリ割り当てが成功したか否かを判断する。
例えば、メモリ取得・解放部３１７は、メモリ割り当てに成功すると、割り当てたメモリ領域の先頭を指すポインタをメモリ取得部３１１に返すとともに、正常終了を示す値を終了コードとして設定してもよい。また、メモリ取得・解放部３１７は、メモリ割り当てに失敗すると、ＮＵＬＬポインタをメモリ取得部３１１に返すとともに、異常終了を示す値を終了コードとして設定してもよい。したがって、メモリ取得部３１１はステップＳ７０８において、メモリ取得・解放部３１７からの返り値、終了コード、または、その双方を用いることにより、メモリ割り当てが成功したか否かを判断することができる。
【０３４６】
そして、ステップＳ７０６でメモリ割り当てが成功した場合、処理はステップＳ７０８からステップＳ７０９へと移行する。逆に、ステップＳ７０６でメモリ割り当てが失敗した場合、処理はステップＳ７０８からステップＳ７１０へと移行する。
【０３４７】
ステップＳ７０９でメモリ取得部３１１は、次のように動作する。
すなわち、メモリ取得部３１１は、ステップＳ７０５で時間測定部３１６が取得した現在時刻を、最終呼び出し時刻ＬＴｊとして管理表６０１に格納する。また、メモリ取得部３１１は、ステップＳ７０７で時間測定部３１６が計算した時間を、前回の測定時間ＰＲＥＶｊとして管理表６０１に格納する。
【０３４８】
さらに、メモリ取得部３１１は、正常終了を示す値を終了コードとして設定する。また、メモリ取得部３１１は、試験実行部への返り値として、メモリ取得・解放部３１７からの返り値（すなわち、メモリ取得・解放部３１７により取得されたメモリ領域を指すポインタ）を設定する。そして、メモリ取得処理は終了する。
【０３４９】
他方、メモリ割り当てが失敗した場合、ステップＳ７１０でメモリ取得部３１１は、定数データ６０２中のリトライフラグＲＴ＿ＦＬＡＧの値を読み取る。そして、リトライフラグＲＴ＿ＦＬＡＧが、「リトライが有効である」と示していれば、処理はステップＳ７１１に移行する。逆に、リトライフラグＲＴ＿ＦＬＡＧが、「リトライが無効である」と示していれば、処理はステップＳ７１４に移行する。
【０３５０】
ステップＳ７１１でメモリ取得部３１１は、リトライカウンタをデクリメントする。そして、次のステップＳ７１２でメモリ取得部３１１は、リトライカウンタの値がゼロか否かを判断する。
【０３５１】
リトライカウンタの値がゼロの場合、処理はステップＳ７１４に移行する。逆に、リトライカウンタの値が１以上の場合、処理はステップＳ７１３に移行する。
ステップＳ７１３でメモリ取得部３１１は、定数データ３１３中のリトライ待ち時間ＲＴ＿ＷＡＩＴの値を読み取る。そして、メモリ取得部３１１は、リトライ待ち時間ＲＴ＿ＷＡＩＴだけ待つ。リトライ待ち時間ＲＴ＿ＷＡＩＴが経過すると、処理はステップＳ７０５に戻る。
【０３５２】
なお、ステップＳ７０３とＳ７１３でメモリ取得部３１１が所定時間ＲＴ＿ＷＡＩＴだけ待つ理由は、図９のステップＳ４１１に関して説明した理由と同様である。
また、第３実施形態では、図９のステップＳ４０８と図１０のステップＳ７１０で、同じリトライフラグＲＴ＿ＦＬＡＧが参照される。そして、図９のステップＳ４１１ならびに図１０のステップＳ７０３およびＳ７１３で、同じリトライ待ち時間ＲＴ＿ＷＡＩＴが参照される。
【０３５３】
しかし、実施形態によっては、定数データ６０２において、ステップＳ４０８用とステップＳ７１０用のリトライフラグが別々に定義されていてもよい。同様に、定数データ６０２において、ステップＳ４１１用の待ち時間と、ステップＳ７０３用の待ち時間と、ステップＳ７１３用の待ち時間が、別々に定義されていてもよい。
【０３５４】
さて、メモリ取得部３１１は、リトライの余地がないとステップＳ７１０またはＳ７１２で判断した場合、ステップＳ７１４において次のように動作する。
すなわち、メモリ取得部３１１は、ステップＳ７０５で時間測定部３１６が取得した現在時刻を、最終呼び出し時刻ＬＴｊとして管理表６０１に格納する。また、メモリ取得部３１１は、エラーを示す特殊な値（例えば、全ビットが１にセットされた値）を、前回の測定時間ＰＲＥＶｊとして管理表６０１に格納する。この特殊な値は、時間の長さとしては無効な値である。
【０３５５】
さらに、メモリ取得部３１１は、異常終了を示す値を終了コードとして設定する。また、メモリ取得部３１１は、メモリ割り当てのためのライブラリ関数の返り値（すなわち、メモリ取得・解放部３１７からの返り値であるＮＵＬＬポインタ）を、試験実行部への返り値として設定する。そして、メモリ取得処理は終了する。
【０３５６】
なお、図１３のステップＳ７０６におけるメモリ取得・解放部３１７の呼び出しによるメモリ割り当ての試みは、図１のステップＳ１０３に相当する。そして、ステップＳ７０９とＳ７１４は、図１のステップＳ１０４に相当する。
【０３５７】
ある観点から見れば、図１のフローチャートＦ１の処理は、図１３の処理においてリトライが行われない場合（例えば、リトライフラグＲＴ＿ＦＬＡＧによりリトライが無効にされているか、または、リトライカウンタの初期値ＲＴ＿ＣＮＴが１の場合）の例である。別の観点から見れば、図１３の処理は、図１のフローチャートＦ１のステップＳ１０３とＳ１０４の間にリトライ制御が追加された処理である。
【０３５８】
以上説明した第３実施形態によれば、メモリ割り当ての試みが失敗しそうな高負荷状況下でメモリ割り当てが要求されると、メモリ割り当ての試みは延期される。したがって、実際にメモリ割り当てが試みられる時点では、コンピュータ３００全体の負荷も下がっている可能性がある。つまり、延期により、メモリ割り当てが成功する見込みが高まる。
【０３５９】
よって、第３実施形態によれば、高負荷状況下でのメモリ割り当ての試みに起因する効率悪化、ストール、ハングなどの問題が軽減される。そのため、効率よく順調にシステム試験が実行される。
【０３６０】
ところで、以上説明した第２実施形態と第３実施形態を比較すると、それぞれには次のような特徴がある。
第２実施形態では、メモリ割り当てを試みるか否かを決定するために、コンピュータ３００全体の負荷を示す客観的な証拠が集められる。具体的には、図５と図１０に示すように、客観的な証拠として、メモリ使用量の値ｕ＿ｍｅｍとＣＰＵ使用量の値ｕ＿ｃｐｕが取得される。
【０３６１】
そして、証拠集めのために、メモリ使用量測定部３１５とＣＰＵ負荷測定部３１４が適宜の処理を実行する。換言すれば、メモリ使用量測定部３１５とＣＰＵ負荷測定部３１４を実現するコマンドまたはシステムコールを、ＣＰＵ２０１が実行する。
【０３６２】
ここで、同じ処理の実行にかかる時間は、コンピュータ３００の負荷が低いときよりも、コンピュータ３００の負荷が高いときの方が長い。よって、メモリ使用量の値とＣＰＵ使用量の値を取得するための処理の実行時間も、コンピュータ３００の負荷を示す客観的な証拠として利用可能である。
【０３６３】
そこで、第２実施形態では、図５と図１０に示すように、メモリ使用量の値ｕ＿ｍｅｍとＣＰＵ使用量の値ｕ＿ｃｐｕだけでなく、それぞれの値を取得するのにかかった時間ｔ＿ｍｅｍとｔ＿ｃｐｕも、メモリ割り当てを試みるか否かを決定するために使われる。また、図５に関して説明した理屈から、図１０のステップＳ５０３とＳ５０５に示すように、第２実施形態では、実行時間の方が使用量よりも優先的に、「メモリ割り当てを試みるか否か」の判断に使われる。
【０３６４】
さて、第２実施形態は上記のとおり、「ある種の処理の実行時間は、コンピュータ３００全体の負荷を示す客観的な証拠として利用可能である」という考察に基づく。第３実施形態は、この考察に基づいている点では第２実施形態と共通である。そして、ある観点から言えば、第３実施形態はこの考察に基づいて、さらにメモリ取得処理におけるオーバヘッドを減らそうとする実施形態である。
【０３６５】
第２実施形態のメモリ取得処理におけるオーバヘッドとは、具体的には、図５のステップＳ５０１とＳ５０２における、メモリ使用量測定部３１５とＣＰＵ負荷測定部３１４による処理である。一方、上記の考察と、第２実施形態において実行時間の方が使用量より優先的に考慮される理由から明らかなように、コンピュータ３００全体の負荷を示す客観的な証拠として、メモリ使用量の値ｕ＿ｍｅｍとＣＰＵ使用量の値ｕ＿ｃｐｕが常に必要なわけではない。
【０３６６】
つまり、実行時間がコンピュータ３００全体の負荷を反映するような適宜の処理が既に実際に実行されているのなら、当該処理の実行時間を、コンピュータ３００全体の負荷を示す客観的な証拠として採用することにより、オーバヘッドを減らすことができる。換言すれば、第３実施形態は、メモリ割り当ての試みが成功しそうか否かに関する予測の正確性とオーバヘッドとのバランスを考慮するにあたって、オーバヘッドを減らすことをより重視した実施形態である。
【０３６７】
そして、第３実施形態では、上記の「適宜の処理」が、具体的には、有効期間ＶＡＬＩＤ＿ＤＵＲにより規定される所定範囲内の過去に実際に実行されたメモリ割り当ての試みなのである。なお、ある範囲内の間隔でメモリ割り当ての要求が繰り返される場合の例としては、例えば、以下のような場合がある。
【０３６８】
図７に示すように、複数の試験対象装置に対して、順々に、または並行して、ステップＳ２０５の試験実行処理が実行される。すると、各試験にかかる時間にもよるが、図９のステップＳ４０４のメモリ取得処理が、ある程度の短い間隔で何度も実行されることがあり得る。
【０３６９】
また、図７では説明の簡単化のため、１つの試験対象装置に対してステップＳ２０５が１回だけ実行されるように図示されている。しかし、試験制御部３０５は、１つの試験対象装置に対して複数の試験条件を決定してもよく、複数の試験条件のそれぞれについてステップＳ２０５と同様に図９の処理を呼び出してもよい。つまり、複数の試験条件のそれぞれについて、図９のステップＳ４０４のメモリ取得処理が実行されてもよい。
【０３７０】
そして、図９のステップＳ４０４のメモリ取得処理は、第３実施形態では具体的には図１３の処理である。よって、ある程度の短い間隔でステップＳ４０４のメモリ取得処理が繰り返し実行されれば、図１３のステップＳ７０６におけるメモリ割り当ての試みも、ある程度の短い間隔で繰り返される。
【０３７１】
また、システム試験プログラム以外の任意のアプリケーションにおいても、ある範囲内の間隔でメモリ割り当ての要求が繰り返されることがあり得る。よって、第３実施形態の図１３と同様のメモリ取得処理は、システム試験プログラム以外の任意のアプリケーションにも適用可能である。もちろん、第２実施形態の図１０と同様のメモリ取得処理も、システム試験プログラム以外の任意のアプリケーションに適用可能である。
【０３７２】
ところで、本発明は上記の第１〜第３実施形態に限られるものではない。上記の説明においてもいくつかの変形について説明したが、上記実施形態は、さらに例えば下記の観点から様々に変形することができる。上記の各実施形態および下記の各種変形は、相互に矛盾しない限り、任意に組み合わせることが可能である。
【０３７３】
変形の第１の観点は、閾値に関する。上記実施形態におけるいくつかの処理は、閾値との比較を含む（例えば、図１０のステップＳ５０３およびＳ５０５、ならびに図１３のステップＳ７０２など）。閾値との比較は、実施形態により「比較対象の数値が、閾値を超えるか否か」を判断する処理でもよいし、「比較対象の数値が、閾値以上か否か」を判断する処理でもよい。また、管理表５０１と６０１中の種々の値は、実施形態に応じて適宜任意に決められてよい。
【０３７４】
変形の第２の観点は、コンピュータのハードウェア構成と判定条件に関する。
図３には、１台のＣＰＵ２０１のみが図示されているが、コンピュータ２００は、複数のＣＰＵを含むマルチプロセッサシステムであってもよい。また、図３のＲＡＭ２０２は、具体的には複数のＤＩＭＭ上に分散していてもよい。
【０３７５】
また、ＮＵＭＡ（Non-Uniform Memory Architecture）システムにも上記実施形態は適用可能である。ＮＵＭＡシステムは、互いに接続された複数のノードを含み、各ノードはＣＰＵとＲＡＭを含む。よって、ＮＵＭＡシステムには、複数のＣＰＵと複数のメモリモジュールが含まれる。
【０３７６】
上記の例のように複数のＣＰＵが存在する場合には、図１０のステップＳ５０５における「ＣＰＵ負荷が大」という条件は、「複数のＣＰＵすべてにおいて負荷が大」という意味である。また、物理的に複数のメモリモジュールが存在する場合には、図１０のステップＳ５０５における「メモリ使用量が大」という条件は、「複数のメモリモジュールすべてにおいてメモリ使用量が大」という意味である。
【０３７７】
つまり、図１０の処理は、次のように一般化されてもよい。ステップＳ５０１では、コンピュータが有する１つまたは複数のメモリモジュールのそれぞれについて、メモリ使用量の値ｕ＿ｍｅｍが取得される。また、ステップＳ５０２では、コンピュータが有する１つまたは複数のＣＰＵのそれぞれについて、ＣＰＵ使用量の値ｕ＿ｃｐｕが取得される。
【０３７８】
そして、以下の（１１−１）または（１１−２）の条件が成立するとき、図１０の処理はステップＳ５０３からステップＳ５０５に移行する。逆に、（１１−１）と（１１−２）のどちらの条件も成立しないとき、図１０の処理はステップＳ５０３からステップＳ５０４に移行する。
【０３７９】
（１１−１）閾値ＴＨ＿ＭＥＭ以下の時間でメモリ使用量の値ｕ＿ｍｅｍを取得することができたメモリモジュールが、少なくとも１つはある。
（１１−２）閾値ＴＨ＿ＣＰＵ以下の時間でＣＰＵ使用量の値ｕ＿ｃｐｕを取得することができたＣＰＵが、少なくとも１つはある。
【０３８０】
また、以下の（１２−１）または（１２−２）の条件が成立するとき、図１０の処理はステップＳ５０５からステップＳ５０６へと移行する。逆に、（１２−１）と（１２−２）のどちらの条件も成立しないとき、図１０の処理はステップＳ５０５からステップＳ５０４に移行する。
【０３８１】
（１２−１）メモリ使用量の値ｕ＿ｍｅｍが閾値ＨＩ＿ＭＥＭ以下のメモリモジュールが、少なくとも１つはある。
（１２−２）ＣＰＵ使用量の値ｕ＿ｃｐｕが閾値ＨＩ＿ＣＰＵ以下のＣＰＵが、少なくとも１つはある。
【０３８２】
上記のように図１０の処理が一般化され得る理由は、次のとおりである。物理的に十分な空き領域のあるメモリモジュールが１つでもあれば、当該メモリモジュール上に新たなメモリ領域を成功裡に割り当てられる見込みが高い。また、低負荷のＣＰＵが１つでもあれば、たとえ、ディスクＩＯのためなどの何らかの目的でＯＳにより一時的に使用されているメモリ領域があっても、低負荷のＣＰＵによって、当該メモリ領域を解放するための処理が順調に遂行される見込みが高い。したがって、図５に関して説明した理由を敷衍すると、上記のように図１０の処理は一般化され得る。
【０３８３】
なお、以上のように図１０の処理が一般化される場合も、図６の管理表５０１と定数データ５０２が利用可能である。同様に、ＣＰＵまたはメモリモジュールが複数ある場合も、図１１の管理表６０１と定数データ６０２が利用可能である。
【０３８４】
例えば、コンピュータ全体に１つの管理表６０１があってもよい。その場合、複数のＣＰＵのうちどのＣＰＵが図１３の処理を行った場合にも、同じ管理表６０１がステップＳ７０９またはＳ７１４で更新される。あるいは逆に、ＣＰＵごとに管理表６０１が設けられていてもよい。
【０３８５】
変形の第３の観点は、割り当て制御（すなわち、割り当て要求に応じてメモリ割り当てを試みるか否かの判断）が実装されるレベルに関する。
第２実施形態と第３実施形態では、メモリ取得部３１１がアプリケーション３０１の層に含まれることから明らかなように、割り当て制御がアプリケーションレベルに実装される。しかし、第１実施形態に関して説明したとおり、割り当て制御は、ライブラリ関数またはＯＳのカーネル内部に実装されてもよい。あるいは、ライブラリ関数またはシステムコールをフックするフック関数が定義されてもよく、フック関数において割り当て制御が実装されてもよい。
【０３８６】
また、第２実施形態または第３実施形態と同様の制御が、システム試験以外のアプリケーション内に実装されてもよいことは無論である。そして、第２実施形態と第３実施形態に関する説明では、ｍａｌｌｏｃ（）のようなライブラリ関数が使われる場合を例示したが、もちろん、アプリケーションからライブラリ関数を介さずに直接システムコールが呼び出されてもよい。
【０３８７】
また、実施形態に応じて、ｍａｌｌｏｃ（）以外のライブラリ関数（例えばｃａｌｌｏｃ（）やｖａｌｌｏｃ（）など）が使われてもよい。そして、メモリ割り当てのためには、上記に例示したｍｍａｐ（）以外のシステムコール（例えばｂｒｋ（））が使われることもある。
【０３８８】
なお、割り当て制御がライブラリ関数またはカーネル内部に実装される場合は、ライブラリ関数またはカーネル内部では、リトライも所定時間の待機も、行われないことが好ましい。なぜなら、ライブラリ関数やシステムコールは、任意のアプリケーションから呼び出される可能性があるからである。そして、あるアプリケーションにとって適切なリトライ回数または待ち時間は、別のアプリケーションにとっては不適切かもしれないからである。よって、ライブラリ関数またはカーネル内部に割り当て制御が実装される場合は、次のような変形が好ましい。
【０３８９】
例えば、待ち時間を示す変数と、「待ち時間を示す変数に設定された時間だけ待ってから、再度メモリ割り当てを要求することが推奨される」と示すための特定の値が定義されていてもよい。以下ではこの特定の値を、説明の便宜上「リトライ推奨コード」という。
【０３９０】
そして、図１のフローチャートＦ１からはステップＳ１０５が削除されてもよい。その代わり、ステップＳ１０２において判定条件が成立する場合、メモリ割り当て制御部１０６は、上記変数に待ち時間を設定するとともに、終了コードを示す変数にリトライ推奨コードを設定し、フローチャートＦ１の処理を終了してもよい。なお、フローチャートＦ２は、変形されなくてもよい。
【０３９１】
また、図１０の処理において、ステップＳ５０６およびＳ５１０〜Ｓ５１４は削除されてもよい。そして、割り当てが失敗したとステップＳ５０８で判断された場合、処理はステップＳ５０８からステップＳ５１５へと移行してもよい。なお、この場合、ステップＳ５１５において、終了コードを示す変数には、異常終了を示す値の代わりに、リトライ推奨コードが設定されてもよい。そして、待ち時間を示す変数に、適宜の値（例えば図６のリトライ待ち時間の値ＲＴ＿ＷＡＩＴ）が設定されてもよい。
【０３９２】
また、図１３の処理は次のように変形されてもよい。すなわち、ライブラリ関数またはカーネル内部に実装されるように変形されたメモリ取得部３１１は、ステップＳ７０３で所定時間待つ代わりに、（１３−１）〜（１３−４）のように動作してもよい。メモリ取得部３１１は、（１３−１）〜（１３−４）のように動作した後、図１３のメモリ取得処理を終了する。
【０３９３】
（１３−１）メモリ取得部３１１は、待ち時間を示す変数に適宜の値（例えば図１１のリトライ待ち時間の値ＲＴ＿ＷＡＩＴ）を設定する。
（１３−２）メモリ取得部３１１は、終了コードを示す変数にリトライ推奨コードを設定する。
（１３−３）メモリ取得部３１１は、時間測定部３１６に現在時刻を取得させ、ステップＳ７１４と同様に管理表６０１を更新する。
（１３−４）メモリ取得部３１１は、メモリ取得処理の呼び出し元にＮＵＬＬポインタを返す。
【０３９４】
さらに、図１０の処理の変形と同様に、図１３の処理において、ステップＳ７０４およびＳ７１０〜Ｓ７１３は削除されてもよい。そして、割り当てが失敗したとステップＳ７０８で判断された場合、処理はステップＳ７０８からステップＳ７１４へと移行してもよい。なお、この場合、ステップＳ７１４において、終了コードを示す変数には、異常終了を示す値の代わりに、リトライ推奨コードが設定されてもよい。そして、待ち時間を示す変数に、適宜の値（例えば図１１のリトライ待ち時間の値ＲＴ＿ＷＡＩＴ）が設定されてもよい。
【０３９５】
以上のように、割り当て制御がライブラリ関数またはカーネル内部に実装される場合は、図１、１０、または１３の処理が適宜変形されてもよい。
なお、終了コードを示す変数にリトライ推奨コードが設定されている場合、メモリ割り当てを要求したアプリケーションは、適宜のリトライ制御を行ってもよいし、再度メモリ割り当てを要求することなくエラー処理を行ってもよい。また、アプリケーションは、変数に設定された待ち時間とは異なる時間だけ待ってから、再度メモリ割り当てを要求してもよい。つまり、割り当て制御がライブラリ関数またはカーネル内部に実装される場合は、アプリケーションがリトライを制御することができるように、アプリケーションに自由を与える実装が好ましい。
【０３９６】
ただし、第３実施形態のように、過去に実行されたメモリ割り当ての試み自体が「特定の処理」として扱われる場合、アプリケーションは、もしリトライ制御を行うならば、待ち時間を、図１１の有効期間ＶＡＬＩＤ＿ＤＵＲより長くすることが望ましい。なぜなら、アプリケーションが決定する待ち時間が有効期間ＶＡＬＩＤ＿ＤＵＲ以下だと、上記のように変形された図１３の処理が、有効期間ＶＡＬＩＤ＿ＤＵＲ内にアプリケーションから無駄に何度も呼び出される可能性があるからである。
【０３９７】
すると、呼び出しのたびに上記（１３−１）〜（１３−４）のようにしてリトライ推奨コードが返されるが、メモリ割り当て自体は実行されない。つまり、「メモリ割り当てを実行しない」と判断するための処理自体に、資源が無駄に消費される。
【０３９８】
そのような無駄な資源の消費を避けるためには、例えば、次のような方法が有効である。すなわち、（１３−１）で変数に有効期間ＶＡＬＩＤ＿ＤＵＲより長い待ち時間が設定されることが好ましい。そして、アプリケーションは、メモリ割り当てを再度要求するまでに、変数に設定された待ち時間以上の長さの時間だけ待つことが好ましい。
【０３９９】
つまり、上記のとおりアプリケーションにリトライ制御に関する自由を与える実装が好ましいが、コンピュータ全体の効率向上という観点から見ると、無制限の自由は好ましくない。具体的には、アプリケーションは、変数に設定された待ち時間（すなわち推奨される待ち時間）を無視しないで、できれば推奨に従うようにすることが好ましい。
【０４００】
変形の第４の観点は、管理表３１２と定数データ３１３に関する。図６と図１１には説明の便宜上、テーブル形式で管理表３１２と定数データ３１３の具体例を示したが、テーブル形式以外のデータ形式が採用されてもよい。
【０４０１】
また、図１１の管理表６０１には４種類のメモリサイズが定義されているが、メモリサイズの数Ｑ（図１２参照）は、４でなくてもよい。もちろん、各メモリサイズの範囲を示す上限値と下限値も、実施形態に応じて任意でよい。
【０４０２】
なお、図６と図１１に示すように、第２実施形態と第３実施形態では、管理表３１２に閾値だけでなく基準値も含まれるが、基準値は管理表３１２に含まれていなくてもよい。なぜなら、後から参照されるのは、基準値から計算された閾値であって、基準値そのものではないからである。
【０４０３】
また、図１１の管理表６０１には、各メモリサイズに対して、前回の測定時間ＰＲＥＶｊと前回の呼び出し時刻ＬＴｊが記憶されている。しかし、１≦α≦βとして、各メモリサイズに対して、直近のβ回のメモリ割り当ての試みそれぞれについて、当該試みにかかった時間と、当該試みのためにメモリ取得・解放部３１７が呼び出された時刻のペアが記憶されていてもよい。
【０４０４】
この場合、図１３のステップＳ７０１では、直近のβ回の試みのうちで呼び出し時刻が有効なものがα回以上あるか否かが判断される。つまり、現在から有効期間ＶＡＬＩＤ＿ＤＵＲ内の過去にα回以上メモリ割り当てが試みられたか否かが判断される。そして、現在から有効期間ＶＡＬＩＤ＿ＤＵＲ内の過去にα回以上メモリ割り当てが試みられていた場合、処理はステップＳ７０２に移行し、そうでなければ、処理はステップＳ７０４に移行する。
【０４０５】
さらに、ステップＳ７０２では、呼び出し時刻が有効と判明したα回以上の試みが、それぞれ（１４−１）と（１４−２）のいずれの条件に該当するかが判断される。
【０４０６】
（１４−１）当該試みにかかった時間が、管理表６０１において無効な値に設定されているか、または、閾値ＴＨｊより長い。
（１４−２）当該試みにかかった時間が、有効な値であり、かつ、閾値ＴＨｊ以下である。
【０４０７】
そして、（１４−１）に該当する試みがα回以上あれば、処理はステップＳ７０２からステップＳ７０３へと移行する。逆に、（１４−１）に該当する試みがα回未満しかなければ、処理はステップＳ７０２からステップＳ７０４へと移行する。
【０４０８】
以上のように、管理表６０１は直近のβ回の試みについての履歴を含んでもよく、図１３の処理も管理表６０１の変形に合わせて適宜変形されてよい。なお、第３実施形態は、α＝β＝１の場合の例である。
【０４０９】
変形の第５の観点は、「メモリ割り当ての要求すべてに対して、図１、図１０または図１３のような割り当て制御を適用するか否か」という観点である。図１、図１０または図１３のような割り当て制御により、メモリ割り当て処理のオーバヘッドは増える。よって、オーバヘッド削減の観点から、図１、図１０または図１３のような割り当て制御の対象が絞り込まれてもよい。
【０４１０】
例えば、要求されたメモリサイズが比較的小さい場合は、たとえコンピュータ全体の負荷が比較的高くても、メモリ割り当てが成功する見込みが比較的高い。つまり、要求されたメモリサイズが比較的小さい場合は、「失敗する見込みが高い無駄な処理によって、資源が消費され、その結果、コンピュータ全体の効率が悪化する」という危険性は低い。
【０４１１】
そこで、要求されたメモリサイズが閾値ＴＨ以下の場合は、図１、図１０または図１３のような割り当て制御が適用されなくてもよい。つまり、要求されたメモリサイズが閾値ＴＨ以下の場合、メモリ割り当ての要求に応じて、無条件にメモリ割り当てが試みられてもよい。閾値ＴＨは、例えば、ＯＳにより定義されるページサイズでもよいし、ページサイズ未満の適宜の値でもよい。そして、図１、図１０または図１３のような割り当て制御は、要求されたメモリサイズが閾値ＴＨを超える場合にのみ、行われてもよい。
【０４１２】
変形の第６の観点は、定数データ３１３の基準値の取得に関する。
第２実施形態と第３実施形態は、システム試験に関する実施形態である。そのため、「図８または図１２の処理が実行される時点でコンピュータ３００全体の負荷が低い」という仮定は、現実的な仮定である。
【０４１３】
しかし、任意のアプリケーションからのメモリ割り当ての要求に対して、第２実施形態または第３実施形態のような割り当て制御が適用される実施形態においては、コンピュータがいつ低負荷なのかは様々である。例えば、ＯＳがブートしている最中は、比較的負荷が高い。また、複数のアプリケーションが同時に実行されていれば、負荷が高い。
【０４１４】
そこで、情報取得部３１０が図８または図１２の処理の実行を開始する前に、ＣＰＵ負荷測定部３１４がＣＰＵの負荷を測定し、メモリ使用量測定部３１５がメモリの使用量を測定してもよい。もし、コンピュータが低負荷であると示す測定結果が得られたら、情報取得部３１０が図８または図１２の処理を開始する。
【０４１５】
逆に、もし、コンピュータが低負荷でなければ、情報取得部３１０は適宜の時間待ち、その後、ＣＰＵ負荷測定部３１４が再度ＣＰＵの負荷を測定し、メモリ使用量測定部３１５が再度メモリの使用量を測定する。負荷が低いことが判明するまで上記の処理が繰り返されれば、図８または図１２の処理は、低負荷のときに実行されることが保証される。
【０４１６】
例えば、ＯＳがブートし終わった後、かつ、どのアプリケーションのプロセスもまだ実行され始めていないときに、図８または図１２の処理が実行されるように、上記のような負荷測定と情報取得部３１０による処理の開始をＯＳが制御してもよい。あるいは、アプリケーションレベルで割り当て制御が実装される場合は、上記のような負荷測定と情報取得部３１０による処理の開始を、アプリケーションが制御してもよい。
【０４１７】
変形の第７の観点は、ステップの実行順序、省略、追加、および入れ替えに関する。
図１、７〜１０、および１２〜１３のフローチャートに示したステップの順序は例示であり、矛盾が生じない限り、ステップの順序は入れ替えられてもよい。また、入れ替え可能なステップの処理は、並列に実行されてもよい。例えば、図８において、ステップＳ３０４〜Ｓ３０６、Ｓ３０１〜Ｓ３０３、Ｓ３０７〜Ｓ３１０という順序で処理が実行されてもよい。
【０４１８】
また、図１０のステップＳ５０４は、図１３のステップＳ７０３のように所定時間待つ処理に置き換えられてもよく、その場合、所定時間の経過後、処理はステップＳ５０６に移行する。逆に、図１３のステップＳ７０３は、ステップＳ７１４と同様の処理を実行して図１３のメモリ取得処理全体を終了するように、変形されてもよい。
【０４１９】
あるいは、いくつかのステップは省略されてもよい。例えば、実施形態によっては、図１０のステップＳ５１０の判断が省略されてもよい。また、変形の第３の観点に関して例示したようなステップの省略も可能である。
【０４２０】
逆に、図１３の処理に、ステップＳ５１０と同様の判断が追加されてもよい。例えば、図１３のステップＳ７０８とＳ７１０の間に、ステップＳ５１０と同様の判断が追加されてもよい。
【符号の説明】
【０４２１】
Ｆ１、Ｆ２  フローチャート
１００、２００、３００  コンピュータ
１０１  メモリ
１０２  プログラム実行部
１０３  特定処理実行部
１０４  要求受付部
１０５  判断部
１０６  メモリ割り当て制御部
１０７  パラメタ
２０１  ＣＰＵ
２０２  ＲＡＭ
２０３  ＲＯＭ
２０４  通信インタフェイス
２０５  入力装置
２０６  出力装置
２０７  記憶装置
２０８  駆動装置
２０９  バス
２１０  記憶媒体
２１１  ネットワーク
２１２  プログラム提供者
３０１  アプリケーション
３０２  ＯＳ
３０３  ハードウェア
３０４  システム試験部
３０５  試験制御部
３０６  ＣＰＵ試験実行部
３０７  メモリ試験実行部
３０８  ディスク試験実行部
３０９  ネットワーク試験実行部
３１０  情報取得部
３１１  メモリ取得部
３１２、５０１、６０１  管理表
３１３、５０２、６０２  定数データ
３１４  ＣＰＵ負荷測定部
３１５  メモリ使用量測定部
３１６  時間測定部
３１７  メモリ取得・解放部
３１８  カーネル
３１９  ドライバ
４００  説明図
【図１】
2013051154.tif 000011
【図２】
2013051154.tif 000012
【図３】
2013051154.tif 000013
【図４】
2013051154.tif 000014
【図５】
2013051154.tif 000015
【図６】
2013051154.tif 000016
【図７】
2013051154.tif 000017
【図８】
2013051154.tif 000018
【図９】
2013051154.tif 000019
【図１０】
2013051154.tif 000020
【図１１】
2013051154.tif 000021
【図１２】
2013051154.tif 000022
【図１３】
2013051154.tif 000023
【手続補正書】
【提出日】平成26年4月9日(2014.4.9)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
プロセッサとメモリとを有するコンピュータにおける、前記プロセッサによって実行されるメモリ割り当て制御方法であって、
前記プロセッサが１つ以上の特定の処理のそれぞれを実行するのにかかる時間に基づく、メモリ割り当ての成功または失敗の蓋然性についての判定結果が、メモリ割り当てが成功する蓋然性が高いことを示す場合に、メモリ割り当ての要求に応じてメモリ割り当てを試み、
前記判定結果が、メモリ割り当てが失敗する蓋然性が高いことを示す場合に、メモリ割り当てを試みずにメモリ割り当て失敗の旨の応答を行うか、または、前記メモリ割り当てが成功する蓋然性が高いことを示す場合に実行されるメモリ割り当ての試みに対して、遅延させてメモリ割り当てを試みる、
ことを特徴とするメモリ割り当て制御方法。
【請求項２】
前記１つ以上の特定の処理は、
前記メモリの使用量または使用率を示す値を、前記要求を受け付けた後に取得する処理と
前記プロセッサの負荷を示す値を、前記要求を受け付けた後に取得する処理
の少なくとも一方を含み、
前記判定結果は、
前記１つ以上の特定の処理に含まれる各特定の処理について、当該特定の処理を前記プロセッサが実行するのにかかる時間が、当該特定の処理に応じて決められた第１の閾値より長い、という第１の条件と、
前記メモリの使用量または使用率が第２の閾値を超えているという第２の条件と、前記プロセッサの負荷が第３の閾値を超えているという第３の条件の論理積と
の論理和が真のとき、メモリ割り当てが失敗する蓋然性が高いことを示す
ことを特徴とする請求項１に記載のメモリ割り当て制御方法。
【請求項３】
前記１つ以上の特定の処理は、所定範囲内の過去に前記メモリに対する割り当て要求に応じて前記プロセッサがメモリ割り当てを試みた処理を含み、
前記判定結果は、前記プロセッサが前記メモリ割り当てを前記所定範囲内の過去において試みたときに結果を得るのにかかった時間が閾値より長いとき、メモリ割り当てが失敗する蓋然性が高いことを示す
ことを特徴とする請求項１に記載のメモリ割り当て制御方法。
【請求項４】
前記メモリ割り当てを試みた結果、前記メモリ割り当てに失敗した場合に、
前記メモリ割り当ての試みが失敗したことが判明するのにかかった時間が閾値より長ければ、メモリ割り当て失敗の旨の応答を行い、
前記時間が前記閾値より短く、かつ、前記メモリ割り当てを試みた回数が所定の回数に達していなければ、前記メモリ割り当てを再度試み、
前記メモリ割り当てを試みた前記回数が前記所定の回数に達してもなお、前記メモリ割り当てに成功しなければ、メモリ割り当て失敗の旨の応答を行う
ことを特徴とする請求項１から３のいずれか１項に記載のメモリ割り当て制御方法。
【請求項５】
プロセッサとメモリとを有するコンピュータにおける前記プロセッサに、
前記プロセッサが特定の処理を実行するのにかかる時間に基づく、メモリ割り当ての成功または失敗の蓋然性についての判定結果が、メモリ割り当てが成功する蓋然性が高いことを示す場合に、メモリ割り当ての要求に応じてメモリ割り当てを試み、
前記判定結果が、メモリ割り当てが失敗する蓋然性が高いことを示す場合に、メモリ割り当てを試みずにメモリ割り当て失敗の旨の応答を行うか、または、前記メモリ割り当てが成功する蓋然性が高いことを示す場合に実行されるメモリ割り当ての試みに対して、遅延させてメモリ割り当てを試みる、
ことを含む処理を実行させるためのプログラム。
【請求項６】
メモリと、
前記メモリ上に動的に割り当てられる領域を用いてプログラムを実行するプログラム実行部と、
前記プログラムとは別のプログラムによる特定の処理を実行する特定処理実行部と、
前記プログラム実行部からメモリ割り当ての要求を受け付ける要求受付部と、
前記特定の処理を前記特定処理部が実行するのにかかる時間に基づく、メモリ割り当ての成功または失敗の蓋然性についての判定結果が、メモリ割り当てが成功する蓋然性が高いことを示す場合に、メモリ割り当ての要求に応じてメモリ割り当てを試み、前記判定結果が、メモリ割り当てが失敗する蓋然性が高いことを示す場合に、メモリ割り当てを試みずにメモリ割り当て失敗の旨の応答を行うか、または、前記メモリ割り当てが成功する蓋然性が高いことを示す場合に実行されるメモリ割り当ての試みに対して、遅延させてメモリ割り当てを試みるメモリ割り当て制御部
を備える情報処理装置。
【国際調査報告】
2013051154.tif 000024
2013051154.tif 000025
2013051154.tif 000026
2013051154.tif 000027