【誤訳訂正書】
【提出日】平成17年12月19日(2005.12.19)
【誤訳訂正１】
【訂正対象書類名】明細書
【訂正対象項目名】全文
【訂正方法】変更
【訂正の内容】
【書類名】明細書
【請求項１】
ランタイム中にコンピュータプログラムを処理するためにコンピュータによって実行される方法であって、前記プログラムがバイトコードを含み、
複数のメソッドから選択されたメソッドを呼び出すステップであって、前記選択されたメソッドの呼出しが前記選択されたメソッドを解釈することを含むステップと、
前記選択されたメソッドの呼出しを追跡するように構成された呼出トラッカを更新するステップと、
前記選択されたメソッドの前記呼出しがしきい値を超えることを前記呼出しトラッカが示すか否か、を判定するステップと、
前記選択されたメソッドの前記呼出しが前記しきい値を超えることを前記呼出トラッカが示している、と判定されたときに、前記選択されたメソッドをコンパイルするステップと、を有するコンピュータによって実行される方法。
【請求項２】
前記選択されたメソッドのコンパイルに伴うコンパイルオーバヘッドを測定するステップを更に含む請求項１に記載のコンピュータによって実行される方法。
【請求項３】
前記コンパイルオーバヘッドが許容範囲内にあるか否かを判定するステップと、
前記コンパイルオーバヘッドが前記許容範囲内にないと判定されたときに、前記しきい値を調節するステップと、を更に含む請求項２に記載のコンピュータによって実行される方法。
【請求項４】
前記コンパイルオーバヘッドの測定は前記コンパイルオーバヘッド用のスライディング平均を計算するステップを含む請求項２及び３のいずれか一項に記載のコンピュータによって実行される方法。
【請求項５】
前記選択されたメソッドの解釈に伴う解釈オーバヘッドを測定するステップを更に含む請求項２〜４のいずれか一項に記載のコンピュータによって実行される方法。
【請求項６】
前記解釈オーバヘッドが許容範囲内にあるか否かを判定するステップと、
前記解釈オーバヘッドが前記許容範囲内にないと判定されたときに、前記しきい値を調節するステップと、を更に含む請求項５に記載のコンピュータによって実行される方法。
【請求項７】
前記しきい値の調節は、前記しきい値を増加させるステップと前記しきい値を減少させるステップの一つを含む、請求項１〜６のいずれか一項に記載のコンピュータによって実行される方法。
【請求項８】
前記呼出トラッカの更新は、前記選択されたメソッド内に置かれたカウンタを増分するステップを含む請求項１〜７のいずれか一項に記載のコンピュータによって実行される方法。
【請求項９】
前記選択されコンパイルされたメソッドを呼び出すステップと、
前記選択されコンパイルされたメソッドの呼出しの数を追跡するように構成された追跡メカニズムを更新するステップと、
前記選択されコンパイルされたメソッドの前記呼出しの数が限界値を超えることを前記追跡メカニズムが示すか否か、を判定するステップと、
前記選択されコンパイルされたメソッドの前記呼出しの数が限界値を超えることを前記追跡メカニズムが示している、と判定されたときに、前記選択されコンパイルされたメソッドをリコンパイルするステップと、を更に含む請求項１〜８のいずれか一項に記載のコンピュータによって実行される方法。
【請求項１０】
コンピュータプログラムを実行するためにコンピュータによって実行される方法であって、前記コンピュータプログラムが複数のメソッドを含み、該複数のメソッドが異なる適正状態にある選択されたメソッドを含み、
前記コンピュータプログラムの実行中にメソッドを前記複数のメソッドから選択するステップであって、前記メソッドが第１の適正状態にあるステップと、
前記コンピュータプログラムの実行中に前記メソッドを前記第１の適正状態から第２の適正状態に変えるステップであって、前記第２の適正状態は前記第１の適正状態よりも最適化されており、前記第１の適正状態から第２の適正状態への前記第１のメソッドの変化は、前記メソッドを変えるコストを、前記メソッドを変える利益と均衡させることを含むようになっているステップと、を有するコンピュータによって実行される方法。
【請求項１１】
前記メソッドを実行するステップを更に含み、前記第１の適正状態にある前記メソッドの実行が、前記第２の適正状態にある前記第１のメソッドの実行よりも遅い請求項１０に記載のコンピュータによって実行される方法。
【請求項１２】
前記第１の適正状態は、解釈された状態とコンパイルされた状態から成るグループから選択された状態である請求項１０及び１１のいずれか一項に記載のコンピュータによって実行される方法。
【請求項１３】
前記複数のメソッドからの前記メソッドの選択は、前記コンピュータプログラムの前記実行中に前記第１のメソッドの呼出しの数を測定するステップを含む請求項１０〜１２のいずれか一項に記載のコンピュータによって実行される方法。
【請求項１４】
コンピュータプログラムを実行するためにコンピュータによって実行される方法であって、前記コンピュータプログラムが複数のメソッドを含み、
前記複数のメソッドから選択された第１のメソッドを呼び出すステップと、
前記選択された第１のメソッドがコンパイラによって処理されることになっているか否かを判定するステップであって、前記選択された第１のメソッドが前記コンパイラによって処理されることになっているか否かの判定は前記選択された第１のメソッドの前記呼出しに関連するしきい値に基づくステップと、
前記第１のメソッドが前記コンパイラによって処理されることになっていると判定されたときに、前記選択された第１のメソッドを前記コンパイラによって処理するステップと、
前記第１のメソッドが前記コンパイラによって処理されることになっていると判定されたときに、前記コンピュータプログラムに伴うオーバヘッドの測定を調節するステップと、
前記オーバヘッドの前記測定が前記オーバヘッドは許容できることを示しているか否かを判定するステップと、
前記オーバヘッドは許容できないと判定されたときに、前記しきい値を調節するステップと、を有するコンピュータによって実行される方法。
【請求項１５】
バイトコードを実行するためのコンピュータ装置であって、前記バイトコードが複数のメソッドとして構成されており、
前記複数のメソッドから選択された第１のメソッドを解釈するように構成されたインタープリタと、
前記選択された第１のメソッドの解釈をカウントするように構成された第１の追跡メカニズムであって、前記選択された第１のメソッドがコンパイルに適するか否かを判定するように更に構成された前記第１の追跡メカニズムと、
前記選択された第１のメソッドがコンパイルに適すると判定されたときに、前記選択された第１のメソッドをコンパイルするように構成されたコンパイラと、を備えたコンピュータ装置。
【請求項１６】
前記第１の追跡メカニズムと協力して、前記選択された第１のメソッドがコンパイルに適するか否かを判定するように構成されたしきい値メカニズムを更に含み、前記しきい値メカニズムが、前記選択された第１のメソッドがコンパイルに適するか否かを示すしきい値をセットするように構成された、請求項１５に記載のコンピュータ装置。
【請求項１７】
前記選択された第１のメソッドがコンパイルされるときに前記選択された第１のメソッドの呼出しをカウントするように構成された第２の追跡メカニズムであって、更に、前記選択された第１のメソッドがリコンパイルに適するか否かを判定するように構成されたメカニズムと、
前記選択された第１のメソッドがリコンパイルに適すると判定されたときに前記選択された第１のメソッドをリコンパイルするように構成されたリコンパイラと、を更に含む請求項１５及び１６のいずれか１項に記載のコンピュータ装置。
【請求項１８】
他のコンピュータプログラムを処理するためのコンピュータプログラムであって、前記他のプログラムはバイトコードを含み、前記バイトコードは複数のメソッドとして構成され、前記コンピュータプログラムは、
前記複数のメソッドから選択された第１のメソッドを呼び出すコンピュータコードであって、前記選択された第１のメソッドの呼出しは前記選択された第１のメソッドを解釈するステップを含むようになっているコンピュータコードと、前記選択された第１のメソッドの呼出しを追跡するように構成された呼出トラッカを更新するコンピュータコードと、
前記選択された第１のメソッドの前記呼出しがしきい値を超えることを呼出トラッカが示すか否かを判定するコンピュータコードと、
前記選択された第１のメソッドの前記呼出しがしきい値を超えることを前記呼出トラッカが示していると判定されたときに、前記選択された第１のメソッドをコンパイルするコンピュータコードと、を備えたコンピュータプログラム。
【請求項１９】
搬送波に組み込まれたデータ信号である請求項１８によるコンピュータプログラム。
【請求項２０】
ランタイム中にコンピュータプログラムを処理するためにコンピュータによって実行される方法であって、前記コンピュータプログラムがバイトコードを含み、該バイトコードが複数のメソッドとして構成され、
前記複数のメソッドから選択された第１のメソッドを呼び出すステップであって、前記選択された第１のメソッドを解釈することを含むステップと、
前記選択された第１のメソッドをコンパイルするのに適するか否かを判定するステップと、
前記選択された第１のメソッドをコンパイルするのに適すると判定されたときに、前記選択された第１のメソッドをコンパイルするステップと、を備える方法。
【請求項２１】
前記選択された第１のメソッドをコンパイルするのに適するか否かを判定するステップは、前記選択された第１のメソッドの呼出しの数を追跡するように構成されたカウンタが、前記選択された第１のメソッドの前記呼出しの数が所定の値を超えることを示すか否かを判定するステップを含んでいる、請求項２０に記載のコンピュータによって実行される方法。
【請求項２２】
前記選択された第１のメソッドをコンパイルするのに適するか否かを判定するステップは、タイマのクロックチックをモニタし、前記選択された第１のメソッドの解釈に伴う総時間を判定するステップを含んでいる請求項２０又は２１に記載のコンピュータによって実行される方法。
【請求項２３】
前記タイマはオペレーティングシステムのタイマである請求項２２に記載のコンピュータによって実行される方法。
【請求項２４】
前記タイマの前記クロックチックをモニタし、前記クロックチックの数がしきい値を超えているか否かを判定する請求項２２に記載のコンピュータによって実行される方法。
【請求項２５】
前記クロックチックの数が前記しきい値を超えていると判定されたとき、前記選択された第１のメソッドがコンパイルされる請求項２４に記載のコンピュータによって実行される方法。
【請求項２６】
前記選択された第１のメソッドのコンパイルに伴うコンパイルオーバヘッドを測定するステップと、
前記コンパイルオーバヘッドが許容範囲内にあるか否かを判定するステップと、
前記コンパイルオーバヘッドが前記許容範囲内にないと判定されたときに前記しきい値を調整するステップと、を更に含む請求項２４又は２５に記載のコンピュータによって実行される方法。
【請求項２７】
前記選択された第１のメソッドをコンパイルするのに適するか否かを判定するステップは、前記選択された第１のメソッドを解釈している間に経過した時間をモニタすることを含む請求項２０〜２６のいずれか一項に記載のコンピュータによって実行される方法。
【請求項２８】
前記選択された第１のメソッドをコンパイルするのに適すると判定されたときに、前記選択された第１のメソッドをコンパイルするか否かを判定するステップと、
前記選択された第１のメソッドをコンパイルするのに適すると判定されたときに、前記選択された第１のメソッドのコンパイルをスケジューリングするステップと、を更に含む請求項２０〜２７のいずれか一項に記載のコンピュータによって実行される方法。
【請求項２９】
前記選択された第１のメソッドのコンパイルをスケジューリングするステップは、前記選択された第１のメソッドをコンパイルする前に、前記選択された第１のメソッドのコンパイルを遅延するステップを含む請求項２８に記載されたコンピュータによって実行される方法。
【請求項３０】
ランタイム中にコンピュータプログラムを処理するためにコンピュータによって実行される方法であって、前記プログラムがバイトコードを含み、前記バイトコードは複数のメソッドとして構成されており、
前記複数のメソッドから選択された第１のメソッドを呼出すステップであって、前記選択された第１のメソッドの呼出しが前記複数のメソッドから選択された第２のメソッドをコールすることを含むステップと、
前記選択された第２のメソッドのコールに応じて前記選択された第２のメソッドを呼出すステップであって、前記選択された第２のメソッドは前記選択された第１のメソッドを用いることで呼出され、前記選択された第２のメソッドの呼出しが前記選択された第２のメソッドを解釈することを含むステップと、
前記選択された第２のメソッドの呼出しの数を追跡するステップと、
前記選択された第２のメソッドの前記呼出しの数がしきい値を超えるか否かを判定するステップと、
前記選択された第２のメソッドの前記呼出しの数が前記しきい値を超えていると判定されたときに前記選択された第１のメソッドをコンパイルするステップと、を有するコンピュータによって実行される方法。
【請求項３１】
前記選択された第１のメソッドをコンパイルするステップは、前記選択された第２のメソッドを前記選択された第１のメソッドにインラインするステップを含む請求項３０に記載のコンピュータによって実行される方法。
【請求項３２】
前記選択された第１のメソッドをコンパイルするステップは、前記選択された第１のメソッドをリコンパイルするステップを含む請求項３０に記載のコンピュータによって実行される方法。
【請求項３３】
前記選択された第１のメソッドのコンパイルを遅延させるステップを更に含む請求項３０又は３１に記載のコンピュータによって実行される方法。
【請求項３４】
バイトコードを実行するコンピュータシステムであって、前記バイトコードが複数のメソッドを含み、
前記複数のメソッドから選択された第１のメソッドを解釈するように構成されたインタープリタと、
前記選択された第１のメソッドをコンパイルするのが有益であるか否かを判定するためのメカニズムと、
前記選択された第１のメソッドをコンパイルするのが有益であると判定されたときに、前記選択された第１のメソッドをコンパイルするように構成されたコンパイラと、を有するコンピュータシステム。
【請求項３５】
前記メカニズムは、呼出し追跡メカニズム及びタイマで構成されるグループから選択された一つである、請求項３４に記載のコンピュータシステム。
【請求項３６】
前記タイマがコンピュータシステムのタイマである、請求項３５に記載のコンピュータシステム。
【請求項３７】
前記選択された第１のメソッドをコンパイルするのが有益であると判定されたときに、前記選択された第１のメソッドのコンパイルを遅延させるように構成された遅延メカニズムを更に含む請求項３４に記載のコンピュータシステム。
【請求項３８】
他のコンピュータプログラムを処理するためのコンピュータプログラムであって、前記他のプログラムはバイトコードを含み、該バイトコードが複数のメソッドとして構成され、
前記複数のメソッドから第１のメソッドを呼び出すコンピュータコードであって、前記選択された第１のメソッドを解釈するコンピュータコードと、
前記選択された第１のメソッドをコンパイルするのに適するか否かを判定するコンピュータコードと、
前記選択された第１のメソッドをコンパイルするのに適すると判定されたときに、前記選択された第１のメソッドをコンパイルするコンピュータコードと、を備えるコンピュータプログラム。
【発明の詳細な説明】
【０００１】
【発明の背景】
１．  発明の分野
本発明は一般的に、ソフトウェアアプリケーションの実行を最適化するための方法及び装置に関する。より詳細には、本発明は、ランタイム中にソフトウェアアプリケーションを最適化するために、コードの部分を、解釈すべきか、コンパイルすべきかを動的に決定するための方法及び装置に関する。
２．  関連技術の説明
コンピュータシステムのネットワーク、例えばローカルエリアネットワーク、イントラネット、及びインターネット全体にわたってリソースを共有するコンピュータシステムの使用が増加している。従って、特定コンピュータシステムは一般に、ソフトウェアアプリケーションがその特定コンピュータシステムに固有のフォーマットを取るように要求するという事実によって、ソフトウェアアプリケーション、つまりコンピュータプログラムは、異なるコンピュータシステムには異なるフォーマットで与えられる（deliver）だろう。それとは別に、コンピュータプログラムは、一つの形式のコンピュータプログラムを多くの異なるコンピュータシステムによって利用できるようにするために、機械独立の形で、すなわちバイトコードとしてコンピュータシステムに提供されるだろう。
【０００２】
コンピュータプログラムが機械独立の形で与えられる（deliver）と、プログラムは直接解釈されるか、或いは機械独立コード、すなわち「機械コード」に翻訳されるであろう。直接に解釈されるプログラムは、機械コードに翻訳されるプログラムよりもコンピュータシステム内で占めるスペースが少ない。しかしながら、直接に解釈されるプログラムは機械コードに翻訳されるプログラムよりも、大抵の場合、実行速度が遅い。従って、コンピュータプログラムを機械コードに翻訳する代わりにコンピュータプログラムを直接に解釈すべきか否かの決定は、実行速度に対するスペースの相対的な重要性によることが多い。
【０００３】
上述のように、コンピュータプログラムはコンピュータシステムにバイトコードとして与えられるであろう。バイトコードを受信するコンピュータシステムは一般に、ランタイムでバイトコードをコンパイルするために使用されるコンパイラを含む。ランタイムでバイトコードをコンパイルするには、そのバイトコードを機械コードに翻訳する必要がある。図１（ａ）は、バイトコードコンパイラを持つコンピュータシステムのブロック線図を示す。コンピュータプログラムとして構成されるバイトコード１０４は、コンピュータシステム１０５に与えられるか、別途に供給される。バイトコード１０４は一般に様々なソースによって供給できる。バイトコード１０４が実行されるときは、バイトコード１０４はコンパイラ１０６を使ってランタイムでコンパイルされる。コンパイラ１０６によって作成されるコンパイルド（compiled）コード１０８は一般に、システム１０５に固有でシステム１０５内で実行可能な機械依存コードである。すなわち、コンパイラ１０６はバイトコード１０４をランタイムでコンパイルドコード１０８に翻訳する。
【０００４】
コンピュータシステムの中には、先にコンパイルされたコードの部分を、それらの部分が繰り返し実行されることが判った場合に、より効率的に実行される形にリコンパイルできるものがある。言い換えれば、第２の、より高価なコンパイルプロセスを使って、繰り返し呼び出される、先にコンパイルされたコードをコンパイルして、繰り返し呼び出されるコードをより効率的に実行することが可能である。図１（ｂ）は、２つのコンパイルプロセスを使用するコンピュータシステムのブロック線図を示す。コンピュータシステム１１５は第１のコンパイラ１１６と第２のコンパイラ１２２とを含む。バイトコード１１４が実行のためにコンピュータシステムに供給される。ランタイムで、第１のコンパイラ１１６によってバイトコード１１４が機械依存コンパイルドコード１１８、すなわち機械コードに翻訳される。
【０００５】
機械依存コンパイルドコード１１８が実行されて、機械依存コンパイルドコード１１８内に含まれる異なるメソッドが追跡され、最も頻繁に呼び出されるメソッドを第２のコンパイラ１２２でコンパイルすべきか否かを決定する。高度に、又は繰り返し実行されるコンパイルドコード１２０が識別されると、その高度に実行されるコンパイルドコード１２０は、コンピュータプログラムの全体的実行速度を増加させるためにリコンパイルされる。このように、第２のコンパイラ１２２は、高度に実行されるコンパイルドコード１２０を、リコンパイルされた高度に実行されるコード１２４に翻訳する。
【０００６】
第２のコンパイラ１２２はしばしば、第１のコンパイラ１１６よりも遅いコンパイラだが、第２のコンパイラ１２２を使ってコンパイルされるコードは通常、第１のコンパイラ１１６を使ってコンパイルされるコードよりも効率的に実行される。従って、高度に実行されるコンパイルドコード１２０をリコンパイルすべきか否かの決定は一般に、全ランタイムに対する追加のコンパイルオーバヘッド（compilation overhead）とリコンパイルされた高度に実行されるコード１２４によって与えられる効率改善の間のトレードオフを含む。
【０００７】
効率を増大にするために、先にコンパイルされたコードのリコンパイルが可能なシステムの一つは、先にコンパイルされたコードをリコンパイルすべきか否かの決定が、メソッド等のコンパイルドコードの特定部分が何回コールされたかに基づいて行なわれることを必要とする。メソッドが一定の限界値よりも頻繁に呼び出された場合は、そのメソッドはリコンパイルされる。一定の限界値は本質的に一定のしきい値であり、それは、実行の効率を増加させるためにメソッドがリコンパイルされる前に、そのメソッドを呼び出すべき回数を反映している。
【０００８】
コンパイラを使ってランタイムでバイトコードを機械依存コードに翻訳するときは、かなりのコンパイルオーバヘッドが、しばしばプログラムの全実行に追加される。従って、機械コードは解釈されたコードよりはるかに速く実行するかもしれないが、機械コードを実行する前にプログラムのすべての部分を機械コードにコンパイルすることは、実行速度の増加がプログラムのコンパイルに伴うオーバヘッドを補償しない場合、必ずしも望ましくないだろう。言い換えれば、プログラムのコンパイルに費やされる時間の量がプログラムの実行中に回復されないときは、プログラムは解釈されたコードとして、より迅速に実行するかもしれない。
【０００９】
上述の既存のシステムでは、コンパイルされたプログラムの中のルーチンのリコンパイルはプログラムをより効率的に実行可能にするために役立つかもしれないが、ルーチンをリコンパイルすべきか否かを決定するための一定の限界の使用は、その反対に、非効率な、例えば非最適の実行をもたらすかもしれない。例として、プログラム中の実質上すべてのルーチンがリコンパイルされるように一定の限界がセットされた場合は、リコンパイル（re-compilation）によって得られた実行速度の増加はリコンパイルに伴うコンパイルオーバヘッドを補償しないかもしれない。
【００１０】
従って、必要なことはバイトコードフォーマットでプログラムを効率的に実行するための方法である。より具体的には、望ましいことは、コンピュータプログラムの部分を解釈すべ時と、コンピュータプログラムの部分を機械コードに翻訳すべき時を動的に決定することによって、コンピュータプログラムの効率的な実行を保証するための方法である。
【００１１】
【発明の概要】
ランタイム中にソフトウェアアプリケーションを最適化するためにバイトコードの部分を解釈すべきか、コンパイルすべきかを動的に決定するためのメソッド及び装置が開示される。本発明の一局面によれば、選ばれたメソッドが呼び出されると、それが最初に解釈される。呼出トラッカ（invocation tracker）が、選ばれたメソッドの呼出の数を追跡する。選ばれたメソッドの呼出の数がしきい値を超えると、そのメソッドがコンパイルされる。各種メソッドその他のコードセグメントの使用を独立に追跡することによって、どのメソッドをコンパイルすべきか、及びどのメソッドを解釈状態で残すべきかに関して、より賢明な決定を行なうことができる。実施形態の中には、すべてのメソッドに対して単一のしきい値を使用するものがある。また他の実施形態では、各しきい値が一つ以上のメソッドに関連した状態で複数のしきい値が使用される。後者の構成では、異なるメソッドに関連するしきい値を変更することができる。
【００１２】
本実施形態の別の局面では、特定メソッドのコンパイルに伴うオーバヘッドが測定される。オーバヘッドは次に、許容オーバヘッドパラメータと比較されて、そのオーバヘッドが許容範囲内にない場合は、その特定メソッドのコンパイルを引き起こすしきい値が調節される。本発明のこの局面は、メソッドの初期コンパイル及び／又はメソッドのリコンパイルに適用できる。
【００１３】
本発明の更に別の局面によれば、複数のメソッドとして構成されたバイトコードを実行するためのコンピュータシステムは、各種メソッドを解釈するのに適したインタープリタと、選ばれたメソッドの解釈をカウントする追跡メカニズムとを含む。追跡メカニズムを用いて、選ばれたメソッドがコンパイルに適するか否かが決定される。コンピュータシステムは更に、各種メソッドをコンパイルするのに適したコンパイラを含む。一実施形態では、コンピュータシステムは、選ばれたメソッドがコンパイルに適するか否かを、追跡メカニズムと協力して決定するしきい値調節メカニズムを含む。別の実施形態では、コンピュータシステムは更に、選ばれたメソッドの呼出を、それがコンパイルされた後でカウントすると共に、その選ばれたメソッドがリコンパイルに適するか否かの決定に使用される別の追跡メカニズムを含む。
【００１４】
本発明のこれらとその他の利点は、下記の詳細説明を一読して各種の図面を検討することによって明らかになるであろう。
【００１５】
本発明は添付の図面に関してなされる下記説明を参照することによって充分に理解されるであろう。
【００１６】
【発明の実施の形態】
バイトコード化された（byte-coded）コンピュータプログラムがコンピュータシステムに提供されると、そのプログラムは直接に解釈されるか、プログラムは実行のためにランタイムで機械コードに翻訳することができる。直接に解釈されるプログラムは一般に、機械コードに翻訳されるプログラムよりも占拠するコンピュータメモリが少ない。他方、機械コードに翻訳されるプログラムは通常、直接に解釈されるプログラムより実行速度が速い。しかしながら、場合によっては、コンパイラを使って機械コードを生成するときにプログラムの全ランタイムに追加されるコンパイルオーバヘッドは、必ずしもそのプログラムの実行中に回収されない。これらの場合、プログラムを直接に解釈する方がより速く、より効率的なことが判明するかもしれない。一般に、プログラムがより効率的に実行されるのは、それが直接に解釈される場合なのか、機械コードに翻訳される場合かの決定は難しい。従って、プログラムは可能である最も迅速、又は最も効率的な方法で実行されないことも多い。
【００１７】
バイトコード化されたコンピュータプログラムの直接的な解釈と機械コードへの翻訳の両者を許すことは、純粋に解釈されたプログラムで得られる実行速度に比べて、コンピュータプログラムの実行速度を増加させる。解釈されたコードと機械コード、例えばコンパイルドコードの混合は、機械コードのみの実行に伴うメモリ要件も明らかに減少させる。このように、解釈されたコードとコンパイルドコードの混合はプログラム実行の効率を増加させる。
【００１８】
バイトコード化されたプログラム内の各メソッドをモニタして、メソッドのコンパイルがプログラムの全実行に対して有益になるか否かを決定することができる。一実施形態では、メソッドのモニタは、メソッドが、解釈されたメソッドとして呼び出される回数の追跡を伴う。解釈されたメソッドの呼出しが、そのメソッドが、コンパイルされた場合にコンパイルコストを回収する可能性があることを示すレベル、つまり、しきい値に達すると、そのメソッドが動的にコンパイルされる。プログラム中のメソッドのコンパイルに伴うコンパイルオーバヘッドが許容レベルに維持されることを本質的に保証するために、プログラムのコンパイルオーバヘッドと解釈オーバヘッドの両者がモニタされる。コンパイルオーバヘッドが高すぎると見なされるときは、コンパイルされるメソッドの数を削減することによってコンパイルオーバヘッドを低くするための調節ができる。行なわれる調節は、解釈されたメソッドをコンパイルすべきか否かの決定に用いられるしきい値を上げることを含む。適合しきい値（adaptive threshold）の修正を許すことによって、バイトコード化されたプログラムの実行を実質的に最適化できる。言い換えれば、解釈されたコードと動的にコンパイルされたコードの混合を調節することによって、より少ない実行時間、ならびにプログラムによって占められるメモリスペースの量とプログラムの実行速度間のより良いバランスを達成できる。
【００１９】
図２（ａ）に関して、バイトコードを動的にコンパイルすベきか否かを適合しきい値を用いて決定するコンピュータシステムを、本発明の実施形態に従って説明する。バイトコード１４４は、コンピュータシステム１４６への入力としてランタイムで供給される。機械独立のコンピュータプログラムとして編成されるバイトコード１４４は通常、メソッド又はルーチンとして構成される。一実施形態では、バイトコード１４４は、バーチャルマシン内のコンパイルタイム環境によって同一バーチャルマシン内のランタイム環境、例えばコンピュータシステム１４６へ供給できる。本発明が実現される適当なバーチャルマシンの一つを、図１１に関して以下により詳しく説明する。
【００２０】
バイトコード１４４がコンピュータシステム１４６に供給されると、バイトコード１４４はインタープリタ１４８で処理することができる。それとは別に、バイトコード１４４をコンパイラ１５０によってコンパイルしてコンパイルドコードを作成することもできる。バイトコード１４４は一般に、インタープリタ１４８とコンパイラ１５０の両者に実質上直接に入力してもよいが、記載の実施形態では、バイトコード１４４は処理のためにインタープリタ１４８のみに供給される。バイトコード１４４の処理に関連するステップを、図２（ｂ）に関して以下に説明する。
【００２１】
メソッドが呼び出される度に、そのメソッドに関連するバイトコード１４４がインタープリタ１４８を使って解釈される。記載の実施形態では、メソッドが何回解釈されるかの手段が維持される。任意の適当な手段を使って、メソッドが何回解釈されるかを追跡することができる。適当な手段は、それに限定されないが、メソッドが解釈される回数をカウントするために使用されるカウンタである。そのようなカウンタは、メソッドが解釈される度にカウンタが増分されるように、メソッドの中に実現できる。
【００２２】
メソッドが解釈される回数がしきい値、すなわち限界値を超えると、コンパイラ１５０を使ってそのメソッドをコンパイルできる。頻繁に実行されるコード１５８に含まれるメソッドの繰り返しの解釈は、解釈されたバイトコード１５４が一般にコンパイルドコードよりも実行が遅いか効率が劣るので、非効率かもしれない。頻繁に実行されるコード１５８のコンパイルは、メソッドのコンパイルによって得られる時間の節約がコンパイルプロセスに伴うコンパイルオーバヘッドを補償する可能性があるので、一般に、頻繁実行コード１５８に組み込まれたメソッドのより効率的な実行を可能とするであろう。
【００２３】
一般に、大抵のコンピュータプログラムの実行では、繰り返し実行されるメソッドもあれば、実行頻度の少ないメソッドもある。頻繁に実行されるコード１５８は一般に、プログラムの実行の重要部分を占めるメソッドを含むコードのセクションとして識別できる。頻繁実行（frequently executed）コード１５８がコンパイラ１５０によってコンパイルされると、頻繁実行コード１６２のコンパイルド版が作成される。従って、コンパイルされた頻繁実行コード１６２内に含まれるメソッドが呼び出されると、そのコンパイルされたメソッドが呼び出される。一実施形態では、頻繁実行コード１５８は、全実行タイムの実質的に５０％以上、例えば全実行時間のほぼ９０％の割合を占めるメソッドのグループを含む。
【００２４】
コンピュータシステムの中には単一レベルのコンパイルを含むものもあれば、複数レベルのコンパイルを含むものもある。多重レベルのコンパイルを含むコンピュータシステムをアレンジすることによって、コンパイルされたメソッドを、そのメソッドのリコンパイルがメソッドに伴う実行効率を増加させると決定されたときにリコンパイルできる。例として、コンパイラ１５０を使って達成される第１のレベルのコンパイルは、「中間」レベルのコンパイルに関係させることができる。中間レベルのコンパイルをアレンジすることによって、バイトコードを、そのバイトコードを解釈することよりも効率的だが、「最終」レベルのコンパイルほど効率的でないかもしれないコンパイルド形式にコンパイルできる。中間レベルのコンパイルは、コンパイル速度に関して、中間的にコンパイルされたメソッドの実行に伴う一部の実行効率を本質的に犠牲にするかもしれない。それに対して最終レベルのコンパイルは、よい長いコンパイルタイムを伴うかもしれないが、より効率的な実行となる。
【００２５】
一実施形態では、追跡メカニズムを使用して、最も頻繁に実行される、コンパイルされた頻繁実行コード１６２に含まれるメソッドを識別できる。言い換えれば、コンパイルされた頻繁実行コード１６２内で、高度に実行されるコンパイルドコード１６６を識別できる。高度に実行されるコンパイルドコード１６６内のメソッドが実行される回数がしきい値を超えると、高度に実行されるコンパイルドコード１６６が追加コンパイラ１７０を使ってリコンパイルされて、高度に実行されるコード１７４のコンパイルド版が作成される。言うまでもなく、追加コンパイラ１７０はコンパイラ１５０とは異なるコンパイラでよい。その他に、コンパイラ１７０とコンパイラ１５０は、異なるパラメータで実現された実質的に同一のコンパイラでもよい。これまで２つのレベルのコンパイルのみを説明したが、システム１４６は一般に、任意数のレベルのコンパイルを含むことができる。
【００２６】
図２（ｂ）は、本発明の実施形態による、バイトコード、（例えば機械独立コンピュータプログラム）の処理に関連するステップを示すプロセス流れ線図である。プロセス２０２は、しきい値モニタが起動されるステップ２０４で始まる。しきい値モニタは、以下に説明するように、コンピュータプログラムと同時に実行して、特定メソッドを、そのメソッドのコンパイルが考慮される前に、実行すべき回数を示すしきい値を追跡する。しきい値モニタの一実施形態を図７に関して以下に説明する。
【００２７】
ステップ２０６では、図３に関して以下に説明するように、バイトコードから成るコンピュータプログラムが実行される。コンピュータプログラムが実行された後、バイトコードを処理するメソッドが完了する。言うまでもなく、記載の実施形態では、しきい値モニタとプログラムは、実質上同時に、すなわち並列プロセスとして実行される。言い換えれば、ステップ２０４とステップ２０６は本質的に並列に実行される。
【００２８】
次に図３を参照して、プログラムの実行に関連するステップを本発明の実施形態に従って説明する。すなわち、図２（ｂ）のステップ２０６について説明する。ステップ３０８で、しきい値が初期化される。一実施形態では、しきい値は、特定メソッドを、そのメソッドのコンパイルが考慮される前に、実行すべき回数を示す上限しきい値である。しきい値は一般に、特定システムの要件、例えばメモリ要件や性能要件によって大幅に変更できる。例として、しきい値は約１０００〜１０，０００の範囲になるように初期化できる。
【００２９】
一実施形態では、プログラム実行に伴うすべてのメソッドに対して単一のしきい値しか存在しないかもしれない。すなわち、しきい値はグローバル定数かグローバル変数かもしれない。しかしながら、他の実施形態では、言うまでもないことだが、多重しきい値が存在する、例えばしきい値は、メソッド固有の定数かメソッド固有の変数かもしれない。
【００３０】
しきい値がステップ３０８で初期化された後、実行カウンタを持たないメソッドを含む解釈されたコードがロードされて、ステップ３１２で、実行カウンタがそのメソッドに追加される。言い換えれば、メソッドが割り当てられて、カウンタがその新しく割り当てられたメソッドに追加される。一旦、カウンタが追加されると、ステップ３１６で、新しく割り当てられたメソッドの中のカウンタが初期化、例えばゼロにセットされる。
【００３１】
ステップ３１６から、プログラムの流れはステップ３２０に進み、そこで、ロードされたコードのメソッドが、コードの実行が完了するか或いはロードされたコード内の実質上すべての適切なメソッドが実行されるまで、実行される。コードの実行中、制御の流れは、先にロードされなかったメソッドに到達するかもしれないが、その場合、そのコードは、当業者の承知するように、動的にロードされるだろう。メソッドＭの実行に関連するステップを、図４に関して以下により詳しく説明する。コードの実行の過程で、ロードすべき解釈されたコードが更に存在するか否かに関する決定がステップ３２４で行なわれる。追加の解釈されたコードをロードすべきであると決定された場合、プロセスの流れは、追加コードがロードされるステップ３１２へ戻る。それとは別に、ロードすべき追加の解釈されたコードは存在しないと決定された場合、ステップ３２０でコードの実行が継続する。
【００３２】
図４は、本発明の実施形態によるメソッドの実行に関連するステップ、すなわち図３のステップ３２０を説明するプロセス流れ線図である。メソッドＭの実行はステップ４０４で開始され、そこでメソッドＭ用のカウンタ、すなわち実行カウンタが増分される。カウンタが増分された後、メソッドＭ用カウンタはステップ４０８でしきい値と比較される。上述のように、しきい値は、メソッドＭの可能なコンパイルが考慮される前にメソッドＭが何回実行されるかに関する表示である。
【００３３】
ステップ４１２では、メソッドＭ用カウンタがしきい値を超えるか否かについての決定が行なわれる。メソッドＭ用カウンタがしきい値を超えない場合は、メソッドＭをコンパイルする必要がないことを示す。従って、プロセスの流れはステップ４１２からステップ４１６に移り、そこでメソッドＭがインタープリタによって実行される。代わりに、ステップ４１２でメソッドＭ用カウンタがしきい値を超えると決定された場合は、全プログラムの実行は、メソッドＭが解釈ではなく、コンパイルされるとすれば、より効率的になることを示す。このように、メソッドＭ用カウンタがしきい値を超えると決定されたときは、リコンパイラがステップ４２０で実行される。リコンパイラの実行に関連するステップを、図５に関して以下に更に詳しく説明する。
【００３４】
リコンパイラがステップ４２０で実行された後、プロセスの流れはステップ４２４に進み、そこでメソッドＭがコンパイルされるか否かに関する決定が行なわれる。すなわち、ステップ４２０でのリコンパイラの実行の結果としてメソッドＭがコンパイルされたか否かに関する決定が行なわれる。メソッドＭがコンパイルされていないと決定された場合、プロセスの流れはステップ４１６に移り、メソッドＭが解釈を介して実行される。ステップ４２４で、メソッドＭがコンパイルされていると決定された場合、そのコンパイルされたメソッドＭ用のコードがステップ４２８で実行される。
【００３５】
上述のように、一実施形態では、リコンパイラを使ってコンパイラが所定のメソッド、例えばメソッドＭをどのように処理するかが決定される。このようなリコンパイラをアレンジすることによって、コンパイルが全プログラムの実行に対して有益であろうと決定された場合に、コンパイラを実際にコールしてメソッドＭをコンパイルできる。図５は、本発明の実施形態による、リコンパイラの実行に関連するステップ、すなわち図４のステップ４２０を示すプロセス流れ線図である。リコンパイラの実行はステップ５０４で始まり、そこでメソッドＭのダイレクトコーラーに対する探索が行なわれる。一般に、コーラー、すなわちメソッドＭをコールしたメソッドの探索は、当業者の承知するように、コールスタックの検査を伴う。
【００３６】
メソッドＭのコーラーを探索した後、ステップ５０６で、メソッドＭ用のコーラーが存在するか否かが決定される。メソッドＭ用のコーラーが存在すると決定された場合、プロセスの流れはステップ５０８に進み、そこで全プログラムに関連するコンパイラはメソッドＭをコーラーとインライン（inline）するのか否かに関する決定が行なわれる。メソッドＭをコーラーにインラインすることは、メソッドＭ用の解釈されたコードのコピーの作成と、コード、例えばメソッドＭのコーラーからのパラメータや変数のパッセージを含むコード、の不要な部分を除去した後の、コーラーへのコピーされたコードの組込みを伴う。コーラーが繰り返し実行されることによってメソッドＭが繰り返し実行される場合、又はコーラーが通常的にメソッドＭを繰り返しコールする場合、コーラーへのメソッドＭのインライン（inlining）とコーラーのコンパイル（compiling）とは、全プログラム実行の効率を増加させるのに役立つかもしれない。しかしながら、コーラーへのメソッドＭのインラインは、他のメソッドがメソッドＭをコールできるという事実によってメソッドＭの非インライン版を排除しないので、メソッドＭはその他のメソッドへアクセスできる状態を維持しなければならない。このように、プログラムに関連するコードの物理量はメソッドＭがインラインされると増加するので、コーラーへのメソッドＭのインラインは全プログラム実行の効率を必ずしも改善しないだろう。
【００３７】
ステップ５０８で、コンパイラがメソッドＭをコーラーとインラインするだろうと決定した場合、記載の実施形態では、全プログラム実行の効率の改善が、特別のプログラムコードの追加よりも本質的に勝ることを示す。その結果、プロセスの流れはステップ５０８からステップ５１０に移り、そこでコンパイラへのコールが行なわれて、メソッドＭをインラインすると共に、メソッドＭをその中にインラインした状態で、メソッドＭのコーラーがコンパイルされる。
【００３８】
メソッドＭをメソッドＭのコーラーにインラインする決定は様々な要因を含む。例として、要因は、それらに限定されないが、メソッドＭのサイズ、コーラーのサイズ、メソッドＭとコーラーとに関連するパラメータの値、及びメソッドＭをコールするメソッドの数を含む。一般に、言うまでもないことだが、メソッドＭのインライン（inlining）は、メソッドＭのコーラーへの、メソッドＭのインラインを含むばかりでなく、コーラーのコーラーへメソッドＭのコーラーをインラインすることも含むだろう。言い換えれば、コーラーは任意数のレベルに対するスタックの中でルックアップされるだろう。
【００３９】
メソッドＭがインラインされてコーラーがコンパイルされた後、コンパイルオーバヘッドがステップ５１２で確認される。一般に、コンパイルオーバヘッドの確認は、ランタイム中のメソッドのコンパイルに伴うオーバヘッドのモニタを伴う。コンパイルオーバヘッドは次に、望ましい最大コンパイルオーバヘッドに対して比較される。望ましい最大コンパイルオーバヘッドは、一実施形態では、ランタイム中のメソッドのコンパイルや、その他、機械コードへのメソッドの翻訳に費やされる全システムオーバヘッド、例えば中央処理装置（ＣＰＵ）や所用時間の最大％の尺度かもしれない。従って、コンパイルオーバヘッドを確認することは、ランタイムでメソッドをコンパイルするために実際に使用されているシステムオーバヘッドの量の決定を伴う。
【００４０】
コンパイルオーバヘッドは望ましい最大コンパイルオーバヘッドを超えるか否かに関する決定が、ステップ５１４で行なわれる。コンパイルオーバヘッドが望ましい最大コンパイルオーバヘッドを超えると決定された場合は、コンパイルされているメソッドが多すぎることを意味し、プロセスの流れはステップ５１６に移り、そこでしきい値が増加される。しきい値の増加は、メソッドを、そのメソッドのコンパイルが考慮される前に、呼び出すベき回数を増加させるので、通常、コンパイルオーバヘッドの削減に有効である。例として、しきい値が１０００に設定され、かつ実質上すべてのメソッドがプログラム実行の過程で少なくとも１０００回、呼び出される場合、しきい値を１０，０００へ上げることは、コンパイルされそうなメソッドが少なくなるので、より低いコンパイルオーバヘッドをもたらすだろう。しきい値の増加に関連するステップを図６に関して以下により詳しく説明する。一旦、しきい値がステップ５１６で増加されると、コンパイラを実行するプロセスが完了する。
【００４１】
ステップ５１４で、コンパイルオーバヘッドが望ましい最大コンパイルオーバヘッドよりも少ないと決定された場合、しきい値は許容可能と見なされる。すなわち、メソッドのコンパイルとそのコンパイルされたメソッドの実行に伴うオーバヘッドは許容レベルにある、と見なされる。このように、リコンパイラの実行が完了する。
【００４２】
ステップ５０８に戻って、全プログラムの実行に関連するコンパイラはメソッドＭをコーラーとインラインしないだろう、と決定された場合、ステップ５１８で、そのコンパイラがメソッドＭをコンパイルするためにコールされる。メソッドＭのインラインなしの、メソッドＭの単なるコンパイルは、一般に全プログラムに関連するコードの量を削減する。前述のように、メソッドＭのインラインは、本質的にメソッドＭのコピーの作成となる。その結果は、メソッドＭが異なるメソッドによってコールされると、メソッドＭは、結局、異なるメソッドの各々の中でインラインされることになるだろう。従って、メソッドＭに関連するコードのコピーは全プログラムにわたって増大して、インラインされたコードのコンパイルに伴うコンパイルの量が有意になるだろう。従って、一実施形態では、スペースを節約すると共にコンパイルの量を削減するために、メソッドＭが２つ以上のメソッドによってコールされそうな場合、メソッドＭをインラインするのではなく、メソッドＭを単にコンパイルする。メソッドＭがステップ５１８でコンパイルされた後、プロセスの流れはステップ５１２に移り、そこでコンパイルオーバヘッドが確認される。メソッドＭが２つ以上のメソッドによってコールされる可能性があるか否かの決定
は、当業者の承知するように、コールチェーンの調査を伴う。
【００４３】
メソッドＭ用のコーラーが存在するか否かを決定するステップであるステップ５０６へ戻って、メソッドＭ用のコーラーが存在しないか、或いはコーラーの探索中に発見されなかったと決定された場合、プロセスの流れはステップ５１８に進み、そこでメソッドＭがコンパイルされる。コーラーが発見されないときは、メソッドＭは、別のメソッドによるのではなく、ランタイムシステムによってコールされたことを示す。
【００４４】
上述のように、プログラムの全実行に伴うコンパイルオーバヘッドが希望最大オーバヘッドよりも大きい場合は、しきい値を増加させることができる。このような適合しきい値の使用は一般に、しきい値を、必要に応じて特定アプリケーションに対して修正することを可能にする。多くのメソッド又は関数が一定の数の呼出しを超えるアプリケーションでは、対応するしきい値が低すぎる場合、結果は、効率、例えば時間とスペースに関して望ましくないほど高いコンパイルオーバヘッドになるかもしれない。従って、より高いしきい値を設定することが、より望ましい、すなわち、より低いコンパイルオーバヘッドをもたらすだろう。
【００４５】
プログラム実行の過程でしきい値を増すことは、密に連続するメソッドのコンパイルの防止にもなるだろう。例として、比較的多数の異なるメソッドが実質上同時に特定しきい値を超える場合、全プログラムの実行中に休止が起るかもしれない。プログラム実行中の休止は望ましくない場合が多いので、最初の数メソッドをコンパイルした後でしきい値を増加させると、密に連続するコンパイルのシーケンスを防ぎ、それによって明白なコンパイルの休止を実質的に除去する。
【００４６】
次に図６を参照して、しきい値の増加に関連するステップを、本発明の実施形態に従って説明する。言い換えれば、図５のステップ５１６について説明する。言うまでもなく、しきい値がグローバル値である実施形態では、しきい値を増すことはグローバル値の増加を伴う。そうではなく、しきい値がメソッド固有の値の場合は、しきい値を増すことは特定メソッドやメソッドのグループに対するしきい値のみの増加を伴う。
【００４７】
しきい値を増加させるプロセスはステップ６０２で始まり、そこでしきい値がしきい限界（threshold limit）、すなわち上部しきい限界にあるか否かに関する決定が行なわれる。しきい限界は、全プログラムの要件に依存するが、一般に、許容可能と見なされるしきい値に対する最高値である。
【００４８】
しきい値がしきい限界にあるとステップ６０２で決定された場合、記載の実施形態では、しきい値を増加させることはできない。このように、しきい値を増加させるプロセスは完了したと見なされる。例として、既存システムでは、約１０００回の呼出し、ないし約５０，０００回の呼出しのオーダーのしきい限界が適当であろう。そうではなく、ステップ６０２でしきい値はしきい限界にないと決定された場合。しきい値がカレントタイム（current time）期間中に先に上方に調節されていたか否かについての決定が行なわれる。一実施形態では、しきい値がカレントタイム期間中に先に調節されたか否かの決定は、関連インターバル変更フラグが調節は最近行なわれたことを示しているか否かの決定を含む。インターバル変更フラグのセットとクリアのための代表的メカニズムを以下に説明する。
【００４９】
しきい値はカレントタイム期間中、例えば最近の過去にすでに上方に調節されたとステップ６０４で決定された場合、しきい値がそれ以上大きくされることはない。最近に調節されたときは、しきい値をそれ以上増加させないことによって、しきい値を過度の調節から守ることができる。しきい値をそれ以上増加させないとステップ６０４で決定された場合、しきい値を増加させるプロセスは完了したと見なされる。
【００５０】
ステップ６０４で、しきい値はカレントタイム期間中に上方に調節されなかったと決定されたときは、プロセスの流れは６０６に移り、そこでしきい値にしきい値係数が乗算される。しきい値係数は一般に、総合コンピュータプログラムの要件によって大幅に変更できる。例として、約１．２ないし約２のオーダーのしきい値係数が現行システムに対して良好に働くようだ。しきい値にしきい値係数が掛けられてしきい値を増加させた後、インターバル変更フラグがステップ６０８でセットされる。インターバル変更フラグを使って、しきい値がカレントタイム期間中に上方に調節されたことを表示できる。しきい値を増加させるプロセスは、インターバル変更フラグがセットされた後に完了する。
【００５１】
記載の実施形態では、図２（ｂ）に関して上述したように、プログラムの実行の開始はしきい値モニタの実行の開始と並列で起る。すなわち、プログラムが実行している間、しきい値モニタも実行している。図７は、本発明の実施形態による、しきい値モニタの実行の開始に関連するステップ、すなわち図２（ｂ）のステップ２０４を示すプロセス流れ線図である。しきい値モニタの実行はステップ７０２で始まり、そこでタイマ信号が、しきい値モニタによってオペレーティングシステムから受信される。タイマ信号は本質的に、プログラムの実行を周期的に中断するクロック「チック」である。当業者の承知するように、しきい値モニタの実行は、タイマ信号が受信されるまで、中断、すなわち、しきい値は「休眠（asleep）」できる。
【００５２】
一旦、タイマ信号が受信されると、スライディング（sliding）平均が、コンパイルオーバヘッドと解釈オーバヘッドの両者に対してステップ７０４で更新される。言い換えれば、所定期間、例えば最近の過去に費やされた時間の量と解釈に費やされた時間の量は、その期間のいくつかの時間間隔にわたって平均された期間の％として表すことができる。
【００５３】
インターバル変更フラグは、スライディング平均が更新された後、ステップ７０６でリセットされる。インターバル変更フラグのリセットは一般に、しきい値が所定期間中に調節されていないことを示すためのインターバル変更フラグのセッティングを伴う。インターバル変更フラグがリセットされた後、ステップ７０８で、コンパイルオーバヘッドが最大希望コンパイルオーバヘッドを超えるか否かに関する決定が行なわれる。コンパイルオーバヘッドは、最小希望コンパイルオーバヘッドと最大希望コンパイルオーバヘッドの間の範囲に入るように維持することが望ましい。最小希望コンパイルオーバヘッドと最大希望コンパイルオーバヘッドの値は大幅に変更できるが、約５％ないし約２５％の範囲の最小値と、約２０％ないし約６５％の範囲の最大値が一部のシステムで良好に働くことが判明している。ある特定実施形態では、最小希望コンパイルオーバヘッドは所定期間の約１０％にすることができる一方、最大希望コンパイルオーバヘッドは所定期間の約５０にできる。
【００５４】
ステップ７０８で、コンパイルオーバヘッドが最大希望コンパイルオーバヘッドよりも大きいと決定された場合、プロセスの流れはステップ７１６に進み、そこでしきい値、例えばグローバルしきい値を増加させる。しきい値を増すために使用される一つの適当な方法は図に関して先に説明した。一旦、しきい値が増加すると、プロセスの流れはステップ７０２に戻り、そこでプロセスは、オペレーティングシステムから受信される新しいタイマ信号を待つ。
【００５５】
ステップ７０８で、コンパイルオーバヘッドが最大希望コンパイルオーバヘッドより小さいと決定された場合、ステップ７１０で、コンパイルオーバヘッドが最小希望コンパイルオーバヘッドより小さいか否かに関する決定が行なわれる。コンパイルオーバヘッドが最小希望コンパイルオーバヘッドより小さい場合、しきい値は高すぎるかもしれない。このように、コンパイルオーバヘッドが最小希望コンパイルオーバヘッドと最大希望コンパイルオーバヘッドの間に入るようにするために、ステップ７１２でしきい値を減少させる。しきい値の減少は、図８に関して以下に更に詳しく説明するが、しきい値へのより迅速な到達を許すので、メソッドのコンパイルの増加をもたらす。従って、コンパイルオーバヘッドを最小希望コンパイルオーバヘッドの上に増加させることができる。しきい値が減じられた後、プロセスの流れはステップ７０２に戻り、そこでしきい値モニタを実行するプロセスが、タイマ信号を受信するまで本質的に中断される。
【００５６】
コンパイルオーバヘッドが最大希望解釈オーバヘッドと最小希望解釈オーバヘッドの間にあると決定されたときは、ステップ７１４で、解釈オーバヘッドが最大希望解釈オーバヘッドより大きいか否かに関する決定が行なわれる。解釈オーバヘッドを計算するための一つの適当な方法を、図９に関して以下に説明する。
【００５７】
最大希望コンパイルオーバヘッドの場合と同様、最大希望解釈オーバヘッドも大幅に変更できる。更に、最小希望解釈オーバヘッドも大幅に変更可能である。例として、最大希望解釈オーバヘッドは所定期間の約２０％にすることができる一方、最小希望解釈オーバヘッドは所定期間の約５％にできる。一実施形態では、希望解釈オーバヘッドは希望コンパイルオーバヘッドと実質的に同一にできる。
【００５８】
解釈オーバヘッドが最大希望解釈オーバヘッドより大きい場合、図８に関して以下に説明する。プロセスのような任意の適当なプロセスを使って、ステップ７１２でしきい値を減少させる。しきい値の減少は一般に、より多くのメソッドのコンパイルを可能にするので、解釈されるメソッドの数を削減する。それとは別に、解釈オーバヘッドが最大希望解釈オーバヘッドより小さいと決定された場合、ステップ７１８で、解釈オーバヘッドが最小希望解釈オーバヘッドの下に来るか否かが決定される。解釈オーバヘッドが最小希望解釈オーバヘッドより小さいときは、ステップ７１６でしきい値を減少させる。解釈オーバヘッドが最小希望解釈オーバヘッドと最大希望解釈オーバヘッドによって定義される許容解釈オーバヘッドの範囲内にある場合は、しきい値モニタを実行するプロセスがステップ７０２で継続して、そこで新タイマ信号がオペレーティングシステムから受信される。
【００５９】
図８に関して、しきい値の減少に関連するステップ、すなわち図７のステップ７１２を本発明の実施形態に従って説明する。しきい値を減少させるプロセスはステップ８０４で始まり、そこでしきい値が下方しきい限界にあるか否かに関する決定が行なわれる。下方しきい限界は一般に、しきい値として適切と見なされる最低値である。例として、下方しきい限界は大幅に変更可能だが、約１００カウントないし約１０００カウントのオーダーの下方しきい限界が良好に働く。一実施形態では、下方しきい限界は約５００カウント又は呼出しにすることができる。
【００６０】
ステップ８０４で、しきい値が下方しきい限界にあると決定された場合、しきい値を下げてはならないことを意味し、しきい値を減少させるプロセスは完了したと見なされる。そうではなく、ステップ８０４で、しきい値が下方しきい限界にないと決定された場合、ステップ８０８で、しきい値はカレント期間中に先に下方に調節されていたか否かに関する決定が行なわれる。
【００６１】
しきい値が最近の過去又はカレントタイム期間に下方に調節されたと決定される場合は、記載の実施形態では、しきい値をそれ以上減少させてはならない。所定期間に２回以上、しきい値の下方への調節を許さないことで、しきい値の過剰な調節を避けることができる。しきい値をそれ以上減少させるべきでないと決定されたときは、しきい値を減少させるプロセスは完了したと見なされる。
【００６２】
しきい値がカレントタイム期間中に下方に調節されていない場合、プロセスの流れはステップ８０８からステップ８１２に移り、そこでしきい値はしきい値係数によって除算される。しきい値係数は一般に、総合コンピュータプログラムの要件によって大幅に変更できる。一実施形態では、しきい値が除算されるしきい値係数は、しきい値を増加させるときに乗数として用いられる、図６に関して上述した同一のしきい値係数である。一旦、しきい値がしきい値係数によって除されると、インターバル変更フラグがステップ８１６でセットされる。記載の実施形態では、インターバル変更フラグをセットして、しきい値がカレントタイム期間中に下方に調節されたことを示す。インターバル変更フラグがセットされた後、しきい値を減少させるプロセスは完了する。
【００６３】
ランタイム中のプログラムに伴うコンパイルオーバヘッドのモニタに加えて、プログラムに伴う解釈オーバヘッドもモニタされる。解釈オーバヘッドのモニタは本質的に、メソッドの解釈で費やされた全プログラムオーバヘッドの量のモニタを含む。図７に関して前述したように、解釈オーバヘッドをモニタすることによって、少なくとも部分的に、しきい値を上げるべきか下げるべきかが決定される。例えば、解釈オーバヘッドが高すぎる場合は、より多くのメソッドをコンパイルすべきことを意味し、しきい値を減少させて、より多くのメソッドをコンパイルさせることができる。
【００６４】
一般に、任意の適当なプロセスを使って解釈オーバヘッドを計算できる。解釈オーバヘッドを計算するための一つの適当なプロセスを、図９に関して以下に説明する。プロセスはステップ９０４で始まり、そこでタイマ信号がオペレーションシステムから受信される。一旦、タイマ信号が受信されると、アプリケーションプロセスのカレントプログラムカウンタがステップ９０８で取得される。一実施形態では、プログラムカウンタは、全プログラムの実行が現在、解釈されたコードを含むか、或いはコンパイルドコードを含むかを識別するリファレンスである。
【００６５】
一旦、カレントプログラムカウンタが取得されると、プログラムカウンタはステップ９１２でインタープリタをリファレンス、例えば指示、するか否かに関して決定が行なわれる。すなわち、解釈されたコードが現在、実行されているか否かについて決定が行なわれる。プログラムカウンタがインタープリタを指示していないと決定された場合は、プログラムカウンタがコンパイラを指示していることを意味し、解釈オーバヘッドの計算が完了する。ステップ９１２で、プログラムカウンタはインタープリタをリファレンスしないと決定された場合、インタープリタオーバヘッドカウンタがステップ９１６で増分される。最後に、ステップ９１８で、解釈オーバヘッドカウンタを用いて解釈オーバヘッド用のスライディング平均が計算され、解釈オーバヘッドを計算するプロセスが完了する。
【００６６】
図１０は、本発明の実現に適した典型的な汎用コンピュータシステムを示す。コンピュータシステム１０３０は、主記憶装置１０３４（通常、リードオンリーメモリ、又はＲＯＭ）と主記憶装置１０３６（通常、ランダムアクセスメモリ、又はＲＡＭ）とを含むメモリデバイスに連結された任意数のプロセッサ１０３２（中央処理装置、又はＣＰＵとも称する）を含む。
【００６７】
コンピュータシステム１０３０、又はより具体的には、ＣＰＵ１０３２は、当業者の承知するように、バーチャルマシンを支援するように構成できる。コンピュータシステム１０３０上で支援されるバーチャルマシンの一例を、図１１に関して以下に説明する。当技術分野で周知のように、ＲＯＭはデータと命令をＣＰＵ１０３２に一方向的に転送するように働くが、ＲＡＭは通常、データと命令を二方向的に転送するように使用される。ＣＰＵ１０３２は一般に任意数のプロセッサを含んでもよい。主記憶装置１０３４、１０３６は共に、任意の適切なコンピュータ読取り可能媒体を含んでもよい。通常、マスメモリデバイスである二次記憶媒体１０３８もＣＰＵ１０３２に二方向的に連結されて、追加のデータ記憶容量を提供する。マスメモリデバイス１０３８は、コンピュータコード、データ等を含むプログラムの格納のために使用されるコンピュータ読取り可能媒体である。通常、マスメモリデバイス１０３８は、主記憶装置１０３４、１０３６よりも一般に遅いハードディスクやテープ等の記憶媒体である。マスメモリデバイス１０３８は磁気かペーパーテープ読取り装置、又は何らかの他の周知のデバイスの形を取ることができる。マスメモリデバイス１０３８内に保持された情報は、適切な場合は、バーチャルメモリとしてのＲＡＭ１０３６の一部として、標準的な方式で組込みできることは言うまでもない。ＣＤ−ＲＯＭ等の特定の主記憶装置１０３４も、データを一方向的にＣＰＵ１０３２に渡すことができる。
【００６８】
ＣＰＵ１０３２はまた、それらに限定されないが、ビデオモニタ、トラックボール、マウス、キーボード、マイクロホン、接触感知ディスプレイ、トランスデューサカードリーダ、磁気又はペーパーテープ読取り装置、タブレット、スタイラス、音声又は手書き認識装置、その他の周知の入力装置、例えば、勿論、他のコンピュータといった装置を含む一つ以上の入出力装置１０４０に連結される。最後に、ＣＰＵ１０３２はオプションとして、１０１２で概略図示するネットワーク接続を使って、コンピュータ又は遠隔通信ネットワーク、例えばローカルエリアネットワーク、インターネットネットワーク、又はイントラネットネットワークに連結してもよい。このようなネットワーク接続を使って、ＣＰＵ１０３２はネットワークから情報を受信したり、上述したメソッドの各ステップを実行する過程で情報を出力するであろうことが予期される。それらの情報は、ＣＰＵ１０３２を使って実行される一連の情報として表されことが多いが、例えば、搬送波に組み込まれたコンピュータデータ信号の形でネットワークから受信されたり、ネットワークに出力することができる。上述のデバイスと材料は、コンピュータハードウェアとソフトウェアの分野の当業者には周知であろう。
【００６９】
前述のように、バーチャルマシンはコンピュータシステム１０３０上で実行できる。図１１は、図１０のコンピュータシステム１０３０によって支援されて本発明の実現に適したバーチャルマシンの図式表示である。コンピュータプログラム、例えばカリフォルニア州Palo Alto のSun Microsystemsによって開発されたＪａｖａ（商標）プログラミング言語で書かれたコンピュータプログラムが実行されると、ソースコード１１１０がコンパイルタイム環境１１０５内のコンパイラ１１２０に供給される。コンパイラはソースコード１１１０をバイトコード１１３０に翻訳する。一般に、ソースコード１１１０は、それがソフトウェア開発者によって作成される時点でバイトコード１１３０に翻訳される。
【００７０】
バイトコード１１３０は一般に、再生、ダウンロード、或いは別途にネットワーク、例えば図１０のネットワーク１０１２を介して配信されるか、図１０の主記憶装置１０３４等の記憶装置に格納される。記載の実施形態では、バイトコード１１３０はプラットホーム独立形（platform-independent）である。すなわち、バイトコード１１３０は、適切なバーチャルマシン１１４０を実行している実質的に任意のコンピュータシステムで実行できる。例として、Ｊａｖａ（商標）環境では、バイトコード１１３０はＪａｖａ（商標）バーチャルマシンを実行しているコンピュータシステム上で実行できる。
【００７１】
バイトコード１１３０は、バーチャルマシン１１４０を含むランタイム環境１１３５に供給される。ランタイム環境１１３５は一般に、図１０のＣＰＵ１０３２等のプロセッサを使って実行できる。バーチャルマシン１１４０はコンパイラ１１４２、インタープリタ１１４４、及びランタイムシステム１１４６を含む。バイトコード１１３０は一般にコンパイラ１１４２かインタープリタ１１４４のいずれかに供給される。
【００７２】
バイトコード１１３０がコンパイラ１１４２に供給されると、バイトコード１１３０に含まれるメソッドは、上述のように、機械命令にコンパイルされる。他方、バイトコード１１３０がインタープリタ１１４４に供給されると、バイトコード１１３０は一度に１バイトずつインタープリタ１１４４に読み取られる。インタープリタ１１４４は次に、各バイトコードがインタープリタ１１４４に読み取られるに従って、各バイトコードによって定義されるオペレーションを実行する。一般に、インタープリタ１１４４はバイトコード１１３０を処理すると共に、バイトコード１１３０に関連するオペレーションを実質上連続的に実行する。
【００７３】
メソッドがオペレーティングシステム１１６０からコールされると、そのメソッドを、解釈されたメソッドとして呼び出すべきであると決定された場合、ランタイムシステム１１４６はインタープリタ１１４４からそのメソッドを取得できる。他方、そのメソッド、コンパイルされたメソッドとして呼び出すベきであると決定された場合、ランタイムシステム１１４６はコンパイラ１１４６を活性化する。コンパイラ１１４２は次にバイトコード１１３０から機械命令を生成すると共に、その機械語命令を実行する。一般に、機械語命令は、バーチャルマシン１１４０が終了すると放棄される。
【００７４】
本発明の実施形態をごく少数だけ説明したが、本発明は、発明の精神と範囲から逸脱することなく、他の多くの特定形式で具体化できることは言うまでもない。例として、リコンパイラの実行に関連するステップを再整理、除去、又は追加できる。更に、一部の実施形態では、メソッドをそのメソッドのコーラーへインラインするためのオプションを排除できる。一般に、本発明のメソッドに関連するステップを、発明の精神と範囲から逸脱することなく再整理、除去、又は追加できる。
【００７５】
コンパイラの実行を、コンパイラが所定メソッドをコンパイルするか否かの決定、及び所定メソッドのコンパイルに関して説明したが、言うまでもなく、所定メソッドのコンパイルは、その所定メソッドをコンパイルすべき旨の決定の後で遅延できる。多重メソッドが実質上同時にコンパイルされている場合は、所定メソッドのコンパイルは、コンパイルされているメソッドが少なくなるまで、例えばコンパイルオーバヘッドが最小希望コンパイルオーバヘッドの下に来るまで遅延することができる。所定メソッドのコンパイルの遅延は、コンパイルオーバヘッドが最大希望コンパイルオーバヘッドを超えないようにするのに役立つだろう。更に、コンパイルの遅延は、プログラムの実行中の比較的長いコンパイルの休止を防ぐためにも役立つだろう。一実施形態では、プログラム内のメソッドのコンパイルを、プログラムの全実行で休止が存在するまで遅延できる。そのような実施形態では、メソッドは、プログラムの全実行の間の休止、又は活動の低い期間にアクセスされるキューの中に置くことができる。
【００７６】
更に、本発明を、最初に解釈されるすべてのメソッドに関して説明したが、言うまでもなく、バイトコードの形のコンピュータプログラムがランタイム環境に最初に供給されるときは、プログラムに関連する少なくとも一部のメソッドを直ちにコンパイルできる。例えば、希望コンパイルオーバヘッドが、実行の最初からプログラムによって満たされるようにするために、一部のメソッドは最初にコンパイルしてもよいが、他のメソッドは最初、解釈された後、所定の解釈されたメソッドの呼出しの数がしきい値を超えた時点で、その所定の解釈されたメソッドがコンパイルされる。
【００７７】
図３に関して上述した、解釈されたメソッド内に置かれたカウンタは、一般に、メソッド内の任意の場所に置いてもよいが、メソッドの実行中のカウンタへのアクセスは高価になるかもしれない。従って、解釈されたメソッド内にカウンタを置いたときは、カウンタをより容易にカウンタにアクセスできるように、メソッドの最初に置くことができる。実施形態の中には、メソッド内に置かれたカウンタへのアクセスに伴うコストのために、すべてのメソッドに対して単一のグローバルカウンタを使用できるものがある。グローバルカウンタがそのしきい値に達したときは、あたかも現行メソッドがその呼出カウンタのしきい値に達したかのように、現在実行中のメソッドのリコンパイルを考慮することができる。
【００７８】
一般に、カウンタは、そのカウンタを含むメソッドを呼び出す間の任意の時点で増分できる。例えば、カウンタは、メソッド内のループの後方分岐（backward branch）が実行している間に増分できる。ループの後方分岐、又はループ内の実質上任意の場所におけるカウンタの増分は、メソッド内のロングランニングループ（long running loop）の検出を容易にする。ロングランニングループは、メソッドの単一の呼出しの間に繰り返し実行できる。カウンタをループ内、例えばループの後方分岐内に置くことによって、ループの各繰り返しをメソッドの呼出しとしてカウントできるので、大量の実行時間を利用するメソッドのコンパイルをより容易に考慮できる。言うまでもないことだが、メソッドの実行中の、メソッドのカウンタへのアクセスは費用がかかるので、一部の実施形態では、ループ内のカウンタが、メソッド内のカウンタよりも容易にアクセスされる「グローバル」ループカウンタを増分することができる。
【００７９】
「ループカウンタしきい値」を使用する実施形態では、ループカウンタしきい値は上述の呼出しきい値とは異なるかもしれない。ループカウンタしきい値も、異なるしきい値係数によって増減できる。しかしながら、一般に、ループカウンタしきい値は、呼出しきい値と実質的にタンデムで調節されるだろう。
【００８０】
カウンタを、メソッド内に置かれるものとして一般的に説明した。しかしながら、当然のことながら、カウンタをメソッド内に置く代わりに、カウンタを、メソッドが呼び出される度にアクセスできるデータベース又はテーブル中に保持することもできる。その場合、データベース、つまり更に具体的にはデータベース内のカウンタが、本発明の精神と範囲から逸脱することなく、特定カウンタに対応するメソッドが呼び出される度に更新されるだろう。
【００８１】
一般に、本発明によるしきい値は大幅に変更することができる。例えば、１０００のしきい値は一部の実施形態に関しては充分かもしれないが、実質上すべてのメソッドが１０００回以上実行される実行では、それより高いしきい値が適当だろう。同様に、最大と最小の希望コンパイルオーバヘッドも、最大と最小の希望解釈オーバヘッドと共に、特定システムの要件によって大幅に変更できる。
【００８２】
しきい値の値は、様々な要因に基づいて選択できる。上記の要因は、それに限定されないが、プログラム実行の％を含む。言い換えれば、しきい値は、全プログラム実行の所定％、例えば半分以上の割合を占めるメソッドがコンパイルされるように選択できる。例として、しきい値は、全プログラム実行の約９５％を占めるメソッドがコンパイルされるように調節できる。
【００８３】
更に、バイトコード化されたプログラムの最適化を、単一のコンパイルレベルか２つのコンパイルレベルを使って説明したが、バイトコード化されたプログラムの実行に伴うコンパイルレベルの数は一般に、発明の精神と範囲から逸脱することなく、大幅に変更できる。一般に、バイトコード化されたプログラムの実行に伴うコンパイルレベルの数は、それに限定されないが、プログラムの最適化の希望レベルを含む任意数の異なる要因に依存するだろう。各コンパイルレベルは独立のしきい値を持つことができるが、しきい値は実質上すべてのコンパイルレベルに対して同一でもよい。多重コンパイルレベルを含むシステムでは、メソッドが呼び出される度に増分されるカウンタを、各コンパイルされたメソッドの中に置くことができる。これらのカウンタは、上述の解釈されたメソッドの中に置かれたものと同様、コンパイルされたメソッドをリコンパイルするのが適切か否かを決定する場合に使用できる。
【００８４】
メソッドをコンパイルすべきか否かの決定は、そのメソッドに関連するカウンタのしきい値に基づくものとして説明したが、メソッドをコンパイルすべきか否かの決定は、任意数の異なる要因に基づくことができる。例として、全オペレーティングシステムでのタイム「チック」を使って、コンパイルから利益を得る時間浪費のメソッドを発見できる。すなわち、メソッドの実行に伴う時間の量を削減するために、多くのタイムチックの過程にわたって実行するメソッドのコンパイルを考慮することができる。
【００８５】
実行カウンタ、すなわち呼出カウンタは一般に、メソッドがアクセスされる度に増分されるカウンタである。言うまでもなく、実施形態の中には、時間の経過と共に呼出カウンタを減少できるものがある。例えば、メソッドがプログラム実行の最初に繰り返し呼び出されたが、比較的長期間にわたって再び呼び出されていない場合、呼出カウンタを減少させて、後からメソッドが呼び出された場合にそのメソッドがコンパイルされる可能性を削減することができる。一旦、メソッド用の呼出カウンタが減少、例えば指数的に減少したときは、メソッドのコンパイルは最早望ましくないだろう。従って、本例は例示的と見なすべきであって、制限的なものと見なしてはならず、本発明は本明細書に記載の詳細に限定すべきではなく、添付の特許請求項の範囲、ならびに同等仕様の全範囲の中で修正可能である。
【図面の簡単な説明】
【図１】  （ａ）は、バイトコードコンパイラを持つコンピュータシステムのブロック線図であり、（ｂ）は、２つのコンパイルプロセスを使用するコンピュータシステムのブロック線図を示す。
【図２】  （ａ）は、本発明の実施形態による、コードを動的にコンパイルするコンピュータシステムのブロック線図であり、（ｂ）は、本発明の実施形態による、バイトコードの処理に関連するステップを示すプロセス流れ線図を示す。
【図３】  本発明の実施形態による、プログラムの実行に関連するステップ、すなわち図２（ｂ）のステップ２０６を示すプロセス流れ線図である。
【図４】  本発明の実施形態による、メソッドの実行に関連するステップ、すなわち図３ｂのステップ３２０を示すプロセス流れ線図である。
【図５】  本発明の実施形態による、リコンパイラの実行に関連するステップ、すなわち図４のステップ４２０を示すプロセス流れ線図である。
【図６】  本発明の実施形態による、しきい値の増加に関連するステップ、例えば図５のステップ５１６を示すプロセス流れ線図である。
【図７】  本発明の実施形態による、しきい値モニタの実行に関連するステップ、すなわち図２（ｂ）のステップ２０４を示すプロセス流れ線図である。
【図８】  本発明の実施形態による、しきい値の減少に関連するステップ、すなわち図７のステップ７１２を示すプロセス流れ線図である。
【図９】  本発明の実施形態による、解釈オーバヘッドの計算に関連するステップを示すプロセス流れ線図である。
【図１０】  本発明の実現に適した汎用コンピュータシステムの図式表示である。
【図１１】  図１０のコンピュータシステムによって支援されて、本発明の実現に適したバーチャルマシンの図式表示である。
【符号の説明】
１０４…バイトコード、１０５…システム、１０６…コンパイラ、１０８…コンパイルコード、１１４…バイトコード、１１５…システム、１１６…第１コンパイラ、１１８…コンパイルコード、１２０…高度に実行されるコンパイルコード、１２２…第２コンパイラ、１２４…リコンパイルされた高度に実行されるコード、１４４…バイトコード、１４６…システム、１４８…インタープリタ、１５０…コンパイラ、１５４…解釈されたコード、１５８…頻繁に実行されるコード、１６２…コンパイルされた頻繁実行コード、１６６…高度に実行されるコンパイルコード、１７０…追加コンパイラ、１７４…高度に実行されるコンパイルコード、１０１２…ネットワーク、１０３２…プロセッサ、１０３４…主記憶装置、１０３６…ＲＯＭ、１０３８…ネットワーク、１０４０…入出力装置、１１０５…コンパイルタイム環境、１１１０…ソースコード、１１２０…コンパイラ、１１３０…バイトコード、１１３５…ランタイム環境、１１４０…バーチャルマシン、１１４２…コンパイラ、１１４４…インタープリタ、１１４６…ランタイムシステム、１１６０…オペレーティングシステム。
【誤訳訂正２】
【訂正対象書類名】図面
【訂正対象項目名】図３
【訂正方法】変更
【訂正の内容】
【図３】
1999272476.tif 000001
【誤訳訂正３】
【訂正対象書類名】図面
【訂正対象項目名】図４
【訂正方法】変更
【訂正の内容】
【図４】
1999272476.tif 000002
【誤訳訂正４】
【訂正対象書類名】図面
【訂正対象項目名】図５
【訂正方法】変更
【訂正の内容】
【図５】
1999272476.tif 000003