JP5592015B2 - ハードウェア制限に基づく調整可能なトランザクション・サイズを利用してコードを動的に最適化する装置、方法およびシステム - Google Patents

Description

本発明は、プロセッサの分野に、特にプロセッサ上でのコード最適化および実行に関する。

半導体処理および論理設計における進歩により集積回路デバイス上に存在しうる論理の量を増すことができるようになった。以前は、単一スレッド・プロセッサ上で、バイナリー・コードのようなコードの最適化は過度に積極的であることが許容されていた。他の実行スレッドによる干渉のおそれがなかったからである。しかしながら、コンピュータ・システム構成は、システム中の単一または複数の集積回路から、個々の集積回路上に存在する複数コア、複数ハードウェア・スレッドおよび複数論理プロセッサへと進化した。プロセッサまたは集積回路は典型的には単一の物理的なプロセッサ・ダイを有する。ここで、前記プロセッサ・ダイは任意の数のコア、ハードウェア・スレッドまたは論理プロセッサを含みうる。集積回路上でのますます増え続ける処理要素――コア、ハードウェア・スレッドおよび論理プロセッサ――の数はより多くのタスクが並列して達成されることを可能にする。単一スレッド・プロセッサからより並列的な、複数スレッド実行へのこの進化の結果として、コード最適化への制限が生じている。

たとえば、擬似コードAは、バイナリー・コードの最適化を示している。[r2]および[r2+4]におけるメモリからのロードが、部分冗長性ロード消去（PRLE: Partial Redundancy Load Elimination）最適化によってループから持ち上げられてヘッダ・ブロック（B3）にくくり出される。そして、[r2+4]におけるメモリへのストアは、部分デッド・ストア消去（PDSE: Partial Dead Store Elimination）最適化によってループからテール・ブロック（B4）に押し出される。

この最適化は単一スレッド環境では機能するかもしれないが、複数スレッド・アプリケーションでは、他のスレッドがループ実行の間に[r2]または[r2+4]におけるメモリへの書き込み／該メモリからの読み出しを行うことがある。これは潜在的には、メモリ操作の実行順の変更のため、無効な実行につながる。

本発明は例として付属の図面の図によって例解されるが、該図によって限定されることは意図されていない。

原子的実行および原子的領域の動的なサイズ変更をサポートするよう適応された複数処理要素プロセッサの論理的な表現のある実施形態を示す図である。 ハードウェア資源制限に基づくトランザクションの動的サイズ変更のための備えをすることを含むコード最適化方法の流れ図のある実施形態を示す図である。 条件付きコミット・コードを挿入するための図２ａの流れ図のある実施形態を示す図である。 実行中にトランザクションを動的にサイズ変更する方法の流れ図のある実施形態を示す図である。 条件付きコミット点において実行を継続するために十分なハードウェア資源が存在するかどうかを判定するための図３ａの流れ図のある実施形態を示す図である。 トランザクションの動的サイズ変更をサポートするよう適応されたハードウェアの論理的表現のある実施形態を示す図である。 トランザクションの動的サイズ変更をサポートするよう適応されたハードウェアの論理的表現のもう一つの実施形態を示す図である。 トランザクションの動的サイズ変更をサポートするよう適応されたハードウェアの論理的表現のもう一つの実施形態を示す図である。 トランザクション内の投機的チェックポイントのための備えをすることを含むコード最適化方法の流れ図のある実施形態を示す図である。 投機的チェックポイント・コードを挿入するための図７ａの流れ図のある実施形態を示す図である。 トランザクションの実行中に投機的にメモリのチェックポイントを作成する方法の流れ図のある実施形態を示す図である。 メモリの投機的チェックポイント作成をサポートするよう適応されたハードウェアの論理的表現のある実施形態を示す図である。 レジスタ・ファイルの投機的チェックポイント作成をサポートするよう適応されたハードウェアの論理的表現のもう一つの実施形態を示す図である。 キャッシュ・メモリの投機的チェックポイント作成をサポートするよう適応されたハードウェアの論理的表現のもう一つの実施形態を示す図である。

以下の記述では、本発明の十全な理解を与えるために、個別的な型のプロセッサ・コア、個別的なプロセッサ構成、個別的な命令型、個別的なハードウェア構造、個別的なコード最適化技法などの例のような数多くの個別的詳細が記載されるが、当業者にとって、これらの個別的詳細が本発明を実施するために用いられることは必須ではないことは明白であろう。一方、個別的および代替的なプロセッサ・アーキテクチャ、記載されるアルゴリズムのための個別的論理回路／コード、個別的なコード実装、個別的なコンパイラ詳細およびマイクロプロセッサの他の個別的な動作の詳細といったよく知られた構成要素または方法は、本発明を無用に埋没させるのを避けるため、詳細には記述しなかった。

本稿に記載される方法および装置は、ハードウェア制約条件に基づいて動的にサイズを決められるトランザクションを利用してコードを最適化するためのものである。具体的には、コードの最適化は、ハードウェア制約条件を利用する投機的なチェックポイント作成および／またはトランザクションの条件付きコミットに関して論じられる。しかしながら、本稿に記載される装置および方法は、それに限定されるものではなく任意の形の動的にサイズを決められるトランザクションにおいて実装されうる。たとえば、コードの最適化は、静的にも動的にも、またハードウェア、ソフトウェアまたはそれらの組み合わせの中で、実行されうる。

図１を参照するに、複数コアを含むプロセッサのある実施形態が示されている。プロセッサ１００は、マイクロプロセッサ、組み込みプロセッサ、デジタル信号プロセッサ（DSP: digital signal processor）、ネットワーク・プロセッサまたはコードを実行する他の装置といった任意のプロセッサを含む。ある実施形態では、プロセッサ１００は、少なくとも二つのコア――コア１０１および１０２――を含む。これらは非対称的なコアまたは対称的なコア（図示した実施形態）を含みうる。しかしながら、プロセッサ１００は、対称的であっても非対称的であってもよい任意の数の処理要素を含んでいてよい。

ある実施形態では、処理要素は、スレッド・ユニット、スレッド・スロット、プロセス・ユニット、コンテキスト、論理プロセッサ、ハードウェア・スレッド、コアおよび／または実行状態またはアーキテクチャ状態のようなプロセッサのための情報を保持することのできる他の任意の要素を指す。換言すれば、ある実施形態での処理要素は、ソフトウェア・スレッド、オペレーティング・システム、アプリケーションまたは他のコードのようなコードに、独立して関連付けられることのできる任意のハードウェアを指す。物理的なプロセッサは典型的には集積回路を指す。集積回路は、潜在的には、コアまたはハードウェア・スレッドのような任意の数の他の処理要素を含む。

コアはしばしば、それぞれが少なくともいくつかの専用の実行資源に関連付けられる独立したアーキテクチャ状態を維持することのできる、集積回路上に位置される論理を指す。コアとは対照的に、ハードウェア・スレッドは典型的には、実行資源へのアクセスを共有する独立したアーキテクチャ状態を維持することのできる集積回路上に位置される任意の論理を指す。見て取れるように、ある種の資源が共有され、他の資源があるアーキテクチャ状態に専用であるとき、ハードウェア・スレッドとコアの命名法の間の境界線には重なりがある。それでも、コアおよびハードウェア・スレッドはしばしば、オペレーティング・システムによって、個々の論理プロセッサと見られる。ここで、オペレーティング・システムは各論理プロセッサ上の動作を個々にスケジュールすることができる。

図１に示されるような物理的プロセッサ１００は二つのコア、コア１０１および１０２を含む。ここで、コア１０１および１０２は対称的コア、すなわち同じ構成、機能ユニットおよび／または論理をもつコアと考えられる。もう一つの実施形態では、コア１０１は順序外（out-of-order）プロセッサ・コアを含み、一方、コア１０２は順序内（in-order）プロセッサ・コアを含む。しかしながら、コア１０１および１０２は、ネイティブ・コア、ソフトウェア管理されるコア、ネイティブな（native）命令セット・アーキテクチャ（ISA: Instruction Set Architecture）を実行するよう適応されたコア、変換された（translated）命令セット・アーキテクチャ（ISA）を実行するよう適応されたコア、協調設計された（co-designed）コアまたは他の既知のコアといった任意の型のコアから個々に選択されてもよい。しかしながら、今の議論を進める上で、コア１０１において示される機能ユニットについて以下で詳述する。コア１０２における諸ユニットは同様の仕方で動作するからである。

描かれているように、コア１０１は二つのハードウェア・スレッド１０１ａおよび１０１ｂを含む。これらはハードウェア・スレッド・スロット１０１ａおよび１０１ｂと称されてもよい。したがって、オペレーティング・システムのようなソフトウェア・エンティティは、ある実施形態では、潜在的に、プロセッサ１００のことを四つの別個のプロセッサ、すなわち四つのソフトウェア・スレッドを並行して実行することができる四つの論理プロセッサまたは処理要素と見る。上記で言及したように、第一のスレッドはアーキテクチャ状態レジスタ１０１ａに関連付けられ、第二のスレッドはアーキテクチャ状態レジスタ１０１ｂに関連付けられ、第三のスレッドはアーキテクチャ状態レジスタ１０２ａに関連付けられ、第四のスレッドはアーキテクチャ状態レジスタ１０２ｂに関連付けられてもよい。図示したように、アーキテクチャ状態レジスタ１０１ａはアーキテクチャ状態レジスタ１０１ｂに複製され、よって個々のアーキテクチャ状態／コンテキストは、論理プロセッサ１０１ａおよび論理プロセッサ１０１ｂについて記憶されることができる。コア１０１では、命令ポインタおよび名前変更割り当て器論理（rename allocater logic）１３０における名前変更論理のような他のより小さな資源もスレッド１０１ａおよびスレッド１０１ｂについて複製されてもよい。並べ替え／リタイア・ユニット１３５内の並べ替えバッファ、ITLB １２０、ロード／ストア・バッファおよび待ち行列のようないくつかの資源は、パーティショニングを通じて共有されてもよい。汎用内部レジスタ、ページ・テーブル・ベース・レジスタ、低レベル・データ・キャッシュおよびデータTLB １１５、実行ユニット（単数または複数）１４０および順序外ユニット１３５の諸部分のような他の資源は潜在的に完全に共有される。

プロセッサ１００はしばしば、完全に共有されていても、パーティショニングを通じて共有されても、または処理要素によって／処理要素に専用にされてもよい他の資源を含む。図１では、純粋に例示的なプロセッサのある実施形態が、プロセッサの例示的な論理ユニット／資源とともに示されている。プロセッサはこれらの機能ユニットの任意のものを含んだりまたは省略したりしてもよいし、また、図示しない他の任意の既知の機能ユニット、論理またはファームウェアを含んでいてもよい。図示したように、コア１０１は単純化された、代表的な順序外（OOO）プロセッサ・コアを含む。OOOコアは、実行されるべき／取られるべき分岐を予測するための分岐ターゲット・バッファ１２０および命令のためのアドレス変換エントリーを記憶するための命令変換バッファ（I-TLB: instruction-translation buffer）１２０を含む。

コア１０１はさらに、フェッチされた要素をデコードするためのフェッチ・ユニットに結合されたデコード・モジュール１２５を含む。フェッチ論理はある実施形態では、それぞれスレッド・スロット１０１ａ、１０１ｂに関連付けられた個々のシーケンサを含む。通例、コア１０１は、プロセッサ１００上で実行可能な命令を定義／指定する第一の命令セット・アーキテクチャ（ISA）に関連付けられる。ここで、しばしば、第一のISAの一部である機械コード命令は、該命令の、実行されるべき命令または動作を参照／指定する部分である（オペコードと称される）。デコード論理１２５は、これらの命令をそのオペコードから認識し、デコードされた命令を、第一のISAによって定義されるような処理のためにパイプラインにおいて先に渡す回路を含む。たとえば、のちにより詳細に論じるように、デコーダ１２５はある実施形態では、条件付きコミット命令および／または投機的チェックポイント命令のような特定の新しい命令を認識するよう設計または適応された論理を含む。デコーダ１２５による認識の結果として、アーキテクチャまたはコア１０１は、適切な命令に関連付けられたタスクを実行するための、特定のあらかじめ定義されたアクションを行う。

一例では、割り当て器および名前変更器ブロック１３０は、命令処理結果を記憶するためのレジスタ・ファイルのような資源をリザーブするための割り当て器を含む。しかしながら、スレッド１０１ａおよび１０１ｂは潜在的に、順序外実行をできる。ここでは、割り当て器および名前変更器ブロック１３０は、命令結果を追跡するための並べ替えバッファのような他の資源をもリザーブする。ユニット１３０はまた、プログラム／命令参照レジスタをプロセッサ１００内部の他のレジスタに名前変更するレジスタ名前変更器をも含んでいてもよい。並べ替え／リタイア・ユニット１３５は、順序外実行および順序外で実行された命令の、のちの順序内リタイアをサポートするために、上述した並べ替えバッファ、ロード・バッファおよびストア・バッファのようなコンポーネントを含む。

スケジューラおよび実行ユニット（単数または複数）ブロック１４０はある実施形態では、実行ユニット上の命令／動作をスケジュールするスケジューラ・ユニットを含む。たとえば、浮動小数点命令が、利用可能な浮動小数点実行ユニットをもつ実行ユニットのポート上でスケジュールされる。実行ユニットに関連付けられたレジスタ・ファイルも、情報命令処理結果を記憶するために含められる。例示的な実行ユニットは浮動小数点実行ユニット、整数実行ユニット、ジャンプ実行ユニット、ロード実行ユニット、ストア実行ユニットおよび他の既知の実行ユニットを含む。

より低レベルのデータ・キャッシュおよびデータ変換バッファ（D-TLB）１５０が実行ユニット（単数または複数）１４０に結合される。データ・キャッシュは、データ・オペランドのような、最近使用された／作用された要素を記憶する。記憶される要素は潜在的にはメモリ・コヒーレンシー状態に保持される。D-TLBは最近の仮想／線形アドレスから物理アドレスへの変換を記憶する。具体例として、プロセッサは、物理的なメモリを複数の仮想ページに分解するページ・テーブル構造を含んでいてもよい。

ここで、コア１０１および１０２は、最近フェッチされた要素をキャッシュする、より高いレベルまたはより外側のキャッシュ１１０へのアクセスを共有する。より高いレベルまたはより外側というのは、実行ユニットから増大するまたはより遠くに行くキャッシュ・レベルを指すことを注意しておく。ある実施形態では、より高いレベルのキャッシュ１１０は、第二または第三レベルのデータ・キャッシュのような、最終レベル・データ・キャッシュ――プロセッサ１００上のメモリ階層における最後のキャッシュ――である。しかしながら、より高いレベルのキャッシュ１１０はそれに限定されるものではなく、命令キャッシュに関連付けられたり命令キャッシュを含んでいたりしてもよい。代わりに、最近デコードされたトレースを記憶するために、トレース・キャッシュ――命令キャッシュの一つの型――がデコーダ１２５のあとに結合されてもよい。

図示した構成では、プロセッサ１００は、システム・メモリ１７５、チップセット、ノースブリッジまたは他の集積回路といったプロセッサ１００の外部の装置と通信するためのバス・インターフェース・モジュール１０５をも含む。メモリ１７５はプロセッサ１００の専用であってもよいし、またはシステム内の他の装置と共有されていてもよい。メモリ１７５の一般的な型の例は、動的ランダム・アクセス・メモリ（DRAM）、静的RAM（SRAM）、不揮発性メモリ（NVメモリ）および他の既知の記憶装置を含む。

ある実施形態では、プロセッサ１００はハードウェア・トランザクション実行、ソフトウェア・トランザクション実行または両者の組み合わせもしくはハイブリッドの機能をもつ。コードのクリティカルまたは原子的〔アトミック〕なセクション／領域とも称されうるトランザクション（transaction）は、原子的なグループとして実行される命令、動作またはマイクロ動作のまとまりを含む。たとえば、トランザクションまたはクリティカルなセクションを画定するために命令または動作が使われてもよい。のちにより詳細に述べるある実施形態では、これらの命令は、上記のデコーダのようなプロセッサ１００のハードウェアによって認識可能な、命令セット・アーキテクチャ（ISA）のような命令のセットの一部である。しばしば、これらの命令は、ひとたび高水準言語からハードウェアに認識可能なアセンブリー言語にコンパイルされたら、動作コード（オペコード）または該命令の他の部分を含み、それをデコード段の間にデコーダが認識する。

典型的には、トランザクションの実行中、メモリへの更新は、トランザクションがコミットされるまでグローバルに可視にはされない。たとえば、ある位置へのトランザクション書き込みは、ローカルなスレッドに対して潜在的に可視であるが、そのトランザクション書き込みを含むトランザクションがコミットされるまでは、別のスレッドからの読み出しに応答して書き込みデータは転送されない。トランザクションがいまだペンディングである間は、メモリ内からロードされ、メモリ内に書き込まれるデータ項目／要素は追跡される。これについてはのちにより詳細に論じる。ひとたびトランザクションがコミット点に達すると、そのトランザクションについて衝突が検出されていなければ、そのトランザクションはコミットされ、そのトランザクション中になされた更新がグローバルに可視にされる。しかしながら、そのトランザクションがペンディング中に無効にされる場合、そのトランザクションはアボートされ、潜在的には、更新をグローバルに可視にすることなく改めて開始される。結果として、本稿で用いるところでのトランザクションのペンディング状態は、実行を開始しており、まだコミットもアボートもされていない、すなわちペンディングであるトランザクションをいう。

ソフトウェア・トランザクショナル・メモリ（STM: software transactional memory）システムはしばしば、ソフトウェア・コードの実行の範囲内で、または少なくとも主としてソフトウェア・コードの実行を通じてアクセス追跡、衝突解決または他のトランザクション・メモリ・タスクを実行することをいう。ある実施形態では、プロセッサ１００は、ハードウェア／論理を使って、すなわちハードウェア・トランザクショナル・メモリ（HTM: Hardware Transactional Memory）システム内で、トランザクションを実行することができる。HTMを実装する際には、アーキテクチャおよびマイクロアーキテクチャの両方の観点から、数多くの個別的な実装の詳細が存在し、そのほとんどは本発明を無用に埋没させることを避けるためにここでは論じない。しかしながら、いくつかの構造、資源および実装は例示的な目的のために開示される。しかしながら、これらの構造および実装は必須ではなく、異なる実装詳細をもつ他の構造で増強および／または置換されてもよい。

組み合わせとして、プロセッサ１００は、STMシステムおよびHTMシステム両方の利点を活用しようと試みる無制限トランザクショナル・メモリ（UTM: unbounded transactional memory）システム内でトランザクションを実行することができてもよい。たとえば、HTMは、トランザクションについてのアクセス追跡、衝突検出、有効確認およびコミットのすべてを実行するためにソフトウェアに頼らないので、小さなトランザクションを実行するために高速かつ効率的である。しかしながら、STMが無制限のサイズのトランザクションを扱うことができる一方、HTMは通例、より小さなトランザクションを扱うことができるだけである。したがって、ある実施形態では、UTMシステムは、小さめのトランザクションを実行するためにハードウェアを利用し、ハードウェアにとっては大きすぎるトランザクションを実行するためにソフトウェアを利用する。以下の議論から見て取れるように、ソフトウェアがトランザクションを扱っているときでも、ハードウェアがソフトウェアを支援および加速するために利用されてもよい。さらに、同じハードウェアが純粋なSTMシステムをサポートおよび加速するために利用されてもよいことを注意しておくことが重要である。

上述したように、トランザクションは、プロセッサ１００内のローカルな処理要素および潜在的には他の処理要素の両方による、データ項目へのトランザクショナル・メモリ・アクセスを含む。トランザクショナル・メモリ・システム内の安全機構なしでは、これらのアクセスのいくつかが、潜在的には、無効なデータおよび実行を、すなわち読み出しを無効にするデータへの書き込みまたは無効なデータの読み出しを、結果として与えることになる。結果として、プロセッサ１００は潜在的に、潜在的な衝突の識別のためにデータ項目への／からのメモリ・アクセスを追跡またはモニタリングするための論理を含む。のちに論じる読み出しモニタおよび書き込みモニタのようなものである。

データ項目またはデータ要素は、ハードウェア、ソフトウェアまたは両者の組み合わせによって定義される任意の粒度レベルのデータを含んでいてもよい。網羅的ではないデータ、データ要素、データ項目またはその言及の例のリストは、メモリ・アドレス、データ・オブジェクト、クラス、ある型の動的言語コードのフィールド、ある型の動的言語コード、変数、オペランド、データ構造およびメモリ・アドレスへの間接参照を含む。しかしながら、いかなる既知のデータのまとまりがデータ要素またはデータ項目と称されてもよい。ある型の動的言語コードのフィールド、ある型の動的言語コードのような上記の例のいくつかは、動的言語コードのデータ構造を指す。例解すると、サン・マイクロシステムズ社からのジャバ（Java（登録商標））のような動的言語コードは強い型付けの（strongly typed）言語である。各変数は、コンパイル時に知られている型をもつ。それらの型は二つのカテゴリーに分けられる――プリミティブ型（ブーリアンおよび数値、たとえば整数（int）、浮動小数点（float））および参照型（クラス、インターフェースおよびアレイ）。参照型の値はオブジェクトへの参照である。ジャバ（商標）では、フィールドからなるオブジェクトはクラス・インスタンスまたはアレイであってもよい。クラスAのオブジェクトaを与えられたら、型Aのフィールドxを指すのにはA::x、クラスAのオブジェクトaのフィールドxを指すのにはa.xという記法を使うのが慣習である。たとえば、a.x＝a.y+a.zのような表現ができる。ここで、フィールドyおよびフィールドzがロードされて加算され、結果がフィールドxに書き込まれる。

したがって、データ項目へのメモリ・アクセスのモニタリング／バッファリングは任意のデータ・レベルの粒度で実行されうる。たとえば、ある実施形態では、データへのメモリ・アクセスは型のレベルでモニタリングされる。ここで、フィールドA::xへのトランザクション書き込みおよびフィールドA::yの非トランザクション・ロードは、同じデータ項目、すなわち型Aへのアクセスとしてモニタリングされてもよい。もう一つの実施形態では、メモリ・アクセス・モニタリング／バッファリングはフィールド・レベルの粒度で実行されてもよい。ここでは、A::xへのトランザクション書き込みおよびA::yの非トランザクション・ロードは、同じデータ項目へのアクセスとしてはモニタリングされない。両者は別個のフィールドへの参照だからである。データ項目へのメモリ・アクセスを追跡するに当たり、他のデータ構造またはプログラミング技法が考慮に入れられてもよいことを注意しておく。例として、クラスAのオブジェクトのフィールドxおよびy、すなわちA::xおよびA::yがクラスBのオブジェクトをポイントしており、新たに割り当てられたオブジェクトに初期化され、初期化後一度も書き込みが行われていないとする。ある実施形態では、A::xによってポイントされるオブジェクトのフィールドB::zへのトランザクション書き込みは、A::yによってポイントされるオブジェクトのフィールドB::zの非トランザクション・ロードに関して、同じデータ項目へのメモリ・アクセスとしてはモニタリングされない。これらの例から敷衍して、モニタがいかなるデータ粒度レベルでモニタリング／バッファリングを実行してもよいことを決定できる。

ある実施形態では、プロセッサ１００は、データ項目に関連付けられたアクセスおよび潜在的なその後の衝突を検出または追跡するモニタを含む。一例として、プロセッサ１００のハードウェアは、モニタリングされることが決定されたロードおよびストアを追跡するための読み出しモニタおよび書き込みモニタを含む。たとえば、ハードウェアの読み出しモニタおよび書き込みモニタが、根底にある記憶構造の粒度によらず、データ項目の粒度でデータ項目をモニタリングする。ある実施形態では、データ項目は、少なくとも該データ項目全体が適切にモニタリングされることを保証するために、記憶構造の粒度で関連付けられた追跡機構によって境を定められる。

個別的な例解のための例として、読み出しおよび書き込みモニタは、低レベル・データ・キャッシュ１５０（これは投機的キャッシュを含んでいてもよい）内の位置のようなキャッシュ位置に関連付けられた属性を、そうした位置に関連付けられたアドレスからのロードおよび該アドレスへのストアをモニタリングするために含む。ここで、データ・キャッシュ１５０のキャッシュ位置についての読み出し属性は、該キャッシュ位置に関連付けられたアドレスへの読み出しイベントに際して、同じアドレスへの潜在的な衝突する書き込みがないかどうかモニタリングするために、設定される。この場合、書き込み属性は、同じアドレスへの潜在的な衝突する読み出しおよび書き込みがないかどうかモニタリングするために、書き込みイベントについて同様の仕方で動作する。この例をさらに進めると、ハードウェアは、しかるべくキャッシュ位置がモニタリングされることを示すよう設定された読み出しおよび／または書き込み属性をもつキャッシュ位置に対する読み出しおよび書き込みについてののぞき見（snoops）に基づいて衝突を検出することができる。逆に、読み出しおよび書き込みモニタを設定すること、あるいはあるキャッシュ位置をバッファリングされる状態に更新することは、ある実施形態では、読み出し要求または所有権要求についての読み出しのようなのぞき見につながり、これは、他のキャッシュにおけるモニタリングされるアドレスとの衝突の検出を許容する。

したがって、設計に基づいて、キャッシュ・ラインのキャッシュ・コヒーレンシー要求およびモニタリングされるコヒーレンシー状態の種々の組み合わせは潜在的な衝突につながる。たとえば、キャッシュ・ラインがあるデータ項目を、共有された読み出しモニタリング状態に保持し、のぞき見がそのデータ項目への書き込み要求を示す。逆に、バッファリングされた書き込み状態にあるデータ項目を保持するキャッシュ・ラインと、そのデータ項目への読み出し要求を示す外部のぞき見は、潜在的に衝突すると考えてもよい。ある実施形態では、アクセス要求および属性状態のそのような組み合わせを検出するために、のぞき見論理が、衝突検出／報告のためのモニタおよび／または論理および衝突を報告するための状態レジスタのような衝突検出／報告論理に結合される。

しかしながら、条件およびシナリオの任意の組み合わせが、あるトランザクションにとって、無効にする要因であると考えられてもよい。トランザクションの非コミットのために考えられうる因子の例は、トランザクション的にアクセスされるメモリ位置への衝突の検出、モニタ情報の喪失、バッファリングされたデータの喪失、トランザクション的にアクセスされるデータ項目に関連付けられたメタデータの喪失および割り込み、リング遷移もしくは明示的なユーザー命令のような他の無効にするイベントの検出を含む。

ある実施形態では、プロセッサ１００のハードウェアはバッファリングされた仕方でトランザクション的更新を保持する。上述したように、トランザクション書き込みはトランザクションのコミットまでグローバルに可視にされない。しかしながら、トランザクション書き込みに関連付けられるローカルなソフトウェア・スレッドは、その後のトランザクション・アクセスのためにトランザクション更新にアクセスすることができる。第一の例として、バッファリングされた更新を保持するためにプロセッサ１００内に別個のバッファ構造が設けられる。これは、該更新を、ローカルなスレッドに提供し、他の外部スレッドには提供しないことができる。

対照的に、もう一つの例として、データ・キャッシュ１５０のようなキャッシュ・メモリが、同じトランザクション的機能を提供しつつ前記更新をバッファリングするために利用される。ここで、キャッシュ１５０は、バッファリングされたコヒーレンシー状態においてデータ項目を保持することができる。ある場合には、新しいバッファリングされたコヒーレンシー状態が、修正排他共有無効（MESI: Modified Exclusive Shared Invalid）プロトコルのようなキャッシュ・コヒーレンシー・プロトコルに加えられて、MESIBプロトコルをなす。バッファリングされたデータ項目、つまりバッファリングされたコヒーレンシー状態に保持されているデータ項目に対するローカルな要求に応答して、内部的なトランザクション的逐次的順序付けを保証するよう、キャッシュ１５０はそのデータ項目をローカルな処理要素に提供する。しかしながら、外部アクセス要求に応答しては、トランザクション的に更新されたデータ項目がコミットまでグローバルに可視にされないことを保証するよう、ミス応答が提供される。さらに、キャッシュ１５０のあるラインがバッファリングされたコヒーレンシー状態に保持され、放逐のために選択されるとき、バッファリングされた更新はより高いレベルのキャッシュ・メモリに書き戻されない――コミット後まで、バッファリングされた更新はメモリ・システムを通じて増殖されない、すなわちグローバルに可視にされない。その代わり、トランザクションはアボートしてもよく、または放逐されたラインが、犠牲者キャッシュ（victim cache）のような、データ・キャッシュとより高いレベルのキャッシュ・メモリとの間の投機的な構造に記憶されてもよい。コミットに際して、バッファリングされたラインは、そのデータ項目をグローバルに可視にするために、修正された状態に遷移させられる。

内部および外部という用語はしばしば、トランザクションの実行またはキャッシュを共有する処理要素に関連付けられたスレッドの観点に対するものであることを注意しておく。たとえば、トランザクションの実行に関連付けられたソフトウェア・スレッドを実行するための第一の処理要素がローカル・スレッドと称される。したがって、上記の議論において、前記第一のスレッドによって以前に書き込まれたアドレスへのストアまたは該アドレスからのロード（この結果、そのアドレスについてのキャッシュ・ラインはバッファリングされたコヒーレンシー状態に保持される）が受領される場合、そのキャッシュ・ラインのバッファリングされたバージョンは、前記第一のスレッドに提供される。それがローカルなスレッドだからである。対照的に、同じプロセッサ内の別の処理要素で第二のスレッドが実行中であることがあるが、該第二のスレッドは、前記キャッシュ・ラインがバッファリングされた状態に保持される原因となった前記トランザクションの実行には関連付けられていない――外部スレッドである；したがって、この第二のスレッドから前記アドレスへのロードまたはストアは、前記キャッシュ・ラインのバッファリングされたバージョンをミスし、より高いレベルのメモリから前記キャッシュ・ラインのバッファリングされていないバージョンを取得するために、通常のキャッシュ置換が利用される。

ある実施形態では、プロセッサ１００は、トランザクション的実行をサポートするようアプリケーション・コード１７６をコンパイルするとともに、潜在的にはアプリケーション・コード１７６を最適化するためのコンパイラ／最適化コードを実行することができる。ここで、コンパイラはトランザクションの実行を可能にするための演算、呼び出し、関数および他のコードを挿入してもよい。

コンパイラはしばしば、ソース・テキスト／コードをターゲット・テキスト／コードに変換するプログラムまたはプログラムの集合を含む。通例、コンパイラによるプログラム／アプリケーション・コードのコンパイルは、高水準プログラミング言語コードを低水準機械語もしくはアセンブリー言語コードに変換するための複数のフェーズおよびパスにおいて行われる。それでも、単純なコンパイルのためには、単一パスのコンパイラも利用されうる。コンパイラは、任意の既知のコンパイル技法を利用し、語彙解析、前処理、構文解析、意味解析、コード生成、コード変換およびコード最適化といった任意の既知のコンパイラ動作を実行してもよい。本稿で述べられるように、トランザクション的実行と動的コード・コンパイルの結び付きは、必要なメモリ順序付けの防護策を保持しつつ、潜在的には、より積極的な最適化を可能にすることになる。

大きめのコンパイラはしばしば複数のフェーズを含むが、たいていそれらのフェーズは二つの一般的なフェーズの範囲内に含まれる：（１）フロントエンド、すなわち一般に統語処理、意味処理および若干の変換／最適化が行われうるところと、（２）バックエンド、すなわち一般に、解析、変換、最適化およびコード生成が行われるところである。いくつかのコンパイラはミドルエンドを使う。これはコンパイラのフロントエンドとバックエンドの間の境界をあいまいにすることになる。結果として、挿入、関連付け、生成またはコンパイラの他の動作は、上述したフェーズまたはパスの任意のものおよびコンパイラの他の任意の既知のフェーズまたはパスにおいて行われてもよい。例解用の例として、コンパイラは潜在的に、トランザクション的動作、呼び出し、関数などをコンパイルの一つまたは複数のフェーズにおいて挿入する。コンパイルのフロントエンド・フェーズにおける呼び出し／動作の挿入、次いでトランザクション・メモリ変換フェーズの際の該呼び出し／動作の低レベル・コードへの変換である。動的コンパイルの間、コンパイラ・コードまたは動的最適化コードがそのような動作／呼び出しを挿入するとともに、ランタイムの間に実行のためのコードを最適化してもよいことを注意しておく。個別的な例解用の例として、バイナリー・コード（すでにコンパイルされたコード）はランタイムの間に動的に最適化されてもよい。ここで、プログラム・コードは動的最適化コード、バイナリー・コードまたはそれらの組み合わせを含んでいてもよい。

それでも、コンパイラの実行環境および動的または静的な性質にもかかわらず、コンパイラは、ある実施形態では、トランザクション的実行を可能にするおよび／またはプログラム・コードの諸セクションを最適化するためにプログラム・コードをコンパイルする。したがって、プログラム・コードの実行への言及は、ある実施形態では、（１）コンパイラ・プログラム（単数または複数）または最適化コード最適化器を動的または静的に実行して、主たるプログラム・コードをコンパイルする、トランザクション構造を維持する、他のトランザクション関係の動作を実行する、またはコードを最適化する；（２）最適化／コンパイルされたアプリケーション・コードのようなトランザクション動作／呼び出しを含む主たるプログラム・コードの実行；（３）主たるプログラム・コードに関連付けられたライブラリのような他のプログラム・コードの実行または（４）それらの組み合わせのことをいう。

しばしば、ソフトウェア・トランザクショナル・メモリ（STM）システム内で、コンパイルされるべきアプリケーション・コードとインラインで、いくつかの動作、呼び出しおよび他のコードを挿入するためにコンパイラが利用され、一方、他の動作、呼び出し、関数およびコードはライブラリ内で別個に提供される。これは潜在的に、ライブラリ配布者が、アプリケーション・コードを再コンパイルする必要なしにライブラリを最適化および更新する能力を提供する。具体例として、コミット関数への呼び出しがアプリケーション・コード内でトランザクションのコミット点においてインラインで挿入されてもよい。一方、コミット関数は更新可能なライブラリにおいて別個に提供される。さらに、特定の動作および呼び出しをどこに置くかの選択は潜在的にアプリケーション・コードの効率に影響する。

背景セクションにおいて上述したように、複数スレッド・システムにおけるコードの積極的な最適化は、潜在的には、メモリ順序付け問題に関して危険がある。しかしながら、ある実施形態では、コード最適化はトランザクション的メモリ防護策と組み合わされて、メモリ順序付けの防護策を保持しつつ積極的な最適化を許容する。ここで、最適化されたコードを含む原子的な領域がプログラム・コード中に挿入されてもよい。それにより、最適化されたコードの実行時に、トランザクション的防護策はメモリ順序付け違反が起こらないことを保証する。結果として、最適化されたコードは積極的に最適化されることができ、原子的な領域はメモリ順序付け違反が検出されることを保証するので、該領域はコミットされない。

それでも、原子的領域とコード最適化の組み合わせは、さらなる修正から利益を受けることもありうる。したがって、ある実施形態では、プロセッサ１００はプロセッサ１００内のハードウェア資源の利用可能性に基づいてプログラム・コード１７６内のトランザクションを動的にサイズ変更することができる。伝統的には、原子的領域は完全にコミットされるか、アボートされるかのいずれかである。しかしながら、この例では、トランザクションは、該トランザクション（または該トランザクション内のコードの一部分）の完全な実行のために低いまたは不十分な資源が存在しているときは、該トランザクションの終点より前にコミットされることがある。すなわち、より小さなトランザクションに動的にサイズ変更されるのである。例解用の例として、キャッシュ・メモリ１５０が一時的な、トランザクション的情報を、付随するトランザクション的追跡情報とともに保持するために利用されるとする。このシナリオでは、キャッシュ１５０が利用可能なキャッシュ・エントリーが少なくなるまたはオーバーフローする（トランザクション的にアクセスされたラインを放逐のために選択し、犠牲者キャッシュが満杯）とき、実行中のトランザクションはその点においてコミットされ、それにより前記一時的な情報がグローバルに可視になる。次いで、そのコミット点からもとのトランザクションの終点まで、新しいトランザクションが改めて開始されてもよい。結果として、トランザクション的ハードウェア資源――この例ではキャッシュ・メモリ１５０――が解放される。そしてトランザクションは、UTMシステムでのようにトランザクション全体をロールバックしたりソフトウェアに移行してトランザクションを拡大したりする代わりに、二つの、より小さなハードウェア・トランザクションとして完遂することができる。

したがって、ある実施形態では、プロセッサ１００は、HTM、STMまたはUTMのいずれであれ、トランザクション的メモリ・システムをサポートするためのハードウェアを含む。例は、デコーダ、キャッシュ・メモリ、投機的記憶構造、追跡機構、ストア・バッファ、レジスタ・ファイル、チェックポイント記憶機構およびトランザクションの実行をサポートする他の任意の既知のハードウェアである。さらに、プロセッサ１００は、トランザクション的実行をサポートするそのようなハードウェアについての利用可能性（availability）、使用（usage）またはそれらの表現を追跡、提供または指示するよう適応されたハードウェア／論理をも含む。第一の例として、使用メトリック（ハードウェア使用の表現）は、キャッシュ・メモリ、犠牲者キャッシュ、ストア・バッファまたはロード・バッファのような記憶構造における利用可能なまたは反占有された（inversely occupied）エントリーの数を含む。もう一つの例として、使用メトリックは、メモリのオーバーフロー、割り込みイベントまたはエントリーの放逐といったイベントの発生を含んでいてもよい。しかしながら、実際のものであれ抽象的なものであれ、任意の使用メトリックが利用されうる。

より抽象的な使用メトリックの例として、カウンタがコード内のループ反復工程の数を計数し、カウンタが閾値に達したとき、トランザクションがコミットされるとする。ここで、閾値は、不十分なハードウェア資源のためトランザクションのアボートが発生するときは閾値を下げるなど、時間を追ったコード・プロファイリングに基づいて動的に調整されてもよい。その場合、ハードウェア資源または特定のイベントの正確な実際の使用度は提供されない。しかしながら、カウンタ閾値の動的調整を通じて、ハードウェアは本質的に、ハードウェア資源がなくなる前に、すなわち高い資源利用のためにアボートまたはロールバックが実行される前に、ループ数を推定している。結果として、ある実施形態では、そのようなハードウェア推定が、ハードウェア資源についての使用または使用の表現と称される。コード実行のための資源利用可能性を推定しているからである。

ある実施形態では、プロセッサ１００内のハードウェアは、トランザクションがいつ動的にサイズ変更されるべきかを非同期的に決定することができる。たとえば、ハードウェア資源の利用度が高い場合、プロセッサ１００は、プロセッサ１００上で実行されているプログラム・コード１７６の観点からは透明に、トランザクションをコミットして、別のトランザクションを再開してもよい。ここで、トランザクションを含むプログラム・コード１７６は実行論理１４０によって実行されている。プログラム・コードの観点からは、トランザクションはシームレスに実行される。しかしながら、ハードウェアの観点からは、ストア・バッファのような資源が高い利用度を有していた（オーバーフローした）ので、ハードウェアはそのトランザクションを、該トランザクションの終点より前にコミットし、そのコミット点において第二のトランザクションを改めて開始し、次いで第二のトランザクションを該トランザクションのもとの終点においてコミットしたのである。

もう一つの実施形態では、トランザクションの動的サイズ変更はハードウェアおよびファームウェア／ソフトウェアの組み合わせを用いて実行される。ここで、プロセッサ１００は、トランザクション的実行をサポートし、それらの資源の利用度／利用可能性を追跡するためのハードウェア資源を含む。そして、プログラム・コード１７６からの条件付きコードは、実行されたとき、実行論理１４０に、それらのハードウェア資源の利用度／利用可能性に基づいて動的にサイズ変更（終点より前にトランザクションをコミット）させる。本質的には、資源利用度のチェックおよび潜在的な条件付きコミットは、ハードウェアによる特定の命令の実行と独立（非同期）なのではなく、同期的に――ソフトウェア命令の結果として――実行される。

たとえば、動的コンパイラ・コードの一部であってもよい動的最適化コード１７７は、実行論理１４０／１４１によって実行されて、プロセッサ１００のランタイムの間にプログラム・コード１７６を動的にコンパイル／最適化する。そのようなコンパイル／最適化の間、原子的領域が、その原子的領域内の条件付きコミット・コードとともに、プログラム・コード１７６のセクションに挿入される。実行論理１４０／１４１は次いで、ランタイムの間に、コード１７６を動的に最適化し、動的に最適化されたコード１７６を実行する。具体的には、実行論理１４０／１４１は原子的領域およびその中の最適化されたコードを実行する。条件付きコミット・コードに遭遇／条件付きコミット・コードをデコードするデコード段１２５に応答して、ハードウェア資源利用度が決定される。利用度／利用可能性はすでに前に追跡されていてもよいが、条件付きコミット・コードに応答して、利用度が報告／評価されることを注意しておく。次いで、ハードウェア資源の利用可能性／使用に基づいて原子的領域をコミットするか否かについての決定がなされてもよい。

ある実施形態では、資源使用に基づいてコミットするか否かを決定することは、条件付きコードに応答してハードウェアによって実行される。換言すれば、ハードウェアは独立してハードウェア使用を評価し、利用度が、早期コミットを引き起こすのに十分高いかどうかを判定してもよい。例として、条件付きコミット・コードは、デコーダ１２５によって認識可能な条件付きコミット命令を含む。条件付きコミット命令または領域チェック命令は分岐ターゲット・アドレスを含む。そしてハードウェアは、デコード論理１２５で条件付きコミット命令をデコードするのに応答して、ハードウェア資源利用度が高すぎるかどうか、あるいは不十分な資源が存在しているかどうかを判定する。利用度が高すぎる、または不十分な資源が存在する場合、実行論理１４０は実行を、分岐ターゲット・アドレスにジャンプさせる。

ある実施形態では、ハードウェアは、所定のアルゴリズムに基づいて、利用度が高すぎるかどうかまたは不十分な資源が存在しているかどうかを判定する。たとえば、ハードウェア資源がストア・バッファを含むとき、利用度が高すぎることは、所定数のストア・バッファ・エントリーが利用されているまたはオーバーフロー（利用可能なストア・バッファ・エントリーがないこと）が発生していることを含む。ハードウェアはまた、前の実行に基づいてコードの期待される使用を推定し（コード・プロファイリング）、その推定を現在のハードウェア使用と一緒に用いて、条件付きコミットなしに実行を継続するのに十分な資源が存在するかどうかを判定してもよい。

あるいはまた、条件付きコミット命令は、期待される使用を含んでいてもよい。そしてハードウェアは、期待される使用をハードウェア使用と比較し、不十分な資源が存在するかどうかを判定する。たとえば、条件付きコード１７６がプログラム・コード１７６の原子的領域内でループに挿入されるとする。結果として、条件付きコードはループの反復工程毎に実行される。ここで、条件付きコミット命令はループの反復工程中に利用されるストア・バッファ・エントリーの期待される数を参照する。この数は、前記コードによって、または前記コードの動的プロファイリングによって推定されるところによる、タッチされる一意的なストア・バッファ・エントリーの数に基づいていてもよい。条件付きコミット命令をデコードするデコード論理１２５に応答して、エントリーの期待される数が、プロセッサ１００のハードウェアによって決定されるところのストア・バッファ内の利用可能なエントリーの数に対して比較される。期待されるエントリーの数が利用可能なエントリーの数より大きければ、実行は、条件付きコミット命令によって参照される分岐ターゲット・アドレスにジャンプする。分岐ターゲット・アドレスは、原子的領域の早期コミットを実行して第二の原子的領域を改めて開始するために、プログラム・コード１７６またはライブラリ・コードのような他のコード内のアドレス参照コードを含んでいてもよい。

もう一つの実施形態では、ハードウェア利用度が高すぎるまたはハードウェア利用可能性が低すぎるときをソフトウェアが決定する。この例では、プロセッサ１００は、ハードウェア使用の表現（ハードウェア使用メトリック）を保持するレジスタのような記憶要素を含む。ここで、条件付きコードは、使用メトリックをロード／読み込みし、それを評価し、早期コミットが実行されるべきかどうかを判定する動作を含む。早期コミットが実行される場合、条件付きコードはジャンプ動作を含む。ジャンプ動作は、実行論理１４０によって実行されたとき、実行を、現在のトランザクションをコミットして別の原子的領域を開始してもよい分岐ターゲット・アドレスにジャンプさせる。

ハードウェアおよびソフトウェアが同様の評価を実行してもよいことを注意しておく。しかしながら、ハードウェア・ソリューションは潜在的に、ハードウェアが完全に早期コミットを扱うまたは条件付きコミット命令を受信するだけであることを許容することを通じて、コードのコンパクトさを可能にする。それでも、ソフトウェアが評価を実行することを許容すれば、早期コミットをいつ実行するかの決定において、より柔軟性が提供される。結果として、実装および所望される利点に基づいて、ハードウェア利用度／利用可能性が高すぎる／低すぎるときを決定するために、ハードウェアとソフトウェアの間の組み合わせの任意の階調が利用されうる。

図１は、例示的なプロセッサの抽象化された論理的なビューを示しており、種々のモジュール、ユニットおよび／または論理を表現している。しかしながら、本稿で記載される方法および装置を利用するプロセッサは図示したユニットを含む必要はないことを注意しておく。さらに、図１は二つのコアしか描いていないが、プロセッサは、同じ型の複数のコア、それぞれ異なる型の二つより多くのコアなど、任意の数を含んでいてよい。

図１は、外部メモリ・コントローラへのインターフェース（コントローラ・ハブ１７０）をもつ、ポイントツーポイント式に結合されたプロセッサのある実施形態を示している。しかしながら、多くの現在のプロセッサはプロセッサ上メモリ・インターフェース・モジュール――オンチップ・モジュール――を、複数のコアを相互接続するリング構成、共有されるキャッシュおよび他のインターフェースとともに含めるようになってきている。図示していないが、プロセッサ１００はある実施形態では、コア、キャッシュおよびメモリ・コントローラ・コンポーネントを結合するリング相互接続を含む。

ここで、キャッシュ・エージェントが、物理的に分配されたキャッシュのスライスを管理するために利用される。例として、各キャッシュ・コンポーネントは共位置のコア――キャッシュの分配されたスライスを管理するためにキャッシュ・エージェントが関連付けられているコア――についてキャッシュのスライスを管理する。キャッシュ・エージェントがリング相互接続上のトラフィックを扱い、キャッシュ・スライスとインターフェースをもつのと同様、コア・エージェント／コンポーネントはトラフィックを扱い、コアとインターフェースをもつ。さらに、リング相互接続は、メモリ・コントローラ・インターフェース論理（MCIL: Memory Controller Interface Logic）および／または他のコントローラを、メモリおよび／またはグラフィック・プロセッサのような他のモジュールとインターフェースをもつよう結合してもよい。

図２ａに目を転じると、原子的領域を利用してコードを最適化する方法の流れ図のある実施形態が描かれている。図２ａにおけるフローのブロックは実質的に逐次的な仕方で示されているが、図示した方法のフローはいかなる順序で実行されても、または部分的もしくは完全に並列に実行されてもよい。たとえば、条件付きコミット・コードは、原子的領域開始および終了命令を挿入する前に挿入されてもよい。さらに、描かれているブロックが実行されることは必須ではない。そして描かれているブロックと関連してまたは描かれているブロックの代わりに、図示されていない他のブロックが実行されてもよい。

ブロック２０５では、最適化されるべきプログラム・コードのセクションが同定される。上述したように、プログラム・コードは、コンパイラ・コード、最適化コード、アプリケーション・コード、ライブラリ・コードまたは他の任意の既知の形式のコードを指しうる。具体的な例解用の例として、プログラム・コードは、プロセッサ１００上で実行のために動的にコンパイルされたおよび／またはプロセッサ１００上で実行されるよう動的に最適化された実行準備のできたバイナリー・コードのような、プロセッサ１００上で実行されるべきコードを含む。さらに、コード（動作、関数呼び出しなど）の挿入およびコードの最適化は、コンパイラおよび／または最適化コードのようなプログラム・コードの実行を通じて実行される。例として、最適化コードは、ランタイムにおいてプロセッサ１００上で動的に実行されて、プロセッサ１００上でのプログラム・コードの実行の直前に、該プログラム・コードを最適化する。

ある実施形態では、擬似コードBからの領域のような、最適化されるべきプログラム・コードのセクションを同定することは、該コードが最適化されるべきプログラム・コードのセクション／領域を指示することを含む。たとえば、最適化されるべきまたは最適化から裨益する可能性の高いコードのセクションを指示するために特定の命令または境界が利用される。もう一つのオプションとして、プログラマーがプログラム・コードの諸セクションに関するヒントを提供し、それが最適化コードによって最適化のためのセクションを同定するために利用される。もう一つの実施形態では、プロファイリング情報に基づいて領域が同定／選択される。たとえば、プログラム・コードは、ハードウェア、プロセッサ上で実行されるソフトウェア、ファームウェアまたはそれらの組み合わせによる実行の間に、プロファイリングされる。ここで、コードのプロファイリングはヒントを生成するまたはもとのソフトウェア・ヒントを修正するとともに、最適化のための領域の直接的な同定を提供する。さらに、コードのセクションは、特定の型、フォーマットまたはコードの順序といったある種の属性によって潜在的に同定される。具体的な例解用の例として、ループを含むコードが潜在的な最適化のターゲットとされる。そして実行中のループのプロファイリングがどのループが最適化されるべきかを決定する。また、ループが最適化されるべきロードおよびストアのような特定のコードを含む場合、そのようなコードを含む領域が最適化のために同定される。擬似コードBから見て取れるように、この領域は、ループ実行を最適化するためにループの外に持ち上げたり押し出したりすることができるロードおよびストアを含んでいる。

ある実施形態では、最適化のために同定されたコードのセクションは原子的領域に変換される。あるいは、コードの該セクションの少なくとも一部分が原子的領域に変換される。ここで、コードの前記一部分は、ブロック２１０〜２１５に示されるように、開始および終了（コミット）トランザクション（原子的領域）命令によって区画される。擬似コードCから見て取れるように、領域開始（region start）および領域コミット（region commit）命令がそれぞれコードの当該領域の前および後に挿入される。ある実施形態では、コードは複数の入口および複数の出口を含む。結果として、開始原子的領域および終了原子的領域命令は、それぞれ各入口点および各出口点に挿入されてもよい。しかしながら、領域が原子的であることを指示する任意の既知の方法が利用されうる。

ブロック２２０では、条件付きコミット点が決定される。最適化されるべきコードの領域内で複数の条件付きコミット点が決定／割り当てされてもよいことを注意しておく。ただし、議論の簡単のため、以下では一つのコミット点のみをより詳細に論じる。条件付きコミット点を決定することは、条件付きコミット点どうしの間でハードウェア資源の枯渇を避けようとするためのいかなる既知の割り当て／決定アルゴリズムに基づいていてもよい。第一の例として、反復工程のたびごとに条件付きコミット点に遭遇するよう、条件付きコミット点がループ内に挿入される。ここで、条件付きコミット点はループの先頭に決定される。もう一つの例として、コードの動的プロファイリングが、ハードウェア資源の枯渇につながることが多い実行経路を示す。よって、そのような経路の実行の間に資源の枯渇を避けるために、そのような実行経路に条件付きコミット点が割り当てられる。同様に、独占するまた資源的にヘビーであることが知られている実行経路に条件付きコミット点が割り当てられてもよい。

ブロック２２５では、条件付きコミット・コードが少なくとも前記条件付きコミット点に挿入される。条件付きコミット・コードは、次のコミット点までの実行をサポートするために不十分なハードウェア資源が存在していることが判定される場合に、トランザクションのサイズ変更、すなわち早期コミットを引き起こす。暫時図２ｂに目を転じると、条件付きコミット・コードを挿入するための流れ図のある実施形態が示されている。フロー２２６では、条件付きコミット命令が条件付きコミット点に挿入される。擬似コードDから見て取れるように、条件付きコミット命令は、ある実施形態では、原子的領域内のコミット点L1において挿入された領域チェック（region check）命令を含む。

第一の例として、領域チェック命令または条件付き分岐命令のような条件付きコミット命令は、分岐ターゲット・アドレスへの参照を含む。次のコミット点まで実行をサポートするのに不十分な資源が存在していると判定する結果として、実行は、条件付きコミット命令に応答して分岐ターゲット・アドレスにジャンプする。ここで、条件付きコミット・コードは、分岐ターゲット・アドレスにおけるコミット・コードをも含んでいてもよい。本質的に、この例では、条件付きコミット命令は、十分な資源が存在するかどうかを判定するための試験／問い合わせを開始する。そして分岐ターゲット・アドレスにおけるコードは、不十分な資源が存在しているときにトランザクションを早期にコミットする。したがって、ブロック２２７では、分岐ターゲット・アドレスにおいてコミット（commit）命令が挿入される。

擬似コードDでは、第一の領域コミット（region_commit）命令はB4における原子的領域の出口／終点において挿入され、第二の領域コミット（region_commit）はブロックB6における分岐ターゲット・アドレス点L2において挿入される。ここで、L1における領域チェック命令に応答して不十分な資源が判別される場合、実行は、領域チェック命令によって参照される分岐ターゲット・アドレス（B6）にジャンプする。トランザクション・ライブラリ内のコミット関数への呼び出しまたはアーキテクチャ上認識されるコミット命令のような領域コミット命令は、原子的領域を早期に（終点B4より前に）コミットするよう実行される。さらに、ブロック２２８（擬似コードDからのB7）では、第二の開始原子的領域命令（region_start）が領域コミット命令のあとに挿入される。結果として、B3において原子的領域の実行が始まる（region_start）。そしてL1において領域チェック命令によって不十分な資源が判別されるか終点B4に遭遇するまで続く。しかしながら、L1において不十分なハードウェア資源が判別される場合には、もとのトランザクションがサイズ変更される、すなわちコミット点L2、B6においてコミットされる。次いで、第二の原子的領域がB7において開始され、領域実行は、コミット点B4までまたはL1で資源がいま一度制限されるまで、第二のトランザクションとして継続される。したがって、ハードウェア資源の枯渇を避けるために、単一の原子的領域は、動的に、より小さなトランザクションにサイズ変更されうる。そのようなハードウェア資源の枯渇は従来であればアボートまたはソフトウェア・トランザクション的実行への拡張を引き起こすところである。

条件付きコミット命令はいかなる情報を含んでいてもよいことを注意しておく。たとえば、先述したように、条件付きコミット命令は、ある実施形態では、次のコミット点までの期待されるハードウェア資源使用を含む。たとえば、擬似コードDにおけるコードB2を通じたループの間に利用されるエントリーの期待される数である。ここで、この期待される使用は、ループB2のもう一回の反復の実行をサポートするのに十分な資源が存在しているかどうかを判定する際に利用される。具体的な例解用の例として、期待される使用は、次のコミット点までにコードの当該領域の実行に応答して一意的にタッチされると期待される記憶構造内のエントリーの数を含む。

さらに、条件付きコードは条件付きコミット命令に限定されない。たとえば、ハードウェアが使用を判別し、その使用をレジスタ（図５を参照してより詳細に論じる）に入れる実施形態では、条件付きコードは、レジスタから該使用を読み／ロードし、該使用を評価し、次いで擬似コードDからのB6およびB7と同様のコミットおよび再開コードに分岐するジャンプまたは分岐動作を発する。他の実施形態では、ソフトウェアは、ハードウェアと通信したりハードウェアに問い合わせたりするのではなく、ハードウェア使用を推定してもよい。そのシナリオでは、条件付きコードは、そのような推定を実行するコードを含む。たとえば、条件付きコミットを実行するまでのループの反復回数を制限するため、図６を参照してより詳細に述べるカウントが、ソフトウェアの実行を通じて保持される。この例では、カウントを保持するために実行されるべきコードが条件付きコミット・コードと考えられる。

ブロック２３０では、プログラム・コードのセクションが最適化される。擬似コードEは最適化後のコードの例を描いている。

原子的領域の画定（demarcation）および条件付きコミット・コードの挿入はいくつかの実施形態ではプログラム・コードを最適化すると考えられるが、プログラム・コードのセクションは、他の実施形態では、トランザクション的実行のメモリ順序付け防護策に依拠しつつ、実行利益を得るためにさらに最適化される。具体例として、ロードおよびストアが、部分冗長性ロード消去（PRLE）および部分デッド・ストア消去（PDSE）を利用して、ループの外側に持ち上げられたり押し出されたりする。擬似コードEは、PRLEが[r2]および[r2+4]のロードを持ち上げ、PDSEが[r2+4]のストアを押し出したあとの原子的領域を描いている。ある実施形態では、さらなるメモリ順序付け規則が適用されることを注意しておく。ここで、メモリ順序付けを破るいかなるメモリ最適化も領域開始およびコミットを横断しないことを保証することが有利でありうる。この例は擬似コードEにおいて見て取れる。ここで、[r2+4]ストアはB6における領域コミットの前に挿入されており、[r2]および[r2+4]のロードはB7における領域開始（region_start）命令のあとに再挿入されている。結果として、領域が早期にコミットされる（条件付きコミット点までとなるようサイズ変更される）場合には、[r2+4]ストアは領域がB6においてコミットされる前に実行される。そして[r2]および[r2+4]ロードはB7における新しいトランザクションの再開後に実行される。

上記ではロードおよびストア最適化について追求したが、いかなる既知のコード最適化技法が利用されてもよい。非網羅的なリストであり純粋に例示するものとして、コード最適化のさらにいくつかの例を挙げておくと、ループ最適化、ソフトウェア・パイプライン化、データ・フロー最適化、コード生成最適化、境界チェック消去（bounds checking elimination）、分岐オフセット最適化、デッド・コード消去およびジャンプ接続（jump threading）がある。

図３ａを参照するに、原子的コードを動的にサイズ変更するための流れ図のある実施形態が描かれている。ブロック３０５では、最適化されたプログラム・コードを含むトランザクション（原子的領域）が実行される。ある実施形態では、最適化されたプログラム・コードはランタイムの間に動的に最適化される、すなわち、プログラム・コードを「オンザフライ」でちょうど実行に間に合うように最適化するために、動的最適化コードがランタイムにおいて実行される。しばしば、この型の動的最適化またはコンパイルは、静的なコンパイルの際のようにプログラム全体を認識することはせず、セクションに分かれたコードの諸部分をコンパイル／最適化できる。

ブロック３１０では、領域チェック命令に遭遇する。ある実施形態では、領域チェック命令に遭遇することは、デコード論理がその命令をデコードすることを含む。しかしながら、遭遇はその命令（またはその命令の動作）の受け取りまたはサービスのパイプラインのいかなる段階を指していてもよい。たとえば、領域チェック命令に遭遇することは、上記の代わりに、その命令に関連付けられた動作のためのバッファ内にエントリーが割り当てられること、該動作のディスパッチ、該命令のための動作またはマイクロ動作を実行する実行ユニットによる該命令の実際の実行またはパイプラインの他の任意の既知の段階を指してもよい。上述したように、領域チェック命令は、ある実施形態では、ハードウェアに問い合わせするための、プロセッサのデコーダによって認識可能なISAの部分である。問い合わせは単に、使用についてハードウェアに問い合わせするためのロードであってもよい。次いでソフトウェアが、ハードウェアからのそれ以上の関与なしに、十分な資源が利用可能であるかどうかを判定する。対照的に、問い合わせは、原子的領域の実行を継続するために十分な資源が存在しているかどうかをハードウェアが判定することの要求を含んでいてもよい。ここで、問い合わせは、不十分な資源が存在している場合にハードウェアが分岐するターゲット・アドレスを提供する。それでも、問い合わせは、十分な資源が利用可能であるかどうかを判定する際にハードウェアが利用するための期待される使用をも領域チェック命令が提供する、より込み入ったものであってもよい。

領域チェック命令に応答して、ブロック３１５では、領域チェックのための点において、ハードウェア・ユニット（単数または複数）が、次の条件付きコミット点までなどのトランザクションのある領域を完遂するために十分な資源を有しているかどうかが判定される。十分なハードウェア資源が存在するかどうかの判定は、任意の仕方で、実際に測定されても、あるいは近似されてもよい。第一の例として、ハードウェア自身が使用レベルを追跡および／または判別する。そしてハードウェア、ファームウェア、ソフトウェアまたはそれらの組み合わせが、その使用レベル／メトリックがトランザクションのある領域を完遂するための十分な利用可能性を含んでいるかどうかを判定する。しかしながら、使用レベルは純粋にソフトウェアの指令で近似／測定されてもよいことを注意しておく。この場合、測定は、ハードウェアが独自の追跡を実行する上述した例ほど正確ではないことがあるが、測定をサポートするために追加的なハードウェア・フックを追加する必要はない。

暫時図３ｂを参照するに、トランザクションのある領域の実行を完遂するための十分な資源があるかどうかを判定するための流れ図のある実施形態が示されている。フロー３５０において、ハードウェア・ユニットまたは複数のハードウェア・ユニットの期待される使用が決定される。ハードウェア、ファームウェア、ソフトウェアまたはそれらの組み合わせが期待される使用度を決定するために利用されてもよい。

あるシナリオでは、トランザクションを含むプログラム・コードの実行がプロファイルされる。プロファイリングの際、限られた資源に起因するアボートの数、アボートなしのコミットおよび／またはハードウェア使用が追跡される。その後、コンパイラのようなコードが、過去の実行プロファイルに基づいて期待される使用のヒントまたは示唆を提供する。もう一つのシナリオでは、期待される使用は推定値を含んでいてもよい。たとえば、ハードウェア・ユニットがストア・バッファである場合、期待される使用は、この状況では、コード領域における一意的なストア（新たなストア・バッファ・エントリーに割り当てられる可能性の高いストア動作）の数を含む。本質的に、コード中のストアの数は、コード領域の実行の間に利用されるストア・バッファ・エントリーの数を推定している。しかしながら、期待される使用を判定することは、ソフトウェア・プロファイリングまたは推定に限定されない。その代わり、ハードウェアが同様のプロファイリングまたは推定を実行するとともにコードと連携して動作して、期待される使用を決定してもよい。

同様に、フロー３５５では、ハードウェア・ユニットの利用可能な使用がハードウェア、ソフトウェア、ファームウェアまたはそれらの組み合わせにおいて判別される。上記からの例を続けると、条件付きコミット命令がハードウェアに、32エントリー・ストア・バッファの期待される使用が、推定または過去のプロファイリングに基づいて10個のストア・バッファ・エントリーを含むことを知らせるとする。次いで、ストア・バッファは、その先頭および末尾ポインタを利用して、20個のエントリーが現在割り当てられている（12個の利用可能なエントリー）と判定することができる。この判定から、フロー３６０において比較が実行されうる。そして利用可能なエントリーの数が期待される使用より多いので、フロー３６０において、実行を継続するための十分な資源が存在していると判定される。あるいはまた、9個のエントリーしか利用可能でない場合には、フロー３７０において、十分な資源が存在していないと判定される。

しかしながら、比較は、厳密に十分なスペースがハードウェア資源中で利用可能であることを保証することに限定されない。その代わり、閾値の使用を通じて緩衝〔バッファ〕ゾーンが設けられてもよい。たとえば、使用が高い（ある閾値より上）または利用可能性が低い（ある閾値より下）場合、フロー３６５、３７０において同様の判定がなされてもよい。具体的な例解用の例として、6エントリーの緩衝ゾーンが利用可能性について利用されるとする。この場合、利用されるべく期待されるエントリーの数が10であり、32エントリー・バッファにおいて20個が利用されている場合、12個のエントリーしか利用可能でない。よって、10エントリーの期待される使用が割り当てられたとしたら、利用可能なものとして2個のエントリーしか残らない。利用可能に残される6エントリーの緩衝ゾーンが利用されるので、フロー３７０において不十分な資源が判定される。その代わり、20個のエントリーが利用可能であれば（12個のエントリーが利用されている）、十分な資源が存在する（フロー３６５のように）。そのコード領域について10個のエントリーを割り当ててもまだ10個の利用可能なエントリーが残るからである。

さらに、使用および利用可能性はスレッド優先度および使用を考慮に入れてもよい。ここで、複数のスレッドがハードウェア資源へのアクセスを共有していた場合、資源は分割されるか、または完全に共有されてもよい。結果として、期待される使用と比較しての使用および利用可能性は、この共有を考慮に入れてもよい。よって、一つのスレッドがハードウェア資源を独占（他のスレッドのために十分な利用可能性を残さない）しない。たとえば、二つのスレッドが分割を通じてキャッシュへのアクセスを共有する場合、一方のスレッドからのトランザクションは、キャッシュのエントリーの半分に制限されうる。よって、使用および利用可能性は、この点で、キャッシュ全体ではなく、キャッシュの半分である。

上記の議論は、ストア・バッファを参照し、暫時キャッシュを参照したが、使用／利用可能性は、ストア・バッファ、ロード・バッファ、キャッシュ・メモリ、犠牲者キャッシュ、レジスタ・ファイル、待ち行列、実行ユニットまたは他の既知のプロセッサ・ハードウェアのようないかなる単数のハードウェア資源またはハードウェア資源の組み合わせに関していてもよい。たとえば、ハードウェア資源がキャッシュ・メモリを含む場合、期待される使用はタッチされる／利用されるキャッシュ・ラインの数を含んでいてもよい；使用はデータを保持するキャッシュ・ラインの数またはコヒーレンシー状態にある／ないキャッシュ・ラインの数、たとえば共有される、排他的なまたは修正されたキャッシュ・ラインの数を含んでいてもよい；利用可能性は、無効なコヒーレンシー状態のような特定のコヒーレンシー状態にある／ない利用可能なエントリーまたはラインの数を含んでいてもよい。さらに、利用可能性／使用については、利用可能性／使用を測定するハードウェアを参照してさらに論じてある。しかしながら、上述したように、使用および利用可能性は、直接または間接的に測定されてもよいし、ソフトウェア、ハードウェアまたはそれらの組み合わせによって推定されてもよい。

図３ａを参照するに、当該領域を完遂する十分な資源があると判定される場合、実行フローはフロー３０５に戻る。換言すれば、実行は、次の条件付きコミット点まで継続し、その点において、ハードウェア資源の評価が再び実行されてもよい。それでも、十分な資源が存在しないと判定される場合には、フロー３２０において、トランザクションはトランザクションの末尾より前に、コミットされる（動的にサイズ変更される）。ある実施形態では、シームレスな実行を提供するため、原子的実行を継続するよう新しいトランザクションがフロー３２５において開始される。ここで、単一のより大きなトランザクションが本質的には、より多くの実行スペースを与えるための仮想またはシステム・メモリへの拡張なしにハードウェアによって扱うことのできる、より小さなトランザクションに動的に分割されている。

図４に目を転じると、トランザクションの実行をサポートする論理ブロックのある実施形態が示されている。描かれているように、メモリ４０５は、オペレーティング・システム（OS）コード、ハイパーバイザー・コード、アプリケーション・コード、動的コンパイラ・コードなどといったプログラム・コード４１０を保持するよう適応されている。例として、プログラム・コード４１０は、図２ａ〜２ｂに従って動的に（ランタイムまたは部分的プログラム・コンパイルにおいて）最適化されるべきアプリケーション・コードの少なくとも一部分を含む。ランタイムの間、動的サイズ変更をサポートするコードを有するトランザクションをもつ最適化されたコードを含むコード４１０が実行される。ある実施形態では、プログラム・コード４１０は、先に論じたように、領域チェック命令のような条件付きコミット命令４１５を含む。

ここで、デコーダ４２５（プロセッサのデコード論理）は、条件付きコミット命令４１５を認識するよう適応されている。たとえば、デコード論理４２５は命令セット・アーキテクチャの一部としてオペコード４１８を同定するよう設計され、相互接続される。結果として、デコーダ４２５がコード（オペコード）４１８を含む条件付き命令４１５をデコードするのに応答して、個別的な（あらかじめ定義された）動作／マイクロ動作が論理４３０、ハードウェア４３５および実行論理４４０によって実行される。描かれているように、条件付き命令４１５は期待されるハードウェア使用（ハードウェア使用メトリック）４１６への参照および分岐アドレス４２０（別のターゲット・アドレスへの、コード内の、ベース・アドレスおよびオフセットのようなアドレス位置）を含む。

デコーダ４２５が条件付き命令４１５をデコードする／条件付き命令４１５に遭遇するとき、ある実施形態では、条件付きコミット命令４１５によって示される実行されるハードウェア使用を受け入れるために利用可能な十分なハードウェア資源があるかどうかをハードウェアが判定する。ハードウェア資源使用およびハードウェア資源の期待される使用を受け入れるために十分な資源が利用可能であるかどうかを判定するには、いかなる既知の方法および装置が利用されてもよい。それでも、以下では、そのような判定を実装するための一つの実施形態の例解を与えるため、具体例を論じている。

ここで、デコーダ４２５が条件付き命令４１５を受け取ると、他の動作／マイクロ動作が、プロセッサ・パイプライン内のデコーダ４２５および論理４３０によって実行される。たとえば、デコーダ４２５は条件付きコミット命令４１５を、実行されるべき動作のトレースのような複数の動作（マイクロ動作）にデコードしてもよい。上記の議論から、トレースはデコード後にトレース・キャッシュにおいて記憶／構築されてもよいことを注意しておく。たとえば、それらの動作の一つがハードウェア資源の使用レベルを示すためにレジスタの読み出しまたはハードウェア４３５からのロードを含む場合、論理４３０はロード・バッファ中にエントリーを割り当て、実行論理４４０上でそのロードの実行をスケジュールしてもよい。

さらに、ハードウェア４３５は、条件付き命令４１５に応答して提供、決定またはロードされるそのような使用レベル４３５を決定するよう適応される。上記から、使用レベルを決定させうる、トランザクション的実行をサポートするためのハードウェアの数多くの例が、キャッシュ・メモリ、投機的キャッシュ・メモリ、ストア・バッファ、ロード・バッファ、レジスタ・ファイル、投機的レジスタ・ファイル、チェックポイント・レジスタ・ファイルなどを含む。結果として、命令４１５は、一つまたは複数のハードウェア資源についての一つまたは複数の期待される使用メトリックを含みうる。別個のハードウェアまたは当該資源自身が、その使用レベルを追跡するよう適応される。たとえば、キャッシュ・メモリのためのキャッシュ制御論理が、ある実施形態では、キャッシュ・メモリ中に保持される無効なキャッシュ・ラインの数またはキャッシュ・メモリ中の利用可能なラインの数といった、キャッシュ・メモリの使用レベルを追跡するよう適応される。

次いで、決定されたハードウェア使用レベルと比較しての期待される使用レベルに基づいて、早期コミット（動的サイズ変更）なしにトランザクションの実行を継続するために十分な資源が存在するかどうかが判定される。早期コミットが実行されるべきであれば、描かれている例では、実行論理４４０は条件付きコミット命令４１５によって定められるように、分岐ターゲット・アドレス４２０にジャンプする。上述したように、分岐ターゲット・アドレスは、実行されたときにトランザクションを早期にコミットし、原子的な実行を継続するために別のトランザクションを再開するコードを含んでいてもよい。

具体的な例解用の例として、条件付きコミット命令４１５がデコード４２５によって受領されるとする。そして、条件付き命令４１５は、10個のストア・バッファ・エントリーおよび10個のキャッシュ・ラインの期待される使用メトリック４１６を含む。ハードウェア４３５（トランザクション・キャッシュ・メモリおよびストア・バッファ）はその使用レベルを判別する。これらのハードウェア・エンティティは連続的に使用を追跡していてもよく、条件付きコミット命令４１５による問い合わせ／要求の際にそのような使用を提供することを注意しておく。あるいは、条件付きコミット命令４１５が受領されたときに論理が実際に使用を決定してもよい。いずれにせよ、ハードウェア使用レベル／メトリック４３６は、実行論理４４０による実行のための情報を保持するレジスタのような記憶要素に提供される。次いで、ハードウェア使用レベル４３６および期待されるハードウェア・メトリック４１６が比較されて、早期コミットなしに実行を継続するために十分な資源が利用可能であるかどうかが判定される。上記から、設計者の任意のアルゴリズム上の選好に基づいて、十分な資源が利用可能であるかどうかを決定するために、上記の比較は、緩衝ゾーン、閾値または直接比較を利用しうることを注意しておく。

ここで、ストア・バッファが32個のストア・バッファ・エントリーのうち16個を利用しており（16個の利用可能なエントリー）、トランザクション・キャッシュは64個のエントリーのうち60個がトランザクション的にアクセスされたとマークされている（当該トランザクションはすでにこれらのラインにアクセスしており、そのようなラインの置換は情報の損失につながり、アボートまたはソフトウェア・トランザクション実行への拡張を引き起こす、すなわち4個の利用可能なエントリー）とする。さらに、設計者のアルゴリズムが、期待されるエントリー数を考慮に入れたあと、4個の利用可能なエントリーがあるべきであると指定しているとする。その場合、期待されるストア・バッファ・エントリーが10個で、利用可能なエントリーが16個なので、次の条件付きコミット点まで原子的実行を受け入れる十分な利用可能なスペースがストア・バッファにある。それでも、トランザクション的にアクセスされたとマークされていないキャッシュ・エントリーは4個しかないので、十分なトランザクション的キャッシュ・スペースはない。結果として、ジャンプ実行ユニットのような実行論理４４０は、当該トランザクションを早期にコミットして（トランザクションを動的に縮小して）別のトランザクションを改めて開始するようコードをフェッチし、デコードし、実行するために、分岐ターゲット・アドレス４２０にジャンプする。

上記の例は、期待されるハードウェア使用メトリックおよび分岐ターゲット・アドレスを含む条件付きコミット命令を参照して論じられていることを注意しておく。しかしながら、条件付きコミット命令は、コードの実行をサポートするために十分なハードウェア利用可能性があるかどうかをハードウェアに評価または推定させる任意の命令を含んでいてもよい。たとえば、条件付きコミット命令は、単なる条件付きジャンプ命令であってもよい。ここでは、ハードウェアが現在の使用レベルを当該コードの過去のハードウェア・プロファイリングと突き合わせて評価して、トランザクションがコミットされるべきかどうかを判定する。そして、該評価を行ったあとのハードウェアは、条件付きコミット命令によって与えられる分岐アドレスにジャンプすることができる。

もう一つの実施形態では、ハードウェアは非同期的に（特定の条件付きコミット命令に縛られたり特定の条件付きコミット命令に応答したりするのでなく）トランザクションがコミットされるべきであると判定してもよい。ここで、プロセッサがトランザクション的コードを実行していて、オーバーフロー・イベント（すでにトランザクション的にマークされているエントリーの放逐のような、ハードウェア資源にスペースが残っていないことを示すイベント）が発生するとき、ハードウェアは、当該コードが何も知らないうちに、そのハードウェア・トランザクションをコミットして、新しいトランザクションを改めて開始してもよい。

次に図５を参照するに、トランザクションの動的サイズ変更をサポートするハードウェアのもう一つの実施形態が示されている。以前に（図４に関して）、判別されたハードウェア使用レベル／メトリックが、実行論理４４０による動作のために利用されるレジスタのような記憶要素に入れられてもよいことを論じた。その例と同様に、判別されたハードウェア使用レベル／メトリックは、同様に、レジスタ５５０のような記憶要素中にロードされてもよい。しかしながら、ある実施形態では、モデル固有レジスタ（MSR: Model Specific Register）を含んでいてもよいレジスタ５５０は、ハードウェア資源利用可能性の評価を実行するためにユーザー・レベルのアプリケーション・コードのようなプログラム・コードによってアクセス可能である（に対して明かされる）よう適応される。前の例においては、ソフトウェアからの期待される使用に基づいてハードウェアが評価を実行した。ここでは、ソフトウェアがハードウェア（MSR ５５０）に問い合わせをして、一つまたは複数のハードウェア資源の使用レベルを受け取ることができる。次いで、ソフトウェアは、次のコミット点まで原子的実行を継続するのに十分な資源があるかどうかを、独自のガイドラインに基づいて判定することができる。これは、ハードウェアのどのくらい多くを使用するかをユーザーが決定できるようにするので、ユーザーに対してより大きな柔軟性を提供しうる。結果として、プロセッサ設計者は、プロセッサがより多くの制御を保持するべきか、あるいはユーザーがそのような決定をできるかを選択しうる。

具体的な例解用の例として、プロセッサが、潜在的に動的なサイズ変更のための挿入された／最適化されたトランザクションを含むプログラム・コード５１０を最適化および実行するために動的コンパイラ・コードを実行しているとする。ここで、プロセッサのためのフェッチ論理（図示せず）は、プロセッサのスレッドのための命令ポインタ（図示せず）に基づいて、ロード動作５１５をフェッチする。ロード・バッファ・エントリーが、ロード・バッファにおいて、論理５３０／ハードウェア５３５において割り当てられる。ロードは論理５３０によってスケジュールされ、ディスパッチされるとともに、実行論理５４０によって実行され、ハードウェア５３５（キャッシュ、バッファまたはレジスタ・ファイルのような、トランザクション的実行をサポートするための資源）から判別された使用レベル５３６をロードする。ロードまたは先行する命令が同期的にハードウェア５３５に、利用度を決定するおよび／または利用度をMSR ５５０に入れることをさせてもよいことを注意しておく。あるいはまた、ハードウェア５３５は利用度レベルをMSR ５５０内に非同期的に（イベントに基づいてまたは周期的に）入れてもよい。いずれにせよ、使用レベルは動作５１６によって読み出され、評価される。

たとえば、動作５１６は、ロードされたハードウェア使用レベルを、期待される使用レベルまたはソフトウェアによって定義された他の閾値レベルとともに評価するブール表式を含んでいてもよい。実際、ブーリアン表式は条件文および／またはジャンプ命令５１７の一部であってもよい。これについては次に、より詳細に論じる。ここで、ハードウェア使用レベルの評価が、トランザクションが早期にコミットされるべきであると示す場合、デコーダ５２５によってオペコード５１７ｏを通じて認識されるジャンプ命令５１７が実行されて、上記で論じたように、宛先アドレス５２０に分岐して、当該トランザクションをコミットして別のトランザクションを改めて開始する。

ここで図６に目を転じると、トランザクションの動的サイズ変更をサポートするハードウェアのさらにもう一つの実施形態が示されている。ある実施形態では、カウンタ６５０が、ループ６１５の実行を通じて反復工程の回数を計数するよう適応される。カウンタ６５０はハードウェア、ソフトウェア、ファームウェアまたはそれらの組み合わせで実装されうることを注意しておく。たとえば、カウンタ６５０は、値を保持するレジスタであってもよい。そして、ループを通じた各反復工程に際して、ソフトウェア・コードが現在の値を読み、該現在の値を修正（インクリメント／デクリメント）して新しい値にし、新しい値をレジスタに記憶する。本質的には、ソフトウェアがカウンタを維持する。しかしながら、ハードウェア・カウンタがループの各反復工程の始まりまたは終わりにおいてインクリメント／デクリメントしてもよい。

ある実施形態では、カウンタ６５０のカウンタ値は、トランザクションの早期コミットが行われる時を決定するために使われる。たとえば、カウンタ６５０は、閾値に達するまで、ループの反復工程の回数を計数する。閾値に達したら、カウンタは満了となるまたはオーバーフローして、早期コミットを引き起こす。カウンタはゼロで始まって閾値に達する（オーバーフローする）までカウントアップしてもよく、あるいはある値で始まってゼロまでカウントダウン（満了またはアンダーフロー）してもよい。

閾値（またはゼロまでデクリメントされるカウンタについては開始値）はいかなる仕方で決定されてもよい。ハードウェアに含まれるまたはソフトウェアによって設定される、静的な、あらかじめ定義された値であってもよい。ここで、静的なあらかじめ定義された値は、プロセッサに含まれるハードウェアの型またはサイズや実行されているコードの型またはサイズといった、いかなる既知の特性に基づいてハードウェアまたはソフトウェアによって知的に選択されてもよい。あるいは、静的なあらかじめ定義された値は、ロールバックが著しく軽減されるようループの反復工程の回数を十分小さな数に制限するための保守的な値のように、安直に選択される。

代替的な実施形態として、閾値（開始値）は動的に選択され、かつ変更可能である。ここで、ハードウェア、ソフトウェアまたはそれらの組み合わせが、任意の特性（単数または複数）に基づいて初期開始値（閾値）を選択してもよい。たとえば、利用可能なキャッシュ・ラインまたはストア・バッファ・エントリーの数（たとえば32）を、当該コードの単一ループ反復工程におけるストアの数の計数（たとえば8）で割って、閾値（たとえば4）を決定する。複数のストアが単一のキャッシュ・ラインにタッチするだけのこともあるので、ストアの数の推定は、ある実施形態では、合理的な程度に保守的である。よって、より積極的な初期値が使用されてもよい。もう一つの例として、コードまたはハードウェアは、ループの実行が完遂するための十分な資源をもつことを保証するために、コード・サイズ／型、ハードウェア・ユニット・サイズ／型または他の既知の因子に基づいて積極的なまたは保守的な値を選択する。さらに、ハードウェアまたはソフトウェアはコードをプロファイリングしてもよく、開始／閾値を提供してもよい。ここで、ループの実行が始まる前に、閾値数を含むソフトウェア・ヒントが提供され、カウンタはその閾値数に基づいて設定される。あるいは、ハードウェアが同様にコードをプロファイリングして、コードのある領域のプロファイル履歴に基づいてカウンタを設定する。

ある実施形態では、カウンタを初期化したのち、閾値（開始値）は動的に修正される。たとえば、ループの実行解析（コード・プロファイリングまたはロールバック判別）に基づいて調整される。本質的には、ある実施形態では、ループ６１５の反復回数を推定するために使われているカウンタ６５０は、限られたハードウェア資源のためにロールバックが起こるまたは受け容れ可能な数のロールバックが起こる前に、実行することができる。したがって、受け容れ可能な数より多くのロールバックが起こると、コミットが起こるまでの反復工程数を減らすことによってロールバックの数を減らすために、以前の閾値は減らされる。このシナリオでは、あまりに頻繁なロールバックは実行時間を浪費し、潜在的に遅延を引き起こす。しかしながら、閾値があまりに保守的（まだ利用可能な資源がたっぷりあるときに早期にトランザクションを無思慮にコミットして、非効率的な原子的実行につながる）でないことを保証するために、ある実施形態では、ロールバックが実際に起こるまで閾値が増大させられる。インクリメント／デクリメントは単一の、複数のまたは指数的なきざみで行われうることを注意しておく。例として、開始値が初期に63に設定されるとする（すなわち、コミットまでに64回の反復工程が許容される）。ハードウェア制約条件に起因するいくつかのアボート／ロールバックが検出されたら、閾値は62にデクリメントされる。その後の諸ロールバックに際しては、実行が効率的に完了することが許容されるバランスの取れた開始値が決定されるまで、閾値はさらに2（60）、4（56）、8（48）などだけデクリメントされる。

図６の議論は、条件付きコミット命令に特に言及することなく、ループ反復回数を数えるカウンタを参照していたことを注意しておく。ここでは、カウンタが閾値に達することは、非同期的にハードウェアを通じてコミットを開始しうる。しかしながら、もう一つの実施形態では、カウンタ６５０は図５および図６からの条件付きコミット・コードと連携して作用する。例として、カウンタは、利用可能なハードウェア資源の量を判別／推定するハードウェア機構であってもよく、条件付きコミット命令はハードウェア・カウンタに基づいてコミット・コードへのジャンプを引き起こす。たとえば、カウンタ６５０が9に初期化されるとする（条件付きコミットが起こるまでに10回の反復工程が許容される）。ループ６１５の反復工程毎に、条件付きジャンプ命令のような条件付きコミット命令が実行されて、カウンタが満了していれば（ゼロに達していれば）分岐ターゲット・アドレスへのジャンプが行われる。10回目の反復工程が完了して条件付きジャンプが実行されるとき、実行フローは、実行中の原子的領域のコミットのためのターゲット・アドレスにジャンプする。

カウンタは個々のハードウェア・ユニットの厳密で個別的な使用レベル測定ではないが、潜在的にはより包括的な推定である。上記で論じたように、閾値の動的調整を通じて、ハードウェア制限に基づくロールバックを減らすための最適な反復工程回数が見出されてもよい。したがって、何らかの以前に同定されていないハードウェア制限がロールバックを引き起こしている場合、動的カウンタ閾値はそれを捕捉することができ、一方、設計者またはプログラマーによる個々の同定はそのような同定されていない原因を逃してしまうことがありうる。さらに、カウンタは個別的なハードウェア・ユニット利用度測定とともに利用されて、ユニット・レベルの粒度および広範なグローバル粒度の両方を提供してもよい。

先の議論は主として、ハードウェア資源が尽きる前にトランザクションを条件付きでコミットすることに焦点を当てていた。すなわち、実行をサポートするために十分な資源が利用可能であるかどうかを判定するために期待される利用度に対するハードウェア利用度を判別するのである。しかしながら、いくつかの実施形態では、原子的領域を通じて実行することが有利でありうる。そして定期的に（ユーザー命令、イベントまたはハードウェアで定義された時間に応答して）原子的領域のチェックポイントを作成するのである。よって、実際のハードウェア制限、例外、割り込みまたは他の障害に遭遇すると、原子的領域は最近の中間的なチェックポイントにロールバックされ、空いている資源にコミットされることができる。本質的には、先を見た推定をしてプロアクティブにトランザクションをコミットする代わりに、ある実施形態では、通常ならトランザクション全体のアボートおよび再開を必要とするような実際の資源の制限に遭遇したとき、トランザクションはサイズ変更されるだけである。これは、ロールバックが起こった場合にロールバックされるのが受け容れ可能な量の実行だけであることを保証するよう、トランザクション内で複数のチェックポイントを実行することによって達成される。

図７ａに目を転じると、トランザクション内の投機的チェックポイントのための備えをすることを含む、コード最適化方法の流れ図のある実施形態が描かれている。ブロック７０５では、最適化されるべきプログラム・コードのセクションが同定される。図２ａの議論と同様に、コードのセクション／領域の同定は、そのセクションに関するユーザーの同定／ヒント、プログラム解析、コード・プロファイリング、コード属性（特定の型、フォーマット、順序（order）または当該領域の特性――ループまたはストア回数）または最適化されるべきコード領域を同定するための他の既知の方法に基づいて行われてもよい。一例では、コードはバイナリー・コードを含む。バイナリー・コードの実行中、バイナリー・コードは動的に最適化される。結果として、実行のための最適化の間、バイナリー・コード中でループに遭遇する。よって、ロールバックが大量の実行の喪失につながらないほどチェックポイント間の距離が十分短くなることを保証するよう、そのループが最適化される（投機的チェックポイントが挿入される）ものと判別される。例として、下記の擬似コードFは最適化されるべきコード領域の例を示している。

図２ａの議論と同様に、フロー７１０、７１５において、コードの領域は区画される（当該セクションの始めに原子的領域開始命令を、当該セクションの終わりに原子的領域終了命令を挿入する）。上述したように、コード領域は複数の入口および複数の出口を含んでいてもよい。ブロック７２０において、プログラム・コード内の投機的チェックポイント位置が判別される。複数の投機的チェックポイントが最適化されるべきコードの領域内に判別／割り当てされてもよいことを注意しておく。ただし、議論の簡単のため、下記では一つのチェックポイントだけがより詳細に論じられる。

投機的チェックポイントの判別は、原子的領域内でのロールバック効果を最小限にするためのいかなる既知の割り当て／判別アルゴリズムに基づいていてもよい。第一の例として、反復工程のたびに投機的チェックポイントに遭遇するよう、ループ内に投機的チェックポイントが挿入される。ここで、投機的チェックポイントは、ループの始めまたはループの端に決定されてもよい。もう一つの例として、コードの動的プロファイリングは、しばしばハードウェア資源が使い尽くされる結果につながる、または高い命令計数をもつ実行経路を示す。よって、長い実行経路内でのアボートのために原子的領域全体をロールバックするのを避けるため、そのような実行経路に投機的チェックポイントが割り当てられる。同様に、独占するまたは資源要求がヘビーであると知られている実行経路に投機的チェックポイントが割り当てられてもよい。本質的には、従来技術の、トランザクション全体の前にあるチェックポイントおよびトランザクション全体の関連したロールバックの代わりに、トランザクション内のチェックポイント（ローカル、内部または一時的チェックポイント）を利用することによって、より小さなロールバック（無駄になる実行がより少ない）が実行される。結果として、より大きな領域が最適化されうる。資源制限に遭遇した場合には、小さなロールバックが実行される。さらに、ロールバック点において、トランザクションは潜在的にコミットされ、結果的な障害が対処され、もう一つのトランザクションが改めて開始される。

フロー７２５において、投機的チェックポイント位置に投機的チェックポイント・コードが挿入される。投機的チェックポイント・コードは、メモリ、キャッシュ・メモリおよび／またはレジスタ・ファイルのような投機的ハードウェア資源にチェックポイントを作成する。ある実施形態では、投機的チェックポイント・コードは、その後のアボート条件に応答してハードウェア資源をチェックポイントまで復元するためのコードをも含んでいてもよい。暫時図７ｂに目を転じると、投機的チェックポイント・コードを挿入するための流れ図のある実施形態が示されている。擬似コードGも、投機的チェックポイント・コードの挿入後のコードの例解用の例を描いている。

フロー７２６では、投機的チェックポイント（speculative checkpoint）（B2、B5のループバック端）において投機的チェックポイント命令／動作（B5におけるL1）が挿入される。ある実施形態では、投機的チェックポイント命令は、投機的ハードウェア資源のチェックポイント（現在のスナップショット）を開始する任意の命令を含む。たとえば、投機的チェックポイント命令は、プロセッサのデコーダによって認識可能である。そしてひとたびデコードされ、スケジュールされ、実行されたら、チェックポイント投機的レジスタ・ファイルおよび投機的キャッシュのようなチェックポイント記憶構造中に投機的レジスタ・ファイル、ストア・バッファまたは両方のチェックポイント（現在状態のスナップショット）を作成させる。

さらに、ある実施形態では、投機的チェックポイント・コードは、現在のロールバックを引き起こしたのと同じロールバック状況を潜在的に回避するよう何らかのアクションを実行する他の何らかのコードをも含む。たとえば、限られたハードウェア資源のためにロールバック（roll-back）が起こる場合、軽減アクションが行われなければ、同じハードウェア制限に毎回遭遇して、先に進めないことになりうる。

例として、擬似コードHの左側のコードが最適化されるものとする。

ここで、最適化されるコード内のロールバックにいかにして対処するかについて複数のシナリオがある。第一の例として、下記の擬似コードIに示されるように、投機的チェックポイント命令は、通常のループ実行か投機的チェックポイントへのロールバック後の再実行かの区別をすることができる条件付き（分岐）命令と対にされる。分岐命令が実行されると、前のチェックポイント作成された状態にロールバックするための任意の既知の仕方で、ロールバックを扱う異なる実行経路にジャンプする。

もう一つのシナリオでは、下記の擬似コードJに示されるように、投機的チェックポイント命令が、単一のチェックポイントへの分岐命令およびいくつかの実施形態においてすでに論じた分岐命令と組み合わされる。

擬似コードGの議論に戻ると、ある実施形態では、投機的チェックポイント（speculative checkpoint）・コードはフィックスアップ（fix-up）（ロールバック、復元、再構成、リカバリーなどとも称されうる）をも含む。これは、実行されたときに、チェックポイント記憶構造から最新のチェックポイントの正確な状態を復元または回復する。上記の他のシナリオも、いくつかの実施形態では、投機的チェックポイント・コードおよび／またはフィックスアップ・コードと考えられうることを注意しておく。それでも、ここでは、擬似コードGに示されるように、フィックスアップ・コードは、トランザクション／原子的領域をコミットするコミット・コード（B6）をも含んでいてもよい。投機的ハードウェアが尽きるかアボートを引き起こすイベント（割り込み、動的アサーション（dynamic assertion）、メモリ・エイリアス・チェックなど）に遭遇すると、チェックポイント・コードは投機的ハードウェアにおける正確な状態を復元する。さらに、投機的ハードウェアを再実行および継続される実行のために解放するため、トランザクションは任意的にコミットされる。この議論から、フィックスアップ・コードに達することは、複数の仕方でなされうることが見て取れる。例として、フィックスアップ・コードには：（１）チェックポイント記憶構造が投機的ハードウェアのチェックポイントを作成するための十分なスペースをもたない投機的チェックポイント動作の実行；（２）投機的ハードウェアが受け入れることができない投機的動作の実行；（３）投機的実行の間の例外；または（４）トランザクション内の一時的な内部チェックポイントへのロールバックにつながる他の任意のイベント、からはいることができる。

さらに、投機的チェックポイントは、条件付きコミットと組み合わされてもよい。これにより、投機的資源の欠如に起因するアボートを回避しつつ、チェックポイント作成のため障害、例外または他の予測不能な原因に起因するそのようなロールバック／アボートをずっと安価にする（原子的領域全体の始まりではなくチェックポイントに戻ることで無駄にされる実行が少なくなる）といったさらなる利益が得られる。下記の擬似コードKはそのような組み合わせの一例を描いている。

さらに、ある実施形態では、条件付きコミット命令が下記の擬似コードLに示されるように、投機的チェックポイントを知らされる。

この場合、領域チェック（region_check）（条件付きコミット）命令は、システムが資源を使い尽くそうとしている場合（上記のように）または実行が（実行が投機的チェックポイントにロールバックしたあとの）ロールバック・リプレーである場合にL2にジャンプする。

さらに、投機的チェックポイント（speculative checkpoint）および条件付きコミット命令が一緒に使用されうるのみならず、それらの命令自身も、ある実施形態では、下記の擬似コードMに描かれるように組み合わされる。

ここで、組み合わされた命令が実行されると、チェックポイントが実行され、条件付きコミットが評価される（資源のハードウェアが使い尽くされようとしているまたは残り少なくなる場合にコミットする）。ここで、システムの投機的資源が少なくなっている場合または記録された投機的チェックポイントに実行がロールバックする場合、実行はL2にジャンプし、（この例では）投機的資源をコミットして結果的な障害にサービスすることによってそれに対処する。

上記の議論は、ひとたびハードウェアが少なくなる、障害が検出される、例外が発生するまたは他の予測不能なイベントが割り込みを引き起こしたときの以前の（または最近の投機的な）チェックポイントへのロールバックに言及しているが、そのような割り込みに応答して他の経路が探求されてもよい。実際、ある実施形態では、割り込み時に、ハードウェア、ソフトウェアまたはそれらの組み合わせが、次に何をするかについての判断をする。たとえば、ハードウェア生成された障害／イベントのような障害が原子的実行の間に発生するとする。原子的実行は割り込まれる。そして、通常は、障害の型を決定し、障害にサービスするために制御はソフトウェアに渡される。

ここで、ハンドラのようなソフトウェアは、次に何をすべきかの決定を、障害の型、最も最近の投機的チェックポイントへのロールバックにおける難しさ、最も最近の投機的チェックポイントではなく最後のコミット点にロールバックすることによって失われる反復工程の回数または実行の量または戻りのためにプログラムにおいて実行の点を選択する際の他の既知の因子など、任意の数の因子に基づいて行ってもよい。本質的には、この例解用の例では、ハンドラのようなソフトウェアが、実行が原子的領域の始まり、原子的領域内の最後のコミット点または原子的領域内の最新の投機的チェックポイントのいずれにロールバックされるべきかどうかの決定をしている。これらの例はソフトウェアがその決定をすることに焦点を当ててきたが、ハードウェアがそのような決定をしてもよい。ある実施形態では、新しい命令（投機的ロールバック（speculative_rollback））がその決定をするのに利用される。ここで、投機的ロールバック命令は、ひとたびデコードされて実行されたらプログラム・コード中の適切な箇所（投機的チェックポイントまたは最近のコミット点）への戻りにつながる任意の情報を含む。

本稿に記載されるコードが、同じブロック、領域、プログラムまたはメモリ空間内で共位置である必要がないことに注意しておくことが重要である。実際、投機的チェックポイント動作は、主たるプログラム・コード内のループバック端に挿入されてもよい。そして直近のチェックポイントにロールバックし、任意的にはトランザクションをコミットするコードを含むフィックスアップ・コードは、ライブラリまたはコードの他の部分に位置していてもよい。ここで、主たるプログラム・コードが実行中である。そしてフィックスアップ・コードにはいろうとするとき、ロールバックおよびコミットを実行するために、ライブラリ・コードの一つまたは複数の関数への呼び出しが実行される。また、ソフトウェアの指令なしにハードウェアが同様のチェックポイント動作を実行してもよい。ここで、ハードウェアは、定期的にまたはイベント駆動の仕方で、投機的ハードウェアを透明にチェックポイント化する。そして投機的ハードウェアが使い尽くされるのに応答して、プロセッサは実行を最新のチェックポイントにロールバックし、トランザクションをコミットし、トランザクションを改めて開始し、チェックポイントとロールバック点との間の命令をリプレーする。ソフトウェアの観点からは、ハードウェアが資源制約および再実行のすべてを扱う間、実行は通常に続いてきている。それでも、ローカルな内部的トランザクション・チェックポイントを達成するために、ハードウェアとソフトウェアの間の任意のレベルの協調も使用されうる。

図７ａに戻ると、ブロック７３０において、プログラム・コードのセクションが最適化される。下記の擬似コードNは最適化後の擬似コードMからのコード領域の例を描いている。

最適化のもう一つの例として、下記の擬似コードOは最適化のもう一つの例（擬似コードGからのコード領域の最適化）を示している。

上記で論じたように、原子的領域内のコードに対していかなる既知の最適化技法が実行されてもよい。非網羅的なリストであり純粋に例示するものとして、コード最適化のいくつかの例を挙げておくと、ループ最適化、データ・フロー最適化、コード生成最適化、境界チェック消去（bounds checking elimination）、分岐オフセット最適化、デッド・コード消去およびジャンプ接続（jump threading）がある。擬似コードOでは、B6においてコミットしたのち、もう一つのトランザクションがB6において開始され、実行はB2において継続される。他の実施形態（図示せず）では、コードはB3において再入されてもよい。原子的領域の区画および条件付きコミット・コードの挿入は、いくつかの実施形態においてプログラム・コードを最適化すると考えられてもよい。

次に図８を参照するに、トランザクションの実行中にメモリを投機的にチェックポイント化する方法の流れ図のある実施形態が示されている。フロー８０５では、トランザクションが実行される。一例として、トランザクションは、ランタイムの間に動的に最適化されるバイナリー・コードになっている。トランザクションは原子性を保証するコード最適化のまわりに挿入される。

フロー８１０では、トランザクションからの投機的チェックポイント命令に遭遇する。投機的チェックポイント命令は、図７ａ〜ｂを参照して上記で論じたように、投機的チェックポイントにおいて最適化器によってランタイムの間に挿入されたものであってもよい。プロセッサは、投機的チェックポイント命令を（典型的にはあらかじめ指定された／定義された動作コードを検出するデコーダによって）認識する。そして投機的チェックポイント命令に応答して、フロー８１５において、投機的レジスタ・ファイルがチェックポイント（投機的）レジスタ・ファイルにおいてチェックポイント化される。さらに、フロー８２０において、投機的キャッシュがストア・バッファのチェックポイントを作成するための十分なスペースを含んでいるかどうかが判定される。もし十分なスペースが利用可能であれば、フロー８２５において、ストア・バッファは投機的キャッシュ内でチェックポイント作成される。しかしながら、十分なスペースがない場合には、フィックスアップ／ロールバック手順（下記でより詳細に論じるブロック８４５〜８５５）が実行される。

結果として、トランザクションの実行中に短期のロールバック・イベントが遭遇される場合、現在の実行に利用されている投機的なレジスタ・ファイルおよびストア・バッファはチェックポイント化された状態に復元されることができる。例として、フロー８３０では、ストア動作に遭遇する。フロー８３５では、ストア・バッファ（store buffer）が、ストア動作のために割り当てられるよう利用可能なエントリーなどの利用可能なエントリーを含むかどうかが判定される。すぐ利用可能なエントリーがあるか、割り当て解除されて再割り当てされうるエントリーがある場合には、ブロック８４０において、そのエントリーがそのように割り当てられる。しかしながら、利用可能なストア・バッファ・エントリーがない場合には、ロールバック手順（ブロック８４５〜８５５）が実行される。

ロールバック／リカバリー手順８４５〜８５５は、前のチェックポイントからの正確なアーキテクチャ状態を復元するものである。ここで、ロールバックは、コミットしていない（グローバルに可視にされていない）投機的実行の間のものである。したがって、グローバルに可視の状態（非投機的な記憶構造）は同じままに留まるべきである。しかしながら、現在の投機的実行をサポートする投機的なハードウェア構造は復元される。投機的キャッシュはすでに、ストア・バッファからの投機的更新を最も最近のチェックポイントまで保持しているので、ブロック８５０においてストア・バッファはフラッシュ（flush）される。換言すれば、トランザクションの始まりから最も最近のチェックポイントまでのストアは投機的なキャッシュ内に保持される。そして、最も最近のチェックポイントから現在の実行点（ロールバックの開始）までのストアがストア・バッファに保持される。よって、ロールバックされようとしているストアは単に、ストア・バッファから破棄される。

さらに、投機的レジスタ・ファイルがチェックポイント・レジスタ・ファイルから復元される。ここで、投機的レジスタ・ファイルは、最も最近のチェックポイントからのものを含め、トランザクションの開始からのすべての更新を保持する。よって、投機的レジスタ・ファイルは、チェックポイント・レジスタ・ファイルからの値を改めてロードされる。もとのチェックポイントが投機的レジスタ・ファイル全体のコピーを含む（投機的実行の間に修正されたレジスタのみを選択的に記憶するのではなく）場合、チェックポイント・レジスタ・ファイルは投機的レジスタ・ファイルとしてラベル変更（再利用）されてもよく、前の投機的レジスタ・ファイルはフラッシュされ、その後はチェックポイント・レジスタ・ファイルとして利用されてもよい。あるいは、投機的レジスタ・ファイルが投機的チェックポイント・レジスタ・ファイルに（一ないし数サイクルで）フラッシュ・コピーされてもよい。

フロー８６０では、トランザクションが任意的にコミットされうる。ロールバック手順に達するのは例外、投機的キャッシュにおけるスペースの欠如またはストア・バッファにおけるスペースの欠如に応答してなので、そうした資源を解放するためにそのトランザクションはコミットされてもよい。ここで、ストア・バッファおよび投機的キャッシュ更新は非投機的キャッシュ・メモリにコミットされて、それらの資源を解放する（フロー８７５〜８８０に示す）。そして同様に、投機的レジスタ・ファイルは非投機的レジスタ・ファイルにコミットされて、さらなる投機的実行のために解放される（フロー８７５〜８８０に示す）。さらに、トランザクションの完全なアボートが実行される（８６５）場合、ブロック８７０において、ストア・バッファおよび投機的キャッシュがフラッシュされて、トランザクション前の（非投機的）状態に復元される。

図９に目を転じると、投機的チェックポイント作成をサポートするよう適応されたハードウェアの論理的な表現のある実施形態が描かれている。デコーダ（デコード論理）９１０は、投機的チェックポイント命令（SCPI: speculative checkpoint instruction）９０５を認識するよう適応または相互接続される。たとえば、図９のハードウェアを含むプロセッサのための命令のあらかじめ定義されたフォーマットが、指定され、ハードウェア中に設計されていてもよい。そして特定のビット・パターンをもつ前記命令の一部分が、個別的な命令に対応する。その一つがSCPI ９０５である。

次いで、SCPIに応答して、投機的記憶構造に保持されている投機的な値９３５が、投機的チェックポイント記憶構造における投機的チェックポイント値９４０としてチェックポイント化される。SCPI ９２０を実行するために実行論理９２０がデコーダに結合されて示されていることを注意しておく。それでも、明らかに、デコードと実行の間にはパイプラインの多数の段階があることがしばしばである。たとえば、SCPIはトレース・キャッシュ内の動作のトレースにデコードされてもよく、それらの動作がバッファにおいて待ち行列化され、スケジュールされ、ディスパッチされ、実行されて、本稿で記載される動作／方法を実行してもよい。

上記で手短に述べたように、チェックポイントはある時点における値の状態のスナップショットまたはその時点における値のその状態を復元するための少なくとも十分な情報である。したがって、チェックポイントは、ある実施形態では、投機的な値９３５の全体のコピーを投機的チェックポイント値９４０として含む。ここで、投機的な値９３５は、投機的レジスタ・ファイルからの投機的レジスタ・ファイル値を含んでいてもよく、投機的チェックポイント値９４０は時間的に最も最近のチェックポイントにおける投機的レジスタ・ファイルのコピーを含む。もう一つの例として、投機的チェックポイント値は最後のチェックポイント以来修正されている投機的な値９３５のみを含む。ここでは、投機的な値９３５は、投機的レジスタ・ファイルからの投機的レジスタ・ファイル値を含んでいてもよく、投機的チェックポイント値は最後のチェックポイント以来修正されている投機的レジスタ・ファイル中のレジスタのみからの、最後のチェックポイントからの投機的レジスタ・ファイル値を含む。さらにもう一つの例では、投機的チェックポイント値９４０は原子的領域の始まりから時間的にあるチェックポイントまでの値のすべてを含み、一方、投機的な値９３５は該チェックポイントから現在の実行点までの投機的な値のすべてを含む。ここで、投機的な値９３５をストア・バッファが保持してもよく、これが投機的キャッシュに保持される（始まりから最後のチェックポイントまでの）古い値に加えられる。

図１０を参照するに、レジスタ・ファイルの投機的なチェックポイント作成をサポートするよう適応されたハードウェアの論理的な表現のもう一つの実施形態が描かれている。上記の議論と同様に、デコーダ１０１０および実行論理１０２はそれぞれSCPI １００５を受け取り、認識し、実行するよう適応される。SCPI １００５に応答して、投機的レジスタ・ファイル１０３５は投機的チェックポイント・レジスタ・ファイル１０４０中にチェックポイント化される。上述したように、チェックポイントはレジスタ・ファイル１０３５のチェックポイント・レジスタ・ファイル１０４０中へのフラッシュ・コピー（flash copy）を含んでいてもよい。あるいは、ファイル１０３５中のレジスタが修正されるとき、古い値がレジスタ・ファイル１０４０中にチェックポイント化される。ここで、SCPI １００５に応答して値をコピーする代わりに、ファイル１０３５における対応物の修正に際してコピーされたファイル１０４０からの古いチェックポイント値は、クリアされるか、無効であるとマークされる。実行が続けられるとき、修正されたレジスタは再びファイル１０４０中にチェックポイント化される。

（図８のブロック８２０におけるような投機的キャッシュにおけるスペースの欠如、図８のブロック８４０におけるようなストア・バッファにおけるスペースの欠如、例外または他のロールバック・イベントからの）最も最近のチェックポイントへのロールバックに応答して、チェックポイント値（修正されたものだけであれ完全なコピーであれ）は、投機的チェックポイント・レジスタ・ファイル１０４０から投機的レジスタ・ファイル１０３５中に復元される。しかしながら、トランザクションのアボートのように、トランザクション領域のまさに先頭へのロールバックがある場合には、投機的レジスタ・ファイル１０３５は、ある実施形態では、非投機的レジスタ・ファイル１０３０から再ロードされる。本質的には、投機的ファイル１０３５が、機能する投機的レジスタ・ファイルである。よって、トランザクションは投機的レジスタ・ファイル１０３５を用いて機能する（読み出しおよび書き込みを行う）。よって、トランザクションの先頭におけるロードが再実行される場合、非投機的な値が再ロードされなければ、ロードは期せずして、アボート前に投機的レジスタ・ファイル１０３５中に保持されていた、のちの修正された投機的な値をロードしてしまうことがありうる。

さらに、トランザクションのコミットに応答して、投機的レジスタ・ファイル１０３５が非投機的レジスタ・ファイル１０３０にコミットされる（コピーされる）。ここで、投機的な更新は、非投機的な結果としてグローバルに可視にされる。ここでもまた、レジスタ・ファイル１０３５全体が非投機的レジスタ・ファイル１０３０にコピーされてもよい。あるいは、投機的レジスタ・ファイル１０３５中の修正されたレジスタのみが非投機的レジスタ・ファイル１０３０にコピーされてもよい。

図１１に目を転じると、キャッシュ・メモリの投機的なチェックポイント化をサポートするよう適応されたハードウェアの論理的な表現のもう一つの実施形態が示されている。図９〜図１０についての上記と同様、デコーダ１１１０および実行論理１１２０はSCPI １１０５をデコードおよび実行するよう適応される。ここで、実行論理１１２０は、原子的領域からの投機的ストアを実行するとき、投機的な更新を保持するためにストア・バッファ１１４０を使う。前のストアからロードするその同じ領域（ローカル・スレッド）からのロードは、ストア・バッファ１１４０に保持されている投機的な値からロードすることを注意しておく。したがって、インフライト（in-flight）ストア機構の同様のロードが、ストア・バッファ１１４０と実行論理１１２０のロード実行ユニットとの間で利用されてもよい。しかしながら、ストア・バッファ１１４０におけるストアのアドレスへの非投機的または非ローカルなロードは、ストア・バッファ１１４０中の値ではなく、キャッシュ１１３０中に保持されている非投機的な値を受け取る。さらに、投機的キャッシュ１１３５にチェックポイント化されたまたは移されたストアのアドレスへの原子的領域からの読み出し／ロードがある場合、投機的キャッシュ値が、直接にまたはストア・バッファ１１４０を通じて、ロードに与えられるべきである。

SCPI １１０５に応答して、バッファ１１４０中のストア・バッファ更新は投機的キャッシュ１１３５に移される。結果として、投機的キャッシュ１１３５は原子的領域の先頭から最も現行のチェックポイントまでの投機的な更新を保持する。そして、ストア・バッファ１１４０がその最も現行のチェックポイントから現在の実行チェックポイントまでの投機的な更新を保持する。したがって、原子的領域のコミットに際して、投機的キャッシュ１１３５およびストア・バッファ１１４０内のすべての更新が非投機的キャッシュ１１３０にコミット／移動／コピーされる。図示したように、このコミットは、ストア・バッファ１１４０を投機的キャッシュ１１３５に、投機的キャッシュ１１３５を非投機的キャッシュ１１３０にコミットすることによって実行される。だが、ストア・バッファ１１４０および投機的キャッシュ１１３５の両方からの更新は、もう一つの実施形態では、非投機的キャッシュ１１３０に直接与えられる。コミット後、更新はグローバルに可視にされ、メモリ階層構造１１５０を通じて（より高位のメモリおよびホーム位置に）伝搬されてもよい。

さらに、最も最近のチェックポイントへのローカルな内部ロールバックに応答して、ストア・バッファ１１４０がフラッシュされる。上記のように、この実施形態では、ストア・バッファ１１４０は本質的には最も最近のチェックポイントから現在の実行点までの更新を保持する。よって、ロールバックの際、それらの更新は破棄される。一例では、ローカルなロールバックは、ストア・バッファ１１４０が原子的領域からの新しいストア動作を受け入れる（図８のブロック８４０）ことができないことに応答して開始されることがあることを注意しておく。そしてブロック８２０では、ロールバックは、投機的キャッシュ１１３５が満杯で、SCPI １１０５の際にストア・バッファ１１４０更新をキャッシュ記憶することができないことに応答して開始されることもありうる。それでも、アボート（原子的領域全体のロールバック）が発生するときは、ストア・バッファ１１４０および投機的キャッシュ１１３５の両方（原子的領域の先頭から現在の実行点までの更新）がフラッシュされる。

本稿で使用されるところのモジュールとは、任意のハードウェア、ソフトウェア、ファームウェアまたはそれらの組み合わせを指す。しばしば、別個のものとして図示されているモジュール境界が変わることも普通であり、潜在的には重なり合う。たとえば、第一および第二のモジュールがハードウェア、ソフトウェア、ファームウェアまたはそれらの組み合わせを共有し、一方で何らかの独立なハードウェア、ソフトウェアまたはファームウェアを保持することがある。ある実施形態では、論理という用語の使用は、ハードウェア、たとえばトランジスタ、レジスタまたはプログラム可能型論理デバイスのような他のハードウェアを含むが、別の実施形態では、論理はソフトウェアまたはファームウェアもしくはマイクロコードのようなハードウェアと統合されたコードをも含む。

本稿で使用されるところの値は、数、状態、論理状態または二値論理状態の任意の既知の表現を含む。しばしば、論理レベル、ロジック値または論理値の使用は1および0としても言及されるが、これは単に二値論理状態を表すものである。たとえば、1が高論理レベルを指し、0が低論理レベルを指す。ある実施形態では、トランジスタまたはフラッシュ・セルのような記憶セルが単一の論理値または複数の論理値を保持することができてもよい。しかしながら、コンピュータ・システムにおける値の他の表現が使用されてきた。たとえば、十進法の数10は二進法の値1010として表現されてもよく、十六進法の文字Aで表されてもよい。したがって、値は、コンピュータ・システムにおいて保持されることのできる情報の任意の表現を含む。

さらに、状態は値または値の一部によって表現されうる。例として、論理的な1のような第一の値がデフォルトまたは初期状態を表してもよく、論理的な0のような第二の値が非デフォルト状態を表してもよい。さらに、用語リセットおよびセットは、ある実施形態では、それぞれデフォルトおよび更新された値または状態を指す。たとえば、デフォルト値は潜在的に高い論理値、すなわちリセットを含み、更新された値は潜在的に低い論理値、即ちセットを含む。値のいかなる組み合わせがいかなる数の状態を表すために利用されてもよいことを注意しておく。

上記で述べた方法、ハードウェア、ソフトウェア、ファームウェアまたはコードの実施形態は、機械アクセス可能または機械可読媒体上に記憶された、処理要素によって実行可能な命令またはコードを介して実装されてもよい。機械アクセス可能／可読媒体は、コンピュータまたは電子システムのような機械によって読み取り可能な形で情報を与える（すなわち、記憶するおよび／または伝送する）任意の機構を含む。たとえば、機械アクセス可能媒体は静的RAM（SRAM）または動的RAM（DRAM）のようなランダム・アクセス・メモリ（RAM）；ROM；磁気または光学式記憶媒体；フラッシュメモリ・デバイス；電気的記憶デバイス；光学式記憶デバイス；音響記憶デバイス；伝搬される信号（たとえば、搬送波、赤外線信号、デジタル信号）を保持するための他の形の記憶デバイスなどを含む。

本明細書を通じた「一つの実施形態」または「ある実施形態」への言及は、その実施形態に関連して記述される特定の特徴、構造または特性が本発明の少なくとも一つの実施形態に含まれることを意味している。よって、本明細書を通じて随所に「一つの実施形態では」または「ある実施形態では」という句が現れるのは、必ずしもみなが同じ実施形態に言及しているわけではない。さらに、それら特定の特徴、構造または特性は一つまたは複数の実施形態においていかなる好適な仕方で組み合わされてもよい。

以上の明細書において、特定の例示的な実施形態に言及しつつ詳細に述べてきたが、付属の請求項に記載される本発明の広義の精神および範囲から外れることなくそれにさまざまな修正や変更をなしうることは明白であろう。よって、本明細書および図面は、制約する意味ではなく、例解する意味で見られるものである。さらに、実施形態および他の例示的な言辞の上記での使用は必ずしも同じ実施形態や同じ例を指すのではなく、異なる、区別される実施形態を指すことも、潜在的には同じ実施形態を指すこともある。

Claims (46)

1. コードを含む機械可読媒体であって、前記コードは、前記機械によって実行されたときに、前記機械に：
   最適化されるべきプログラム・コードのセクションを同定する動作と；
   前記プログラム・コードの前記セクション内の条件付きコミット点を決定する動作と；
   前記条件付きコミット点を決定することに応答して前記条件付きコミット点において条件付きコミット命令を挿入する動作と；
   最適化されるべきプログラム・コードの前記セクションを同定することに応答してプログラム・コードの前記セクションを最適化する動作とを実行させる、
   機械可読媒体。
2. 最適化されるべきプログラム・コードのセクションを同定する動作が、前記プログラム・コードの動的プロファイリングに基づき、条件付きコミット点を決定する動作が、前記プログラム・コードの前記セクション内のループの先頭に前記条件付きコミット点を割り当てる、動的プロファイリングに基づいてある実行経路に前記条件付きコミット点を割り当てる、およびハードウェア資源を独占すると知られている実行経路に前記条件付きコミット点を割り当てる、からなる群より選択される割り当てアルゴリズムに基づく、請求項１記載の機械可読媒体。
3. 前記条件付きコミット命令が、実行されたときに、第一の分枝として、プログラム・コードの前記セクションの実行を継続する、または、第二の分枝として、条件付きコミット・コード位置にジャンプする条件付き分岐命令を含む、請求項１記載の機械可読媒体。
4. 前記コードが、前記機械によって実行されたときに、前記機械にさらに：
   プログラム・コードの前記セクションの先頭に第一の領域開始命令を挿入する動作と；
   プログラム・コードの前記セクションの末尾に第一のコミット命令を挿入する動作と；
   前記条件付きコミット・コード位置に第二のコミット命令を挿入する動作と；
   前記第二のコミット命令後に、前記条件付きコミット・コード位置における第二の領域開始命令を挿入する動作とを実行させる、
   請求項３記載の機械可読媒体。
5. プログラム・コードの前記セクションを最適化する動作が、前記第一および第二の領域開始命令より上にメモリ順序付けを破るロードを持ち上げることなく、かつ前記第一および第二のコミット命令より下にメモリ順序付けを破るストアを押し出すこともなく、コードの前記セクションを動的に最適化することを含む、請求項４記載の機械可読媒体。
6. ランタイムの間にコードを動的に最適化する方法であって：
   最適化されるべきプログラム・コードのセクションを同定する段階と；
   最適化されるべきプログラム・コードの前記セクションを同定することに応答して、プログラム・コードの前記セクションの少なくとも一部を原子的領域として画定する段階と；
   前記原子的領域内の条件付きコミット点を決定する段階と；
   前記条件付きコミット点を決定することに応答して前記条件付きコミット点において領域チェック命令を挿入する段階と；
   最適化されるべきプログラム・コードの前記セクションを同定することに応答してプログラム・コードの前記セクションを最適化する段階とを含む、
   方法。
7. プログラム・コードの前記セクションの少なくとも一部を原子的領域として画定する段階が、コードの前記セクションの前記一部の先頭に開始トランザクション命令を、コードの前記セクションの前記一部の末尾に終了トランザクション命令を挿入することを含む、請求項６記載の方法。
8. プログラム・コードの前記セクションを最適化する段階が、部分冗長性ロード消去（PRLE）、部分デッド・ストア消去（PDSE）、ループ最適化、データ・フロー最適化、コード生成最適化、境界チェック消去、分岐オフセット最適化、デッド・コード消去およびジャンプ接続からなる群より選択される最適化技法を利用してコードの前記セクションを最適化することを含む、請求項６記載の方法。
9. 前記領域チェック命令が、実行されたときにハードウェアに問い合わせする条件付き分岐命令を含み、前記条件付き分岐命令は、前記ハードウェアの前記問い合わせへのあらかじめ定義された応答に応答して、早発（premature）領域コミット命令および領域再開命令に分岐するものである、請求項６記載の方法。
10. 前記領域チェック命令を挿入する段階が、前記プログラム・コードの前記セクションの前記一部の中のループの先頭において行われ、前記領域チェック命令は前記ループの反復工程毎に実行される、請求項６記載の方法。
11. コードを含む機械可読媒体であって、前記コードは、前記機械によって実行されたときに、前記機械に：
    動的に最適化されたプログラム・コードを含むトランザクションを実行する動作と；
    前記トランザクションの終わりより前の領域チェック点において、前記トランザクションの実行をサポートするハードウェア・ユニットが前記トランザクションのある領域を完遂するための利用可能な十分な資源を含んでいるかどうかを判定する動作と；
    前記トランザクションの実行をサポートするハードウェア・ユニットの資源が少ないと判定することに応答して前記領域チェック点において前記トランザクションをコミットする動作とを実行させる、
    機械可読媒体。
12. 前記領域チェック点において前記トランザクションをコミットしたあと新たなトランザクションを開始することをさらに含む、請求項１１記載の機械可読媒体。
13. 前記ハードウェア・ユニットが、ストア・バッファ、ロード・バッファ、キャッシュ・メモリおよびレジスタ・ファイルからなる群より選択されるユニットを含む、請求項１１記載の機械可読媒体。
14. 前記ハードウェア・ユニットがキャッシュ・メモリを含む請求項１１記載の機械可読媒体であって、前記トランザクションの実行をサポートするハードウェア・ユニットが前記トランザクションの前記領域を完遂するための利用可能な十分な資源を含んでいるかどうかを判定する動作が：前記トランザクションの前記領域を完遂することにおいてタッチされると期待されるキャッシュ・ラインの数を決定し；前記キャッシュ・メモリ中の利用可能なエントリーの数を決定し；期待されるキャッシュ・ラインの数を利用可能なキャッシュ・ラインの数と比較し；前記トランザクションの実行をサポートする前記キャッシュ・メモリが前記トランザクションの前記領域を完遂するための利用可能な十分な資源を含むかどうかを、期待されるキャッシュ・ラインの数と利用可能なキャッシュ・ラインの数との前記比較に基づいて、判定することを含む、機械可読媒体。
15. 前記領域を完遂することにおいてタッチされると期待されるキャッシュ・ラインの数を決定することが、前記トランザクションに挿入されたコンパイラ・ヒントに基づき、前記コンパイラ・ヒントは、前記トランザクションの前記領域の以前の実行の動的プロファイリングに基づく、請求項１４記載の機械可読媒体。
16. コードを含む機械可読媒体であって、前記コードは、前記機械によって実行されたときに、前記機械に：
    最適化されるべきプログラム・コードのセクションを同定する段階と；
    前記プログラム・コードの前記セクション内の投機的チェックポイントを決定する段階と；
    前記投機的チェックポイントを決定することに応答して前記投機的チェックポイントにおいて投機的チェックポイント・コードを挿入する動作と；
    最適化されるべきプログラム・コードの前記セクションを同定することに応答してプログラム・コードの前記セクションを最適化する動作とを実行させる、
    機械可読媒体。
17. 最適化されるべきプログラム・コードのセクションを同定する動作が、前記プログラム・コードの動的プロファイリングに基づき、投機的チェックポイントを決定する動作が、前記プログラム・コードの前記セクション内のループの先頭に、前記プログラム・コードの前記セクション内のループのループバック端に前記投機的チェックポイントを割り当てる、動的プロファイリングに基づいてある実行経路に前記投機的チェックポイントを割り当てる、ハードウェア資源を独占すると知られている実行経路に前記投機的チェックポイントを割り当てる、および、投機的ハードウェア資源の枯渇を回避するよう実行経路に前記投機的チェックポイントを割り当てる、からなる群より選択される割り当てアルゴリズムに基づく、請求項１６記載の機械可読媒体。
18. 前記コードが、前記機械によって実行されたときに、前記機械にさらに：
    プログラム・コードの前記セクションに原子的領域開始命令を挿入する動作と；
    プログラム・コードの前記セクションに原子的領域終了命令を挿入する動作とをさらに実行させる、
    請求項１６記載の機械可読媒体。
19. 前記投機的チェックポイント・コードが投機的チェックポイント動作を含み、前記投機的チェックポイント動作は、実行されたときに、前記機械に、投機的レジスタ・ファイルおよびストア・バッファをチェックポイント記憶構造においてチェックポイント化させ、前記コードは、前記機械によって実行されたとき、前記機械に、コードの前記セクションの実行中に前記ストア・バッファの資源が尽きることに応答して前記投機的レジスタ・ファイルの前記チェックポイントにロールバックするフィックスアップ・コードを挿入する動作をさらに実行させる、請求項１６記載の機械可読媒体。
20. プログラム・コードの前記セクションを最適化する動作が、部分冗長性ロード消去（PRLE）、部分デッド・ストア消去（PDSE）、ループ最適化、データ・フロー最適化、コード生成最適化、境界チェック消去、分岐オフセット最適化、デッド・コード消去およびジャンプ接続からなる群より選択される最適化技法を利用してコードの前記セクションを最適化することを含む、請求項１６記載の機械可読媒体。
21. 最適化されるべきプログラム・コードのセクションを同定する段階と；
    最適化されるべきプログラム・コードの前記セクションを同定することに応答して、プログラム・コードの前記セクションの少なくとも一部を原子的領域として画定する段階と；
    前記原子的領域内の投機的チェックポイントを決定する段階と；
    前記投機的チェックポイントを決定することに応答して前記投機的チェックポイントにおいて投機的チェックポイント・コードを挿入する段階と；
    最適化されるべきプログラム・コードの前記セクションを同定することに応答してプログラム・コードの前記セクションを最適化する段階とを含む、
    方法。
22. プログラム・コードの前記セクションの少なくとも一部を原子的領域として画定する段階が、コードの前記セクションの前記一部の先頭に開始トランザクション命令を、コードの前記セクションの前記一部の末尾に終了トランザクション命令を挿入することを含む、請求項２１記載の方法。
23. 投機的チェックポイント動作を実行する段階と；
    前記投機的チェックポイント動作の実行に応答して、投機的レジスタ・ファイルを投機的チェックポイント・レジスタ・ファイルにおいてチェックポイント化する段階と；
    前記投機的チェックポイント動作の実行に応答して、ストア・バッファを投機的キャッシュにおいてチェックポイント化する段階と；
    コードの前記セクションの前記一部の実行中に前記投機的キャッシュまたは前記ストア・バッファの資源が尽きることに応答して前記投機的チェックポイント・レジスタ・ファイルに保持されている前記投機的レジスタ・ファイルの前記チェックポイントにロールバックするフィックスアップ・コードを挿入する段階とをさらに含む、
    請求項２１記載の方法。
24. コードの前記セクションの前記一部の実行中に前記ストア・バッファの資源が尽きることに応答して前記フィックスアップ・コードを挿入することは：前記ストア・バッファがコードの前記セクションの前記一部の実行の間に利用可能なエントリーを全く含まないことに応答して前記フィックスアップ・コードを挿入することを含み、
    コードの前記セクションの前記一部の実行中に前記投機的キャッシュの資源が尽きることに応答して前記フィックスアップ・コードを挿入することは：前記投機的キャッシュが、前記投機的チェックポイント動作の実行の際に前記ストア・バッファからのエントリーを保持するための十分な利用可能なエントリーを含まないことに応答して前記フィックスアップ・コードを挿入することを含む、
    請求項２３記載の方法。
25. プログラム・コードの前記セクションを最適化する動作が、部分冗長性ロード消去（PRLE）、部分デッド・ストア消去（PDSE）、ループ最適化、データ・フロー最適化、コード生成最適化、境界チェック消去、分岐オフセット最適化、デッド・コード消去およびジャンプ接続からなる群より選択される最適化技法によりコードの前記セクションを最適化することを含む、請求項２１記載の方法。
26. コードを含む機械可読媒体であって、前記コードは、前記機械によって実行されたときに、前記機械に：
    動的に最適化されたプログラム・コードを含むトランザクションを実行する動作と；
    前記トランザクション内のチェックポイントにおいて、投機的レジスタ・ファイルをチェックポイント・レジスタ・ファイル中にチェックポイント化する動作と；
    前記トランザクションの実行をサポートするハードウェア・ユニットの資源が少ないことを判別する動作と；
    前記ハードウェア・ユニットの資源が少ないことを判別することに応答して前記チェックポイント・レジスタ・ファイルを前記投機的レジスタ・ファイル中に復元し、ストア・バッファをフラッシュする動作とを実行させる、
    機械可読媒体。
27. 前記トランザクション内のチェックポイントにおいて、投機的レジスタ・ファイルをチェックポイント・レジスタ・ファイル中にチェックポイント化する動作が、投機的チェックポイント命令の実行に応答して行われ、前記コードは、前記機械によって実行されたとき、前記機械に、やはり投機的チェックポイント命令の実行に応答して、前記トランザクション内の前記チェックポイントにおいて、ストア・バッファを投機的キャッシュ中にチェックポイント化する動作をさらに実行させる、請求項２６記載の機械可読媒体。
28. 前記ハードウェア・ユニットが前記ストア・バッファを含み、前記トランザクションの実行をサポートするハードウェア・ユニットの資源が少ないことを判別する動作が、前記トランザクションからのストアに遭遇する際に前記ストア・バッファの資源が少なく、前記ストア・バッファが利用可能なストア・バッファ・エントリーを含まないことを判別することを含む、請求項２７記載の機械可読媒体。
29. 前記ハードウェア・ユニットが投機的キャッシュをも含み、前記トランザクションの実行をサポートするハードウェア・ユニットの資源が少ないことを判別する動作が、
    やはり投機的チェックポイント命令の実行に応答して、前記トランザクション内の前記チェックポイントにおいて、前記ストア・バッファを前記投機的キャッシュ中にチェックポイント化する際に、
    前記ストア・バッファからのエントリーを保持するために十分な利用可能なエントリーを前記投機的キャッシュが含まないことに応答して、
    前記投機的キャッシュの資源が少ないことを判別することを含む、請求項２８記載の機械可読媒体。
30. 前記コードが、前記機械によって実行されたとき、前記機械に、前記ハードウェア・ユニットの資源が少ないことを判別することに応答して前記チェックポイント・レジスタ・ファイルを前記投機的レジスタ・ファイル中に復元し、前記ストア・バッファをフラッシュすることに応答して、前記トランザクションの一部の領域コミットを実行する動作を実行させる、請求項２６記載の機械可読媒体。
31. 前記ハードウェア・ユニットの資源が少ないことを判別することに応答して前記チェックポイント・レジスタ・ファイルを前記投機的レジスタ・ファイル中に復元し、前記ストア・バッファをフラッシュする動作が：前記ハードウェア・ユニットの資源が少ないことを判別し、前記ハードウェア・ユニットに関連する因子に基づいて、前記復元が、最も最近のコミットされた点ではなく前記チェックポイント・レジスタ・ファイルに関連するチェックポイントまでであることを判別するコードを実行し、前記復元が前記チェックポイント・レジスタ・ファイルに関連する前記チェックポイントまでであることを判別するのに応答して、前記チェックポイント・レジスタ・ファイルを前記投機的レジスタ・ファイル中に復元し、前記ストア・バッファをフラッシュすることを含む、請求項２６記載の機械可読媒体。
32. 投機的チェックポイント命令をデコードしてデコードされた投機的チェックポイント命令を得るよう適応されたデコード論理と；
    デコードされた投機的チェックポイント命令を実行するよう適応された実行論理と；
    最適化されたコードを含むことになるソフトウェア・スレッドの原子的領域の開始前から前記ソフトウェア・スレッドに関連付けられた非投機的な値を保持するよう適応された第一のメモリと；
    前記原子的領域の実行中および前記デコードされた投機的チェックポイント命令が前記実行論理によって実行されたあとに、前記ソフトウェア・スレッドに関連付けられた投機的な値を保持するよう適応された第二のメモリと；
    前記実行論理が前記デコードされた投機的チェックポイント命令を実行するのに応答して前記第二のメモリからの投機的チェックポイント値を保持するよう適応された第三のメモリとを有する、
    装置。
33. 前記第一のメモリが非投機的レジスタ・ファイルを含み、前記第二のメモリが投機的レジスタ・ファイルを含み、前記第三のメモリが投機的チェックポイント・レジスタ・ファイルを含む、請求項３２記載の装置。
34. 前記投機的レジスタ・ファイルが前記原子的領域の実行中および前記デコードされた投機的チェックポイント命令が前記実行論理によって実行されたあとに、前記ソフトウェア・スレッドに関連付けられた投機的な値を保持するよう適応されていることが、前記投機的レジスタ・ファイルが、前記原子的領域の実行中および前記デコードされた投機的チェックポイント命令が前記実行論理によって実行されたあとに、前記ソフトウェア・スレッドに関連付けられた投機的アーキテクチャ状態値を保持するよう適応されていることを含み、
    前記投機的チェックポイント・レジスタ・ファイルが前記実行論理が前記デコードされた投機的チェックポイント命令を実行するのに応答して前記投機的レジスタ・ファイルからの投機的チェックポイント値を保持するよう適応されていることが、前記投機的チェックポイント・レジスタ・ファイルが、前記実行論理が前記投機的レジスタ・ファイルからの前記投機的チェックポイント命令を実行する際に、前記ソフトウェア・スレッドに関連付けられたアーキテクチャ状態値を、投機的チェックポイント・アーキテクチャ状態値として前記投機的チェックポイント・レジスタ・ファイル中にロードするよう適応されていることを含む、
    請求項３３記載の装置。
35. 不十分なハードウェア資源に基づく、前記投機的チェックポイント命令に関連付けられたチェックポイントへのロールバックに応答して、前記投機的チェックポイント・レジスタ・ファイル中に保持される前記投機的チェックポイント・アーキテクチャ状態値が前記投機的レジスタ・ファイル中に再ロードされ；
    前記原子的領域のコミットに応答して、前記投機的レジスタ・ファイル中に保持される前記投機的アーキテクチャ状態値が前記非投機的レジスタ・ファイル中にロードされ；
    前記原子的領域の始まりへのロールバックに応答して、前記非投機的レジスタ・ファイル中に保持される前記非投機的な値が、前記投機的レジスタ・ファイル中にロードされる、
    請求項３４記載の装置。
36. 前記第一のメモリがキャッシュ・メモリを含み、前記第二のメモリがバッファを含み、前記第三のメモリが投機的キャッシュ・メモリを含む、請求項３２記載の装置。
37. 前記バッファが前記原子的領域の実行中および前記デコードされた投機的チェックポイント命令が前記実行論理によって実行されたあとに、前記ソフトウェア・スレッドに関連付けられた投機的な値を保持するよう適応されていることが、前記バッファが、前記原子的領域の実行中および前記デコードされた投機的チェックポイント命令が前記実行論理によって実行されたあとに、前記ソフトウェア・スレッドに関連付けられた投機的なメモリ値を保持するよう適応されていることを含み、
    前記投機的キャッシュ・メモリが前記実行論理が前記デコードされた投機的チェックポイント命令を実行するのに応答して前記バッファからの投機的チェックポイント値を保持するよう適応されていることが、前記投機的キャッシュ・メモリが、前記実行論理が前記バッファからの前記投機的チェックポイント命令を実行する際に、前記ソフトウェア・スレッドに関連付けられた投機的なメモリ値を、投機的チェックポイント・メモリ値として前記投機的キャッシュ・メモリ中にロードするよう適応されていることを含む、
    請求項３６記載の装置。
38. 前記原子的領域のコミットに応答して、前記バッファおよび前記投機的キャッシュ・メモリが、前記投機的なメモリ値および前記投機的チェックポイント・メモリ値を前記キャッシュ・メモリ中にロードするよう適応されており；
    前記投機的チェックポイント命令に関連付けられたチェックポイントへのロールバックに応答して、前記バッファがフラッシュされるよう適応されており；
    前記原子的領域より前の点へのロールバックに応答して、前記バッファおよび前記投機的キャッシュ・メモリがフラッシュされるよう適応されている、
    請求項３７記載の装置。
39. 前記デコード論理、実行論理、第一のメモリ、第二のメモリおよび第三のメモリが複数処理要素のマイクロプロセッサ内に含まれており、前記複数処理要素のマイクロプロセッサは、同期的動的ランダム・アクセス・メモリ（SDRAM：Synchronous Dynamic Random Access Memory）、読み出し専用メモリ（ROM）およびフラッシュメモリからなる群より選択されるシステム・メモリを含むコンピュータ・システム内に結合されるよう適応されている、請求項３２記載の装置。
40. 投機的チェックポイント命令をデコードしてデコードされた投機的チェックポイント命令を得るよう適応されたデコード論理と；
    デコードされた投機的チェックポイント命令を実行するよう適応された実行論理と；
    原子的領域の実行中の投機的更新を保持するよう適応されたストア・バッファと；
    前記実行論理が前記デコードされた投機的チェックポイント命令を実行するのに応答して前記ストア・バッファからの前記投機的更新をチェックポイント化するよう適応された投機的キャッシュと；
    前記原子的領域の始まりより前からの非投機的な値を保持するよう適応された非投機的キャッシュとを有しており、
    前記原子的領域のコミットに応答して、前記投機的キャッシュからの前記投機的更新が前記非投機的キャッシュ中にロードされる、
    装置。
41. 前記投機的キャッシュおよび前記ストア・バッファが、前記原子的領域のコミットに応答して、投機的更新をもって前記非投機的キャッシュを更新するようさらに適応されている、請求項４０記載の装置。
42. 前記ストア・バッファがさらに、前記投機的チェックポイント命令に関連付けられたチェックポイントへのロールバックまたは前記原子的領域の始まりへのロールバックに応答してフラッシュされるよう適応されている、請求項４０記載の装置。
43. 前記投機的キャッシュがさらに、前記原子的領域の始まりへのロールバックに応答してフラッシュされるよう適応されている、請求項４２記載の装置。
44. 前記投機的キャッシュがさらに、前記投機的キャッシュが前記ストア・バッファからの前記投機的更新を保持するための十分なエントリーを含まないことに応答して、前記ストア・バッファからの前記投機的更新の前記チェックポイントを完遂するために十分な投機的キャッシュ・エントリーが利用可能でないことを示すよう適応されており；
    前記ストア・バッファがさらに、前記原子的領域からのストアに遭遇する際にストア・バッファ・エントリーが利用可能でないことに応答して、ストア・バッファ・エントリーが利用可能でないことを示すよう適応されており；
    前記原子的領域内のチェックポイントへのロールバックは、前記投機的キャッシュが、前記ストア・バッファからの前記投機的更新の前記チェックポイントを完遂するために十分な投機的キャッシュ・エントリーが利用可能でないことを示すこと、または、前記ストア・バッファが、前記原子的領域からのストアに遭遇する際にストア・バッファ・エントリーが利用可能でないことに応答して、ストア・バッファ・エントリーが利用可能でないことを示すことに応答して開始される、
    請求項４３記載の装置。
45. 前記非投機的キャッシュがさらに、前記原子的領域からの投機的読み出しに応答してロード・バッファにエントリーを与えるよう適応されている、請求項４２記載の装置。
46. 前記非投機的キャッシュがより上位レベルのメモリからのラインをキャッシュするよう適応されており、前記より上位レベルのメモリは：同期的動的ランダム・アクセス・メモリ（SDRAM：Synchronous Dynamic Random Access Memory）、読み出し専用メモリ（ROM）およびフラッシュメモリからなる群より選択される、請求項４２記載の装置。

Images