JPH11272476A - バイトコードされたプログラムを動的に最適化するための方法及び装置 - Google Patents

Abstract

(57)【要約】 【課題】 ランタイム中にソフトウェアアプリケーショ
ン最適化用に、コードの部分を解釈或いはコンパイルす
べきかを動的に決定する方法及び装置を提供する。 【解決手段】 複数の方法として構成されたバイトコー
ドを含むコンピュータプログラムのランタイム処理のた
めのコンピュータ実現方法は、複数の方法から選択され
た第１の方法を呼び出すことを含む。第１の選択方法の
呼出は、第１の選択方法の解釈を伴う。第１の選択方法
の呼出の数を追跡するように構成された呼出トラッカが
更新され、呼出トラッカがいつ、第１の選択方法の呼出
の数はしきい値を超えた旨を表示するか、に関する決定
が行なわれる。第１の選択方法がコンパイルされるの
は、呼出トラッカが第１の選択方法の呼出の数がしきい
値を超えた旨表示している、と決定されたときである。
このしきい値は、コンパイルオーバヘッドと解釈オーバ
ヘッドとを許容レベルに維持するために定期的に調節さ
れる。

Description

【発明の詳細な説明】

【０００１】

【発明の背景】１． 発明の分野 本発明は一般的に、ソフトウェアアプリケーションの実
行を最適化するための方法及び装置に関する。より詳細
には、本発明は、ランタイム中にソフトウェアアプリケ
ーションを最適化するために、コードの部分を、解釈す
べきか、コンパイルすべきかを動的に決定するための方
法及び装置に関する。 ２． 関連技術の説明 コンピュータシステムのネットワーク、例えばローカル
エリアネットワーク、イントラネット、及びインターネ
ット全体にわたってリソースを共有するコンピュータシ
ステムの使用が増加している。従って、特定コンピュー
タシステムは一般に、ソフトウェアアプリケーションが
その特定コンピュータシステムに固有のフォーマットを
取るように要求するという事実によって、ソフトウェア
アプリケーション、つまりコンピュータプログラムは、
異なるコンピュータシステムには異なるフォーマットで
与えられる（deliver）だろう。それとは別に、コンピ
ュータプログラムは、一つの形式のコンピュータプログ
ラムを多くの異なるコンピュータシステムによって利用
できるようにするために、機械独立の形で、すなわちバ
イトコードとしてコンピュータシステムに提供されるだ
ろう。

【０００２】コンピュータプログラムが機械独立の形で
与えられる（deliver）と、プログラムは直接解釈され
るか、或いは機械独立コード、すなわち「機械コード」
に翻訳されるであろう。直接に解釈されるプログラム
は、機械コードに翻訳されるプログラムよりもコンピュ
ータシステム内で占めるスペースが少ない。しかしなが
ら、直接に解釈されるプログラムは機械コードに翻訳さ
れるプログラムよりも、大抵の場合、実行速度が遅い。
従って、コンピュータプログラムを機械コードに翻訳す
る代わりにコンピュータプログラムを直接に解釈すべき
か否かの決定は、実行速度に対するスペースの相対的な
重要性によることが多い。

【０００３】上述のように、コンピュータプログラムは
コンピュータシステムにバイトコードとして与えられる
であろう。バイトコードを受信するコンピュータシステ
ムは一般に、ランタイムでバイトコードをコンパイルす
るために使用されるコンパイラを含む。ランタイムでバ
イトコードをコンパイルするには、そのバイトコードを
機械コードに翻訳する必要がある。図１（ａ）は、バイ
トコードコンパイラを持つコンピュータシステムのブロ
ック線図を示す。コンピュータプログラムとして構成さ
れるバイトコード１０４は、コンピュータシステム１０
５に与えられるか、別途に供給される。バイトコード１
０４は一般に様々なソースによって供給できる。バイト
コード１０４が実行されるときは、バイトコード１０４
はコンパイラ１０６を使ってランタイムでコンパイルさ
れる。コンパイラ１０６によって作成されるコンパイル
ド(compiled)コード１０８は一般に、システム１０５に
固有でシステム１０５内で実行可能な機械依存コードで
ある。すなわち、コンパイラ１０６はバイトコード１０
４をランタイムでコンパイルドコード１０８に翻訳す
る。

【０００４】コンピュータシステムの中には、先にコン
パイルされたコードの部分を、それらの部分が繰り返し
実行されることが判った場合に、より効率的に実行され
る形にリコンパイルできるものがある。言い換えれば、
第２の、より高価なコンパイルプロセスを使って、繰り
返し呼び出される、先にコンパイルされたコードをコン
パイルして、繰り返し呼び出されるコードをより効率的
に実行することが可能である。図１（ｂ）は、２つのコ
ンパイルプロセスを使用するコンピュータシステムのブ
ロック線図を示す。コンピュータシステム１１５は第１
のコンパイラ１１６と第２のコンパイラ１２２とを含
む。バイトコード１１４が実行のためにコンピュータシ
ステムに供給される。ランタイムで、第１のコンパイラ
１１６によってバイトコード１１４が機械依存コンパイ
ルドコード１１８、すなわち機械コードに翻訳される。

【０００５】機械依存コンパイルドコード１１８が実行
されて、機械依存コンパイルドコード１１８内に含まれ
る異なる方法が追跡され、最も頻繁に呼び出される方法
を第２のコンパイラ１２２でいつコンパイルすべきかを
決定する。高度に、又は繰り返し実行されるコンパイル
ドコード１２０が識別されると、その高度に実行される
コンパイルドコード１２０は、コンピュータプログラム
の全体的実行速度を増加させるためにリコンパイルされ
る。このように、第２のコンパイラ１２２は、高度に実
行されるコンパイルドコード１２０を、リコンパイルさ
れた高度に実行されるコード１２４に翻訳する。

【０００６】第２のコンパイラ１２２はしばしば、第１
のコンパイラ１１６よりも遅いコンパイラだが、第２の
コンパイラ１２２を使ってコンパイルされるコードは通
常、第１のコンパイラ１１６を使ってコンパイルされる
コードよりも効率的に実行される。従って、高度に実行
されるコンパイルドコード１２０をいつリコンパイルす
べきかの決定は一般に、全ランタイムに対する追加のコ
ンパイルオーバヘッド(compilation overhead)とリコン
パイルされた高度に実行されるコード１２４によって与
えられる効率改善の間のトレードオフを含む。

【０００７】効率を増大にするために、先にコンパイル
されたコードのリコンパイルが可能なシステムの一つ
は、先にコンパイルされたコードをリコンパイルすべき
か否かの決定が、方法等のコンパイルドコードの特定部
分が何回コールされたかに基づいて行なわれることを必
要とする。方法が一定の限界値よりも頻繁に呼び出され
た場合は、その方法はリコンパイルされる。一定の限界
値は本質的に一定のしきい値であり、それは、実行の効
率を増加させるために方法がリコンパイルされる前に、
その方法を呼び出すべき回数を反映している。

【０００８】コンパイラを使ってランタイムでバイトコ
ードを機械依存コードに翻訳するときは、かなりのコン
パイルオーバヘッドが、しばしばプログラムの全実行に
追加される。従って、機械コードは解釈されたコードよ
りはるかに速く実行するかもしれないが、機械コードを
実行する前にプログラムのすべての部分を機械コードに
コンパイルすることは、実行速度の増加がプログラムの
コンパイルに伴うオーバヘッドを補償しない場合、必ず
しも望ましくないだろう。言い換えれば、プログラムの
コンパイルに費やされる時間の量がプログラムの実行中
に回復されないときは、プログラムは解釈されたコード
として、より迅速に実行するかもしれない。

【０００９】上述の既存のシステムでは、コンパイルさ
れたプログラムの中のルーチンのリコンパイルはプログ
ラムをより効率的に実行可能にするために役立つかもし
れないが、ルーチンをいつリコンパイルすべきかを決定
するための一定の限界の使用は、その反対に、非効率
な、例えば非最適の実行をもたらすかもしれない。例と
して、プログラム中の実質上すべてのルーチンがリコン
パイルされるように一定の限界がセットされた場合は、
リコンパイル(re-compilation)によって得られた実行速
度の増加はリコンパイルに伴うコンパイルオーバヘッド
を補償しないかもしれない。

【００１０】従って、必要なことはバイトコードフォー
マットでプログラムを効率的に実行するための方法であ
る。より具体的には、望ましいことは、コンピュータプ
ログラムの部分を解釈すべ時と、コンピュータプログラ
ムの部分を機械コードに翻訳すべき時を動的に決定する
ことによって、コンピュータプログラムの効率的な実行
を保証するための方法である。

【００１１】

【発明の概要】ランタイム中にソフトウェアアプリケー
ションを最適化するためにバイトコードの部分を解釈す
べきか、コンパイルすべきかを動的に決定するための方
法及び装置が開示される。本発明の一局面によれば、選
ばれた方法が呼び出されると、それが最初に解釈され
る。呼出トラッカ(invocation tracker)が、選ばれた方
法の呼出の数を追跡する。選ばれた方法の呼出の数がし
きい値を超えると、その方法がコンパイルされる。各種
方法その他のコードセグメントの使用を独立に追跡する
ことによって、どの方法をコンパイルすべきか、及びど
の方法を解釈状態で残すべきかに関して、より賢明な決
定を行なうことができる。実施形態の中には、すべての
方法に対して単一のしきい値を使用するものがある。ま
た他の実施形態では、各しきい値が一つ以上の方法に関
連した状態で複数のしきい値が使用される。後者の構成
では、異なる方法に関連するしきい値を変更することが
できる。

【００１２】本実施形態の別の局面では、特定方法のコ
ンパイルに伴うオーバヘッドが測定される。オーバヘッ
ドは次に、許容オーバヘッドパラメータと比較されて、
そのオーバヘッドが許容範囲内にない場合は、その特定
方法のコンパイルを引き起こすしきい値が調節される。
本発明のこの局面は、方法の初期コンパイル及び／又は
方法のリコンパイルに適用できる。

【００１３】本発明の更に別の局面によれば、複数の方
法として構成されたバイトコードを実行するためのコン
ピュータシステムは、各種方法を解釈するのに適したイ
ンタープリタと、選ばれた方法の解釈をカウントする追
跡メカニズムとを含む。追跡メカニズムを用いて、選ば
れた方法がいつコンパイルに適するかが決定される。コ
ンピュータシステムは更に、各種方法をコンパイルする
のに適したコンパイラを含む。一実施形態では、コンピ
ュータシステムは、選ばれた方法がいつコンパイルに適
するかを、追跡メカニズムと協力して決定するしきい調
節メカニズムを含む。別の実施形態では、コンピュータ
システムは更に、選ばれた方法の呼出を、それがコンパ
イルされた後でカウントすると共に、その選ばれた方法
がいつリコンパイルに適するかの決定に使用される別の
追跡メカニズムを含む。

【００１４】本発明のこれらとその他の利点は、下記の
詳細説明を一読して各種の図面を検討することによって
明らかになるであろう。

【００１５】本発明は添付の図面に関してなされる下記
説明を参照することによって充分に理解されるであろ
う。

【００１６】

【発明の実施の形態】バイトコード化された(byte-code
d)コンピュータプログラムがコンピュータシステムに提
供されると、そのプログラムは直接に解釈されるか、プ
ログラムは実行のためにランタイムで機械コードに翻訳
することができる。直接に解釈されるプログラムは一般
に、機械コードに翻訳されるプログラムよりも占拠する
コンピュータメモリが少ない。他方、機械コードに翻訳
されるプログラムは通常、直接に解釈されるプログラム
より実行速度が速い。しかしながら、場合によっては、
コンパイラを使って機械コードを生成するときにプログ
ラムの全ランタイムに追加されるコンパイルオーバヘッ
ドは、必ずしもそのプログラムの実行中に回収されな
い。これらの場合、プログラムを直接に解釈する方がよ
り速く、より効率的なことが判明するかもしれない。一
般に、プログラムがより効率的に実行されるのは、それ
が直接に解釈される場合なのか、機械コードに翻訳され
る場合かの決定は難しい。従って、プログラムは可能で
ある最も迅速、又は最も効率的な方法で実行されないこ
とも多い。

【００１７】バイトコード化されたコンピュータプログ
ラムの直接的な解釈と機械コードへの翻訳の両者を許す
ことは、純粋に解釈されたプログラムで得られる実行速
度に比べて、コンピュータプログラムの実行速度を増加
させる。解釈されたコードと機械コード、例えばコンパ
イルドコードの混合は、機械コードのみの実行に伴うメ
モリ要件も明らかに減少させる。このように、解釈され
たコードとコンパイルドコードの混合はプログラム実行
の効率を増加させる。

【００１８】バイトコード化されたプログラム内の各方
法をモニタして、方法のコンパイルがプログラムの全実
行に対して有益になるか否かを決定することができる。
一実施形態では、方法のモニタは、方法が、解釈された
方法として呼び出される回数の追跡を伴う。解釈された
方法の呼出しが、その方法が、コンパイルされた場合に
コンパイルコストを回収する可能性があることを示すレ
ベル、つまり、しきい値に達すると、その方法が動的に
コンパイルされる。プログラム中の方法のコンパイルに
伴うコンパイルオーバヘッドが許容レベルに維持される
ことを本質的に保証するために、プログラムのコンパイ
ルオーバヘッドと解釈オーバヘッドの両者がモニタされ
る。コンパイルオーバヘッドが高すぎると見なされると
きは、コンパイルされる方法の数を削減することによっ
てコンパイルオーバヘッドを低くするための調節ができ
る。行なわれる調節は、解釈された方法をいつコンパイ
ルすべきかの決定に用いられるしきい値を上げることを
含む。適合しきい値(adaptive threshold)の修正を許す
ことによって、バイトコード化されたプログラムの実行
を実質的に最適化できる。言い換えれば、解釈されたコ
ードと動的にコンパイルされたコードの混合を調節する
ことによって、より少ない実行時間、ならびにプログラ
ムによって占められるメモリスペースの量とプログラム
の実行速度間のより良いバランスを達成できる。

【００１９】図２（ａ）に関して、バイトコードをいつ
動的にコンパイルすベきかを適合しきい値を用いて決定
するコンピュータシステムを、本発明の実施形態に従っ
て説明する。バイトコード１４４は、コンピュータシス
テム１４６への入力としてランタイムで供給される。機
械独立のコンピュータプログラムとして編成されるバイ
トコード１４４は通常、方法又はルーチンとして構成さ
れる。一実施形態では、バイトコード１４４は、バーチ
ャルマシン内のコンパイルタイム環境によって同一バー
チャルマシン内のランタイム環境、例えばコンピュータ
システム１４６へ供給できる。本発明が実現される適当
なバーチャルマシンの一つを、図１１に関して以下によ
り詳しく説明する。

【００２０】バイトコード１４４がコンピュータシステ
ム１４６に供給されると、バイトコード１４４はインタ
ープリタ１４８で処理することができる。それとは別
に、バイトコード１４４をコンパイラ１５０によってコ
ンパイルしてコンパイルドコードを作成することもでき
る。バイトコード１４４は一般に、インタープリタ１４
８とコンパイラ１５０の両者に実質上直接に入力しても
よいが、記載の実施形態では、バイトコード１４４は処
理のためにインタープリタ１４８のみに供給される。バ
イトコード１４４の処理に関連するステップを、図２
（ｂ）に関して以下に説明する。

【００２１】方法が呼び出される度に、その方法に関連
するバイトコード１４４がインタープリタ１４８を使っ
て解釈される。記載の実施形態では、方法が何回解釈さ
れるかの手段が維持される。任意の適当な手段を使っ
て、方法が何回解釈されるかを追跡することができる。
適当な手段は、それに限定されないが、方法が解釈され
る回数をカウントするために使用されるカウンタであ
る。そのようなカウンタは、方法が解釈される度にカウ
ンタが増分されるように、方法の中に実現できる。

【００２２】方法が解釈される回数がしきい値、すなわ
ち限界値を超えると、コンパイラ１５０を使ってその方
法をコンパイルできる。頻繁に実行されるコード１５８
に含まれる方法の繰り返しの解釈は、解釈されたバイト
コード１５４が一般にコンパイルドコードよりも実行が
遅いか効率が劣るので、非効率かもしれない。頻繁に実
行されるコード１５８のコンパイルは、方法のコンパイ
ルによって得られる時間の節約がコンパイルプロセスに
伴うコンパイルオーバヘッドを補償する可能性があるの
で、一般に、頻繁実行コード１５８に組み込まれた方法
のより効率的な実行を可能とするであろう。

【００２３】一般に、大抵のコンピュータプログラムの
実行では、繰り返し実行される方法もあれば、実行頻度
の少ない方法もある。頻繁に実行されるコード１５８は
一般に、プログラムの実行の重要部分を占める方法を含
むコードのセクションとして識別できる。頻繁実行(fre
quently executed) コード１５８がコンパイラ１５０に
よってコンパイルされると、頻繁実行コード１６２のコ
ンパイルド版が作成される。従って、コンパイルされた
頻繁実行コード１６２内に含まれる方法が呼び出される
と、そのコンパイルされた方法が呼び出される。一実施
形態では、頻繁実行コード１５８は、全実行タイムの実
質的に５０％以上、例えば全実行時間のほぼ９０％の割
合を占める方法のグループを含む。

【００２４】コンピュータシステムの中には単一レベル
のコンパイルを含むものもあれば、複数レベルのコンパ
イルを含むものもある。多重レベルのコンパイルを含む
コンピュータシステムをアレンジすることによって、コ
ンパイルされた方法を、その方法のリコンパイルが方法
に伴う実行効率を増加させると決定されたときにリコン
パイルできる。例として、コンパイラ１５０を使って達
成される第１のレベルのコンパイルは、「中間」レベル
のコンパイルに関係させることができる。中間レベルの
コンパイルをアレンジすることによって、バイトコード
を、そのバイトコードを解釈することよりも効率的だ
が、「最終」レベルのコンパイルほど効率的でないかも
しれないコンパイルド形式にコンパイルできる。中間レ
ベルのコンパイルは、コンパイル速度に関して、中間的
にコンパイルされた方法の実行に伴う一部の実行効率を
本質的に犠牲にするかもしれない。それに対して最終レ
ベルのコンパイルは、よい長いコンパイルタイムを伴う
かもしれないが、より効率的な実行となる。

【００２５】一実施形態では、追跡メカニズムを使用し
て、最も頻繁に実行される、コンパイルされた頻繁実行
コード１６２に含まれる方法を識別できる。言い換えれ
ば、コンパイルされた頻繁実行コード１６２内で、高度
に実行されるコンパイルドコード１６６を識別できる。
高度に実行されるコンパイルドコード１６６内の方法が
実行される回数がしきい値を超えると、高度に実行され
るコンパイルドコード１６６が追加コンパイラ１７０を
使ってリコンパイルされて、高度に実行されるコード１
７４のコンパイルド版が作成される。言うまでもなく、
追加コンパイラ１７０はコンパイラ１５０とは異なるコ
ンパイラでよい。その他に、コンパイラ１７０とコンパ
イラ１５０は、異なるパラメータで実現された実質的に
同一のコンパイラでもよい。これまで２つのレベルのコ
ンパイルのみを説明したが、システム１４６は一般に、
任意数のレベルのコンパイルを含むことができる。

【００２６】図２（ｂ）は、本発明の実施形態による、
バイトコード、（例えば機械独立コンピュータプログラ
ム）の処理に関連するステップを示すプロセス流れ線図
である。プロセス２０２は、しきい値モニタが起動され
るステップ２０４で始まる。しきい値モニタは、以下に
説明するように、コンピュータプログラムと同時に実行
して、特定方法を、その方法のコンパイルが考慮される
前に、実行すべき回数を示すしきい値を追跡する。しき
い値モニタの一実施形態を図７に関して以下に説明す
る。

【００２７】ステップ２０６では、図３に関して以下に
説明するように、バイトコードから成るコンピュータプ
ログラムが実行れる。コンピュータプログラムが実行さ
れた後、バイトコードを処理する方法が完了する。言う
までもなく、記載の実施形態では、しきい値モニタとプ
ログラムは、実質上同時に、すなわち並列プロセスとし
て実行される。言い換えれば、ステップ２０４とステッ
プ２０６は本質的に並列に実行される。

【００２８】次に図３を参照して、プログラムの実行に
関連するステップを本発明の実施形態に従って説明す
る。すなわち、図２（ｂ）のステップ２０６について説
明する。ステップ３０８で、しきい値が初期化される。
一実施形態では、しきい値は、特定方法を、その方法の
コンパイルが考慮される前に、実行すべき回数を示す上
限しきい値である。しきい値は一般に、特定システムの
要件、例えばメモリ要件や性能要件によって大幅に変更
できる。例として、しきい値は約１０００〜１０，００
０の範囲になるように初期化できる。

【００２９】一実施形態では、プログラム実行に伴うす
べての方法に対して単一のしきい値しか存在しないかも
しれない。すなわち、しきい値はグローバル定数かグロ
ーバル変数かもしれない。しかしながら、他の実施形態
では、言うまでもないことだが、多重しきい値が存在す
る、例えばしきい値は、方法固有の定数か方法固有の変
数かもしれない。

【００３０】しきい値がステップ３０８で初期化された
後、実行カウンタを持たない方法を含む解釈されたコー
ドがロードされて、ステップ３１２で、実行カウンタが
その方法に追加される。言い換えれば、方法が割り当て
られて、カウンタがその新しく割り当てられた方法に追
加される。一旦、カウンタが追加されると、ステップ３
１６で、新割当て方法の中のカウンタが初期化、例えば
ゼロにセットされる。

【００３１】ステップ３１６から、プログラムの流れは
ステップ３２０に進み、そこで、ロードされたコードの
方法が、コードの実行が完了するか或いはロードされた
コード内の実質上すべての適切な方法が実行されるま
で、実行される。コードの実行中、制御の流れは、先に
ロードされなかった方法に到達するかもしれないが、そ
の場合、そのコードは、当業者の承知するように、動的
にロードされるだろう。方法Ｍの実行に関連するステッ
プを、図４に関して以下により詳しく説明する。コード
の実行の過程で、ロードすべき解釈されたコードが更に
存在するか否かに関する決定がステップ３２４で行なわ
れる。追加の解釈されたコードをロードすべきであると
決定された場合、プロセスの流れは、追加コードがロー
ドされるステップ３１２へ戻る。それとは別に、ロード
すべき追加の解釈されたコードは存在しないと決定され
た場合、ステップ３２０でコードの実行が継続する。

【００３２】図４は、本発明の実施形態による方法の実
行に関連するステップ、すなわち図３のステップ３２０
を説明するプロセス流れ線図である。方法Ｍの実行はス
テップ４０４で開始され、そこで方法Ｍ用のカウンタ、
すなわち実行カウンタが増分される。カウンタが増分さ
れた後、方法Ｍ用カウンタはステップ４０８でしきい値
と比較される。上述のように、しきい値は、方法Ｍの可
能なコンパイルが考慮される前に方法Ｍが何回実行され
るかに関する表示である。

【００３３】ステップ４１２では、方法Ｍ用カウンタが
しきい値を超えるか否かについての決定が行なわれる。
方法Ｍ用カウンタがしきい値を超えない場合は、方法Ｍ
をコンパイルする必要がないことを示す。従って、プロ
セスの流れはステップ４１２からステップ４１６に移
り、そこで方法Ｍがインタープリタによって実行され
る。代わりに、ステップ３１２でＭ用カウンタがしきい
値を超えると決定された場合は、全プログラムの実行
は、方法Ｍが解釈ではなく、コンパイルされるとすれ
ば、より効率的になることを示す。このように、方法Ｍ
用カウンタがしきい値を超えると決定されたときは、リ
コンパイラがステップ４２０で実行される。リコンパイ
ラの実行に関連するステップを、図５に関して以下に更
に詳しく説明する。

【００３４】リコンパイラがステップ４２０で実行され
た後、プロセスの流れはステップ４２４に進み、そこで
方法Ｍがコンパイルされるか否かに関する決定が行なわ
れる。すなわち、ステップ４２０でのリコンパイラの実
行の結果として方法Ｍがコンパイルされたか否かに関す
る決定が行なわれる。方法Ｍがコンパイルされていない
と決定された場合、プロセスの流れはステップ４１６に
移り、方法Ｍが解釈を介して実行される。ステップ４２
４で、方法Ｍがコンパイルされていると決定された場
合、そのコンパイルされた方法Ｍ用のコードがステップ
４２８で実行される。

【００３５】上述のように、一実施形態では、リコンパ
イラを使ってコンパイラが所定の方法、例えば方法Ｍを
どのように処理するかが決定される。このようなリコン
パイラをアレンジすることによって、コンパイルが全プ
ログラムの実行に対して有益であろうと決定された場合
に、コンパイラを実際にコールして方法Ｍをコンパイル
できる。図５は、本発明の実施形態による、リコンパイ
ラの実行に関連するステップ、すなわち図４のステップ
４２０を示すプロセス流れ線図である。リコンパイラの
実行はステップ５０４で始まり、そこで方法Ｍのダイレ
クトコーラーに対する探索が行なわれる。一般に、コー
ラー、すなわち方法Ｍをコールした方法の探索は、当業
者の承知するように、コールスタックの検査を伴う。

【００３６】方法Ｍのコーラーを探索した後、ステップ
５０６で、方法Ｍ用のコーラーが存在するか否かが決定
される。方法Ｍ用のコーラーが存在すると決定された場
合、プロセスの流れはステップ５０８に進み、そこで全
プログラムに関連するコンパイラは方法Ｍをコーラーと
インライン(inline)するのか否かに関する決定が行なわ
れる。方法Ｍをコーラーにインラインすることは、方法
Ｍ用の解釈されたコードのコピーの作成と、コード、例
えば方法Ｍのコーラーからのパラメータや変数のパッセ
ージを含むコード、の不要な部分を除去した後の、コー
ラーへのコピーされたコードの組込みを伴う。コーラー
が繰り返し実行されることによって方法Ｍが繰り返し実
行される場合、又はコーラーが通常的に方法Ｍを繰り返
しコールする場合、コーラーへの方法Ｍのインライン(i
nlining)とコーラーのコンパイル(compiling) とは、全
プログラム実行の効率を増加させるのに役立つかもしれ
ない。しかしながら、コーラーへの方法Ｍのインライン
は、他の方法が方法Ｍをコールできるという事実によっ
て方法Ｍの非インライン版を排除しないので、方法Ｍは
その他の方法へアクセスできる状態を維持しなければな
らない。このように、プログラムに関連するコードの物
理量は方法Ｍがインラインされると増加するので、コー
ラーへの方法Ｍのインラインは全プログラム実行の効率
を必ずしも改善しないだろう。

【００３７】ステップ５０８で、コンパイラが方法Ｍを
コーラーとインラインするだろうと決定した場合、記載
の実施形態では、全プログラム実行の効率の改善が、特
別のプログラムコードの追加よりも本質的に勝ることを
示す。その結果、プロセスの流れはステップ５０８から
ステップ５１０に移り、そこでコンパイラへのコールが
行なわれて、方法Ｍをインラインすると共に、方法Ｍを
その中にインラインした状態で、方法Ｍのコーラーがコ
ンパイルされる。

【００３８】方法Ｍを方法Ｍのコーラーにインラインす
る決定は様々な要因を含む。例として、要因は、それら
に限定されないが、方法Ｍのサイズ、コーラーのサイ
ズ、方法Ｍとコーラーとに関連するパラメータの値、及
び方法Ｍをコールする方法の数を含む。一般に、言うま
でもないことだが、方法Ｍのインライン(inlining)は、
方法Ｍのコーラーへの、方法Ｍのインラインを含むばか
りでなく、コーラーのコーラーへ方法Ｍのコーラーをイ
ンラインすることも含むだろう。言い換えれば、コーラ
ーは任意数のレベルに対するスタックの中でルックアッ
プされるだろう。

【００３９】方法Ｍがインラインされてコーラーがコン
パイルされた後、コンパイルオーバヘッドがステップ５
１２で確認される。一般に、コンパイルオーバヘッドの
確認は、ランタイム中の方法のコンパイルに伴うオーバ
ヘッドのモニタを伴う。コンパイルオーバヘッドは次
に、望ましい最大コンパイルオーバヘッドに対して比較
される。望ましい最大コンパイルオーバヘッドは、一実
施形態では、ランタイム中の方法のコンパイルや、その
他、機械コードへの方法の翻訳に費やされる全システム
オーバヘッド、例えば中央処理装置（ＣＰＵ）や所用時
間の最大％の尺度かもしれない。従って、コンパイルオ
ーバヘッドを確認することは、ランタイムで方法をコン
パイルするために実際に使用されているシステムオーバ
ヘッドの量の決定を伴う。

【００４０】コンパイルオーバヘッドは望ましい最大コ
ンパイルオーバヘッドを超えるか否かに関する決定が、
ステップ５１４で行なわれる。コンパイルオーバヘッド
が望ましい最大コンパイルオーバヘッドを超えると決定
された場合は、コンパイルされている方法が多すぎるこ
とを意味し、プロセスの流れはステップ５１６に移り、
そこでしきい値が増加される。しきい値の増加は、方法
を、その方法のコンパイルが考慮される前に、呼び出す
ベき回数を増加させるので、通常、コンパイルオーバヘ
ッドの削減に有効である。例として、しきい値が１００
０に設定され、かつ実質上すべての方法がプログラム実
行の過程で少なくとも１０００回、呼び出される場合、
しきい値を１０，０００へ上げることは、コンパイルさ
れそうな方法が少なくなるので、より低いコンパイルオ
ーバヘッドをもたらすだろう。しきい値の増加に関連す
るステップを図６に関して以下により詳しく説明する。
一旦、しきい値がステップ５１６で増加されると、コン
パイラを実行するプロセスが完了する。

【００４１】ステップ５１４で、コンパイルオーバヘッ
ドが望ましい最大コンパイルオーバヘッドよりも少ない
と決定された場合、しきい値は許容可能と見なされる。
すなわち、方法のコンパイルとそのコンパイルされた方
法の実行に伴うオーバヘッドは許容レベルにある、と見
なされる。このように、リコンパイラの実行が完了す
る。

【００４２】ステップ５０８に戻って、全プログラムの
実行に関連するコンパイラは方法Ｍをコーラーとインラ
インしないだろう、と決定された場合、ステップ５１８
で、そのコンパイラが方法Ｍをコンパイルするためにコ
ールされる。方法Ｍのインラインなしの、方法Ｍの単な
るコンパイルは、一般に全プログラムに関連するコード
の量を削減する。前述のように、方法Ｍのインライン
は、本質的に方法Ｍのコピーの作成となる。その結果
は、方法Ｍが異なる方法によってコールされると、方法
Ｍは、結局、異なる方法の各々の中でインラインされる
ことになるだろう。従って、方法Ｍに関連するコードの
コピーは全プログラムにわたって増大して、インライン
されたコードのコンパイルに伴うコンパイルの量が有意
になるだろう。従って、一実施形態では、スペースを節
約すると共にコンパイルの量を削減するために、方法Ｍ
が２つ以上の方法によってコールされそうな場合、方法
Ｍをインラインするのではなく、方法Ｍを単にコンパイ
ルする。方法Ｍがステップ５１８でコンパイルされた
後、プロセスの流れはステップ５１２に移り、そこでコ
ンパイルオーバヘッドが確認される。方法Ｍが２つ以上
の方法によってコールされる可能性があるか否かの決定
は、当業者の承知するように、コールチェーンの調査を
伴う。

【００４３】方法Ｍ用のコーラーが存在するか否かを決
定するステップであるステップ５０６へ戻って、方法Ｍ
用のコーラーが存在しないか、或いはコーラーの探索中
に発見されなかったと決定された場合、プロセスの流れ
はステップ５１８に進み、そこで方法Ｍがコンパイルさ
れる。コーラーが発見されないときは、方法Ｍは、別の
方法によるのではなく、ランタイムシステムによってコ
ールされたことを示す。

【００４４】上述のように、プログラムの全実行に伴う
コンパイルオーバヘッドが希望最大オーバヘッドよりも
大きい場合は、しきい値を増加させることができる。こ
のような適合しきい値の使用は一般に、しきい値を、必
要に応じて特定アプリケーションに対して修正すること
を可能にする。多くの方法又は関数が一定の数の呼出し
を超えるアプリケーションでは、対応するしきい値が低
すぎる場合、結果は、効率、例えば時間とスペースに関
して望ましくないほど高いコンパイルオーバヘッドにな
るかもしれない。従って、より高いしきい値を設定する
ことが、より望ましい、すなわち、より低いコンパイル
オーバヘッドをもたらすだろう。

【００４５】プログラム実行の過程でしきい値を増すこ
とは、密に連続する方法のコンパイルの防止にもなるだ
ろう。例として、比較的多数の異なる方法が実質上同時
に特定しきい値を超える場合、全プログラムの実行中に
休止が起るかもしれない。プログラム実行中の休止は望
ましくない場合が多いので、最初の数方法をコンパイル
した後でしきい値を増加させると、密に連続するコンパ
イルのシーケンスを防ぎ、それによって明白なコンパイ
ルの休止を実質的に除去する。

【００４６】次に図６を参照して、しきい値の増加に関
連するステップを、本発明の実施形態に従って説明す
る。言い換えれば、図５のステップ５１６について説明
する。言うまでもなく、しきい値がグローバル値である
実施形態では、しきい値を増すことはグローバル値の増
加を伴う。そうではなく、しきい値が方法固有の値の場
合は、しきい値を増すことは特定方法や方法のグループ
に対するしきい値のみの増加を伴う。

【００４７】しきい値を増加させるプロセスはステップ
６０２で始まり、そこでしきい値がしきい限界(thresho
ld limit) 、すなわち上部しきい限界にあるか否かに関
する決定が行なわれる。しきい限界は、全プログラムの
要件に依存するが、一般に、許容可能と見なされるしき
い値に対する最高値である。

【００４８】しきい値がしきい限界にあるとステップ６
０２で決定された場合、記載の実施形態では、しきい値
を増加させることはできない。このように、しきい値を
増加させるプロセスは完了したと見なされる。例とし
て、既存システムでは、約１０００回の呼出し、ないし
約５０，０００回の呼出しのオーダーのしきい限界が適
当であろう。そうではなく、ステップ６０２でしきい値
はしきい限界にないと決定された場合。しきい値がカレ
ントタイム(current time)期間中に先に上方に調節され
ていたか否かについての決定が行なわれる。一実施形態
では、しきい値がカレントタイム期間中に先に調節され
たか否かの決定は、関連インターバル変更フラグが調節
は最近行なわれたことを示しているか否かの決定を含
む。インターバル変更フラグのセットとクリアのための
代表的メカニズムを以下に説明する。

【００４９】しきい値はカレントタイム期間中、例えば
最近の過去にすでに上方に調節されたとステップ６０４
で決定された場合、しきい値がそれ以上大きくされるこ
とはない。最近に調節されたときは、しきい値をそれ以
上増加させないことによって、しきい値を過度の調節か
ら守ることができる。しきい値をそれ以上増加させない
とステップ６０４で決定された場合、しきい値を増加さ
せるプロセスは完了したと見なされる。

【００５０】ステップ６０４で、しきい値はカレントタ
イム期間中に上方に調節されなかったと決定されたとき
は、プロセスの流れは６０６に移り、そこでしきい値に
しきい値係数が乗算される。しきい値係数は一般に、総
合コンピュータプログラムの要件によって大幅に変更で
きる。例として、約１．２ないし約２のオーダーのしき
い値係数が現行システムに対して良好に働くようだ。し
きい値にしきい値係数が掛けられてしきい値を増加させ
た後、インターバル変更フラグがステップ６０８でセッ
トされる。インターバル変更フラグを使って、しきい値
がカレントタイム期間中に上方に調節されたことを表示
できる。しきい値を増加させるプロセスは、インターバ
ル変更フラグがセットされた後に完了する。

【００５１】記載の実施形態では、図２（ｂ）に関して
上述したように、プログラムの実行の開始はしきい値モ
ニタの実行の開始と並列で起る。すなわち、プログラム
が実行している間、しきい値モニタも実行している。図
７は、本発明の実施形態による、しきい値モニタの実行
の開始に関連するステップ、すなわち図２（ｂ）のステ
ップ２０４を示すプロセス流れ線図である。しきい値モ
ニタの実行はステップ７０２で始まり、そこでタイマ信
号が、しきい値モニタによってオペレーティングシステ
ムから受信される。タイマ信号は本質的に、プログラム
の実行を周期的に中断するクロック「チック」である。
当業者の承知するように、しきい値モニタの実行は、タ
イマ信号が受信されるまで、中断、すなわち、しきい値
は「休眠(asleep)」できる。

【００５２】一旦、タイマ信号が受信されると、スライ
ディング(sliding)平均が、コンパイルオーバヘッドと
解釈オーバヘッドの両者に対してステップ７０４で更新
される。言い換えれば、所定期間、例えば最近の過去に
費やされた時間の量と解釈に費やされた時間の量は、そ
の期間のいくつかの時間間隔にわたって平均された期間
の％として表すことができる。

【００５３】インターバル変更フラグは、スライディン
グ平均が更新された後、ステップ７０６でリセットされ
る。インターバル変更フラグのリセットは一般に、しき
い値が所定期間中に調節されていないことを示すための
インターバル変更フラグのセッティングを伴う。インタ
ーバル変更フラグがリセットされた後、ステップ７０８
で、コンパイルオーバヘッドが最大希望コンパイルオー
バヘッドを超えるか否かに関する決定が行なわれる。コ
ンパイルオーバヘッドは、最小希望コンパイルオーバヘ
ッドと最大希望コンパイルオーバヘッドの間の範囲に入
るように維持することが望ましい。最小希望コンパイル
オーバヘッドと最大希望コンパイルオーバヘッドの値は
大幅に変更できるが、約５％ないし約２５％の範囲の最
小値と、約２０％ないし約６５％の範囲の最大値が一部
のシステムで良好に働くことが判明している。ある特定
実施形態では、最小希望コンパイルオーバヘッドは所定
期間の約１０％にすることができる一方、最大希望コン
パイルオーバヘッドは所定期間の約５０にできる。

【００５４】ステップ７０８で、コンパイルオーバヘッ
ドが最大希望コンパイルオーバヘッドよりも大きいと決
定された場合、プロセスの流れはステップ７１６に進
み、そこでしきい値、例えばグローバルしきい値を増加
させる。しきい値を増すために使用される一つの適当な
方法は図に関して先に説明した。一旦、しきい値が増加
すると、プロセスの流れはステップ７０２に戻り、そこ
でプロセスは、オペレーティングシステムから受信され
る新しいタイマ信号を待つ。

【００５５】ステップ７０８で、コンパイルオーバヘッ
ドが最大希望コンパイルオーバヘッドより小さいと決定
された場合、ステップ７１０で、コンパイルオーバヘッ
ドが最小希望コンパイルオーバヘッドより小さいか否か
に関する決定が行なわれる。コンパイルオーバヘッドが
最小希望コンパイルオーバヘッドより小さい場合、しき
い値は高すぎるかもしれない。このように、コンパイル
オーバヘッドが最小希望コンパイルオーバヘッドと最大
希望コンパイルオーバヘッドの間に入るようにするため
に、ステップ７１２でしきい値を減少させる。しきい値
の減少は、図８に関して以下に更に詳しく説明するが、
しきい値へのより迅速な到達を許すので、方法のコンパ
イルの増加をもたらす。従って、コンパイルオーバヘッ
ドを最小希望コンパイルオーバヘッドの上に増加させる
ことができる。しきい値が減じられた後、プロセスの流
れはステップ７０２に戻り、そこでしきい値モニタを実
行するプロセスが、タイマ信号を受信するまで本質的に
中断される。

【００５６】コンパイルオーバヘッドが最大希望解釈オ
ーバヘッドと最小希望解釈オーバヘッドの間にあると決
定されたときは、ステップ７１４で、解釈オーバヘッド
が最大希望解釈オーバヘッドより大きいか否かに関する
決定が行なわれる。解釈オーバヘッドを計算するための
一つの適当な方法を、図９に関して以下に説明する。

【００５７】最大希望コンパイルオーバヘッドの場合と
同様、最大希望解釈オーバヘッドも大幅に変更できる。
更に、最小希望解釈オーバヘッドも大幅に変更可能であ
る。例として、最大希望解釈オーバヘッドは所定期間の
約２０％にすることができる一方、最小希望解釈オーバ
ヘッドは所定期間の約５％にできる。一実施形態では、
希望解釈オーバヘッドは希望コンパイルオーバヘッドと
実質的に同一にできる。

【００５８】解釈オーバヘッドが最大希望解釈オーバヘ
ッドより大きい場合、図８に関して以下に説明するプロ
セスのような任意の適当なプロセスを使って、ステップ
７１２でしきい値を減少させる。しきい値の減少は一般
に、より多くの方法のコンパイルを可能にするので、解
釈される方法の数を削減する。それとは別に、解釈オー
バヘッドが最大希望解釈オーバヘッドより小さいと決定
された場合、ステップ７１８で、解釈オーバヘッドが最
小希望解釈オーバヘッドの下に来るか否かが決定され
る。解釈オーバヘッドが最小希望解釈オーバヘッドより
小さいときは、ステップ７１６でしきい値を減少させ
る。解釈オーバヘッドが最小希望解釈オーバヘッドと最
大希望解釈オーバヘッドによって定義される許容解釈オ
ーバヘッドの範囲内にある場合は、しきい値モニタを実
行するプロセスがステップ７０２で継続して、そこで新
タイマ信号がオペレーティングシステムから受信され
る。

【００５９】図８に関して、しきい値の減少に関連する
ステップ、すなわち図７のステップ７１２を本発明の実
施形態に従って説明する。しきい値を減少させるプロセ
スはステップ８０４で始まり、そこでしきい値が下方し
きい限界にあるか否かに関する決定が行なわれる。下方
しきい限界は一般に、しきい値として適切と見なされる
最低値である。例として、下方しきい限界は大幅に変更
可能だが、約１００カウントないし約１０００カウント
のオーダーの下方しきい限界が良好に働く。一実施形態
では、下方しきい限界は約５００カウント又は呼出しに
することができる。

【００６０】ステップ８０４で、しきい値が下方しきい
限界にあると決定された場合、しきい値を下げてはなら
ないことを意味し、しきい値を減少させるプロセスは完
了したと見なされる。そうではなく、ステップ８０４
で、しきい値が下方しきい限界にないと決定された場
合、ステップ８０８で、しきい値はカレント期間中に先
に下方に調節されていたか否かに関する決定が行なわれ
る。

【００６１】しきい値が最近の過去又はカレントタイム
期間に下方に調節されたと決定される場合は、記載の実
施形態では、しきい値をそれ以上減少させてはならな
い。所定期間に２回以上、しきい値の下方への調節を許
さないことで、しきい値の過剰な調節を避けることがで
きる。しきい値をそれ以上減少させるべきでないと決定
されたときは、しきい値を減少させるプロセスは完了し
たと見なされる。

【００６２】しきい値がカレントタイム期間中に下方に
調節されていない場合、プロセスの流れはステップ８０
８からステップ８１２に移り、そこでしきい値はしきい
値係数によって除算される。しきい値係数は一般に、総
合コンピュータプログラムの要件によって大幅に変更で
きる。一実施形態では、しきい値が除算されるしきい値
係数は、しきい値を増加させるときに乗数として用いら
れる、図６に関して上述した同一のしきい値係数であ
る。一旦、しきい値がしきい値係数によって除される
と、インターバル変更フラグがステップ８１６でセット
される。記載の実施形態では、インターバル変更フラグ
をセットして、しきい値がカレントタイム期間中に下方
に調節されたことを示す。インターバル変更フラグがセ
ットされた後、しきい値を減少させるプロセスは完了す
る。

【００６３】ランタイム中のプログラムに伴うコンパイ
ルオーバヘッドのモニタに加えて、プログラムに伴う解
釈オーバヘッドもモニタされる。解釈オーバヘッドのモ
ニタは本質的に、方法の解釈で費やされた全プログラム
オーバヘッドの量のモニタを含む。図７に関して前述し
たように、解釈オーバヘッドをモニタすることによっ
て、少なくとも部分的に、しきい値を上げるべきか下げ
るべきかが決定される。例えば、解釈オーバヘッドが高
すぎる場合は、より多くの方法をコンパイルすべきこと
を意味し、しきい値を減少させて、より多くの方法をコ
ンパイルさせることができる。

【００６４】一般に、任意の適当なプロセスを使って解
釈オーバヘッドを計算できる。解釈オーバヘッドを計算
するための一つの適当なプロセスを、図９に関して以下
に説明する。プロセスはステップ９０４で始まり、そこ
でタイマ信号がオペレーションシステムから受信され
る。一旦、タイマ信号が受信されると、アプリケーショ
ンプロセスのカレントプログラムカウンタがステップ９
０８で取得される。一実施形態では、プログラムカウン
タは、全プログラムの実行が現在、解釈されたコードを
含むか、或いはコンパイルドコードを含むかを識別する
リファレンスである。

【００６５】一旦、カレントプログラムカウンタが取得
されると、プログラムカウンタはステップ９１２でイン
タープリタをリファレンス、例えば指示、するか否かに
関して決定が行なわれる。すなわち、解釈されたコード
が現在、実行されているか否かについて決定が行なわれ
る。プログラムカウンタがインタープリタを指示してい
ないと決定された場合は、プログラムカウンタがコンパ
イラを指示していることを意味し、解釈オーバヘッドの
計算が完了する。ステップ９１２で、プログラムカウン
タはインタープリタをリファレンスしないと決定された
場合、インタープリタオーバヘッドカウンタがステップ
９１６で増分される。最後に、ステップ９１８で、解釈
オーバヘッドカウンタを用いて解釈オーバヘッド用のス
ライディング平均が計算され、解釈オーバヘッドを計算
するプロセスが完了する。

【００６６】図１０は、本発明の実現に適した典型的な
汎用コンピュータシステムを示す。コンピュータシステ
ム１０３０は、主記憶装置１０３４（通常、リードオン
リーメモリ、又はＲＯＭ）と主記憶装置１０３６（通
常、ランダムアクセスメモリ、又はＲＡＭ）とを含むメ
モリデバイスに連結された任意数のプロセッサ１０３２
（中央処理装置、又はＣＰＵとも称する）を含む。

【００６７】コンピュータシステム１０３０、又はより
具体的には、ＣＰＵ１０３２は、当業者の承知するよう
に、バーチャルマシンを支援するように構成できる。コ
ンピュータシステム１０３０上で支援されるバーチャル
マシンの一例を、図１１に関して以下に説明する。当技
術分野で周知のように、ＲＯＭはデータと命令をＣＰＵ
１０３２に一方向的に転送するように働くが、ＲＡＭは
通常、データと命令を二方向的に転送するように使用さ
れる。ＣＰＵ１０３２は一般に任意数のプロセッサを含
んでもよい。主記憶装置１０３４、１０３６は共に、任
意の適切なコンピュータ読取り可能媒体を含んでもよ
い。通常、マスメモリデバイスである二次記憶媒体１０
３８もＣＰＵ１０３２に二方向的に連結されて、追加の
データ記憶容量を提供する。マスメモリデバイス１０３
８は、コンピュータコード、データ等を含むプログラム
の格納のために使用されるコンピュータ読取り可能媒体
である。通常、マスメモリデバイス１０３８は、主記憶
装置１０３４、１０３６よりも一般に遅いハードディス
クやテープ等の記憶媒体である。マスメモリデバイス１
０３８は磁気かペーパーテープ読取り装置、又は何らか
の他の周知のデバイスの形を取ることができる。マスメ
モリデバイス１０３８内に保持された情報は、適切な場
合は、バーチャルメモリとしてのＲＡＭ１０３６の一部
として、標準的な方式で組込みできることは言うまでも
ない。ＣＤ−ＲＯＭ等の特定の主記憶装置１０３４も、
データを一方向的にＣＰＵ１０３２に渡すことができ
る。

【００６８】ＣＰＵ１０３２はまた、それらに限定され
ないが、ビデオモニタ、トラックボール、マウス、キー
ボード、マイクロホン、接触感知ディスプレイ、トラン
スデューサカードリーダ、磁気又はペーパーテープ読取
り装置、タブレット、スタイラス、音声又は手書き認識
装置、その他の周知の入力装置、例えば、勿論、他のコ
ンピュータといった装置を含む一つ以上の入出力装置１
０４０に連結される。最後に、ＣＰＵ１０３２はオプシ
ョンとして、１０１２で概略図示するネットワーク接続
を使って、コンピュータ又は遠隔通信ネットワーク、例
えばローカルエリアネットワーク、インターネットネッ
トワーク、又はイントラネットネットワークに連結して
もよい。このようなネットワーク接続を使って、ＣＰＵ
１０３２はネットワークから情報を受信したり、上述の
方法手段を実行する過程で情報を出力するであろうこと
が予期される。それらの情報は、ＣＰＵ１０３２を使っ
て実行される一連の情報として表されことが多いが、例
えば、搬送波に組み込まれたコンピュータデータ信号の
形でネットワークから受信されたり、ネットワークに出
力することができる。上述のデバイスと材料は、コンピ
ュータハードウェアとソフトウェアの分野の当業者には
周知であろう。

【００６９】前述のように、バーチャルマシンはコンピ
ュータシステム１０３０上で実行できる。図１１は、図
１０のコンピュータシステム１０３０によって支援され
て本発明の実現に適したバーチャルマシンの図式表示で
ある。コンピュータプログラム、例えばカリフォルニア
州Palo Alto のSun Microsystemsによって開発されたＪ
ａｖａ（商標）プログラミング言語で書かれたコンピュ
ータプログラムが実行されると、ソースコード１１１０
がコンパイルタイム環境１１０５内のコンパイラ１１２
０に供給される。コンパイラはソースコード１１１０を
バイトコード１１３０に翻訳する。一般に、ソースコー
ド１１１０は、それがソフトウェア開発者によって作成
される時点でバイトコード１１３０に翻訳される。

【００７０】バイトコード１１３０は一般に、再生、ダ
ウンロード、或いは別途にネットワーク、例えば図１０
のネットワーク１０１２を介して配信されるか、図１０
の主記憶装置１０３４等の記憶装置に格納される。記載
の実施形態では、バイトコード１１３０はプラットホー
ム独立形(platform-independent)である。すなわち、バ
イトコード１１３０は、適切なバーチャルマシン１１４
０を実行している実質的に任意のコンピュータシステム
で実行できる。例として、Ｊａｖａ（商標）環境では、
バイトコード１１３０はＪａｖａ（商標）バーチャルマ
シンを実行しているコンピュータシステム上で実行でき
る。

【００７１】バイトコード１１３０は、バーチャルマシ
ン１１４０を含むランタイム環境１１３５に供給され
る。ランタイム環境１１３５は一般に、図１０のＣＰＵ
１０３２等のプロセッサを使って実行できる。バーチャ
ルマシン１１４０はコンパイラ１１４２、インタープリ
タ１１４４、及びランタイムシステム１１４６を含む。
バイトコード１１３０は一般にコンパイラ１１４２かイ
ンタープリタ１１４４のいずれかに供給される。

【００７２】バイトコード１１３０がコンパイラ１１４
２に供給されると、バイトコード１１３０に含まれる方
法は、上述のように、機械命令にコンパイルされる。他
方、バイトコード１１３０がインタープリタ１１４４に
供給されると、バイトコード１１３０は一度に１バイト
ずつインタープリタ１１４４に読み取られる。インター
プリタ１１４４は次に、各バイトコードがインタープリ
タ１１４４に読み取られるに従って、各バイトコードに
よって定義されるオペレーションを実行する。一般に、
インタープリタ１１４４はバイトコード１１３０を処理
すると共に、バイトコード１１３０に関連するオペレー
ションを実質上連続的に実行する。

【００７３】方法がオペレーティングシステム１１６０
からコールされると、その方法を、解釈された方法とし
て呼び出すべきであると決定された場合、ランタイムシ
ステム１１４６はインタープリタ１１４４からその方法
を取得できる。他方、その方法、コンパイルされた方法
として呼び出すベきであると決定された場合、ランタイ
ムシステム１１４６はコンパイラ１１４６を活性化す
る。コンパイラ１１４２は次にバイトコード１１３０か
ら機械命令を生成すると共に、その機械語命令を実行す
る。一般に、機械語命令は、バーチャルマシン１１４０
が終了すると放棄される。

【００７４】本発明の実施形態をごく少数だけ説明した
が、本発明は、発明の精神と範囲から逸脱することな
く、他の多くの特定形式で具体化できることは言うまで
もない。例として、リコンパイラの実行に関連するステ
ップを再整理、除去、又は追加できる。更に、一部の実
施形態では、方法をその方法のコーラーへインラインす
るためのオプションを排除できる。一般に、本発明の方
法に関連するステップを、発明の精神と範囲から逸脱す
ることなく再整理、除去、又は追加できる。

【００７５】コンパイラの実行を、コンパイラが所定方
法をコンパイルするか否かの決定、及び所定方法のコン
パイルに関して説明したが、言うまでもなく、所定方法
のコンパイルは、その所定方法をコンパイルすべき旨の
決定の後で遅延できる。多重方法が実質上同時にコンパ
イルされている場合は、所定方法のコンパイルは、コン
パイルされている方法が少なくなるまで、例えばコンパ
イルオーバヘッドが最小希望コンパイルオーバヘッドの
下に来るまで遅延することができる。所定方法のコンパ
イルの遅延は、コンパイルオーバヘッドが最大希望コン
パイルオーバヘッドを超えないようにするのに役立つだ
ろう。更に、コンパイルの遅延は、プログラムの実行中
の比較的長いコンパイルの休止を防ぐためにも役立つだ
ろう。一実施形態では、プログラム内の方法のコンパイ
ルを、プログラムの全実行で休止が存在するまで遅延で
きる。そのような実施形態では、方法は、プログラムの
全実行の間の休止、又は活動の低い期間にアクセスされ
るキューの中に置くことができる。

【００７６】更に、本発明を、最初に解釈されるすべて
の方法に関して説明したが、言うまでもなく、バイトコ
ードの形のコンピュータプログラムがランタイム環境に
最初に供給されるときは、プログラムに関連する少なく
とも一部の方法を直ちにコンパイルできる。例えば、希
望コンパイルオーバヘッドが、実行の最初からプログラ
ムによって満たされるようにするために、一部の方法は
最初にコンパイルしてもよいが、他の方法は最初、解釈
された後、所定の解釈された方法の呼出しの数がしきい
値を超えた時点で、その所定の解釈された方法がコンパ
イルされる。

【００７７】図３に関して上述した、解釈された方法内
に置かれたカウンタは、一般に、方法内の任意の場所に
置いてもよいが、方法の実行中のカウンタへのアクセス
は高価になるかもしれない。従って、解釈された方法内
にカウンタを置いたときは、カウンタをより容易にカウ
ンタにアクセスできるように、方法の最初に置くことが
できる。実施形態の中には、方法内に置かれたカウンタ
へのアクセスに伴うコストのために、すべての方法に対
して単一のグローバルカウンタを使用できるものがあ
る。グローバルカウンタがそのしきい値に達したとき
は、あたかも現行方法がその呼出カウンタのしきい値に
達したかのように、現在実行中の方法のリコンパイルを
考慮することができる。

【００７８】一般に、カウンタは、そのカウンタを含む
方法を呼び出す間の任意の時点で増分できる。例えば、
カウンタは、方法内のループの後方分岐(backward bran
ch)が実行している間に増分できる。ループの後方分
岐、又はループ内の実質上任意の場所におけるカウンタ
の増分は、方法内のロングランニングループ(long runn
ing loop) の検出を容易にする。ロングランニングルー
プは、方法の単一の呼出しの間に繰り返し実行できる。
カウンタをループ内、例えばループの後方分岐内に置く
ことによって、ループの各繰り返しを方法の呼出しとし
てカウントできるので、大量の実行時間を利用す方法の
コンパイルをより容易に考慮できる。言うまでもないこ
とだが、方法の実行中の、方法のカウンタへのアクセス
は費用がかかるので、一部の実施形態では、ループ内の
カウンタが、方法内のカウンタよりも容易にアクセスさ
れる「グローバル」ループカウンタを増分することがで
きる。

【００７９】「ループカウンタしきい値」を使用する実
施形態では、ループカウンタしきい値は上述の呼出しき
い値とは異なるかもしれない。ループカウンタしきい値
も、異なるしきい値係数によって増減できる。しかしな
がら、一般に、ループカウンタしきい値は、呼出しきい
値と実質的にタンデムで調節されるだろう。

【００８０】カウンタを、方法内に置かれるものとして
一般的に説明した。しかしながら、当然のことながら、
カウンタを方法内に置く代わりに、カウンタを、方法が
呼び出される度にアクセスできるデータベース又はテー
ブル中に保持することもできる。その場合、データベー
ス、つまり更に具体的にはデータベース内のカウンタ
が、本発明の精神と範囲から逸脱することなく、特定カ
ウンタに対応する方法が呼び出される度に更新されるだ
ろう。

【００８１】一般に、本発明によるしきい値は大幅に変
更することができる。例えば、１０００のしきい値は一
部の実施形態に関しては充分かもしれないが、実質上す
べての方法が１０００回以上実行される実行では、それ
より高いしきい値が適当だろう。同様に、最大と最小の
希望コンパイルオーバヘッドも、最大と最小の希望解釈
オーバヘッドと共に、特定システムの要件によって大幅
に変更できる。

【００８２】しきい値の値は、様々な要因に基づいて選
択できる。上記の要因は、それに限定されないが、プロ
グラム実行の％を含む。言い換えれば、しきい値は、全
プログラム実行の所定％、例えば半分以上の割合を占め
る方法がコンパイルされるように選択できる。例とし
て、しきい値は、全プログラム実行の約９５％を占める
方法がコンパイルされるように調節できる。

【００８３】更に、バイトコード化されたプログラムの
最適化を、単一のコンパイルレベルか２つのコンパイル
レベルを使って説明したが、バイトコード化されたプロ
グラムの実行に伴うコンパイルレベルの数は一般に、発
明の精神と範囲から逸脱することなく、大幅に変更でき
る。一般に、バイトコード化されたプログラムの実行に
伴うコンパイルレベルの数は、それに限定されないが、
プログラムの最適化の希望レベルを含む任意数の異なる
要因に依存するだろう。各コンパイルレベルは独立のし
きい値を持つことができるが、しきい値は実質上すべて
のコンパイルレベルに対して同一でもよい。多重コンパ
イルレベルを含むシステムでは、方法が呼び出される度
に増分されるカウンタを、各コンパイルされた方法の中
に置くことができる。これらのカウンタは、上述の解釈
された方法の中に置かれたものと同様、コンパイルされ
た方法をリコンパイルするのはいつが適切かを決定する
場合に使用できる。

【００８４】方法をコンパイルすべきか否かの決定は、
その方法に関連するカウンタのしきい値に基づくものと
して説明したが、方法をコンパイルすべきか否かの決定
は、任意数の異なる要因に基づくことができる。例とし
て、全オペレーティングシステムでのタイム「チック」
を使って、コンパイルから利益を得る時間浪費の方法を
発見できる。すなわち、方法の実行に伴う時間の量を削
減するために、多くのタイムチックの過程にわたって実
行する方法のコンパイルを考慮することができる。

【００８５】実行カウンタ、すなわち呼出カウンタは一
般に、方法がアクセスされる度に増分されるカウンタで
ある。言うまでもなく、実施形態の中には、時間の経過
と共に呼出カウンタを減少できるものがある。例えば、
方法がプログラム実行の最初に繰り返し呼び出された
が、比較的長期間にわたって再び呼び出されていない場
合、呼出カウンタを減少させて、後から方法が呼び出さ
れた場合にその方法がコンパイルされる可能性を削減す
ることができる。一旦、方法用の呼出カウンタが減少、
例えば指数的に減少したときは、方法のコンパイルは最
早望ましくないだろう。従って、本例は例示的と見なす
べきであって、制限的なものと見なしてはならず、本発
明は本明細書に記載の詳細に限定すべきではなく、添付
の特許請求項の範囲、ならびに同等仕様の全範囲の中で
修正可能である。

【図面の簡単な説明】

【図１】（ａ）は、バイトコードコンパイラを持つコン
ピュータシステムのブロック線図であり、（ｂ）は、２
つのコンパイルプロセスを使用するコンピュータシステ
ムのブロック線図を示す。

【図２】（ａ）は、本発明の実施形態による、コードを
動的にコンパイルするコンピュータシステムのブロック
線図であり、（ｂ）は、本発明の実施形態による、バイ
トコードの処理に関連するステップを示すプロセス流れ
線図を示す。

【図３】本発明の実施形態による、プログラムの実行に
関連するステップ、すなわち図２（ｂ）のステップ２０
６を示すプロセス流れ線図である。

【図４】本発明の実施形態による、方法の実行に関連す
るステップ、すなわち図３ｂのステップ３２０を示すプ
ロセス流れ線図である。

【図５】本発明の実施形態による、リコンパイラの実行
に関連するステップ、すなわち図４のステップ４２０を
示すプロセス流れ線図である。

【図６】本発明の実施形態による、しきい値の増加に関
連するステップ、例えば図５のステップ５１６を示すプ
ロセス流れ線図である。

【図７】本発明の実施形態による、しきい値モニタの実
行に関連するステップ、すなわち図２（ｂ）のステップ
２０４を示すプロセス流れ線図である。

【図８】本発明の実施形態による、しきい値の減少に関
連するステップ、すなわち図７のステップ７１２を示す
プロセス流れ線図である。

【図９】本発明の実施形態による、解釈オーバヘッドの
計算に関連するステップを示すプロセス流れ線図であ
る。

【図１０】本発明の実現に適した汎用コンピュータシス
テムの図式表示である。

【図１１】図１０のコンピュータシステムによって支援
されて、本発明の実現に適したバーチャルマシンの図式
表示である。

【符号の説明】

１０４…バイトコード、１０５…システム、１０６…コ
ンパイラ、１０８…コンパイルコード、１１４…バイト
コード、１１５…システム、１１６…第１コンパイラ、
１１８…コンパイルコード、１２０…高度に実行される
コンパイルコード、１２２…第２コンパイラ、１２４…
リコンパイルされた高度に実行されるコード、１４４…
バイトコード、１４６…システム、１４８…インタープ
リタ、１５０…コンパイラ、１５４…解釈されたコー
ド、１５８…頻繁に実行されるコード、１６２…コンパ
イルされた頻繁実行コード、１６６…高度に実行される
コンパイルコード、１７０…追加コンパイラ、１７４…
高度に実行されるコンパイルコード、１０１２…ネット
ワーク、１０３２…プロセッサ、１０３４…主記憶装
置、１０３６…ＲＯＭ、１０３８…ネットワーク、１０
４０…入出力装置、１１０５…コンパイルタイム環境、
１１１０…ソースコード、１１２０…コンパイラ、１１
３０…バイトコード、１１３５…ランタイム環境、１１
４０…バーチャルマシン、１１４２…コンパイラ、１１
４４…インタープリタ、１１４６…ランタイムシステ
ム、１１６０…オペレーティングシステム。

フロントページの続き (72)発明者 ロバート グライセマー アメリカ合衆国， カリフォルニア州， メンロパーク， オーク レーン 960, ナンバーエフ (72)発明者 デイヴィッド グリズウォールド アメリカ合衆国， カリフォルニア州， ウッドサイド， スカイライン ドライヴ 10

Claims (19)

【特許請求の範囲】
1. 【請求項１】 ランタイム中にコンピュータプログラム
   を処理するためのコンピュータ実現方法であって、前記
   プログラムがバイトコードを含み、 複数の方法から選択された方法を呼び出すステップであ
   って、前記選択された方法の呼出しが前記選択された方
   法を解釈することを含むステップと、 前記選択された方法の呼出しを追跡するように構成され
   た呼出トラッカを更新するステップと、 前記選択された方法の前記呼出しがしきい値を超えるこ
   とをいつ前記呼出トラッカが示すか、を決定するステッ
   プと、 前記選択された方法の前記呼出しが前記しきい値を超え
   たことを前記呼出トラッカが示している、と決定された
   ときに、前記選択された方法をコンパイルするステップ
   と、を有するコンピュータ実現方法。
2. 【請求項２】 前記選択された方法のコンパイルに伴う
   コンパイルオーバヘッドを測定するステップを更に含
   む、請求項１に記載のコンピュータ実現方法。
3. 【請求項３】 前記コンパイルオーバヘッドがいつ許容
   範囲内にあるか、を決定するステップと、 前記コンパイルオーバヘッドが前記許容範囲内にない、
   と決定されたときに、前記しきい値を調節するステップ
   と、を更に含む請求項２に記載のコンピュータ実現方
   法。
4. 【請求項４】 前記コンパイルオーバヘッドの測定は前
   記コンパイルオーバヘッド用のスライディング平均を計
   算するステップを含む、請求項２及び３のいずれか一項
   に記載のコンピュータ実現方法。
5. 【請求項５】 前記選択された方法の解釈に伴う解釈オ
   ーバヘッドを測定するステップを更に含む請求項２〜４
   のいずれか一項に記載のコンピュータ実現方法。
6. 【請求項６】 前記解釈オーバヘッドがいつ許容範囲内
   にあるか、を決定するステップと、前記解釈オーバヘッ
   ドが前記許容範囲内にない、と決定されたときに、前記
   しきい値を調節するステップと、を更に含む請求項５に
   記載のコンピュータ実現方法。
7. 【請求項７】 前記しきい値の調節は、前記しきい値を
   増加させるステップと前記しきい値を減少させるステッ
   プの一つを含む、請求項１〜６のいずれか一項に記載の
   コンピュータ実現方法。
8. 【請求項８】 前記呼出トラッカの更新は、前記選択さ
   れた方法内に置かれたカウンタを増分するステップを含
   む、請求項１〜７のいずれか一項に記載のコンピュータ
   実現方法。
9. 【請求項９】 前記コンパイルされた選択された方法を
   呼び出すステップと、 前記コンパイルされた選択された方法の呼出しの数を追
   跡するように構成された追跡メカニズムを更新するステ
   ップと、 前記コンパイルされた選択された方法の呼出しの前記数
   が限界値を超えることをいつ前記追跡メカニズムが示す
   か、を決定するステップと、 前記コンパイルされた選択された方法の呼出しの前記数
   が限界値を超えることを前記追跡メカニズムが示してい
   る、と決定されたときに、前記コンパイルされた選択さ
   れた方法をリコンパイルするステップと、を更に含む請
   求項１〜８のいずれか一項に記載のコンピュータ実現方
   法。
10. 【請求項１０】 コンピュータプログラムを実行するた
    めのコンピュータ実現方法であって、前記コンピュータ
    プログラムが複数の方法を含み、該複数の方法が異なる
    適正状態にある選択された方法を含み、 前記コンピュータプログラムの実行中に方法を前記複数
    の方法から選択するステップであって、前記方法が第１
    の適正状態にあるステップと、 前記コンピュータプログラムの実行中に前記方法を前記
    第１の適正状態から第２の適正状態に変えるステップで
    あって、前記第２の適正状態は前記第１の適正状態より
    も、最適化されており、前記第１の適正状態から第２の
    適正状態への前記第１の方法の変化は、前記方法を変え
    るコストを、前記方法を変える利益と均衡させることを
    含むようになっているステップと、を有するコンピュー
    タ実現方法。
11. 【請求項１１】 前記方法を実行するステップを更に含
    み、前記第１の適正状態にある前記方法の実行が、前記
    第２の適正状態にある前記第１の方法の実行よりも遅
    い、請求項１０に記載のコンピュータ実現方法。
12. 【請求項１２】 前記第１の適正状態は、解釈された状
    態とコンパイルされた状態から成るグループから選択さ
    れた状態である、請求項１０及び１１のいずれか一項に
    記載のコンピュータ実現方法。
13. 【請求項１３】 前記複数の方法からの前記方法の選択
    は、前記コンピュータプログラムの前記実行中に前記第
    １の方法の呼出しの数を測定するステップを含む、請求
    項１０〜１２のいずれか一項に記載のコンピュータ実現
    方法。
14. 【請求項１４】 コンピュータプログラムを実行するた
    めのコンピュータ実現方法であって、前記コンピュータ
    プログラムが複数の方法を含み、 前記複数の方法から選択された第１の方法を呼び出すス
    テップと、 前記第１の選択された方法がいつコンパイラによって処
    理されるべきか、を決定するステップであって、前記選
    択された方法がいつ前記コンパイラによって処理される
    べきかの決定は前記第１の選択された方法の前記呼出し
    に関連するしきい値に基づくステップと、 前記第１の方法が前記コンパイラによって処理されるべ
    きである、と決定されたときに、前記選択された方法を
    前記コンパイラによって処理するステップと、 前記第１の方法が前記コンパイラによって処理されるべ
    きである、と決定されたときに、前記コンピュータプロ
    グラムに伴うオーバヘッドの測定を調節するステップ
    と、 前記オーバヘッドの前記測定が前記オーバヘッドは許容
    できることを示しているか否か、を決定するステップ
    と、 前記オーバヘッドは許容できない、と決定されたとき
    に、前記しきい値を調節するステップと、を有するコン
    ピュータ実現方法。
15. 【請求項１５】 バイトコードを実行するためのコンピ
    ュータ装置であって、前記バイトコードが複数の方法と
    して構成されており、 前記複数の方法から第１の選択された方法を解釈するよ
    うに構成されたインタープリタと、 前記第１の選択された方法の解釈をカウントするように
    構成された第１の追跡メカニズムであって、前記第１の
    選択された方法がいつコンパイルに適するか、を決定す
    るように更に構成されたメカニズムと、 前記第１の選択された方法がコンパイルに適する、と決
    定されたときに、前記第１の選択された方法をコンパイ
    ルするように構成されたコンパイラと、を備えたコンピ
    ュータ装置。
16. 【請求項１６】 前記追跡メカニズムと協力して、前記
    第１の選択された方法がいつコンパイルに適するか、を
    決定するように構成されたしきい値メカニズムを更に含
    み、前記しきい値メカニズムが、前記第１の方法がいつ
    コンパイルに適するか、を示すしきい値をセットするよ
    うに構成された、請求項１５に記載のコンピュータ装
    置。
17. 【請求項１７】 前記第１の選択された方法がコンパイ
    ルされるときに前記第１の選択された方法の呼出しをカ
    ウントするように構成された第２の追跡メカニズムであ
    って、更に、前記第１の選択された方法がいつリコンパ
    イルに適するか、を決定するように構成されたメカニズ
    ムと、 前記第１の選択された方法がリコンパイルに適すると決
    定されたときに前記第１の選択された方法をリコンパイ
    ルするように構成されたリコンパイラ、を更に含む請求
    項１５及び１６のいずれか１項に記載のコンピュータ装
    置。
18. 【請求項１８】 コンピュータプログラムを処理するた
    めのコンピュータプログラムプロダクトであって、前記
    プログラムはバイトコードを含み、前記バイトコードは
    複数の方法として構成され、前記コンピュータプログラ
    ムプロダクトは、 前記複数の方法から選択された第１の方法を呼び出すコ
    ンピュータコードであって、前記第１の選択された方法
    の呼出しは前記第１の選択された方法を解釈するステッ
    プを含むようになっているコンピュータコードと、 前記第１の選択された方法の呼出しを追跡するように構
    成された呼出トラッカを更新するコンピュータコード
    と、 前記選択された方法の前記呼出しがしきい値を超えるこ
    とをいつ呼出トラッカが示すか、を決定するコンピュー
    タコードと、 前記第１の選択された方法の前記呼出しがしきい値を超
    えることを前記呼出トラッカが示している、と決定され
    たときに、前記選択された方法をコンパイルするコンピ
    ュータコードと、を備えたコンピュータプログラムプロ
    ダクト。
19. 【請求項１９】 搬送波に組み込まれたデータ信号であ
    る、請求項１８によるコンピュータプログラムプロダク
    ト。