(57)【要約】【課題】  アプリケーションのプロファイリングを容易にするシステムおよび方法を提供する。【解決手段】  本発明にかかるシステムおよび方法は、アプリケーション命令をインターセプトすること、あらかじめ確立されたポリシーに従って、アプリケーション命令が、頻繁に使用される命令であるかどうかを判断すること、およびアプリケーション命令が、頻繁に使用される命令である場合にのみ、アプリケーション命令の実行に関する情報の収集を容易にするために、アプリケーション命令にインスツルメントすることを含む。【選択図】図５
2005018760.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションのプロファイリングを容易にする方法であって、
アプリケーション命令の実行直前に、該アプリケーション命令をインターセプトすること（５０４）と、
あらかじめ確立されたポリシーに従って、アプリケーション命令が、頻繁に使用される命令であるかどうかを判断すること（５１６）と、
前記アプリケーション命令が、頻繁に使用される命令である場合にのみ、前記アプリケーション命令にインスツルメントすること（５１８）であって、それによって、前記アプリケーション命令の実行に関する情報の収集を容易にする、前記アプリケーション命令にインスツルメントすること（５１８）と
を含む方法。
【請求項２】
前記アプリケーション命令が、頻繁に使用される命令であるかどうかを判断することは、
該アプリケーション命令に関連したプログラムカウンタを調べること
を含む
請求項１に記載の方法。
【請求項３】
前記アプリケーション命令にインスツルメントすることは、該アプリケーション命令にインスツルメントすることであって、該アプリケーション命令が実行されたことに関する情報を収集すること
を含む
請求項１に記載の方法。
【請求項４】
前記アプリケーション命令にインスツルメントすることは、
該アプリケーション命令にインスツルメントすることであって、他のどのアプリケーション命令が、該インターセプトしたアプリケーション命令を呼び出したかに関する情報を収集するインスツルメントすること
を含む
請求項１に記載の方法。
【請求項５】
前記アプリケーション命令にインスツルメントすることは、
該アプリケーション命令にインスツルメントすることであって、該インターセプトしたアプリケーション命令が、どのアプリケーション命令を呼び出すかに関する情報を収集すること
を含む
請求項１に記載の方法。
【請求項６】
前記アプリケーション命令にインスツルメントすることは、
該アプリケーション命令にインスツルメントすることであって、プロセッササイクル数を表すカウンタまたは実行された命令数を表すカウンタをインクリメントすること
を含む
請求項１に記載のアプリケーションのプロファイリングを容易にする方法。
【請求項７】
前記アプリケーションがアクセスする共有ライブラリに記憶されたコードの実行に関する情報を記録すること（５１４）
をさらに含む請求項１に記載の方法。
【請求項８】
アプリケーションのプロファイリングを容易にし、コンピュータ可読媒体に記憶されるプログラム（１００）であって、
アプリケーションバイナリをインターセプトするように構成されたロジック（１１０）と、
アプリケーション命令が、頻繁に使用される命令であるかどうかを判断するように構成されたロジック（１０６）と、
頻繁に使用される命令であると判断されるアプリケーション命令の実行に関する情報の収集を容易にするように、該アプリケーション命令にインスツルメントするように構成されたロジック（１２０）と
を備えるプログラム。
【請求項９】
アプリケーション命令が、頻繁に使用される命令であるかどうかを判断するように構成された前記ロジックは、
該アプリケーション命令が実行される回数をカウントするように構成されたロジック
を備える
請求項８に記載のプログラム。
【請求項１０】
前記アプリケーション命令にインスツルメントするように構成されたロジックは、
該アプリケーション命令にインスツルメントするように構成されたロジックであって、該アプリケーション命令が実行されたこと、他のどのアプリケーション命令が、該インターセプトされたアプリケーション命令を呼び出したか、および、該インターセプトされたアプリケーション命令が、どのアプリケーション命令を呼び出すかのうちの少なくとも１つに関する情報を収集するロジック
を備える
請求項８に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この開示は、包括的には、バイナリコードの実行の動的変換に関する。
詳細には、この開示は、アプリケーションのプロファイリングを容易にするシステムおよび方法に関する。
【背景技術】
【０００２】
ソフトウェアプログラマは、通常、アプリケーション開発中に、アプリケーションをプロファイリングして、そのアプリケーションのさまざまな部分が、実行中にどのように使用されるかを判断する。
このような情報により、例えば、アプリケーションの実行を最適化することができる。
【０００３】
プロファイリングは、通常、アプリケーションがどのように実行されるかを明らかにする統計情報の収集を伴う。
この情報は、アプリケーションのどの関数またはどの部分が所与の入力（すなわち有効範囲（coverage））に対して使用されたかの識別情報、それぞれの特定の関数または部分の実行に要した時間、それぞれの特定の関数が呼び出された回数、それぞれの関数が別の関数を呼び出した回数、実行されたコードに見られる命令レベル並列性の量などを含むことができる。
【０００４】
アプリケーションをプロファイリングするために使用される最も一般的な方法は、アプリケーションおよびコンパイラが生成したインスツルメンテーションの統計的なサンプリングを含む。
インスツルメンテーションは、通常、ソースコードのコンパイル中に、アプリケーションコードに挿入される。
これらのインスツルメンテーションは、多くの場合、コンパイラによる各アプリケーション関数の開始時に挿入される関数呼び出しを含む。
アプリケーションの各関数の実行についてさまざまな統計情報を取得できるように、インスツルメンテーションのそれぞれは、自身に関連付けられたアプリケーション関数に関する情報を収集する。
さらに、所与の入力による所与の実行に対する関数（または部分）間の呼び出し側／被呼び出し側の関係が、挿入されたインスツルメンテーションコードによって再現される。
これは、「コールグラフ」として知られている。
【０００５】
インスツルメンテーションが収集された情報に加えて、任意の所与のアプリケーション関数（または部分、例えば「基本ブロック」）で要した時間が、通常、そのアプリケーションをランタイムサポートコードとリンクすることにより求められる。
このランタイムサポートコードは、アプリケーションプログラムカウンタの値を周期的に（例えば毎秒１００回）記録するために使用されるタイマをインスタンス化するものである。
周期的にサンプリングされた値から、各アプリケーション関数の実行に要した概算時間を求めることができる。
【０００６】
さまざまなインスツルメンテーションおよびプログラムカウンタのサンプリング（「プログラムカウンタヒストグラム」として知られている）によって収集される情報は、標準的には、ユーザ可読なコールグラフまたはコールグラフの視覚表現を生成するプロファイリングプログラムによって分析される。
プログラマは、このユーザ可読なコールグラフまたはコールグラフの視覚表現を検討して、アプリケーションが実行される様子について学習することができる。
コールグラフは、標準的には、さまざまなアプリケーション関数を表す一連のノード、および、それらのノードを接続してアプリケーション関数間のさまざまな関連を表す一連のアークを備える。
さらに、コールグラフは、特定のアプリケーション関数内で要した時間、関数の起動回数、ある関数が別の関数を起動する回数などのさまざまな情報を提供する注釈を含むことができる。
【０００７】
上述したプロファイリング方法は、実施が簡単ではあるが、重大な欠点を含んでいる。
まず、周期的なサンプリングを使用して統計値を収集することから、得られた結果は、あまり正確でないことがある。
したがって、生成されたプログラムカウンタヒストグラムは、アプリケーションが実行される方法に関して、誤った、かつ／または、不正確な情報、したがって、判断を誤らせるような情報を含むことがある。
サンプリングレートを増加させることにより、プロファイリングの正確さを増加させることができるが、このサンプリングの増加に関連したオーバーヘッドは、かなり大きくなる可能性があり、例えば、実行時間の５０％以上を占める可能性がある。
【０００８】
従来のプロファイリング方法を通じて得られる情報の正確さは、プロファイリングが行われるというまさにそのことによってさらに減少する可能性がある。
例えば、ある関数が、既存のアプリケーション関数の実行に関する情報を収集する目的でコンパイラによってその既存のアプリケーション関数に追加されるが、その追加された関数が、（例えば、インスツルメントされる関数の実行が非常に短時間のときは）そのアプリケーション関数と同程度またはそれより多くの時間を必要とする場合、収集される情報は、既存のアプリケーション関数の実行に要した時間について、通常オペレーション中に実際に必要とされる時間よりも多くの時間を示すことになる。
その上、インスツルメンテーションプローブをアプリケーションに挿入すると、所与のアプリケーションのコンパイルおよび実行のさまざまな面に無視できない影響がある。
例えば、インスツルメンテーションプローブが関数に挿入された後にコンパイラが生成するコードは、インスツルメンテーションがない場合よりも、効率が大幅に低下することがある。
さらに、ランタイムにおいて、インスツルメンテーションコードの実行が、ハードウェア（例えば、キャッシュ、ＴＬＢなど）の状態を変更することにより、アプリケーションの挙動を変更する可能性がある。
【０００９】
プロファイリングの正確さは、共有ライブラリがアプリケーションによって使用される場合にさらに低減する。
当技術分野において既知のように、共有ライブラリからのコードは、アプリケーションのランタイムにおいてのみアクセスされる。
したがって、ライブラリのコードが、アプリケーションソースコードから分離されていることから、コンパイラによってソースコードに追加されたインスツルメンテーションは、ライブラリのコードに関する情報を収集することはない。
【００１０】
さらに、従来のプロファイリング方法では、プログラマは、最も頻繁に使用されるコードの部分のみに関する情報ごとの収集を限定することができない。
その理由は、このような情報は、コンパイル時に事前に分からないからである。
当技術分野において既知のように、関数の実行に要した時間が、ほとんど関係しないほど非常に短い場合には、プログラマは、通常、それらの関数の実行について関心を持たない。
しかしながら、従来のプロファイリング技術によると、各関数（または他のアプリケーションコード部分）は、個別にインスツルメントされる。
従来のプロファイリング方式に共通のもう１つの欠点は、プロファイリングが、コンパイラツールチェーンまたは使用されるプロファイリングツールによって定義されるような所定の統計的計測に制限されるということである。
したがって、プログラマは、アプリケーション上でなされる他の量または計測であって、特定のアプリケーションについてプログラマにとってより意味のあり得る量または計測を定義することができない。
【発明の開示】
【発明が解決しようとする課題】
【００１１】
上記説明から、上記で特定した欠点の１つまたは２つ以上のものを回避するアプリケーションプロファイリングのためのシステムおよび方法を有することが望ましいということを理解することができる。
【課題を解決するための手段】
【００１２】
アプリケーションのプロファイリングを容易にするシステムおよび方法が開示される。
一配置において、システムおよび方法は、アプリケーション命令をインターセプトすること、あらかじめ確立されたポリシーに従って、アプリケーション命令が、頻繁に使用される命令であるかどうかを判断すること、およびアプリケーション命令が、頻繁に使用される命令である場合にのみ、アプリケーション命令の実行に関する情報の収集を容易にするために、アプリケーション命令にインスツルメントすることに関する。
【００１３】
開示するシステムおよび方法は、添付図面を参照することによって、より良く理解することができる。
【発明を実施するための最良の形態】
【００１４】
アプリケーションのプロファイリングを容易にするシステムおよび方法について開示する。
一般的に言うと、この開示するシステムおよび方法は、例えばアプリケーションを最適化する目的でアプリケーションコードの実行に関する情報を収集できるように、アプリケーション実行の制御を取得することに使用することができる。
以下に詳細に説明するように、開示するシステムおよび方法によると、コードの個々の部分（例えば、基本ブロックまたは個々の命令）を、そのコード部分の実行直前にバイナリレベルで監視することができる。
コードがこのような低レベルで監視されることから、ソースコードインスツルメンテーションの変換が不要となるので、プロファイリングオーバーヘッドを大幅に減少させることができる。
さらに、このような監視により、プロファイリングされるアプリケーションコードに対する影響が低減される。
例えば、アプリケーションソースコードをコンパイルするのに使用されるコンパイラは、この監視に気付かず、その挙動は変更されない。
さらに、共有ライブラリからのコードを含めて、実行されるすべてのコードをプロファイリングすることができる。
また、開示するシステムおよび方法は、最も頻繁に実行されるコードフラグメントのみにインスツルメンテーションを限定するのに使用することもでき、それによって、プロファイリングのオーバーヘッドをさらに低減することができる。
【００１５】
本発明のシステムおよび方法の説明を容易にするために、図面を参照して、システム例を解説する。
これらのシステムについて詳細に説明するが、これらのシステムは、例示の目的で提供されるものにすぎず、さまざまな変更が、本発明の概念から逸脱することなく実施可能であることが理解されよう。
他のシステム例は、２００１年８月８日に出願された「Dynamic Execution Layer Interface for Explicitly or Transparently Executing Application or System Binaries」という発明の名称の米国特許出願第０９／９２４，２６０号（代理人整理番号第１００１１５２５−１号）に記載されている。
ここで、この米国特許出願は、参照により本開示に援用される。
システム例を説明した後、システムのオペレーション例を提供して、アプリケーションプロファイリングを容易にすることができる方法を説明する。
【００１６】
次に図１を参照する。
図１には、上記で特定したように、アプリケーションプロファイリングを容易にするために使用できる一例の動的実行レイヤインタフェース（ＤＥＬＩ（dynamic execution layer interface））１００を示す。
一般的に言うと、ＤＥＬＩ１００は、高級言語または低級言語で記述された汎用ソフトウェアレイヤ、および、ハードウェアからアプリケーションのバイナリコードを解放する当該ハードウェアを備える。
汎用ソフトウェアレイヤは、アプリケーション間に存在し、アプリケーションには、オペレーティングシステム（Ｏ／Ｓ）を含むものと、含まないものとがある。
この配置を通じて、ＤＥＬＩ１００は、動的なコンピュータプログラムコード変換、多種多様な異なるアプリケーションで使用できるサービスのキャッシュ、およびリンクを提供することができる。
以下にさらに詳細に解説するように、ＤＥＬＩ１００は、トランスペアレントモード、非トランスペアレントモード、またはこれら２つのモードを組み合わせたモードで動作中に、そのサービスを提供することができる。
トランスペアレントモードでは、ＤＥＬＩ１００は、実行されるアプリケーションが、コンピュータハードウェア上で直接実行されていないことに気付かないように、当該実行されるアプリケーションの制御を自動的に取得する。
非トランスペアレントモードでは、ＤＥＬＩ１００は、アプリケーションプログラミングインタフェース（ＡＰＩ）を通じてそのサービスをアプリケーションにエキスポートし、それによって、アプリケーションは、ＤＥＬＩ１００が一定のシステムイベントに対してどのように反応するかを制御することが可能になる。
【００１７】
図１において、ＤＥＬＩ１００は、少なくとも１つのアプリケーション１０２とコンピュータハードウェア１０４との間に位置するように示されている。
この特定の配置に応じて、アプリケーション１０２は、ＤＥＬＩの存在に気付かない１つまたは２つ以上のユーザアプリケーション、および／または、ＤＥＬＩ１００に気付いて、ＤＥＬＩのサービスを利用するように構成されるクライアントを含むことができる。
しかしながら、より一般的には、アプリケーション１０２は、コンピュータプロセッサによって実行される命令を含んだあらゆる種類のプログラムコードを含む。
Ｏ／Ｓが使用される場合、ＤＥＬＩ１００は、提供されるサービスの性質に応じて、Ｏ／Ｓ（図示せず）の上または下のいずれにも存在することもできる。
例えば、ＤＥＬＩ１００が、Ｏ／Ｓの上で動作する場合、ＤＥＬＩ１００は、アプリケーションの実行のみを制御することができる。
一方、ＤＥＬＩ１００が、Ｏ／Ｓの下で動作する場合、ＤＥＬＩは、Ｏ／Ｓおよびアプリケーションの双方からのシステムコードおよびユーザコードが混合したものを含むことができる命令ストリームにアクセスする。
ハードウェア１０４は、さまざまな異なるコンピュータシステムコンポーネントを含むことができるが、通常は、少なくともコンピュータプロセッサを含む。
【００１８】
ＤＥＬＩ１００は、コア１０６、アプリケーションプログラミングインタフェース（ＡＰＩ）１０８、トランスペアレントモードレイヤ１１０、およびシステム制御／構成レイヤ１１２を含んだ４つの主要なコンポーネントを含むことができる。
一般的に言うと、コア１０６は、ＡＰＩ１０８およびトランスペアレントモードレイヤ１１０の双方に２つの主要なサービスをエキスポートする。
これらのサービスの第１のサービスは、ネイティブコードフラグメント、または、ハードウェア１０４の命令セットに対応するコードフラグメントのキャッシュおよびリンクに関するものである。
第２のサービスは、事前にキャッシュされたコードフラグメントの実行に関するものである。
ＡＰＩ１０８は、設けられると、非トランスペアレント動作モードにおいて、コア１０６のキャッシュサービスおよびリンクサービスへのアクセスを提供する関数をアプリケーション１０２にエキスポートする。
トランスペアレントモードレイヤ１１０は、コア１０６が、キャッシュ対象のコードフラグメントをフェッチするだけでなく、トランスペアレント動作モードにおいてコード実行の制御をトランスペアレントに取得することも可能にする。
最後に、システム制御／構成レイヤ１１２は、例えば、コードのキャッシュ用ポリシー、リンク用ポリシー、および最適化用ポリシーを含めた、コア１０６のオペレーション用ポリシーを提供することにより、ＤＥＬＩ１００の構成を可能にする。
これらのポリシーは、例えば、ＡＰＩ１０８を介してアプリケーション１０２からレイヤ１１２に提供することができる。
また、システム制御／構成レイヤ１１２は、ＤＥＬＩ１００のトランスペアレントモードを有効にするかどうかも制御する。
したがって、システム制御／構成レイヤ１１２は、ＡＰＩ１０８からの入力を受け取るのか、トランスペアレントモードレイヤ１１０からの入力を受け取るのか、あるいは、その両者からの入力を受け取るのかも制御する。
【００１９】
図１にさらに示すように、システム１００は、バイパス経路１１４を含むことができる。
このバイパス経路１１４は、必要に応じて、アプリケーションをハードウェア１０４上で直接実行できるように、アプリケーション１０２が、ＤＥＬＩ１００をバイパスするために使用できるものである。
なお、このようなオペレーションは、ＤＥＬＩ１００が、利用してもよいし利用しなくてもよいオプションの実行レイヤであることから可能となり得る。
【００２０】
図１に示すように、コア１０６は、コアコントローラ１１６、キャッシュマネージャ１１８、フラグメントマネージャ１２０、および最適化マネージャ１２２を備える。
コアコントローラ１１６は、コア１０６の他のコンポーネントにタスクを割り当てるディスパッチャとして機能する。
これらの他のコンポーネントは、割り当てられたタスクの完了を担当する。
キャッシュマネージャ１１８は、フラグメントマネージャ１２０および最適化マネージャ１２２だけでなくシステム制御／構成レイヤ１１２によって指定されたポリシーに従って、１つまたは２つ以上のコードキャッシュ１２４（例えば、キャッシュ１〜ｎ）内へのコードフラグメントのキャッシュを制御するメカニズム（例えば一組のアルゴリズム）を備える。
コア１０６の１つまたは２つ以上のコードキャッシュ１２４は、例えば、ハードウェア１０４の専用メモリデバイスに配置することもできるし、ハードウェア１０４のメインローカルメモリに作成することもできる。
コードキャッシュ（複数可）１２４が、専用メモリデバイスにマッピングされると、命令キャッシュ補充のオーバーヘッドが低減すること、メモリバンド幅が増加することなどにより、大幅な性能向上を得ることができる。
フラグメントマネージャ１２０は、コードキャッシュ（複数可）１２４内におけるコードフラグメントの配置、および、それらのフラグメントに課される変換の種類を指定する。
最後に、最適化マネージャ１２２は、コードフラグメントに適用されてコードフラグメントの実行を最適化することができる一組の最適化を含む。
【００２１】
上述したように、ＡＰＩ１０８は、設けられると、ＤＥＬＩサービスへのアクセスを提供する関数をアプリケーション１０２にエキスポートする。
より具体的に言うと、ＡＰＩ１０８は、コア１０６のキャッシュサービスおよびリンクサービスをアプリケーション１０２にエキスポートする。
アプリケーション１０２は、通常、ＤＥＬＩが存在することを知っているクライアントを含む。
ＡＰＩ１０８によってエキスポートされたこれらのサービスにより、アプリケーション１０２は、非トランスペアレントモードにおけるＤＥＬＩ１００のオペレーションを制御することが可能になる。
この制御は、
（ｉ）コードフラグメントをキャッシュするためにコア１０６に明示的に放出することにより、かつ／または、
（ｉｉ）ＤＥＬＩ１００のコードキャッシュ（複数可）１２４から特定のコードフラグメントを実行するようにＤＥＬＩ１００に命令することにより
可能にされる。
さらに、ＡＰＩ１０８は、ＤＥＬＩ１００のオペレーションを初期化する関数および中止する関数もエキスポートすることができる。
例えば、ＡＰＩ１０８は、ＤＥＬＩ１００のトランスペアレントオペレーションを初期化でき、さらに、ＤＥＬＩ１００がこのようなオペレーションを中止すべき時を示すこともできる。
また、ＡＰＩ１０８は、上述したように、アプリケーション１０２によって指定されたポリシーをコア１０６（例えば、フラグメントマネージャ１２０および／または最適化マネージャ１２２）に配信することにより、ＤＥＬＩ１００の構成も容易にする。
【００２２】
図１をさらに参照して、トランスペアレントモードレイヤ１１０は、通常、インジェクタ１２６を含む。
このインジェクタ１２６は、実行中のアプリケーション１０２の制御をトランスペアレントに取得するために使用される。
ＤＥＬＩ１００が、完全なトランスペアレントモードで動作する場合（すなわち、アプリケーションが、ＤＥＬＩの存在に気付かない場合）、インジェクタ１２６を使用することにより、アプリケーション１０２の実行開始前に、アプリケーション１０２にＤＥＬＩがインジェクトされ、その結果、ＤＥＬＩの制御下でアプリケーション１０２を実行することができる。
このような状況において、ＤＥＬＩ１００は、アプリケーション１０２の実行可能イメージを変更しないようにして、例外処理を妨げないようにする。
制御は、いくつかの異なる方法でインジェクタ１２６によって取得することができる。
これらの異なる方法のそれぞれは、アプリケーションバイナリがロードされる仮想アドレスを変更することなく、当該アプリケーションバイナリをロードする。
一例として、Ｏ／Ｓカーネルローダが、アプリケーションの実行可能イメージをロードする際に、ＤＥＬＩ１００（例えば、共有ライブラリとしてコンパイルされた）が、Ｏ／Ｓカーネルローダによって自動的にロードされるように、Ｏ／Ｓカーネルローダを変更することができる。
あるいは、ユーザレベルローダを使用することにより、カーネルローダを変更することなく、当該カーネルローダを利用することができる。
それによって、アプリケーション１０２は、サスペンドモードにおいてメモリにロードされ、後にアプリケーションが再開した時にＤＥＬＩ１００の共有ライブラリをロードすることになる命令が、後にそのアプリケーションに（例えば、アプリケーションスタック上で）インジェクトされる。
【００２３】
別の代替形態では、ｐｔｒａｃｅを使用して、ＤＥＬＩ１００をアプリケーション１０２にアタッチすることができる。
当技術分野において既知のように、ｐｔｒａｃｅは、多くの場合、デバッグによって使用されるメカニズムであり、あるプロセスが別のプロセスを制御することを可能にするメカニズムである。
ｐｔｒａｃｅを介してアプリケーション１０２にアタッチする別個のプロセスであって、アプリケーションのバイナリイメージ（例えば、ｃｒｔ０）の先頭にある実行起動コードが、アプリケーションのエントリポイントをまさに呼び出そうとする地点までアプリケーションを実行するプロセスとして、ＤＥＬＩ１００を構成することができる。
次いで、アプリケーション１０２の実行をサスペンドすることができ、ＤＥＬＩ１００を使用して、アプリケーション命令をフェッチし、それらの命令をアプリケーションの代わりに実行することができる。
【００２４】
さらに別の代替形態では、アプリケーションのテキストセグメントを、実行可能ファイルの別個のコピーにおいて拡張することができる。
特に、アプリケーションのバイナリイメージを一時的な場所にコピーでき、アプリケーションのテキストセグメントの最後にＤＥＬＩテキストセグメントを追加することによってアプリケーションのテキストセグメントを拡張でき、開始シンボル（すなわち、ｃｒｔ０によって呼び出されるエントリポイント）をＤＥＬＩエントリポイントに変更できる。
次いで、その結果生成された実行可能ファイルを、ｅｘｅｃを使用して実行することができる。
元のアプリケーションのテキストセグメントは、そのテキストセグメントが標準的に有する仮想アドレスと同じ仮想アドレスに今までどおりロードされるが、実際のアプリケーション１０２が起動する前に、ＤＥＬＩ１００が制御を取得することになる。
【００２５】
別の例において、ＤＥＬＩ１００は、ｃｒｔ０の特別版を使用してアプリケーション１０２の制御を取得することができる。
当技術分野において既知のように、ｃｒｔ０コードは、コマンドライン引数を拾い上げ、初期スタックおよびデータセグメントをセットアップし、次いで、開始シンボル（一般に、アプリケーション１０２のｍａｉｎ（）関数）の値を呼び出す役割を有する。
アプリケーション１０２のエントリポイントを呼び出す前に、ｃｒｔ０は、ダイナミックリンクローダｄｌｄをマッピングし、次いで、ダイナミックリンクローダｄｌｄは、アプリケーション１０２によって参照される動的にリンクされたあらゆるライブラリ（ＤＬＬ）をロードする。
ｃｒｔ０のカスタム版を使用すると、ＤＥＬＩコード（それ自体はＤＬＬとしてコンパイルされている）をさらにマッピングすることができ、開始シンボルによって定義されたエントリポイントの代わりにＤＥＬＩのエントリポイントを呼び出すことができる。
【００２６】
次いで、アプリケーション１０２の制御を取得する方法とは無関係に、命令フェッチコントローラ１２８を使用して、アプリケーションバイナリコードのフラグメント（例えばトレース）のコピーを抽出（すなわちフェッチ）することができ、それらのコピーをキャッシュするためにＤＥＬＩコア１０６に渡すことができ、そして、キャッシュされた適切なコピーを、コアのコードキャッシュ（複数可）１２４から実行するようにコア１０６に指示することができる。
このようなオペレーションを容易にする際のトランスペアレントモードレイヤ１１０の使用については、図４に関連して以下に説明する。
【００２７】
本明細書では、ＤＥＬＩ１００を、ＡＰＩ１０８を含むものとして図示して説明してきたが、当業者ならば、この開示を全体として見ることにより、要求される動作モードに完全に依存してＡＰＩを省略可能であるということが分かることに留意すべきである。
例えば、ＤＥＬＩ１００が、完全なトランスペアレントモードでのみ動作するものである場合、ＡＰＩ１０８は不要とすることができる。
【００２８】
上述したように、システム制御／構成レイヤ１１２は、コードのキャッシュおよびリンクのポリシーを提供することにより、ＤＥＬＩ１００の構成を可能にする。
ＤＥＬＩ１００は、どの特定の種類のポリシーにもポリシーの内容にも限定されるものではないが、これらのポリシーは、通常、ＤＥＬＩがどのように挙動するかを決定する。
例えば、レイヤ１１２は、コードフラグメントをアプリケーション１０２からどのようにして抽出するのか、元のコードからフラグメントをどのようにして作成するのか、複数のコードフラグメントを互いにどのようにリンクしてより大きなコードフラグメントを形成できるのかなどに関するポリシーを提供することができる。
このレイヤのポリシーは、静的なものとすることもできるし、動的なものとすることもできる。
前者の場合には、ポリシーをＤＥＬＩ１００内にハードコード化することができ、構築時に構成を固定することができる。
後者の場合には、アプリケーション１０２が、ＡＰＩ１０８の関数呼び出しを通じてポリシーを動的に提供することができる。
ポリシーを実施することにより、ＤＥＬＩ１００が特定のシステムイベントおよび／またはハードウェアイベント（例えば、例外および割り込み）に反応する方法が制御される。
上述したポリシーに加えて、システム制御／構成レイヤ１１２は、コードキャッシュ（複数可）１２４のサイズ、ログファイルを作成するかどうか、コードフラグメントを最適化すべきかどうかなどを指定することができる。
【００２９】
図２は、コア１０６およびそのオペレーションの構成例を示している。
この図に示すように、コア１０６は、ＡＰＩ１０８またはトランスペアレントモードレイヤ１１０から２種類の要求を受け付ける。
第１に、コードフラグメントのキャッシュおよびリンクを行う要求２００を関数インタフェースを通じて受け付けることができる。
このような要求は、例えば「ＤＥＬＩ＿ｅｍｉｔ＿ｆｒａｇｍｅｎｔ（ｔａｇ，ｆｒａｇｂｕｆ）」（ＤＥＬＩ放出フラグメント（タグ，フラグバフ））の形の関数を含むことができる。
この関数は、そのパラメータとしてのコードフラグメントおよび識別子（例えば、タグ）を受け取って、ＤＥＬＩのキャッシュ（複数可）１２４に記憶する。
さらに、コア１０６は、「ＤＥＬＩ＿ｅｘｅｃｕｔｅ＿ｆｒａｇｍｅｎｔ（ｔａｇ）」（ＤＥＬＩ実行フラグメント（タグ））などの関数インタフェースを通じて、特定のコードフラグメントタグで実行を開始する要求を受け付ける。
この関数インタフェースは、キャッシュ（複数可）１２４に記憶されたコードフラグメントを特定して、実行するためにハードウェア１０４に渡す。
【００３０】
コアコントローラ１１６は、これらの要求を処理して、適切なコアモジュールにディスパッチする。
次いで、所与の識別子を有するコードフラグメントを放出するための要求２０２をフラグメントマネージャ１２０に渡すことができる。
フラグメントマネージャ１２０は、そのフラグメント形成ポリシー２０４に従ってこのコードフラグメントを変換し、場合によっては、そのインスツルメンテーションポリシー２０６に従ってこのコードフラグメントにインスツルメントし、このコードフラグメントを、そのフラグメントリンクポリシー２０８に従って、事前にキャッシュされたフラグメントと共にリンクする。
例えば、フラグメントマネージャ１２０は、キャッシュ（複数可）１２４の複数のコードフラグメントをリンクすることができ、その結果、実行は、あるコードフラグメントの実行終了時に別のコードフラグメントにジャンプし、それによって、キャッシュ（複数可）からの実行長は増加する。
これを達成するために、フラグメントマネージャ１２０は、フラグメント割り当て命令２１０をキャッシュマネージャ１１８に発行する。
次いで、フラグメントマネージャ１２０は、コードキャッシュ（複数可）１２４内の処理されたコードフラグメントを割り当てる要求をキャッシュマネージャ１１８に送る。
【００３１】
キャッシュマネージャ１１８は、コードフラグメントの割り当てを制御し、通常、キャッシュ空間を管理するために、それ自身のキャッシュポリシー２１２を備える。
しかしながら、フラグメントマネージャ１２０は、特定のフラグメント割り当て解除命令２１４をキャッシュマネージャ１１８に発行することもできる。
例えば、フラグメントマネージャ１２０は、現在のフラグメントを、事前に割り当てられたフラグメントと統合することを決定することがある。
この場合、前のフラグメントを割り当て解除する必要があり得る。
いくつかの配置において、キャッシュマネージャ１１８およびフラグメントマネージャ１２０は、２００１年５月２２日に発行された「A preemptive Replacement Strategy for a Caching Dynamic Translator Based on Changes in the Translation Rate」という発明の名称の米国特許第６，２３７，０６５号に図示および記載された方法で、コードキャッシュ（複数可）１２４およびコードフラグメントを管理することができる。
ここで、この米国特許は、参照により本開示に援用される。
あるいは、コードキャッシュ（複数可）１２４およびコードフラグメントの管理は、２００１年１月５日に出願された「A Partitioned Code Cache Organization to Exploit Program Locality」という発明の名称の米国特許出願第０９／７５５，３８９号に図示および記載された方法で実行することもできる。
ここで、この米国特許出願も、参照により本開示に援用される。
【００３２】
キャッシュマネージャ１１８にフラグメントを渡す前に、フラグメントマネージャ１２０は、そのフラグメントを最適化マネージャ１２２に渡して（２１６）、その最適化ポリシー２１８に従ってコードフラグメントの品質を改善することができる。
いくつかの配置において、最適化マネージャ１２２は、２００１年１月５日に出願された「A Fast Runtime Scheme for Removing Dead Code Across Linked Fragments」という発明の名称の米国特許出願０９／７５５，３８１号に図示および記載された方法でコードフラグメントを最適化することができる。
ここで、この米国特許出願は、参照により本開示に援用される。
あるいは、最適化マネージャ１２２は、２００１年１月５日に出願された「A Memory Disambiguation Scheme for Partially Redundant Load Removal」という発明の名称の米国特許出願０９／７５５，７７４号に図示および記載された方法で、コードフラグメントを最適化することもできる。
ここで、この米国特許出願も、参照により本開示に援用される。
特に、最適化マネージャ１２２は、冗長な計算の削除、冗長なメモリアクセスの削除、関数を直列化して手順呼び出し／復帰のオーバーヘッドの除去などの古典的なコンパイラ最適化技術を使用してコードフラグメントを最適化することもできる。
一方、アプリケーションをプロファイリングするためにＤＥＬＩ１００を使用する場合、コードフラグメントは、所望のコード統計値および測定値を収集するように最適化されないことが予測される。
【００３３】
上述したように、フラグメントマネージャ１２０は、そのフラグメント形成ポリシー２０４に従ってコードフラグメントを変換する。
フラグメントマネージャ１２０が実行した変換は、例えば、相対アドレス、分岐アドレスなどを変更することによりメモリアドレス参照を変えることによるコードの再配置を含むことができる。
コードフラグメントのレイアウトも、その機能（すなわち、セマンティクス）を変えることなく、コードの物理的なレイアウトを変えて変更することができる。
これらの変換は、ＡＰＩ１０８を通じて受け取ったフラグメントおよび命令フェッチコントローラ１２８から受け取ったフラグメントに対してフラグメントマネージャ１２０により実行される。
【００３４】
コードインスツルメンテーションを実行するために、フラグメントマネージャ１２０は、コードプロファイリング用のインスツルメンテーションポリシー２０６に従って、コードフラグメントの実行頻度に関するデータ、メモリアドレスのアクセス頻度に関するデータなどのデータを収集する。
フラグメントの形成または割り当て解除を容易にするために、プログラムカウンタを使用して、これらの統計値を収集することができる。
これらのポリシーは、システム制御／構成レイヤ１１２によって構成される。
システム制御／構成レイヤ１１２は、ＡＰＩ１０８を通じて送られたポリシー命令またはＤＥＬＩ構築時に確立されたポリシー命令のいずれかを受け取る。
ポリシーは、さまざまなフラグメント作成方法、さまざまなフラグメントインスツルメント方法、さまざまなフラグメント最適化方法、およびさまざまなフラグメントリンク方法の選択肢を含むこともできるし、あるいは、ポリシーは、単に、これらのタスクを実行するＤＥＬＩ１００のハードコード化されたアルゴリズムとすることもできる。
【００３５】
ＤＥＬＩコア１０６が受け付ける第２の種類の要求は、所与の識別子（例えばタグ）によって特定されたフラグメントを実行する要求２２０である。
このような場合に、コアコントローラ１１６は、フラグメントマネージャ１２０にルックアップ要求２２２を発行する。
フラグメントマネージャ１２０は、そのフラグメントが、現在、キャッシュ（複数可）１２４に存在してアクティブである場合に、対応するコードキャッシュアドレス２２４を返す。
一例として、フラグメントマネージャ１２０は、存在するアクティブなコードフラグメントのルックアップテーブルを保持することができる。
このルックアップテーブルでは、タグを使用して、コードフラグメントの位置を特定することができる。
あるいは、フラグメントマネージャ１２０またはキャッシュマネージャ１１８は、コードフラグメントが存在しアクティブであるかどうかを追跡する他の任意の適切な技術を使用することもできる。
フラグメントが、キャッシュ（複数可）１２４に現在存在せずアクティブでない場合に、フラグメントマネージャ１２０は、コアコントローラ１１６にエラーコードを返す。
コアコントローラ１１６は、最初の要求者にそのフラグメントタグをキャッシュミスアドレスとして返す（２２６）。
他方、フラグメントが、現在存在しアクティブである場合、コアコントローラ１１６は、その最初の要求を、そのキャッシュアドレスと共にキャッシュマネージャ１１８にパッチする（２２８）。
次に、キャッシュマネージャ１１８は、そのコードキャッシュ（複数可）においてアドレス指定されたコードフラグメントに制御を移し、したがって、アドレス指定されたコードフラグメントを実行する。
次いで、キャッシュミスが発生するまで、すなわち、実行対象の次のアプリケーションのアドレスのコピーが、キャッシュ（複数可）に現在存在しないという事態が発生するまで、コードキャッシュ（複数可）１２４に実行が集中する状態が続く。
この状況は、例えば、実行中のコードがコードキャッシュ（複数可）１２４からエスケープする試みによって検出することができる。
キャッシュミスが、キャッシュマネージャ１１８からコアコントローラ１１６に報告され（２３０）、次に、最初の要求者に戻される（２２６）。
【００３６】
図３は、ＤＥＬＩ１００を実行することができる、例えばマルチプログラミングされたシステムなどのコンピュータシステム３００のアーキテクチャ例を示す概略図である。
一般的に言うと、このコンピュータシステム３００は、デスクトップコンピュータ、ポータブルコンピュータ、専用サーバコンピュータ、マルチプロセッサコンピューティングデバイスなどの多種多様な有線および／または無線のコンピューティングデバイスのいずれか１つを含むことができる。
その特定の配置に関係なく、コンピュータシステム３００は、例えば、処理デバイス３０２、メモリ３０４、１つまたは２つ以上のユーザインタフェースデバイス３０６、表示装置３０８、１つまたは２つ以上の入出力（Ｉ／Ｏ）デバイス３１０、および１つまたは２つ以上のネットワーク接続デバイス３１２を備える。
これらのそれぞれは、ローカルインタフェース３１４に接続されている。
【００３７】
処理デバイス３０２には、あらゆるカスタムメイドのプロセッサまたは市販のプロセッサ、中央処理装置（ＣＰＵ）またはコンピュータシステム３００に関連したいくつかのプロセッサのうちのある補助プロセッサ、半導体ベースのマイクロプロセッサ（マイクロチップの形）、マクロプロセッサ、１つまたは２つ以上の特定用途向け集積回路（ＡＳＩＣ）、適切に構成された複数のデジタル論理ゲート、ならびに、個別のディスクリート素子およびさまざまな組み合わせのディスクリート素子の双方を備えてコンピューティングシステムの全体のオペレーションを調整する他の既知の電気的な構成が含まれ得る。
【００３８】
メモリ３０４には、揮発性メモリ素子（例えば、ランダムアクセスメモリ（ＤＲＡＭ、ＳＲＡＭなどのＲＡＭ））および不揮発性メモリ素子（例えば、ＲＯＭ、ハードドライブ、テープ、ＣＤＲＯＭなど）の任意の１つの組み合わせが含まれ得る。
メモリ３０４は、通常、Ｏ／Ｓ３１６、１つまたは２つ以上のアプリケーション１０２（例えば、ユーザアプリケーションおよび／もしくはクライアント）、ならびにＤＥＬＩ１００を含む。
ＤＥＬＩ１００については、すでに詳細に説明した。
当業者ならば、メモリ３０４には、簡潔にするために省略された他のコンポーネントが含まれ得ることが理解され、また、通常は、含まれることになることが理解されよう。
【００３９】
１つまたは２つ以上のユーザインタフェースデバイス３０６は、ユーザがコンピューティングシステム３００と対話できるコンポーネントを備える。
例えば、コンピューティングシステム３００が、パーソナルコンピュータ（ＰＣ）を含む場合、これらのコンポーネントには、キーボードおよびマウスが含まれ得る。
コンピューティングシステム３００が、ハンドヘルドデバイス（例えば、ＰＤＡ、携帯電話）を含む場合、これらのコンポーネントには、ファンクションキーまたはファンクションボタン、タッチセンシティブスクリーン、スタイラスなどが含まれ得る。
表示装置３０８には、ＰＣ用のコンピュータモニタもしくはプラズマスクリーンまたはハンドヘルドデバイス用の液晶表示装置（ＬＣＤ）が含まれ得る。
【００４０】
図３をさらに参照して、１つまたは２つ以上のＩ／Ｏデバイス３１０は、コンピューティングシステム３００を別のシステムおよび／またはデバイスへ接続することを容易にするように適合され、したがって、Ｉ／Ｏデバイス３１０には、１つまたは２つ以上のシリアルもしくはパラレルの小型コンピュータ用周辺機器インタフェース（ＳＣＳＩ）、ユニバーサルシリアルバス（ＵＳＢ）、ＩＥＥＥ  １３９４（例えば、ファイアワイア（商標））、および／もしくはパーソナルエリアネットワーク（ＰＡＮ）のコンポーネントが含まれ得る。
ネットワークインタフェースデバイス３１２は、ネットワークを介したデータの送信および／または受信に使用されるこれらのさまざまなコンポーネントを備える。
一例として、ネットワークインタフェースデバイス３１２には、入力および出力の双方を通信できるデバイスが含まれ、例えば、変調器／復調器（例えばモデム）、無線（例えば無線周波（ＲＦ））トランシーバ、電話インタフェース、ブリッジ、ルータ、ネットワークカードなどが含まれる。
【００４１】
さまざまなソフトウェアおよび／またはファームウェアが、本明細書で説明されている。
このソフトウェアおよび／またはファームウェアは、任意のコンピュータ関連システムもしくはコンピュータ関連方法により使用されるか、または、これらのものと共に使用される任意のコンピュータ可読媒体に記憶できることが理解されるべきである。
この文書の状況において、コンピュータ可読媒体とは、コンピュータプログラムを含むことができるか、または、記憶することができる電子的、磁気的、光学的、または他の物理的なデバイスもしくは手段を示す。
このコンピュータプログラムは、コンピュータ関連システムもしくはコンピュータ関連方法により使用されるか、または、これらのものと共に使用されるものである。
これらのプログラムは、命令実行システム、命令実行装置、または命令実行デバイスにより使用されるか、または、これらのものと共に使用される任意のコンピュータ可読媒体に具体化することができる。
これらの命令実行システム、命令実行装置、または命令実行デバイスとしては、コンピュータベースのシステム、プロセッサを含むシステム、または、命令実行システム、命令実行装置、もしくは命令実行デバイスから命令をフェッチしてその命令を実行できる他のシステムなどがある。
この文書の状況において、「コンピュータ可読媒体」は、命令実行システム、命令実行装置、もしくは命令実行デバイスにより使用されるか、または、これらのものと共に使用されるプログラムの記憶、通信、伝搬、または搬送を行うことができる任意の手段とすることができる。
【００４２】
コンピュータ可読媒体は、例えば、電子的、磁気的、光学的、電磁気、赤外線、または半導体のシステム、装置、デバイス、もしくは伝搬媒体とすることができるが、これらに限定されるものではない。
コンピュータ可読媒体のより具体的な例（網羅した一覧ではない）には、１本または２本以上のワイアを有する電気接続、ポータブルコンピュータディスケット、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、消去可能プログラマブル読み出し専用メモリ（ＥＰＲＯＭ、ＥＥＰＲＯＭ、またはフラッシュメモリ）、光ファイバ、およびポータブルコンパクトディスク読み出し専用メモリ（ＣＤＲＯＭ）が含まれる。
プログラムは、例えば、用紙または他の媒体の光学式スキャンを介して電気的に取り込むことができ、次いで、必要に応じてコンパイル、解釈、または適切な方法によるそれ以外の処理を行うことができ、次いで、コンピュータメモリに記憶できるので、コンピュータ可読媒体は、さらに、プログラムが印刷される用紙とすることもできるし、別の適切な媒体とすることもできることに留意されたい。
【００４３】
次に、上述したＤＥＬＩ１００の一般的な性質として、ＤＥＬＩのオペレーション例を解説する。
上記で特定したように、ＤＥＬＩ１００は、２つの一般的な動作モード、すなわちトランスペアレントモードおよび非トランスペアレントモードに加えてそれらを組み合わせたもので動作する。
図４は、トランスペアレントモードのオペレーションを示している。
この動作モードの説明では、フロー図を提供する。
この開示のフロー図のあらゆるプロセスステップまたはプロセスブロックは、プロセスにおける特定の論理関数もしくは論理ステップを実施する１つまたは２つ以上の実行可能命令を含むコードのモジュール、セグメント、または部分を表すことが理解されるべきである。
特定の例のプロセスステップを説明するが、代替的な実施態様も実施可能であることが理解されよう。
さらに、ステップは、それに伴う機能に応じて、ほぼ同時または逆の順序を含めて、図示または解説したものとは異なる順序で実行することもできる。
【００４４】
一般的に言うと、ＤＥＬＩ１００がアプリケーション１０２の実行の制御をトランスペアレントに取得するのか、非トランスペアレントに取得するのかにかかわらず、アプリケーションは、ハードウェア１０４上では直接実行されない。
そうではなく、アプリケーションコードは、例えば、コードキャッシュ（複数可）１２４に保持され得るコードフラグメントの形でＤＥＬＩ１００を通じて実行される。
図４は、アプリケーション１０２がＤＥＬＩの存在に気付かない完全なトランスペアレントモードでＤＥＬＩ１００が動作する簡単な例を示している。
ブロック４００から開始して、まず、ＤＥＬＩ１００が起動される。
トランスペアレントモードで動作している場合、この起動は、アプリケーション１０２の起動の結果として行うことができる。
ブロック４０２に示すように、アプリケーション１０２の起動時に、ＤＥＬＩ１００は、トランスペアレントモードレイヤ１１０のインジェクタ１２６によりアプリケーション１０２にインジェクトされる。
その結果、ＤＥＬＩは、アプリケーションおよびその実行の制御を取得する。
上述したように、この制御を取得できるさまざまな異なる方法が存在する。
【００４５】
ＤＥＬＩ１００が、アプリケーション１０２の制御を有すると、ＤＥＬＩを使用して、上述したサービスなど、いくつかの異なるサービスのいずれか１つを提供することができる。
例えば、ＤＥＬＩ１００は、ハードウェアエミュレーションおよび／またはソフトウェアエミュレーション、動的な変換および最適化、トランスペアレントなリモートのコード実行、仮想化されたハードウェア環境のプログラム用のコンピュータシステム機能の再マッピング、コードの伸張、コードの解読などを容易にすることができる。
これらの異なるサービスには、それぞれ、コードキャッシュ（複数可）１２４内へのプログラムコードフラグメントのキャッシュおよびリンクが必要となる。
アプリケーションバイナリからコピーされた一定のコードフラグメントをキャッシュし、それらのコードフラグメントをある方法で変換することにより、後に、変換したコードをコードキャッシュ（複数可）１２４から実行することによって、所望のサービスを提供することができる。
【００４６】
コードをキャッシュする前に、ＤＥＬＩ１００は、どの特定のコードフラグメントをキャッシュすべきかを決定しなければならない。
完全なトランスペアレントモードで動作している場合、アプリケーション１０２は、ＤＥＬＩ１００に気付かないことから、ＤＥＬＩは、どのコードフラグメントをキャッシュすべきかについての案内をアプリケーションから受け取ることはない。
コードのキャッシュは、ＤＥＬＩ構築時に作成されたポリシーを通じて指示することができるが、より一般的には、ＤＥＬＩ１００は、少なくとも部分的に、独力でこれらの決定を行うことになる。
ブロック４０４に示すように、ＤＥＬＩ１００は、アプリケーションコードの実行を監視することにより、この決定を行うことができる。
監視している際に、ＤＥＬＩ１００は、例えば、どのフラグメントが最も頻繁に使用されるかを判断することにより、例えば、どのコードフラグメントがアプリケーション１０２にとって最も有用であるかに関する情報を収集することができる。
【００４７】
さまざまなコードフラグメントが、ＤＥＬＩ１００の制御下で、アプリケーション１０２によって実行されるので、ＤＥＬＩは、実行される各コードを「見る」。
したがって、監視プロセスを通じて、ＤＥＬＩ１００は、どのコードフラグメントが最も頻繁に使用されるかを判断することができる。
次いで、ＤＥＬＩ１００は、システム制御／構成レイヤ１１２によって提供されるポリシーを参照して、どのコードが「ホット」であるのか、すなわち、アプリケーションの実行に最も重要であるのかの判断を行うことができる。
上述したように、この判断は、実行インスタンスを追跡するプログラムカウンタを使用して行うことができる。
当業者ならば、他のさまざまな方法を使用して、どのコードがホットであるのかの判断が可能であることが理解されよう。
この判断を行うことができる方法の例は、１９９８年１１月５日に出願された「Method for Selecting Active Code Traces for Translation in a Caching Dynamic Translator」という発明の名称の米国特許出願第０９／１８６，９４５号、および、１９９９年５月１４日に出願された「Low Overhead Speculative Selection of Hot Traces in a Caching Dynamic Translator」という発明の名称の米国特許出願第０９／３１２，２９６号に記載されている。
ここで、これらの出願は共に、参照により本開示に援用される。
【００４８】
図４をさらに参照して、判定ブロック４０６に示すように、各コードフラグメントが実行されるごとに、ＤＥＬＩ１００は、関連したコードフラグメントが事前にキャッシュされたものであるかどうかを判断することができる。
事前にキャッシュされたものである場合、ブロック４０８に示すように、ＤＥＬＩ１００は、キャッシュ（および場合によっては変換）されたコードを含むコードキャッシュ（複数可）１２４にジャンプし、このコードが、元のアプリケーションコードの代わりにハードウェア１０４によって実行される。
コードがキャッシュされたものであるかどうかの判断は、上述したように、ネイティブアプリケーションコードと、コードキャッシュ（複数可）１２４内にキャッシュされている類似のものとの間の関連を特定する識別子（例えばタグ）を参照して行うことができる。
次いで、キャッシュされていないコードの参照（すなわち、キャッシュミス）が発生する時まで、キャッシュされたコードの実行が、コードキャッシュ（複数可）１２４に存在するリンクされたコードフラグメントの実行を含めて、継続される。
判定要素４１０を参照して、キャッシュされていないコードの参照が発生すると、ブロック４１２に示すように、ＤＥＬＩ１００は、アプリケーションコードにジャンプし、そのコードの実行が再開される。
この時点で、ＤＥＬＩ１００は、この実行の監視を再開することができる（ブロック４０４）。
【００４９】
判定要素４０６に戻って、関連したコードフラグメントがコードキャッシュ（複数可）１２４に存在しないとＤＥＬＩ１００が判断した場合、フローは、判定要素４１４に進む。
判定要素４１４において、あらかじめ定められたポリシーを参照して、コードフラグメントがホットであるかどうかが判断される。
コードがホットでない場合、フローは、ブロック４０４に戻り、ブロック４０４において、アプリケーションコードの実行監視が継続される。
他方、コードがホットである場合、ブロック４１６に示すように、トランスペアレントモードレイヤ１１０の命令フェッチコントローラ１２８を使用してフラグメントをフェッチすることにより、コードフラグメントがコピーされる。
必要に応じて、各コードは、そのコードがホットであるかどうかを判定要素４１４で判断する前に、コピーできることに留意されたい。
一方、このような変更は、システム１００の全体のオペレーションにも影響を与えないし、達成可能な結果にも影響を与えない。
【００５０】
この時点で、ブロック４１８に示すように、コードフラグメントをある方法で変換することができる。
さらに、キャッシュ（複数可）１２４内のコードフラグメントを、コードリンク用に確立されたポリシーに従ってリンクすることもできる。
コード変換の性質は、ＤＥＬＩ１００が提供するサービスの種類に依存する。
例えば、ＤＥＬＩ１００が、アプリケーションの実行を単に最適化するだけのものである場合、この変換は、より良い性能を得るために、コードを再配置することおよび／または再構成することを含むことができる。
提供される変換の性質にかかわらず、コードの構造は、基礎となるセマンティクスを変更しないように変更される。
コードフラグメントが変換されると、ブロック４２０に示すように、変換されたコードは、コードキャッシュ（複数可）１２４内にキャッシュすることができる。
そして、フローは上述したブロック４０８に進み、変換されたコードは、ＤＥＬＩ１００内で実行される。
【００５１】
上記例では、コードは、ホットであるとみなされる場合にキャッシュされるが、他の判断基準を使用して、どのコードをキャッシュすべきかを判断することもできる。
実際には、いくつかの配置において、ほぼすべての実行が、最終的にはコードキャッシュ（複数可）１２４内で行われるように、各コード（または少なくともそのコードの関連したバージョン）をキャッシュすることができる。
【００５２】
上述したように、ＤＥＬＩ１００は、非トランスペアレントモードで動作することもできる。
一般的に言うと、ＤＥＬＩ１００は、非トランスペアレントモードで動作している場合、例えば、ＤＬＬとして、または、アプリケーション１０２がアクセスできるＡＰＩ１０８の関数をエキスポートする静的にリンクされたモジュールとして動作することができる。
最も単純な場合には、アプリケーション（クライアント）は、ＤＥＬＩのオペレーションのあらゆる態様をＡＰＩ１０８を通じて制御する。
このような場合に、ＤＥＬＩ１００を利用すると、クライアントがＡＰＩ１０８を介して提供する明示的な命令に従って、コードのキャッシュ、リンク、および最適化を行うことができる。
あるいは、ハイブリッドな配置では、クライアントは、ＤＥＬＩ１００に、トランスペアレント形式でそのサービスを提供するように要求することができる。
このような場合、クライアントは、ＤＥＬＩ１００のオペレーションを起動すると共に、ＤＥＬＩがそのオペレーションを停止する時に応じて、命令を提供する。
いずれの場合も、クライアントは、ＤＥＬＩ１００に気付いており、ＤＥＬＩのサービスを利用するように構成される。
プロファイリングのシナリオにおいて、アプリケーション１０２は、一般に、ＤＥＬＩの存在に気付かないことから、非トランスペアレントモードのオペレーションについては、詳細には説明しない。
しかしながら、アプリケーションソフトウェアが、このようなプロファイリングを容易にするように記述されているか、または、起動するように記述されている場合、このようなプロファイリングを非トランスペアレント形式で提供できることが、当業者には理解されよう。
【００５３】
上述したように、既存のほとんどのプロファイリング方法は、プロファイリングの正確さおよびオーバーヘッドの観点から不利である。
しかしながら、ＤＥＬＩ１００は、ランタイムにおいて低レベルのコード（例えば、アプリケーションバイナリ）を制御することから、ＤＥＬＩ１００を使用すると、これらの問題の大部分は回避可能である。
したがって、ＤＥＬＩ１００は、それぞれのアプリケーション関数、基本ブロック、または個々の命令の実行を監視して、アプリケーションコードの実行に関する情報を取得することができる。
さらに、コードフラグメントがホットである場合を判断するＤＥＬＩの能力により、ＤＥＬＩ１００を使用すると、最も頻繁に使用されるコードの部分のみにインスツルメンテーションを限定することができ、それによって、プロファイリングのオーバーヘッドを低減することができる。
【００５４】
図５に、アプリケーションのプロファイリングを容易にする際のＤＥＬＩのオペレーション例を示す。
ブロック５００から開始して、ＤＥＬＩ１００が起動される。
そして、ブロック５０２に示すように、ＤＥＬＩ１００は、アプリケーション１０２の実行の制御を取得するために、アプリケーション１０２の開始前にアプリケーション１０２にインジェクトされる。
図４について説明した動作モードと同様に、ＤＥＬＩ１００は、コードの実行を監視して、どのコードフラグメントがキャッシュされるべきかを決定し、したがって、ブロック５０４に示すように、アプリケーション命令をインターセプトする。
したがって、判定要素５０６に示すように、ＤＥＬＩ１００は、まず、関連したコードフラグメントが、事前にキャッシュされたものであるかどうかを判断することができる。
事前にキャッシュされたものである場合、ブロック５０８に示すように、ＤＥＬＩ１００は、そのコードを含むコードキャッシュ（複数可）１２４にジャンプし、このコードが、元のアプリケーションコードの代わりにハードウェア１０４によって実行される。
この場合も、キャッシュされていないコードの参照が発生するまで、例えば、キャッシュミスが発生するまで、キャッシュされたコードの実行が継続され（５１０）、キャッシュミスが発生した時に、ＤＥＬＩ１００は、アプリケーションコードおよびブロック５０４にジャンプして戻る。
【００５５】
判定要素５０８を再び参照して、関連したコードフラグメントが、コードキャッシュ（複数可）１２４に存在しない場合、フローは、ブロック５１２に進み、ブロック５１２において、コードフラグメント（１つまたは２つ以上のアプリケーション命令）が、例えば、１つまたは２つ以上の命令バッファにコピーされる。
次いで、ブロック５１４に示すように、ＤＥＬＩ１００は、コードフラグメントの実行に関する情報を記録することができる。
一例として、この情報には、コードフラグメントが実行されたこと（１回の繰り返し）、どの命令（複数可）がそのコードフラグメントを呼び出したか、そのコードフラグメントがどの命令（複数可）を呼び出すかなどが含まれ得る。
特に、従来のプロファイリング方法と異なり、情報は、アプリケーションがアクセスするあらゆる共有ライブラリ内に含まれる命令（例えばルーチン）の実行に関しても収集される。
一般に、収集されたさまざまな情報は、ファイルに配置される。
このファイルは、適切なプロファイリングプログラムによって使用され、それによって、アプリケーションが実行される方法に関する情報を明らかにするコールグラフが生成される。
さらに、任意の所与の入力に対してどのコードが関係しているかの表示をプログラマに提供するために、収集された情報から、アプリケーションの有効範囲を求めることができる。
【００５６】
次に、判定要素５１６を参照して、ＤＥＬＩ１００は、図４について説明した方法で、コードフラグメントがホットであるかどうかを判断する。
コードフラグメントがホットでない場合、フローは、単にブロック５０４に戻り、ブロック５０４において、ＤＥＬＩ１００は、アプリケーション命令のインターセプトを継続する。
他方、コードフラグメントがホットである場合、すなわち、フラグメントが、あらかじめ確立されたポリシーによって決定されるような頻繁に使用されるコードフラグメントである場合、フローは、ブロック５１８に進み、ブロック５１８において、コードフラグメントが、プロファイリング用にインスツルメントされる。
このインスツルメンテーションは、図５のフローから明らかなように、ＤＥＬＩ１００が、コードキャッシュ（複数可）１２４内のコードの実行を明示的に監視しないことから必要とされる。
【００５７】
さまざまな情報を収集するようにコードフラグメントにインスツルメントすることができる。
この場合も、この情報には、コードフラグメントが実行されたこと、どの命令（複数可）がそのコードフラグメントを呼び出したか、そのフラグメントがどの命令（複数可）を呼び出すかなどが含まれ得る。
さらに、コードフラグメントにインスツルメントして、ＤＥＬＩ１００が保持するサイクルカウンタ（図示せず）をインクリメントすることができ、それによって、そのコードフラグメントを実行するのに必要なプロセッササイクル数を概算し、アプリケーションのオペレーション中にそのフラグメントの実行に要した時間を見積もることができる。
インクリメントの幅は、どの程度のプロセッササイクル数がフラグメントの実行に必要とされるかに関するＤＥＬＩの見積もりによって指示される。
例えば、このインスツルメンテーションにおいて、４０プロセッササイクルがフラグメントの実行に必要であるとＤＥＬＩ１００が見積もった場合に、コードフラグメントが実行されるごとに、４０サイクル単位で、関連するカウンタをインクリメントすることができる。
一例として、ＤＥＬＩ１００は、アーキテクチャ仕様マニュアルで所与のアーキテクチャについて指定されるサイクルで表された命令数および当該命令の理論的実行待ち時間をカウントすることにより、サイクル数を見積もることができる。
この方法は、有益ではあるが、命令およびデータのキャッシュがストールしたり、効率的なキャッシュオペレーション用に使用されるキャッシュメカニズムが失敗して補充を行うなどの動的なイベントによるサイクルカウントへの寄与を無視するという欠点を有する。
この欠点がない別の見積もり方法は、所定のハードウェアカウンタが利用可能であることに基づくものである。
この所定のハードウェアは、ＤＥＬＩ１００がセットアップできるものであり、かつ、ＤＥＬＩがフラグメントの開始および終了に挿入した命令コードによりポーリングされて、そのフラグメントの実行に必要なサイクル数を導出できるものである。
それぞれ個々のフラグメントの実行に関する情報を収集できるように、コードフラグメントごとに個別のカウンタを使用することもできる。
さらに、キャッシュされたすべてのコードフラグメントの実行時間を反映するグローバルカウンタを設けることもできる。
【００５８】
プロセッサ速度が判明しているか、または、ハードウェアカウンタが使用される場合には、カウンタ周波数が判明している限り、収集されたサイクル情報により、各コードフラグメントの実行に要した時間の見積もりを求めることができる。
次いで、この情報は、プロファイリングプログラムによって生成されたコールグラフ（または他の出力）内に含めることができる。
キャッシュされたコードフラグメントにインスツルメンテーションを追加することは、アプリケーションの実行にオーバーヘッドを追加することになるが、コードに対する影響が最小限である低レベルの命令の形で、インスツルメンテーションが挿入されることから、このオーバーヘッド量は、従来のプロファイリング方法で追加されるものよりも非常に小さい。
コードフラグメントがインスツルメントされると、そのコードフラグメントは、コードキャッシュ（複数可）１２４に放出され、フローは、上述したブロック５０８に戻る。
【００５９】
ＤＥＬＩ１００は、元のどのアプリケーションコードが、コードキャッシュのコードに関連付けられているかについて判断でき、かつ、元のコードについての正確な統計出力を生成できることから、上述した方法は、ヒットしたフラグメントがコードキャッシュにおいて実行される場合であっても、別の方法としての統計的なサンプリングを使用してコードをプロファイリングすることを妨げるものではない。
また、ランタイムにおいてインスツルメンテーションを挿入することにより、コードフラグメントまたは関数について、ユーザが定義した量を積算することもでき、かつ／または、監視中のものに対するより多くの制御が、従来のプロファイリング方式よりもはるかに細かな制御レベルでユーザに与えられる。
例えば、プロファイリングの出力が、関連しない情報により乱されないように、ユーザは、コールグラフの一部の選択除去を要求することができる。
プロファイリング情報をプログラマに表示するのに使用されるほとんどのユーティリティは、これをプロファイリングデータ上のポストパス（post-pass）として可能にする。
開示した手法の利点は、それを収集するイベントのオーバーヘッドが除去されることである。
【００６０】
プロファイリングが可能な別の量の別の例としては、多くの場合、測定が困難であると判明するが、命令レベル並列性（ＩＬＰ）の量がある。
このような量は、所与のプログラムまたはアプリケーションを実行するために、プロセッサによって１サイクルあたり並列に実行される基本演算（例えば、縮小命令セットコンピュータ（ＲＩＳＣ）が完了する基本演算など）の平均個数を表す。
このような量は、超長命令語（ＶＬＩＷ）やスーパースカラーなどの一定の種類のマイクロプロセッサおよび一般的には命令レベル並列性を利用するあらゆるプロセッサのプログラム性能を分析するのに非常に重要である。
【００６１】
ＩＬＰ（１命令あたりのサイクル数（ＣＰＩ（cycles per instruction））または１サイクルあたりの命令数（ＩＰＣ（instructions per cycle）として表現されることがある）を測定するために、上述したメカニズムに基づくプロファイル方式を実施することができる。
この場合に追加する唯一必要なものは、実行サイクルに加えて、プロファイラが、上述したような各コードフラグメントに対して実行されるＶＬＩＷ（または並列）命令の個数を積算することである。
実行終了時に、積算されたサイクル数および命令数を使用することにより、全体的なプログラム平均値に加えて、各コードブロックまたは各コードフラグメントあたりの所望の量（ＩＬＰまたはＩＰＣ）を生成することができる。
この生成は、サイクル数を実行命令数で除算してＣＰＩを計算することにより行われるか、または、ＩＰＣを得るために実行命令総数をサイクル数で除算することにより行われる。
【００６２】
コードフラグメントの実行命令数を積算することは、静的にスケジューリングされたＶＬＩＷの場合には、簡単なタスクである。
その理由は、並列命令が、コンパイル時に生成され、それらの構造が、実行中にもはや変更されることがないからである。
フラグメントをコードキャッシュに放出するＤＥＬＩプロセスは、それらのＶＬＩＷ命令をカウントする理想的な場所である。
一方、スーパースカラープロセッサの場合、プログラムの実行中に、並列命令が動的に形成されることから、複雑さが追加される。
これにより、スーパースカラーＣＰＵが並列実行することになる命令数がどの程度であるかを見積もる付加的段階が、フラグメントの放出中に必要となる。
これが見積もられると、その情報を使用して、上述したようなプロファイリングインスツルメンテーションコードが放出される。
スーパースカラーの場合、この手法は、正確さに劣る測定につながる。
【００６３】
上記明細書本文および図面では、例示の目的で、本発明の特定の実施の形態を詳細に開示してきたが、当業者には、本発明の範囲から逸脱することなく、実施の形態の変形および変更を行い得ることが理解されよう。
【図面の簡単な説明】
【００６４】
【図１】コンピュータシステム上で実行されて動的変換サービスを提供する動的実行レイヤインタフェース（ＤＥＬＩ）の一実施の形態を示すブロック図である。
【図２】図１に示すＤＥＬＩのコアの構成およびオペレーションの一実施の形態のブロック図である。
【図３】図１に示すＤＥＬＩを実行できるコンピュータシステムの一実施の形態のブロック図である。
【図４】図１に示すＤＥＬＩのトランスペアレントオペレーションの一実施の形態を示すフロー図である。
【図５】アプリケーションをプロファイリングする際の図１に示すＤＥＬＩのオペレーションの一実施の形態を示すフロー図である。
【符号の説明】
【００６５】
１０２・・・アプリケーション、
１０４・・・ハードウェア、
１０６・・・コア、
１１０・・・トランスペアレントモードレイヤ、
１１２・・・システム制御／構成レイヤ、
１１６・・・コアコントローラ、
１１８・・・キャッシュマネージャ、
１２０・・・フラグメントマネージャ、
１２２・・・最適化マネージャ、
１２６・・・インジェクタ、
１２８・・・命令フェッチコントローラ、
２０４・・・フラグメント形成ポリシー、
２０６・・・インスツルメンテーションポリシー、
２０８・・・フラグメントリンクポリシー、
２１２・・・キャッシュポリシー、
２１８・・・最適化ポリシー、
３０２・・・処理デバイス、
３０４・・・メモリ、
３０６・・・ユーザインタフェースデバイス、
３０８・・・表示装置、
３１０・・・Ｉ／Ｏデバイス、
３１２・・・ネットワークインタフェースデバイス、
３１４・・・ローカルインタフェース、
３１６・・・オペレーティングシステム、
【図１】
2005018760.tif 000003
【図２】
2005018760.tif 000004
【図３】
2005018760.tif 000005
【図４】
2005018760.tif 000006
【図５】
2005018760.tif 000007