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

Description

本発明は、メモリ管理方法、計算機及びメモリ管理プログラムに関する。

近年、ＣＰＵ（Central Processing Unit）の性能が飛躍的に向上し、ＣＰＵの処理速度に対し、ＣＰＵからメモリへのアクセス速度が非常に遅い。そのため、両者の速度差が、ソフトウェアの実行速度を向上させるための課題となっている。

この課題に対する一般的な解決方法として、ＣＰＵとメモリの間に、メモリより容量が小さく且つアクセス速度が高速なキャッシュを配置し、キャッシュにメモリ上の命令やデータを格納することで、メモリへのアクセス回数を削減する方法が知られている。キャッシュへのアクセス速度は、メモリへのアクセス速度の例えば１０分の１である。そのため、キャッシュを効率的に利用することが高速化のために重要である。

しかし、キャッシュを配置した場合であっても、キャッシュヒット率が低い場合には、ＣＰＵとメモリ間のアクセス回数を削減できず、ソフトウェアの実行速度は向上させることができない。キャッシュヒット率とは、キャッシュ上に必要な命令やデータが存在する確率のことである。従って、ソフトウェアの実行速度を向上させるためには、キャッシュヒット率を向上させることが重要である。

ここで、キャッシュの特徴について述べる。キャッシュは、命令を格納するための命令キャッシュ（i-cache：instruction-cache）と、データを格納するためのデータキャッシュ（d-cache：data-cache）に分類することができる。特に、命令キャッシュは、データキャッシュよりサイズが小さい場合が多く、頻繁に書き換えが発生する。

なお、キャッシュへの命令やデータの書き込みや読み込みのためのアクセスは、キャッシュライン又はブロックと呼ばれる一定のサイズ単位で実行される。そのため、使用頻度が高い命令やデータをメモリ上の近傍位置にまとまって配置することにより、キャッシュの書き換え回数を減らすことが好ましい。

しかし、命令やデータの使用頻度は、実際にシステム上で動作させるまでは不明であるため、予めメモリ上の配置を最適化することは困難である。命令やデータのメモリ上の配置に関連し、各種発明がなされてきた（特許文献１、２参照）。

特許文献１には、ソースプログラム中の関数の呼び出し回数と呼び出され回数に基づいて、メモリ上の当該関数の配置を最適化する言語処理方法及び言語処理装置が開示されている。

また、特許文献２には、アクセス速度が異なるメモリを備えるシステムにおいて、システムの動作中に、予め指定したコードの使用頻度を集計して統計情報を生成し、統計情報に基づいて使用頻度が多いコードを検出し、当該コードをアクセス速度が速いメモリへ転送して配置するコード転送方法が開示されている。

特開平１１−２１２７９８号広報 特開２００９−６４１１２号広報

しかしながら、上記の特許文献１に開示された技術では、コンパイル環境がない場合には最適化できなかった。また、システムの動作中に動的に最適化できなかった。

すなわち、特許文献１に開示された技術では、ソースプログラムを実行バイナリであるオブジェクトコードにコンパイル（翻訳）することを前提としている。そのため、ソースプログラムがない場合やコンパイル環境がない場合には、メモリ上の命令やデータの配置を最適化することができない。また、コンパイル時に最適化するので、システムの動作中に動的に最適化できない。

一方、上記の特許文献２に開示された技術では、システムの動作中に動的に最適化することができる。しかしながら、ソースプログラム又はオブジェクトコードにおいて、使用頻度の統計を測定するためのコードを予め指定する必要があった。

本発明は、上述した問題を考慮したものであって、ソースプログラム又はオブジェクトコードの修正やコンパイル環境を必要とすることなく、システムの動作中に動的にメモリ上の命令の配置を最適化するメモリ管理方法、計算機及びメモリ管理プログラムを提供することを目的とする。

本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、プログラムを格納するメモリと、前記メモリに格納されたプログラムを実行するプロセッサと、前記メモリに格納されたプログラムを一時的に格納するキャッシュと、を備えた計算機におけるメモリ管理方法であって、前記メモリは、前記プロセッサのプログラムカウンタが示す値の履歴を記録するプログラムカウンタ履歴領域を備え、前記方法は、前記プロセッサが、所定のタイミング毎に、前記プログラムカウンタが示す値を取得する手順と、取得された前記プログラムカウンタが示す値の履歴を、前記プログラムカウンタ履歴領域に記録する手順と、記録された前記プログラムカウンタが示す値の履歴に基づいて、前記プログラムの実行状況に関する統計情報を生成する手順と、生成された前記統計情報に基づいて、前記メモリ上における前記プログラムの命令の配置を最適化する手順と、最適化に基づいて配置された前記プログラムの命令を、前記キャッシュに格納する手順と、を含むことを特徴とする。

本発明によれば、ソースプログラム又はオブジェクトコードの修正やコンパイル環境を必要とすることなく、システムの動作中に動的にメモリ上の命令の配置を最適化することができる。

本発明の第１の実施形態の計算機のハードウェア構成の一例を示す図である。 本発明の第１の実施形態の計算機で実行されるコンテキストスイッチの概要を示す図である。 本発明の第１の実施形態のタスク構造体のデータ構造の一例を示す図である。 本発明の第１の実施形態のＣＰＵ、メモリ、標的プロセス及びＰＣ履歴の関係を示す図である。 本発明の第１の実施形態のタイマ割込み発生時の制御ロジックを示すフローチャートである。 本発明の第１の実施形態のメモリ上の配置の最適化の流れの概要を示す図である。 本発明の第１の実施形態のＰＣ履歴の一例を示す図である。 本発明の第１の実施形態のマッピング情報の一例を示す図である。 本発明の第１の実施形態の最適化情報の一例を示す図である。 本発明の第１の実施形態の最適化アルゴリズムの制御ロジックを示すフローチャートである。 本発明の第１の実施形態の関数アドレステーブルの更新の制御ロジックを示すフローチャートである。 本発明の第２の実施形態のメモリ上の配置の最適化の流れの概要を示す図である。

以下、図面を用いて本発明の実施の形態について説明する。

（第１の実施形態）
本発明の第１の実施形態では、コンテキストスイッチ時にＰＣ（Program Counter）が示す値（以下、「ＰＣ値」という。）を取得し、取得されたＰＣ値に基づいてプロファイル情報を作成し、作成されたプロファイル情報に基づいてメモリ上の命令の配置を最適化する方法について説明する。なお、ＰＣとは、次に実行すべき命令のメモリ上のアドレスを格納しているＣＰＵのレジスタ（カウンタ）である。

すなわち、本発明の第１の実施形態のメモリ管理方法は、コンテキストスイッチ時にＰＣ値を取得するステップと、プロファイル情報を作成するステップと、メモリ上の命令の配置を最適化するステップとを含む。

以下、本発明の第１の実施形態の最適化可能なソフトウェアが稼働できるハードウェア環境、ＰＣ値を取得するステップ、プロファイル情報を作成するステップ、メモリ上の命令の配置を最適化するステップについて、順に説明する。

（ハードウェア環境）
図１は、本発明の第１の実施形態の計算機１のハードウェア構成の一例を示す図である。図１に示すように、本発明の第１の実施形態の最適化可能なソフトウェアが稼働できる計算機１は、少なくともＣＰＵ１００、キャッシュ１１０及びメモリ１２０を備える。なお、計算機１は、ＣＰＵ１００、キャッシュ１１０及びメモリ１２０以外の構成要素を備えてよい。

ＣＰＵ１００は、メモリ１２０に記憶されている命令やデータを読み出して実行することによって、計算機１を制御する演算処理装置である。このＣＰＵ１００は、必要な命令やデータがキャッシュ１１０上にある場合には、キャッシュ１１０から命令やデータを読み出す。

キャッシュ１１０は、命令やデータの一時的な格納場所である。キャッシュ１１０は、命令を格納するためのｉ‐ｃａｃｈｅ１１１、データを格納するためのｄ−ｃａｃｈｅ１１２を備える。なお、ｄ‐ｃａｃｈｅ１１２を備えなくてもよい。

メモリ１２０は、ＣＰＵ１００によって実行される命令やデータを記憶するＲＡＭ（Random Access Memory）等の記憶装置である。メモリ１２０は、キャッシュ１１０より低速であるが、キャッシュ１１０よりも容量は大きい。

ＣＰＵ１００とキャッシュ１１０とはバス１３０で接続され、キャッシュ１１０とメモリ１２０とはバス１３１で接続されている。そのため、互いに命令やデータを伝送することが可能である。

なお、本発明の第１の実施形態では、ＣＰＵ１００がシングルコア及びシングルＣＰＵである場合を例に説明するが、本発明はマルチコア及びマルチＣＰＵに対しても適用可能である。さらに、本発明はキャッシュ１１０が複数の階層で構成されている場合や、メモリ１２０が複数のメモリから構成されている場合に対しても適用可能である。すなわち、様々なハードウェア構成上で利用可能である。

以上に示す構成において、本発明の第１の実施形態の計算機１では、メモリ１２０上の命令格納メモリ４２０（図６等参照）における命令の配置を、ｉ−ｃａｃｈｅ１１１に格納するのに適した態様に最適化する。

以下、ＰＣ値を取得するステップについて、図２、図３及び図４を用いて説明する。

（ＰＣ値の取得）
図２は、本発明の第１の実施形態の計算機１で実行されるコンテキストスイッチの概要を示す図である。

コンテキストスイッチとは、ＣＰＵ１００によって実行されるマルチタスクＯＳ（Operating System）が有する機能であって、プロセスの切替え処理を実行する機能である。具体的には、プロセスの切替え時に、ＣＰＵ１００のレジスタ等の状態を保存し、再開する際に保存しておいた状態を復元する機能である。なお、マルチタスクＯＳとは、複数のタスク（プロセス）を並列処理するオペレーティングシステムである。タスクとは、計算機１上においてＯＳから見た処理の実行単位をいう。プロセスとは、ＯＳからメモリ領域等を割り当てられた実行中のプログラムをいう。

図２を用いて、マルチタスクＯＳ（ＣＰＵ１００）がプロセスＡ２２０を実行中にタイマ割込み２００が発生した場合に、実行対象のプロセスをプロセスＡ２２０から、休止中のプロセスＢ２３０に切替える処理を説明する。

まず、マルチタスクＯＳは、ＣＰＵ１００のコンテキスト（状態）２１０に関する情報を、実行中のプロセスＡ２２０が有するタスク構造体Ａ２２１に保存する。次に休止中のプロセスＢ２３０が有するタスク構造体Ｂ２３１から、コンテキスト２１０に関する情報を取り出し、ＣＰＵ１００のコンテキスト２１０に格納する。これにより、ＣＰＵ１００のコンテキスト２１０を復元する。その結果、プロセスＡ２２０は休止状態になり、プロセスＢ２３０が実行状態になる。

ここで、タスク構造体Ａ２２１には、プロセスＡ２２０が休止状態になった瞬間のコンテキスト２１０に関する情報が保存される。そのため、次にプロセスＡ２２０が実行状態になったときには、休止前の処理から再開することができる。

すなわち、マルチタスクＯＳは、タイマ割込み２００をトリガーとして、複数のプロセス（図２ではプロセスＡ２２０、プロセスＢ２３０）がＣＰＵ１００を共有できるように、ＣＰＵ１００のコンテキスト２１０を保存したり、復元したりすることができる。

なお、詳細には後述するが、本発明の第１の実施形態では、タスク構造体Ａ２２１、Ｂ２３１の拡張がユーザによって自由に実施可能であることを利用し、タスク構造体Ａ２２１、Ｂ２３１にＰＣ取得フラグ３１０、ＰＣ履歴ポインタ３２０（図３参照）を追加する。また、マルチタスクＯＳ（ＣＰＵ１００）は、コンテキストスイッチを実行する度に、ＰＣ値をＰＣ履歴３３０（図３参照）に保存する。

通常、ＰＣはコンテキストスイッチを実行する度に上書きされるので、最新の値のみを記憶する。しかしながら、本発明の第１の実施形態によれば、マルチタスクＯＳ（ＣＰＵ１００）は、コンテキストスイッチを実行する度に、ＰＣ値を保存（記録）する。これにより、コンテキストスイッチ時のＰＣ値の履歴を取得することができる。

図３は、本発明の第１の実施形態のタスク構造体３００のデータ構造の一例を示す図である。タスク構造体３００とは、プロセス毎に状態やＩＤなどを格納する構造体である。

タスク構造体３００は、プロセス状態、プロセスＩＤ、使用メモリ量、ＰＣ取得フラグ３１０、ＰＣ履歴ポインタ３２０等を含む。すなわち、一般的なタスク構造体３００の構成要素（プロセス状態、プロセスＩＤ、使用メモリ量等）に、ＰＣ取得フラグ３１０、ＰＣ履歴ポインタ３２０が拡張されている。ここでは、拡張された構成要素であるＰＣ取得フラグ３１０、ＰＣ履歴ポインタ３２０について説明する。

ＰＣ取得フラグ３１０は、コンテキストスイッチ時にＰＣ値を取得するか否かを決定するフラグである。ＰＣ取得フラグ３１０のＯＮ／ＯＦＦの切替え方法については後述する。ＰＣ履歴ポインタ３２０は、ＰＣ履歴３３０へのポインタである。

ＰＣ履歴３３０は、ＰＣ値、すなわち、次に実行すべき命令が格納されたアドレスの値の履歴を記録する領域である。つまり、計算機１上でソフトウェアが実行された際の命令の実行履歴を抽出した情報が記録される。

以上のように、本発明の第１の実施形態によれば、タスク構造体３００がＰＣ取得フラグ３１０及びＰＣ履歴ポインタ３２０の構成要素を含む。これにより、コンテキストスイッチ時のＰＣ値を過去に遡って取得することができる。

図４は、本発明の第１の実施形態のＣＰＵ１００、メモリ１２０、標的プロセス４００及びＰＣ履歴３３０の関係を示す図である。

図４において、標的プロセス４００とは、最適化すべきソフトウェア（プログラム）を実行しているプロセスである。この標的プロセス４００は、メモリ１２０上にタスク構造体３００を有する。また、この標的プロセス４００は、メモリ１２０上の命令格納メモリ４２０を参照し、命令格納メモリ４２０に格納された命令を実行する。なお、命令格納メモリ４２０は、ＰＣ４１０によっても参照されている。

（ＰＣ取得フラグ３１０の切替え方法について）
ここで、ＰＣ取得フラグ３１０の切替え方法について説明する。

本発明の第１の実施形態では、ＣＰＵ１００によって実行されるマルチタスクＯＳのカーネルに、例えばＰＲ＿ＣＯＮＴＲＯＬという名前のシステムコールを追加する。これにより、マルチタスクＯＳ（ＣＰＵ１００）は、当該システムコールによって任意の標的プロセス４００のＰＣ取得フラグ３１０のＯＮ／ＯＦＦを切替える。

なお、この切替えは、ユーザがキーボード等の入力装置を介して、コマンドライン等のインターフェースにおいて切替え指示を入力することによって、任意のタイミングで実行することができる。

具体的には、ＰＣ値の取得処理を開始する場合には、ＰＣ値を取得したい標的プロセス４００に対してＰＲ＿ＣＯＮＴＲＯＬを実行することによって、当該標的プロセス４００のＰＣ取得フラグ３１０をＯＮにする。そうすると、マルチタスクＯＳ（ＣＰＵ１００）は、ＰＣ４１０が示す値をＰＣ履歴３３０に保存する。これにより、指定した標的プロセス４００のみでＰＣ４１０が示す値を取得させることが可能になる。

一方、ＰＣ値の取得処理を終了する場合には、任意の標的プロセス４００に対してＰＲ＿ＣＯＮＴＲＯＬを実行することによって、当該標的プロセス４００のＰＣ取得フラグ３１０をＯＦＦにする。そうすると、マルチタスクＯＳ（ＣＰＵ１００）は、ＰＣ４１０が示す値をＰＣ履歴３３０に保存しない。

以上に示す方法により、ＰＣ取得フラグ３１０を切替えることによって、ＰＣ値の取得処理の削減とＰＣ履歴３３０の領域の節約が可能になる。なお、ＰＣ取得フラグ３１０の切替え方法は、ＰＲ＿ＣＯＮＴＲＯＬに限定されるものではない。また、ＰＣを取得するか否かを決定する方法は、ＰＣ取得フラグ３１０に限定されるものではない。例えば、後述するＰＣ履歴ポインタ３２０にＰＣ履歴３３０へのポインタを設定するかＮＵＬＬポインタを設定するかによって切替えてもよい。

（ＰＣ履歴ポインタ３２０について）
次に、ＰＣ履歴ポインタ３２０について説明する。

本発明の第１実施形態では、標的プロセス４００のタスク構造体３００は、ＰＣ履歴３３０の実体を保持するのではなく、ＰＣ履歴３３０に対するポインタであるＰＣ履歴ポインタ３２０を保持する。これにより、複数の同種の標的プロセス４００がある場合に、各標的プロセス４００は互いのＰＣ履歴３３０を共有することができる。なお、複数の同種の標的プロセス４００がある場合、各標的プロセス４００が参照している命令格納メモリ４２０は同一であり、同一の領域のＰＣ履歴３３０にアドレスを保存しても良い。

以上に示すように、ＰＣ履歴ポインタ３２０という変数を使用することによって、例えばＰＣ４１０が示す値を一定数収集するために必要な時間を削減できる。また、ＰＣ履歴３３０が分散してしまうことによって、ＣＰＵ１００のｄ−ｃａｃｈｅ１１２のキャッシュヒット率が低下するのを防ぐことができる。また、ＰＣ履歴３３０を格納するためのメモリ量を削減することができる。また、ＰＣ履歴ポインタ３２０にＮＵＬＬポインタを格納することによって、ＰＣ履歴３３０の領域が確保されていない場合にも対応できる。

なお、本発明はＰＣ履歴３３０を複数の標的プロセス４００間で共有しない場合にも適用可能である。さらに、タスク構造体３００がＰＣ履歴ポインタ３２０ではなく、ＰＣ履歴３３０の実体を保持する場合にも適用可能である。

（各標的プロセス４００間でのＰＣ履歴３３０の共有方法）
複数の標的プロセス４００がある場合に、各標的プロセス４００によってＰＣ履歴３３０を共有する方法について説明する。

まず、マルチタスクＯＳ（ＣＰＵ１００）は、ｐｒｏｃなどの仮想ファイルシステムにＰＣ履歴３３０のアドレスを出力可能に設定し、初期値をＮＵＬＬにする。次に、標的プロセス４００がＰＣ値の取得処理を開始する際に、仮想ファイルシステムに設定されたＰＣ履歴３３０のアドレスがＮＵＬＬである場合には、新しくＰＣ履歴３３０の領域を確保し、確保されたＰＣ履歴３３０のアドレスを仮想ファイルシステムに出力する。一方、仮想ファイルシステムに設定されたＰＣ履歴３３０のアドレスがＮＵＬＬでない場合には、既にＰＣ履歴３３０の領域が確保されているため、確保されているＰＣ履歴３３０のアドレスをＰＣ履歴ポインタ３２０に設定する。これにより、各標的プロセス４００はＰＣ履歴３３０を共有する。

（ＰＣ履歴３３０の誤解放の防止について）
複数の標的プロセス４００がＰＣ履歴３３０を共有している場合に、ＰＣ履歴３３０の領域の誤解放を防ぐための方法について説明する。

ＰＣ履歴３３０において、当該ＰＣ履歴３３０へのポインタの数（参照数）を記録する参照カウンタを追加してもよい。これにより、ＰＣ履歴３３０の領域が誤って解放されてしまうのを防ぐことができる。

すなわち、マルチタスクＯＳ（ＣＰＵ１００）は、例えばＰＣ値の取得処理を開始する場合には、ＰＣ履歴ポインタ３２０にＰＣ履歴３３０のアドレスを格納するとともに、参照カウンタを１増やす。一方、ＰＣ値の取得処理を終了する場合には、ＰＣ履歴ポインタ３２０にＮＵＬＬポインタを格納するとともに、参照カウンタを１減らす。そして、参照カウンタが０になった場合にのみ、ＰＣ履歴３３０を解放する。

また、マルチタスクＯＳ（ＣＰＵ１００）は、ＰＣ履歴ポインタ３２０がＰＣ履歴３３０を参照している場合に、ＰＣ４１０が示す値をＰＣ履歴３３０に格納する。一方、ＰＣ履歴ポインタ３２０がＮＵＬＬポインタを参照している場合に、ＰＣ４１０が示す値をＰＣ履歴３３０に格納しない。このように切替えることにより、ＰＣ取得フラグ３１０の領域を節約することができる。

図５は、本発明の第１の実施形態のタイマ割込み発生時の制御ロジックを示すフローチャートである。ここでは、ＣＰＵ１００によって実行されるマルチタスクＯＳが、タイマ割込み発生時に、コンテキストスイッチを実行する際の動作を説明する。

まず、タイマ割込みが発生すると（ステップ５００）、マルチタスクＯＳ（ＣＰＵ１００）は、コンテキストスイッチが必要か否かを判定する（ステップ５１０）。

具体的には、例えばプロセス毎に予め設定された優先度に基づいて、コンテキストスイッチが必要か否かを判定する。すなわち、処理待ちのプロセスの優先度が実行中のプロセスの優先度よりも高い場合には、コンテキストスイッチは必要であると判定する。一方、処理待ちのプロセスの優先度が実行中のプロセスの優先度よりも低い場合には、コンテキストスイッチは不要であると判定する。

マルチタスクＯＳ（ＣＰＵ１００）は、コンテキストスイッチが必要でないと判定した場合（ステップ５１０で“Ｎ”）、処理を終了する。一方、コンテキストスイッチが必要であると判定した場合（ステップ５１０で“Ｙ”）、ＰＣ取得フラグ３１０がＯＮであるか否かを判定する（ステップ５２０）。

マルチタスクＯＳ（ＣＰＵ１００）は、ＰＣ取得フラグ３１０がＯＦＦである場合（ステップ５２０で“Ｎ”）、ステップ５４０に進む。一方、ＰＣ取得フラグ３１０がＯＮである場合（ステップ５２０で“Ｙ”）、ＰＣ履歴３３０にＰＣ値を格納する（ステップ５３０）。具体的には、図４に示すように、ＰＣ４１０が指すメモリ１２０上の命令格納メモリ４２０に格納された命令のアドレスを、ＰＣ履歴３３０に格納する。最も単純な格納方法としては、図３に示すように線形リストでよい。

その後ステップ５４０において、マルチタスクＯＳ（ＣＰＵ１００）は、通常のコンテキストスイッチ処理を実行する（ステップ５４０）。その後、処理を終了する。

以上に示す処理のうち、特にステップ５２０及びステップ５３０の処理により、マルチタスクＯＳ（ＣＰＵ１００）は、コンテキストスイッチ処理の実行時に、ＰＣ履歴３３０にＰＣ値を格納している。

以上に示すように、マルチタスクＯＳ（ＣＰＵ１００）は、ＰＣ履歴３３０を自動的に取得することができる。そのため、ＰＣ履歴３３０を取得するためのソフトウェア使用者や標的プロセス４００の作成者による設定及びソフトウェアの変更は不要である。例えば、ＰＣ履歴３３０を取得するための新しい割込みの追加が不要である。また、タスク構造体３００にＰＣ取得フラグ３１０やＰＣ履歴ポインタ３２０のための新しい領域を確保し、コンテキストスイッチ時にステップ５２０及びステップ５３０の処理を追加するだけで、ＰＣ履歴３３０を取得することができる。そのため、ＰＣ値を取得する際の処理が急激に遅くなることもない。また、追加するシステムコールは、ＰＣ取得フラグ３１０のＯＮ／ＯＦＦを切替えるＰＲ＿ＣＯＮＴＲＯＬのみであって、このシステムコールは標的プロセス４００の起動時に１回だけ起動すればよい。そのため、このシステムコールによる負荷は小さい。

なお、ステップ５３０では、ＰＣ履歴３３０へのＰＣ値の格納方法として線形リストを挙げたが、ＰＣ履歴３３０は特定のデータ構造に限定されるものではない。すなわち、格納すべきＰＣ値の量が多い場合にはハッシュマップ、少ない場合には線形リストのように、状況に応じて最適なデータ構造を選択してもよい。

また、ステップ５３０では、必要に応じてＰＣ履歴３３０にＰＣ値以外の情報、例えばコンテキストスイッチ処理が実行された時刻情報を格納してもよい。これにより、以降ＰＣ履歴３３０に基づいて生成されるプロファイル情報に、時間的局所性を含めることができる。

また、ＰＣ値を取得するタイミングは、標的プロセス４００を中断する時点と再開する時点のいずれのタイミングでもよい。また、タイマ割込みの頻度はマルチタスクＯＳに依存するが、本発明はタイマ割込みの頻度に依らず適用できる。また、ＰＣ値の取得回数の増加に従い、ＰＣ履歴３３０の容量が大きくなる。そのため、例えば保持するＰＣ値の最大個数を予め指定し、取得されたＰＣ値が最大個数を超えた場合には、古い順に上書きしてもよい。

図６は、本発明の第１の実施形態のメモリ１２０上の配置の最適化の流れの概要を示す図である。図６を用いて、ＰＣ履歴３３０を用いてメモリ１２０上の命令（ここでは関数単位）の配置を最適化する流れについて説明する。関数とは、プログラム中の手続きを意味や内容毎に一つの手続きとしてまとめたものである。

メモリ１２０上の関数の配置を最適化するステップは、プロファイル情報６１０を作成するステップ、最適化情報６２０を生成するステップ、命令格納メモリ４２０において関数をコピーするステップ、及び、関数アドレステーブル６４０を更新するステップを含む。図６〜図９を用いて順に説明する。

（プロファイル情報６１０を作成するステップ）
マルチタスクＯＳ（ＣＰＵ１００）が、ＰＣ履歴３３０を統計処理することによって、プロファイル情報６１０を生成するステップについて説明する。プロファイル情報６１０とは、プログラムの過去及び現在の実行状況に関する統計情報であって、ＰＣ履歴３３０に基づいて生成される。

マルチタスクＯＳ（ＣＰＵ１００）は、まずプロファイル情報６１０を作成するためのスレッド（最適化スレッド６００）を一つ生成する。なお、最適化スレッド６００は、例えば最適化プロセスとして生成しても良い。

なお、最適化スレッド６００を生成する主体は、マルチタスクＯＳのみならず標的プロセス４００であってもよい。そして、最適化スレッド６００を生成することによって、自動的に又は任意のタイミングで最適化を開始できる。なお、スレッドとして生成しているので、最適化スレッド６００と標的プロセス４００とを並列に動作させることができる利点がある。

また、最適化スレッド６００は、標的プロセス４００が参照している命令格納メモリ４２０の内容を書き換えない。そのため、マルチＣＰＵ又はマルチコアの環境では、最適化スレッド６００に関するロック（排他制御）は不要であり、標的プロセス４００の性能を全く落とさないなどの利点がある。なお、最適化スレッド６００を生成する代わりに、例えば別プロセスを生成してもよい。

次に、生成された最適化スレッド６００（ＣＰＵ１００）は、標的プロセス４００のタスク構造体３００や仮想ファイルシステムから、ＰＣ履歴３３０を取得し、必要に応じて取得されたＰＣ履歴３３０をコピー（複製）する。これにより、ＰＣ値の取得が継続されていてＰＣ履歴３３０が更新中であっても、プロファイル情報６１０を生成できる。

図７Ａは、本発明の第１の実施形態のＰＣ履歴３３０の一例を示す図である。図７Ａに示す例では、ＰＣ履歴３３０は、ＰＣ値の履歴として、アドレス３３１、３３２、３３３等を含む。

その後、最適化スレッド６００（ＣＰＵ１００）は、取得されたＰＣ履歴３３０と、関数マッピング情報７００とに基づいて、プロファイル情報６１０を生成する。プロファイル情報６１０とは、最適化情報６２０を生成するために利用される統計情報であって、例えば関数毎の使用回数である。

図７Ｂは、本発明の実施形態の関数マッピング情報７００の一例を示す図である。関数マッピング情報７００は、関数名７０１と、メモリ上の配置７２０との対応関係を示す情報が格納されたテーブルである。

図７Ｂに示すテーブルでは、標的プロセス４００が利用するｆｕｎｃＡ６１３、ｆｕｎｃＢ６１４及びｆｕｎｃＣ６１５それぞれの関数のメモリ１２０上の配置（先頭アドレスと終端アドレス）７２１、７２２、７２３を示している。

このような関数マッピング情報７００は、例えばダイナミックリンクライブラリのｄｌｌファイルやｓｏファイルから取得できる。なお、ｄｌｌファイルやｓｏファイルからは各関数の先頭アドレスを直接取得できるが、各関数の終端アドレスを直接取得することができない。そこで、各関数は命令格納メモリ４２０上で連続して配置されているという特徴に基づいて、任意の関数が配置されている領域は、その先頭アドレスから次の関数の先頭アドレスの直前までの領域と判断し、当該関数の終端アドレスを決定することができる。なお、同様の手順で関数の名前も取得できる。しかしながら、関数の名前が不要である場合には、関数マッピング情報７００から関数名７０１を削除することによって、メモリ１２０を節約してもよい。また、関数マッピング情報７００の取得方法は、ｄｌｌファイルやｓｏファイルからの取得に限定されるものではない。

図６に戻って、最適化スレッド６００（ＣＰＵ１００）は、前述したように、ＰＣ履歴３３０と関数マッピング情報７００とに基づいて、プロファイル情報６１０を生成する。具体的には、ＰＣ履歴３３０に記録されている各アドレス（ＰＣ値）が、関数マッピング情報７００のどの領域に含まれているかを調べることによって、関数毎の使用回数を求める。

例えばＰＣ履歴３３０のアドレス３３１（図７Ａ参照）は０ｘ０１００１２３４であって、図７Ｂのメモリ上の配置７２１に含まれる。そのため、ｆｕｎｃＡ６１３が呼び出されたと判定できる。上記の手順を繰り返すことによって、関数毎の使用回数を示すプロファイル情報６１０を作成できる。なお、本発明のプロファイル情報６１０は、関数単位の使用回数に限定されるものではない。

なお、最適化スレッド６００（ＣＰＵ１００）は、必要に応じて最新のＮ個（例えば１０個）のＰＣ履歴３３０に基づくプロファイル情報６１０や特定の関数（例えばｆｕｎｃＢ６１４）に限定したプロファイル情報６１０を生成してもよい。また、複数のプロファイル情報６１０を生成してもよい。さらに、ＰＣ履歴３３０に基づいてプロファイル情報６１０を生成できなかった場合は、プロファイル情報６１０にＮＵＬＬを格納してもよい。

また、ＰＣ履歴３３０にアドレス（ＰＣ値）以外の情報を格納することにより、プロファイル情報６１０により詳細な統計情報を組み込むことができる。例えば、ＰＣ値の取得時刻が格納されたＰＣ履歴３３０を統計処理することにより、プロファイル情報６１０に時間的局所性を組み込むことができる。

また、最適化スレッド６００（ＣＰＵ１００）は、予め作成された関数マッピング情報７００を保持し、当該関数マッピング情報７００を用いて、マルチタスクＯＳによるＰＣ値の取得と同時にプロファイル情報６１０を作成することもできる。これにより、プロファイル情報６１０を常に最新の状態にすることができ、最適化に関する精度を向上することができる。

（最適化情報６２０を生成するステップ）
最適化スレッド６００（ＣＰＵ１００）が、プロファイル情報６１０に最適化アルゴリズムを適用することによって、最適化情報６２０を生成するステップについて説明する。なお、最適化アルゴリズムとは、メモリ１２０上の関数の配置を最適化するための処理手順である。また、最適化情報６２０とは、メモリ１２０上の関数の配置を最適化するために利用される情報である。

図８は、本発明の第１の実施形態の最適化アルゴリズムの制御ロジックを示すフローチャートである。ここでは、最適化スレッド６００が、図８に示す最適化アルゴリズムに従って最適化情報６２０を生成する処理を説明する。

まず、最適化スレッド６００による最適化アルゴリズムが開始すると（ステップ８００）、最適化スレッド６００（ＣＰＵ１００）は、プロファイル情報６１０から任意の関数Ｘを選択する（ステップ８１０）。

ステップ８１０において、具体的には、最適化スレッド６００は、プロファイル情報６１０に登録された関数であるｆｕｎｃＡ６１３、ｆｕｎｃＢ６１４、ｆｕｎｃＣ６１５のいずれかを選択する。なお、プロファイル情報６１０における統計情報の登録単位が関数単位ではない場合には、登録単位に応じて選択してもよい。

次に、最適化スレッド６００（ＣＰＵ１００）は、関数Ｘが存在するか否かを判定する（ステップ８２０）。関数Ｘが存在しない場合（ステップ８２０で“Ｎ”）、処理を終了する。一方、関数Ｘが存在する場合（ステップ８２０で“Ｙ”）、関数Ｘの使用回数が予め定めた閾値Ｔより大きいか否かを判定する（ステップ８３０）。

ここでいう閾値Ｔとは、プロファイル情報６１０に登録された１又は複数の関数から最適化対象の関数を抽出するために、メモリ１２０の容量の大きさや最適化の度合いに応じて決定される値である。例えば、プロファイル情報６１０に登録された各関数の使用回数の平均値である。なお、メモリ１２０の空き容量が大きい場合には閾値Ｔを小さくしてよい。これにより、最適化対象の関数を増やすよう調整できる。

また、ステップ８３０では、関数Ｘの使用回数の代わりに、例えば関数Ｘの使用時刻を用いてもよい。この場合、関数Ｘが最後に使用された時刻が、プロファイル情報６１０に登録された各関数が最後に使用された時刻の平均値よりも新しいか否かを判定する。これにより、最後に使用された時刻が新しい関数Ｘを、最適化対象の関数として抽出することができる。

また、ステップ８３０では、関数Ｘの使用回数の代わりに、例えば関数Ｘの使用時刻に基づいて算出される使用間隔（時間）を用いてもよい。この場合、関数Ｘの使用間隔が、プロファイル情報６１０に登録された各関数の使用間隔の平均値よりも小さいか否かを判定する。これにより、使用間隔が小さい関数Ｘを、最適化対象の関数として抽出することができる。

さらに、ステップ８３０では、最適化スレッド６００（ＣＰＵ１００）は、例えば関数Ｘの使用回数をプロファイル情報６１０に登録された各関数の使用回数の合計値で割った値が、予め定めた閾値Ｔより大きいか否かを判定することにより、関数Ｘの使用割合を考慮して最適化対象の関数を抽出してもよい。

また、使用回数や使用時刻、使用間隔など複数の要素に重み付けし、組み合わせて判定することもできる。

以上のように、ステップ８３０では、最適化スレッド６００（ＣＰＵ１００）は、プロファイル情報６１０に登録された１又は複数の関数から、最適化対象の関数を抽出している。

関数Ｘの使用回数が閾値Ｔより小さい場合（ステップ８３０で“Ｎ”）、ステップ８５０に進む。一方、関数Ｘの使用回数が閾値Ｔより大きい場合（ステップ８３０で“Ｙ”）、ステップ８４０に進み、最適化スレッド６００（ＣＰＵ１００）は、関数Ｘとその使用回数を、最適化情報６２０に優先度順で追加する（ステップ８４０）。

ここでいう優先度とは、メモリ１２０上の関数の配置を最適化する際の基準値（評価値）である。すなわち、優先度が高い関数の順に、メモリ１２０上の配置を最適化する。

なお、優先度は、最適化アルゴリズムで利用しているパラメータによって決定できる。例えば、利用しているパラメータが各関数の使用回数である場合、優先度は使用回数とすることができる。この場合、最適化スレッド６００（ＣＰＵ１００）は、使用回数が多い順に、関数Ｘとその使用回数を最適化情報６２０に追加する。また例えば、利用しているパラメータが各関数の使用時刻である場合、優先度は使用時刻とすることができる。ここで、時間的局所性から最後に使用された時刻が新しいほど再度利用される可能性が高いため、最後に使用された時刻が新しい順に優先度を高くする。すなわち、最適化スレッド６００は、最後に使用された時刻が新しい順に、関数Ｘとその使用回数を最適化情報６２０に追加する。なお、関数の使用時刻から算出される使用間隔（時間）が小さいほど再度利用される可能性が高いので、使用間隔が小さい順に優先度を高くしてもよい。すなわち、最適化スレッド６００は、使用間隔が小さい順に、関数Ｘとその使用回数を最適化情報６２０に追加する。これにより、時間の経過とともに各関数の使用頻度が変化する場合でも対応可能である。

また、利用しているパラメータが複数（例えば使用回数及び使用時刻）存在する場合、優先度は複数のパラメータの組み合わせとすることができる。この場合、最適化スレッド６００は、例えば各関数の使用回数に、最後に使用された時刻が最も新しい関数に１００を加算、２番目に新しい関数に９９を加算する等のように重みを付けた値の大きい順に、関数Ｘとその使用回数を最適化情報６２０に追加する。

また、関数マッピング情報７００から得られる関数のサイズが小さいほどキャッシュを有効に活用できるため、関数のサイズが小さい順に優先度を高くしてもよい。

その後ステップ８５０において、最適化スレッド６００（ＣＰＵ１００）は、プロファイル情報６１０から、別の関数Ｘを選択し（ステップ８５０）、ステップ８２０の処理に戻る。以降、ステップ８２０からステップ８５０の処理を繰り返し、関数Ｘが存在しなくなった時点で（ステップ８２０で“Ｎ”）、最適化アルゴリズムを終了する（ステップ８６０）。

以上に示す処理により、最適化スレッド６００（ＣＰＵ１００）は、プロファイル情報６１０に基づいて最適化情報６２０を生成する。

例えば、図６のプロファイル情報６１０に示すように、ｆｕｎｃＡ６１３、ｆｕｎｃＢ６１４及びｆｕｎｃＣ６１５の使用回数６１２がそれぞれ１００、３、８０であり、閾値Ｔが５０である場合、最適化情報６２０は、ｆｕｎｃＡ６１３及びｆｕｎｃＣ６１５とその優先度６２２となる。

なお、プロファイル情報６１０がＮＵＬＬの場合や全ての関数Ｘの使用回数６１２が閾値Ｔより小さい場合は、最適化スレッド６００（ＣＰＵ１００）は、最適化情報６２０にＮＵＬＬを格納してもよい。また、閾値Ｔは最適アルゴリズムの中で動的に決定してもよい。

また、図８に示すような特定の最適化アルゴリズムに限定されるものではなく、様々な最適化アルゴリズムが利用可能である。例えば、時間を多く費やしている関数が最適化情報６２０に多く含まれるように重み付けしてもよい。

（命令格納メモリ４２０において関数をコピーするステップ）
最適化スレッド６００（ＣＰＵ１００）が、最適化情報６２０に基づいて、命令格納メモリ４２０において関数をコピーするステップについて説明する。具体的には、最適化情報６２０に含まれる各関数を、命令格納メモリ４２０上の別アドレスに連続した状態でコピーすることによって、命令格納メモリ４２０における各関数の配置を最適化する。

図６に示す例では、最適化情報６２０に含まれる関数はｆｕｎｃＡ６１３とｆｕｎｃＣ６１５である。そこで、最適化スレッド６００は、ｆｕｎｃＡ６１３及びｆｕｎｃＣ６１５を、元のオブジェクトコードが格納された命令格納メモリ４２０上のアドレス領域６３０から、別アドレス領域６３１にコピーする。なお、関数マッピング情報７００（図７Ｂ参照）における各関数の開始アドレスと終端アドレスを参照することによって、別アドレス領域６３１上で任意の関数を連続させて配置できる。

具体的には、まず最適化スレッド６００は、最適化情報６２０を最適化情報７１０（図７Ｃ参照）に更新する。

図７Ｃは、本発明の第１の実施形態の最適化情報７１０の一例を示す図である。図７Ｃに示すように、最適化情報７１０は、最適化情報６２０にコピー先アドレス７１１とコピー元アドレス７１２とが追加されたものである。

すなわち、最適化スレッド６００は、最適化情報６２０にコピー先アドレス７１１とコピー元アドレス７１２を追加することによって、最適化情報７１０に更新する。

次に最適化スレッド６００は、最適化情報７１０を用いて、コピー元アドレス７１２に対応する命令格納メモリ４２０上のアドレス領域６３０に格納された関数を、コピー先アドレス７１１に対応する命令格納メモリ４２０上の別アドレス領域６３１にコピーする。そうすると、ＣＰＵ１００（図６において不図示）は、別アドレス領域６３１にコピーされた関数を、ｉ‐ｃａｃｈｅ１１１に格納する。

なお、最適化スレッド６００は、最適化情報６２０がＮＵＬＬの場合は、上記コピーを実行しない。また、メモリ１２０とは別にメモリがある場合、別メモリにコピーしてもよい。

また、本発明は仮想記憶に対しても適用可能である。従って、コピーすべき命令の量がメモリ１２０の空き容量よりも大きい場合であっても、ソフトウェアの実行速度を高速化することができる。ただし、コピーすべき命令の量がメモリ１２０の空き容量に対して非常に大きい場合には、ハードディスク（図１において不図示）へのアクセス回数が増加することによって、ソフトウェアの実行速度が低速になる可能性がある。そこで、最適化アルゴリズムにおいて、メモリ１２０の空き容量に関する情報を組込む、又は、コピーする命令の量を調整する最適化レベルを指定できるようにすることによって、コピーする命令の量を削減する対策が可能である。

（関数アドレステーブル６４０を更新するステップ）
最適化スレッド６００（ＣＰＵ１００）が、最適化情報７１０（図７Ｃ参照）に基づいて、関数アドレステーブル６４０を更新するステップについて説明する。

図９は、本発明の第１の実施形態の関数アドレステーブル６４０の更新の制御ロジックを示すフローチャートである。なお、関数アドレステーブル６４０とは、関数名６４１に示す関数と、当該関数が格納されたメモリ１２０上の先頭メモリアドレス６４２とのマッピングを示したテーブルである。

まず、最適化スレッド６００によるアドレス更新が開始すると（ステップ９００）、最適化スレッド６００（ＣＰＵ１００）は、古い最適化情報７１０があるか否か判定する（ステップ９１０）。古い最適化情報７１０がある場合とは、上記ＰＣ値の取得とメモリ１２０上の関数の配置の最適化を繰り返した場合に、別アドレス領域６３１上に古い最適化情報７１０に従ってコピーされた関数が残っている場合である。この状態で別アドレス領域６３１が書き換えられるとメモリ領域の解放漏れが発生する。

古い最適化情報７１０がない場合（ステップ９１０で“Ｎ”）、ステップ９５０に進む。一方、古い最適化情報７１０がある場合（ステップ９１０で“Ｙ”）、最適化スレッド６００（ＣＰＵ１００）は、ステップ９５０による関数アドレステーブル６４０の更新処理の前に、ステップ９２０からステップ９４０の処理を実行する。

すなわち、まずステップ９２０において、最適化スレッド６００（ＣＰＵ１００）は、古い最適化情報７１０のコピー元アドレス７１２に基づいて、関数アドレステーブル６４０を更新する（ステップ９２０）。具体的には、関数アドレステーブル６４０の関数名６４１に示す各関数の先頭メモリアドレス６４２を、古い最適化情報７１０のコピー元アドレス７１２に更新する。これにより、標的プロセス４００は命令格納メモリ４２０上のアドレス領域６３０を参照し、処理を継続することができる。

その後ステップ９３０において、最適化スレッド６００（ＣＰＵ１００）は、古い最適化情報７１０に従って確保されたメモリ領域を解放する（ステップ９３０）。具体的には、古い最適化情報７１０に従ってコピーされた関数が格納されている命令格納メモリ４２０上の別アドレス領域６３１を解放する。

以上ステップ９２０及びステップ９３０に示すように、最適化スレッド６００（ＣＰＵ１００）は、関数アドレステーブル６４０の先頭メモリアドレス６４２を更新した後に、別アドレス領域６３１を解放する。これにより、並列に動作している標的プロセス４００の不具合を回避できる。

その後ステップ９４０において、最適化スレッド６００（ＣＰＵ１００）は、古い最適化情報７１０に含まれる全ての関数が格納された領域の解放が終了したので、古い最適化情報７１０を削除する（ステップ９４０）。

その後ステップ９５０において、最適化スレッド６００（ＣＰＵ１００）は、新しい最適化情報７１０のコピー先アドレス７１１に基づいて、関数アドレステーブル６４０を更新する（ステップ９５０）。具体的には、関数アドレステーブル６４０の関数名６４１に示す各関数の先頭メモリアドレス６４２を、新しい最適化情報７１０のコピー先アドレス７１１に更新する。その後、処理を終了する（ステップ９６０）。

例えば、図７Ｃに示すように、最適化情報７１０に含まれる関数がｆｕｎｃＡ６１３とｆｕｎｃＣ６１５である場合、図９に示す処理によって、関数アドレステーブル６４０のアドレス６４３〜６４５のうち、アドレス６４３及びアドレス６４５が更新される。

以上に示す処理により、以後、標的プロセス４００は関数を呼び出す場合、更新後の関数アドレステーブル６４０に従って、命令格納メモリ４２０上の別アドレス領域６３１に格納された関数を呼び出す。その結果、ＣＰＵ１００によるｉ−ｃａｃｈｅ１１１への書き換え回数を減少させ、不具合を引き起こさずにソフトウェアの実行速度を高速化することができる。

なお、関数アドレステーブル６４０の更新後であっても、命令格納メモリ４２０上のアドレス領域６３０には、関数の元々のオブジェクトコードが残っている。そのため、標的プロセス４００は、アドレス領域６３０を参照した場合であっても、関数の不存在による不具合を発生することなく動作できる。

なお、メモリ１２０上の関数アドレステーブル６４０を更新しても、関数アドレステーブル６４０がキャッシュ１１０上に存在する場合は、関数の元々のオブジェクトコードが参照される。そのため、通常は不具合対策としてキャッシュクリアを実行する必要がある。この場合、関数アドレステーブル６４０以外のキャッシュもクリアされ、一時的に処理速度が遅くなる。そこで、本発明の第１の実施形態では、キャッシュクリアを実行してもよいが、実行しなくてもよい。キャッシュクリアを実行しない場合であっても、元々のオブジェクトコードが残っているため、関数の不存在による不具合が発生しない。なお、キャッシュ１１０上の関数アドレステーブル６４０の更新を待ってもよい。

以上説明してきた第１の実施形態によれば、ソースプログラム又はオブジェクトコードの修正やコンパイル環境を必要とすることなく、システムの動作中に動的にメモリ１２０上の命令（ここでは関数単位）の配置を最適化することができる。

（第２の実施形態）
第１の実施形態では、関数毎にメモリ１２０上の配置を最適化する形態について説明した。第２の実施形態では、関数同士の依存関係を利用して、関数の組み合わせ毎にメモリ１２０上の配置を最適化する形態について説明する。なお、以下では、前述の第１の実施形態と同様である部分の説明を適宜省略する。

図１０は、本発明の第２の実施形態のメモリ１２０上の配置の最適化の流れの概要を示す図である。図１０を用いて、ＰＣ履歴３３０を用いてメモリ１２０上の関数の配置を最適化する流れについて説明する。なお、以下では前述の第１の実施形態（図６参照）と同様の機能を果たす部分には同一の符号を付して重複する説明を適宜省略する。

前述の第１の実施形態と同様に、メモリ１２０上の関数の配置を最適化するステップは、プロファイル情報６１０を作成するステップ、最適化情報６２０を生成するステップ、命令格納メモリ４２０において関数をコピーするステップ、及び、関数アドレステーブル６４０を更新するステップを含む。

なお、以下では、前述の第１の実施形態との差異点を中心に説明する。

最適化情報６２０を生成するステップにおいて、第２の実施形態の最適化スレッド６００（ＣＰＵ１００）は、関数同士の依存関係を考慮した最適化アルゴリズムをプロファイル情報６１０に適用することによって、最適化情報６２０を生成する。関数同士の依存関係とは、図１０の依存関係１０００に示すように、関数同士の呼び出しと呼び出される関係をまとめたものである。

なお、関数の呼び出し関係は、ソフトウェアのソースコードやオブジェクトコードから取得できる。最適化スレッド６００（ＣＰＵ１００）は、このような関数同士の依存関係を取得し、同一の関数を含む複数の最適化パターンを含む最適化情報６２０を生成する。

図１０に示す例では、依存関係１０００に示すように、ｆｕｎｃＤ１００１からｆｕｎｃＥ１００２、ｆｕｎｃＦ１００３及びｆｕｎｃＧ１００４の呼出し回数は、それぞれ１００回、１回、８０回である。

この場合、最適化情報６２０を生成するステップにおいて、最適化スレッド６００（ＣＰＵ１００）は、呼出し回数が閾値（例えば５０回）より大きい関数の組み合わせ、例えばｆｕｎｃＤ１００１とｆｕｎｃＥ１００２の組、及び、ｆｕｎｃＤ１００１及びｆｕｎｃＧ１００４の組を抽出する。

その後、命令格納メモリ４２０において関数をコピーするステップにおいて、第２の実施形態の最適化スレッド６００（ＣＰＵ１００）は、最適化情報６２０に含まれる各関数の組み合わせを、命令格納メモリ４２０上の別アドレスに連続した状態でコピーすることによって、命令格納メモリ４２０における各関数の組み合わせの配置を最適化する。

図１０に示す例では、最適化スレッド６００は、別アドレス１０１１に示すように、ｆｕｎｃＤ１００１とｆｕｎｃＥ１００２の組、及び、ｆｕｎｃＤ１００１及びｆｕｎｃＧ１００４の組を、元のオブジェクトコードが格納された命令格納メモリ４２０上のアドレス１０１０から、別アドレス１０１１に連続するようにコピーする。そうすると、ＣＰＵ１００（図１０において不図示）は、別アドレス１０１１にコピーされたｆｕｎｃＤ１００１をｉ−ｃａｃｈｅ１１１に格納するとともに、ｆｕｎｃＥ１００２及びｆｕｎｃＧ１００４を格納できる。これにより、ｉ−ｃａｃｈｅ１１１の書き換え回数を減少できる。

なお、その後の関数アドレステーブル６４０を更新するステップでは、最適化スレッド６００（ＣＰＵ１００）は、優先度が高い最適化パターン（例えば呼出し回数が最も大きいｆｕｎｃＤ１００１とｆｕｎｃＥ１００２の関数の組み合わせ）に基づいて、関数アドレステーブル６４０を更新する。なお、その後適切なタイミングで関数アドレステーブル６４０を更新してもよい。適切なタイミングとは、例えばｆｕｎｃＥ１００２が１００回呼び出された時である。また、複数の最適化パターンに基づく更新を実行することによって、ｉ−ｃａｃｈｅ１１１の書き換え回数をさらに減少させてもよい。

以上説明してきた第２の実施形態によれば、前述の第１の実施形態に加え、メモリ１２０の命令格納メモリ４２０上に、複数の最適化パターンを配置することができる。また、命令格納メモリ４２０上に配置された隣接する関数同士に依存関係があるので、前述の第１の実施形態に比して、ｉ−ｃａｃｈｅ１１１の書き換え回数を減少できる。そのため、更なるソフトウェアの実行速度を高速化することができる。

なお、メモリ１２０の使用量に制限がある場合や関数の依存関係の取得が困難である場合は第１の実施形態のメモリ管理方法を適用し、メモリ１２０の使用量に制限がない場合や関数の依存関係の取得が容易である場合は第２の実施形態のメモリ管理方法を適用するように、第１の実施形態と第２の実施形態とを切替えることも好ましい。

以上、本発明の各実施形態について説明したが、上記各実施形態は本発明の適用例の一つを示したものであり、本発明の技術的範囲を上記各実施形態の具体的構成に限定する趣旨ではない。

例えば、上記各実施形態では、ＣＰＵ１００によって実行されるマルチタスクＯＳを例に説明してきたが、この場合には限らない。例えばシングルタスクＯＳでもよい。この場合、コンテキストスイッチを実行する毎ではなく、ユーザによる設定等に基づく定期的なタイミング毎にＰＣ値を取得すればよい。

１００ ＣＰＵ
１１０ キャッシュ
１１１ ｉ−ｃａｃｈｅ
１２０ メモリ
３００ タスク構造体
３１０ ＰＣ取得フラグ
３３０ ＰＣ履歴（ＰＣ履歴領域）
４００ 標的プロセス
４１０ ＰＣ
４２０ 命令格納メモリ
６００ 最適化スレッド
６１０ プロファイル情報
６２０ 最適化情報
６４０ 関数アドレステーブル
７００ 関数マッピング情報
１０００ 依存関係

Claims (8)

1. プログラムを格納するメモリと、前記メモリに格納されたプログラムを実行するプロセッサと、前記メモリに格納されたプログラムを一時的に格納するキャッシュと、を備えた計算機におけるメモリ管理方法であって、
   前記メモリは、前記プロセッサのプログラムカウンタが示す値の履歴を記録するプログラムカウンタ履歴領域を備え、
   前記方法は、
   前記プロセッサが、
   所定のタイミング毎に、前記プログラムカウンタが示す値を取得する手順と、
   取得された前記プログラムカウンタが示す値の履歴を、前記プログラムカウンタ履歴領域に記録する手順と、
   記録された前記プログラムカウンタが示す値の履歴に基づいて、前記プログラムの実行状況に関する統計情報を生成する手順と、
   生成された前記統計情報に基づいて、前記メモリ上における前記プログラムの命令の配置を最適化する手順と、
   最適化に基づいて配置された前記プログラムの命令を、前記キャッシュに格納する手順と、
   を含み、
   前記最適化する手順において、前記プロセッサは、生成された前記統計情報に基づいて前記メモリに格納されたプログラムの命令を抽出し、前記抽出したプログラムの命令を、前記メモリにおいて前記プログラムが配置された領域と別の領域に連続した状態でコピーし、
   前記格納する手順において、前記プロセッサは、前記別の領域にコピーしたプログラムの命令を前記キャッシュに格納することを特徴とするメモリ管理方法。
2. 前記プロセッサ上では、複数のタスクを並列処理するマルチタスク方式のオペレーティングシステムが動作し、
   前記取得する手順では、前記オペレーティングシステムが、コンテキストスイッチ処理を実行する毎に、前記プログラムカウンタが示す値を取得し、
   前記記録する手順では、前記オペレーティングシステムが、取得された前記プログラムカウンタが示す値の履歴を、前記プログラムカウンタ履歴領域に記録することを特徴とする請求項１に記載のメモリ管理方法。
3. 前記マルチタスク方式のオペレーティングシステム上では、複数のタスクが動作し、
   前記各タスクは、前記メモリ上に、前記プログラムカウンタが示す値を取得するか否かを示すプログラムカウンタ取得フラグを含むタスク構造体を有し、
   前記取得する手順では、前記オペレーティングシステムは、コンテキストスイッチ処理を実行時に、切替え後のタスクが有するタスク構造体中のプログラムカウンタ取得フラグがオンの場合に、前記プログラムカウンタが示す値を取得することを特徴とする請求項２に記載のメモリ管理方法。
4. 前記プロセッサ上では、複数のタスクを並列処理するマルチタスク方式のオペレーティングシステムが動作し、
   前記オペレーティングシステム上で複数の同種のタスクが動作している場合、
   前記複数の同種のタスクの各々は、前記プログラムカウンタ履歴領域を共有することを特徴とする請求項１に記載のメモリ管理方法。
5. 前記プログラムカウンタが示す値の取得を実行するか否かを切替え可能であることを特徴とする請求項１に記載のメモリ管理方法。
6. 前記最適化する手順において、前記プロセッサは、前記プログラムの実行状況に関する統計情報と、前記プログラムの命令間の依存情報とに基づいて、前記メモリ上における前記プログラムの命令の配置を最適化することを特徴とする請求項１に記載のメモリ管理方法。
7. プログラムを格納するメモリと、前記メモリに格納されたプログラムを実行するプロセッサと、前記メモリに格納されたプログラムを一時的に格納するキャッシュと、を備えた計算機であって、
   前記メモリは、前記プロセッサのプログラムカウンタが示す値の履歴を記録するプログラムカウンタ履歴領域を備え、
   前記プロセッサは、
   所定のタイミング毎に、前記プログラムカウンタが示す値を取得し、
   取得された前記プログラムカウンタが示す値の履歴を、前記プログラムカウンタ履歴領域に記録し、
   記録された前記プログラムカウンタが示す値の履歴に基づいて、前記プログラムの実行状況に関する統計情報を生成し、
   生成された前記統計情報に基づいて、前記メモリ上における前記プログラムの命令の配置を最適化し、
   最適化に基づいて配置された前記プログラムの命令を、前記キャッシュに格納し、
   前記最適化において、生成された前記統計情報に基づいて前記メモリに格納されたプログラムの命令を抽出し、前記抽出したプログラムの命令を、前記メモリにおいて前記プログラムが配置された領域と別の領域に連続した状態でコピーし、
   前記格納において、前記別の領域にコピーしたプログラムの命令を前記キャッシュに格納することを特徴とする計算機。
8. プログラムを格納するメモリと、前記メモリに格納されたプログラムを実行するプロセッサと、前記メモリに格納されたプログラムを一時的に格納するキャッシュと、を備えた計算機において実行されるメモリ管理プログラムであって、
   前記メモリは、前記プロセッサのプログラムカウンタが示す値の履歴を記録するプログラムカウンタ履歴領域を備え、
   前記メモリ管理プログラムは、
   所定のタイミング毎に、前記プログラムカウンタが示す値を取得する手順と、
   取得された前記プログラムカウンタが示す値の履歴を、前記プログラムカウンタ履歴領域に記録する手順と、
   記録された前記プログラムカウンタが示す値の履歴に基づいて、前記プログラムの実行状況に関する統計情報を生成する手順と、
   生成された前記統計情報に基づいて、前記メモリ上における前記プログラムの命令の配置を最適化する手順と、
   最適化に基づいて配置された前記プログラムの命令を、前記キャッシュに格納する手順と、
   を前記プロセッサに実行させ、
   前記最適化する手順は、生成された前記統計情報に基づいて前記メモリに格納されたプログラムの命令を抽出し、前記抽出したプログラムの命令を、前記メモリにおいて前記プログラムが配置された領域と別の領域に連続した状態でコピーする手順を含み、
   前記格納する手順は、前記別の領域にコピーしたプログラムの命令を前記キャッシュに格納する手順を含むことを特徴とするメモリ管理プログラム。

Images