JP2004110824A - マルチプロセッシング環境における透過動的最適化のための方法およびシステム - Google Patents

Abstract

【課題】　広範囲のカテゴリのコードについてマルチプロセッサ・システムの固有の特性を利用できる最適化プロセスを提供すること。
【解決手段】　マルチプロセッシング環境における透過動的最適化の方法（およびシステム）は、システムの他のプロセッサ上で動作している実行モニタにより第１のプロセッサ上のアプリケーションの実行をモニタするステップと、システムの他のプロセッサ上で実行している実行時オプティマイザにより元のアプリケーションの１つまたは複数のセグメントを透過的に最適化するステップとを含む。
【選択図】　図３

Description

　本発明は、一般に、ソフトウェア・システムに関し、より具体的には、このようなシステムのチューニングを改善して、そのパフォーマンスを改善するための方法に関する。

　典型的なソフトウェア・システムの構築は、いくつかのステップを含み、特定のハードウェアおよびソフトウェア構成上で実行するようにチューニングされた連結モジュール（または「実行可能バイナリ」）の生成に終わる。このプロセスは、「静的最適化」として知られ、最適化とともにプログラムをコンパイルし、インストルメンテーションを挿入するステップと、事前構築した実行時ライブラリとの静的または動的結合のステップと、予想ユーザ構成の何らかのサンプルについて、ある範囲の予想ユーザ入力でテストするステップと、テスト中に収集したデータに基づいて最適化を伴う再コンパイルのステップ（これは、「プロファイル指示フィードバックによる最適化」という）とを含むことができる。

　結果的に得られるプログラムは、予想ユーザ構成および入力データの範囲にわたって堅固かつ最適なものになると予想される。しかし、実際には、ユーザ環境のスペクトルは、このようなプログラムがいずれのケースでもその最適パフォーマンスを達成できないほど広範囲になる可能性がある。

　静的技法（すなわち、後続実行のためにコードの微調整を可能にするために動作環境外でのコード実行に関する情報を収集すること）は効率のよいコードを生成するには不十分であることが長い間、認識されてきた。というのは、考えられるすべてのエンドユーザ・データおよびハードウェア構成を表現するテスト・データを生成することは、不可能ではないとしても、困難であるからである。

　しかも、命令レベルの並列性が増し、パイプラインが深まるにつれて、この不十分さはますます苛立たしいものになる。

　静的最適化に代わるものとして「動的最適化」がある。動的最適化は、最適化すべきコードをインストルメントするステップと、それをコンパイルするステップと、それを実行時ライブラリと静的または動的に結合するステップとを含むという点で、プロファイル指示フィードバックを備えた静的最適化と同様のものである。

　しかし、動的最適化は、実際のユーザ・データによるライブ実行中にインストルメント化コードが観察される点と、実行コードがその場で再最適化される（すなわち、このように収集されたプログラム実行に関する情報を同じ実行中に使用して、（同じ動作内の）後続実行のためにコードを再最適化する）点で、静的最適化とは異なる。

　その結果、動的最適化から得られる最適化コードは、静的最適化技法により達成可能なものより効率がよい場合が多い。というのは、たとえば、実際のプログラム使用が示すように、その効率が増すと全体的なパフォーマンスに影響するようなコードのうち、使用頻度が高い部分に最適化を集中させることができるからである。

　そのうえ、動的最適化の場合、顧客が仮説データセットを生成するという労働集約型タスクを実行するための要件はまったくない。

　しかし、従来の動的最適化システムにおける動的最適化の欠点は、実行しなければならない情報収集およびコンパイル作業がアプリケーション・コードの実行によって順次散在し、その結果、アプリケーションの実行時間を増すことである。何らかの恩恵が動的最適化から発生するようにするには、アプリケーションの実行時間内に達成される改善がこの追加コストを上回らなければならない。

　動的最適化の例としては、これまでに提案され、Ｊａｖａ（登録商標）バイトコードの動的コンパイルおよび最適化を実行することによりＪａｖａ（登録商標）アプリケーションの実行を最適化しようとする技法を含む。このような技法の要点は、典型的なバイトコード実行がほとんどのコンパイル済みアプリケーションより大幅に遅いので、実行時処理のオーバヘッドが実行の適度な改善によって吸収可能であることである。このような機会は、高度に最適化した非Ｊａｖａ（登録商標）（バイナリ・コード）アプリケーションの実行時には滅多に得られないものである。

　しかも、メソッド呼出しの最適化など、使用する技法の多くは、一般に適用不能である。

　HPL 1999-1978 990621におけるV. Bala他の「Transparent Dynamic Optimization: the design and implementation ofDynamo」という論文に記載されているような他のプロジェクトでは、結果として得られる実行時間の改善によってオーバヘッドに報いることができると想定して、命令キャッシュの局所性を改善するようにコード・レイアウトを再整理することにより、実行時パフォーマンスを動的に改善する問題に対処している。

　しかし、このダイナモ技法では、インストルメンテーション情報を利用せず、しかも、ユニプロセッサ・システム用に設計されているので、マルチプロセッサ・アプリケーションを考慮していない。

　しかし、現在のコンピュータ・システムは通常、複数のプロセッサからなる。ロー・エンドでも、シングルチップ・マルチプロセッサが普及しつつある。また、このような構成の多くでは、そのプロセッサのうちの少なくとも１つが十分に利用されないケースが頻繁になっている。マルチプロセッサ機能を活用してプログラム実行を改善しようというこれまでの試みは、アプリケーションの自動並列化などの技法に集中していた。このような技法は様々な理由で成功が限られており、そのうちの最も重要なものは、自動並列化が数値集約型アプリケーション、特にフォートランで作成されたものに最も関連することと、通常はＣで作成される商用トランザクション処理アプリケーションがこの手法にあまり適していないことが分かっていることと、より規則正しいタイプのコードの場合でも自動並列化は実際に実現するのが困難であることが分かっていることである。

　したがって、明らかに、広範囲のカテゴリのコードについてマルチプロセッサ・システムの固有の特性を利用できる最適化プロセスが必要になっている。
HPL 1999-1978990621におけるV. Bala他の「Transparent Dynamic Optimization: thedesign and implementation of Dynamo」という論文 １９９６年１２月発行のProceedingsof MICRO 1996に掲載されたBall他による「Efficient Path Profiling」という論文

　従来の方法および構造の上記その他の問題、欠点、短所を考慮して、本発明の一目的は、１つまたは複数のアイドル状態または十分に利用されていないプロセッサの便宜的使用を利用することにより、マルチプロセッサ・システムにおいて改善されたプログラム実行効率を提供することにある。

　本発明の他の目的は、システムのユーザにとって透過的な方法で、その実行特性を学習し、この知識を応用して現行ホスト・システム上の実行挙動をチューニングし強化することにより、ソフトウェア・システムのパフォーマンスを改善することにある。

　具体的には、本発明は、最適化すべきアプリケーションの実行を妨げずに、対称型または分散形マルチプロセッサ・システムにおいて使用可能なサイクルを使用してこのパフォーマンス強化を実施することにより、従来の方法およびシステムに改良を加えようとするものである。

　本発明の第１の態様では、マルチプロセッシング環境における透過動的最適化の方法（およびシステム）は、システムの他のプロセッサ上で動作している実行モニタにより第１のプロセッサ上のアプリケーションの実行をモニタするステップと、システムの他のプロセッサ上で実行している実行時オプティマイザにより元のアプリケーションの１つまたは複数のセグメントを透過的に最適化するステップとを含む。

　本発明の第２の態様では、マルチプロセッサ・コンピューティング環境がその実行環境についてアプリケーションの同時動的最適化を実行するための方法は、システム内の第１のプロセッサ上でアプリケーションのインストルメント化コピーを実行するステップと、システムの他のプロセッサ上で動作している実行モニタによりアプリケーションの実行をモニタするステップであって、そのモニタがアプリケーションのインストルメント化コピーに含まれるインストルメンテーション・コードを実行することにより生成された実行特性に関して実行されるステップと、システムの他のプロセッサ上で実行している実行時オプティマイザにより元のアプリケーションの１つまたは複数のセグメントを最適化するステップであって、その最適化が、同時に実行中のアプリケーションへのパフォーマンス上の影響なしに、実行モニタによって収集された実行特性に関して実行されるステップと、１つまたは複数のセグメントを最新最適化セグメントで置き換えることにより元の実行アプリケーションを変更するステップであって、その変更がアプリケーションのユーザにとって透過的な方法で実行されるステップとを含む。

　本発明の第３の態様では、マルチプロセッサ・システム内でその実行環境についてアプリケーションの同時動的最適化を実行するための方法は、個別プロセッサ内でまたは複数プロセッサにわたって動作している個別プロセスとして動作している実行モニタにより、第１のプロセッサ内で動作しているプログラムまたはアプリケーションのそれぞれの実行をモニタするステップと、それが実行しているバイナリ・コードにより、そのバイナリ・コードの実行特性のプロファイル・データを作成するステップであって、そのバイナリ・コードがパフォーマンスをモニタするためのインストルメンテーション・コードを含むステップと、実行モニタにより、そのプロファイル・データを連続的に評価するステップと、所与のしきい条件を満足するときに、動的オプティマイザを呼び出して、頻繁に実行するコード・フラグメントを最適化するステップとを含み、その後続実行で使用するために実行中の命令ストリームにその最適化コード・フラグメントが挿入される。

　本発明の第４の態様では、共用マルチプロセッシング（ＳＭＰ）システム内の透過動的最適化の方法は、第１のプロセッサ上でアプリケーション・バイナリを実行するステップと、システム内の他のプロセッサ上で実行の挙動をモニタするステップと、アプリケーション・バイナリが実行されている間にアプリケーション・バイナリの実行を最適化するステップとを含む。

　本発明の第５の態様では、マルチプロセッシング・システム内の透過動的最適化のためのシステムは、第１のプロセッサ上でアプリケーション・バイナリの実行をモニタするための実行モニタであって、システムの他のプロセッサ上で動作する実行モニタを含み、その実行モニタが、モニタと同時に、元のアプリケーション・バイナリの１つまたは複数のセグメントを最適化するための動的オプティマイザを含み、その動的オプティマイザがシステムの他のプロセッサ上で実行される。

　本発明の第６の態様では、マルチプロセッシング・システム内の透過動的最適化の方法を実行するためにディジタル処理装置により実行可能な複数の機械可読命令からなるプログラムを具体的に実施する信号運搬媒体であって、その方法は、システムの他のプロセッサ上で動作している実行モニタにより、第１のプロセッサ上でアプリケーション・バイナリの実行をモニタするステップと、システムの他のプロセッサ上で実行される実行時オプティマイザにより、元のアプリケーション・バイナリの１つまたは複数のセグメントを透過的に最適化するステップとを含む。

　したがって、本発明によれば、好ましくは、マルチプロセッシング・システム内の余分な処理サイクルを使用して、実行中のアプリケーションの実行特性を観察し、その動作中のシステムを透過的に変更して、そのパフォーマンスを大幅に改善する。

　好ましくは、プログラムまたはアプリケーションのそれぞれの実行は、個別プロセッサ内でまたは複数プロセッサにわたって動作している個別プロセスとして動作している実行モニタにより、「シャドウ化」される。それが実行しているときに、パフォーマンスをモニタするように設計されたインストルメンテーション・コードを含むバイナリ・コードは、その実行特性のプロファイルを作成する。その実行モニタは、そのプロファイル・データを連続的に評価し、所与のしきい条件を満足するときに、本発明の動的オプティマイザを呼び出して、頻繁に実行するコード・フラグメントを最適化（または再最適化）し、次にそれは後続実行時に使用される実行中の命令ストリームに挿入される。新たに挿入したコード・フラグメントは、いかなるインストルメンテーションも含まなくなるか、またはアプリケーションの実行特性におけるその他の変更を検出するために「再インストルメント化」されている可能性がある。

　本発明は、Ｊａｖａ（登録商標）バイトコードとは対照的なバイナリ実行可能コードに上記の技法を適用するものであり、そのコードは、解釈されたときから、最適化のコストを償却するのに十分な低速で実行される。（それにもかかわらず、この技法はバイトコード・アプリケーションにも効果的である。）すなわち、このバイナリは、それが動作している間に、共用マルチプロセッサ（ＳＭＰ）システム内の他のプロセッサ上で、実行の挙動をモニタし、それが実行されている間に個別プロセッサ上でそれを最適化できるようにインストルメント化される。

　上記その他の目的、態様、および長所は、添付図面に関連して以下に示す本発明の好ましい実施形態の詳細な説明からより十分に理解されるだろう。

　次に、添付図面、より具体的には図１〜１０を参照すると、本発明による方法および構造の好ましい実施形態が示されている。

　一般に、本発明は、マルチプロセッサ・システム上のプログラムの実行についてパフォーマンス上の大幅な改善を達成するために新しいやり方でマルチプロセッシング機能を活用するものである。純粋に静的なコンパイラは一般に、プログラム内のすべての経路が均等に取られる可能性があるものと想定し、したがって、通常は、考えられるすべての経路を同程度に最適化する。しかし、実際には一部の経路がより頻繁に取られる可能性があるので、あまり頻繁に取られない経路を減速するという犠牲を払っても、最適化のために主要経路を選択した場合に最適化がより有益になる可能性がある。

　これに対して、純粋に動的なコンパイラ（Ｊａｖａ（登録商標）バイトコード・プログラム用のほとんどのジャストインタイム（ＪＩＴ）コンパイラなど）は、あるプログラムの現在の実行に関する詳細情報について処理している間に、狭い時間ウィンドウ内でこの知能を使用する必要がある切迫した事情によって著しく阻害される。

　以下で明らかになるように、本発明は、既知の動的コンパイラを超える２つの長所を有する。

　第１に、事実上、そのマルチプロセッサ設計のために、このような制約付きの持続期間内に動作する必要はない。さらに、実行中のプログラム分析に関する要件を削減するために、最適化動作を実行しながら、静的最適化出力を使用することができる。

　さらに、本質的に、あまり遠くない将来のすべてのシステムはシングルチップ・マルチプロセッサから構築されると予想され、したがって、本発明の手法は独自に関連するものになる。

　ここに記載すべき本発明の好ましい実施形態では、コード実行をモニタし、収集した実行情報に基づいてコードを最適化し、最適化コードをプログラムに再挿入するための方法を含む動的実行時最適化システム（または「動的オプティマイザ」）は、連続的に動作している実行モニタの制御下でサブスレッドまたはプロセスとして、モニタ中のプログラムを実行するプロセッサ（またはプロセッサ・グループ）とは別のプロセッサ（またはプロセッサ・グループ）内で実行される可能性があるものと想定する。

　さらに、最適化すべき実行コードは、たとえば、１９９６年１２月発行のProceedings of MICRO 1996に掲載されたBall他による「EfficientPath Profiling」という論文に記載された技法を使用して、インストルメンテーション・コードを組み込むようにコンパイルされたものになる。したがって、本発明では、実行バイナリ・コードは当技術分野で周知のように、すでに（たとえば、静的または動的に）インストルメント化されているものと想定する。

　本発明の主な焦点は、新規の方法でそのインストルメンテーション・コードによって生成された情報を活用することである。

　上記で概略を示した説明ではＳＭＰ環境を想定しているが、本発明は、分散共用メモリを介して通信する１つまたは複数のプロセッサからなるクラスタから構成されるコンピュータ・システムにも適用されることに留意されたい。このような構成では、動的最適化システムは、最適化すべきコードを実行しているノードまたはプロセッサとは別個のものである限り、そのクラスタ内の単一（または複数）のノード（複数も可）上かあるいはクラスタ内の１つのノードの１つ（または複数）のプロセッサ上で実行されることになるだろう。

　以下では図１に関連して本発明を詳細に説明するが、同図では、マルチプロセッシング・ハードウェア・システム１００上で動作する動的オプティマイザを示している。

　マルチプロセッシング・システム１００は、２つ以上の任意の数のプロセッサ１０１ａ、１０１ｂなどを含むことができ、各プロセッサは図１ではそれぞれ１〜ｎ＋１と表示されている。各プロセッサはそれ専用のローカル・メモリ（図１には図示せず）を有することができ、すべてのプロセッサは共用メイン・メモリ１０２を介して通信することができる。このシステムは、スレッド・スケジューリング・パッケージを含むかまたはサポートするオペレーティング・システム１０３によって制御される。

　本発明の動的最適化プロセス下で実行されるすべてのインストルメント化プログラム（たとえば、実行バイナリ）について、以下に詳述する実行モニタ１０４において同時実行モニタ・スレッドが創出される。

　実行モニタ・スレッドの目的は、所与の実行インストルメント化バイナリの実行挙動を分析し、さらにこの分析に対して、それを生成するために要する時間を短縮しながら、アプリケーションの予想出力を保存する変更（最適化）を加えることである。この（モニタ）スレッドは、それがモニタしているアプリケーションと同じ長さだけ実行される。

　したがって、図１は、実アプリケーションを実行しており、そのそれぞれが潜在的に他のすべてのプロセッサとは別個のものである１〜ｎ個のプロセッサと、少なくとも１つの他のプロセッサｎ＋１（たとえば、ｎ＋２など他の複数のプロセッサが可能であるが、簡潔さのため１つのみ図示されている）が存在することを示している。プロセッサ１〜ｎ上で実行されるそれぞれのインストルメント化バイナリに対し、１つの実行モニタ１０４が関連付けられている。これらはすべてがプロセッサｎ＋１上のみで動作する必要はない。これらは、このような実行モニタ１０４がいくつのリソースを使い果たすかに応じて、異なるプロセッサ（複数も可）上で動作することができる。しかし、実行モニタの数と、プロセッサ１〜ｎ上で実行されるインストルメント化バイナリの数の間には、１対１の関係がある。

　ＳＭＰの複数のプロセッサ上で複数のインストルメント化バイナリが実行される可能性があることに留意されたい。ここに記載する関係は、このようなインストルメント化バイナリとそれ自体の「シャドウ」プロセスとの間のもの（たとえば、以下に記載し、参照番号２０１ａおよび２０５によって図２に示すもの）である。これは、本発明が関連し、有利に使用する１対１の関係であり、本発明では、所与のインストルメント化バイナリに関するシャドウ・プロセスが個別プロセッサ上で実行されることだけが必要である。

　したがって、プロセッサ１（１０１ａ）がそのバイナリを実行すると、プロセッサ１の実行の特性が専用実行モニタ１０４によって観察される。

　図２は、第１のプロセッサ２０１上で実行している、最適化すべきインストルメント化バイナリ・アプリケーション２０１ａと、インストルメント化バイナリ・アプリケーション２０１ａの実行をモニタする実行モニタ・スレッド２０５との間の対話の概念図２００であり、実行モニタは、プロセッサ２０１とは別個のプロセッサ２０３上で実行される。

　図２では、実行インストルメント化バイナリは長期間にわたって実行される、かなり大型のシステムからなる可能性がある。この場合、実行インストルメント化バイナリをモニタし、実行中にそれを変更するための方法は「シャドウ」プロセスという。このシャドウ・プロセスは、実行モニタと、動的オプティマイザと、フラグメント・テーブル（またはキャッシュ）マネージャとを使用することを含む。インストルメント化バイナリの始動時に、この「シャドウ」プロセスはフォークされ、インストルメント化バイナリまたはアプリケーションの実行の持続期間の間、実行し続ける。

　シャドウ・プロセス２０５は、フラグメント・キャッシュ２０１ｂも含む。フラグメント・キャッシュ２０１ｂはシャドウ・プロセスのソフトウェア・アーチファクトであり、実行コード・ストリーム内にそれを再挿入するまで最適化後のコード・フラグメントを記憶するために使用するものであることに留意されたい。このデータ構造のサイズは重要であり、これはインストルメント化バイナリ・アプリケーション２０１ａの動的再最適化フラグメントを記憶するために「フラグメント・キャッシュ・マネージャ」によって管理される。

　これらの「フラグメント」は、頻繁に実行される複数命令のシーケンス（インストルメンテーション・コードによって生成されるインストルメンテーションの分析に基づいて、実行モニタ・スレッドが決定したもの）であり、その後、アプリケーションの一部としてプロセッサ２０１によって実行可能であり、そのフラグメントの最適化の結果として、より効率よくプログラム実行が行われる可能性があると判定されたときに、「シャドウ」プロセスの実行またはプロファイル・モニタ・ステップ（２０４）中に選択されたものである。

　実行バイナリのうち、選択された部分だけがフラグメント・キャッシュ２０１ｂに記憶されることに留意されたい。これらの部分は、インストルメンテーションの出力に基づいて選択される。本質的に、これらは頻繁に実行される複数命令のシーケンスを含み、いくつかの追加または削除は最適化機能によって必要かつ受入可能なものと見なされる。

　この実行またはプロファイル・モニタ２０４は、プログラムを通る特定の経路を実行した回数を含む、様々な特性をモニタすることができる。このため、ある経路を何度も（たとえば、１０００回以上）実行した場合、このモニタがフラグメント・マネージャ２０２をトリガし、この経路に関する何かを実行し始め、この特定の１つのコードについて（後述する動的オプティマイザ２０７を使用して）最適化プロセスを開始する。

　したがって、プロセッサ２０３は、インストルメント化バイナリ・アプリケーションから選択したフラグメントを最適化するためにシャドウ・プロセス・スレッド２０５の一部として動的オプティマイザ・スレッド２０７も実行し、フラグメント・マネージャ２０２を介してフラグメント・キャッシュ２０１ｂに最適化フラグメントを戻す。

　プログラムの経路が実行された回数と、このような実行の発生回数がしきい回数（たとえば、１００１回以上）を超えているかどうかをモニタすることに関する上記の例に関連して、フラグメント・マネージャ２０２は、動的オプティマイザ２０７による最適化（または再最適化）のためにフラグメント・キャッシュ２０１ｂからその経路（たとえば、実行バイナリの一部または「フラグメント」であって、比較的小さいひとかたまりのコードである）またはその経路の一部分を抽出するように動作する。

　このため、フラグメントは取り出され、最適化され、次に動作中のバイナリ内に置き換えられる（戻される）。フラグメント・マネージャ２０２は、経路のどの部分を最適化すべきかを決定する。これは、経路全体ではない可能性がある。フラグメント・マネージャ２０２は、命令（複数も可）のコピーを作成し、オプティマイザ２０７がそのコピーを調べ、そのコピーに変更を加えることができるようにその命令を記憶することにより、経路のその部分を「抽出」する。

　このため、フラグメント・マネージャ２０２は、このような最適化を実行するよう、オプティマイザ２０７に「指示」し、フラグメント・マネージャ２０２がそのフラグメントに関連すると確信するプロファイル情報をオプティマイザに与える。その場合、オプティマイザは、そのフラグメントについて作業してそれを最適化する（たとえば、それをより高速かつより効率的にするためにコードをリオーダする）ことになり、実行後にフラグメント・マネージャ２０２に通知することになる。次に、フラグメント・マネージャ２０２は、それ自体の内部テーブルに記憶されたデータを使用して、プロセッサ１（２０１）内の元の実行バイナリに最適化フラグメントを再挿入するための正確な論理位置を決定する。

　次に、最適化フラグメントはプロセッサ１（２０１）上のフラグメント・キャッシュ２０１ｂ内に置かれ、フラグメント・マネージャ２０２は、実行バイナリで実行するために同じ経路（命令（複数も可））（または、場合により、経路の一部分）が次に検出されたときに、元の実行バイナリ内のコードではなく、フラグメント・キャッシュ２０１ｂ内のコードが実行のために採集されるように、実行バイナリを変更することになる。

　第１の事例のフラグメント・マネージャ２０２は、インストルメント化実行バイナリ２０１ａから直接、その経路を抽出することになるが、その後の段階（たとえば、その経路の再最適化）では、フラグメント・マネージャ２０２は、インストルメント化実行バイナリ２０１ａから直接ではなく、フラグメント・キャッシュ２０１ｂからそれを抽出することになると思われることに留意されたい。

　このため、フラグメントは、元のバイナリ（または、その後、動的最適化バイナリ）内の実コード・シーケンスとして、ならびに、動的オプティマイザが生成した再挿入最適化コード・シーケンスとしてという２通りの形式で現れる可能性がある。後者はフラグメント・キャッシュ２０１ｂ内に現れ、前者は（上記の括弧内のケースを除く）元のアプリケーション内に現れる。各実行インストルメント化バイナリ・アプリケーションの場合、実行モニタ・スレッド（シャドウ・プロセス・スレッド）２０５の１つの事例が存在することになり、所与のインストルメント化バイナリ・アプリケーション用の実行モニタはここではその「モニタ・スレッド」という。

　実行モニタ（またはシャドウ・プロセス）スレッド２０５の動作は、アプリケーションと並列だが、アプリケーションには知られずに進行し、その実行は、それ自体の実行特性を特徴づけるプロファイル・ストリームの生成を除き、変化なしで進行する。

　「実行特性」は、実行の副作用としてインストルメント化バイナリによって生成されるプロファイル・データを表すことに留意されたい。

　さらに、フラグメント・キャッシュ２０１ｂは、共用メモリ内に存在し、実行モニタ・スレッド２０５のフラグメント・マネージャ２０２によって割り振られ制御される、データ構造またはテーブルにすぎないことに留意されたい。上記の通り、フラグメントは、その実行特性により、それが（再）最適化の潜在的可能性になっている命令シーケンスであり、この命令シーケンスは、実行モニタ（シャドウ・プロセス）２０５により実行バイナリから抽出され、最適化され、その後、そのバイナリに再挿入するためにフラグメント・キャッシュに記憶されることになる。

　さらに、目標は、これらのフラグメントを最適化して、実行バイナリに再挿入することなので、それらがフラグメント・キャッシュ２０１ｂに存在することは過渡的なものであり、標準的な技法を使用してその記憶を管理し再利用することに留意されたい。

　図３は、本発明の動的最適化プロセスに関連して図２のシステムが実行する方法３００の諸ステップを示す流れ図である。

　方法３００では、インストルメント化バイナリをプロセッサ２０１にロードすると、フォークを実行して、図２のプロセッサ２０３（ｎ＋１）で実行モニタ・スレッドを始動する（ステップ３００Ａ）。

　さらに、インストルメント化バイナリ・アプリケーションをロードすると、プロセッサ２０１上でのインストルメント化バイナリ・アプリケーションの実行と同時に図２のプロセッサ２０３（ｎ＋１）上で実行するために、ステップ３０１で実行モニタ・スレッドを創出（フォーク）する。前述の通り、実行モニタ・スレッドは、インストルメント化バイナリの実行を監視またはモニタするので、「シャドウ・スレッド」ともいう。

　シャドウ・プロセス（実行モニタ）スレッドの創出は、ＦＯＲＫまたは何らかのこのようなオペレーティング・システム（ＯＳ）プリミティブの実行によって実施される。この場合も、この活動の並列性に注目する。プロセッサ２０１上で動作しているインストルメント化バイナリ・アプリケーションがこの分析および最適化プロセスに気づかず、したがって、（前述のダイナモまたはＪａｖａ（登録商標）ＪＩＴケースとは異なり）決して待つ必要がないという点で、この並列性は、より積極的な技法を可能にし、タイミング・エラーを帳消しにするので、重要なものである。インストルメント化バイナリ・アプリケーションはベンチマーキング用に設計されたプログラムにすることが可能であるが、このシステムによる実際の恩恵は、実際のユーザ・データを実行して、実際のユーザ・アプリケーションとともに使用したときに達成される。

　インストルメント化バイナリの実行の一部として実行されるステップ３０２では、実行プロファイルを生成する。この実行プロファイルは、実行バイナリ（または動作中のプログラム）の実行特性を記述したものである。このような特性は、バイナリ・アプリケーションに挿入された特定のインストルメンテーション・コードによって決定される。モニタするためにインストルメンテーション・コードを設計可能な特性の例としては、アプリケーション内の特定のループが実行される回数、またはより具体的には、特定の経路またはコード・ブロックのシーケンスが実行される回数を含む。

　プロファイル・データは共用メモリ内のインストルメント化アプリケーションによって生成され、シャドウ・プロセス（実行モニタ）スレッドは同じ共用メモリ位置からそれを読み出すことに留意されたい。モニタ・スレッドはいずれのプロファイル・カウンタの絶対値にも決定的に依存しているわけではなく（たとえば、あるループの１００００回の実行と、１０００１回または１１０００回は著しく異なっているわけではない）、したがって、アプリケーション・スレッドとモニタ・スレッドの間にロックまたはその他の同期を設ける必要はない。

　後述するように、情報は、生成されるにつれて、連続的に提供される。このため、これは動的プロセスであり、そのため、実行が行われている間に実行コードを実際に変更できるように、情報が連続的に提供される。

　このため、プロセッサ２０３上で動作する図２の実行モニタ・スレッド２０５により、生成されたプロファイル情報（たとえば、「実行特性」ともいう）をステップ３０２で連続的にモニタするが、モニタ・スレッド２０５は現在検査中のインストルメント化バイナリ・アプリケーションに排他的に関連付けられている。

　現在の実施形態を説明するために、モニタ・スレッドは、検査中のインストルメント化バイナリ・アプリケーションを実行しているプロセッサとは別個の単一プロセッサ上で動作するものと想定する。しかし、本発明は、複数プロセッサがインストルメント化バイナリ・アプリケーションを実行しているプロセッサとは別個のものである限り、その複数プロセッサにわたってモニタ・スレッドを実行可能であると企図するものである。

　ステップ３０４では、シャドウ・プロセス（実行モニタ）２０５は、生成したプロファイル・データを検査して、しきい条件を満足しているかどうかを判定する。このため、この例示的実施形態では、カウンタまたは増分器／減分器を使用することができるだろう。別法として、他の実施形態では、他の構造を使用することができるだろう。たとえば、カウンタと他の何らかの装置の組合せ（または全カウンタの合計が所与の値になり、それが所与の条件を示すようなカウンタの組合せ）は、どのしきい値を測定中であるか、あるいは測定中の条件またはしきい値の複雑さなどに応じて、使用することができるだろう。通常、使用するしきい値は、インストルメンテーションを挿入したときに設定され、実行時に減分されるので、ゼロに達すると、オプティマイザ２０７の呼出しがトリガされる。さらに、通常、「しきい値」は、測定中の他の何らかのタイプの値とは対照的に、何らかのタイプのカウントまたは数（たとえば、同じコードを検出した回数など）に関連付けられることになる。

　オプティマイザ２０７は、好ましくは、汎用コンパイラ・オプティマイザの一形式である。このオプティマイザは、実行時に実行しており、このため、典型的なコンパイル時オプティマイザより短い時間で実行しなければならないことに気づいているが、それ以外には、決してそれが最適化しているバイナリ・アプリケーション専用のものではない。

　動的オプティマイザ２０７は通常、操作するためにそれが呼び出された「フラグメント」を含む特定の命令シーケンスを分析し、たとえば、基礎をなすハードウェアがそのコードのコンパイル対象であった特定のモデルではない場合に発生しうる待ち時間をカバーするように命令シーケンスをグループ化し直すことにより、パフォーマンスを改善する。動的オプティマイザ２０７は通常、動的コンパイル・システムとともにあらかじめパッケージ化される。たとえば、これは、コンピュータのオペレーティング・システム（ＯＳ）の一部として出荷される可能性もある。

　いずれのしきい値にも達しない限り、モニタ・スレッド２０５は、インストルメント化出力を検査し続けることになる。

　あるしきい値に達した場合、ステップ３０６では、バイナリ・アプリケーションのうち、そのしきい値に達する原因になった部分をインストルメント化バイナリから抽出し（たとえば、フラグメント・マネージャ２０２によってコピーし）、最適化のために動的オプティマイザ２０７に送り、元の（未再最適化）フラグメントが本来実行されたと思われるときに、最適化のあとで今後の使用のためにフラグメント・キャッシュ２０１ｂに記憶する。

　次に、ステップ３０８では、オプティマイザ２０７によりそのフラグメントを最適化する。前述の通り、適用される最適化プロセスは、実行時のコード・シーケンスの最適化に適用可能な、いくつかの標準的な最適化技法の１つである。好ましいタイプの最適化は、コンパイル時に静的に既知ではない情報を活用するもの（たとえば、所与の変数が実行時に一定値を有するもの）である。

　そのうえ、それが実際は仮定値を有するという証拠の優越性に基づいて、所与の変数が一定値を有すると推測する最適化を実行することができる。当然のことながら、このような場合、その推測が間違っている場合に備えなければならない。このような考慮は当技術分野では既知のものであるが、この場合、本発明者らは新しい情況でそれを適用することに留意されたい。

　最適化は、たとえば、頻繁に実行されるコード経路からの不必要な分岐の除去、またはそれが現在動作している特定のネットワーク・ノードのアーキテクチャ上の全能力を活用するようにアプリケーションを専門化することを含むことができる。

　基本的に、あるマシンの旧モデル（またはより安価なマシン）上で動作するようにアプリケーションをコンパイルし、そのアプリケーションが現在の事例でそれ以降のマシン（またはより高価なハイエンド・マシン）上で動作している場合、さらに最適化を行う機会がある可能性がある。

　たとえば、新しくより強力な命令が存在する可能性があるか、または、そのアプリケーションの当初のコンパイル対象であったものを上回る命令レベルの並列性（たとえば、より多くの機能ユニット）を現行マシンが有する可能性がある。このような不測の事態（しかもネットワーク化世界では、ますます起こりそうなものになっている）の結果、動的再最適化の重要な機会が得られることになる。したがって、これにより、これらの技法を適用するためのもう１つの理由が得られる。

　すなわち、ネットワーク化世界では、特定のアーキテクチャの最低共通項モデル用にコンパイルするための強い動機が存在する。というのは、そのアプリケーションがネットワーク内の大部分のコンピュータ上で動作可能であるからである。しかし、これは最適化のレベルを下げる（したがって、パフォーマンスを低減する）ための動機をもたらし、本発明の技法は、このようなアプリケーションの実行時間を改善する際に得に有用と思われる。

　図３の方法３００は任意選択で、後続のモニタを可能にするためにインストルメンテーション・コードを最適化フラグメントに挿入できるようにする。このようなインストルメンテーション・コードのフラグメントへの自動挿入は周知のものと確信しているので、簡潔さのため、本明細書ではこれ以上説明しない。（とりわけ）前述のＢａｌａ他の論文では、インストルメンテーションの挿入方法を教示している。

　動的オプティマイザ２０７によるステップ３０８の最適化後、ステップ３１０で最適化フラグメントをフラグメント・キャッシュ２０１ｂに記憶する。

　次に、ステップ３１２では、非最適化バージョンの代わりに最適化フラグメントをインストルメント化バイナリに挿入するので、今後、インストルメント化バイナリを後で実行したときに、それはインストルメント化バイナリの一部として実行されることになる。

　この挿入動作は、たとえば、元のバイナリにパッチを当てて、新たな最適化フラグメントに分岐することにより実行することができ、その最適化フラグメントは、当然のことながら、元の（抽出した）フラグメントに続く命令に分岐して戻る必要があるだろう。本発明を全体として解釈すると、当業者には明白になるように、他の技法も使用することができるだろう。

　任意選択で、インストルメンテーション・コードは、バイナリ・アプリケーションに挿入する前にフラグメントから除去することができる。これに関して、インストルメンテーション・コードは、実際には再挿入されないので、それ自体は除去されない。インストルメンテーションはすっかり様式化され、容易に認識されるので、アプリケーション・コードはインストルメンテーションとは容易に区別することができ、したがって、回避するのは難しいことではない。この通りではない場合でも、インストルメント・エージェントによりインストルメンテーションの位置を既知の（または発見可能な）位置に記録させることは難しいことではないだろう。

　ステップ３１２で最適化フラグメントを実行バイナリに挿入した後、ステップ３１３では、インストルメント化バイナリが依然として実行中であるかどうかを判定する。インストルメント化バイナリが依然として実行中である場合（たとえば、ステップ３１３で「ＹＥＳ」）、プロセスはステップ３０２にループバックする。インストルメント化バイナリが実行中ではない場合（たとえば、ステップ３１３で「ＮＯ」）、プロセスはステップ３１４に移行する。

　ステップ３１４では、インストルメント化バイナリと実行モニタ（シャドウ・スレッド）の実行が終了する。

　したがって、バイナリとシャドウ・スレッドの実行が一斉に終了する。実際は、本発明の重要な特徴の１つは、すべてのステップが実行中に行われることである。

　前述の通り、図３に示す２本の縦の流れは並列動作であることに留意されたい。

　次に、図４に関連して本発明の他の実施形態について述べるが、これは図３のプロセスの改良版であり、特に図３のステップ３０８で使用することができる。

　すなわち、図３のステップ３０８では、動的オプティマイザ２０７がフラグメントを検査し、これを分析して、そのフラグメントを最適化するためにどの最適化を実行することができるかを決定する。最適化するためのこの決定は、その時点で動的オプティマイザが何を観察できるかだけに基づくものである。

　図４の方法４００では、動的オプティマイザ２０７により、より良好な最適化を実行するために、追加の諸ステップを行う。これに関して、オプティマイザがこのような情報そのものを計算する必要なしに、オプティマイザがより迅速に動作できるように、ステップ３０８で動的オプティマイザ２０７に追加情報を提供する。しかも、おそらくオプティマイザには、本来は独力で抽出することが困難であると判断されうるような情報を提供することができる。

　具体的には、図４は、アプリケーション・プログラムの静的コンパイル中に収集された情報を使用する動的最適化の方法４００を示している。本発明のこの実施形態によれば、動的オプティマイザ２０７は、コンパイルの時点でインストルメント化バイナリに関して収集された情報を使用することができ、これは本明細書では動的最適化プロセスの「静的コンパイル段階」という。

　静的コンパイラによって生成されたデータ／情報は一般に注釈付きバイナリとして記憶され、これは余分な情報を収容するための拡張部（たとえば、それに添付した注釈）を備えたインストルメント化バイナリにすることができることに留意されたい。

　動的最適化を支援するために静的最適化中に収集可能な情報としては、フロー・グラフ情報、特に、どのラベルが所与の分岐のターゲットであるかと、その実行時の曖昧性除去によってコンパイル時に抑制された最適化を使用可能にすることができる静的データ依存関係を含むことができる。

　この実施形態は、コンパイル時により容易に検出可能であって、したがって、高価な実行時分析を妨げる可能性がある詳細を利用するために特に有益である可能性がある。

　方法４００は図４のステップ４００Ａから始まり、図３に関して前述した方法でコンパイル済みプログラムにインストルメンテーション・コードを挿入する。上記で言及した注釈は、静的プログラム情報を収集することにより、コンパイル時に生成される（特定のサンプル・データ・セットによって実行することにより収集されたプロファイル・データではない）。

　コンパイルは進行し、フロント・エンド、最適化、レジスタ割振り、最終アセンブリなどのコンパイルの様々なフェーズ中に、ステップ４０２で情報を収集する。

　ステップ４０４は、有用な情報を収集する様々な時点におけるコンパイラの中間言語（ＩＬ）の注釈を表している。

　ステップ４０６では、静的コンパイル・フェーズによって生成されたバイナリは、上記の開示全体にわたって言及したインストルメンテーションだけでなく、コンパイル時に生成した注釈も含む。これらの注釈は、バイナリ・モジュールに付加されたコード化データ・ストリングの形を取る。

　ステップ４１０〜４１４は図３で前述したように進行し、その違いは、注釈付きバイナリに含まれる情報が実行モニタ（シャドウ・プロセス）システムの動的最適化コンポーネントによって配置されることである。変更はバイナリのみに対して行われ、バイナリの実行と同時に行われることに留意されたい。

　それ以上の静的最適化が不要である場合、ステップ４０２で収集した情報を使用して、ステップ４０８でインストルメント化バイナリに付加すべき注釈ファイルを作成する。このようなファイルの一例を図５〜７に示す。

　具体的には、図５は、制御フロー・グラフとして知られるコンパイル時データ構造の可視表現５００を示している。グラフ内の各ノード（すなわち、１〜１２）は基本ブロックを表し、方向を示す線はノード同士を接続する後継エッジを表している。ここに表したプログラムは、算出分岐テーブルを含んでいる。

　図６は、注釈付きバイナリの一部を形成可能なフロー・グラフのコード化表現５２０を示している。

　図７は、この例の注釈ファイルに含まれると思われる実際のデータ５４０を表している。動的オプティマイザ２０７は潜在的にこのデータを使用して、実行時にこのグラフを迅速に再構築することができるだろう。

　その場合、この注釈付きインストルメント化バイナリは、本発明による動的最適化ツール２０７を備えたマルチプロセッサ・システム上で実行するための準備が整っている。

　ステップ４０８では、第１のプロセッサまたはプロセッサ・セット上で実際のユーザ・データを使用してプログラムを実行し、それにより、ステップ４１０で、バイナリ・アプリケーション自体を実行しているプロセッサ（複数も可）とは異なるプロセッサまたはプロセッサ・セット上で、インストルメント化バイナリ・アプリケーション用の実行モニタ・スレッドを創出する。

　ステップ４１２では、動的オプティマイザは、図３のステップ３０２〜３１２に関して前述するように、注釈を利用するように変更された改良済み最適化バイナリを生成するために実行バイナリに含まれるインストルメンテーションによって生成された情報とともに静的最適化中に生成された注釈を使用する。

　図８のプロセス６００の流れ図に転ずると、本発明による動的最適化システムの他の実施形態は、最適化すべきバイナリ・アプリケーションの実行中に、以前に頻繁に実行されたバイナリ・アプリケーションの所与の非インストルメント化モジュールを検出する機能を含む。

　このようなモジュールを検出した場合（ステップ６１０）、本発明は、後続のモニタおよび最適化のためにインストルメンテーション・コードの自動挿入に備えるものである。図８の内容は最適化の特殊ケースと見なすことができ、論理的には図８の諸ステップは図３のボックス３０６とボックス３１２の間に収まることに留意されたい。

　潜在的に他のアプリケーション間で「共用」される可能性のあるコードの変更を回避するために、ステップ６２０でシステムは、元のモジュール（未プロファイル化バイナリ）のコピーを作成し、このように変更されたモジュールのリストを維持する。

　次に、ステップ６３０は、バイナリをインストルメントするためのメソッドを呼び出す。今後、このモジュールを呼び出したときに、モニタは、インストルメント化バージョンに直ちにスイッチし、それを実行して、実行モニタが読み取るべきプロファイルを生成することができる（ステップ６４０）。すなわち、ステップ６４０は、次の呼出し時にインストルメント化バージョンを呼び出すように、「ホット」フラグメントを変更する。

　次に、この方法は、ステップ３１４で実行が終了するまで、図３のステップ３１０などに移行するが、その終了時点であるステップ６５０では、コピーしたバイナリのリストを削除する。

　この技法は、たとえば、ソース・コードが使用不能であるために、そのコンパイルが実現不能であるようなコンポーネントのインストルメンテーションを可能にするものである。バイナリ実行時ライブラリは、このようにして最適化可能なコンポーネントの一例である。

　本発明のこの態様の他の応用例により、レガシー（すなわち、非インストルメント化）バイナリは、上記の自動再コンパイル技法の応用によるプロセッサ構成のアーキテクチャ上の機能強化または改良点の恩恵を享受することができる。

　図９に示すように、本発明の他の実施形態では、ＩＢＭの整理番号ＹＯＲ９２００１０５３２ＵＳ１を有し、Ｎａｉｒ他による米国特許出願第１０／２４４,４３４号に記載されているようなホスト・システム上で実行するためにターゲット・アプリケーションの命令ストリームを動的に変換するプロセスにおいて、このインストルメント化バイナリが生成される。図９は、エミュレーション・スレッド７１０と、変換スレッド７２０と、ホスト・プロセッサ（複数も可）７５０用にスレッド・スケジューラ７４０によってスケジューリングされるサービス・スレッド７３０とを含むシステム７００を示している。

　図９に示すこの実施形態では、エミュレーション・システム７００には、エミュレーション・システム７００の一体部分であって、変換スレッド７２０の１つである、実行モニタ・スレッドが設けられている。変換スレッドのうちの１つまたは複数を使用して、実行モニタによって選択されるコード・フラグメントを動的に最適化する。

　図９のシステム７００では、パフォーマンスを強化するために、頻繁に実行されるコード・シーケンスに動的最適化を施す。このようなシーケンスは、キャッシュしたコードの実行頻度を追跡するためにカウンタを使用するインタプリタ変換スレッドによって挿入されるインストルメンテーション・コードによって識別される。モニタ・スレッドはこれらのカウンタの値を連続的に追跡し、所与のしきい値に達すると、所与のコード・シーケンスについては（それ以上の）最適化が有益である可能性があることをオプティマイザ・スレッドに知らせ、最適化すべきコード・シーケンスを導入したゲスト命令の（エミュレートした）実アドレスを示す。

　上記のハードウェア／ソフトウェア環境に加え、本発明の他の態様では、上記の方法を実行するためのコンピュータ実現方法を含む。一例として、この方法は前述の特定の環境で実現することができる。

　このような方法は、たとえば、ディジタル・データ処理装置によって実施されるように、一連の機械可読命令を実行するようにコンピュータを操作することにより実現することができる。このような命令は、様々なタイプの信号運搬媒体に存在することができる。

　この信号運搬媒体は、たとえば高速アクセス記憶装置によって代表されるように、たとえばＣＰＵ内に含まれるＲＡＭを含むことができる。別法として、ＣＰＵによって直接または間接的にアクセス可能な磁気データ記憶ディスケット８００（図１０）などの他の信号運搬媒体に命令を含めることもできる。

　ディスケット８００に含まれるか、コンピュータ／ＣＰＵまたはその他の場所に含まれるかにかかわらず、ＤＡＳＤ記憶装置（たとえば、従来の「ハード・ドライブ」またはＲＡＩＤアレイ）、磁気テープ、電子読取専用メモリ（たとえば、ＲＯＭ、ＥＰＲＯＭ、またはＥＥＰＲＯＭ）、光学記憶装置（たとえば、ＣＤ−ＲＯＭ、ＷＯＲＭ、ＤＶＤ、ディジタル光学テープなど）、紙の「パンチ」カードなどの様々な機械可読データ記憶媒体、またはディジタルおよびアナログ通信リンクならびに無線などの伝送媒体を含むその他の適当な信号運搬媒体上に命令を記憶することができる。本発明の例証となる一実施形態では、機械可読命令は、「Ｃ」などの言語からコンパイルされたソフトウェア・オブジェクト・コードを含むことができる。

　いくつかの好ましい実施形態に関して本発明を説明してきたが、当業者であれば、特許請求の範囲の精神および範囲内で変更を加えて本発明を実施できることが分かるだろう。

　たとえば、前述の通り、本発明は共用マルチプロセッサ・システム（ＳＭＰ）に限定されず、分散マルチプロセッサ・システムにおいても有利に適用可能であろう。

　さらに、本出願人の意図は、権利請求中に後日補正された場合でも、すべての特許請求の範囲と同等のものを包含することであることに留意されたい。

　まとめとして、本発明の構成に関して以下の事項を開示する。

　（１）マルチプロセッシング・システムにおける透過動的最適化の方法において、
　前記システムの他のプロセッサ上で動作している実行モニタにより第１のプロセッサ上のアプリケーション・バイナリの実行をモニタするステップと、
　前記システムの前記他のプロセッサ上で実行している実行時オプティマイザにより元のアプリケーション・バイナリの１つまたは複数のセグメントを透過的に最適化するステップとを具備する方法。
　（２）前記システム内の前記第１のプロセッサ上の前記アプリケーション・バイナリのインストルメント化コピーを実行するステップをさらに具備する、上記（１）に記載の方法。
　（３）前記モニタが、前記アプリケーション・バイナリのインストルメント化コピーに含まれるインストルメント化コードを実行することにより生成された実行特性に関して実行される、上記（１）に記載の方法。
　（４）前記最適化が、同時に実行中のアプリケーション・バイナリへのパフォーマンス上の影響なしに、前記実行モニタによって収集された実行特性に関して実行される、上記（１）に記載の方法。
　（５）１つまたは複数のセグメントを最新最適化セグメントで置き換えることにより元の実行アプリケーション・バイナリを同時に変更するステップをさらに具備する、上記（１）に記載の方法。
　（６）前記変更が前記アプリケーション・バイナリのユーザにとって透過的な方法で実行される、上記（５）に記載の方法。
　（７）前記実行アプリケーション・バイナリに挿入する前に最適化部分からインストルメンテーション・コードを除去するステップをさらに具備する、上記（１）に記載の方法。
　（８）インストルメンテーションにより、前記１つまたは複数のセグメントが頻繁に実行されたものと決定するステップをさらに具備する、上記（１）に記載の方法。
　（９）新しいインストルメンテーションを最適化部分に挿入して、前記最新最適化アプリケーション・バイナリの実行特性をモニタし続けるステップをさらに具備する、上記（１）に記載の方法。
　（１０）前記最適化が、頻繁に実行されるコード経路からの不必要な分岐の除去を含む、上記（１）に記載の方法。
　（１１）前記最適化が、それが動作している特定のネットワーク・ノードのアーキテクチャ上の全能力を活用するようにアプリケーション・バイナリを専門化することを含む、上記（１）に記載の方法。
　（１２）前記アプリケーション・バイナリが、コンパイル時に収集され、前記実行時オプティマイザによる使用のために前記バイナリに記憶されたプロファイリング命令およびプログラム・データを含む、上記（１）に記載の方法。
　（１３）前記実行アプリケーション・バイナリの少なくとも複数の部分が以前にインストルメント化されていない、上記（１）に記載の方法。
　（１４）前記少なくとも複数の部分が、ソース・コードなしのレガシー・バイナリと共用実行時ライブラリのうちの少なくとも一方を含み、前記方法が、
　頻繁に実行されるバイナリをモニタするステップと、
　前記バイナリを分析し、そこに適切なインストルメンテーション・コードを挿入するためにコピーを作成するステップと、
　前記バイナリの今後の呼出し時に、インストルメント化コピーにスイッチし、その実行を続行するステップとをさらに具備する、上記（１３）に記載の方法。
　（１５）前記バイナリが、実行されていない間に分析される、上記（１４）に記載の方法。
　（１６）前記システムが、分散共用メモリを介して通信する複数ノードのクラスタを含む、上記（１）に記載の方法。
　（１７）前記システムが共用マルチプロセッサ・システム（ＳＭＰ）を含む、上記（１）に記載の方法。
　（１８）前記インストルメント化アプリケーション・バイナリが、ホスト・システム上で実行するためにターゲット・アプリケーションの命令ストリームを動的に変換するプロセス中に生成される、上記（２）に記載の方法。
　（１９）マルチプロセッサ・コンピューティング環境がその実行環境についてアプリケーションの同時動的最適化を実行するための方法において、
　システム内の第１のプロセッサ上で前記アプリケーションのインストルメント化コピーを実行するステップと、
　前記システムの他のプロセッサ上で動作している実行モニタにより前記アプリケーションの実行をモニタするステップであって、前記モニタが前記アプリケーションの前記インストルメント化コピーに含まれるインストルメンテーション・コードを実行することにより生成された実行特性に関して実行されるステップと、
　前記システムの他のプロセッサ上で実行している実行時オプティマイザにより前記元のアプリケーションの１つまたは複数のセグメントを最適化するステップであって、前記最適化が、同時に実行中のアプリケーションへのパフォーマンス上の影響なしに、前記実行モニタによって収集された実行特性に関して実行されるステップと、
　１つまたは複数のセグメントを最新最適化セグメントで置き換えることにより前記元の実行アプリケーションを変更するステップであって、前記変更が前記アプリケーションのユーザにとって透過的な方法で実行されるステップとを具備する方法。
　（２０）マルチプロセッサ・システム内でその実行環境についてアプリケーションの同時動的最適化を実行するための方法において、
　個別プロセッサ内でまたは複数プロセッサにわたって動作している個別プロセスとして動作している実行モニタにより、第１のプロセッサ内で動作しているプログラムまたはアプリケーションのそれぞれの実行をモニタするステップと、
　それが実行しているバイナリ・コードにより、前記バイナリ・コードの実行特性のプロファイル・データを作成するステップであって、前記バイナリ・コードがパフォーマンスをモニタするためのインストルメンテーション・コードを含むステップと、
　前記実行モニタにより、前記プロファイル・データを連続的に評価するステップと、
　所与のしきい条件を満足するときに、動的オプティマイザを呼び出して、頻繁に実行するコード・フラグメントを最適化するステップとを具備し、
　その後続実行で使用するために実行中の命令ストリームに前記最適化コード・フラグメントが挿入される方法。
　（２１）前記マルチプロセッサ・システム内の余分な処理サイクルを使用して、実行中のアプリケーションの実行特性を観察し、前記実行中のアプリケーションを透過的に変更して、そのパフォーマンスを改善する、上記（２０）に記載の方法。
　（２２）新たに挿入したコード・フラグメントが、いかなるインストルメンテーションも含まない、上記（２０）に記載の方法。
　（２３）新たに挿入したコード・フラグメントが、前記アプリケーションの実行特性におけるその他の変更を検出するために再インストルメント化コードを含む、上記（２０）に記載の方法。
　（２４）共用マルチプロセッシング（ＳＭＰ）システム内の透過動的最適化の方法において、
　第１のプロセッサ上でアプリケーション・バイナリを実行するステップと、
　前記システム内の他のプロセッサ上で前記実行の挙動をモニタするステップと、
　前記アプリケーション・バイナリが実行されている間に前記アプリケーション・バイナリの実行を最適化するステップとを具備する方法。
　（２５）前記アプリケーション・バイナリがインストルメント化される、上記（２４）に記載の方法。
　（２６）前記実行アプリケーション・バイナリの少なくとも一部が以前にインストルメント化されていない、上記（２４）に記載の方法。
　（２７）マルチプロセッシング・システム内の透過動的最適化のためのシステムにおいて、
　第１のプロセッサ上でアプリケーション・バイナリの実行をモニタするための実行モニタであって、前記システムの他のプロセッサ上で動作する実行モニタを具備し、
　前記実行モニタが、前記モニタと同時に、前記元のアプリケーション・バイナリの１つまたは複数のセグメントを最適化するための動的オプティマイザを含み、前記オプティマイザが前記システムの前記他のプロセッサ上で実行されるシステム。
　（２８）前記実行モニタが、前記インストルメント化バイナリ・アプリケーションの動的再最適化フラグメントを記憶するためのフラグメント・キャッシュを含む、上記（２７）に記載のシステム。
　（２９）前記実行モニタが、前記アプリケーション・バイナリのインストルメント化コピーに含まれるインストルメンテーション・コードを実行することにより生成された実行特性に関して前記モニタを実行する、上記（２７）に記載のシステム。
　（３０）前記動的オプティマイザが、同時に実行中のアプリケーション・バイナリへのパフォーマンス上の影響なしに、前記実行モニタによって収集された実行特性に関して前記最適化を実行する、上記（２７）に記載のシステム。
　（３１）前記実行モニタが、１つまたは複数のセグメントを最新最適化セグメントで置き換えることにより前記元の実行アプリケーション・バイナリを同時に変更する、上記（２７）に記載のシステム。
　（３２）前記変更が前記アプリケーション・バイナリのユーザにとって透過的な方法で実行される、上記（３１）に記載のシステム。
　（３３）前記実行モニタが、前記実行アプリケーション・バイナリに挿入する前に最適化部分から前記インストルメンテーション・コードを除去する、上記（２７）に記載のシステム。
　（３４）前記実行モニタが、新しいインストルメンテーションを最適化部分に挿入して、前記最新最適化アプリケーション・バイナリの実行特性をモニタし続ける、上記（２７）に記載のシステム。
　（３５）前記動的オプティマイザが、頻繁に実行されるコード経路から不必要な分岐を除去する、上記（２７）に記載のシステム。
　（３６）前記動的オプティマイザが、それが動作している特定のネットワーク・ノードのアーキテクチャ上の全能力を活用するようにアプリケーション・バイナリを専門化する、上記（２７）に記載のシステム。
　（３７）前記アプリケーション・バイナリが、コンパイル時に収集され、前記動的オプティマイザによる使用のために前記バイナリに記憶されたプロファイリング命令および何らかのプログラム・データを含む、上記（２７）に記載のシステム。
　（３８）前記実行アプリケーション・バイナリの少なくとも複数の部分が以前にインストルメント化されていない、上記（２７）に記載のシステム。
　（３９）前記少なくとも複数の部分が、ソース・コードなしのレガシー・バイナリと共用実行時ライブラリのうちの少なくとも一方を含み、前記システムが、
　頻繁に実行されるバイナリをモニタするための手段と、
　前記バイナリを分析し、そこに適切なインストルメンテーション・コードを挿入するためにコピーを作成するための手段と、
　前記バイナリの今後の呼出し時に、インストルメント化コピーにスイッチし、その実行を続行するための手段とをさらに具備する、上記（３８）に記載のシステム。
　（４０）前記バイナリが、実行されていない間に分析される、上記（３９）に記載のシステム。
　（４１）分散共用メモリを介して通信する複数ノードのクラスタをさらに含む、上記（２７）に記載のシステム。
　（４２）前記システムが共用マルチプロセッサ・システム（ＳＭＰ）を含む、上記（２７）に記載のシステム。
　（４３）インストルメント化アプリケーション・バイナリが、ホスト・システム上で実行するためにターゲット・アプリケーションの命令ストリームを動的に変換するプロセス中に生成される、上記（２８）に記載のシステム。
　（４４）前記実行モニタが前記第１のプロセッサ専用になっている、上記（２７）に記載のシステム。
　（４５）前記実行モニタが、
　前記フラグメント・キャッシュ内のフラグメントを管理するためのフラグメント・マネージャと、
　前記フラグメント・マネージャに入力を提供するために、所定の条件を満足するときに前記実行アプリケーション・バイナリによってトリガされるプロファイル・モニタとをさらに含み、
　前記動的オプティマイザが、前記フラグメント・マネージャを介して前記フラグメント・キャッシュに最適化フラグメントを戻し、
　前記実行モニタが、最適化のために前記アプリケーション・バイナリのどの部分を抽出すべきかを決定し、前記命令のコピーを作成し、前記動的オプティマイザが前記コピーを参照してそれに変更を加えられるように前記命令を記憶することにより、前記アプリケーション・バイナリの前記部分を抽出し、
　前記実行モニタが、特定のフラグメントを最適化するために関連するプロファイル情報を前記動的オプティマイザに提供する、上記（２８）に記載のシステム。
　（４６）マルチプロセッシング・システム内の透過動的最適化の方法を実行するためにディジタル処理装置により実行可能な複数の機械可読命令からなるプログラムを具体的に実施する信号運搬媒体において、
　前記システムの他のプロセッサ上で動作している実行モニタにより、第１のプロセッサ上でアプリケーション・バイナリの実行をモニタするステップと、
　前記システムの前記他のプロセッサ上で実行される実行時オプティマイザにより、前記元のアプリケーション・バイナリの１つまたは複数のセグメントを透過的に最適化するステップとを具備する信号運搬媒体。
　（４７）複数のホスト・プロセッサを有するマルチプロセッサ・システム用のエミュレーション・システムにおいて、
　ホスト・システム上で実行するためにターゲット・アプリケーションの命令ストリームを動的に変換する間にインストルメント化バイナリを生成するための実行モニタを具備し、
　前記実行モニタ・スレッドが、複数の変換スレッドのうちの１つを具備し、
　前記変換スレッドの少なくとも１つを使用して、前記実行モニタが選択したコード・フラグメントを動的に最適化する、エミュレーション・システム。
　（４８）前記変換スレッドのうちの１つがオプティマイザ・スレッドを具備し、
　頻繁に実行されるコード・シーケンスを動的に最適化して、パフォーマンスを強化し、
　前記シーケンスが、キャッシュしたコードの実行頻度をモニタするインタプリタ変換スレッドによって挿入されるインストルメンテーション・コードによって識別され、
　所定のしきい値に達したときに、所与のコード・シーケンスが最適化の候補であることを前記オプティマイザ・スレッドに知らせ、最適化すべきコード・シーケンスを導入したゲスト命令のエミュレートした実アドレスが前記オプティマイザ・スレッドに提供されるように、モニタ・スレッドが前記頻度を連続的に追跡する、上記（４７）に記載のエミュレーション・システム。
　（４９）マルチプロセッサ・システム用のエミュレーション・システムにおいて、
　複数のスレッドを具備し、変換スレッドのうちの１つが実行モニタを具備し、前記変換スレッドの少なくとも１つが動的オプティマイザを具備する、エミュレーション・システム。

本発明を実行するためのマルチプロセッシング・システム１００を示すシステム図である。 本発明によりインストルメント化バイナリ２０１ａを実行するためのプロセッサ２０１と、動的オプティマイザ２０７を実行するためのプロセッサ２０３を示す機能強化図２００である。 本発明による動的最適化のプロセス３００を示す流れ図である。 静的最適化プロセス中に収集した情報を利用するように適合させた本発明の動的オプティマイザ用のプロセス４００の代替実施形態を示す流れ図であり、具体的には、コンパイル時に収集したデータは、実行モニタの動的オプティマイザ・コンポーネントにより実行時に使用するために実行可能コードに記憶されることを示す図である。 図４の方法４００中に作成した注釈ファイルを示す図であり、具体的には、制御フロー・グラフとして知られるコンパイル時データ構造の可視表現である。 図４の方法４００中に作成した注釈ファイルを示す図であり、具体的には、注釈付きバイナリの一部を形成可能なフロー・グラフのコード化表現を示す図である。 図４の方法４００中に作成した注釈ファイルを示す図であり、具体的には、図６の例に関する注釈ファイルに含まれると思われる実際のデータを表す図である。 静的最適化中にインストルメント化されていないバイナリ・アプリケーションの動的最適化を可能にする、本発明の他の実施形態を示す図である。 ＩＢＭの整理番号ＹＯＲ９２００１０５３２ＵＳ１を有する前述の米国特許出願第１０／２４４,４３４号に記載されているようなエミュレータとともに使用する本発明の一実施形態を示す図である。 本発明による方法のプログラムの諸ステップを記憶するための信号運搬媒体８００（たとえば、記憶媒体）を示す図である。

符号の説明

１０１ａ、２０１　プロセッサ１
１０１ｂ　プロセッサ２
１０２　メイン・メモリ
１０３　オペレーティング・システム
１０４　実行モニタ
２０１ａ　インストルメント化実行バイナリ
２０１ｂ　フラグメント・キャッシュ
２０２　フラグメント管理
２０３　プロセッサｎ＋１
２０４　プロファイル・モニタ
２０７　動的オプティマイザ
７１０　エミュレーション・スレッド
７３０　サービス・スレッド
７４０　スレッド・スケジューラ
７５０　ホスト・プロセッサ１
７５０　ホスト・プロセッサ２
７５０　ホスト・プロセッサｎ

　　

Claims (49)

1. 　マルチプロセッシング・システムにおける透過動的最適化の方法において、
   　前記システムの他のプロセッサ上で動作している実行モニタにより第１のプロセッサ上のアプリケーション・バイナリの実行をモニタするステップと、
   　前記システムの前記他のプロセッサ上で実行している実行時オプティマイザにより元のアプリケーション・バイナリの１つまたは複数のセグメントを透過的に最適化するステップとを具備する方法。
2. 　前記システム内の前記第１のプロセッサ上の前記アプリケーション・バイナリのインストルメント化コピーを実行するステップをさらに具備する、請求項１に記載の方法。
3. 　前記モニタが、前記アプリケーション・バイナリのインストルメント化コピーに含まれるインストルメント化コードを実行することにより生成された実行特性に関して実行される、請求項１に記載の方法。
4. 　前記最適化が、同時に実行中のアプリケーション・バイナリへのパフォーマンス上の影響なしに、前記実行モニタによって収集された実行特性に関して実行される、請求項１に記載の方法。
5. 　１つまたは複数のセグメントを最新最適化セグメントで置き換えることにより元の実行アプリケーション・バイナリを同時に変更するステップをさらに具備する、請求項１に記載の方法。
6. 　前記変更が前記アプリケーション・バイナリのユーザにとって透過的な方法で実行される、請求項５に記載の方法。
7. 　前記実行アプリケーション・バイナリに挿入する前に最適化部分からインストルメンテーション・コードを除去するステップをさらに具備する、請求項１に記載の方法。
8. 　インストルメンテーションにより、前記１つまたは複数のセグメントが頻繁に実行されたものと決定するステップをさらに具備する、請求項１に記載の方法。
9. 　新しいインストルメンテーションを最適化部分に挿入して、前記最新最適化アプリケーション・バイナリの実行特性をモニタし続けるステップをさらに具備する、請求項１に記載の方法。
10. 　前記最適化が、頻繁に実行されるコード経路からの不必要な分岐の除去を含む、請求項１に記載の方法。
11. 　前記最適化が、それが動作している特定のネットワーク・ノードのアーキテクチャ上の全能力を活用するようにアプリケーション・バイナリを専門化することを含む、請求項１に記載の方法。
12. 　前記アプリケーション・バイナリが、コンパイル時に収集され、前記実行時オプティマイザによる使用のために前記バイナリに記憶されたプロファイリング命令およびプログラム・データを含む、請求項１に記載の方法。
13. 　前記実行アプリケーション・バイナリの少なくとも複数の部分が以前にインストルメント化されていない、請求項１に記載の方法。
14. 　前記少なくとも複数の部分が、ソース・コードなしのレガシー・バイナリと共用実行時ライブラリのうちの少なくとも一方を含み、前記方法が、
    　頻繁に実行されるバイナリをモニタするステップと、
    　前記バイナリを分析し、そこに適切なインストルメンテーション・コードを挿入するためにコピーを作成するステップと、
    　前記バイナリの今後の呼出し時に、インストルメント化コピーにスイッチし、その実行を続行するステップとをさらに具備する、請求項１３に記載の方法。
15. 　前記バイナリが、実行されていない間に分析される、請求項１４に記載の方法。
16. 　前記システムが、分散共用メモリを介して通信する複数ノードのクラスタを含む、請求項１に記載の方法。
17. 　前記システムが共用マルチプロセッサ・システム（ＳＭＰ）を含む、請求項１に記載の方法。
18. 　前記インストルメント化アプリケーション・バイナリが、ホスト・システム上で実行するためにターゲット・アプリケーションの命令ストリームを動的に変換するプロセス中に生成される、請求項２に記載の方法。
19. 　マルチプロセッサ・コンピューティング環境がその実行環境についてアプリケーションの同時動的最適化を実行するための方法において、
    　システム内の第１のプロセッサ上で前記アプリケーションのインストルメント化コピーを実行するステップと、
    　前記システムの他のプロセッサ上で動作している実行モニタにより前記アプリケーションの実行をモニタするステップであって、前記モニタが前記アプリケーションの前記インストルメント化コピーに含まれるインストルメンテーション・コードを実行することにより生成された実行特性に関して実行されるステップと、
    　前記システムの他のプロセッサ上で実行している実行時オプティマイザにより前記元のアプリケーションの１つまたは複数のセグメントを最適化するステップであって、前記最適化が、同時に実行中のアプリケーションへのパフォーマンス上の影響なしに、前記実行モニタによって収集された実行特性に関して実行されるステップと、
    　１つまたは複数のセグメントを最新最適化セグメントで置き換えることにより前記元の実行アプリケーションを変更するステップであって、前記変更が前記アプリケーションのユーザにとって透過的な方法で実行されるステップとを具備する方法。
20. 　マルチプロセッサ・システム内でその実行環境についてアプリケーションの同時動的最適化を実行するための方法において、
    　個別プロセッサ内でまたは複数プロセッサにわたって動作している個別プロセスとして動作している実行モニタにより、第１のプロセッサ内で動作しているプログラムまたはアプリケーションのそれぞれの実行をモニタするステップと、
    　それが実行しているバイナリ・コードにより、前記バイナリ・コードの実行特性のプロファイル・データを作成するステップであって、前記バイナリ・コードがパフォーマンスをモニタするためのインストルメンテーション・コードを含むステップと、
    　前記実行モニタにより、前記プロファイル・データを連続的に評価するステップと、
    　所与のしきい条件を満足するときに、動的オプティマイザを呼び出して、頻繁に実行するコード・フラグメントを最適化するステップとを具備し、
    　その後続実行で使用するために実行中の命令ストリームに前記最適化コード・フラグメントが挿入される方法。
21. 　前記マルチプロセッサ・システム内の余分な処理サイクルを使用して、実行中のアプリケーションの実行特性を観察し、前記実行中のアプリケーションを透過的に変更して、そのパフォーマンスを改善する、請求項２０に記載の方法。
22. 　新たに挿入したコード・フラグメントが、いかなるインストルメンテーションも含まない、請求項２０に記載の方法。
23. 　新たに挿入したコード・フラグメントが、前記アプリケーションの実行特性におけるその他の変更を検出するために再インストルメント化コードを含む、請求項２０に記載の方法。
24. 　共用マルチプロセッシング（ＳＭＰ）システム内の透過動的最適化の方法において、
    　第１のプロセッサ上でアプリケーション・バイナリを実行するステップと、
    　前記システム内の他のプロセッサ上で前記実行の挙動をモニタするステップと、
    　前記アプリケーション・バイナリが実行されている間に前記アプリケーション・バイナリの実行を最適化するステップとを具備する方法。
25. 　前記アプリケーション・バイナリがインストルメント化される、請求項２４に記載の方法。
26. 　前記実行アプリケーション・バイナリの少なくとも一部が以前にインストルメント化されていない、請求項２４に記載の方法。
27. 　マルチプロセッシング・システム内の透過動的最適化のためのシステムにおいて、
    　第１のプロセッサ上でアプリケーション・バイナリの実行をモニタするための実行モニタであって、前記システムの他のプロセッサ上で動作する実行モニタを具備し、
    　前記実行モニタが、前記モニタと同時に、前記元のアプリケーション・バイナリの１つまたは複数のセグメントを最適化するための動的オプティマイザを含み、前記オプティマイザが前記システムの前記他のプロセッサ上で実行されるシステム。
28. 　前記実行モニタが、前記インストルメント化バイナリ・アプリケーションの動的再最適化フラグメントを記憶するためのフラグメント・キャッシュを含む、請求項２７に記載のシステム。
29. 　前記実行モニタが、前記アプリケーション・バイナリのインストルメント化コピーに含まれるインストルメンテーション・コードを実行することにより生成された実行特性に関して前記モニタを実行する、請求項２７に記載のシステム。
30. 　前記動的オプティマイザが、同時に実行中のアプリケーション・バイナリへのパフォーマンス上の影響なしに、前記実行モニタによって収集された実行特性に関して前記最適化を実行する、請求項２７に記載のシステム。
31. 　前記実行モニタが、１つまたは複数のセグメントを最新最適化セグメントで置き換えることにより前記元の実行アプリケーション・バイナリを同時に変更する、請求項２７に記載のシステム。
32. 　前記変更が前記アプリケーション・バイナリのユーザにとって透過的な方法で実行される、請求項３１に記載のシステム。
33. 　前記実行モニタが、前記実行アプリケーション・バイナリに挿入する前に最適化部分から前記インストルメンテーション・コードを除去する、請求項２７に記載のシステム。
34. 　前記実行モニタが、新しいインストルメンテーションを最適化部分に挿入して、前記最新最適化アプリケーション・バイナリの実行特性をモニタし続ける、請求項２７に記載のシステム。
35. 　前記動的オプティマイザが、頻繁に実行されるコード経路から不必要な分岐を除去する、請求項２７に記載のシステム。
36. 　前記動的オプティマイザが、それが動作している特定のネットワーク・ノードのアーキテクチャ上の全能力を活用するようにアプリケーション・バイナリを専門化する、請求項２７に記載のシステム。
37. 　前記アプリケーション・バイナリが、コンパイル時に収集され、前記動的オプティマイザによる使用のために前記バイナリに記憶されたプロファイリング命令および何らかのプログラム・データを含む、請求項２７に記載のシステム。
38. 　前記実行アプリケーション・バイナリの少なくとも複数の部分が以前にインストルメント化されていない、請求項２７に記載のシステム。
39. 　前記少なくとも複数の部分が、ソース・コードなしのレガシー・バイナリと共用実行時ライブラリのうちの少なくとも一方を含み、前記システムが、
    　頻繁に実行されるバイナリをモニタするための手段と、
    　前記バイナリを分析し、そこに適切なインストルメンテーション・コードを挿入するためにコピーを作成するための手段と、
    　前記バイナリの今後の呼出し時に、インストルメント化コピーにスイッチし、その実行を続行するための手段とをさらに具備する、請求項３８に記載のシステム。
40. 　前記バイナリが、実行されていない間に分析される、請求項３９に記載のシステム。
41. 　分散共用メモリを介して通信する複数ノードのクラスタをさらに含む、請求項２７に記載のシステム。
42. 　前記システムが共用マルチプロセッサ・システム（ＳＭＰ）を含む、請求項２７に記載のシステム。
43. 　インストルメント化アプリケーション・バイナリが、ホスト・システム上で実行するためにターゲット・アプリケーションの命令ストリームを動的に変換するプロセス中に生成される、請求項２８に記載のシステム。
44. 　前記実行モニタが前記第１のプロセッサ専用になっている、請求項２７に記載のシステム。
45. 　前記実行モニタが、
    　前記フラグメント・キャッシュ内のフラグメントを管理するためのフラグメント・マネージャと、
    　前記フラグメント・マネージャに入力を提供するために、所定の条件を満足するときに前記実行アプリケーション・バイナリによってトリガされるプロファイル・モニタとをさらに含み、
    　前記動的オプティマイザが、前記フラグメント・マネージャを介して前記フラグメント・キャッシュに最適化フラグメントを戻し、
    　前記実行モニタが、最適化のために前記アプリケーション・バイナリのどの部分を抽出すべきかを決定し、前記命令のコピーを作成し、前記動的オプティマイザが前記コピーを参照してそれに変更を加えられるように前記命令を記憶することにより、前記アプリケーション・バイナリの前記部分を抽出し、
    　前記実行モニタが、特定のフラグメントを最適化するために関連するプロファイル情報を前記動的オプティマイザに提供する、請求項２８に記載のシステム。
46. 　マルチプロセッシング・システム内の透過動的最適化の方法を実行するためにディジタル処理装置により実行可能な複数の機械可読命令からなるプログラムを具体的に実施する信号運搬媒体において、
    　前記システムの他のプロセッサ上で動作している実行モニタにより、第１のプロセッサ上でアプリケーション・バイナリの実行をモニタするステップと、
    　前記システムの前記他のプロセッサ上で実行される実行時オプティマイザにより、前記元のアプリケーション・バイナリの１つまたは複数のセグメントを透過的に最適化するステップとを具備する信号運搬媒体。
47. 　複数のホスト・プロセッサを有するマルチプロセッサ・システム用のエミュレーション・システムにおいて、
    　ホスト・システム上で実行するためにターゲット・アプリケーションの命令ストリームを動的に変換する間にインストルメント化バイナリを生成するための実行モニタを具備し、
    　前記実行モニタ・スレッドが、複数の変換スレッドのうちの１つを具備し、
    　前記変換スレッドの少なくとも１つを使用して、前記実行モニタが選択したコード・フラグメントを動的に最適化する、エミュレーション・システム。
48. 　前記変換スレッドのうちの１つがオプティマイザ・スレッドを具備し、
    　頻繁に実行されるコード・シーケンスを動的に最適化して、パフォーマンスを強化し、
    　前記シーケンスが、キャッシュしたコードの実行頻度をモニタするインタプリタ変換スレッドによって挿入されるインストルメンテーション・コードによって識別され、
    　所定のしきい値に達したときに、所与のコード・シーケンスが最適化の候補であることを前記オプティマイザ・スレッドに知らせ、最適化すべきコード・シーケンスを導入したゲスト命令のエミュレートした実アドレスが前記オプティマイザ・スレッドに提供されるように、モニタ・スレッドが前記頻度を連続的に追跡する、請求項４７に記載のエミュレーション・システム。
49. 　マルチプロセッサ・システム用のエミュレーション・システムにおいて、
    　複数のスレッドを具備し、変換スレッドのうちの１つが実行モニタを具備し、前記変換スレッドの少なくとも１つが動的オプティマイザを具備する、エミュレーション・システム。

Images