発明の分野
[001]本発明は、一般に、デジタルコンピューターシステムに関し、より詳細には、命令シーケンスを含む命令を選択するためのシステム及び方法に関する。本出願は、2014年7月25日に出願された、Mohammad A. Abdallahによる、「A RUNTIME ARCHITECTURE FOR EFFICIENTLY OPTIMIZING AND EXECUTING GUEST CODE AND CONVERTING TO NATIVE CODE」と題する、本発明の譲受人に譲渡された同時継続中の米国仮特許出願第62/029383号の利益を主張する。この米国仮特許出願は全体が本明細書に援用される。
発明の背景
[002]プロセッサは、依存型又は完全に独立型の複数のタスクを処理することを要求される。そのようなプロセッサの内部状態は通例、プログラム実行の各特定の時点に異なる値を保持し得るレジスタからなる。プログラム実行の各時点において、内部状態イメージは、プロセッサのアーキテクチャ状態と呼ばれる。
[003]コード実行が別の機能(例えば、別のスレッド、プロセス又はプログラム)を実行するように切り替えられるとき、新たな機能が内部レジスタを利用して新たな状態を構築することができるように、マシン/プロセッサの状態を保存しなくてはならない。新たな機能が終了すると、その状態は破棄され、前のコンテキストの状態が復元され、実行が再開する。そのような切り替えプロセスは、コンテキスト切り替え(context switch、コンテキストスイッチ)と呼ばれ、通例、特に、多数のレジスタ(例えば、64個、128個、256個)及び/又はアウトオブオーダ実行(out of order execution)を利用する最新のアーキテクチャを用いて、数十又は数百サイクルを含む。
[004]スレッドアウェア(thread-aware)ハードウェアアーキテクチャにおいて、ハードウェアが、ハードウェアによりサポートされた限られた数のスレッドのための複数のコンテキスト状態をサポートすることは一般的である。この場合、ハードウェアは、サポートされるスレッドごとに全てのアーキテクチャ状態要素を複製する。これによって、新たなスレッドを実行するときのコンテキスト切り替えの必要性がなくなる。一方、これは依然として、複数の欠点を有し、すなわち、ハードウェアにおいてサポートされる追加のスレッドごとに全てのアーキテクチャ状態要素(すなわち、レジスタ)を複製するエリア、電力及び複雑性を有する。更に、ソフトウェアスレッド数が明示的にサポートされるハードウェアスレッド数を超えた場合には、依然としてコンテキスト切り替えを実行しなくてはならない。
[005]これは、多数のスレッドを要する細かい粒度で並列処理が必要とされるので、一般的となる。複製コンテキスト状態ハードウェアストレージを有するハードウェアスレッドアウェアアーキテクチャは、スレッド化されていないソフトウェアコードには役立たず、スレッド化されたソフトウェアのためのコンテキスト切り替え数を低減するのみである。一方、これらのスレッドは、通例、粗い粒度の並列処理のために構築され、結果として、開始及び同期のための大幅なソフトウェアオーバーヘッドが生じ、効率的なスレッド化の開始/自動生成を行うことなく、関数の呼び出し及びループの並列実行等の、細かい粒度の並列処理が残される。そのような上記のオーバーヘッドに加えて、そのようなコードの自動並列化は、非明示的に/容易に並列化/スレッド化されたソフトウェアコードのための最先端のコンパイラ又はユーザ並列化技法を用いても困難である。
[006]1つの実施形態において、本発明は、アグノスティックランタイムアーキテクチャ(agnostic runtime architecture)のためのシステムとして実装される。本システムは、ベアメタルに近いJIT(just in time)変換レイヤと、ゲスト仮想マシンから命令を受け取るために変換レイヤ内に含まれるランタイムネイティブ(native)命令アセンブリ構成部と、ネイティブコードから命令を受け取るために変換レイヤ内に含まれるランタイムネイティブ命令シーケンス形成構成部とを備える。本システムは、コードキャッシュ割振り及びメタデータ作成のために変換レイヤ内に含まれ、ランタイムネイティブ命令アセンブリ構成部及びランタイムネイティブ命令シーケンス形成構成部から入力を受け取るように結合された、動的シーケンスブロックベースの命令マッピング構成部を更に備え、動的シーケンスブロックベースの命令マッピング構成部は、ランタイムネイティブ命令アセンブリ構成部及びランタイムネイティブ命令シーケンス形成構成部から結果として得られる処理された命令を受け取り、この結果として得られる処理された命令を実行のためにプロセッサに割り振る。
[007]実施形態は要約であり、このため、必然的に、詳細の単純化、一般化及び省略を含む。結果として、当業者は、要約が単なる例示であり、いかなる形においても限定を意図していないことを理解するであろう。特許請求の範囲によってのみ定義されるような本発明の他の態様、発明的特徴及び利点は、以下に示される非限定的な詳細な説明において明らかとなるであろう。
[008]本発明は、添付の図面の図において限定ではなく例として説明されており、同様の参照符号は類似した要素を指す。
本発明の1つの実施形態による、アーキテクチャアグノスティックランタイムシステムの概略図を示す。
本発明の1つの実施形態による、ハードウェアアクセラレーションされた(hardware accelerated)変換/JITレイヤを描く図を示す。
本発明の1つの実施形態による、ハードウェアアクセラレーションされたランタイム変換/JITレイヤのより詳細な図を示す。
本発明の1つの実施形態によるシステムエミュレーション及びシステム変換を実装する構成部を描く図を示す。
本発明の1つの実施形態によるゲストフラグアーキテクチャエミュレーションを描く図を示す。
本発明の1つの実施形態による統合されたレジスタファイルの図を示す。
本発明の1つの実施形態による、投機的(speculative、スペキュラティブ)アーキテクチャ状態及び過渡的(transient、トランジェント)アーキテクチャ状態をサポートする統合されたシャドーレジスタファイル及びパイプラインアーキテクチャの図を示す。
本発明の1つの実施形態による、ランアヘッドバッチ(run ahead batch)/変換プロセスを描く図を示す。
本発明の1つの実施形態による、ゲスト命令ブロック及びそれらの対応するネイティブ変換ブロックがキャッシュ内に記憶される方式を示す、例示的なハードウェアアクセラレーションされた変換システムの図を示す。
本発明の1つの実施形態による、ハードウェアアクセラレーションされた変換システムのより詳細な例を示す。
本発明の1つの実施形態による、二重スコープの使用を含む第2の使用モデルの図を示す。
本発明の1つの実施形態による、トランジェントコンテキスト(transient context)から戻るときに以前のコンテキストを保存及び復元する必要のないトランジェントコンテキスト切り替えを含む、第3の使用モデルの図を示す。
本発明の1つの実施形態による、命令シーケンスにおける例外が、後続のコードの変換が必要とされることに起因する事例を描く図である。
本発明の1つの実施形態による、トランジェントコンテキストから戻るときに以前のコンテキストを保存及び復元する必要のないトランジェントコンテキスト切り替えを含む、第4の使用モデルの図を示す。
本発明の1つの実施形態による、分岐の前の最適化されたスケジューリング命令を例示する図を示す。
本発明の1つの実施形態による、ストアの前のロードの最適化されたスケジューリングを例示する図を示す。
本発明の1つの実施形態による、ストアフィルタリングアルゴリズムの図を示す。
本発明の1つの実施形態による、インオーダでのメモリからのロードの読出しを構成するメモリ一貫性モデルにおける、アウトオブオーダのロードを用いたセマフォ(semaphore)の実施を示す。
本発明の1つの実施形態による、JIT最適化を通じた順序変更プロセス(reordering process、リオーダリングプロセス)の図を示す。
本発明の1つの実施形態による、JIT最適化を通じたリオーダリングプロセスの図を示す。
本発明の1つの実施形態による、JIT最適化を通じたリオーダリングプロセスの図を示す。
本発明の1つの実施形態による、JIT最適化を通じてストアの前に順序変更(reorder、リオーダ)されるロードを例示する図を示す。
本発明の1つの実施形態による、ロード及びストア命令分割の第1の図を示す。
本発明の1つの実施形態による、メモリ内に記憶されたネイティブ命令マッピングに対するコードキャッシュ及びゲスト命令と併せてCLBがどのように機能するかを示す例示的な流れ図を示す。
本発明の1つの実施形態による、ランアヘッドランタイムゲスト命令の変換/デコード(conversion/decoding)プロセスの図を示す。
本発明の1つの実施形態による、ゲスト命令シーケンスを有する変換テーブルと、ネイティブ命令マッピングを有するネイティブマッピングテーブルとを描く図を示す。
発明の詳細な説明
[001]本発明は、1つの実施形態に関連して説明されたが、本発明は、本明細書において示される特定の形態に限定されることを意図するものではない。対照的に、添付の特許請求の範囲によって規定される本発明の範囲内に妥当に含めることができるような代替形態、変更形態及び等価物を包含することが意図される。
[002]以下の詳細な説明において、特定の方法の順序、構造、要素及び接続等の多数の特定の詳細が示された。一方、これらの特定の詳細及び他の特定の詳細は、本発明の実施形態を実施するように利用される必要がないことが理解される。他の状況では、この説明を不要に曖昧にすることを回避するために、既知の構造、要素又は接続は、省略されているか又は詳細に説明されていない。
[003]本明細書において「1つの実施形態」又は「一実施形態」に言及する場合、それは、その実施形態に関連して記載された特定の特徴、構造又は特性が、本発明の少なくとも1つの実施態様に含まれることを示すように意図される。本明細書の様々な場所における「1つの実施形態」という語句の出現は、必ずしも全てが同じ実施形態を指すとは限らず、他の実施形態に対し相互に排他的な別個の実施形態又は代替的な実施形態でもない。更に、様々な特徴が説明されるが、それらは、いくつかの実施形態に示され、他の実施形態には示されない場合がある。同様に、いくつかの実施形態の要件であるが他の実施形態の要件ではない場合がある様々な要件が説明される。
[004]以下に続く詳細な説明のいくつかの部分は、コンピュータメモリ内のデータビットに対する動作の、プロシージャ、ステップ、論理ブロック、処理及び他の記号表現に関して記述される。これらの記述及び表現は、データ処理技術分野における当業者の研究内容をその他の当業者に最も効率的に伝達するためにそれらの当業者によって使用される手段である。プロシージャ、コンピュータ実行ステップ、論理ブロック、プロセス等は、ここでは、一般的に、所望の結果を得るためのステップ又は命令の自己矛盾のないシーケンスであると考えられる。ステップとは、物理量を物理的に操作することを必要とするもののことである。必ずしもそうではないが、通例、これらの量は、コンピュータシステムにおいて記憶され、転送され、組み合わせられ、比較され、他の形で操作されることが可能なコンピュータ可読ストレージ媒体の電気信号又は磁気信号の形態をとる。一般的に使用されるという主たる理由から、これらの信号を、ビット、値、要素、シンボル、文字、項、数値等と呼ぶことが場合によっては都合がよいことが知られている。
[005]しかしながら、これらの及び類似する用語の全ては、適切な物理量に関連付けられかつそれらの量に付された単なる都合のよいラベルであることを念頭におくべきである。以下の論考から明らかなように、特に明記しない限り、本発明の全体を通して、「処理する」又は「アクセスする」又は「書き込む」又は「記憶する」又は「複製する」等の用語を用いた論考は、コンピュータシステムのレジスタ及びメモリ並びに他のコンピュータ可読媒体内において物理的な(電子的な)量として表現されたデータを操作してコンピュータシステムのメモリ若しくはレジスタ又は他のそのような情報記憶装置、情報伝送装置又は情報表示装置内において物理量として同様に表現される他のデータに変換するコンピュータシステム又はそれに類似する電子的コンピューティング装置のアクション及び処理を指すことがわかる。
[006]本発明の実施形態は、汎用アグノスティックランタイムシステムの実施を対象とする。本明細書において用いられるとき、本発明の実施形態は、「VISC ISAアグノスティックランタイムアーキテクチャ」とも呼ばれる。以下の詳細な説明の図1〜図30は、汎用アグノスティックランタイムシステムを実施するのに用いられるメカニズムプロセス及びシステムを示す。
[007]本発明の実施形態は、ソフトウェア産業における傾向、すなわち、新たなシステムソフトウェアが、ランタイムコンパイル、最適化及び実行をますます目指す傾向を利用することを対象とする。より従来的な古いソフトウェアシステムは、静的コンパイルに適している。
[008]本発明の実施形態は、有利には、ランタイム操作に向かう傾向を有する新たなシステムソフトウェアを対象とする。例えば、初期に普及していたのはJava仮想マシンランタイム実装である。しかし、これらの実装には、ネイティブ実行よりも4倍〜5倍低速であるという不利な点がある。最近では、実装は、Java仮想マシンの実装に加えて、ネイティブコードのカプセル化(例えば、2倍〜3倍低速)を対象としている。更に最近では、実装はChrome及び低レベルの仮想マシンランタイム実装(例えば、ネイティブの2倍低速)を対象としている。
[009]本発明の実施形態は、拡張ランタイムサポートを有し、用いるアーキテクチャを実装する。本発明の実施形態は、ゲストコード(例えば、ランタイムゲストコードを含む)を効率的に実行する機能を有する。本発明の実施形態は、ゲスト/ランタイム命令をネイティブ命令に効率的に変換することができる。本発明の実施形態は、変換されたゲスト/ランタイムコードをネイティブコードに効率的にマッピングすることができるようになる。更に、本発明の実施形態は、ゲストコード又はネイティブコードをランタイムにおいて効率的に最適化することができるようになる。
[010]これらの能力は、本発明の実施形態が、アーキテクチャアグノスティックランタイムシステムの時代に十分適したものとなることを可能にする。本発明の実施形態は、レガシーアプリケーションコードを実行する能力を有して完全にポータブルとなり、そのようなコードは、他のアーキテクチャにおけるよりも2倍以上高速に実行されるように最適化することができる。
[011]図1は、本発明の1つの実施形態によるアーキテクチャアグノスティックのランタイムシステムの概略図を示す。図1は、仮想マシンランタイムJIT(例えば、実行時コンパイラ)を示す。仮想マシンランタイムJITは、示されるようなJavaのようなバイトコード、低レベルの内部表現コード及び仮想マシンJITを含む。仮想マシンJITは、低レベルの内部表現コード及びJavaのようなバイトコードの双方を処理する。仮想マシンJITの出力は、示すようなISA固有のコードである。
[012]Javaコードは、マシンと独立している。プログラマは1つのプログラムを書くことができ、このプログラムは多くの異なるマシン上で実行されるべきである。Java仮想マシンは、ISA固有であり、各マシンアーキテクチャは、独自のマシン固有の仮想マシンを有する。仮想マシンの出力は、ランタイムにおいて動的に生成されるISA固有のコードである。
[013]図1は、プロセッサに密に結合されたハードウェアアクセラレーションされた変換/JITレイヤも示す。ランタイムJIT/変換レイヤは、プロセッサが、仮想マシンJITによって処理される必要がない処理されたjavaバイトコードを用いることを可能にし、以て、コード性能を大幅に加速する。ランタイムJIT/変換レイヤは、プロセッサが、仮想マシン/JITによって処理される必要がないjavaバイトコード(例えば、仮想マシンランタイムJIT内に示される)の低レベルの内部表現を用いることも可能にする。
[014]図1は、静的バイナリ実行コードを生成するオフラインコンパイラ(例えば、x86、ARM等)によって処理されるC++コード(例えば、その類似物)も示す。C++は、マシンと独立したプログラミング言語である。コンパイラは、マシン固有である(例えば、x86、ARM等)。プログラムは、マシン固有コンパイラを用いてオフラインでコンパイルされ、以て、マシン固有の静的バイナリコードが生成される。
[015]図1は、ISA固有のコードが従来のプロセッサにおいて従来のオペレーティングシステムによってどのように実行されるかを示す一方で、(例えば、低レベルの内部表現からの)ポータブルコード、(例えば、仮想マシンランタイムJITからの)前処理されたJavaのようなバイトコード、及び(例えば、コンパイラからの)静的バイナリ実行可能コードの双方を、全て、ハードウェアアクセラレーションされた変換/JITレイヤ及びプロセッサを介して処理することができるかを有利に示す。
[016]ハードウェアアクセラレーションされた変換/JITレイヤは、本発明の実施形態の利点を達成するための主要なメカニズムであることが留意されるべきである。以下の図は、ハードウェアアクセラレーションされた変換/JITレイヤの動作方式を示す。
[017]図2は、本発明1つの実施形態による、ハードウェアアクセラレーションされた変換/JITレイヤを描く図を示す。図2は、仮想マシン/高レベルランタイム/ロードタイムJITが、仮想マシン高レベル命令表現、低レベル仮想マシン命令表現、及びゲストコードアプリケーション命令をどのように生成するかを示す。これらの全てが、ランタイム/ロードタイムのゲスト/仮想マシン命令表現対ネイティブ命令表現のマッピングのためのプロセスに供給される。そしてこれは、示されるハードウェアアクセラレーションされた変換/JITレイヤに渡され、このレイヤにおいて、ランタイムネイティブ命令表現対命令アセンブリ構成部によって処理され、次にコードキャッシュ割振り及びメタデータ作成のためのハードウェア/ソフトウェアによる動的シーケンスに基づくブロック構築/マッピング構成部に渡される。図2において、ハードウェアアクセラレーションされた変換/JITレイヤは、動的に変換されたシーケンスを記憶するためのシーケンスキャッシュを有するプロセッサに結合されて示される。また、図2は、ネイティブコードがランタイムネイティブ命令シーケンス形成構成部によってどのように直接処理することができるかも示す。ランタイムネイティブ命令シーケンス形成構成部は、結果として得られた出力を、コードキャッシュ割振り及びメタデータ作成のためのハードウェア/ソフトウェアによる動的シーケンスに基づくブロック構築/マッピング構成部に送る。
[018]図3は、本発明の1つの実施形態によるハードウェアアクセラレーションされたランタイム変換/JITレイヤのより詳細な図である。図3は、ハードウェアアクセラレーションされたランタイム変換/JITレイヤが、システムエミュレーション及びシステム変換を容易にするハードウェア構成部をどのように含むかを示す。分散化したフラグサポート、CLB/CLBV等のこれらの構成要素部は、システムエミュレーション及びシステム変換の双方をサポートして機能するカスタマイズされたハードウェアを含む。これらは、ランタイムソフトウェアを、従来のプロセッサの5倍以上の速度で実行させる。システムエミュレーション及びシステム変換が以下で論考される。
[019]図4は、本発明の1つの実施形態によるシステムエミュレーション及びシステム変換を実施するための構成部を描く図を示す。図4はまた、アプリケーションコード及びOS/システム固有のコードの双方を有するイメージも示す。
[020]本発明の実施形態は、アプリケーションコード及びOS/システム固有のコードを実行するためにシステムエミュレーション及びシステム変換を用いる。システムエミュレーションを用いて、マシンは、ハードウェアがサポートするアーキテクチャと異なるゲストシステムアーキテクチャ(システム及びアプリケーションコードの双方を含む)をエミュレート/仮想化している。エミュレーションは、(例えば、システムコードを扱う)システムエミュレーション/仮想化変換器、及び(例えば、アプリケーションコードを扱う)アプリケーションコード変換器によって提供される。アプリケーションコード変換器は、ベアメタル構成部と共に描かれて示されていることに留意されたい。
[021]システム変換を用いて、マシンは、ゲストアーキテクチャと、ハードウェアがサポートするアーキテクチャとの間の類似したシステムアーキテクチャ特性を有するが、アーキテクチャの非システム部分が異なるコード(すなわち、アプリケーション命令)を変換している。システム変換器は、ゲストアプリケーション変換器構成部及びベアメタル構成部を含んで示されている。システム変換器は、マルチパス最適化プロセスを潜在的に実装するものとしても示されている。システム変換及びエミュレーションという用語に言及することによって、本明細書における後続の説明は、図4に示すようなシステムエミュレーションパス又はシステム変換パスのいずれかを用いることができるプロセスを指していることに留意するべきである。
[022]以下の図5〜図26は、汎用アグノスティックランタイムシステム/VISC ISAアグノスティックランタイムアーキテクチャをサポートするためのシステムエミュレーション及びシステム変換の双方を実施するのに用いられる様々なプロセス及びシステムを示す。以下の図におけるプロセス及びシステムでは、ハードウェア/ソフトウェアアクセラレーションがランタイムコードに提供され、そしてこのランタイムコードはアーキテクチャの増大した性能を提供する。そのようなハードウェアアクセラレーションは、分散したフラグ、CLB、CLBV、ハードウェアゲスト変換テーブル等のためのサポートを含む。
[023]図5は、本発明の1つの実施形態によるゲストフラグアーキテクチャエミュレーションを描く図を示す。図5の左側は、5つのフラグを有する集中型のフラグレジスタを示す。図5の右側は、レジスタ自体の間でフラグが分散した、分散型のフラグレジスタを有する分散型のフラグアーキテクチャを示す。
[024]アーキテクチャエミュレーション(例えば、システムエミュレーション又は変換)中、分散型フラグアーキテクチャが、集中型のゲストフラグアーキテクチャの挙動をエミュレートすることが必要である。分散型のフラグアーキテクチャは、データレジスタに関連付けられたフラグフィールドと対照的に複数の独立したフラグレジスタを用いることによって実施することもできる。例えば、データレジスタは、R0〜R15として実施することができるのに対し、独立フラグレジスタは、F0〜F15として実施することができる。これらのフラグレジスタは、この場合、必ずしもデータレジスタと直接関連付けられない。
[025]図6は、本発明の1つの実施形態による、統合されたレジスタファイル1201の図を示す。図5に示されるように、統合されたレジスタファイル1201は、2つの部分1202〜1203及びエントリセレクタ1205を含む。統合されたレジスタフェイス1201は、ハードウェア状態アップデートのためのアーキテクチャスペキュレーションのためのサポートを実施する。
[026]統合されたレジスタファイル1201は、最適化されたシャドーレジスタ及びコミットされたレジスタ状態管理プロセスの実装を可能にする。このプロセスは、ハードウェア状態更新のためのアーキテクチャ投機をサポートする。このプロセスの下で、本発明の実施形態は、レジスタメモリ間のクロスコピーを必要とすることなく、シャドーレジスタ機能及びコミットされたレジスタ機能をサポートすることができる。例えば、1つの実施形態では、統合されたレジスタファイル1201の機能は、大部分がエントリセレクタ1205によって提供される。図5の実施形態では、各レジスタファイルエントリは、2対のレジスタR及びR’から構成され、それらはそれぞれ、部分1及び部分2からのものである。任意の所与の時点において、各エントリから読み出されるレジスタは、部分1又は部分2からのR又はR’のいずれかである。エントリセレクタ1205によって各エントリについて記憶されるx及びyビットの値に基づいてレジスタファイルの各エントリの4つの異なる組み合わせが存在する。
[027]図7は、本発明の1つの実施形態による、投機的アーキテクチャ状態及びトランジェントアーキテクチャ状態をサポートする統合されたシャドーレジスタファイル及びパイプラインアーキテクチャ1300の図を示す。
[028]図7の実施形態は、アーキテクチャ投機状態を含む命令及び結果をサポートし、トランジェント状態を含む命令及び結果をサポートするアーキテクチャ1300を含む構成部を描いている。本明細書において用いられるとき、コミットされるアーキテクチャ状態は、コンピュータ上で実行されるプログラムによってアクセス(例えば、読出し及び書込み)することができる可視レジスタ及び可視メモリを含む。対照的に、投機的アーキテクチャの状態は、コミットされないレジスタ及び/又はメモリを含み、したがって、全体的に可視でない。
[029]1つの実施形態では、アーキテクチャ1300によって有効にされる4つの使用モデルが存在する。第1の使用モデルは、ハードウェア状態アップデートのためのアーキテクチャ投資を含む。
[030]第2の使用モデルは、二重スコープの使用を含む。この使用モデルは、プロセッサ内への2つのスレッドのフェッチに適用される。ここで、一方のスレッドは、投機的状態において実行し、他方のスレッドは、非投機的状態において実行する。この使用モデルでは、双方のスコープがマシン内にフェッチされ、同時にマシン内に存在する。
[031]第3の使用モデルは、1つの形態から別の形態への命令のJIT(実行時)変換又はコンパイルを含む。この使用モデルでは、アーキテクチャ状態のリオーダは、ソフトウェア、例えば、JITにより達成される。第3の使用モデルは、例えば、ゲスト対ネイティブ命令変換、仮想マシン対ネイティブ命令変換、又はネイティブマイクロ命令の、より最適化されたネイティブマイクロ命令への再マッピング/変換に適用することができる。
[032]第4の使用モデルは、トランジェントコンテキストから返されるときに以前のコンテキストを保存及び復元する必要のない、トランジェントコンテキスト切り替えを含む。この使用モデルは、複数の理由で生じる場合があるコンテキスト切り替えに適用される。1つのそのような理由は、例えば、例外処理コンテキストによる例外の正確な処理であり得る。
[033]再び図7を参照すると、アーキテクチャ1300は、上記で説明した4つの使用モデルを実施するための複数の構成部を含む。統合されたシャドーレジスタファイル1301は、第1の部分である、コミットされたレジスタファイル1302と、第2の部分である、シャドーレジスタファイル1303と、第3の部分である、最新のインジケータアレイ1304とを含む。投機的リタイアメントメモリバッファ1342及び最新のインジケータアレイ1340が含まれる。アーキテクチャ1300は、アウトオブオーダアーキテクチャを含み、このため、アーキテクチャ1300は、リオーダバッファ及びリタイアメントウィンドウ1332を更に含む。リオーダ及びリタイアメントウィンドウ1332は、マシンリタイアメントポインタ1331、レディビットアレイ1334、及びインジケータ1333等の命令ごとの最新インジケータを更に含む。
[034]本明細書の1つの実施形態による、第1の使用モデル、すなわち、ハードウェア状態アップデートのためのアーキテクチャ投機が詳細に更に説明される。上記で説明したように、アーキテクチャ1300は、アウトオブオーダアーキテクチャを含む。アーキテクチャ1300のハードウェアは、アウトオブオーダ命令結果(例えば、アウトオブオーダロード及びアウトオブオーダストア及びアウトオブオーダレジスタアップデート)をコミットすることができる。アーキテクチャ1300は、統合されたシャドーレジスタファイルを利用して、コミットされたレジスタとシャドーレジスタとの間の投機的実行をサポートする。更に、アーキテクチャ1300は、投機的ロードストアバッファ1320及び投機的リタイアメントメモリバッファ1342を利用して、投機的実行をサポートする。
[035]アーキテクチャ1300は、これらの構成部を、リオーダバッファ及びリタイアメントウィンドウ1332と併せて使用して、マシンが統合されたシャドーレジスタファイル及びリタイアメントメモリバッファの内部にアウトオブオーダ方式でこれらをリタイアした場合であっても、その状態が、コミットされたレジスタファイル1302及び可視メモリ1350に正しくリタイアすることを可能にする。例えば、アーキテクチャは、統合されたシャドーレジスタファイル1301及び投機的メモリ1342を用いてロールバックを実施し、例外が生じるか又は生じないかに基づいてイベントをコミットする。この機能は、レジスタ状態が、統合されたシャドーレジスタファイル1301にアウトオブオーダでリタイアすることを可能にし、投機的リタイアメントメモリバッファ1342が可視メモリ1350にアウトオブオーダでリタイアすることを可能にする。投機的実行が進行し、アウトオブオーダ命令実行が進行するとき、分岐が予測ミスされず、かつ例外が生じない場合、マシンリタイアメントポインタ1331は、コミットイベントがトリガされるまで進む。コミットイベントは、統合されたシャドーレジスタファイルに、そのコミットポイントを進めることによってそのコンテンツをコミットさせ、マシンリタイアメントポインタ1331に従って、投機的リタイアメントメモリバッファに、そのコンテンツをメモリ1350に対しコミットさせる。
[036]例えば、リオーダバッファ及びリタイアメントウィンドウ1332内に示される命令1〜7を検討すると、レディビットアレイ1334は、実行の準備ができている命令の隣に「X」を示し、実行の準備ができていない命令の隣に「/」を示す。したがって、命令1、2、4及び6は、アウトオブオーダで進むことを許可される。その後、命令6の分岐が予測ミスされる等の例外が生じる場合、命令6の後に行う命令をロールバックすることができる。代替的に、例外が生じない場合、マシンリタイアメントポインタ1331をその都度移すことによって命令1〜7の全てをコミットすることができる。
[037]最新のインジケータアレイ1341、最新のインジケータアレイ1304及び最新のインジケータ1333は、アウトオブオーダ実行を可能にするために用いられる。例えば、命令2が命令5の前にレジスタR4をロードするにもかかわらず、命令5を行う準備ができると、命令2からのロードは無視される。最新のロードは、最新のインジケータに従って以前のロードを上書きする。
[038]リオーダバッファ及びリタイアメントウィンドウ1332内で分岐予測又は例外が生じる場合、ロールバックイベントがトリガされる。上記で説明したように、ロールバックの場合、統合されたシャドーレジスタファイル1301は、最新のコミットされたポイントまでロールバックし、投機的リタイアメントメモリバッファ1342がフラッシュされることになる。
[039]図8は、本発明の1つの実施形態によるランアヘッドバッチ/変換プロセスを描く図を示す。この図は、ゲストコードが変換プロセスをどのように経てネイティブコードに変換されるかを示す。そして、このネイティブコードは、ネイティブコードキャッシュをポピュレート(populate)し、このネイティブコードキャッシュが、CLBをポピュレートするのに更に用いられる。図面は、ゲストコードが、以前に変換されていないアドレス(例えば、5000)にどのようにジャンプするかを示す。次に、変換プロセスは、このゲストコードを変更して、示すような(例えば、ゲスト分岐8000及び推測分岐6000を含む)対応するネイティブコードにする。推測分岐は、コードキャッシュにおけるネイティブ分岐に変換される(例えば、ネイティブ分岐g8000及びネイティブ分岐g6000)。マシンは、ネイティブ分岐のためのプログラムカウンタが、推測分岐のためのプログラムカウンタと異なることになることを認識する。これは、ネイティブコードキャッシュ(例えば、X、Y及びZ)における表記によって示される。これらの変換が完了すると、結果として得られた変換が更なる使用のためにCLBに記憶される。この機能は、ネイティブコードへのゲストコードの変換を大幅に加速する。
[040]図9は、本発明の1つの実施形態による、ゲスト命令ブロック及びそれらの対応するネイティブ変換ブロックがキャッシュ内にどのように記憶されるかを示す例示的なハードウェアアクセラレーションされた変換システム500の図を示す。図9に示すように、変換ルックアサイドバッファ506を用いて、ゲストブロックとネイティブブロックとの間のアドレスマッピングをキャッシングし、それによって、最も頻繁に遭遇するネイティブ変換ブロックが、プロセッサ508に低レイテンシの可用性でアクセスされるようにする。
[041]図9は、頻繁に遭遇するネイティブ変換ブロックが、高速低レイテンシキャッシュ、変換ルックアサイドバッファ506内でどのように維持されるかを示す。図9に示される構成部は、はるかに高レベルの性能を送達するためのハードウェアアクセラレーションされた変換処理を実施する。
[042]ゲストフェッチロジック装置部(guest fetch logic unit、ゲストフェッチロジックユニット)502は、システムメモリ501からゲスト命令をフェッチするハードウェアベースのゲスト命令フェッチユニットとして機能する。所与のアプリケーションのゲスト命令は、システムメモリ501内に存在している。プログラムの始動時に、ハードウェアベースのゲストフェッチロジックユニット502は、ゲストフェチバッファ503への推測命令のプリフェッチを開始する。ゲストフェッチバッファ507は、ゲスト命令を蓄積し、これらをアセンブル(assemble)してゲスト命令ブロックにする。ゲスト命令ブロックは、変換テーブル504を用いることによって対応するネイティブ変換ブロックに変換される。変換されたネイティブ命令は、ネイティブ変換ブロックが完了するまで、ネイティブ変換バッファ505内で蓄積される。次に、ネイティブ変換ブロックはネイティブキャッシュ507に転送され、マッピングが変換ルックアサイドバッファ506に記憶される。次に、ネイティブキャッシュ507を用いて、ネイティブ命令を実行のためにプロセッサ508に供給する。1つの実施形態において、ゲストフェッチロジックユニット502によって実施される機能は、ゲストフェッチロジック状態マシンによって生成される。
[043]このプロセスが継続すると、変換ルックアサイドバッファ506は、ネイティブブロックへのゲストブロックのアドレスマッピングで満たされる。変換ルックアサイドバッファ506は、より頻繁に遭遇するブロックマッピングがバッファ内に保持されるのに対し、ほとんど遭遇しないブロックマッピングがバッファからエビクト(evict)されることを確実にするための1つ又は複数のアルゴリズム(例えば、最も長く用いられていない等)を用いる。このようにして、ホットネイティブ変換ブロックマッピング(hot native conversion blocks mapping)が、変換ルックアサイドバッファ506内に記憶される。更に、ネイティブブロック内の十分予測された遠くのゲスト分岐は、CLBに新たなマッピングを挿入する必要がない。なぜなら、それらのターゲットブロックが単一のマッピングされたネイティブブロック内でスティッチング(stitch)され、これによって、CLB構造のための小さな容量効率を保持するためである。更に、1つの実施形態では、CLBは、終了ゲストのみをネイティブアドレスマッピングに記憶するように構造化される。この態様は、CLBの小さな容量効率も保持する。
[044]ゲストフェッチロジック502は、ゲスト命令ブロックからのアドレスが既にネイティブ変換ブロックに変換されているか否かを判断するために、変換ルックアサイドバッファ506を調べる。上記で説明したように、本発明の実施形態は、変換処理のためのハードウェアアクセラレーションを提供する。このため、ゲストフェッチロジック502は、新たな変換のためにシステムメモリ501からのゲストアドレスをフェッチする前に、既存のネイティブ変換ブロックマッピングのための変換ルックアサイドバッファ506を調べる。
[045]1つの実施形態では、変換ルックアサイドバッファは、ゲストアドレス範囲によって、又は個々のゲストアドレスによってインデックス付けされる。ゲストアドレス範囲は、ネイティブ変換ブロックに変換されたゲスト命令ブロックのアドレス範囲である。変換ルックアサイドバッファによって記憶されるネイティブ変換ブロックマッピングは、対応するゲスト命令ブロックの対応するゲストアドレス範囲を介してインデックス付けされる。このため、ゲストフェッチロジックは、ゲストアドレスを、ゲストアドレス範囲又は変換されたブロックの個々のゲストアドレスと比較することができ、そのマッピングは変換ルックアサイドバッファ506に保持され、既存のネイティブ変換ブロックが、ネイティブキャッシュ507又は図6のコードキャッシュに記憶されるものの中に存在しているか否かが判断される。既存のネイティブ変換ブロックがネイティブキャッシュ又はコードキャッシュ内にある場合、対応するネイティブ変換命令は、これらのキャッシュからプロセッサに直接転送される。
[046]このようにして、ホットゲスト命令ブロック(例えば、頻繁に実行されるゲスト命令ブロック)は、高速低レイテンシ変換ルックアサイドバッファ506内に維持される対応するホットネイティブ変換ブロックマッピングを有する。ブロックに達すると、適切な交換ポリシが、ホットブロックマッピングが変換ルックアサイドバッファ内に留まることを確実にする。このため、ゲストフェッチロジック502は、要求されたゲストアドレスが以前に変換されたか否かを迅速に特定することができ、以前に変換されたネイティブ命令を、プロセッサ508によって実行するためにネイティブキャッシュ507に直接転送することができる。これらの態様により、多数のサイクルが節約される。なぜならシステムメモリへのトリップが、40〜50以上のサイクルをとり得るためである。これらの属性(例えば、CLB、ゲスト分岐シーケンス予測、ゲスト及びネイティブ分岐バッファ、以前のもの(the prior)のネイティブキャッシング)は、本発明の実施形態のハードウェアアクセラレーション機能が、比較可能なネイティブアプリケーションのアプリケーションの80%〜100%まで、ゲストアプリケーションのアプリケーション性能を達成することを可能にする。
[047]1つの実施形態では、ゲストフェッチロジック502は、プロセッサ508からのゲスト命令要求と独立して、変換のためのゲスト命令を連続してプリフェッチする。ネイティブ変換ブロックは、より頻繁に用いられていないブロックのために、システムメモリ501における変換バッファ「コードキャッシュ」内で蓄積することができる。変換ルックアサイドバッファ506は、最も頻繁に用いられるマッピングも保持する。このため、要求されたゲストアドレスが、変換ルックアサイドバッファ内のゲストアドレスにマッピングされない場合、ゲストフェッチロジックは、システムメモリ501をチェックして、ゲストアドレスが、システムメモリ501に記憶されているネイティブ変換ブロックに対応するか否かを判断することができる。
[048]1つの実施形態では、変換ルックアサイドバッファ506は、キャッシュとして実施され、キャッシュコヒーレンシプロトコルを用いて、高レベルのキャッシュ及びシステムメモリ501に記憶されたはるかに大きな変換バッファを用いてコヒーレンシを維持する。変換ルックアサイドバッファ506内に記憶されるネイティブ命令マッピングは、より高レベルのキャッシュ及びシステムメモリ501にも書き戻される。システムメモリへの書き戻し(write back、ライトバック)は、コヒーレンシを維持する。このため、キャッシュ管理プロトコルを用いて、ホットネイティブ変換ブロックマッピングが変換ルックアサイドバッファ506に記憶され、コールドネイティブ変換マッピングブロックがシステムメモリ501に記憶されることを確実にすることができる。このため、変換バッファ506のはるかに大きな形態がシステムメモリ501に存在する。
[049]1つの実施形態において、例示的なハードウェアアクセラレーションされた変換システム500を用いて、多数の異なる仮想ストレージ方式を実施することができることに留意するべきである。例えば、ゲスト命令ブロック及びそれらの対応するネイティブ変換ブロックがどのようにキャッシュ内に記憶されるかを用いて、仮想ストレージ方式をサポートすることができる。同様に、ゲストブロックとネイティブブロックとの間のアドレスマッピングをキャッシングするのに用いられる変換ルックアサイドバッファ506を用いて、仮想ストレージ方式(例えば、仮想メモリ対物理メモリのマッピングの管理)をサポートすることができる。
[050]1つの実施形態では、図9のアーキテクチャは、入力として、複数の異なる命令アーキテクチャを受け取ることができるフレキシブルな変換プロセスを用いる仮想命令セットプロセッサ/コンピュータを実施する。そのような仮想命令セットプロセッサにおいて、プロセッサのフロントエンドは、ソフトウェア制御され得る一方で、はるかに高いレベルの性能を送達するためのハードウェアアクセラレーションされた変換処理を利用するように実施される。そのような実施態様を用いて、各々がはるかに高レベルの性能を享受するようにハードウェアアクセラレーションの利点を受けながら、様々なゲストアーキテクチャが処理及び変換され得る。例示的なゲストアーキテクチャは、Java(登録商標)又はJavaScript(登録商標)、x86、MIPS、SPARC等を含む。1つの実施形態では、「ゲストアーキテクチャ」は、(例えば、ネイティブアプリケーション/マクロオペレーションからの)ネイティブ命令とすることができ、変換プロセスは、最適化されたネイティブ命令(例えば、最適化されたネイティブ命令/マイクロオペレーション)を生成する。ソフトウェアにより制御されたフロントエンドは、プロセッサ上で実行されるアプリケーションに高い度合いの柔軟性を提供することができる。上記で説明したように、ハードウェアアクセラレーションは、ゲストアプリケーションのゲスト命令の実行について、ネイティブハードウェア速度に近い速度を達成することができる。
[051]図10は、本発明の1つの実施形態による、ハードウェアアクセラレーションされた変換システム600のより詳細な例を示す。システム600は、上記で説明したシステム500と実質的に同じようにして実施される。一方、システム600は、例示的なハードウェアアクセラレーションプロセスの機能を説明する更なる詳細を示す。
[052]システムメモリ601は、ゲストコード602、変換ルックアサイドバッファ603、オプティマイザコード604、変換器コード605、及びネイティブコードキャッシュ606を含むデータ構造を含む。システム600は、ゲスト命令及びネイティブ命令が共にインタリーブされ共有される、共有ハードウェアキャッシュ607も示す。ゲストハードウェアキャッシュ610は、共有されたハードウェアキャッシュ607から最も頻繁にタッチされるゲスト命令をキャッシングする。
[053]ゲストフェッチロジック620は、ゲストコード602からゲスト命令をプリフェッチする。ゲストフェッチロジック620は、仮想ゲストアドレスを対応する物理ゲストアドレスに変換する変換ルックアサイドバッファとして機能するTLB609とインタフェースする。TLB609は、ヒットをゲストハードウェアキャッシュ610に直接転送することができる。ゲストフェッチロジック620によってフェッチされるゲスト命令は、ゲストフェッチバッファ611に記憶される。
[054]変換テーブル612及び613は、置換フィールド及び制御フィールドを含み、ゲストフェッチバッファ611から受け取ったゲスト命令をネイティブ命令に変換するためのマルチレベル変換テーブルとして機能する。
[055]マルチプレクサ614及び615は、変換されたネイティブ命令をネイティブ変換バッファ616に転送する。ネイティブ変換バッファ616は変換されたネイティブ命令を蓄積してネイティブ変換ブロックにアセンブルする。これらのネイティブ変換ブロックは、次に、ネイティブハードウェアキャッシュ600に転送され、マッピングが変換ルックアサイドバッファ630に保持される。
[056]変換ルックアサイドバッファ630は、変換されたブロックエントリポイントアドレス631、ネイティブアドレス632、変換されたアドレス範囲633、コードキャッシュ及び変換ルックアサイドバッファ管理ビット634、及び動的分岐バイアスビット635のためのデータ構造を含む。ゲスト分岐アドレス631及びネイティブアドレス632は、いずれの対応するネイティブ変換ブロックが変換されたロック範囲633内に存在するかを示すゲストアドレス範囲を含む。キャッシュ管理プロトコル及び交換ポリシは、ホットネイティブ変換ブロックマッピングが変換ルックアサイドバッファ630内に存在するのに対し、コールドネイティブ変換ブロックマッピングがシステムメモリ601内の変換ルックアサイドバッファデータ構造603内に存在することを確実にする。
[057]システム500と同様に、システム600は、ホットブロックマッピングが高速低レイテンシ変換ルックアサイドバッファ630内に存在することを確実にしようとする。このため、1つの実施形態において、フェッチロジック640又はゲストフェッチロジック620がゲストアドレスをフェッチするように調べるとき、フェッチロジック640はまず、ゲストアドレスをチェックして、対応するネイティブ変換ブロックがコードキャッシュ606内に存在するか否かを判断する。これによって、要求されたゲストアドレスが、コードキャッシュ606内に対応するネイティブ変換ブロックを有するか否かに関して判断することが可能になる。要求されたゲストアドレスが、バッファ603若しくは608又はバッファ630内に存在してない場合、ゲストアドレス及び複数の後続のゲスト命令がゲストコード602からフェッチされ、変換プロセスが変換テーブル612及び613を介して実施される。このようにして、本発明の実施形態は、ランアヘッドゲストフェッチ及びデコード、テーブルルックアップ並びに命令フィールドアセンブリを実施することができる。
[058]図11は、本発明の1つの実施形態による、二重スコープの使用を含む第2のモデルの図1400を示す。上記で説明したように、この使用モデルは、2つのスレッドのプロセッサへのフェッチに適用され、ここで、一方のスレッドは、投機的状態において実行され、他方のスレッドは、非投機的状態で実行される。この使用モデルでは、双方のスコープがマシン内にフェッチされ、同時にマシン内に存在する。
[059]図1400に示すように、2つのスコープ/トレース1401及び1402がマシン内にフェッチされた。この例では、スコープ/トレース1401は、現在の非投機的スコープ/トレースである。スコープ/トレース1402は、新たな投機的スコープ/トレースである。アーキテクチャ1300は、2つのスレッドが実行のためにこれらの状態を使用することを可能にする投機的及びスクラッチ状態を可能にする。一方のスレッド(例えば、1401)は、非投機的スコープにおいて実行し、他方のスレッドは(例えば1402)は投機的スコープを使用する。双方のスコープがマシン内にフェッチされ、同時に存在することができ、各スコープはそれぞれのモードを異なる形で設定する。第1のスコープは非投機的であり、他方は投機的である。このため、第1のスコープは、CR/CMモードで実行し、他方は、SR/SMモードで実行する。CR/CMモードでは、コミットされたレジスタが読出し及び書込みをされ、メモリ書込みはメモリに進む。SR/SMモードでは、レジスタ書込みはSSSRに進み、レジスタ読出しは最新の書込みから到来する一方で、メモリはリタイアメントメモリバッファ(SMB)に書き込む。
[060]1つの例は、順序付けされた現在のスコープ(例えば、1401)及び投機的な次のスコープ(例えば、1402)である。次のスコープは現在のスコープの後にフェッチされるので、従属関係が守られるように、双方をマシンにおいて実行することができる。例えば、スコープ1401において、「SSSRをCRにコミットする」において、この時点までレジスタ及びメモリはCRモードにある一方、コードはCR/CMモードで実行される。スコープ1402において、コードはSR及びSMモードで実行され、例外が生じた場合、ロールバックすることができる。このようにして、双方のスコープがマシンにおいて同時に実行されるが、各々が異なるモードで実行されており、それに応じてレジスタの読み出し及び書込みを行っている。
[061]図12は、本発明の1つの実施形態による、トランジェントコンテキストから戻るときに以前のコンテキストを保存及び復元する必要のないトランジェントコンテキスト切り替えを含む、第3の使用モデルの図を示す。上記で説明されたように、この使用モデルは、複数の理由で生じ得るコンテキスト切り替えに適用される。1つのそのような理由は、例えば、例外処理コンテキストを介した例外の正確な処理であり得る。
[062]第3の使用モデルは、マシンが変換されたコードを実行しており、コンテキスト切り替え(例えば、変換されたコード内の例外、又は後続のコードのための変換が必要とされる場合)に遭遇するときに生じる。現在の範囲において(例えば、例外の前に)、SSSR及びSMBは、ゲストアーキテクチャ状態に対するそれらの投機的状態をまだコミットしていない。現在の状態は、SR/SMモードで実行されている。例外が生じるとき、マシンは、例外に正確に対処するために、例外ハンドラ(例えば、変換器)に切り替える。ロールバックが挿入され、これによって、レジスタ状態がCRにロールバックされ、SMBがフラッシュされる。変換器コードは、SR/CMモードで実行される。変換器コードの実行中、SMBは、コミットイベントを待機することなくメモリにコンテンツをリタイアしている。レジスタは、CRを更新することなくSSSRに書き込まれる。その後、変換器が終了し、変換コードの実行に戻るように切り替える前に、SSSRをロールバックする(例えば、SSSRがCRにロールバックされる)。このプロセス中、最後にコミットされたレジスタ状態はCRにある。
[063]これは、前のスコープ/トレース1501がSSSRからCRにコミットされた図1500に示されている。現在のスコープ/トレース1502は投機的である。レジスタ及びメモリ及びこのスコープは投機的であり、実行はSR/SMモード下で生じる。この例では、例外はスコープ1502において生じ、コードは、変換前に元の順序で再度実行される必要がある。この時点において、SSSRはロールバックされ、SMBがフラッシュされる。次に、JITコード1503が実行される。JITコードはSSSRをスコープ1501の末尾までロールバックし、SMBをフラッシュする。JITの実行は、SC/CMモード下で行われる。JITが終了すると、SSSRはCRにロールバックされ、次に、現在のスコープ/トレース1504が、CR/CMモードで元の変換順序において再実行される。このようにして、厳密な現在の順序において例外が正確に処理される。
[064]図13は、本発明の1つの実施形態による、命令シーケンスにおける例外が、後続のコードの変換が必要とされることに起因する事例を描く図である。図1600に示すように、前のスコープ/トレース1601は、変換されていない宛先へのfar jumpで終了する。far jumpの宛先にジャンプする前に、SSSRはCRにコミットされる。次に、JITコード1602を実行して、far jumpの宛先において、(例えば、ネイティブ命令の新たなトレースを構築するための)推測命令を変換する。JITの実行は、SR/CMモード下で行われる。JITの実行の終了時、レジスタ状態はSSSRからCRにロールバックされ、JITによって変換された新たなスコープ/トレース1603が実行を開始する。新たなスコープ/トレースは、SR/SMモードにおける前のスコープ/トレース1601の最後にコミットされた点から実行を継続する。
[065]図14は、本発明の1つの実施形態による、トランジェントコンテキストから戻るときに以前のコンテキストを保存及び復元する必要のないトランジェントコンテキスト切り替えを含む、第4の使用モデルの図を示す。上記で説明したように、この使用モデルは、複数の理由で生じ得るコンテキスト切り替えに適用される。1つのそのような理由は、例えば、例外処理コンテキストによる処理入力又は出力であり得る。
[066]図1700は、CR/CMモード下で実行される前のスコープ/トレース1701が関数F1の呼び出しで終了する事例を示す。その時点までのレジスタ状態は、SSSRからCRにコミットされる。関数F1のスコープ/トレース1702は、次に、SR/CMモード下で投機的に実行を開始する。次に、関数F1は、メインのスコープ/トレース1703に戻って終了する。この時点において、レジスタ状態はSSSRからCRにロールバックされる。メインのスコープ/トレース1703は、CR/CMモードにおける実行を再開する。
[067]図15は、本発明の1つの実施形態による、分岐の前の最適化されたスケジューリング命令を例示する図を示す。図15に示されるように、ハードウェア最適化された例が、従来の実行時コンパイラの例と並べて示される。図15の左側は、不成立にバイアスがかかった分岐不成立の「L1への分岐C」を含む、元の非最適化コードを示す。図15の中央の列は、従来の実行時コンパイラ最適化を示し、ここで、レジスタはリネームされ、命令は分岐の前に移される。この例において、実行時コンパイラは、分岐にバイアスがかかった決定が誤りである(例えば、分岐が不成立ではなく、実際に成立する)機会を考慮するように補償コードを挿入する。対照的に、図15の右列は、ハードウェアによって展開(unroll、アンロール)された最適化を示す。この場合、レジスタはリネームされ、命令は分岐の前に移される。一方、補償コードが挿入されていないことに留意するべきである。ハードウェアは、分岐にバイアスがかかった決定が真であるか否かを追跡する。予測ミスされた分岐の場合、ハードウェアは、正しい命令シーケンスを実行するために、その状態を自動的にロールバックする。ハードウェアオプティマイザによる解決方法は、補償コードの使用を回避することができる。なぜなら、分岐が予測ミスされるこれらの事例では、ハードウェアがメモリ内の元のコードにジャンプし、そこから正しいシーケンスを実行する一方で、予測ミスされた命令シーケンスをフラッシュするためである。
[068]図16は、本発明の1つの実施形態による、ストアの前のロードの最適化されたスケジューリングを例示する図を示す。図16に示すように、ハードウェア最適化された例が、従来の実行時コンパイラの例と並べて描かれている。図16の左側は、ストア「R3←LD[R5]」を含む元の非最適化コードを示す。図16の中央列は、従来の実行時コンパイラ最適化を示し、ここで、レジスタはリネームされ、ロードはストアの前に移される。この例では、実行時コンパイラは、ロード命令のアドレスがストア命令のアドレスをエイリアス(alias)する(例えば、ストアの前にロードを移すことが適切でない)機会を考慮するように補償コードを挿入する。対照的に、図16の右列は、ハードウェアによってアンロールされた最適化を示す。この場合、レジスタはリネームされ、ロードもストアの前に移される。一方、補償コードが挿入されていないことに留意するべきである。ロードをストアの前に移すことが誤っている場合、ハードウェアは、正しい命令シーケンスを実行するために、その状態を自動的にロールバックする。ハードウェアオプティマイザによる解決方法は、補償コードの使用を回避することができる。なぜなら、アドレスエイリアスチェック分岐が予測ミスされるこれらの事例では、ハードウェアがメモリ内の元のコードにジャンプし、そこから正しいシーケンスを実行する一方で、予測ミスされた命令シーケンスをフラッシュするためである。この場合、シーケンスはエイリアスなしを想定する。1つの実施形態では、図16に示す機能は、命令スケジューリング及びオプティマイザ構成部によって実装することができることに留意するべきである。同様に、1つの実施形態では、図16に示す機能は、ソフトウェアオプティマイザによって実施することができることに留意するべきである。
[069]更に、動的にアンロールされたシーケンスに関して、命令は、リネームを用いることによって、以前のパスによって予測される分岐(例えば、動的に構築された分岐)をパスすることができることに留意するべきである。非動的に予期された分岐の場合、命令の移動は、分岐の範囲を考慮するべきである。ループは、所望の範囲までアンロールすることができ、シーケンス全体にわたって最適化を適用することができる。例えば、これは分岐をまたいで移る命令の宛先レジスタをリネームすることによって実施することができる。この特徴の利点のうちの1つは、分岐の範囲の補償コードも拡張解析も必要とされないことである。このため、この特徴は最適化プロセスを大幅に加速し、簡略化する。
[070]図17は、本発明の1つの実施形態による、ストアフィルタリングアルゴリズムの図を示す。図17の実施形態の目的は、全てのストアが、ロードキュー内の全てのエントリに対しチェックしなくてはならないことを防ぐようにストアをフィルタリングすることである。
[071]ストアは、アドレスマッチについてキャッシュをスヌープしてコヒーレンシを維持する。スレッド/コアXロードは、キャッシュラインから読み出す場合、データをロードしたキャッシュラインの部分をマーキングする。別のスレッド/コアYストアがキャッシュをスヌープするとき、任意のそのようなストアがそのキャッシュライン部分に重複している場合、そのスレッド/コアXのロードについて予測ミスが生じる。
[072]これらのスヌープをフィルタリングするための1つの解決方法は、ロードキューエントリの参照先を追跡することである。この場合、ストアは、ロードキューをスヌープする必要がない。ストアがアクセスマスクとのマッチを有する場合、参照先トラッカから得られたロードキューエントリは、ロードエントリに予測ミスをさせることになる。
[073]別の解決方法(参照先トラッカがない場合)では、ストアがアクセスマスクとのマッチを有する場合、ストアアドレスがロードキューエントリをスヌープし、マッチしたロードエントリに予測ミスをさせることになる。
[074]双方の解決方法により、ロードは、キャッシュラインから読み出しているとき、それぞれのアクセスマスクビットを設定する。そのロードは、リタイアするとき、そのビットをリセットする。
[075]図18は、本発明の1つの実施形態による、インオーダでのメモリからのロードの読出しを構成するメモリ一貫性(memory consistency、メモリコンシステンシ)モデルにおける、アウトオブオーダロードを有するセマフォの実施を示す。本明細書において用いられるとき、セマフォという用語は、共通のリソースに対し、複数のスレッド/コアのためのアクセス制御を提供するデータ構造を指す。
[076]図18の実施形態では、アクセスマスクは、複数のスレッド/コアによるメモリリソースへのアクセスを制御するのに用いられる。アクセスマスクは、キャッシュラインのいずれのワードが未解決のロードを有するかを追跡することによって機能する。アウトオブオーダロードは、キャッシュラインのワードにアクセスするときにマスクビットを設定し、ロードがリタイアするときにマスクビットをクリアする。マスクビットが設定されている間に、別のスレッド/コアからのストアがそのワードに書き込む場合、アクセスマスクは(例えば、トラッカを介して)そのロードに対応するロードキューエントリを、予測ミスとなる/フラッシュされるか、又はその従属命令を用いてリタイアされるようにシグナリングする。アクセスマスクは、スレッド/コアも追跡する。
[077]このようにして、アクセスマスクは、メモリコンシステンシ規則が正しく実施されることを確実にする。メモリコンシステンシ規則は、ストアがメモリをインオーダでアップデートすることを指示し、このセマフォが2つのコア/スレッドにわたって機能するために、メモリから読出しをインオーダでロードする。このため、コア1及びコア2によって実行されるコードは正しく実行されることになる。ここで、これらのコードは共に、メモリロケーション「フラグ」及び「データ」の双方にアクセスする。
[078]図19は、本発明の1つの実施形態による、JIT最適化を通じたリオーダリングプロセスの図を示す。図19は、メモリコンシステンシオーダリング(memory consistency ordering、例えば、ロードの前にロードを行う順序付け)を描いている。ロードは、同じアドレスに対する他のロードの前にディスパッチ(dispatch)することはできない。例えば、ロードは、同じスレッドからの後続のロードの同じアドレスについてチェックする。
[079]1つの実施形態では、全ての後続のロードが、アドレスマッチについてチェックされる。例えば、この解決方法が機能するためには、ロードCチェックは、元のロードCロケーションの点(point、ポイント)まで、リタイアメント後にキュー(又は例えばその拡張部)に留まる必要がある。ロードチェック拡張サイズは、リオーダされたロード(例えば、ロードC)が前にジャンプすることができるロードの数に対する制約を設けることによって決定することができる。この解決方法は、パーシャルストアオーダリング(partial store ordering)メモリコンシステンシモデル(例えば、ARMコンシステンシモデル)でしか機能しないことに留意するべきである。
[080]図20は、本発明の1つの実施形態による、JIT最適化を通じたリオーダリングプロセスの図を示す。ロードは、同じアドレスに対する他のロードの前にディスパッチすることができない。例えば、ロードは、同じスレッドからの後続のロードの同じアドレスについてチェックする。図20は、他のスレッドストアがロードキュー全体に対してどのようにチェックを行い、拡張を監視するかを示す。モニタは、元のロードによって設定され、元のロード位置に続いて、後続の命令によってクリアされる。この解決方法は、トータルストアオーダリング(total store ordering)メモリコンシステンシモデル及びパーシャルストアオーダリングメモリコンシステンシモデルの双方(例えば、x86及びARMコンシステンシモデル)で機能することに留意するべきである。
[081]図21は、本発明の1つの実施形態による、JIT最適化を通じたリオーダリングプロセスの図を示す。ロードは、同じアドレスに対する他のロードの前にディスパッチすることができない。本発明の1つの実施形態は、ロードリタイアメント拡張を実施する。この実施形態では、他のスレッドストアは、ロード/ストアキュー全体(及び例えば拡張)に対しチェックする。
[082]この解決方法を実施する際、リタイアする全てのロードは、元のロードCロケーションのポイントまでリタイアした後にロードキュー(又は例えばその拡張)内に留まる必要がある。他のスレッドからのストアが到来するとき(スレッド0)、このストアは、ロードキュー全体(例えば、拡張を含む)にCAMマッチする。拡張サイズは、リオーダされたロード(ロードC)が(例えば、8エントリ拡張を用いることによって)前にジャンプすることができるロード数に制限を設けることによって決定することができる。この解決方法は、トータルストアオーダリングメモリコンシステンシモデル及びパーシャルストアオーダリングメモリコンシステンシモデルの双方(例えば、x86及びARMコンシステンシモデル)で機能することに留意するべきである。
[083]図22は、本発明の1つの実施形態による、JIT最適化を通じてストアの前にリオーダされるロードを例示する図を示す。図22は、同じスレッド内の、ストアからロードへの転送オーダリング(例えば、ストアからロードへのデータ依存性)を利用する。
[084]同じスレッド内のストアの同じアドレスに対するロードは、そのストアの前にJITを通じてリオーダすることができない。1つの実施形態では、リタイアする全てのロードは、元のロードCロケーションのポイントまで、リタイアメント(retirement)後にキュー(及び/又は例えばその拡張)に留まる必要がある。各リオーダされたロードは、後続のストアに関係したマシン順序(例えば、IP)内のそのロードの初期位置を示すオフセットを含む。
[085]1つの例示的な実施態様は、オフセットインジケータに初期命令位置を含めることである。同じスレッドからストアが到来するとき、このストアは、マッチを探しているロードキュー全体(拡張を含む)にCAMマッチし、これは、このストアが、マッチしたロードに転送されることを示す。ストアがロードCの前にディスパッチされた場合、そのストアはストアキュー内のエントリを予約し、ロードが後にディスパッチされるときに、ロードはストアのアドレスに対しCAMマッチし、自身のIPを用いてマシン順序を決定し、ストアのうちの任意のものからそのロードへのデータ転送を完結する。拡張サイズは、リオーダされたロード(ロードC)が(例えば、8エントリの拡張を用いることによって)前にジャンプすることができるロード数に対する制約を設けることによって決定することができる。
[086]別の解決方法は、元のロードの場所にチェックストア命令を配置することである。チェックストア命令は、ディスパッチするとき、アドレスマッチについてロードキューに対しチェックを行う。同様に、ロードは、ディスパッチするとき、チェックストア命令によって占有されるストアキューエントリに対し、アドレスマッチについてチェックする。
[087]図23は、本発明の1つの実施形態による、ロード及びストア命令分割の第1の図を示す。本発明の1つの特徴は、ロードが2つのマクロ命令に分割されることであり、第1の命令は一時的ロケーション(ロードストアキュー)へのアドレス計算及びフェッチを行い、第2の命令はレジスタ又はALU宛先へのメモリアドレスコンテンツ(データ)のロードである。本発明の実施形態は、ロード及びストア命令を、2つのそれぞれのマイクロ命令に分割し、それらをリオーダすることに関連して説明されているが、同じ方法及びシステムを、ロード及びストア命令を2つのそれぞれのマイクロ命令に分割し、これらをマイクロコードコンテキスト内でリオーダすることによって実施することができることに留意するべきである。
[088]機能は、ストアについて同じである。ストアも、2つのマクロ命令に分割される。第1の命令はストアアドレス及びフェッチであり、第2の命令はそのアドレスにおけるデータのストアである。ストアの分割及び2つの命令は、ロードについて後述するのと同じ規則に従う。
[089]2つの命令へのロードの分割によって、ランタイムオプティマイザが、所与の命令シーケンス内ではるかに早く、アドレス計算をスケジューリングして、命令をフェッチすることが可能になる。これによって、キャッシュ階層と別個の一時バッファにデータをプリフェッチすることによって、メモリミスからのより容易な回復が可能になる。一時的なバッファは、LA/SAとLD/SDとの間の1対1の対応でプリフェッチデータの利用可能性を保証するために用いられる。対応するロードデータ命令は、ロードアドレスとロードデータとの間のウィンドウ内にある以前のストアとのエイリアシングが存在する場合(例えば、転送事例が前のストアから検出された場合)、又はアドレス計算に何らかの障害問題(例えば、ページ障害)が存在する場合、再発行することができる。更に、2つの命令へのロードの分割は、情報を2つの命令に複製することも含むことができる。そのような情報は、アドレス情報、ソース情報、他の追加の識別子等に対処することができる。この複製によって、LA/SAがない場合に2つの命令のLD/SDの独立したディスパッチが可能になる。
[090]ロードアドレス及びフェッチ命令は、ロードデータが戻るのを待つことなく、実際のマシンリタイアメントウィンドウからリタイアし、以て、そのアドレス(例えば、段落の最初に参照されるロードアドレス)に対するキャッシュミスの場合であってもマシンが転送を進めることを可能にすることができる。例えば、そのアドレス(例えば、アドレスX)に対するキャッシュミスの場合に、マシンは、場合によっては、メモリ階層からデータがフェッチされるのを待って、数百サイクルにわたって停止することができる。ロードデータが戻るのを待つことなく実際のマシンリタイアメントウィンドウからロードアドレス及びフェッチ命令をリタイアすることによって、マシンは依然として転送を進めることができる。
[091]命令の分割によって、LA/SA命令を早期に、かつLD/SD命令シーケンスから離れるようにリオーダして、ロード及びストアのより早期のディスパッチ及び実行を可能にする、本発明の実施形態の主要な利点が可能になることに留意するべきである。
[092]図24は、本発明の1つの実施形態による、メモリ内に記憶されたネイティブ命令マッピングに対するコードキャッシュ及びゲスト命令と併せてCLBがどのように機能するかを示す例示的な流れ図を示す。
[093]上記で説明したように、CLBを用いて、コードキャッシュメモリ(例えば、ゲスト対ネイティブアドレスマッピング)内に記憶された対応する変換されたネイティブアドレスを有するゲストアドレスのマッピングを記憶する。1つの実施形態では、CLBは、ゲストアドレスの一部分を用いてインデックス付けされる。ゲストアドレスは、インデックス、タグ及びオフセット(例えば、チャンクサイズ)に分割される。このゲストアドレスは、インデックスに対応するCLBエントリにおけるマッチを特定するのに用いられるタグを含む。タグ上にヒットが存在する場合、対応するエントリは、コードキャッシュメモリ806内のどこに対応する変換されたネイティブ命令チャンク(例えば、変換されたネイティブ命令の対応するブロック)を見つけることができるかを示すポインタを記憶する。
[094]本明細書において用いられる「チャンク」という用語は、変換されたネイティブ命令ブロックの対応するメモリサイズを指すことに留意するべきである。例えば、チャンクは、変換されたネイティブ命令ブロックの異なるサイズに依拠して、サイズが異なることができる。
[095]1つの実施形態では、コードキャッシュメモリ806に関して、コードキャッシュは、1組の固定サイズのチャンクに(例えば、チャンクタイプごとに異なるサイズを用いて)割り当てられる。コードキャッシュは、システムメモリ及び全ての下位レベルのHWキャッシュ(例えば、ネイティブハードウェアキャッシュ608、共有ハードウェアキャッシュ607)内の組及び方法に論理的に分割することができる。CLBは、ゲストアドレスを用いて、コードキャッシュチャンクのための方法タグをインデックス付けし、タグ比較することができる。
[096]図24は、方法x及び方法yとして示される2つの方法においてゲストアドレスタグを記憶するCLBハードウェアキャッシュ804を描く。1つの実施形態において、CLB構造を用いたネイティブアドレスに対するゲストアドレスのマッピングは、構造化された方法においてネイティブコードチャンクへのポインタ(例えば、ゲストからネイティブへのアドレスマッピング)を記憶することにより行うことができることに留意するべきである。各方法はタグに関連付けられる。CLBは、ゲストアドレス802(タグを含む)を用いてインデックス付けされる。CLBにおけるヒット時に、タグに対応するポインタが返される。このポインタを用いて、コードキャッシュメモリをインデックする。これは、ライン「コードチャンクのネイティブアドレス=Seg#+F(pt)」によって図24に示されている。このラインは、コードチャンクのネイティブアドレスが、ポインタ及びセグメント番号の関数であることを表す。本実施形態において、セグメントは、ポインタスコープが仮想的にマッピングされるメモリ内のポイントのための基部を指す(例えば、物理メモリ内の任意の領域内にポインタアレイがマッピングされることを可能にする)。
[097]代替的に、1つの実施形態では、コードキャッシュメモリは、図24に示されるように、ライン「コードチャンクのネイティブアドレス=seg#+インデックス*(チャンクのサイズ)+way#*(チャンクサイズ)」によって第2の方法によりインデックス付けすることができる。そのような実施形態では、コードキャッシュは、その方法構造がCLB方法の構造化にマッチするように組織化され、それによって、CLBの方法と、コードキャッシュチャンクとの間に1:1のマッピングが存在するようにする。次に、特定のCLB方法におけるヒットが存在するとき、コードキャッシュの対応する方法における対応するコードチャンクがネイティブコードを有する。
[098]依然として図24を参照すると、CLBのインデックスがミスである場合、メモリのより高い階層をヒットについてチェックすることができる(例えば、L1キャッシュ、L2キャッシュ等)。これらのより高いレベルのキャッシュにおいてヒットが存在しない場合、システムメモリ801におけるアドレスがチェックされる。1つの実施形態において、ゲストインデックスは、例えば、64個のチャンクを含むエントリをポインティングする。64個のチャンクの各々のタグは、読み出され、ゲストタグと比較され、ヒットが存在するか否かが判断される。このプロセスは、図24において、点線のボックス805によって示される。システムメモリ内のタグとの比較後にヒットが存在しない場合、メモリのいかなる階層レベルにおいても変換が存在せず、ゲスト命令が変換されなくてはならない。
[099]本発明の実施形態は、キャッシュのような方式でゲスト対ネイティブ命令マッピングを記憶するメモリの階層レベルの各々を管理することに留意するべきである。これは、キャッシュベースのメモリ(例えば、CLBハードウェアキャッシュ、ネイティブキャッシュ、L1及びL2キャッシュ等)から固有に到来する。一方、CLBは、システムメモリ801内のゲスト対ネイティブ命令マッピングのための最も長く用いられていない(LRU)交換管理ポリシを実施するのに用いられる「コードキャッシュ+CLB管理ビット」も含む。1つの実施形態では、CLB管理ビット(例えば、LRUビット)は、ソフトウェア管理される。このようにして、メモリの全ての階層レベルを用いて、最も近時に用いられた、最も頻繁に遭遇するゲスト対ネイティブ命令マッピングを記憶する。これに応じて、最も頻繁に遭遇する変換されたネイティブ命令を同様に記憶するメモリの全ての階層レベルが導かれる。
[0100]図24は、CLB内に記憶される動的分岐バイアスビット及び/又は分岐履歴ビットも示す。これらの動的分岐ビットを用いて、ゲスト命令シーケンスをアセンブルする際に用いられる分岐予測の挙動を追跡する。これらのビットを用いて、いずれの分岐予測が最も頻繁に正確に予測されるか、及びいずれの分岐予測が最も頻繁に予測ミスされるかを追跡する。CLBは、変換されたブロック範囲のためのデータも記憶する。このデータは、プロセスが、(例えば、自己変更コードのように)対応するゲスト命令が変更されたコードキャッシュメモリ内の変換されたブロック範囲を無効にすることを可能にする。
[0101]図25は、本発明の1つの実施形態による、ランアヘッドランタイムゲスト命令の変換/デコードプロセスの図を示す。図25は、ゲストコードのオンデマンド変換/デコード中、目的は、メインメモリからゲストコードを持ってくること(例えば、これはコストのかかるトリップとなる)を回避することであることを示す図である。図25は、ゲストコードが、命令シーケンスにおけるゲスト分岐のターゲットからプリフェッチされるプリフェッチプロセスを示す。例えば、命令シーケンスは、推測分岐X、Y及びZを含む。これによって、アドレスX、Y及びZにおけるゲストコードのプリフェッチ命令の問題が生じる。
[0102]図26は、本発明の1つの実施形態による、ゲスト命令シーケンスを有する変換テーブルと、ネイティブ命令マッピングを有するネイティブマッピングテーブルとを描く図を示す。1つの実施形態では、メモリ構造/テーブルは、低レベル低レイテンシキャッシュと同様のキャッシュとして実施することができる。
[0103]1つの実施形態では、最も頻繁に遭遇するゲスト命令及びそれらのマッピングは、低レベルキャッシュ構造に記憶され、ランタイムがこれらの構造に迅速にアクセスして、ゲスト命令のための等価なネイティブ命令を取得することを可能にする。マッピングテーブルは、ルックアップされたゲスト命令フォーマットのための等価な命令フォーマットを提供することができる。いくつかの制御値を用いて、これらのマッピングテーブルに制御フィールドとして記憶し、ゲスト命令内のある特定のフィールドを、ネイティブ命令における等価なフィールドと置換することを迅速に可能にする。ここでの着想は、最も頻繁に遭遇するゲスト命令のみを低レベル(例えば、キャッシュ)に記憶して迅速な変換を可能にすることであり、一方で、他の頻繁でないゲスト命令は変換により時間がかかる可能性がある。
[0104]ここで、本発明の実施形態による用語CLB/CLBV/CLTが論考される。1つの実施形態では、A CLBは、ゲスト分岐の宛先にマッピングするコードのアドレスを取得するためのネイティブコードを実行する間、ネイティブゲスト分岐に遭遇するときにルックアップされるメモリ構造として維持される変換ルックアサイドバッファである。1つの実施形態では、CLBVは、CLBの犠牲キャッシュイメージである。エントリがCLBからエビクトされるとき、エントリは正規のL1/L2キャッシュ構造にキャッシュされる。CLBがミスに遭遇するとき、CLBは、ミスのターゲットを探索するために、ハードウェアアクセスによってL1/L2を自動的にルックアップする。1つの実施形態では、CLTはミスのターゲットがCLB又はCLBVに見つからないときに用いられ、ソフトウェアハンドラは、メインメモリ内のCLTテーブル内のエントリをルックアップするようにトリガされる。
[0105]次に、本発明の実施形態によるCLBカウンタが検討される。1つの実施形態では、CLBカウンタは、変換時に設定される値であり、変換される命令シーケンス/トレースに関係付けられたメタデータと共に記憶される。このカウンタは、命令シーケンス/トレースが実行される度にデクリメントされ、ホット性(hotness)のトリガとしての役割を果たす。この値は、全てのCLBレベル(例えば、CLB、CLBV、CLT)において記憶される。この値は、閾値に到達すると、JITコンパイラをトリガして命令シーケンス/トレースを最適化する。この値は、ハードウェアによって維持及び管理される。1つの実施形態では、命令シーケンス/トレースはCLBカウンタ及びソフトウェアカウンタのハイブリッドを有することができる。
[0106]次に、本発明の1つの実施形態によるバックグラウンドスレッドが検討される。1つの実施形態において、ホット性がトリガされると、ソフトウェアに不可視のバックグラウンドハードウェアタスクとしての役割を果たし、独自のハードウェアリソース、通例、最小限のリソース(例えば、スモールレジスタファイル及びシステム状態)を有する、ハードウェアバックグラウンドスレッドが始動される。バックグラウンドスレッドは、低い優先度で、実行リソースが利用可能であるときに実行リソースを記憶するバックグラウンドスレッドとして実行され続ける。バックグラウンドスレッドはハードウェアスレッドIDを有し、ソフトウェアに対し可視でないが、低レベルハードウェア管理システムによって管理される。
[0107]本発明の1つの実施形態による、JITプロファイリング及びランタイムモニタリング/動的チェックが検討される。JITは、時間間隔において、命令シーケンス/トレースのプロファイリング/モニタリング/スイープを開始することができる。JITは、分岐プロファイリングを用いること等によって、最適化に関連するある値を維持することができる。分岐プロファイリングは、コードインストルメンテーション(code instrumentation)を有する分岐プロファイリングハードウェア命令を用いて、分岐のセマンティックを有する命令を実施することによって、命令シーケンス/トレース内の分岐についての分岐予測値/バイアスを見つけ、それによって、特定のアドレスから命令のフェッチを開始し、これらの命令を、マシンフロントエンドを通じて渡し、これらの命令を実行することなくハードウェアブランチ予測器をルックアップする。次に、JITは、これらのハードウェア分岐予測カウンタの値を蓄積して、ハードウェアが提供するよりも大きなカウンタを作成する。これによって、JITが分岐バイアスをプロファイリングすることが可能になる。
[0108]継続的なプロファイリングは、この情報を用いてコードを変更及び最適化しない値を検出するためのプロファイリングを指す。
[0109]場合によっては、ロードとストアとの間のアドレスエイリアシングについて動的にチェックすることによって、ストア対ロード転送が生じないことをチェックすることが可能であるため、ロードストアエイリアシングのチェックが用いられる。
[0110]1つの実施形態では、JITは、コードをインストルメントするか、又は分岐プロファイリング命令等の特殊な命令を用いるか、又はロード命令をチェックするか、又はストア命令をチェックすることができる。
[0111]説明の目的で、上記の説明は、包括的であることも、本発明を限定することも意図していない特定の実施形態を参照する。上記の教示に整合する多くの変更形態及び変形形態が可能である。実施形態は、当業者が特定の使用に適することができるような様々な変更形態を有する本発明及びその様々な実施形態を最も良好に理解することを可能にするために、本発明及びその実際の用途の原理を最も良好に説明するために選択及び説明された。