JP6555981B2 - 情報処理装置及びその制御方法 - Google Patents

Description

本発明は、動的コンパイルに関するものである。

従来プログラムの実行環境である仮想マシン環境において、アプリケーション実行中にネイティブコードにコンパイルを行う、ＪＩＴ（Just In Time）コンパイルと呼ばれる手段が知られている。ＪＩＴコンパイルでは、プログラムを実行しながら呼び出し回数の多い関数を優先してネイティブコードへ変換する（非特許文献１）。さらに、ネイティブコードはコードキャッシュと呼ばれるメモリ領域に一時的に保存される。コードキャッシュが一杯になると、例えば実行頻度の少ないネイティブコードから順にコードキャッシュから破棄される。

また、ネイティブコードが生成されていない場合はインタプリタ方式による実行が行われる。インタプリタ方式の実行速度はネイティブコードで実行するよりも低速である。なお、このネイティブコードはアプリケーションが実行中に生成されるため、アプリケーションの初回利用時にはネイティブコードによる高速動作が行えない問題がある。この問題を解決するため、ユーザがアプリケーションを実行するより前に、アプリケーションを事前に読み込みＪＩＴコンパイルを済ませておく従来技術がある（特許文献１）。

特許第５１６７５８９号

ＪＩＴ コンパイルと最適化の概要（http://otndnld.oracle.co.jp/document/products/jrockit/geninfo/diagnos/underst_jit.html）

しかしながら、従来技術において事前に読み込ませたアプリケーションが呼び出す関数のうち全てが実際に必要になるとは限らない。例えばユーザがアプリケーションの中の一部の機能しか使用しない場合、呼ばれない関数もある。このような関数に対するＪＩＴコンパイルは不要である。

また、コードキャッシュに保存された或る関数Ｆのネイティブコードが破棄された後、再度関数Ｆが呼ばれると再コンパイルを行う場合がある。このケースでは一度作成したネイティブコードと同じものを再度生成しており無駄と言える。

本発明は上述した問題を解決するためになされたものである。そして、本発明は、アプリケーションによっては高速に実行可能な環境を提供する。

この課題を解決するため、例えば本発明の情報処理装置は以下の構成を備える。すなわち、
アプリケーションを実行する仮想マシンとして機能する情報処理装置であって、
前記アプリケーションから要求された関数に対応するネイティブコードがキャッシュメモリに格納されている場合、当該ネイティブコードを実行し、前記キャッシュメモリに格納されていない場合、前記アプリケーションから要求された関数をインタプリタ形式に実行する実行手段と、
前記アプリケーションからのコンパイル要求を受信した場合、要求された関数のコンパイルを行い、生成されたネイティブコードを前記キャッシュメモリに登録する動的コンパイル手段と、
前記アプリケーションから、関数の終了の要求を受信した場合、要求されたネイティブコードを前記キャッシュメモリより消去、もしくはキャッシュメモリへの維持する優先度をより低く設定する設定手段とを有する。

本発明によれば、単にアプリケーションの実行環境を提要するだけでなく、そのアプリケーションが要求すれば、そのタイミングで必要な関数のネイティブコードを生成し、キャッシュメモリに登録する。この結果、その関数を実際に実行するタイミングより早く要求している限り、高速な処理を行うことも可能になる。

ハードウェア構成図。 第１の実施形態における装置の機能構成図。 ＪＩＴコンパイル処理を示すフローチャート。 第２の実施形態における装置の機能構成図。 高速版ネイティブコード生成処理を示すフローチャート。 時刻指定ＪＩＴコンパイル処理を示すフローチャート。 アプリケーション優先度定義テーブルを示す図。

以下、添付の図面を参照して、本発明に係る実施形態を詳細に説明する。なお、以下の実施形態において示す構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。

［第１の実施形態］
図１は本実施形態における情報処理装置１０００のハードウェア構成を示す図である。中央演算処理装置（以下、ＣＰＵ）１００１は演算処理部であり、装置全体の動作制御のための各種処理を実行する。ネイティブコードの生成やアプリケーションの実行もここで行う。

メモリ１００２はＲＡＭやＲＯＭなどの半導体メモリであり、ＣＰＵ１００１で実行する各種プログラムやその演算結果やネイティブコード等がここに格納される。コードキャッシュもここに存在する。入力装置１００３は、キーボードやマウスやタッチデバイスなどでありユーザがアプリケーション利用時に情報を入力する際のインタフェースとなる。出力装置１００４は、ディスプレイ装置などであり、ユーザに対しアプリケーションの処理結果等の情報を出力する際のインタフェースとなる。タイマー１００５はコンパイルの実行タイミング等の時刻管理や、コンパイル時間の計測などを行う。補助記憶装置１００６はハードディスクドライブなどであり各種データの保管先に用いられる。通信インタフェース１００７は外部ネットワーク（インターネットを含む）とのデータ入出力の制御を行う。１００８はシステムバスであり、上記の参照符号１００１〜１００７で示される構成要素を接続し、各構成要素間での情報転送経路となる。

図２は本実施形態において必要なシステムの構成要素を示すブロック図である。アプリケーション１００、仮想マシン２００、仮想マシン内の一部にＪＩＴ（Just In Time)管理部３００が存在する。仮想マシン２００としては例えばＪａｖａ(登録商標)ＶＭ（Virtual Machine）が想定される。当然、アプリケーション１００、仮想マシン２００は、情報処理装置１０００内のＣＰＵ１００１がそれぞれのソフトウェアを実行することで実現するものである。つまり、アプリケーション１００、仮想マシン２００は同じ物理的な装置内に存在する。なお、以下の説明では、図２の処理部が主体とした処理として説明するが、現実にはそれぞれの処理部として機能するためのプログラムを、ＣＰＵ１００１が実行するで実現することになる。

アプリケーション１００は、アプリケーション処理実行部１０１、ＪＩＴコンパイル開始指示部１０２、ＪＩＴコンパイル終了指示部１０３を含む。アプリケーション処理実行部１０１は、ユーザが利用する各種アプリケーションの処理を行う。ユーザからの入力を受け付け、各種処理内容を仮想マシンへ伝達し仮想マシンから処理結果を受け取り、ユーザへ結果を提示（表示）する機能を持つ。ＪＩＴコンパイル開始指示部１０２は、ＪＩＴ管理部３００に対して、ＪＩＴコンパイルの開始指示や対象関数を伝達する機能を持つ。ＪＩＴコンパイル終了指示部１０３は、ＪＩＴ管理部３００に対して、ＪＩＴコンパイルの終了指示や対象関数を伝達する機能を持つ。

仮想マシン２００は、ＪＩＴコンパイラ２０１、ネイティブコードキャッシュ管理部２０３、処理命令部２０４、ＪＩＴ管理部３００を含む。

ＪＩＴコンパイラ２０１は、プログラム中の関数単位でネイティブコード（ＣＰＵ１００１が直接解釈可能なコード）２０２を生成する機能を持つ。また、このＪＩＴコンパイラ２０１は、後述のＪＩＴコンパイル命令制御部３０２からの指示を受けて動作する。また、背景技術で述べたように実行中に呼び出し回数の多い関数を検出しその関数のネイティブコードを生成する機能も持つ。

ＪＩＴコンパイラ２０１で生成されたネイティブコード２０２は、これはコードキャッシュへ保存される。コードキャッシュ内の各ネイティブコードに対してキャッシュ優先度を与え、いつキャッシュから破棄するかを管理する必要がある。ネイティブコードキャッシュ管理部２０３はこの管理を行う。

処理命令部２０４は、アプリケーションから受けた各種処理を実行する。処理はインタプリタ形式で実行するが、実行対象となる関数のネイティブコードが存在すれば（キャッシュされていれば）それを利用して実行する。また、処理実行中の各関数の呼び出し回数等の情報はＪＩＴコンパイラ２０１へ渡される。

ＪＩＴ管理部３００は、アプリケーション指示受付部３０１、ＪＩＴコンパイル命令制御部３０２、キャッシュ優先度指定部３０３を含む。

アプリケーション指示受付部３０１は、アプリケーション１００からの開始指示やＪＩＴコンパイルの対象関数の情報を受け取る。ＪＩＴコンパイル命令制御部３０２は、ＪＩＴコンパイラ２０１に対して実行開始や実行停止等の命令を送る機能を持つ。また、ＪＩＴコンパイル命令制御部３０２は、ＪＩＴコンパイルが完了したら通知を受け取り、ＪＩＴコンパイルの完了時刻とコンパイル対象関数とを対応付けて保存する機能も持つ。キャッシュ優先度指定部３０３は、ＪＩＴコンパイル命令制御部３０２からの指示を受けてコードキャッシュ内の特定のネイティブコードのキャッシュ優先度を変更するよう、ネイティブコードキャッシュ管理部２０３へ指示する機能を持つ。また、ＪＩＴコンパイル命令制御部３０２からＪＩＴコンパイルの完了時刻の情報を取得し、コンパイル後の経過時間に応じてキャッシュ優先度の変更を２０３へ指示する機能も持つ。

次に、本実施形態の基本的な動作例を図３（ａ），（ｂ）を用いて説明する。なお、図３（ａ），（ｂ）は、仮想マシン２００で実行される処理内容が示し、アプリケーション１００の処理内容は省略している（アプリケーションの種類は問わない）。先に説明したように、処理はＣＰＵ１００１が実行するものであるが、理解を容易にするため、図２の機能ブロック図の各処理部を主語として説明する。図３（ａ）は、アプリケーション１００からネイティブコード生成処理の指示を受けた場合の仮想マシン２００の処理を示している。

まずアプリケーション１００は、ＪＩＴコンパイルをしてもらいたいタイミングになると、ＪＩＴコンパイル開始指示部１０２を制御し、アプリケーション指示受付部３０１へＪＩＴコンパイルの指示要求（動的コンパイル要求）を出す。この時、ＪＩＴコンパイル開始指示部１０２は、ＪＩＴコンパイルの対象の関数名（仮にＦＡ）もアプリケーション指示受付部３０１に伝える。仮想マシン２００は、この指示要求を受けたらすぐにＪＩＴコンパイラ２０１が関数ＦＡのコンパイルを開始する（Ｓ３０１，Ｓ３０３）。ここでもしコンパイルが終わるまでの間にアプリケーション１００のＪＩＴコンパイル開始指示部１０２からＪＩＴコンパイルの中止指示が来たとする。つまりアプリケーション指示受付部３０１がＪＩＴコンパイル中止指示を受けたとする（Ｓ３０２）。この場合、ＪＩＴコンパイル命令制御部３０２がＪＩＴコンパイラ２０１に対して中止命令を出して、ＪＩＴコンパイラ２０１には速やかにコンパイルを終了する。またＪＩＴコンパイラ２０１は、この時コンパイル途中まで生成された中間バイナリ等の各種ファイルを破棄する（Ｓ３０５）。

アプリケーション１００からの中止指示を受信しないままＪＩＴコンパイルが完了したとする（Ｓ３０４がＹＥＳの場合）。この場合、ＪＩＴコンパイラ２０１は、生成されたネイティブコード（仮にＢＦＡという）を不図示のコードキャッシュ（メモリ１００２に確保される）に格納する（Ｓ３０６）。また、このとき、ＪＩＴコンパイラ２０１は、ＪＩＴコンパイル命令制御部３０２へコンパイル完了を通知する。この結果、対象関数ＦＡとそのコンパイル完了時刻が対応付けられて記録管理される。これはＪＩＴコンパイル命令制御部３０２で行われる（Ｓ３０７）。

次に、キャッシュ優先度指定部３０３が、生成されたネイティブコードＢＦＡのキャッシュ優先度を高く設定する処理を行う。コードキャッシュには、それ以前に生成されたネイティブコードＢＦＸも保存されているとする。この場合、従来の手法では、背景技術で述べたように実行中に呼び出し回数の多い関数をＪＩＴコンパイルするものである。本実施形態では、ＢＦＡに対してはＢＦＸよりも高い優先度を設定する（Ｓ３０８）。ＢＦＡはアプリケーションが意図的に指示して生成されたものであり、ＢＦＸよりも利用される確率が高いものとして扱う。こうすることでＢＦＡが長期間キャッシュ中に残るようになる。これは、コードキャッシュが埋まった状態で新たなネイティブコードが生成されたとき、優先度の低いものから順にコードキャッシュから消去されるからである。例えばコードキャッシュがＢＦＡとＢＦＸで埋まっているときに、新たなネイティブコードＢＦＹが生成されると、優先度が低いＢＦＸが消去される。こうしてＢＦＡがコードキャッシュに長時間残る確率が上がる。

なおＳ３０３において、もし以前に関数ＦＡのコンパイルが行われておりコードキャッシュ中にＢＦＡが存在していた場合はコンパイルする必要はない。生成済みのＢＦＡがもし低いキャッシュ優先度に設定されていたら高い優先度に設定し直す。

上記のＳ３０１〜Ｓ３０８の処理と並行して、アプリケーションは処理を実行している。アプリケーションが関数ＦＡを実行するより少し前にＪＩＴコンパイル指示を出すようにしておけば、関数ＦＡの初回実行時から生成済みのネイティブコードＢＦＡを用いることができ、従来の方法よりも高速に実行できる。そのため、アプリケーション１００には、実際に実行する関数ＦＡの記述の数ステップ前に、ＦＡ関数のコンパイル開始命令を記述しておくと都合がよい。

次に、図３（ｂ）に従い、アプリケーション１００からネイティブコードの終了指示を受けた場合の仮想マシン２００の処理を説明する。

アプリケーション１００は、或る関数（仮にＦＡとする）の使用を終了するタイミングで、ＪＩＴコンパイル終了指示部１０３からアプリケーション指示受付部３０１へ終了指示要求を行う。つまり、仮想マシン２００が、この指示（関数名を含む）を受けたと判断したとする（ステップＳ３０９）。この場合、ＪＩＴコンパイル命令制御部３０２からキャッシュ優先度指示部３０３を通じて、ネイティブコードキャッシュ管理部２０３がＢＦＡをコードキャッシュから消去する処理を行う（Ｓ３１０）。なお別の例として、消去せずにＢＦＡのキャッシュ優先度を最低値に下げてもよい。この場合はコードキャッシュが全部埋まるまでは残っているが、埋まった後はすぐ他のネイティブコードに追い出されて消去される。

一方、アプリケーションからの終了指示が来ない場合でも、ＢＦＡが生成された時刻から一定時間が経過したらキャッシュの優先度を下げる処理を行う。この処理は、ＪＩＴコンパイル命令制御部３０２が保存した関数ＦＡのＪＩＴコンパイル完了時刻をまずキャッシュ優先度指定部３０３へ渡す。そして、キャッシュ優先度指定部３０３が経過時間に応じてネイティブコードキャッシュ管理部２０３へ命令する形で行う（Ｓ０１１）。優先度の下げ方としては例えば所定期間（例えば３０秒経過）するごとに優先度を少しずつ下げてもよいし、例えば５分という長時間経過したときに最低値に下げてもよい。そうするとコードキャッシュ中のＢＦＡ以外のネイティブコードと比べ優先度が相対的に低くなる。そしてコードキャッシュが一杯になった時に新しいネイティブコードが入ってくると（Ｓ３１２）、優先度の低いＢＦＡがコードキャッシュから消去されることになる（Ｓ３１０）。

このような処理があることで、万が一アプリケーションがハングアップするなどして終了通知が送れず終了してしまう場合でも、生成したネイティブコードＢＦＡがキャッシュに残り続けることはない。

以上が本第１の実施形態における仮想マシン２００の基本的な動作例である。これによれば、アプリケーション１００が必要とするタイミングで関数ＦＡのネイティブコードを用意（キャッシュへの登録）することができる。従って、関数ＦＡの１回目の実行から、インタプリタより高速に実行可能である。また、ネイティブコードＢＦＡはアプリケーションの終了指示が来るまでコードキャッシュ（キャッシュメモリ」）に保存され続ける可能性が高くなる。つまり利用途中でＢＦＡがコードキャッシュから追い出されることがなくなり、ひいては無駄なネイティブコードＢＦＡの再コンパイルを不要にすることができる。また、アプリケーション１００が、もはや利用しないとわかった段階で、該当する関数の利用終了を指示することで、該当するネイティブコードをコードキャッシュから削除できる。よってそれ以外のネイティブコードがキャッシュに残る可能性を高くすることもできる。

［第２の実施形態］
第２の実施形態では、上記第１の実施形態でＪＩＴコンパイルする際に、インライン展開の深さの設定を変えて、より高速動作が可能なネイティブコードを生成する例を説明する。

図４は本第２の実施形態において必要なシステムの構成要素を示すブロック図である。第１の実施形態における図２の構成に対し、ＪＩＴコンパイラ稼働監視部３０４が追加された点が異なる。

ＪＩＴコンパイラ稼働監視部３０４は、ＪＩＴコンパイラが動作中であるかどうかを監視する機能を持つ。また、ＪＩＴコンパイラ稼働監視部３０４は、ＪＩＴコンパイルの対象関数とそのコンパイルにかかった処理時間とを対応づけて記録する機能も持つ。さらに、ＪＩＴコンパイラ稼働監視部３０４は、対象関数のコード規模も関数名と対応付けて記録する機能も持つ。

次に、本第２の実施形態の動作例を図５を用いて説明する。なお図５は仮想マシン２００で実行される処理内容を示しており、アプリケーション１００の処理内容は省略している。

まずアプリケーション１００はＪＩＴコンパイルの対象関数名ＦＢとＪＩＴコンパイルの指示を仮想マシン２００に送る。この時、関数ＦＢをアプリケーションが利用開始する時刻までの時間的余裕度を示すパラメータもあわせて送る。この時間的余裕度とは例えば、“長”、“短”の２段階の値である。アプリケーションが関数ＦＢをすぐ使用したい場合は“短”、しばらく後に使用したい場合は“長”、というように時間的余裕度のパラメータ値をアプリケーション指示受付部３０１へ送る。仮想マシン２００のアプリケーション指示受付部３０１は、上記のように、関数ＦＢとその時間的余裕度を示す情報を受信する（Ｓ５０１）。

次に、ＪＩＴコンパイル命令制御部３０２は、アプリケーション指示受付部３０１からの情報の時間的余裕度の値を見て“長”であった時、ＪＩＴコンパイラ稼働監視部３０４へ命令する。命令を受けたＪＩＴコンパイラ稼働監視部３０４は、ＪＩＴコンパイラが今現在稼働しているかどうかを調べる（Ｓ５０２）。そして、ＪＩＴコンパイラが稼働しておらず、かつ、時間的余裕度が“長”である場合、インライン展開の深さを大きな値に設定することで実行速度優先のネイティブコードの生成ためのＪＩＴコンパイルを開始する。このインライン展開の深さを指定する値は、例えばＪａｖａ(登録商標)においては”-XX:MaxInlineSize”というオプションの指定値が相当する。これを大きな値にするほど高速に動作可能なネイティブコード（以下、高速版ネイティブコード）が生成される。ただし通常よりコンパイル処理時間は長くなる（Ｓ５０３、Ｓ５０４）。

一方、時間的余裕度が“短”である場合は、インライン展開の深さの値を変えない通常のＪＩＴコンパイル開始を指示する（Ｓ５０３、Ｓ５０５）。

なお、Ｓ５０４とＳ５０５において、ＪＩＴコンパイラが既に別の関数のコンパイル稼働中である場合は終了を待ってからコンパイル開始を指示する。この場合、その終了を待つので、“短”としてコンパイルさせる。なお、Ｓ５０３で示した高速版ネイティブコードの生成条件は別のものでもよい。例えば、時間的余裕度が“長”であれば常に高速版ネイティブコードを生成するようにしてもよい。

また、高速版ネイティブコードの生成方法として、インライン展開の深さを変更する例を示したが、より高速に動作するネイティブコードを生成できる手段であれば他のものでもよい。例えばコード最適化を行う、Ｊａｖａ(登録商標)におけるＣ２コンパイラを利用するといったものでもよい。

以上のようにすれば、アプリケーションが実行する関数ＦＢを、より高速に動作することが可能となる。

なお、以上はネイティブコードを生成する実施形態であった。ネイティブコードをキャッシュから消去する処理や、ネイティブコードの生成を中断する処理は図３（ａ）および（ｂ）のＳ３０５〜Ｓ３１２と同様である。

［第３の実施形態］
本第３の実施形態は、アプリケーションが関数を使用する時刻が予想できる場合に、ＪＩＴコンパイルの開始時刻を指定する例である。まずアプリケーションが関数を使用する時刻を予想できるユースケースの例を挙げる。

例えばユーザが指定した時刻Ｔ１に印刷を開始するアプリケーションの場合、印刷処理に関係する関数ＦＣがＴ１に使用されることが予想できる。また例えば、印刷処理の実行前に毎回決められた設定ファイルの読み込みが必要なアプリケーションがある。このとき、過去の実績から予測して設定ファイルの読み込み処理にＴ２時間かかるとすれば、ユーザが印刷開始の操作を行った時点よりＴ２時間後に、印刷処理に関する関数ＦＣが使用されることが予想できる。以上のようにアプリケーションが関数ＦＣを使用する時刻が予想できる場合に、本第３の実施形態が適用できる。

本第３の実施形態の機能構成図は図４と同様であり、その処理内容を図６を用いて説明する。なお図６は仮想マシン２００で実行される処理内容を示し、アプリケーション１００の処理内容は省略している。

アプリケーション１００はＪＩＴコンパイルの対象関数名ＦＣと関数ＦＣを使用する時刻Ｔ３をアプリケーション指示受付部３０１へ送ることになる。つまり、仮想マシン２００のアプリケーション指示受付部３０１は、アプリケーション１００からＪＩＴコンパイルの対象関数名ＦＣと関数ＦＣを使用する時刻Ｔ３を受け付ける（Ｓ６０１）。次にＪＩＴコンパイル命令制御部３０２は、アプリケーション指示受付部３０１から受け取った情報に基づき、ＪＩＴコンパイラ２０１へ開始命令を送る時刻（以下、コンパイル開始時刻）Ｔ３´を決定する（Ｓ６０２）。

時刻Ｔ３’の決め方は、ＪＩＴコンパイル処理時間Ｔｃを過去のデータから予測しＴ３’＝Ｔ３−Ｔｃとする。Ｔｃの予測は、ＪＩＴコンパイラ稼働監視部３０４が記録していた過去のコンパイル処理時間のデータを用いる。まず対象関数ＦＣと同規模の関数を探し、その関数の過去のコンパイル処理時間をＴｃとする。

以上のようにして決定した時刻Ｔ３’になったら、ＪＩＴコンパイル命令制御部３０２がＪＩＴコンパイラ２０１へ開始命令を送り、ＪＩＴコンパイラ２０１がネイティブコードの生成を開始する（Ｓ６０３）。そして完了したら、ＪＩＴコンパイラ２０１がＪＩＴコンパイル命令制御部３０２へ完了通知を送る。通知を受けたＪＩＴコンパイル命令制御部３０２はＪＩＴコンパイラ稼働監視部３０４へ命令する。そして、ＪＩＴコンパイラ稼働監視部３０４が、ネイティブコードの生成にかかった時間や関数ＦＣのコード規模に関するデータを保存する（Ｓ６０４）。このデータは次回以降のコンパイル開始時刻の予測に用いる。

以上のようにすれば、アプリケーションによる関数呼び出しが長時間後となる場合でも、呼ばれる直前にネイティブコードを用意することができる。この結果、実際に該当する関数を実行する際には、キャッシュされた状態となるので、処理を高速に行うことが可能になる。なお、本第３の実施形態では、第２の実施形態で述べた高速版バイナリ作成と組み合わせて使用してもよい。つまり、コンパイル開始時刻が長時間先である場合には高速版バイナリを作成するようにしてもよい。

［第４の実施形態］
本第４の実施形態では、アプリケーション１００の種類に応じて生成済みのネイティブコードのキャッシュ優先度を変更する例を説明する。

まず、仮想マシン２００の一部のプログラム（仮想マシンとは独立したプログラムでも構わない）を利用し、あらかじめアプリケーションＩＤ（以下、ＡｐｐＩＤ）を設定しておく。図７は、この設定処理で生成されたアプリケーションＩＤと優先順位の対応関係のテーブルを示している。このテーブルは、補助記憶装置１００６に記憶保持されるものであり、変更、修正、削除などの指示がない限り、その情報は維持される。なお、システムアプリケーションA,Bは、ユーザが選択するのではなく、デフォルトして設定さてるものとする。

そして図３（ａ）のＳ３０１で仮想マシン２００がアプリケーション１００から指示を受ける際には、ＡｐｐＩＤも受け取るようにする。そして、Ｓ３０８でキャッシュ優先度を設定する際に、例えば図７に示す表に従って、アプリケーションごとに各々決められた優先度を用いる。図７ではアプリケーションごとにその重要度とキャッシュ優先度があらかじめ定義されている。また、図７によればシステムアプリケーション（ＡｐｐＩＤ＝００１、００２）はユーザアプリケーション（ＡｐｐＩＤ＝００３、００４）よりも高いキャッシュ優先度が与えられている。つまり、コードキャッシュ内にシステムアプリケーションが呼ぶ関数のネイティブコードと、ユーザアプリケーションが呼ぶ関数のネイティブコードが共存したとき、前者の方が長期間キャッシュ内に残る。この設定は、システムアプリケーションはユーザアプリケーションと比べて重要性が高く、いつも高速に動作させたいという場合に効果がある。

このようにすれば、重要なアプリケーションが呼ぶ関数のネイティブコードがコードキャッシュの上位位置に格納されるので、消される確率を下げるといった制御が可能となる。

［第５の実施形態］
本第５の実施形態は、アプリケーション指示受付部３０１が複数のアプリケーションから短時間に大量のＪＩＴコンパイル指示を受けた場合のコンパイル順番の調整に関して説明する。

仮想マシン２００が、大量の指示を短時間に受信すると、到着済みの指示によるＪＩＴコンパイル処理が終わるまで、残りの指示は待ち状態になる。本第５の実施形態では、この待ち状態になっている複数の指示の順番を組み替える。

例えば、図７のように指示の送信元のＡｐｐＩＤとその重要度が決められている場合、その重要度が高い順に待ち状態の指示順番を並び替える。この例では、重要なシステムアプリケーションＡｐｐＩＤ=００１から来た指示が一番上に変更される。このようにすれば、大量のＪＩＴコンパイル指示があった場合でも、重要なアプリケーションが使用するネイティブコードが優先して先に生成される。

また他の例として、アプリケーションの重要度の代わりに、過去の履歴情報を元に順序を変更してもよい。例えばＳ３０９でアプリケーションから終了指示が来た場合、指示の送信元のＡｐｐＩＤを記録し、ＡｐｐＩＤごとの終了指示が来た回数を集計する。第１の実施形態で述べたように通常はアプリケーションが関数ＦＡの使用が終わったらその終了指示を出す。しかしアプリケーションがハングアップ等の異常状態になって終了指示を出さない場合がある。つまり終了指示が来た回数が少ないアプリケーションは、異常状態になる確率が高いと判断される。そこでこのようなアプリケーションから来た指示の順番を下げるようにする。このようにすれば、異常状態にならない通常のアプリケーションの指示を優先させることができる。

（その他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

１０００…情報処理装置、１００１…中央演算処理装置、１００２…メモリ、１００３…入力装置、１００４…出力装置、１００５…タイマ、１００６…補助記憶装置、１００７…通信インターフェース、１００８…システムバス、１００…アプリケーション、１０１…アプリケーション処理実行部、１０２…ＪＩＴコンパイル開始指示部、１０３…ＪＩＴコンパイル終了指示部、２０１…ＪＩＴコンパイラ、２０２…ネイティブコード、２０３…ネイティブコードキャッシュ管理部、２０４…処理命令部、３００…ＪＩＴ管理部、３０１…アプリケーション指示受付部、３０２…ＪＩＴコンパイル命令制御部、３０３…キャッシュ優先度指定部

Claims (8)

1. アプリケーションを実行する仮想マシンとして機能する情報処理装置であって、
   前記アプリケーションから要求された関数に対応するネイティブコードがキャッシュメモリに格納されている場合、当該ネイティブコードを実行し、前記キャッシュメモリに格納されていない場合、前記アプリケーションから要求された関数をインタプリタ形式に実行する実行手段と、
   前記アプリケーションからのコンパイル要求を受信した場合、要求された関数のコンパイルを行い、生成されたネイティブコードを前記キャッシュメモリに登録する動的コンパイル手段と、
   前記アプリケーションから、関数の終了の要求を受信した場合、要求されたネイティブコードを前記キャッシュメモリより消去、もしくはキャッシュメモリへの維持する優先度をより低く設定する設定手段と、
   を有することを特徴とする情報処理装置。
2. 前記動的コンパイル手段は、
   前記アプリケーションから、前記関数を利用するタイミングまでの時間的余裕が少なくとも２段階のいずれであるかを示す情報を受信した場合、時間的余裕が大きいほど実行速度優先のネイティブコードを生成するためのパラメータを設定してコンパイルを行う
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記動的コンパイル手段は、
   前記アプリケーションから、前記関数を利用する時刻が設定された場合、当該時刻にてネイティブコードの生成が完了するためのコンパイル開始時刻を決定し、当該決定した時刻になったときにコンパイルを行う
   ことを特徴とする請求項１に記載の情報処理装置。
4. アプリケーションの種類と優先度とを対応関係を示すテーブルを記憶する記憶手段を更に有し、
   前記動的コンパイル手段は、前記テーブルを参照し、関数のコンパイル要求したアプリケーションの種類に応じた優先度に対応するキャッシュメモリの位置に、生成したネイティブコードを格納することを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
5. アプリケーションの種類と優先度とを対応関係を示すテーブルを記憶する記憶手段を更に有し、
   前記動的コンパイル手段は、複数のアプリケーションからのコンパイル要求を受信した場合、優先度の高いアプリケーションからのコンパイル要求を優先することを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
6. アプリケーションを実行する仮想マシンとして機能する情報処理装置の制御方法であって、
   実行手段が、前記アプリケーションから要求された関数に対応するネイティブコードがキャッシュメモリに格納されている場合、当該ネイティブコードを実行し、前記キャッシュメモリに格納されていない場合、前記アプリケーションから要求された関数をインタプリタ形式に実行する実行工程と、
   動的コンパイル手段が、前記アプリケーションからのコンパイル要求を受信した場合、要求された関数のコンパイルを行い、生成されたネイティブコードを前記キャッシュメモリに登録する動的コンパイル工程と、
   設定手段が、前記アプリケーションから、関数の終了の要求を受信した場合、要求されたネイティブコードを前記キャッシュメモリより消去、もしくはキャッシュメモリへの維持する優先度をより低く設定する設定工程と、
   を有することを特徴とする情報処理装置の制御方法。
7. コンピュータが読み込み実行することで、前記コンピュータを、請求項１乃至５のいずれか１項に記載の情報処理装置が有する各手段として機能させるためのプログラム。
8. 請求項７に記載のプログラムを格納したコンピュータが読み込み可能な記憶媒体。

Images