アプリケーションサーバ
【課題】アプリケーション実行性能の状況に応じて、動的コンパイルのタイミングを最適化するアプリケーションサーバを提供する。
【解決手段】動的コンパイルにおいて、各メソッドの実行頻度などの情報を基に、メソッドごとにコンパイルを行なうタイミングを設定し、全体のアプリケーションプログラムの実行性能に与える影響の大きいメソッドから早めにコンパイルを行なうようにする。これにより、インタプリタによる実行とネイティブコードによる実行のバランスを最適にすることで、アプリケーションプログラムの起動直後の実行性能が安定する。
【解決手段】動的コンパイルにおいて、各メソッドの実行頻度などの情報を基に、メソッドごとにコンパイルを行なうタイミングを設定し、全体のアプリケーションプログラムの実行性能に与える影響の大きいメソッドから早めにコンパイルを行なうようにする。これにより、インタプリタによる実行とネイティブコードによる実行のバランスを最適にすることで、アプリケーションプログラムの起動直後の実行性能が安定する。
【発明の詳細な説明】
【技術分野】
【０００１】
以下の実施形態は、アプリケーション実行性能の状況に応じて、動的コンパイルのタイミングを最適化するアプリケーションサーバに関する。
【背景技術】
【０００２】
Java（登録商標）やMicrosoft .NETのように、アプリケーションプログラムの実行環境として、あるアプリケーションを開始してから、インターネットを通してプログラムを受け取って実行したり、動的に生成されたプログラムを実行する形態のアプリケーションプログラムに対して、仮想マシンによる実行環境が多く利用されている。
【０００３】
アプリケーションプログラムを仮想マシン環境で実行するのは、プログラムをアプリケーションプログラムの起動後（つまり実行時）に読み込んで実行することや、プログラムを様々なプラットフォーム（ハードウェアやＯＳ（Operating System)）で実行するのに適している（仮想マシンがプラットフォーム依存の処理を吸収する）からである。これに対して、C言語やCOBOLなどで作られたアプリーションは、アプリケーションを実行する前に、静的コンパイラによって、アプリケーションプログラムを、動作させるプラットフォームに依存した実行形式のプログラムに変換(コンパイル) しておく方式が一般的である。
【０００４】
仮想マシンでアプリケーションプログラムを実行する場合の実行環境の特徴として、アプリケーションプログラムをインタプリタで(プログラムの命令を１つずつ解釈実行して)動作する手段と、ネイティブコード（機械命令）にコンパイルしてから実行する手段があり、どちらか一方の手段だけを持つ実行環境の場合や、両方の手段を持つ実行環境の場合がある。
【０００５】
インタプリタによる実行は、一般的にネイティブコードによる実行より数倍から数百倍程度遅く、ネイティブコードに変換してから実行するのが一般的である。しかし、ネイティブコードへの変換（コンパイル）は、アプリケーションプログラムの実行時に行われるため、アプリケーションの実行時間には、コンパイル処理の時間が含まれる。
【０００６】
特に、アプリケーションプログラムの起動直後には、多くのコンパイル処理が動作するため、アプリケーションプログラムの起動直後の実行性能が安定しないという問題がある。アプリケーションプログラムのコンパイルは、アプリケーションプログラムの起動後(実行時)に行われることから、動的コンパイラ、あるいはJust In Time (ジャストインタイム)コンパイラ と呼ばれている。
【０００７】
仮想マシンでアプリケーションプログラムを実行するときに、動的コンパイルを行うことによる影響を低減させる技術には以下がある。
１つ目は、動的コンパイラの最適化処理の程度を弱めて、コンパイル処理を軽くする方式である。コンパイラの最適化処理とは、出力するするネイティブコードをより高速なコードに変換するため処理で、最適化処理を強力にすればネイティブコードは高速になるが、コンパイル処理の負担は重くなる。このため、アプリケーションプログラムの起動時の性能を求められる場合、例えば、クライアント向けの仮想マシンでは、最適化処理の軽いコンパイラを使用することで、起動時の性能を優先するように調整している。一方、多くのアプリケーションプログラムを実行する必要のあるアプリケーションサーバ向けの仮想マシンでは、最適化処理を強化したコンパイラを使用することで、最大性能を優先するように調整している。
【０００８】
１つ目の従来技術などで使用されるJava仮想マシンについては、http://java.sun.com/j2se/1.5.0/ja/docs/ja/guide/vm/index.htmlのサイトの記述を参照されたい。
【０００９】
２つ目は、起動時のコンパイル処理による負担を抑えつつ、最大性能も得られるように調整する方式である。この方式によるコンパイラは適用型コンパイラとよばれ、アプリケーションプログラムの起動時はインタプリタで実行を始めて、実行しながらプログラムを解析してパフォーマンスのボトルネック（頻繁に動作するメソッド）を見つける方式を使用している。性能に影響のあるメソッドはコンパイルするが、実行頻度の低いメソッドはコンパイルすることがないため、アプケーションプログラムの起動時にコンパイル処理による負担を軽減して、最大性能も得られることを狙っている。
【００１０】
２つ目の従来技術等で使用されるJava仮想マシンについては、上記ウェブサイトを参照されたい。
Oracle JRockit JDK、 JIT コンパイルと最適化の概要については、http://otndnld.oracle.co.jp/document/products/jrockit/geninfo/diagnos/underst_jit.htmlのサイトの記述を参照されたい。
【００１１】
また、３つ目として、アプリケーションプログラムを起動後、アプリケーションプログラムへの入力を受け付ける（業務を開始する）前に、予め（例えば前回のアプリケーションプログラムの実行時に得た）情報を元に、使用頻度の高いプログラムを事前に読み込み、コンパイルを済ませておく方式がある。
【００１２】
従来技術には、実行頻度の高い手続きをネイティブコードへ変換する処理を短時間で開始することができ、かつ、この変換処理にともなう負荷によってアプリケーションの実行に支障が生じることを防止することができるシステムがある。
【先行技術文献】
【特許文献】
【００１３】
【特許文献１】特開２００７−２１３４９０号公報
【発明の概要】
【発明が解決しようとする課題】
【００１４】
前述したように、仮想マシンでアプリケーションプログラムを実行する環境では、アプリケーションプログラムの起動後に、動的コンパイラ、あるいは、ジャストインタイムコンパイラとよばれるコンパイラによって、一般的にネイティブコードに変換してから実行するのが一般的である。
【００１５】
ネイティブコードへの変換（コンパイル）は、アプリケーションプログラムの実行時に行われるため、アプリケーションプログラムの実行時間には、コンパイル処理の時間が含まれるという避けられない問題がある。
特に、アプリケーションの起動直後には、多くのコンパイル処理が動作するため、起動直後のアプリケーションの実行性能が安定しないという問題がある。
【００１６】
図１は、起動直後のアプリケーションの実行性能が安定しない例を示す図である。
グラフの横軸は、仮想マシンが起動してからの経過時間、右側縦軸は、アプリケーションプログラムが処理要求(リクエスト)を処理するのに要した時間（レスポンス時間）、左縦軸は、コンパイラがネイティブコードに変換したプログラム（メソッド）の総数を示す。処理要求の開始直後は、ネイティブコードがそろっていない(一部のプログラムはインタプリタで実行される)ことと、コンパイル処理が多く動作することで、処理時間が安定していない。
【００１７】
この問題に対して、１つ目の従来技術では、コンパイラの最適化の程度を妥協して、コンパイル処理を軽くする方式を使用した。この方式では、クライアントマシンのような特定の実行環境では有効である。しかし、最大性能を求められるアプリケーションサーバ向けの仮想マシンを使用した環境では、コンパイラの最適化が弱いため、アプリケーションプログラムの最大性能を犠牲にすることになる。例えば、毎朝の９時に業務を開始するアプリケーションサーバで動作するアプリケーションプログラムがあり、開始直後から大量の処理をこなさなければならないような場合には不向きである（例えば、インタネートによるチケット販売）。
【００１８】
２つ目の従来技術では、ボトルネックとなる実行頻度の高いメソッドだけをコンパイルする方式を使用した。この方式は、すべてのプログラムをコンパイルする方式と比べると、アプリケーション起動時の性能に効果があった。しかし、起動後、インタプリタによる実行とプログラムの実行頻度の解析をどのくらいの期間するのが適切か、また、いつコンパイル処理を実施してネイティブコードによる実行に変えたら効果が得られるかは、いろいろな要因（ハードウェアの性能、アプリケーションプログラムの特性、アプリケーションプログラムが扱う処理量など）に依存する。プログラムのボトルネック（実行頻度の高いメソッド）を見つける方式としては、プログラム（メソッド）の呼び出し回数やループ回転数によって判断する方式が知られている。しかし、インタプリタ実行とネイティブコードによる実行の最適なバランスを見つけるのは非常に難しく、従来は、プログラム（メソッド）の実行が特定の回数に到達したらコンパイルを行う方式を採用しており、バランス調整は行っていない。したがって、２つ目の従来技術による仮想マシンを使用しても、アプリケーションプログラムの起動時の性能が運用要件を満たさない例があるのが現状である。
【００１９】
３つ目の従来技術では、アプリケーションを起動後、アプリケーションプログラムへの入力を受け付ける（業務を開始する）前に、予め、使用頻度の高いプログラム（メソッド）を事前に読み込み、コンパイルを済ませておく方式を使用した。しかし、この方式は、アプリケーションプログラムの実行中にインターネットを通してプログラムを読み込んだり、実行時以後にプログラムが生成されるようなアプリケーションに対しては不向きであった。
【００２０】
Java言語のように、動的にプログラムを読み込む（必要になったときに読み込む）という仕様の場合、あるメソッドから別のメソッドを参照しているときに、参照されるメソッドがまだ読み込まれていような場合は、コンパイラが生成するコードには余分なコードが増える。
【００２１】
これは、「プログラムが読み込まれていなかったら、プログラムを読み込んで参照を解決する」というコードをコンパイラが生成するコードの中に組み込まなければいけないためである。３つ目の従来技術では、このようなコードが増えるため、アプリケーションの実行中にインターネットを通してプログラムを読み込んだり、実行時以後にプログラムが生成されるようなアプリケーションに対しては不向きである。
【００２２】
また、コンパイラの最適化処理の面で不利になる。すなわち、コンパイラはプログラムの実行を予測することで、より強力な最適化を行うことができる(例えば、if文の分岐確率、仮想関数呼び出しで頻繁に呼ばれる関数) 。動的にプログラムを読み込んで実行する場合、コンパイル前のインタプリタ実行中にプログラムの動的な情報を収集して（プロファイルして）、コンパイラの最適化に利用するのが一般的である。しかし、３つ目の従来技術のようにプログラムの実行前にコンパイルすると、このような最適化ができなくなるため不利である。
【００２３】
以下の実施形態においては、アプリケーション実行性能の状況に応じて、動的コンパイルのタイミングを調整するアプリケーションサーバを提供する。
【課題を解決するための手段】
【００２４】
以下の実施形態の一側面におけるアプリケーションサーバは、プログラムの実行に際して動的コンパイルを行うアプリケーションサーバであって、該プログラムをインタプリタによって実行する際、該プログラムの実行性能に関する情報を取得する実行性能情報取得部と、該実行性能に関する情報に基づいて、該プログラムに含まれる各メソッドについて、それぞれコンパイルタイミングを指定する情報を設定するコンパイルタイミング情報設定部と、該コンパイルタイミングを指定する情報に基づいて、該メソッドをネイティブコードにコンパイルする動的コンパイル部とを備える。
【発明の効果】
【００２５】
以下の実施形態によれば、アプリケーション実行性能の状況に応じて、動的コンパイルのタイミングを調整するアプリケーションサーバを提供することができる。
【図面の簡単な説明】
【００２６】
【図１】起動直後のアプリケーションプログラムの実行性能が安定しない例を示す図である。
【図２】アプリケーションサーバ上で仮想マシンが動作する環境で、起動直後にアプリケーションプログラムの実行性能が安定しない例を示す図である。
【図３】図２の例に示したアプリケーションプログラムの実行に対して、プログラム（メソッド）の特徴ごとに、コンパイル処理の状況（コンパイル処理量とコンパイルの発生タイミング）を示したイメージを示す図である。
【図４】本実施形態の動的コンパイルを適用した場合に、図３に示したコンパイル処理の状況がどのように変化するかを示す図である。
【図５】アプリケーションプログラムの実行性能とコンパイル処理量の傾向とその分類を説明する図（その１）である。
【図６】アプリケーションプログラムの実行性能とコンパイル処理量の傾向とその分類を説明する図（その２）である。
【図７】アプリケーションプログラムの実行性能とコンパイル処理量の傾向とその分類を説明する図（その３）である。
【図８】アプリケーションプログラムの実行性能とコンパイル処理量の傾向とその分類を説明する図（その４）である。
【図９】コンパイルタイミング調整の判断基準情報を取得する２回のタイミングを示す図である。
【図１０】コンパイルタイミング調整の判断基準情報からコンパイルのタイミングを調整する方法を説明する図（その１）である。
【図１１】コンパイルタイミング調整の判断基準情報からコンパイルのタイミングを調整する方法を説明する図（その２）である。
【図１２】本実施形態が適用されるシステムの構成例を示す図である。
【図１３】アプリケーションサーバ上で動作する各機能のブロック構成を示す図である。
【図１４】仮想マシン上、および、仮想マシンの動的コンパイラでの動作を説明する図（その１）である。
【図１５】仮想マシン上、および、仮想マシンの動的コンパイラでの動作を説明する図（その２）である。
【図１６】仮想マシン起動部の動作フローチャートである。
【図１７】アプリケーションプログラムの実行性能計測・通知部の動作フローチャートである。
【図１８】アプリケーションの実行性能計測・通知部が使用するデータを示す図である。
【図１９Ａ】コンパイル集中度の計測部の動作フローチャート（その１）である。
【図１９Ｂ】コンパイル集中度の計測部の動作フローチャート（その２）である。
【図２０】コンパイル集中度の計測部が使用するデータを示す図である。
【図２１】プログラム(メソッド)実行頻度の計測部の動作フローチャートである。
【図２２】プログラム(メソッド)実行頻度の計測部が使用するデータを示す図である。
【図２３Ａ】コンパイルタイミング調整決定部の動作フローチャート（その１）である。
【図２３Ｂ】コンパイルタイミング調整決定部の動作フローチャート（その２）である。
【図２４】コンパイルタイミング調整決定部が扱うデータを示す図である。
【図２５Ａ】コンパイルタイミング制御情報の計算と出力部の動作フローチャート（その１）である。
【図２５Ｂ】コンパイルタイミング制御情報の計算と出力部の動作フローチャート（その２）である。
【図２５Ｃ】コンパイルタイミング制御情報の計算と出力部の動作フローチャート（その３）である。
【図２６】コンパイルタイミング制御情報の計算と出力部が扱うデータを示す図である。
【図２７】コンパイルタイミング制御情報の入力・判断部の動作フローチャートである。
【図２８】コンパイルタイミング制御情報の入力・判断部が使用するデータを示す図である。
【図２９】動的コンパイル部の動作フローチャートと使用するデータを示す図である。
【図３０】本実施形態の効果を説明する図（その１）である。
【図３１】本実施形態の効果を説明する図（その２）である。
【発明を実施するための形態】
【００２７】
本実施形態では、アプリケーションプログラムの起動時に、多数のコンパイル処理が動作することで、アプリケーションプログラムの実行に使えるCPU時間が奪われる（オーバヘッド）ことを回避するように、コンパイルを行うタイミングを調整することで、インタプリタによる実行とネイティブコードによる実行のバランスを最適にする（各々のプログラムのコンパイルを行うタイミングを遅らせた方がアプリケーションプログラムの実行性能がよくなるのか、早めた方がよいのかを判断する）ことで、アプリケーションプログラムの起動直後の実行性能を安定させる。
【００２８】
これは、（１）アプリケーションプログラムの起動直後の性能が安定しない期間は、コンパイルの処理量を減らす、（２）しかし、実行性能に大きく影響するプログラム(メソッド）は、起動直後の性能が安定しない期間であっても、コンパイルのタイミングを早めてインタプリタからネイティブコードの実行に早く切り替え、逆に実行性能への影響が少ないプログラム（メソッド）は起動直後のコンパイルが集中して性能が安定しない期間で行わないことで実現する。
【００２９】
つまり、アプリケーションプログラムの起動直後のコンパイルの集中を分散化させ、実行性能に影響するプログラム（メソッド）は適切なタイミングでコンパイルさせる。なお、コンパイルを行うプログラムの単位は、メソッドごとに行うこともあり、以下の説明で、プログラムをコンパイルするといったときは、メソッドのコンパイルの意味を含む。
【００３０】
そして、仮想マシンは、アプリケーションサーバで動作することを想定する。アプケーションサーバは、仮想マシンを起動して、仮想マシン上でアプリケーションプログラムの起動を開始する。アプリケーションプログラムによる業務を実行する準備が整った状態でアプリケーションプログラムの起動が完了する。つまり、アプリケーションプログラムの起動が完了するまでは、アプリケーションプログラムは業務を開始しない（アプリケーションサーバ上でアプリケーションプログラムの実行が可能な状態になることをアプリケーションサーバの起動が完了したという場合がある）。
【００３１】
アプリケーションプログラムの起動が完了する以前に実行を開始したプログラム（メソッド）は、アプリケーションプログラムの起動が完了する前にプログラム(メソッド）のコンパイルを完了することで、業務の開始後に、これらのプログラム(メソッド）がコンパイルされることはなくなる。これにより、業務開始後にコンパイルされるメソッドの数が減るので、（１）が実現できる。
【００３２】
従来技術では、アプリケーションの起動が完了する以前に実行を開始したプログラム(メソッド）が、業務を開始してからコンパイルされることがあった。また、アプリケーションプログラムの起動後に実行されるプログラム（メソッド）は、アプリケーションプログラムの実行性能への影響度と、そのときのコンパイル処理の負荷の状況に応じて、コンパイルのタイミングを早めたり遅らせたり調整することで（２）を実現できる。
【００３３】
図２は、アプリケーションサーバ上で仮想マシンが動作する環境で、起動直後にアプリケーションプログラムの実行性能が安定しない例を示す図である。
アプリケーションプログラムが起動を開始すると、起動に必要なプログラム（メソッド）の実行が始まり、これらのプログラム（メソッド）に対して多数のコンパイル処理が行われるが、起動が完了するころにはコンパイルの処理量は一時的に少なくなる。業務が開始されると、業務を実行するためのプログラム（メソッド）が動作して、これらのプログラム（メソッド）に対して多数のコンパイル処理が行われる。
【００３４】
このときに、アプリケーションプログラムの起動が完了するより前に、すでに実行を開始していたプログラム（メソッド）もこのタイミングでコンパイルされることがある。業務処理がある程度行われると、多くのプログラム（メソッド）がネイティブコードの実行に切り替わり、コンパイル処理数も少なくなることで、業務の処理時間（レスポンス時間）は安定してくる。
【００３５】
なお、図２においては、アプリケーションプログラムの起動完了と業務開始が同一時刻となっているが、実際には、アプリケーションプログラムの動作速度によって、短い時間単位で異なることが生じうる。しかし、図２においては、図示の便宜上、これらを同一時刻としている。
【００３６】
図３は、図２の例に示したアプリケーションの実行に対して、プログラム（メソッド）の特徴ごとに、コンパイル処理の状況（コンパイル処理量とコンパイルの発生タイミング）を示したイメージを示す図である。
【００３７】
黒丸が１つのプログラム（メソッド）のコンパイルを示しており、プログラム（メソッド）のコンパイルの特徴によって、（ａ）、（ｂ）、（ｃ）の３つの特徴に分けて、コンパイル処理の発生状況を示している。
【００３８】
（ａ）は「アプリケーションプログラムの起動完了時点で１度でも実行されているプログラム（メソッド）のコンパイル」を示す。（ｂ）は「アプリケーションプログラムが業務を開始後に実行されるプログラム（メソッド）で、かつ、実行性能への影響が大きいプログラムのコンパイル」を示す。（ｃ）は「アプリケーションプログラムの業務開始後に実行されるプログラム（メソッド）で、かつ、実行性能への影響が小さいプログラムのコンパイル」を示す。
【００３９】
アプリケーションプログラムが業務を開始した直後では、コンパイル処理が集中しており、この時点では、インタプリタによる実行からネイティブコードでの実行への切り替えが徐々に行われている。
【００４０】
図４は、本実施形態のコンパイルを適用した場合に、図３に示したコンパイル処理の状況がどのように変化するかを示す図である。
（ａ）のアプリケーションプログラムの起動完了時点で１度でも実行されているプログラム(メソッド）は、アプリケーションプログラムの起動が完了する前にコンパイルをすることで、業務を開始するより前にコンパイルが完了している。これにより、起動直後の性能が安定しない期間のコンパイル処理の集中が緩和されている。（ｂ）のアプリケーションプログラムが業務を開始後に実行されるプログラムで、かつ、実行性能への影響が大きいプログラム（メソッド）は、従来より早いタイミングでコンパイルすることで、インタプリタによる実行からネイティブコードによる高速な実行への切り替えが速く進む。（ｃ）のアプリケーションプログラムが業務を開始後に実行されるプログラム（メソッド）で、かつ、実行性能への影響が小さいプログラム（メソッド）は、従来より遅いタイミングでコンパイルをすることで、起動直後の性能が安定しない期間のコンパイル処理の集中が緩和されている。
【００４１】
ここで、黒丸は１つのプログラム(メソッド）のコンパイルを示す。また、図３と同様に、（ａ）は、 アプリケーション起動完了時点で１度でも実行されているプログラム(メソッド）のコンパイル、（ｂ）は、アプリケーションが業務を開始後に実行されるプログラム(メソッド）で、かつ実行性能への影響が大きいプログラム(メソッド）のコンパイル、（ｃ）は、アプリケーションが業務を開始後に実行されるプログラム(メソッド）で、かつ実行性能への影響が小さいプログラム(メソッド）のコンパイルを示す。
【００４２】
アプリケーション起動完了後に初めて実行されるプログラム(メソッド）（ｂ）、（ｃ）は、実行性能への影響の度合いに応じて、コンパイルのタイミングを早めたり遅らせたりする調整をするが、調整の決定には個々のプログラム(メソッド）の特徴だけでなく、アプリケーションプログラムの実行性能とコンパイル処理量の全体的な傾向、実際の状況に合わせて総合的に判断する必要がある。
【００４３】
例えば、あるプログラム(メソッド）は、実行性能への影響がある程度大きいので早めにコンパイルしたいが、コンパイル処理量が全体的に多いアプリケーションプログラムでは、調整をすることにより、さらにコンパイル処理の負担が増え、逆に実行性能を低下させる可能性もある。
どのようなケースで、どのような総合的な判断をしたらいいのかを示すために、アプリケーションプログラムの実行性能とコンパイル処理量の傾向の主要なケースを説明する。
【００４４】
図５〜図８は、アプリケーションプログラムの実行性能とコンパイル処理量の傾向とその分類を説明する図である。
図５〜図７では、横軸に時間、右縦軸に処理時間、左縦軸にコンパイル数をとっている。
【００４５】
図５のケース１は、（１）アプリケーションプログラムの業務処理（運用）開始直後に急激的にコンパイル処理量が増え、（２）業務処理開始直後の実行性能（処理時間）と安定時の実行性能（処理時間）の性能差（処理時間（レスポンス時間）の差）が大きいが、（３）実行性能（処理時間）が不安定な期間が短い場合である。
【００４６】
このケースは、業務処理開始直後（運用開始直後）の短期間にコンパイル処理が集中するため、この期間は、実行性能の低下が大きくなるが、全体的にインタプリタによる実行からネイティブコードによる実行へ早く切り替わるために、実行性能が安定するまでの期間が短い。
【００４７】
図６のケース２は、（１）アプリケーションの運用開始後からコンパイル処理が徐々に進み、（２）運用直後の実行性能と安定時の実行性能の性能差は図５のケース１に比べると小さいが、（３）実行性能が不安定な期間が長い場合である。
【００４８】
このケースは、運用開始直後のコンパイル処理が急激に増えないため、コンパイル処理による実行性能への影響は小さいが、全体的にインタプリタによる実行からネイティブコードの実行への切り替えが徐々に行われるため、実行性能が安定するまでの期間が長くかかる場合である。
【００４９】
図７のケース３は、運用直後の実行性能と安定時の実行性能の性能差が大きく、かつ、安定した実行性能になるまでの期間が長い。このようなパターンは例外的であるが、原因として、インプリタによる実行とネイティブコードによる実行の性能差が大きい（図６のケース２に該当するが安定時とそうでないときの性能差が大きい）、または、多数のコンパイル処理が行われる期間が長い（図５のケース１に該当するがよりコンパイル処理が連続的に多く行われる）、あるいは、その両方が複合的に影響していることが考えられる。
【００５０】
この３つのケースを現象からとらえると、図８のように、実行性能が安定する前と安定した後の性能差の大小、および、安定した性能になるまでの不安定期間の長短の表で分類できる。また、このような現象が生じる要因には、実行性能に影響度が高いプログラム(メソッド）がネイティブコードによる実行に切り替わっているかどうか、コンパイル処理の集中度、コンパイル処理の集中期間の３つがある。それぞれのケースに応じて、これらの要因を調整することで、適切なコンパイルのタイミング調整をすることができる。
【００５１】
コンパイルのタイミング調整をおこなうための判断基準となる情報は、（１）実行性能の安定前と安定後の性能差、（２）実行性能が安定するまでの期間、（３）コンパイル処理の集中度、（４）コンパイル処理の集中期間、（５）プログラム（メソッド）ごとの実行頻度（重要度）になり、本実施形態では、これらに応じたコンパイルを行うタイミングの調整を行う。
この５つの情報を、コンパイルタイミング調整の判断基準情報と呼ぶ。
【００５２】
図９は、コンパイルタイミング調整の判断基準情報を取得する２回のタイミングを示す図である。
プログラム（メソッド）ごとの実行頻度（重要度）は、図３、図４の特徴（ａ）、（ｂ）、（ｃ）に応じた調整を行うために、アプリケーションプログラムの起動が完了した時点と、アプリケーションプログラムの運用開始後であって性能が安定した時点の２回取得する。
【００５３】
アプリケーションプログラムの運用開始後に、性能がいつ安定したか判別できない場合は、予め設定した測定期間が過ぎたときに取得するか、あるいは、コンパイル処理の集中度が変化した時点に取得してもよい。
【００５４】
コンパイルタイミング調整の判断基準情報は、アプリケーションプログラムの実行を実施して初めて取得することができる（アプリケーションプログラムを実行しないと取得することができない）。このため、アプリケーションプログラムを運用する前のテスト時に運用時と同じ環境でアプリケーションを動作させて判断基準情報を取得し、各プログラム（メソッド）のコンパイルを行うタイミングを決定し、コンパイルのタイミングを調整するための情報を作成する。
【００５５】
コンパイルのタイミングを調整する情報の作成は、運用前のテスト時だけでなく、アプリケーションプログラムの最初の運用や、必要になったときなどの任意の運用時に行うこともできる。１度作成すると、それ以後の運用で使用することができる。コンパイルタイミング調整の判断基準情報のうち、（１）実行性能の安定前と安定後の性能差、（２）実行性能が安定するまでの期間は、アプリケーションサーバが取得して、仮想マシンに通知する。（３）コンパイル処理の集中度、（４）コンパイル処理の集中期間、（５）プログラム（メソッド）ごとの実行頻度（重要度）は、仮想マシンが取得する。
【００５６】
（１）の実行性能の安定前と安定後の性能差は、アプリケーションプログラムの起動開始時点を安定前とし、コンパイル処理するメソッドの数の揺らぎが所定値以下になった時点を安定後として、性能差（レスポンス時間の差）を取得することによって得られる（後述の図１７のステップＳ１６、Ｓ１８に対応する）。（２）の安定するまでの期間は、（１）の安定前から安定後の間の時間である。（３）のコンパイルの集中度は、所定の測定時間内に行なわれるコンパイル処理の数である。(４)のコンパイル処理の集中期間は、コンパイル処理の集中度を計測した時間である。（５）のプログラム(メソッド）ごとの実行頻度（重要度）は、メソッドごとに単位時間当たりに実行された回数を計測し、その回数から、閾値を用いて、メソッドを分類したものである（後述）。
【００５７】
アプリケーションサーバで実行するアプリケーションプログラムの場合は、アプリケーションプログラムの作成者（例えばＳＥ）とアプリケーションプログラムの利用者(運用者)は同じことが多い。
【００５８】
アプリケーションプログラムの作成者と利用者が同じ場合は、コンパイルタイミング調整の判断基準情報の収集時をテスト時に行うか、アプリケーションプログラムの運用時に行うかは、利用者の判断になる。
【００５９】
アプリケーションプログラムを製品として第三者（利用者）に提供する場合は、テスト時に一般的な利用形態にもとづいてコンパイルタイミング調整値を決定して、製品に同梱するという形態が考えられる（製品にコンパイルタイミング調整値の決定と利用を行う仕組みを持たせるという形態も可能である）。
【００６０】
図１０及び図１１は、コンパイルタイミング調整の判断基準情報からコンパイルのタイミングを調整する方法を説明する図である。
コンパイルを行うタイミングは、プログラム(メソッド)の実行頻度がどこまで到達したかによって決定する。本実施形態では、状況に応じてそれぞれのプログラム（メソッド）ごとに、実行頻度の到達に応じてコンパイルを行うタイミングを調整する。
【００６１】
従来技術では、メソッドの実行回数をカウントして、回数が事前に設定した閾値に到達したらコンパイルする。どのメソッドも、実行回数が固定の閾値に到達したときにコンパイルする。
【００６２】
本実施形態では、特徴（ａ）のメソッドはアプリケーションプログラムの起動が完了する前に、コンパイルが完了するように調整する。
特徴（ｂ）、（ｃ）のメソッドは、コンパイルタイミング調整の判断基準情報（（１）実行性能の安定前と安定後の性能差、（２）実行性能が安定するまでの期間、（３）コンパイル処理の集中度、（４）コンパイル処理の集中期間、（５）プログラム（メソッド）ごとの実行頻度（重要度））から求めたコンパイルタイミング調整値によって、コンパイルするタイミングを決定する。
【００６３】
特徴（ａ）のプログラム（メソッド）は、アプリケーションプログラムの起動が完了する前にコンパイルが完了するように調整する。アプリケーションプログラムの起動完了時点で測定したプログラム（メソッド）ごとの実行頻度を参照して、そのプログラム（メソッド）がコンパイルされるタイミングをアプリケーションプログラムの起動完了時点での実行頻度により規定されるコンパイルタイミングよりも少し早いタイミングで（予め決めた特定の割合だけ小さく見積もった実行頻度の到達で）、コンパイルが行われるようにする。これにより、アプリケーションプログラムの起動完了前に実行されたプログラム（メソッド）が、アプリケーションプログラムの運用開始後にコンパイルされることはなくなる。
【００６４】
特徴（ｂ）、（ｃ）のプログラム（メソッド）のコンパイルタイミングの調整方法を説明する。コンパイルタイミング調整の判断基準情報の１つであるプログラム（メソッド）ごとの実行頻度（重要度）は、実行頻度が高いものほどアプリケーションプログラムの実行性能への影響が大きいと考え、実行頻度に応じて、重要度１（極めて重要）、重要度２（重要）、重要度３（通常）、重要度４（重要度は低い）に分類する。また、コンパイル処理の集中度は、集中度の程度に応じて、集中度大、集中度中、集中度小に分類する。集中度と各プログラム（メソッド）の重要度に応じてコンパイルのタイミングを早めるのか遅らせるのかの基本的な方向性を決める。これに、実際のアプリケーションプログラムの運用状況、つまり、コンパイルタイミング調整の判断基準情報の、実行性能の安定前と安定後の性能差、実行性能が安定するまでの期間、および、コンパイル処理の集中期間を加味した最適化をして、コンパイルを行うタイミングを決定する。
【００６５】
特徴（ｂ）、（ｃ）のプログラム（メソッド）について、コンパイルタイミング調整の判断基準情報により、コンパイルのタイミングをどのように調整するのかの方針を示したものが図１０である。また、実際にどの程度の調整を行うかを数値で表したものが図１１である。
【００６６】
図１１に示した調整の係数は、コンパイルを実施する標準の実行頻度（コンパイルタイミングの標準実行頻度；予め決定された値）に、この係数を掛けた値に、プログラム（メソッド）の実行が到達したときにコンパイルを行うことを示す。この係数の値は、仮想マシン起動時点で予め決められた値を設定するか、またはプログラムの作成者あるいは、利用者が適宜設定する。
【００６７】
特徴（ａ）のプログラム（メソッド）については、前述の調整方法でも説明したとおり、コンパイルを行うタイミングは、プログラム(メソッド)の実行頻度がどこまで到達したかによって決定する。
【００６８】
図１０において、各メソッドは重要度にしたがって分類される。重要度は、メソッドの実行頻度を３つの異なる閾値（閾値１＞閾値２＞閾値３）と比較し、決定する。重要度１は、最も実行頻度が高いメソッドで、閾値１より大きな実行頻度を持つメソッドが分類される。重要度２は、閾値１よりは小さいが閾値２より大きな実行頻度を持つメソッドが分類される。重要度３は、閾値２よりは小さいが閾値３より大きな実行頻度を持つメソッドが分類される。重要度４は、閾値３よりは小さい実行頻度を持つメソッドが分類される。集中度についても、２つの閾値を設け、コンパイル処理の集中度の値を分類する。
【００６９】
重要度１のメソッドは実行頻度が大きいので、集中度が大、中、小のいずれでも、コンパイルタイミングを早める。特に、実行性能の安定前と安定後の性能差が大きいほど大きく早めるようにする。重要度２のメソッドは、集中度が大のときであって、実行性能が安定するまでの期間がコンパイル処理の集中期間と一致する場合に、コンパイルタイミングを遅らせる。集中度が中の場合には、何もしない。集中度が小のときは、コンパイルタイミングを早める。
【００７０】
重要度３のメソッドは、集中度が大のときは、コンパイルタイミングを遅らせ、集中度が中のときは何もせず、集中度が小のときは、実行性能が安定するまでの期間がコンパイルの集中期間に比べて長い場合に、コンパイルタイミングを早める。重要度４のメソッドは、いずれの集中度のときも、コンパイルタイミングを遅らせる。特に、実行性能の安定前と安定後の性能差が大きいほど大きく遅らせるようにする。ただし、集中度が大のときは、実行性能が安定するまでの期間がコンパイルの集中期間に比べて長い場合には、小さく遅らせる。
【００７１】
図１１は、図１０の定性的処理分類を、数値例を入れて具体的にしたものである。図１１において、具体的な数値は一例であり、実際の数値は仮想マシン起動時点で予め決められた値、またはプログラムの作成者あるいは利用者が適宜設定する。
【００７２】
ここで説明した、特徴（ｂ）、（ｃ）のプログラム（メソッド）に対するコンパイルタイミングの調整方法を、図８に示したアプリケーションの３つのケースに当てはめて、その作用を説明する。
【００７３】
ケース１（不安定・安定時の性能差が大きく、不安定な期間（実行性能が安定するまでの期間）が短い場合）になるのは、短期間にコンパイルが集中するケース（集中度大）が通常である。コンパイルの集中が性能を不安定にしている主原因であるかは、集中期間と不安定期間がほぼ一致するかどうかで判断できる（数値で判断するには、不安定期間÷集中期間が１．０に近い場合なので、例えば、この値が１．２以下であればコンパイル集中が主原因であると判断する）。重要度１のプログラム（メソッド）に対しては、コンパイルのタイミングを早めるが、重要度２〜４のプログラム（メソッド）に対してはコンパイルのタイミングを遅らせる。このとき重要度が低い（４に近いもの）ほど、大きく遅らせる。また、不安定・安定の性能差も考慮するが、性能差が大きい場合ほどコンパイルの集中の影響を受けているので、重要度が低いプログラム（重要度４）に対しては、性能差が大きい場合はコンパイルのタイミングをより遅らせる。その分、逆に、極めて重要なプログラムは、性能差が大きい場合ほどコンパイルのタイミングを早めて、ネイティブコードへの切り替えを早く行う。
【００７４】
ケース２（不安定・安定時の性能差が小さく、不安定な期間（実行性能が安定するまでの期間）が長い場合）になるのは、コンパイルが徐々に進む(集中度小で、実行からネイティブコードによる実行への切り替えが遅い)ケースが通常である。この状況は、コンパイル集中期間に対して不安定期間が長いかどうかで判断できる（数値で判断するには、不安定期間÷集中期間が大きい場合なので、例えば、この値が１．５より大きいと判断する）。重要度が通常より高い（重要度１〜３）場合は、コンパイルのタイミングを早めてネイティブコードによる実行への切り替えが早く行われるようにする。このとき、重要度が高いものほどコンパイルのタイミングを早める。また、不安定・安定の性能差も考慮するが、重要度１（極めて重要）なプログラムに対しては、性能差が大きいほどネイティブコードへの切り替えタイミングの遅れに影響するため、性能差が大きいほどコンパイルのタイミングを早める。重要度１〜３のプログラムのタイミングを早めた分、逆に、重要度４のプログラムのタイミングを遅らせることで、コンパイル時間の影響のバランスを取ることができる（重要度１のプログラムに対して、性能差大の場合はコンパイルのタイミングをより早めたので、重要度４では性能差大の場合にコンパイルのタイミングを遅らせる）。
【００７５】
ケース３（不安定・安定時の性能差が大きく、不安定な期間（実行性能が安定するまでの期間）が長い場合）は特殊なケースと考えられるが、コンパイルの集中が長く続く、あるいは、インタプリタによる実行とネイティブコードによる実行の性能差が大きいこと（または、その複合）が考えられる。この場合、不安定・安定時の性能差が大きく、不安定な期間が長いことから、集中度大に判定される可能性があるが、ケース１（同じく集中度大に分類される可能性の高い）の場合と係数の決め方を変える。ケース１とケース３の識別は、ケース１は、コンパイルの短期集中が主要因であるため、集中期間と不安定期間がほぼ一致するかどうかで判断した（数値では、不安定期間÷集中期間が１．２以下）。ケース３は、コンパイルの長期集中が要因とは限らないので、不安定期間が集中期間より長くなっているかで判断する（数値では、不安定期間÷集中期間が１．２より大きい；なお、この値は後にコンパイル集中期間影響率と呼ぶ）。その場合、ケース１と比べてケース３は、ネイティブコードへの切り替えの遅れが発生しているプログラムの割合が高いため、コンパイルのタイミングを早める場合（重要度１）、遅らせる場合（重要度４）のどちらも、コンパイルのタイミングをケース１より少し早める。
【００７６】
集中度が中の場合は、集中度が小と集中度が大の中間の状況に対応できるように係数を設定する。
なお、自動的に集中度に応じた調整を行う形態を説明したが、人の判断で、どのケースの調整方法を行うのかを指定できるようにしてもよい。
【００７７】
図１２は、本実施形態が適用されるシステムの構成例を示す図である。
本実施形態は、サーバマシン（アプリケーションサーバ）１０−１、１０−２に実装されるアプリケーションサーバプログラム１４、アプリケーションサーバプログラムに組み込まれる仮想マシン１２、仮想マシン上で動作する動的コンパイラ１３において実施される。アプリケーションサーバプログラム１４上では、アプリケーションプログラム１５が動作する。Ｗｅｂサーバプログラム１６は、アプリケーションプログラムやデータの受け渡しの仲介を行い、ＯＳ（Operating System)１７上で動作する。
【００７８】
サーバマシン１０−２は、上記のようなＷｅｂサーバプログラム１６とＯＳ１７を実装し、ネットワークを介して、クライアントマシン１１と通信したり、他のサーバマシン１０−１と通信する。サーバマシン１０−２は、クライアントマシン１１からの、アプリケーションプログラムの実行リクエストを受け取ったり、該リクエストに対するレスポンスをクライアントマシン１１に返送したりする。また、他のサーバマシン１０−１からは、ネットワークを介して、アプリケーションプログラム１５ａを受け取り、自サーバマシン１０−２にインストールしたりする。他のサーバマシン１０−１からアプリケーションプログラム１５ａを受信できるようにすることにより、自サーバマシン１０−２には実装されていなかったアプリケーションプログラム１５の実行をクライアントマシン１１からリクエストされた場合にも対応することができるようになる。
【００７９】
また、本実施形態のプロセスを実現するプログラムは、仮想マシン１２に組み込まれて実行されるが、これは、他のサーバマシン１０−１から自サーバマシン１０−２に、ネットワークを介してダウンロードされ、自サーバマシン１０−２にインストールされるようにしても良い。あるいは、本実施形態のプロセスを実現するプログラムは、ＣＤ−ＲＯＭ，ＤＶＤ、ＩＣメモリ、フレキシブルディスク、Ｂｌｕ−ｒａｙ等の可搬記録媒体１９に格納されていてもよい。この場合、可搬記録媒体１９に格納されている当該プログラムを媒体ドライバ１８で読み取り、サーバマシン１０−２にインストールするようにして使用する。
【００８０】
図１３は、アプリケーションサーバ上で動作する各機能のブロック構成を示す図である。
アプリケーションサーバ２０には、仮想マシン起動部２１、リクエストの送付部２２、アプリケーションの実行性能（レスポンス性能）計測・通知部２３を持つ。
【００８１】
仮想マシン起動部２１は、（１）仮想マシン１２を起動して、運用対象のアプリケーションプログラム１５を仮想マシン１２上で実行できるように、アプリケーションプログラム１５の起動を開始する。また、仮想マシン起動部２１は、（２）アプリケーションプログラム１５の起動が完了して、アプリケーションプログラム１５の運用の（リクエストを受け付ける）準備が整ったら、アプリケーションプログラム１５の起動完了通知を、仮想マシン１２に送付する。次に、リクエストの送付部２２は、（３）リクエストを仮想マシン１２上で動作するアプリケーションプログラム１５に送付する。アプリケーションの実行性能計測・通知部２３は、（４）アプリケーションの実行性能(レスポンス性能)を測定して、実行性能が安定する前と安定した後の性能差、および、安定した性能になるまでの期間を計測して、性能が安定したと判断した時に、仮想マシン１２に通知する。
【００８２】
図１４及び図１５は、仮想マシン上、および、仮想マシンの動的コンパイラでの動作を説明する図である。
仮想マシン１２は、動的コンパイラ１３に加え、コンパイル集中度の計測部３０、プログラム（メソッド）実行頻度の計測部３１、コンパイルのタイミング調整決定部３２、コンパイルタイミング制御情報の計算と出力部３３ （以上図１４）、コンパイルタイミング情報の入力・判断部３４(以上図１５)を持つ。
【００８３】
コンパイル集中度の計測部３０は、動的コンパイラ１３で行われているコンパイル処理を測定して、コンパイル集中度を求めるために、定められた期間、定められた時間単位にコンパイルされるプログラム数（メソッド数）を記録する。定められた期間とは、図９で示した、２回のコンパイルタイミング調整の判断基準情報の取得タイミングの間の時間である。
【００８４】
プログラム（メソッド）実行頻度の計測部３１は、プログラム（メソッド）が呼び出されたときに、そのプログラム(メソッド)の実行頻度を記録する。コンパイルのタイミング調整決定部３２は、コンパイル集中度の計測部３０、および、プログラム(メソッド)実行頻度の計測部３１を起動することで、あるいは、アプリケーションサーバ２０からの通知で、コンパイルタイミング調整の判断基準情報を収集して、これらの情報から、各プログラム（メソッド）のコンパイルタイミングを決定する。
【００８５】
コンパイルのタイミング調整決定部３２の手順は、（１）アプリケーションサーバ２０からアプリケーションプログラムの起動完了通知を受け取ったら、（２）プログラム（メソッド）実行頻度の計測部３１が記録した実行頻度を参照して、その時点（アプリケーションプログラムの起動が完了した時点の）プログラム（メソッド）ごとの実行頻度を保存する。また、（３）コンパイル集中度の計測部３０に、コンパイルの集中度の記録の開始を指示する。（４）アプリケーション性能が安定した時点で、アプリケーションサーバ２０からアプリケーション実行性能の通知(実行性能の安定前と安定後の性能差、実行性能が安定するまでの期間) を受けたら、（５）プログラム（メソッド）実行頻度の計測部３１が記録した実行頻度を参照する。そして、その時点（アプリケーション性能が安定した時点）で、プログラム（メソッド）ごとの実行頻度を保存する。 また、（６）コンパイル集中度の計測部３０に、コンパイルの集中度の記録の終了を指示する。以上の（１）〜（６）のプロセスで取得した情報がコンパイルのタイミング調整の判断基準情報になる。
【００８６】
コンパイルタイミング制御情報の計算と出力部３３は、コンパイルのタイミング調整の判断基準情報から、各プログラム（メソッド）のコンパイルのタイミングを決定して、コンパイルタイミング制御情報を出力する。コンパイルタイミング制御情報は、コンパイルのタイミング調整を行う１つのプログラム（メソッド）に対して、プログラム（メソッド）識別情報とコンパイルタイミング調整値を持つ。コンパイルタイミング調整値は、プログラム(メソッド）が実行される回数を示し、この回数分だけ実行されたらコンパイルするように指示するためのものである。具体的な数値は、予め決められた数値に、図１１で説明した係数を乗算したものを用いる。
【００８７】
図１５に示すように、コンパイルタイミング制御情報の入力・判断部３４は、コンパイルタイミング制御情報を使用して仮想マシン１２を起動する場合に動作する。アプリケーションサーバ２０は、アプリケーションプログラムに対応したコンパイルタイミング制御情報があれば、仮想マシン１２を起動するときに、コンパイルタイミング制御情報を通知して起動する。仮想マシン１２は、コンパイルタイミング制御情報の入力・判断部３４により、コンパイルタイミング制御情報を読み込む。また、プログラム（メソッド）の呼び出しがあった場合に、そのプログラム（メソッド）の実行頻度がコンパイルタイミング制御情報で指定された値に到達したら、動的コンパイラ１３に、そのプログラム（メソッド）のコンパイルを依頼する。
【００８８】
従来技術では、コンパイルを依頼するときの実行頻度は、どのプログラム（メソッド）でも固定の値であったが、本実施形態では、プログラム(メソッド)ごとに調整された値（コンパイルタイミング制御情報のコンパイル調整値）に実行頻度が到達していれば、動的コンパイラ１３に、そのプログラム（メソッド）のコンパイルを依頼する。該当するプログラム(メソッド)がコンパイルタイミング情報にない場合は、仮想マシン１２の起動時点で予め決められた標準値に到達した場合にコンパイルを依頼する。
【００８９】
図１６は、仮想マシン起動部の動作フローチャートである。
ステップＳ１０において、コンパイルタイミング制御情報が存在し、かつ、この情報を使用した起動であるか否かを判断する。ステップＳ１０の判断がＹｅｓの場合には、ステップＳ１１に進み、Ｎｏの場合には、ステップＳ１２に進む。ステップＳ１１では、仮想マシンを起動すると共に、実行するアプリケーションプログラムと、コンパイルタイミング制御情報を仮想マシンに通知する。ステップＳ１２では、仮想マシンを起動すると共に、実行するアプリケーションプログラムと、コンパイル制御情報を使用しないことを仮想マシンに通知する。ステップＳ１３において、アプリケーションプログラムの運用が開始可能になったら、アプリケーションプログラムの起動完了通知を仮想マシンに通知して、処理を終了する。
【００９０】
図1７は、アプリケーションプログラムの実行性能計測・通知部の動作フローチャートである。また、図１８は、アプリケーションの実行性能計測・通知部が使用するデータを示す図である。
【００９１】
図１８のデータ（１）（２）（４）は、アプリケーションサーバが使用するメモリ上に置かれ、データ（３）は仮想マシンが使用するメモリ上に置かれる。（１）の平均実行性能の記録では、アプリケーションプログラムについて、平均実行性能の測定を行なうたびに記録番号をつけ、平均実行性能、すなわち、平均レスポンス時間をミリ秒の単位で記録する。（２）の平均実行性能の記録回数は、（１）の平均実行性能の記録番号の最大値であり、予め設定される。（３）のアプリケーションサーバから通知された実行性能情報は、実行性能の安定前と安定後の性能差と、実行性能が安定するまでの時間からなる。（４）のデータの平均実行性能の最大記録回数、実行性能の安定判断の変動率、実行性能決定のサンプリング数は、仮想マシン起動時点で予め決められた値を使用する。
【００９２】
図１７において、ステップＳ１５では、アプリケーションプログラムの実行性能（レスポンス時間）を実行性能決定のサンプリング数だけ測定して、その平均実行性能を求め、平均実行性能の記録に設定する。このサンプリング数は、予め決定しておく。ステップＳ１６において、平均実行性能の変動の割合が、前回記録した平均実行性能に比べて、実行性能の安定判断の変動率より小さいか否かを判断する。ステップＳ１６の判断がＹｅｓの場合には、ステップＳ１８に進む。ステップＳ１６の判断がＮｏの場合には、ステップＳ１７に進む。ステップＳ１７では、平均の実行性能の記録回数が、平均実行性能の最大記録回数より大きいか否かを判断する。ステップＳ１７の判断がＹｅｓの場合には、ステップＳ１８に進む。ステップＳ１７の判断がＮｏの場合には、ステップＳ１５に戻る。ステップＳ１８では、最初に記録した平均の実行性能と最後に記録した平均の実行性能の割合から、実行性能の安定前と安定後の性能差（（実行性能の安定前と安定後の性能比）＝（安定前に記録した平均実行性能）÷（安定後に記録した平均実行性能））を求め、仮想マシンに通知する。また、平均実行性能を最初に記録した時刻と最後に記録した時刻の差から、実行性能が安定するまでの期間を求め、仮想マシンに通知する。
【００９３】
図１９Ａ、Ｂは、コンパイル集中度の計測部の動作フローチャートである。また、図２０は、コンパイル集中度の計測部が使用するデータを示す図である。
図２０のデータは、仮想マシンが使用するメモリ上に置かれる。（１）のコンパイル集中度の記録は、測定ごとに付けられる、コンパイル集中度の記録番号と、各測定が行なわれた時刻である、コンパイル集中度の測定時期（例えば、単位は秒）と、測定時に検出された実行中のコンパイル処理の数である、コンパイル集中度（例えば、単位は、個／秒）とからなる。（２）のデータは、コンパイル集中度の記録回数と、前回の計測時までに完了したコンパイルの総数とからなる。（３）のデータは、コンパイル処理の集中期間と、コンパイル処理の集中度（例えば、単位は、個／秒）とからなる。（４）のデータは、コンパイル集中度測定のサンプリング間隔、コンパイル集中度測定の最小サンプリング期間、コンパイル集中度測定の最大サンプリング期間、コンパイル集中度判定の変動率からなり、これらは、仮想マシン起動時点で予め決められた値を使用する。
【００９４】
図１９Ａ、Ｂにおいて、コンパイル集中度の計測部は、ステップＳ２０で、コンパイル集中度測定の測定終了の指示をコンパイルのタイミング調整決定部から受けているか否かを判断する。ステップＳ２０の判断がＹｅｓの場合には、ステップＳ２８に進む。ステップＳ２０の判断がＮｏの場合には、ステップＳ２１において、コンパイル集中度測定の総期間が、コンパイル集中測定の最大サンプリング期間を超えているか否かを判断する。ステップＳ２１の判断がＹｅｓの場合には、ステップＳ２８に進む。ステップＳ２１の判断がＮｏの場合には、ステップＳ２２において、コンパイル集中度測定の測定開始の指示をコンパイルのタイミング調整決定部から受けているか否かを判断する。
【００９５】
ステップＳ２２の判断がＮｏの場合には、ステップＳ２７に進む。ステップＳ２２の判断がＹｅｓの場合には、ステップＳ２３において、コンパイル集中情報のコンパイル処理の集中度を設定済みか否かを判断する。ステップＳ２３の判断がＹｅｓの場合には、ステップＳ２７に進む。ステップＳ２３の判断がＮｏの場合には、ステップＳ２４において、動的コンパイル部（後述）から、プログラム（メソッド）のコンパイル総数を受け取る。そして、（コンパイル処理の集中度）＝（（今回計測時のコンパイル総数）−（前回計測時のコンパイル総数））÷（コンパイル集中度測定のサンプリング間隔(秒））により、コンパイル処理の集中度を求めて、コンパイル集中度の記録に設定する。また、今回測定時のコンパイル総数を前回測定時のコンパイル総数に保存する。
【００９６】
ステップＳ２５では、前回記録したコンパイル処理の集中度と今回記録したコンパイル処理の集中度を比べて、変動の割合が、コンパイル集中判定の変動率より小さい、かつ、コンパイル集中度測定の総期間がコンパイル集中度測定の最小サンプリング期間以上か否かを判断する。ステップＳ２５の判断がＮｏの場合には、ステップＳ２７に進む。ステップＳ２５の判断がＹｅｓの場合には、ステップＳ２６に進む。
【００９７】
ステップＳ２６では、これまで測定・記録した期間をコンパイル処理の集中期間に設定し、これまでに記録したコンパイル処理の集中度の平均を求め、コンパイル処理集中度に設定する。そして、ステップＳ２７において、コンパイル集中度測定のサンプリング間隔（秒）の間、スリープし、ステップＳ２０に戻る。
【００９８】
ステップＳ２８では、コンパイル集中度情報のコンパイル集中度が設定済みか否かを判断する。ステップＳ２８の判断がＮｏのときは、ステップＳ２９に進む。ステップＳ２８の判断がＹｅｓのときは、処理を終了する。ステップＳ２９では、これまで測定・記録した期間をコンパイル処理の集中期間に設定し、これまでに記録したコンパイル処理の集中度の平均を求め、コンパイル処理の集中度に設定して、処理を終了する。
【００９９】
図２１は、プログラム(メソッド)実行頻度の計測部の動作フローチャートである。図２２は、プログラム(メソッド)実行頻度の計測部が使用するデータを示す図である。
図２２のデータは、仮想マシンが使用するメモリ上に置かれる。図２２のプログラム（メソッド）実行頻度の記録は、プログラム（メソッド）の識別情報として、メソッド名とそのシグネチャが格納される。そして、この識別情報に対応して、プログラム（メソッド）の実行頻度、コンパイル状態が格納される。実行頻度は、実行頻度の計測を始めてから現在の記録時点までのメソッドの実行回数を記録する。プログラム実行頻度の記録には、プログラム（メソッド）がコンパイルされたかどうかの状態を記録する項目があり、この項目の初期値はfalseで、動的コンパイラがプログラム（メソッド）をコンパイルしたときに、対象のプログラム（メソッド）のコンパイル状態をtrueにする。
【０１００】
図２１において、プログラム(メソッド)実行頻度の計測部の処理は、仮想マシンによって、プログラム(メソッド)の呼び出しが行われたときに実行される。ステップＳ３５において、測定対象のプログラム（メソッド）が、プログラム（メソッド）実行頻度の記録に登録されているか否かを判断する。ステップＳ３５の判断がＮｏの場合には、ステップＳ３６において、プログラム（メソッド）実行頻度の記録に、測定対象のプログラム（メソッド）を追加し、追加したプログラム（メソッド）の記録に、そのプログラム（メソッド）の識別情報を設定し、実行頻度を「１」に設定して、処理を終了する。ステップＳ３５の判断がＹｅｓの場合には、ステップＳ３７において、プログラム（メソッド）実行頻度の記録から、測定対象のプログラム（メソッド）の記録を検索し、実行頻度に値を加算する。加算する値は、１でもよいし、プログラム（メソッド）の内容に応じて、重み付けをした値を使っても良い。内容に応じて重み付けするとは、プログラム（メソッド）の大きさやループ処理のありなしなどから、当該プログラム（メソッド）の実行負荷の大きさに従い重み付けするものである。ステップＳ３７の処理が終わったら、処理を終了する。
【０１０１】
図２３Ａ、Ｂは、コンパイルタイミング調整決定部の動作フローチャートである。また、図２４は、コンパイルタイミング調整決定部が扱うデータを示す図である。
図２４のデータは、仮想マシンが使用するメモリ上に置かれる。（１）のプログラム（メソッド）実行頻度の重要度決定の基準値は、計測された実行頻度を４つの重要度の段階に分類するための実行頻度の区間が指定されている。プログラム（メソッド）実行頻度の重要度決定の基準値は、仮想マシン起動時点で予め決められた値を使用する。（２）〜（５）は、コンパイルタイミング調整の判断基準情報である。（２）は、アプリケーション起動完了時のプログラム（メソッド）実行頻度情報である。これは、プログラム（メソッド）の識別情報に対応して、プログラム（メソッド）の実行頻度とコンパイル情報が格納される。（３）は、アプリケーション性能安定時のプログラム（メソッド）実行頻度情報である。これは、プログラム（メソッド）の識別情報に対応して、プログラム（メソッド）の実行頻度と、コンパイル情報と、（１）のデータから得られた重要度が格納される。（２）と（３）のデータは、それぞれ、アプリケーション起動完了時と性能安定時に測定された図２２のデータから生成される。（４）は、コンパイル集中情報であり、コンパイル集中度の計測部が作成するものである。これは、コンパイル処理の集中期間と、コンパイル処理の集中度（個／秒）のデータからなる。（５）は、アプリケーションサーバから通知された実行性能情報であり、実行性能の安定前と安定後の性能差と、実行性能が安定するまでの期間からなる。
【０１０２】
図２３Ａ、Ｂにおいて、ステップＳ４０では、コンパイルタイミング調整決定部は、仮想マシン起動部から、アプリケーションプログラムの起動完了の通知が届いているか否かを判断する。ステップＳ４０の判断がＹｅｓの場合には、ステップＳ４２に進む。ステップＳ４０の判断がＮｏの場合には、ステップＳ４１に進む。
【０１０３】
ステップＳ４１では、仮想マシン起動部からアプリケーションプログラムの起動完了の通知が届くまで待ち合わせる。ステップＳ４２では、プログラム（メソッド）実行頻度計測部が集計しているプログラム（メソッド）実行頻度の記録を複写して、アプリケーションプログラム起動完了時のプログラム（メソッド）の実行頻度情報を作成する。ステップＳ４３では、コンパイル集中度の計測部を実行して、コンパイル集中度の計測を開始する。
【０１０４】
ステップＳ４４において、アプリケーションの実行性能計測・通知部からアプリケーションプログラムの実行性能の通知が届いているか否かを判断する。ステップＳ４４の判断がＹｅｓの場合には、ステップＳ４６に進む。ステップＳ４４の判断がＮｏの場合には、ステップＳ４５において、アプリケーションの実行性能計測・通知部からプリケーション実行性能の通知が届くまで待ち合わせる。
【０１０５】
ステップＳ４６では、アプリケーションサーバから通知された実行性能情報を仮想マシンのメモリに格納する。ここで、実行性能情報は、実行性能の安定前と安定後の性能差、及び、実行性能が安定するまでの期間からなる。
【０１０６】
ステップＳ４７では、プログラム(メソッド）実行頻度計測部が集計しているプログラム（メソッド）実行頻度の記録を複写して、アプリケーション性能安定時のプログラム（メソッド）実行頻度情報を作成する。また、アプリケーション性能安定時のプログラム（メソッド）実行頻度情報には、実行頻度に応じた重要度を格納する項目を設ける。そして、アプリケーション性能安定時のプログラム（メソッド）実行頻度情報に設定されている各プログラム（メソッド）の実行頻度と重要度基準値（閾値）とを比較して、重要度を設定する。
【０１０７】
ステップＳ４８では、コンパイル集中度の計測部を実行して計測処理を実行し、計測処理が終わったらコンパイル集中度の計測を終了する。ここで、コンパイル集中度の計測部が作成したコンパイル集中度の記録は、コンパイルのタイミング調整決定部から参照でき、これをコンパイル集中情報とする。ステップＳ４９において、コンパイルタイミング制御情報の計算と出力部を実行して、コンパイルタイミング制御情報を出力する。
【０１０８】
図２５Ａ、Ｂ、Ｃは、コンパイルタイミング制御情報の計算と出力手部の動作フローチャートである。また、図２６は、コンパイルタイミング制御情報の計算と出力部が扱うデータを示す図である。
【０１０９】
図２６のデータは、仮想マシンが使用するメモリ上に置かれる。また、コンパイルタイミング制御情報の計算と出力部は、図２４に示したコンパイルタイミング調整の判断基準情報も使用する。コンパイルタイミング調整係数、コンパイルタイミングの標準実行頻度、コンパイル集中度決定の基準値、コンパイルタイミング調整係数の決定基準テーブルの内容は、仮想マシン起動時点で予め決められた値を使用する。（１）のデータは、コンパイルタイミング調整係数と、コンパイルタイミングの標準実行頻度とからなる。コンパイルタイミングの標準実行頻度は、プログラム（メソッド）がコンパイル処理されるまでに、インタプリタで実行される回数の基準値であり、予め決められた値である。コンパイルタイミング調整係数は、コンパイルタイミングの標準実行頻度に乗算して、コンパイル処理が行なわれるまでにプログラム（メソッド）が実行される回数を可変するための値であり、コンパイルタイミング調整係数の決定基準テーブルに基づいて決定される。
【０１１０】
（２）のコンパイル集中度決定の基準値は、単位時間当たりのコンパイル処理されたプログラム（メソッド）数を、３つの段階に分類するための基準値（閾値）を示すもので、これに従い、コンパイルの集中度が、大、中、小のいずれかに設定される。（３）の性能差大小決定の基準値は、実行性能の安定前と安定後の性能差を２つの段階（大・小）に分類するための基準値（閾値）を示す。（４）のコンパイルタイミング調整係数の決定基準テーブルは予め設定されたもので、アプリケーションプログラムのインタプリタによる実行結果から各プログラム（メソッド）を重要度と集中度で分類した結果を用いて、コンパイルタイミング調整係数を設定するためのものである。コンパイルタイミング調整係数の値が１．０の場合には、コンパイルタイミングは変更されず、１．０より大きければ、コンパイルタイミングは遅くなり、１．０より小さければ、コンパイルタイミングは早くなる。
【０１１１】
（５）のコンパイルタイミング制御情報は、プログラム（メソッド）ごとにコンパイルタイミング調整値を格納するもので、プログラム(メソッド）の識別情報（メソッド名とシグネチャ）と、コンパイルタイミング調整値が対応付けられて、コンパイルタイミング制御情報の計算と出力部によって生成され、出力される。コンパイルタイミング調整値は、コンパイルタイミングの標準実行頻度に、（４）のデータから得られたコンパイルタイミング調整係数を乗算して得られる。
【０１１２】
図２５Ａ、Ｂ、Ｃにおいて、コンパイルタイミング制御情報の計算と出力部は、ステップＳ５５において、アプリケーションプログラムの起動完了時のプログラム（メソッド）実行頻度情報を読み込み、１つ目に登録されているプログラム（メソッド）の実行頻度情報を取り出す。ステップＳ５６において、プログラム（メソッド）の実行頻度情報があるか否かを判断する。
【０１１３】
ステップＳ５６の判断がＮｏの場合には、ステップＳ６３に進む。ステップＳ５６の判断がＹｅｓの場合には、ステップＳ５７において、実行頻度情報から、プログラム（メソッド）識別情報、コンパイル状態、プログラム（メソッド）の実行頻度を取り出す。ステップＳ５８において、取り出した実行頻度情報のコンパイル状態はtrueか否かを判断する。ステップＳ５８の判断がＹｅｓの場合には、ステップＳ５９に、Ｎｏの場合には、ステップＳ６０に進む。
【０１１４】
ステップＳ５９においては、コンパイルタイミング調整値に、プログラム（メソッド）の実行頻度を設定し、ステップＳ６１に進む。ステップＳ６０においては、コンパイルタイミング調整値に、（プログラム（メソッド）の実行頻度）×（コンパイルタイミング調整係数）を設定する。ステップＳ６１では、コンパイルタイミング制御情報に、プログラム（メソッド）識別情報とコンパイルタイミング調整値を出力する。ステップＳ６２においては、次に登録されているプログラム(メソッド）の実行頻度情報を取り出し、ステップＳ５６に戻る。ここで、コンパイル状態がtrueでない（falseの）ものだけコンパイルタイミング調整値を可変するのは、trueとなっているものは、既にコンパイルされており、改めてコンパイルするタイミングを設定する必要が無いからである。
【０１１５】
ステップＳ６３では、アプリケーションプログラムの安定時のプログラム（メソッド）の実行頻度情報を読み込み、１つ目に登録されているプログラム（メソッド）の実行頻度情報を取り出す。ステップＳ６４において、プログラム（メソッド）の実行頻度情報があるか否かを判断する。ステップＳ６４の判断がＮｏの場合には、処理を終了する。ステップＳ６４の判断がＹｅｓの場合には、ステップＳ６５に進む。
【０１１６】
ステップＳ６５では、実行頻度情報から、プログラム（メソッド）識別情報、プログラム（メソッド）の実行頻度、重要度を取り出す。ステップＳ６６において、取り出したプログラム（メソッド）識別情報は、アプリケーションプログラム起動完了時のプログラム（メソッド）の実行頻度情報に含まれているか否かを判断する。ステップＳ６６の判断がＹｅｓの場合には、ステップＳ７４に進む。ステップＳ６６の判断がＮｏの場合には、ステップＳ６７に進む。
【０１１７】
ステップＳ６７では、アプリケーションサーバから通知された実行性能情報から、実行性能の安定前と安定後の性能差、実行性能が安定するまでの期間を取り出す。ステップＳ６８において、コンパイル集中情報から、コンパイル処理の集中期間、コンパイル処理の集中度を取り出す。ステップＳ６９において、コンパイル処理の集中度とコンパイル集中度判定の基準値を比較して、コンパイル処理の集中度（大／中／小）を求める。
【０１１８】
ステップＳ７０において、（コンパイル集中期間影響率）＝（実行性能が安定するまでの期間）÷（コンパイル処理の集中期間）を求める。ステップＳ７１において、コンパイルタイミング調整係数の決定基準テーブルから、コンパイル処理の集中度、プログラム（メソッド）の重要度、コンパイル集中度、コンパイル集中期間影響率、実行性能の安定前と安定後の性能差の条件に当てはまるコンパイルタイミング調整係数を求める（図２６（３）参照）。ステップＳ７２において、コンパイルタイミング調整値に、（コンパイルタイミングの標準実行頻度）×（コンパイルタイミング調整係数）を設定する。ステップＳ７３において、コンパイルタイミング制御情報に、プログラム（メソッド）識別情報とコンパイルタイミング調整値を出力する。ステップＳ７４において、次に登録されているプログラム（メソッド）の実行頻度情報を取り出し、ステップＳ６５に戻る。
【０１１９】
図２７は、コンパイルタイミング制御情報の入力・判断部の動作フローチャートである。また、図２８は、コンパイルタイミング制御情報の入力・判断部が使用するデータを示す図である。
【０１２０】
図２８において、（２）のコンパイルタイミング制御情報は、仮想マシンが使用するメモリから読み込んで使用する。（１）のコンパイルタイミングの標準実行頻度は、仮想マシン起動時点で予め決められた値を使用する。
【０１２１】
図２７において、コンパイルタイミング制御情報の入力・判断部は、メソッドの呼び出しがある前に起動される。ステップＳ８０で、コンパイルタイミング制御情報が読み込まれているか否かを判断する。ステップＳ８０の判断がＮｏの場合には、ステップＳ８４に進む。ステップＳ８０の判断がＹｅｓの場合には、ステップＳ８１において、プログラム（メソッド）の呼び出しがあった場合のそのプログラム（メソッド）が、コンパイルタイミング情報のプログラム（メソッド）識別情報に存在するか否かを判断する。ステップＳ８１の判断がＮｏの場合には、ステップＳ８４に進む。ステップＳ８１の判断がＹｅｓの場合には、ステップＳ８２に進む。
【０１２２】
ステップＳ８２においては、コンパイルタイミング制御情報から、プログラム（メソッド）の呼び出しがあったプログラム（メソッド）のコンパイルタイミング調整値を取り出す。ステップＳ８３において、プログラム（メソッド）の呼び出しがあった場合のそのプログラム（メソッド）の実行頻度が、コンパイルタイミング情報から取り出したコンパイルタイミング調整値以上か否かを判断する。ステップＳ８３の判断がＮｏの場合には、処理を終了する。ステップＳ８３の判断がＹｅｓの場合には、ステップＳ８５に進む。
【０１２３】
ステップＳ８４では、プログラム（メソッド）の呼び出しがあった場合のそのプログラム（メソッド）の実行頻度が、コンパイルタイミングの標準実行頻度以上か否かを判断する。ステップＳ８４の判断がＮｏの場合には、処理を終了する。ステップＳ８４の判断がＹｅｓの場合には、ステップＳ８５に進む。ステップＳ８５では、呼び出しがあったプログラム(メソッド）のコンパイルをコンパイラに依頼し、処理を終了する。
【０１２４】
図２９は、動的コンパイル部の動作フローチャートと使用するデータを示す図である。
コンパイルタイミング情報に基づいてどのようにコンパイルするかは、コンパイル制御情報の入力・判断部で制御しており、動的コンパイル部（動的コンパイラを含む）は、コンパイルの依頼があった時にコンパイル処理を実行する。
【０１２５】
図１９Ａ、Ｂおよび図２０のコンパイル集中度の計測部が、コンパイル総数を記録するために、動的コンパイル部は、動的コンパイラにコンパイル処理をさせると共に、コンパイル総数（図２９（ｂ））をカウントする処理を行う。
【０１２６】
図２９（ａ）において、動的コンパイル部は、ステップＳ９０で、プログラム（メソッド）のコンパイル依頼があるか否かを判断する。ステップＳ９０の判断がＮｏの場合には、ステップＳ９３に進む。ステップＳ９０の判断がＹｅｓの場合には、ステップＳ９１において、依頼のあったプログラム（メソッド）を動的コンパイラにコンパイルさせ、ステップＳ９２において、コンパイル総数（図２９（ｂ））を１増加する。そして、ステップＳ９３において、動的コンパイラを終了するか否かを判断する。これは、利用者からの指示で、動的コンパイラを終了するか否か決定するようにして良い。ステップＳ９３の判断がＮｏの場合には、ステップＳ９０に戻り、Ｙｅｓの場合には、処理を終了する。
【０１２７】
図３０及び図３１は、本実施形態の効果を説明する図である。
コンパイルを行うタイミングを調整して、インタプリタによる実行とネイティブコードによる実行のバランスを最適にすることで、アプリケーションプログラムの起動直後の実行性能が安定する。安定時のアプリケーション実行性能と比較して、アプリケーション起動直後の実行性能が低下する割合を図３０のように軽減することができる。図３０によれば、アプリケーションプログラムの起動開始後、起動完了と業務の開始前に行なわれる動的コンパイルの増加数が多くなり、アプリケーションプログラムの起動完了と業務の開始後の動的コンパイル数が減って、処理時間が短くなっている。また、アプリケーションの実行性能が安定した状態になるまでの期間を図３１のように早めることができる。すなわち、重要度の高いアプリケーションがインタプリタ実行からネイティブコードの実行へ早く切り替わり、アプリケーションプログラムの動作の安定化が早くなる。
【符号の説明】
【０１２８】
１０−１、１０−２ サーバマシン
１１ クライアントマシン
１２ 仮想マシン
１３ 動的コンパイラ
１４ アプリケーションサーバプログラム
１５、１５ａ アプリケーションプログラム
１６ Ｗｅｂサーバプログラム
１７ ＯＳ
１８ 媒体ドライバ
１９ 可搬記録媒体
２０ アプリケーションサーバ
２１ 仮想マシン起動部
２２ リクエストの送付部
２３ アプリケーションの実行性能計測・通知部
３０ コンパイル集中度の計測部
３１ プログラム(メソッド）実行頻度の計測部
３２ コンパイルのタイミング調整決定部
３３ コンパイルタイミング制御情報の計算と出力部
３４ コンパイルタイミング制御情報の入力・判断部
【技術分野】
【０００１】
以下の実施形態は、アプリケーション実行性能の状況に応じて、動的コンパイルのタイミングを最適化するアプリケーションサーバに関する。
【背景技術】
【０００２】
Java（登録商標）やMicrosoft .NETのように、アプリケーションプログラムの実行環境として、あるアプリケーションを開始してから、インターネットを通してプログラムを受け取って実行したり、動的に生成されたプログラムを実行する形態のアプリケーションプログラムに対して、仮想マシンによる実行環境が多く利用されている。
【０００３】
アプリケーションプログラムを仮想マシン環境で実行するのは、プログラムをアプリケーションプログラムの起動後（つまり実行時）に読み込んで実行することや、プログラムを様々なプラットフォーム（ハードウェアやＯＳ（Operating System)）で実行するのに適している（仮想マシンがプラットフォーム依存の処理を吸収する）からである。これに対して、C言語やCOBOLなどで作られたアプリーションは、アプリケーションを実行する前に、静的コンパイラによって、アプリケーションプログラムを、動作させるプラットフォームに依存した実行形式のプログラムに変換(コンパイル) しておく方式が一般的である。
【０００４】
仮想マシンでアプリケーションプログラムを実行する場合の実行環境の特徴として、アプリケーションプログラムをインタプリタで(プログラムの命令を１つずつ解釈実行して)動作する手段と、ネイティブコード（機械命令）にコンパイルしてから実行する手段があり、どちらか一方の手段だけを持つ実行環境の場合や、両方の手段を持つ実行環境の場合がある。
【０００５】
インタプリタによる実行は、一般的にネイティブコードによる実行より数倍から数百倍程度遅く、ネイティブコードに変換してから実行するのが一般的である。しかし、ネイティブコードへの変換（コンパイル）は、アプリケーションプログラムの実行時に行われるため、アプリケーションの実行時間には、コンパイル処理の時間が含まれる。
【０００６】
特に、アプリケーションプログラムの起動直後には、多くのコンパイル処理が動作するため、アプリケーションプログラムの起動直後の実行性能が安定しないという問題がある。アプリケーションプログラムのコンパイルは、アプリケーションプログラムの起動後(実行時)に行われることから、動的コンパイラ、あるいはJust In Time (ジャストインタイム)コンパイラ と呼ばれている。
【０００７】
仮想マシンでアプリケーションプログラムを実行するときに、動的コンパイルを行うことによる影響を低減させる技術には以下がある。
１つ目は、動的コンパイラの最適化処理の程度を弱めて、コンパイル処理を軽くする方式である。コンパイラの最適化処理とは、出力するするネイティブコードをより高速なコードに変換するため処理で、最適化処理を強力にすればネイティブコードは高速になるが、コンパイル処理の負担は重くなる。このため、アプリケーションプログラムの起動時の性能を求められる場合、例えば、クライアント向けの仮想マシンでは、最適化処理の軽いコンパイラを使用することで、起動時の性能を優先するように調整している。一方、多くのアプリケーションプログラムを実行する必要のあるアプリケーションサーバ向けの仮想マシンでは、最適化処理を強化したコンパイラを使用することで、最大性能を優先するように調整している。
【０００８】
１つ目の従来技術などで使用されるJava仮想マシンについては、http://java.sun.com/j2se/1.5.0/ja/docs/ja/guide/vm/index.htmlのサイトの記述を参照されたい。
【０００９】
２つ目は、起動時のコンパイル処理による負担を抑えつつ、最大性能も得られるように調整する方式である。この方式によるコンパイラは適用型コンパイラとよばれ、アプリケーションプログラムの起動時はインタプリタで実行を始めて、実行しながらプログラムを解析してパフォーマンスのボトルネック（頻繁に動作するメソッド）を見つける方式を使用している。性能に影響のあるメソッドはコンパイルするが、実行頻度の低いメソッドはコンパイルすることがないため、アプケーションプログラムの起動時にコンパイル処理による負担を軽減して、最大性能も得られることを狙っている。
【００１０】
２つ目の従来技術等で使用されるJava仮想マシンについては、上記ウェブサイトを参照されたい。
Oracle JRockit JDK、 JIT コンパイルと最適化の概要については、http://otndnld.oracle.co.jp/document/products/jrockit/geninfo/diagnos/underst_jit.htmlのサイトの記述を参照されたい。
【００１１】
また、３つ目として、アプリケーションプログラムを起動後、アプリケーションプログラムへの入力を受け付ける（業務を開始する）前に、予め（例えば前回のアプリケーションプログラムの実行時に得た）情報を元に、使用頻度の高いプログラムを事前に読み込み、コンパイルを済ませておく方式がある。
【００１２】
従来技術には、実行頻度の高い手続きをネイティブコードへ変換する処理を短時間で開始することができ、かつ、この変換処理にともなう負荷によってアプリケーションの実行に支障が生じることを防止することができるシステムがある。
【先行技術文献】
【特許文献】
【００１３】
【特許文献１】特開２００７−２１３４９０号公報
【発明の概要】
【発明が解決しようとする課題】
【００１４】
前述したように、仮想マシンでアプリケーションプログラムを実行する環境では、アプリケーションプログラムの起動後に、動的コンパイラ、あるいは、ジャストインタイムコンパイラとよばれるコンパイラによって、一般的にネイティブコードに変換してから実行するのが一般的である。
【００１５】
ネイティブコードへの変換（コンパイル）は、アプリケーションプログラムの実行時に行われるため、アプリケーションプログラムの実行時間には、コンパイル処理の時間が含まれるという避けられない問題がある。
特に、アプリケーションの起動直後には、多くのコンパイル処理が動作するため、起動直後のアプリケーションの実行性能が安定しないという問題がある。
【００１６】
図１は、起動直後のアプリケーションの実行性能が安定しない例を示す図である。
グラフの横軸は、仮想マシンが起動してからの経過時間、右側縦軸は、アプリケーションプログラムが処理要求(リクエスト)を処理するのに要した時間（レスポンス時間）、左縦軸は、コンパイラがネイティブコードに変換したプログラム（メソッド）の総数を示す。処理要求の開始直後は、ネイティブコードがそろっていない(一部のプログラムはインタプリタで実行される)ことと、コンパイル処理が多く動作することで、処理時間が安定していない。
【００１７】
この問題に対して、１つ目の従来技術では、コンパイラの最適化の程度を妥協して、コンパイル処理を軽くする方式を使用した。この方式では、クライアントマシンのような特定の実行環境では有効である。しかし、最大性能を求められるアプリケーションサーバ向けの仮想マシンを使用した環境では、コンパイラの最適化が弱いため、アプリケーションプログラムの最大性能を犠牲にすることになる。例えば、毎朝の９時に業務を開始するアプリケーションサーバで動作するアプリケーションプログラムがあり、開始直後から大量の処理をこなさなければならないような場合には不向きである（例えば、インタネートによるチケット販売）。
【００１８】
２つ目の従来技術では、ボトルネックとなる実行頻度の高いメソッドだけをコンパイルする方式を使用した。この方式は、すべてのプログラムをコンパイルする方式と比べると、アプリケーション起動時の性能に効果があった。しかし、起動後、インタプリタによる実行とプログラムの実行頻度の解析をどのくらいの期間するのが適切か、また、いつコンパイル処理を実施してネイティブコードによる実行に変えたら効果が得られるかは、いろいろな要因（ハードウェアの性能、アプリケーションプログラムの特性、アプリケーションプログラムが扱う処理量など）に依存する。プログラムのボトルネック（実行頻度の高いメソッド）を見つける方式としては、プログラム（メソッド）の呼び出し回数やループ回転数によって判断する方式が知られている。しかし、インタプリタ実行とネイティブコードによる実行の最適なバランスを見つけるのは非常に難しく、従来は、プログラム（メソッド）の実行が特定の回数に到達したらコンパイルを行う方式を採用しており、バランス調整は行っていない。したがって、２つ目の従来技術による仮想マシンを使用しても、アプリケーションプログラムの起動時の性能が運用要件を満たさない例があるのが現状である。
【００１９】
３つ目の従来技術では、アプリケーションを起動後、アプリケーションプログラムへの入力を受け付ける（業務を開始する）前に、予め、使用頻度の高いプログラム（メソッド）を事前に読み込み、コンパイルを済ませておく方式を使用した。しかし、この方式は、アプリケーションプログラムの実行中にインターネットを通してプログラムを読み込んだり、実行時以後にプログラムが生成されるようなアプリケーションに対しては不向きであった。
【００２０】
Java言語のように、動的にプログラムを読み込む（必要になったときに読み込む）という仕様の場合、あるメソッドから別のメソッドを参照しているときに、参照されるメソッドがまだ読み込まれていような場合は、コンパイラが生成するコードには余分なコードが増える。
【００２１】
これは、「プログラムが読み込まれていなかったら、プログラムを読み込んで参照を解決する」というコードをコンパイラが生成するコードの中に組み込まなければいけないためである。３つ目の従来技術では、このようなコードが増えるため、アプリケーションの実行中にインターネットを通してプログラムを読み込んだり、実行時以後にプログラムが生成されるようなアプリケーションに対しては不向きである。
【００２２】
また、コンパイラの最適化処理の面で不利になる。すなわち、コンパイラはプログラムの実行を予測することで、より強力な最適化を行うことができる(例えば、if文の分岐確率、仮想関数呼び出しで頻繁に呼ばれる関数) 。動的にプログラムを読み込んで実行する場合、コンパイル前のインタプリタ実行中にプログラムの動的な情報を収集して（プロファイルして）、コンパイラの最適化に利用するのが一般的である。しかし、３つ目の従来技術のようにプログラムの実行前にコンパイルすると、このような最適化ができなくなるため不利である。
【００２３】
以下の実施形態においては、アプリケーション実行性能の状況に応じて、動的コンパイルのタイミングを調整するアプリケーションサーバを提供する。
【課題を解決するための手段】
【００２４】
以下の実施形態の一側面におけるアプリケーションサーバは、プログラムの実行に際して動的コンパイルを行うアプリケーションサーバであって、該プログラムをインタプリタによって実行する際、該プログラムの実行性能に関する情報を取得する実行性能情報取得部と、該実行性能に関する情報に基づいて、該プログラムに含まれる各メソッドについて、それぞれコンパイルタイミングを指定する情報を設定するコンパイルタイミング情報設定部と、該コンパイルタイミングを指定する情報に基づいて、該メソッドをネイティブコードにコンパイルする動的コンパイル部とを備える。
【発明の効果】
【００２５】
以下の実施形態によれば、アプリケーション実行性能の状況に応じて、動的コンパイルのタイミングを調整するアプリケーションサーバを提供することができる。
【図面の簡単な説明】
【００２６】
【図１】起動直後のアプリケーションプログラムの実行性能が安定しない例を示す図である。
【図２】アプリケーションサーバ上で仮想マシンが動作する環境で、起動直後にアプリケーションプログラムの実行性能が安定しない例を示す図である。
【図３】図２の例に示したアプリケーションプログラムの実行に対して、プログラム（メソッド）の特徴ごとに、コンパイル処理の状況（コンパイル処理量とコンパイルの発生タイミング）を示したイメージを示す図である。
【図４】本実施形態の動的コンパイルを適用した場合に、図３に示したコンパイル処理の状況がどのように変化するかを示す図である。
【図５】アプリケーションプログラムの実行性能とコンパイル処理量の傾向とその分類を説明する図（その１）である。
【図６】アプリケーションプログラムの実行性能とコンパイル処理量の傾向とその分類を説明する図（その２）である。
【図７】アプリケーションプログラムの実行性能とコンパイル処理量の傾向とその分類を説明する図（その３）である。
【図８】アプリケーションプログラムの実行性能とコンパイル処理量の傾向とその分類を説明する図（その４）である。
【図９】コンパイルタイミング調整の判断基準情報を取得する２回のタイミングを示す図である。
【図１０】コンパイルタイミング調整の判断基準情報からコンパイルのタイミングを調整する方法を説明する図（その１）である。
【図１１】コンパイルタイミング調整の判断基準情報からコンパイルのタイミングを調整する方法を説明する図（その２）である。
【図１２】本実施形態が適用されるシステムの構成例を示す図である。
【図１３】アプリケーションサーバ上で動作する各機能のブロック構成を示す図である。
【図１４】仮想マシン上、および、仮想マシンの動的コンパイラでの動作を説明する図（その１）である。
【図１５】仮想マシン上、および、仮想マシンの動的コンパイラでの動作を説明する図（その２）である。
【図１６】仮想マシン起動部の動作フローチャートである。
【図１７】アプリケーションプログラムの実行性能計測・通知部の動作フローチャートである。
【図１８】アプリケーションの実行性能計測・通知部が使用するデータを示す図である。
【図１９Ａ】コンパイル集中度の計測部の動作フローチャート（その１）である。
【図１９Ｂ】コンパイル集中度の計測部の動作フローチャート（その２）である。
【図２０】コンパイル集中度の計測部が使用するデータを示す図である。
【図２１】プログラム(メソッド)実行頻度の計測部の動作フローチャートである。
【図２２】プログラム(メソッド)実行頻度の計測部が使用するデータを示す図である。
【図２３Ａ】コンパイルタイミング調整決定部の動作フローチャート（その１）である。
【図２３Ｂ】コンパイルタイミング調整決定部の動作フローチャート（その２）である。
【図２４】コンパイルタイミング調整決定部が扱うデータを示す図である。
【図２５Ａ】コンパイルタイミング制御情報の計算と出力部の動作フローチャート（その１）である。
【図２５Ｂ】コンパイルタイミング制御情報の計算と出力部の動作フローチャート（その２）である。
【図２５Ｃ】コンパイルタイミング制御情報の計算と出力部の動作フローチャート（その３）である。
【図２６】コンパイルタイミング制御情報の計算と出力部が扱うデータを示す図である。
【図２７】コンパイルタイミング制御情報の入力・判断部の動作フローチャートである。
【図２８】コンパイルタイミング制御情報の入力・判断部が使用するデータを示す図である。
【図２９】動的コンパイル部の動作フローチャートと使用するデータを示す図である。
【図３０】本実施形態の効果を説明する図（その１）である。
【図３１】本実施形態の効果を説明する図（その２）である。
【発明を実施するための形態】
【００２７】
本実施形態では、アプリケーションプログラムの起動時に、多数のコンパイル処理が動作することで、アプリケーションプログラムの実行に使えるCPU時間が奪われる（オーバヘッド）ことを回避するように、コンパイルを行うタイミングを調整することで、インタプリタによる実行とネイティブコードによる実行のバランスを最適にする（各々のプログラムのコンパイルを行うタイミングを遅らせた方がアプリケーションプログラムの実行性能がよくなるのか、早めた方がよいのかを判断する）ことで、アプリケーションプログラムの起動直後の実行性能を安定させる。
【００２８】
これは、（１）アプリケーションプログラムの起動直後の性能が安定しない期間は、コンパイルの処理量を減らす、（２）しかし、実行性能に大きく影響するプログラム(メソッド）は、起動直後の性能が安定しない期間であっても、コンパイルのタイミングを早めてインタプリタからネイティブコードの実行に早く切り替え、逆に実行性能への影響が少ないプログラム（メソッド）は起動直後のコンパイルが集中して性能が安定しない期間で行わないことで実現する。
【００２９】
つまり、アプリケーションプログラムの起動直後のコンパイルの集中を分散化させ、実行性能に影響するプログラム（メソッド）は適切なタイミングでコンパイルさせる。なお、コンパイルを行うプログラムの単位は、メソッドごとに行うこともあり、以下の説明で、プログラムをコンパイルするといったときは、メソッドのコンパイルの意味を含む。
【００３０】
そして、仮想マシンは、アプリケーションサーバで動作することを想定する。アプケーションサーバは、仮想マシンを起動して、仮想マシン上でアプリケーションプログラムの起動を開始する。アプリケーションプログラムによる業務を実行する準備が整った状態でアプリケーションプログラムの起動が完了する。つまり、アプリケーションプログラムの起動が完了するまでは、アプリケーションプログラムは業務を開始しない（アプリケーションサーバ上でアプリケーションプログラムの実行が可能な状態になることをアプリケーションサーバの起動が完了したという場合がある）。
【００３１】
アプリケーションプログラムの起動が完了する以前に実行を開始したプログラム（メソッド）は、アプリケーションプログラムの起動が完了する前にプログラム(メソッド）のコンパイルを完了することで、業務の開始後に、これらのプログラム(メソッド）がコンパイルされることはなくなる。これにより、業務開始後にコンパイルされるメソッドの数が減るので、（１）が実現できる。
【００３２】
従来技術では、アプリケーションの起動が完了する以前に実行を開始したプログラム(メソッド）が、業務を開始してからコンパイルされることがあった。また、アプリケーションプログラムの起動後に実行されるプログラム（メソッド）は、アプリケーションプログラムの実行性能への影響度と、そのときのコンパイル処理の負荷の状況に応じて、コンパイルのタイミングを早めたり遅らせたり調整することで（２）を実現できる。
【００３３】
図２は、アプリケーションサーバ上で仮想マシンが動作する環境で、起動直後にアプリケーションプログラムの実行性能が安定しない例を示す図である。
アプリケーションプログラムが起動を開始すると、起動に必要なプログラム（メソッド）の実行が始まり、これらのプログラム（メソッド）に対して多数のコンパイル処理が行われるが、起動が完了するころにはコンパイルの処理量は一時的に少なくなる。業務が開始されると、業務を実行するためのプログラム（メソッド）が動作して、これらのプログラム（メソッド）に対して多数のコンパイル処理が行われる。
【００３４】
このときに、アプリケーションプログラムの起動が完了するより前に、すでに実行を開始していたプログラム（メソッド）もこのタイミングでコンパイルされることがある。業務処理がある程度行われると、多くのプログラム（メソッド）がネイティブコードの実行に切り替わり、コンパイル処理数も少なくなることで、業務の処理時間（レスポンス時間）は安定してくる。
【００３５】
なお、図２においては、アプリケーションプログラムの起動完了と業務開始が同一時刻となっているが、実際には、アプリケーションプログラムの動作速度によって、短い時間単位で異なることが生じうる。しかし、図２においては、図示の便宜上、これらを同一時刻としている。
【００３６】
図３は、図２の例に示したアプリケーションの実行に対して、プログラム（メソッド）の特徴ごとに、コンパイル処理の状況（コンパイル処理量とコンパイルの発生タイミング）を示したイメージを示す図である。
【００３７】
黒丸が１つのプログラム（メソッド）のコンパイルを示しており、プログラム（メソッド）のコンパイルの特徴によって、（ａ）、（ｂ）、（ｃ）の３つの特徴に分けて、コンパイル処理の発生状況を示している。
【００３８】
（ａ）は「アプリケーションプログラムの起動完了時点で１度でも実行されているプログラム（メソッド）のコンパイル」を示す。（ｂ）は「アプリケーションプログラムが業務を開始後に実行されるプログラム（メソッド）で、かつ、実行性能への影響が大きいプログラムのコンパイル」を示す。（ｃ）は「アプリケーションプログラムの業務開始後に実行されるプログラム（メソッド）で、かつ、実行性能への影響が小さいプログラムのコンパイル」を示す。
【００３９】
アプリケーションプログラムが業務を開始した直後では、コンパイル処理が集中しており、この時点では、インタプリタによる実行からネイティブコードでの実行への切り替えが徐々に行われている。
【００４０】
図４は、本実施形態のコンパイルを適用した場合に、図３に示したコンパイル処理の状況がどのように変化するかを示す図である。
（ａ）のアプリケーションプログラムの起動完了時点で１度でも実行されているプログラム(メソッド）は、アプリケーションプログラムの起動が完了する前にコンパイルをすることで、業務を開始するより前にコンパイルが完了している。これにより、起動直後の性能が安定しない期間のコンパイル処理の集中が緩和されている。（ｂ）のアプリケーションプログラムが業務を開始後に実行されるプログラムで、かつ、実行性能への影響が大きいプログラム（メソッド）は、従来より早いタイミングでコンパイルすることで、インタプリタによる実行からネイティブコードによる高速な実行への切り替えが速く進む。（ｃ）のアプリケーションプログラムが業務を開始後に実行されるプログラム（メソッド）で、かつ、実行性能への影響が小さいプログラム（メソッド）は、従来より遅いタイミングでコンパイルをすることで、起動直後の性能が安定しない期間のコンパイル処理の集中が緩和されている。
【００４１】
ここで、黒丸は１つのプログラム(メソッド）のコンパイルを示す。また、図３と同様に、（ａ）は、 アプリケーション起動完了時点で１度でも実行されているプログラム(メソッド）のコンパイル、（ｂ）は、アプリケーションが業務を開始後に実行されるプログラム(メソッド）で、かつ実行性能への影響が大きいプログラム(メソッド）のコンパイル、（ｃ）は、アプリケーションが業務を開始後に実行されるプログラム(メソッド）で、かつ実行性能への影響が小さいプログラム(メソッド）のコンパイルを示す。
【００４２】
アプリケーション起動完了後に初めて実行されるプログラム(メソッド）（ｂ）、（ｃ）は、実行性能への影響の度合いに応じて、コンパイルのタイミングを早めたり遅らせたりする調整をするが、調整の決定には個々のプログラム(メソッド）の特徴だけでなく、アプリケーションプログラムの実行性能とコンパイル処理量の全体的な傾向、実際の状況に合わせて総合的に判断する必要がある。
【００４３】
例えば、あるプログラム(メソッド）は、実行性能への影響がある程度大きいので早めにコンパイルしたいが、コンパイル処理量が全体的に多いアプリケーションプログラムでは、調整をすることにより、さらにコンパイル処理の負担が増え、逆に実行性能を低下させる可能性もある。
どのようなケースで、どのような総合的な判断をしたらいいのかを示すために、アプリケーションプログラムの実行性能とコンパイル処理量の傾向の主要なケースを説明する。
【００４４】
図５〜図８は、アプリケーションプログラムの実行性能とコンパイル処理量の傾向とその分類を説明する図である。
図５〜図７では、横軸に時間、右縦軸に処理時間、左縦軸にコンパイル数をとっている。
【００４５】
図５のケース１は、（１）アプリケーションプログラムの業務処理（運用）開始直後に急激的にコンパイル処理量が増え、（２）業務処理開始直後の実行性能（処理時間）と安定時の実行性能（処理時間）の性能差（処理時間（レスポンス時間）の差）が大きいが、（３）実行性能（処理時間）が不安定な期間が短い場合である。
【００４６】
このケースは、業務処理開始直後（運用開始直後）の短期間にコンパイル処理が集中するため、この期間は、実行性能の低下が大きくなるが、全体的にインタプリタによる実行からネイティブコードによる実行へ早く切り替わるために、実行性能が安定するまでの期間が短い。
【００４７】
図６のケース２は、（１）アプリケーションの運用開始後からコンパイル処理が徐々に進み、（２）運用直後の実行性能と安定時の実行性能の性能差は図５のケース１に比べると小さいが、（３）実行性能が不安定な期間が長い場合である。
【００４８】
このケースは、運用開始直後のコンパイル処理が急激に増えないため、コンパイル処理による実行性能への影響は小さいが、全体的にインタプリタによる実行からネイティブコードの実行への切り替えが徐々に行われるため、実行性能が安定するまでの期間が長くかかる場合である。
【００４９】
図７のケース３は、運用直後の実行性能と安定時の実行性能の性能差が大きく、かつ、安定した実行性能になるまでの期間が長い。このようなパターンは例外的であるが、原因として、インプリタによる実行とネイティブコードによる実行の性能差が大きい（図６のケース２に該当するが安定時とそうでないときの性能差が大きい）、または、多数のコンパイル処理が行われる期間が長い（図５のケース１に該当するがよりコンパイル処理が連続的に多く行われる）、あるいは、その両方が複合的に影響していることが考えられる。
【００５０】
この３つのケースを現象からとらえると、図８のように、実行性能が安定する前と安定した後の性能差の大小、および、安定した性能になるまでの不安定期間の長短の表で分類できる。また、このような現象が生じる要因には、実行性能に影響度が高いプログラム(メソッド）がネイティブコードによる実行に切り替わっているかどうか、コンパイル処理の集中度、コンパイル処理の集中期間の３つがある。それぞれのケースに応じて、これらの要因を調整することで、適切なコンパイルのタイミング調整をすることができる。
【００５１】
コンパイルのタイミング調整をおこなうための判断基準となる情報は、（１）実行性能の安定前と安定後の性能差、（２）実行性能が安定するまでの期間、（３）コンパイル処理の集中度、（４）コンパイル処理の集中期間、（５）プログラム（メソッド）ごとの実行頻度（重要度）になり、本実施形態では、これらに応じたコンパイルを行うタイミングの調整を行う。
この５つの情報を、コンパイルタイミング調整の判断基準情報と呼ぶ。
【００５２】
図９は、コンパイルタイミング調整の判断基準情報を取得する２回のタイミングを示す図である。
プログラム（メソッド）ごとの実行頻度（重要度）は、図３、図４の特徴（ａ）、（ｂ）、（ｃ）に応じた調整を行うために、アプリケーションプログラムの起動が完了した時点と、アプリケーションプログラムの運用開始後であって性能が安定した時点の２回取得する。
【００５３】
アプリケーションプログラムの運用開始後に、性能がいつ安定したか判別できない場合は、予め設定した測定期間が過ぎたときに取得するか、あるいは、コンパイル処理の集中度が変化した時点に取得してもよい。
【００５４】
コンパイルタイミング調整の判断基準情報は、アプリケーションプログラムの実行を実施して初めて取得することができる（アプリケーションプログラムを実行しないと取得することができない）。このため、アプリケーションプログラムを運用する前のテスト時に運用時と同じ環境でアプリケーションを動作させて判断基準情報を取得し、各プログラム（メソッド）のコンパイルを行うタイミングを決定し、コンパイルのタイミングを調整するための情報を作成する。
【００５５】
コンパイルのタイミングを調整する情報の作成は、運用前のテスト時だけでなく、アプリケーションプログラムの最初の運用や、必要になったときなどの任意の運用時に行うこともできる。１度作成すると、それ以後の運用で使用することができる。コンパイルタイミング調整の判断基準情報のうち、（１）実行性能の安定前と安定後の性能差、（２）実行性能が安定するまでの期間は、アプリケーションサーバが取得して、仮想マシンに通知する。（３）コンパイル処理の集中度、（４）コンパイル処理の集中期間、（５）プログラム（メソッド）ごとの実行頻度（重要度）は、仮想マシンが取得する。
【００５６】
（１）の実行性能の安定前と安定後の性能差は、アプリケーションプログラムの起動開始時点を安定前とし、コンパイル処理するメソッドの数の揺らぎが所定値以下になった時点を安定後として、性能差（レスポンス時間の差）を取得することによって得られる（後述の図１７のステップＳ１６、Ｓ１８に対応する）。（２）の安定するまでの期間は、（１）の安定前から安定後の間の時間である。（３）のコンパイルの集中度は、所定の測定時間内に行なわれるコンパイル処理の数である。(４)のコンパイル処理の集中期間は、コンパイル処理の集中度を計測した時間である。（５）のプログラム(メソッド）ごとの実行頻度（重要度）は、メソッドごとに単位時間当たりに実行された回数を計測し、その回数から、閾値を用いて、メソッドを分類したものである（後述）。
【００５７】
アプリケーションサーバで実行するアプリケーションプログラムの場合は、アプリケーションプログラムの作成者（例えばＳＥ）とアプリケーションプログラムの利用者(運用者)は同じことが多い。
【００５８】
アプリケーションプログラムの作成者と利用者が同じ場合は、コンパイルタイミング調整の判断基準情報の収集時をテスト時に行うか、アプリケーションプログラムの運用時に行うかは、利用者の判断になる。
【００５９】
アプリケーションプログラムを製品として第三者（利用者）に提供する場合は、テスト時に一般的な利用形態にもとづいてコンパイルタイミング調整値を決定して、製品に同梱するという形態が考えられる（製品にコンパイルタイミング調整値の決定と利用を行う仕組みを持たせるという形態も可能である）。
【００６０】
図１０及び図１１は、コンパイルタイミング調整の判断基準情報からコンパイルのタイミングを調整する方法を説明する図である。
コンパイルを行うタイミングは、プログラム(メソッド)の実行頻度がどこまで到達したかによって決定する。本実施形態では、状況に応じてそれぞれのプログラム（メソッド）ごとに、実行頻度の到達に応じてコンパイルを行うタイミングを調整する。
【００６１】
従来技術では、メソッドの実行回数をカウントして、回数が事前に設定した閾値に到達したらコンパイルする。どのメソッドも、実行回数が固定の閾値に到達したときにコンパイルする。
【００６２】
本実施形態では、特徴（ａ）のメソッドはアプリケーションプログラムの起動が完了する前に、コンパイルが完了するように調整する。
特徴（ｂ）、（ｃ）のメソッドは、コンパイルタイミング調整の判断基準情報（（１）実行性能の安定前と安定後の性能差、（２）実行性能が安定するまでの期間、（３）コンパイル処理の集中度、（４）コンパイル処理の集中期間、（５）プログラム（メソッド）ごとの実行頻度（重要度））から求めたコンパイルタイミング調整値によって、コンパイルするタイミングを決定する。
【００６３】
特徴（ａ）のプログラム（メソッド）は、アプリケーションプログラムの起動が完了する前にコンパイルが完了するように調整する。アプリケーションプログラムの起動完了時点で測定したプログラム（メソッド）ごとの実行頻度を参照して、そのプログラム（メソッド）がコンパイルされるタイミングをアプリケーションプログラムの起動完了時点での実行頻度により規定されるコンパイルタイミングよりも少し早いタイミングで（予め決めた特定の割合だけ小さく見積もった実行頻度の到達で）、コンパイルが行われるようにする。これにより、アプリケーションプログラムの起動完了前に実行されたプログラム（メソッド）が、アプリケーションプログラムの運用開始後にコンパイルされることはなくなる。
【００６４】
特徴（ｂ）、（ｃ）のプログラム（メソッド）のコンパイルタイミングの調整方法を説明する。コンパイルタイミング調整の判断基準情報の１つであるプログラム（メソッド）ごとの実行頻度（重要度）は、実行頻度が高いものほどアプリケーションプログラムの実行性能への影響が大きいと考え、実行頻度に応じて、重要度１（極めて重要）、重要度２（重要）、重要度３（通常）、重要度４（重要度は低い）に分類する。また、コンパイル処理の集中度は、集中度の程度に応じて、集中度大、集中度中、集中度小に分類する。集中度と各プログラム（メソッド）の重要度に応じてコンパイルのタイミングを早めるのか遅らせるのかの基本的な方向性を決める。これに、実際のアプリケーションプログラムの運用状況、つまり、コンパイルタイミング調整の判断基準情報の、実行性能の安定前と安定後の性能差、実行性能が安定するまでの期間、および、コンパイル処理の集中期間を加味した最適化をして、コンパイルを行うタイミングを決定する。
【００６５】
特徴（ｂ）、（ｃ）のプログラム（メソッド）について、コンパイルタイミング調整の判断基準情報により、コンパイルのタイミングをどのように調整するのかの方針を示したものが図１０である。また、実際にどの程度の調整を行うかを数値で表したものが図１１である。
【００６６】
図１１に示した調整の係数は、コンパイルを実施する標準の実行頻度（コンパイルタイミングの標準実行頻度；予め決定された値）に、この係数を掛けた値に、プログラム（メソッド）の実行が到達したときにコンパイルを行うことを示す。この係数の値は、仮想マシン起動時点で予め決められた値を設定するか、またはプログラムの作成者あるいは、利用者が適宜設定する。
【００６７】
特徴（ａ）のプログラム（メソッド）については、前述の調整方法でも説明したとおり、コンパイルを行うタイミングは、プログラム(メソッド)の実行頻度がどこまで到達したかによって決定する。
【００６８】
図１０において、各メソッドは重要度にしたがって分類される。重要度は、メソッドの実行頻度を３つの異なる閾値（閾値１＞閾値２＞閾値３）と比較し、決定する。重要度１は、最も実行頻度が高いメソッドで、閾値１より大きな実行頻度を持つメソッドが分類される。重要度２は、閾値１よりは小さいが閾値２より大きな実行頻度を持つメソッドが分類される。重要度３は、閾値２よりは小さいが閾値３より大きな実行頻度を持つメソッドが分類される。重要度４は、閾値３よりは小さい実行頻度を持つメソッドが分類される。集中度についても、２つの閾値を設け、コンパイル処理の集中度の値を分類する。
【００６９】
重要度１のメソッドは実行頻度が大きいので、集中度が大、中、小のいずれでも、コンパイルタイミングを早める。特に、実行性能の安定前と安定後の性能差が大きいほど大きく早めるようにする。重要度２のメソッドは、集中度が大のときであって、実行性能が安定するまでの期間がコンパイル処理の集中期間と一致する場合に、コンパイルタイミングを遅らせる。集中度が中の場合には、何もしない。集中度が小のときは、コンパイルタイミングを早める。
【００７０】
重要度３のメソッドは、集中度が大のときは、コンパイルタイミングを遅らせ、集中度が中のときは何もせず、集中度が小のときは、実行性能が安定するまでの期間がコンパイルの集中期間に比べて長い場合に、コンパイルタイミングを早める。重要度４のメソッドは、いずれの集中度のときも、コンパイルタイミングを遅らせる。特に、実行性能の安定前と安定後の性能差が大きいほど大きく遅らせるようにする。ただし、集中度が大のときは、実行性能が安定するまでの期間がコンパイルの集中期間に比べて長い場合には、小さく遅らせる。
【００７１】
図１１は、図１０の定性的処理分類を、数値例を入れて具体的にしたものである。図１１において、具体的な数値は一例であり、実際の数値は仮想マシン起動時点で予め決められた値、またはプログラムの作成者あるいは利用者が適宜設定する。
【００７２】
ここで説明した、特徴（ｂ）、（ｃ）のプログラム（メソッド）に対するコンパイルタイミングの調整方法を、図８に示したアプリケーションの３つのケースに当てはめて、その作用を説明する。
【００７３】
ケース１（不安定・安定時の性能差が大きく、不安定な期間（実行性能が安定するまでの期間）が短い場合）になるのは、短期間にコンパイルが集中するケース（集中度大）が通常である。コンパイルの集中が性能を不安定にしている主原因であるかは、集中期間と不安定期間がほぼ一致するかどうかで判断できる（数値で判断するには、不安定期間÷集中期間が１．０に近い場合なので、例えば、この値が１．２以下であればコンパイル集中が主原因であると判断する）。重要度１のプログラム（メソッド）に対しては、コンパイルのタイミングを早めるが、重要度２〜４のプログラム（メソッド）に対してはコンパイルのタイミングを遅らせる。このとき重要度が低い（４に近いもの）ほど、大きく遅らせる。また、不安定・安定の性能差も考慮するが、性能差が大きい場合ほどコンパイルの集中の影響を受けているので、重要度が低いプログラム（重要度４）に対しては、性能差が大きい場合はコンパイルのタイミングをより遅らせる。その分、逆に、極めて重要なプログラムは、性能差が大きい場合ほどコンパイルのタイミングを早めて、ネイティブコードへの切り替えを早く行う。
【００７４】
ケース２（不安定・安定時の性能差が小さく、不安定な期間（実行性能が安定するまでの期間）が長い場合）になるのは、コンパイルが徐々に進む(集中度小で、実行からネイティブコードによる実行への切り替えが遅い)ケースが通常である。この状況は、コンパイル集中期間に対して不安定期間が長いかどうかで判断できる（数値で判断するには、不安定期間÷集中期間が大きい場合なので、例えば、この値が１．５より大きいと判断する）。重要度が通常より高い（重要度１〜３）場合は、コンパイルのタイミングを早めてネイティブコードによる実行への切り替えが早く行われるようにする。このとき、重要度が高いものほどコンパイルのタイミングを早める。また、不安定・安定の性能差も考慮するが、重要度１（極めて重要）なプログラムに対しては、性能差が大きいほどネイティブコードへの切り替えタイミングの遅れに影響するため、性能差が大きいほどコンパイルのタイミングを早める。重要度１〜３のプログラムのタイミングを早めた分、逆に、重要度４のプログラムのタイミングを遅らせることで、コンパイル時間の影響のバランスを取ることができる（重要度１のプログラムに対して、性能差大の場合はコンパイルのタイミングをより早めたので、重要度４では性能差大の場合にコンパイルのタイミングを遅らせる）。
【００７５】
ケース３（不安定・安定時の性能差が大きく、不安定な期間（実行性能が安定するまでの期間）が長い場合）は特殊なケースと考えられるが、コンパイルの集中が長く続く、あるいは、インタプリタによる実行とネイティブコードによる実行の性能差が大きいこと（または、その複合）が考えられる。この場合、不安定・安定時の性能差が大きく、不安定な期間が長いことから、集中度大に判定される可能性があるが、ケース１（同じく集中度大に分類される可能性の高い）の場合と係数の決め方を変える。ケース１とケース３の識別は、ケース１は、コンパイルの短期集中が主要因であるため、集中期間と不安定期間がほぼ一致するかどうかで判断した（数値では、不安定期間÷集中期間が１．２以下）。ケース３は、コンパイルの長期集中が要因とは限らないので、不安定期間が集中期間より長くなっているかで判断する（数値では、不安定期間÷集中期間が１．２より大きい；なお、この値は後にコンパイル集中期間影響率と呼ぶ）。その場合、ケース１と比べてケース３は、ネイティブコードへの切り替えの遅れが発生しているプログラムの割合が高いため、コンパイルのタイミングを早める場合（重要度１）、遅らせる場合（重要度４）のどちらも、コンパイルのタイミングをケース１より少し早める。
【００７６】
集中度が中の場合は、集中度が小と集中度が大の中間の状況に対応できるように係数を設定する。
なお、自動的に集中度に応じた調整を行う形態を説明したが、人の判断で、どのケースの調整方法を行うのかを指定できるようにしてもよい。
【００７７】
図１２は、本実施形態が適用されるシステムの構成例を示す図である。
本実施形態は、サーバマシン（アプリケーションサーバ）１０−１、１０−２に実装されるアプリケーションサーバプログラム１４、アプリケーションサーバプログラムに組み込まれる仮想マシン１２、仮想マシン上で動作する動的コンパイラ１３において実施される。アプリケーションサーバプログラム１４上では、アプリケーションプログラム１５が動作する。Ｗｅｂサーバプログラム１６は、アプリケーションプログラムやデータの受け渡しの仲介を行い、ＯＳ（Operating System)１７上で動作する。
【００７８】
サーバマシン１０−２は、上記のようなＷｅｂサーバプログラム１６とＯＳ１７を実装し、ネットワークを介して、クライアントマシン１１と通信したり、他のサーバマシン１０−１と通信する。サーバマシン１０−２は、クライアントマシン１１からの、アプリケーションプログラムの実行リクエストを受け取ったり、該リクエストに対するレスポンスをクライアントマシン１１に返送したりする。また、他のサーバマシン１０−１からは、ネットワークを介して、アプリケーションプログラム１５ａを受け取り、自サーバマシン１０−２にインストールしたりする。他のサーバマシン１０−１からアプリケーションプログラム１５ａを受信できるようにすることにより、自サーバマシン１０−２には実装されていなかったアプリケーションプログラム１５の実行をクライアントマシン１１からリクエストされた場合にも対応することができるようになる。
【００７９】
また、本実施形態のプロセスを実現するプログラムは、仮想マシン１２に組み込まれて実行されるが、これは、他のサーバマシン１０−１から自サーバマシン１０−２に、ネットワークを介してダウンロードされ、自サーバマシン１０−２にインストールされるようにしても良い。あるいは、本実施形態のプロセスを実現するプログラムは、ＣＤ−ＲＯＭ，ＤＶＤ、ＩＣメモリ、フレキシブルディスク、Ｂｌｕ−ｒａｙ等の可搬記録媒体１９に格納されていてもよい。この場合、可搬記録媒体１９に格納されている当該プログラムを媒体ドライバ１８で読み取り、サーバマシン１０−２にインストールするようにして使用する。
【００８０】
図１３は、アプリケーションサーバ上で動作する各機能のブロック構成を示す図である。
アプリケーションサーバ２０には、仮想マシン起動部２１、リクエストの送付部２２、アプリケーションの実行性能（レスポンス性能）計測・通知部２３を持つ。
【００８１】
仮想マシン起動部２１は、（１）仮想マシン１２を起動して、運用対象のアプリケーションプログラム１５を仮想マシン１２上で実行できるように、アプリケーションプログラム１５の起動を開始する。また、仮想マシン起動部２１は、（２）アプリケーションプログラム１５の起動が完了して、アプリケーションプログラム１５の運用の（リクエストを受け付ける）準備が整ったら、アプリケーションプログラム１５の起動完了通知を、仮想マシン１２に送付する。次に、リクエストの送付部２２は、（３）リクエストを仮想マシン１２上で動作するアプリケーションプログラム１５に送付する。アプリケーションの実行性能計測・通知部２３は、（４）アプリケーションの実行性能(レスポンス性能)を測定して、実行性能が安定する前と安定した後の性能差、および、安定した性能になるまでの期間を計測して、性能が安定したと判断した時に、仮想マシン１２に通知する。
【００８２】
図１４及び図１５は、仮想マシン上、および、仮想マシンの動的コンパイラでの動作を説明する図である。
仮想マシン１２は、動的コンパイラ１３に加え、コンパイル集中度の計測部３０、プログラム（メソッド）実行頻度の計測部３１、コンパイルのタイミング調整決定部３２、コンパイルタイミング制御情報の計算と出力部３３ （以上図１４）、コンパイルタイミング情報の入力・判断部３４(以上図１５)を持つ。
【００８３】
コンパイル集中度の計測部３０は、動的コンパイラ１３で行われているコンパイル処理を測定して、コンパイル集中度を求めるために、定められた期間、定められた時間単位にコンパイルされるプログラム数（メソッド数）を記録する。定められた期間とは、図９で示した、２回のコンパイルタイミング調整の判断基準情報の取得タイミングの間の時間である。
【００８４】
プログラム（メソッド）実行頻度の計測部３１は、プログラム（メソッド）が呼び出されたときに、そのプログラム(メソッド)の実行頻度を記録する。コンパイルのタイミング調整決定部３２は、コンパイル集中度の計測部３０、および、プログラム(メソッド)実行頻度の計測部３１を起動することで、あるいは、アプリケーションサーバ２０からの通知で、コンパイルタイミング調整の判断基準情報を収集して、これらの情報から、各プログラム（メソッド）のコンパイルタイミングを決定する。
【００８５】
コンパイルのタイミング調整決定部３２の手順は、（１）アプリケーションサーバ２０からアプリケーションプログラムの起動完了通知を受け取ったら、（２）プログラム（メソッド）実行頻度の計測部３１が記録した実行頻度を参照して、その時点（アプリケーションプログラムの起動が完了した時点の）プログラム（メソッド）ごとの実行頻度を保存する。また、（３）コンパイル集中度の計測部３０に、コンパイルの集中度の記録の開始を指示する。（４）アプリケーション性能が安定した時点で、アプリケーションサーバ２０からアプリケーション実行性能の通知(実行性能の安定前と安定後の性能差、実行性能が安定するまでの期間) を受けたら、（５）プログラム（メソッド）実行頻度の計測部３１が記録した実行頻度を参照する。そして、その時点（アプリケーション性能が安定した時点）で、プログラム（メソッド）ごとの実行頻度を保存する。 また、（６）コンパイル集中度の計測部３０に、コンパイルの集中度の記録の終了を指示する。以上の（１）〜（６）のプロセスで取得した情報がコンパイルのタイミング調整の判断基準情報になる。
【００８６】
コンパイルタイミング制御情報の計算と出力部３３は、コンパイルのタイミング調整の判断基準情報から、各プログラム（メソッド）のコンパイルのタイミングを決定して、コンパイルタイミング制御情報を出力する。コンパイルタイミング制御情報は、コンパイルのタイミング調整を行う１つのプログラム（メソッド）に対して、プログラム（メソッド）識別情報とコンパイルタイミング調整値を持つ。コンパイルタイミング調整値は、プログラム(メソッド）が実行される回数を示し、この回数分だけ実行されたらコンパイルするように指示するためのものである。具体的な数値は、予め決められた数値に、図１１で説明した係数を乗算したものを用いる。
【００８７】
図１５に示すように、コンパイルタイミング制御情報の入力・判断部３４は、コンパイルタイミング制御情報を使用して仮想マシン１２を起動する場合に動作する。アプリケーションサーバ２０は、アプリケーションプログラムに対応したコンパイルタイミング制御情報があれば、仮想マシン１２を起動するときに、コンパイルタイミング制御情報を通知して起動する。仮想マシン１２は、コンパイルタイミング制御情報の入力・判断部３４により、コンパイルタイミング制御情報を読み込む。また、プログラム（メソッド）の呼び出しがあった場合に、そのプログラム（メソッド）の実行頻度がコンパイルタイミング制御情報で指定された値に到達したら、動的コンパイラ１３に、そのプログラム（メソッド）のコンパイルを依頼する。
【００８８】
従来技術では、コンパイルを依頼するときの実行頻度は、どのプログラム（メソッド）でも固定の値であったが、本実施形態では、プログラム(メソッド)ごとに調整された値（コンパイルタイミング制御情報のコンパイル調整値）に実行頻度が到達していれば、動的コンパイラ１３に、そのプログラム（メソッド）のコンパイルを依頼する。該当するプログラム(メソッド)がコンパイルタイミング情報にない場合は、仮想マシン１２の起動時点で予め決められた標準値に到達した場合にコンパイルを依頼する。
【００８９】
図１６は、仮想マシン起動部の動作フローチャートである。
ステップＳ１０において、コンパイルタイミング制御情報が存在し、かつ、この情報を使用した起動であるか否かを判断する。ステップＳ１０の判断がＹｅｓの場合には、ステップＳ１１に進み、Ｎｏの場合には、ステップＳ１２に進む。ステップＳ１１では、仮想マシンを起動すると共に、実行するアプリケーションプログラムと、コンパイルタイミング制御情報を仮想マシンに通知する。ステップＳ１２では、仮想マシンを起動すると共に、実行するアプリケーションプログラムと、コンパイル制御情報を使用しないことを仮想マシンに通知する。ステップＳ１３において、アプリケーションプログラムの運用が開始可能になったら、アプリケーションプログラムの起動完了通知を仮想マシンに通知して、処理を終了する。
【００９０】
図1７は、アプリケーションプログラムの実行性能計測・通知部の動作フローチャートである。また、図１８は、アプリケーションの実行性能計測・通知部が使用するデータを示す図である。
【００９１】
図１８のデータ（１）（２）（４）は、アプリケーションサーバが使用するメモリ上に置かれ、データ（３）は仮想マシンが使用するメモリ上に置かれる。（１）の平均実行性能の記録では、アプリケーションプログラムについて、平均実行性能の測定を行なうたびに記録番号をつけ、平均実行性能、すなわち、平均レスポンス時間をミリ秒の単位で記録する。（２）の平均実行性能の記録回数は、（１）の平均実行性能の記録番号の最大値であり、予め設定される。（３）のアプリケーションサーバから通知された実行性能情報は、実行性能の安定前と安定後の性能差と、実行性能が安定するまでの時間からなる。（４）のデータの平均実行性能の最大記録回数、実行性能の安定判断の変動率、実行性能決定のサンプリング数は、仮想マシン起動時点で予め決められた値を使用する。
【００９２】
図１７において、ステップＳ１５では、アプリケーションプログラムの実行性能（レスポンス時間）を実行性能決定のサンプリング数だけ測定して、その平均実行性能を求め、平均実行性能の記録に設定する。このサンプリング数は、予め決定しておく。ステップＳ１６において、平均実行性能の変動の割合が、前回記録した平均実行性能に比べて、実行性能の安定判断の変動率より小さいか否かを判断する。ステップＳ１６の判断がＹｅｓの場合には、ステップＳ１８に進む。ステップＳ１６の判断がＮｏの場合には、ステップＳ１７に進む。ステップＳ１７では、平均の実行性能の記録回数が、平均実行性能の最大記録回数より大きいか否かを判断する。ステップＳ１７の判断がＹｅｓの場合には、ステップＳ１８に進む。ステップＳ１７の判断がＮｏの場合には、ステップＳ１５に戻る。ステップＳ１８では、最初に記録した平均の実行性能と最後に記録した平均の実行性能の割合から、実行性能の安定前と安定後の性能差（（実行性能の安定前と安定後の性能比）＝（安定前に記録した平均実行性能）÷（安定後に記録した平均実行性能））を求め、仮想マシンに通知する。また、平均実行性能を最初に記録した時刻と最後に記録した時刻の差から、実行性能が安定するまでの期間を求め、仮想マシンに通知する。
【００９３】
図１９Ａ、Ｂは、コンパイル集中度の計測部の動作フローチャートである。また、図２０は、コンパイル集中度の計測部が使用するデータを示す図である。
図２０のデータは、仮想マシンが使用するメモリ上に置かれる。（１）のコンパイル集中度の記録は、測定ごとに付けられる、コンパイル集中度の記録番号と、各測定が行なわれた時刻である、コンパイル集中度の測定時期（例えば、単位は秒）と、測定時に検出された実行中のコンパイル処理の数である、コンパイル集中度（例えば、単位は、個／秒）とからなる。（２）のデータは、コンパイル集中度の記録回数と、前回の計測時までに完了したコンパイルの総数とからなる。（３）のデータは、コンパイル処理の集中期間と、コンパイル処理の集中度（例えば、単位は、個／秒）とからなる。（４）のデータは、コンパイル集中度測定のサンプリング間隔、コンパイル集中度測定の最小サンプリング期間、コンパイル集中度測定の最大サンプリング期間、コンパイル集中度判定の変動率からなり、これらは、仮想マシン起動時点で予め決められた値を使用する。
【００９４】
図１９Ａ、Ｂにおいて、コンパイル集中度の計測部は、ステップＳ２０で、コンパイル集中度測定の測定終了の指示をコンパイルのタイミング調整決定部から受けているか否かを判断する。ステップＳ２０の判断がＹｅｓの場合には、ステップＳ２８に進む。ステップＳ２０の判断がＮｏの場合には、ステップＳ２１において、コンパイル集中度測定の総期間が、コンパイル集中測定の最大サンプリング期間を超えているか否かを判断する。ステップＳ２１の判断がＹｅｓの場合には、ステップＳ２８に進む。ステップＳ２１の判断がＮｏの場合には、ステップＳ２２において、コンパイル集中度測定の測定開始の指示をコンパイルのタイミング調整決定部から受けているか否かを判断する。
【００９５】
ステップＳ２２の判断がＮｏの場合には、ステップＳ２７に進む。ステップＳ２２の判断がＹｅｓの場合には、ステップＳ２３において、コンパイル集中情報のコンパイル処理の集中度を設定済みか否かを判断する。ステップＳ２３の判断がＹｅｓの場合には、ステップＳ２７に進む。ステップＳ２３の判断がＮｏの場合には、ステップＳ２４において、動的コンパイル部（後述）から、プログラム（メソッド）のコンパイル総数を受け取る。そして、（コンパイル処理の集中度）＝（（今回計測時のコンパイル総数）−（前回計測時のコンパイル総数））÷（コンパイル集中度測定のサンプリング間隔(秒））により、コンパイル処理の集中度を求めて、コンパイル集中度の記録に設定する。また、今回測定時のコンパイル総数を前回測定時のコンパイル総数に保存する。
【００９６】
ステップＳ２５では、前回記録したコンパイル処理の集中度と今回記録したコンパイル処理の集中度を比べて、変動の割合が、コンパイル集中判定の変動率より小さい、かつ、コンパイル集中度測定の総期間がコンパイル集中度測定の最小サンプリング期間以上か否かを判断する。ステップＳ２５の判断がＮｏの場合には、ステップＳ２７に進む。ステップＳ２５の判断がＹｅｓの場合には、ステップＳ２６に進む。
【００９７】
ステップＳ２６では、これまで測定・記録した期間をコンパイル処理の集中期間に設定し、これまでに記録したコンパイル処理の集中度の平均を求め、コンパイル処理集中度に設定する。そして、ステップＳ２７において、コンパイル集中度測定のサンプリング間隔（秒）の間、スリープし、ステップＳ２０に戻る。
【００９８】
ステップＳ２８では、コンパイル集中度情報のコンパイル集中度が設定済みか否かを判断する。ステップＳ２８の判断がＮｏのときは、ステップＳ２９に進む。ステップＳ２８の判断がＹｅｓのときは、処理を終了する。ステップＳ２９では、これまで測定・記録した期間をコンパイル処理の集中期間に設定し、これまでに記録したコンパイル処理の集中度の平均を求め、コンパイル処理の集中度に設定して、処理を終了する。
【００９９】
図２１は、プログラム(メソッド)実行頻度の計測部の動作フローチャートである。図２２は、プログラム(メソッド)実行頻度の計測部が使用するデータを示す図である。
図２２のデータは、仮想マシンが使用するメモリ上に置かれる。図２２のプログラム（メソッド）実行頻度の記録は、プログラム（メソッド）の識別情報として、メソッド名とそのシグネチャが格納される。そして、この識別情報に対応して、プログラム（メソッド）の実行頻度、コンパイル状態が格納される。実行頻度は、実行頻度の計測を始めてから現在の記録時点までのメソッドの実行回数を記録する。プログラム実行頻度の記録には、プログラム（メソッド）がコンパイルされたかどうかの状態を記録する項目があり、この項目の初期値はfalseで、動的コンパイラがプログラム（メソッド）をコンパイルしたときに、対象のプログラム（メソッド）のコンパイル状態をtrueにする。
【０１００】
図２１において、プログラム(メソッド)実行頻度の計測部の処理は、仮想マシンによって、プログラム(メソッド)の呼び出しが行われたときに実行される。ステップＳ３５において、測定対象のプログラム（メソッド）が、プログラム（メソッド）実行頻度の記録に登録されているか否かを判断する。ステップＳ３５の判断がＮｏの場合には、ステップＳ３６において、プログラム（メソッド）実行頻度の記録に、測定対象のプログラム（メソッド）を追加し、追加したプログラム（メソッド）の記録に、そのプログラム（メソッド）の識別情報を設定し、実行頻度を「１」に設定して、処理を終了する。ステップＳ３５の判断がＹｅｓの場合には、ステップＳ３７において、プログラム（メソッド）実行頻度の記録から、測定対象のプログラム（メソッド）の記録を検索し、実行頻度に値を加算する。加算する値は、１でもよいし、プログラム（メソッド）の内容に応じて、重み付けをした値を使っても良い。内容に応じて重み付けするとは、プログラム（メソッド）の大きさやループ処理のありなしなどから、当該プログラム（メソッド）の実行負荷の大きさに従い重み付けするものである。ステップＳ３７の処理が終わったら、処理を終了する。
【０１０１】
図２３Ａ、Ｂは、コンパイルタイミング調整決定部の動作フローチャートである。また、図２４は、コンパイルタイミング調整決定部が扱うデータを示す図である。
図２４のデータは、仮想マシンが使用するメモリ上に置かれる。（１）のプログラム（メソッド）実行頻度の重要度決定の基準値は、計測された実行頻度を４つの重要度の段階に分類するための実行頻度の区間が指定されている。プログラム（メソッド）実行頻度の重要度決定の基準値は、仮想マシン起動時点で予め決められた値を使用する。（２）〜（５）は、コンパイルタイミング調整の判断基準情報である。（２）は、アプリケーション起動完了時のプログラム（メソッド）実行頻度情報である。これは、プログラム（メソッド）の識別情報に対応して、プログラム（メソッド）の実行頻度とコンパイル情報が格納される。（３）は、アプリケーション性能安定時のプログラム（メソッド）実行頻度情報である。これは、プログラム（メソッド）の識別情報に対応して、プログラム（メソッド）の実行頻度と、コンパイル情報と、（１）のデータから得られた重要度が格納される。（２）と（３）のデータは、それぞれ、アプリケーション起動完了時と性能安定時に測定された図２２のデータから生成される。（４）は、コンパイル集中情報であり、コンパイル集中度の計測部が作成するものである。これは、コンパイル処理の集中期間と、コンパイル処理の集中度（個／秒）のデータからなる。（５）は、アプリケーションサーバから通知された実行性能情報であり、実行性能の安定前と安定後の性能差と、実行性能が安定するまでの期間からなる。
【０１０２】
図２３Ａ、Ｂにおいて、ステップＳ４０では、コンパイルタイミング調整決定部は、仮想マシン起動部から、アプリケーションプログラムの起動完了の通知が届いているか否かを判断する。ステップＳ４０の判断がＹｅｓの場合には、ステップＳ４２に進む。ステップＳ４０の判断がＮｏの場合には、ステップＳ４１に進む。
【０１０３】
ステップＳ４１では、仮想マシン起動部からアプリケーションプログラムの起動完了の通知が届くまで待ち合わせる。ステップＳ４２では、プログラム（メソッド）実行頻度計測部が集計しているプログラム（メソッド）実行頻度の記録を複写して、アプリケーションプログラム起動完了時のプログラム（メソッド）の実行頻度情報を作成する。ステップＳ４３では、コンパイル集中度の計測部を実行して、コンパイル集中度の計測を開始する。
【０１０４】
ステップＳ４４において、アプリケーションの実行性能計測・通知部からアプリケーションプログラムの実行性能の通知が届いているか否かを判断する。ステップＳ４４の判断がＹｅｓの場合には、ステップＳ４６に進む。ステップＳ４４の判断がＮｏの場合には、ステップＳ４５において、アプリケーションの実行性能計測・通知部からプリケーション実行性能の通知が届くまで待ち合わせる。
【０１０５】
ステップＳ４６では、アプリケーションサーバから通知された実行性能情報を仮想マシンのメモリに格納する。ここで、実行性能情報は、実行性能の安定前と安定後の性能差、及び、実行性能が安定するまでの期間からなる。
【０１０６】
ステップＳ４７では、プログラム(メソッド）実行頻度計測部が集計しているプログラム（メソッド）実行頻度の記録を複写して、アプリケーション性能安定時のプログラム（メソッド）実行頻度情報を作成する。また、アプリケーション性能安定時のプログラム（メソッド）実行頻度情報には、実行頻度に応じた重要度を格納する項目を設ける。そして、アプリケーション性能安定時のプログラム（メソッド）実行頻度情報に設定されている各プログラム（メソッド）の実行頻度と重要度基準値（閾値）とを比較して、重要度を設定する。
【０１０７】
ステップＳ４８では、コンパイル集中度の計測部を実行して計測処理を実行し、計測処理が終わったらコンパイル集中度の計測を終了する。ここで、コンパイル集中度の計測部が作成したコンパイル集中度の記録は、コンパイルのタイミング調整決定部から参照でき、これをコンパイル集中情報とする。ステップＳ４９において、コンパイルタイミング制御情報の計算と出力部を実行して、コンパイルタイミング制御情報を出力する。
【０１０８】
図２５Ａ、Ｂ、Ｃは、コンパイルタイミング制御情報の計算と出力手部の動作フローチャートである。また、図２６は、コンパイルタイミング制御情報の計算と出力部が扱うデータを示す図である。
【０１０９】
図２６のデータは、仮想マシンが使用するメモリ上に置かれる。また、コンパイルタイミング制御情報の計算と出力部は、図２４に示したコンパイルタイミング調整の判断基準情報も使用する。コンパイルタイミング調整係数、コンパイルタイミングの標準実行頻度、コンパイル集中度決定の基準値、コンパイルタイミング調整係数の決定基準テーブルの内容は、仮想マシン起動時点で予め決められた値を使用する。（１）のデータは、コンパイルタイミング調整係数と、コンパイルタイミングの標準実行頻度とからなる。コンパイルタイミングの標準実行頻度は、プログラム（メソッド）がコンパイル処理されるまでに、インタプリタで実行される回数の基準値であり、予め決められた値である。コンパイルタイミング調整係数は、コンパイルタイミングの標準実行頻度に乗算して、コンパイル処理が行なわれるまでにプログラム（メソッド）が実行される回数を可変するための値であり、コンパイルタイミング調整係数の決定基準テーブルに基づいて決定される。
【０１１０】
（２）のコンパイル集中度決定の基準値は、単位時間当たりのコンパイル処理されたプログラム（メソッド）数を、３つの段階に分類するための基準値（閾値）を示すもので、これに従い、コンパイルの集中度が、大、中、小のいずれかに設定される。（３）の性能差大小決定の基準値は、実行性能の安定前と安定後の性能差を２つの段階（大・小）に分類するための基準値（閾値）を示す。（４）のコンパイルタイミング調整係数の決定基準テーブルは予め設定されたもので、アプリケーションプログラムのインタプリタによる実行結果から各プログラム（メソッド）を重要度と集中度で分類した結果を用いて、コンパイルタイミング調整係数を設定するためのものである。コンパイルタイミング調整係数の値が１．０の場合には、コンパイルタイミングは変更されず、１．０より大きければ、コンパイルタイミングは遅くなり、１．０より小さければ、コンパイルタイミングは早くなる。
【０１１１】
（５）のコンパイルタイミング制御情報は、プログラム（メソッド）ごとにコンパイルタイミング調整値を格納するもので、プログラム(メソッド）の識別情報（メソッド名とシグネチャ）と、コンパイルタイミング調整値が対応付けられて、コンパイルタイミング制御情報の計算と出力部によって生成され、出力される。コンパイルタイミング調整値は、コンパイルタイミングの標準実行頻度に、（４）のデータから得られたコンパイルタイミング調整係数を乗算して得られる。
【０１１２】
図２５Ａ、Ｂ、Ｃにおいて、コンパイルタイミング制御情報の計算と出力部は、ステップＳ５５において、アプリケーションプログラムの起動完了時のプログラム（メソッド）実行頻度情報を読み込み、１つ目に登録されているプログラム（メソッド）の実行頻度情報を取り出す。ステップＳ５６において、プログラム（メソッド）の実行頻度情報があるか否かを判断する。
【０１１３】
ステップＳ５６の判断がＮｏの場合には、ステップＳ６３に進む。ステップＳ５６の判断がＹｅｓの場合には、ステップＳ５７において、実行頻度情報から、プログラム（メソッド）識別情報、コンパイル状態、プログラム（メソッド）の実行頻度を取り出す。ステップＳ５８において、取り出した実行頻度情報のコンパイル状態はtrueか否かを判断する。ステップＳ５８の判断がＹｅｓの場合には、ステップＳ５９に、Ｎｏの場合には、ステップＳ６０に進む。
【０１１４】
ステップＳ５９においては、コンパイルタイミング調整値に、プログラム（メソッド）の実行頻度を設定し、ステップＳ６１に進む。ステップＳ６０においては、コンパイルタイミング調整値に、（プログラム（メソッド）の実行頻度）×（コンパイルタイミング調整係数）を設定する。ステップＳ６１では、コンパイルタイミング制御情報に、プログラム（メソッド）識別情報とコンパイルタイミング調整値を出力する。ステップＳ６２においては、次に登録されているプログラム(メソッド）の実行頻度情報を取り出し、ステップＳ５６に戻る。ここで、コンパイル状態がtrueでない（falseの）ものだけコンパイルタイミング調整値を可変するのは、trueとなっているものは、既にコンパイルされており、改めてコンパイルするタイミングを設定する必要が無いからである。
【０１１５】
ステップＳ６３では、アプリケーションプログラムの安定時のプログラム（メソッド）の実行頻度情報を読み込み、１つ目に登録されているプログラム（メソッド）の実行頻度情報を取り出す。ステップＳ６４において、プログラム（メソッド）の実行頻度情報があるか否かを判断する。ステップＳ６４の判断がＮｏの場合には、処理を終了する。ステップＳ６４の判断がＹｅｓの場合には、ステップＳ６５に進む。
【０１１６】
ステップＳ６５では、実行頻度情報から、プログラム（メソッド）識別情報、プログラム（メソッド）の実行頻度、重要度を取り出す。ステップＳ６６において、取り出したプログラム（メソッド）識別情報は、アプリケーションプログラム起動完了時のプログラム（メソッド）の実行頻度情報に含まれているか否かを判断する。ステップＳ６６の判断がＹｅｓの場合には、ステップＳ７４に進む。ステップＳ６６の判断がＮｏの場合には、ステップＳ６７に進む。
【０１１７】
ステップＳ６７では、アプリケーションサーバから通知された実行性能情報から、実行性能の安定前と安定後の性能差、実行性能が安定するまでの期間を取り出す。ステップＳ６８において、コンパイル集中情報から、コンパイル処理の集中期間、コンパイル処理の集中度を取り出す。ステップＳ６９において、コンパイル処理の集中度とコンパイル集中度判定の基準値を比較して、コンパイル処理の集中度（大／中／小）を求める。
【０１１８】
ステップＳ７０において、（コンパイル集中期間影響率）＝（実行性能が安定するまでの期間）÷（コンパイル処理の集中期間）を求める。ステップＳ７１において、コンパイルタイミング調整係数の決定基準テーブルから、コンパイル処理の集中度、プログラム（メソッド）の重要度、コンパイル集中度、コンパイル集中期間影響率、実行性能の安定前と安定後の性能差の条件に当てはまるコンパイルタイミング調整係数を求める（図２６（３）参照）。ステップＳ７２において、コンパイルタイミング調整値に、（コンパイルタイミングの標準実行頻度）×（コンパイルタイミング調整係数）を設定する。ステップＳ７３において、コンパイルタイミング制御情報に、プログラム（メソッド）識別情報とコンパイルタイミング調整値を出力する。ステップＳ７４において、次に登録されているプログラム（メソッド）の実行頻度情報を取り出し、ステップＳ６５に戻る。
【０１１９】
図２７は、コンパイルタイミング制御情報の入力・判断部の動作フローチャートである。また、図２８は、コンパイルタイミング制御情報の入力・判断部が使用するデータを示す図である。
【０１２０】
図２８において、（２）のコンパイルタイミング制御情報は、仮想マシンが使用するメモリから読み込んで使用する。（１）のコンパイルタイミングの標準実行頻度は、仮想マシン起動時点で予め決められた値を使用する。
【０１２１】
図２７において、コンパイルタイミング制御情報の入力・判断部は、メソッドの呼び出しがある前に起動される。ステップＳ８０で、コンパイルタイミング制御情報が読み込まれているか否かを判断する。ステップＳ８０の判断がＮｏの場合には、ステップＳ８４に進む。ステップＳ８０の判断がＹｅｓの場合には、ステップＳ８１において、プログラム（メソッド）の呼び出しがあった場合のそのプログラム（メソッド）が、コンパイルタイミング情報のプログラム（メソッド）識別情報に存在するか否かを判断する。ステップＳ８１の判断がＮｏの場合には、ステップＳ８４に進む。ステップＳ８１の判断がＹｅｓの場合には、ステップＳ８２に進む。
【０１２２】
ステップＳ８２においては、コンパイルタイミング制御情報から、プログラム（メソッド）の呼び出しがあったプログラム（メソッド）のコンパイルタイミング調整値を取り出す。ステップＳ８３において、プログラム（メソッド）の呼び出しがあった場合のそのプログラム（メソッド）の実行頻度が、コンパイルタイミング情報から取り出したコンパイルタイミング調整値以上か否かを判断する。ステップＳ８３の判断がＮｏの場合には、処理を終了する。ステップＳ８３の判断がＹｅｓの場合には、ステップＳ８５に進む。
【０１２３】
ステップＳ８４では、プログラム（メソッド）の呼び出しがあった場合のそのプログラム（メソッド）の実行頻度が、コンパイルタイミングの標準実行頻度以上か否かを判断する。ステップＳ８４の判断がＮｏの場合には、処理を終了する。ステップＳ８４の判断がＹｅｓの場合には、ステップＳ８５に進む。ステップＳ８５では、呼び出しがあったプログラム(メソッド）のコンパイルをコンパイラに依頼し、処理を終了する。
【０１２４】
図２９は、動的コンパイル部の動作フローチャートと使用するデータを示す図である。
コンパイルタイミング情報に基づいてどのようにコンパイルするかは、コンパイル制御情報の入力・判断部で制御しており、動的コンパイル部（動的コンパイラを含む）は、コンパイルの依頼があった時にコンパイル処理を実行する。
【０１２５】
図１９Ａ、Ｂおよび図２０のコンパイル集中度の計測部が、コンパイル総数を記録するために、動的コンパイル部は、動的コンパイラにコンパイル処理をさせると共に、コンパイル総数（図２９（ｂ））をカウントする処理を行う。
【０１２６】
図２９（ａ）において、動的コンパイル部は、ステップＳ９０で、プログラム（メソッド）のコンパイル依頼があるか否かを判断する。ステップＳ９０の判断がＮｏの場合には、ステップＳ９３に進む。ステップＳ９０の判断がＹｅｓの場合には、ステップＳ９１において、依頼のあったプログラム（メソッド）を動的コンパイラにコンパイルさせ、ステップＳ９２において、コンパイル総数（図２９（ｂ））を１増加する。そして、ステップＳ９３において、動的コンパイラを終了するか否かを判断する。これは、利用者からの指示で、動的コンパイラを終了するか否か決定するようにして良い。ステップＳ９３の判断がＮｏの場合には、ステップＳ９０に戻り、Ｙｅｓの場合には、処理を終了する。
【０１２７】
図３０及び図３１は、本実施形態の効果を説明する図である。
コンパイルを行うタイミングを調整して、インタプリタによる実行とネイティブコードによる実行のバランスを最適にすることで、アプリケーションプログラムの起動直後の実行性能が安定する。安定時のアプリケーション実行性能と比較して、アプリケーション起動直後の実行性能が低下する割合を図３０のように軽減することができる。図３０によれば、アプリケーションプログラムの起動開始後、起動完了と業務の開始前に行なわれる動的コンパイルの増加数が多くなり、アプリケーションプログラムの起動完了と業務の開始後の動的コンパイル数が減って、処理時間が短くなっている。また、アプリケーションの実行性能が安定した状態になるまでの期間を図３１のように早めることができる。すなわち、重要度の高いアプリケーションがインタプリタ実行からネイティブコードの実行へ早く切り替わり、アプリケーションプログラムの動作の安定化が早くなる。
【符号の説明】
【０１２８】
１０−１、１０−２ サーバマシン
１１ クライアントマシン
１２ 仮想マシン
１３ 動的コンパイラ
１４ アプリケーションサーバプログラム
１５、１５ａ アプリケーションプログラム
１６ Ｗｅｂサーバプログラム
１７ ＯＳ
１８ 媒体ドライバ
１９ 可搬記録媒体
２０ アプリケーションサーバ
２１ 仮想マシン起動部
２２ リクエストの送付部
２３ アプリケーションの実行性能計測・通知部
３０ コンパイル集中度の計測部
３１ プログラム(メソッド）実行頻度の計測部
３２ コンパイルのタイミング調整決定部
３３ コンパイルタイミング制御情報の計算と出力部
３４ コンパイルタイミング制御情報の入力・判断部
【特許請求の範囲】
【請求項１】
プログラムの実行に際して動的コンパイルを行うアプリケーションサーバであって、
該プログラムをインタプリタによって実行する際、該プログラムの実行性能に関する情報を取得する実行性能情報取得部と、
該実行性能に関する情報に基づいて、該プログラムに含まれる各メソッドについて、それぞれコンパイルタイミングを指定する情報を設定するコンパイルタイミング情報設定部と、
該コンパイルタイミングを指定する情報に基づいて、該メソッドをネイティブコードにコンパイルする動的コンパイル部と、
を備えることを特徴とするアプリケーションサーバ。
【請求項２】
前記実行性能情報取得部は、
前記プログラムの実行性能の安定前と実行性能の安定後の性能差、および、実行性能が安定するまでの期間についての情報を取得する安定前後情報取得部と、
コンパイル処理の集中期間、および、コンパイル処理の集中度についての情報を取得する集中情報取得部と、
各メソッドの実行頻度、および、各メソッドの重要度の情報を取得するメソッド情報取得部と、
を備えることを特徴とする請求項１に記載のアプリケーションサーバ。
【請求項３】
前記実行性能の安定前の時点は、前記プログラムの起動完了時点であり、前記実行性能の安定後の時点は、動的コンパイルによるコンパイル数の揺らぎが所定値以下となる時点であることを特徴とする請求項２に記載のアプリケーションサーバ。
【請求項４】
前記実行性能の安定前と実行性能の安定後の性能差は、前記プログラムの平均レスポンス時間の差であることを特徴とする請求項２に記載のアプリケーションサーバ。
【請求項５】
前記コンパイル処理の集中度は、単位時間当たりに行なわれたコンパイル処理の数に基づいたメソッドの分類を示すことを特徴とする請求項２に記載のアプリケーションサーバ。
【請求項６】
前記コンパイル処理の集中期間は、コンパイル処理数の計測の開始から、前記単位時間当たりに行なわれたコンパイル処理の数の変動の割合が所定値以下となるまでの期間であることを特徴とする請求項５に記載のアプリケーションサーバ。
【請求項７】
前記各メソッドの実行頻度は、単位時間当たりにそれぞれのメソッドを実行した回数であり、前記各メソッドの重要度は、該メソッドを実行した回数に基づいた各メソッドの分類を示すことを特徴とする請求項２に記載のアプリケーションサーバ。
【請求項８】
前記コンパイルタイミング情報設定部は、実行性能の安定前と実行性能の安定後の性能差、コンパイル処理の集中度、各メソッドの重要度、（実行性能が安定するまでの期間）÷（コンパイル処理の集中期間）によって求められるコンパイル集中期間影響率を基に、メソッドごとにコンパイルタイミング調整係数を決定し、所定値に該コンパイルタイミング調整係数を乗算して、前記コンパイルタイミングを指定する情報を設定することを特徴とする請求項２に記載のアプリケーションサーバ。
【請求項９】
前記実行性能の安定前と実行性能の安定後の性能差が大きいほど、前記コンパイルタイミング調整係数を小さくすることを特徴とする請求項８に記載のアプリケーションサーバ。
【請求項１０】
前記コンパイル処理の集中度が小さいほど、前記コンパイルタイミング調整係数を小さくすることを特徴とする請求項８に記載のアプリケーションサーバ。
【請求項１１】
前記各メソッドの重要度が重要なほど、前記コンパイルタイミング調整係数を小さくすることを特徴とする請求項８に記載のアプリケーションサーバ。
【請求項１２】
前記コンパイル集中期間影響率が大きいほど、前記コンパイルタイミング調整係数を小さくすることを特徴とする請求項８に記載のアプリケーションサーバ。
【請求項１３】
プログラムの実行に際して動的コンパイルを行うアプリケーションサーバの処理方法であって、
該アプリケーションサーバは、
該プログラムをインタプリタによって実行する際、該プログラムの実行性能に関する情報を取得し、
該実行性能に関する情報に基づいて、該プログラムに含まれる各メソッドについて、それぞれコンパイルタイミングを指定する情報を設定し、
該コンパイルタイミングを指定する情報に基づいて、該メソッドをネイティブコードにコンパイルする、
ことを特徴とする処理方法。
【請求項１４】
アプリケーションプログラムの実行に際して動的コンパイルをコンピュータに行わせるプログラムであって、
該コンピュータに、
該アプリケーションプログラムをインタプリタによって実行する際、該アプリケーションプログラムの実行性能に関する情報を取得させ、
該実行性能に関する情報に基づいて、該アプリケーションプログラムに含まれる各メソッドについて、それぞれコンパイルタイミングを指定する情報を設定させ、
該コンパイルタイミングを指定する情報に基づいて、該メソッドをネイティブコードにコンパイルさせる、
ことを特徴とするプログラム。
【請求項１】
プログラムの実行に際して動的コンパイルを行うアプリケーションサーバであって、
該プログラムをインタプリタによって実行する際、該プログラムの実行性能に関する情報を取得する実行性能情報取得部と、
該実行性能に関する情報に基づいて、該プログラムに含まれる各メソッドについて、それぞれコンパイルタイミングを指定する情報を設定するコンパイルタイミング情報設定部と、
該コンパイルタイミングを指定する情報に基づいて、該メソッドをネイティブコードにコンパイルする動的コンパイル部と、
を備えることを特徴とするアプリケーションサーバ。
【請求項２】
前記実行性能情報取得部は、
前記プログラムの実行性能の安定前と実行性能の安定後の性能差、および、実行性能が安定するまでの期間についての情報を取得する安定前後情報取得部と、
コンパイル処理の集中期間、および、コンパイル処理の集中度についての情報を取得する集中情報取得部と、
各メソッドの実行頻度、および、各メソッドの重要度の情報を取得するメソッド情報取得部と、
を備えることを特徴とする請求項１に記載のアプリケーションサーバ。
【請求項３】
前記実行性能の安定前の時点は、前記プログラムの起動完了時点であり、前記実行性能の安定後の時点は、動的コンパイルによるコンパイル数の揺らぎが所定値以下となる時点であることを特徴とする請求項２に記載のアプリケーションサーバ。
【請求項４】
前記実行性能の安定前と実行性能の安定後の性能差は、前記プログラムの平均レスポンス時間の差であることを特徴とする請求項２に記載のアプリケーションサーバ。
【請求項５】
前記コンパイル処理の集中度は、単位時間当たりに行なわれたコンパイル処理の数に基づいたメソッドの分類を示すことを特徴とする請求項２に記載のアプリケーションサーバ。
【請求項６】
前記コンパイル処理の集中期間は、コンパイル処理数の計測の開始から、前記単位時間当たりに行なわれたコンパイル処理の数の変動の割合が所定値以下となるまでの期間であることを特徴とする請求項５に記載のアプリケーションサーバ。
【請求項７】
前記各メソッドの実行頻度は、単位時間当たりにそれぞれのメソッドを実行した回数であり、前記各メソッドの重要度は、該メソッドを実行した回数に基づいた各メソッドの分類を示すことを特徴とする請求項２に記載のアプリケーションサーバ。
【請求項８】
前記コンパイルタイミング情報設定部は、実行性能の安定前と実行性能の安定後の性能差、コンパイル処理の集中度、各メソッドの重要度、（実行性能が安定するまでの期間）÷（コンパイル処理の集中期間）によって求められるコンパイル集中期間影響率を基に、メソッドごとにコンパイルタイミング調整係数を決定し、所定値に該コンパイルタイミング調整係数を乗算して、前記コンパイルタイミングを指定する情報を設定することを特徴とする請求項２に記載のアプリケーションサーバ。
【請求項９】
前記実行性能の安定前と実行性能の安定後の性能差が大きいほど、前記コンパイルタイミング調整係数を小さくすることを特徴とする請求項８に記載のアプリケーションサーバ。
【請求項１０】
前記コンパイル処理の集中度が小さいほど、前記コンパイルタイミング調整係数を小さくすることを特徴とする請求項８に記載のアプリケーションサーバ。
【請求項１１】
前記各メソッドの重要度が重要なほど、前記コンパイルタイミング調整係数を小さくすることを特徴とする請求項８に記載のアプリケーションサーバ。
【請求項１２】
前記コンパイル集中期間影響率が大きいほど、前記コンパイルタイミング調整係数を小さくすることを特徴とする請求項８に記載のアプリケーションサーバ。
【請求項１３】
プログラムの実行に際して動的コンパイルを行うアプリケーションサーバの処理方法であって、
該アプリケーションサーバは、
該プログラムをインタプリタによって実行する際、該プログラムの実行性能に関する情報を取得し、
該実行性能に関する情報に基づいて、該プログラムに含まれる各メソッドについて、それぞれコンパイルタイミングを指定する情報を設定し、
該コンパイルタイミングを指定する情報に基づいて、該メソッドをネイティブコードにコンパイルする、
ことを特徴とする処理方法。
【請求項１４】
アプリケーションプログラムの実行に際して動的コンパイルをコンピュータに行わせるプログラムであって、
該コンピュータに、
該アプリケーションプログラムをインタプリタによって実行する際、該アプリケーションプログラムの実行性能に関する情報を取得させ、
該実行性能に関する情報に基づいて、該アプリケーションプログラムに含まれる各メソッドについて、それぞれコンパイルタイミングを指定する情報を設定させ、
該コンパイルタイミングを指定する情報に基づいて、該メソッドをネイティブコードにコンパイルさせる、
ことを特徴とするプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９Ａ】
【図１９Ｂ】
【図２０】
【図２１】
【図２２】
【図２３Ａ】
【図２３Ｂ】
【図２４】
【図２５Ａ】
【図２５Ｂ】
【図２５Ｃ】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９Ａ】
【図１９Ｂ】
【図２０】
【図２１】
【図２２】
【図２３Ａ】
【図２３Ｂ】
【図２４】
【図２５Ａ】
【図２５Ｂ】
【図２５Ｃ】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【公開番号】特開２０１３−１０５４６４（Ｐ２０１３−１０５４６４Ａ）
【公開日】平成２５年５月３０日（２０１３．５．３０）
【国際特許分類】
【出願番号】特願２０１１−２５１１２７（Ｐ２０１１−２５１１２７）
【出願日】平成２３年１１月１６日（２０１１．１１．１６）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２５年５月３０日（２０１３．５．３０）
【国際特許分類】
【出願日】平成２３年１１月１６日（２０１１．１１．１６）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]