"コードを最適化する装置であって、プログラムコードを保持するメモリと、プロセッサとを備え、前記プロセッサが、トランザクション実行をサポートし、ハードウェアリソースの利用可能性の表現を提供する前記ハードウェアリソースと、前記プログラムコードを実行して、前記ハードウェアリソースの利用可能性の表現に基づいて、前記プログラムコードの最適化された部分を含むトランザクション領域のサイズを前記プロセッサに動的に変更させる実行論理とを有する装置。前記プログラムコードを実行して、前記ハードウェアリソースの利用可能性の表現に基づいて、アプリケーションコードの最適化された部分を含むトランザクション領域のサイズを前記プロセッサに動的に変更させる前記実行論理は、前記プログラムコード内の、前記トランザクション領域の末尾の前の条件コミット命令を実行する実行論理を有し、前記条件コミット命令は、前記ハードウェアリソースの利用可能性の表現が、前記トランザクション領域の実行を完了させるには不十分なことを示している場合、前記トランザクション領域の末尾の前に前記トランザクションをコミットさせるものである、請求項1に記載の装置。前記メモリに動的最適化コードを保持するよう適合されており、前記実行論理はさらに、前記動的最適化コードを実行して、ランタイム中に前記トランザクション領域の末尾の前に前記条件コミット命令を挿入することを含む前記コードの一部の最適化により、前記プログラムコードの前記最適化された一部を取得する、請求項2に記載の装置。前記ハードウェアリソースの利用可能性の表現に基づいて、アプリケーションコードの最適化された部分を含むトランザクション領域のサイズを前記プロセッサに動的に変更させるよう、前記プログラムコードを実行する実行論理は、前記トランザクション領域からトランザクション書き込みを実行する実行論理を有し、前記トランザクション領域は、前記トランザクション書き込みでハードウェア格納バッファがオーバフローすると、最近のチェックポイントにロールバックされて、コミットされる、請求項1に記載の装置。前記メモリは、オンプロセッサキャッシュメモリ、前記プロセッサに直接連結されたシステムメモリ、および、前記プロセッサに間接的に連結されたシステムメモリからなる群から選択される、請求項1に記載の装置。トランザクションに関する領域チェック命令をデコードするデコード論理と、前記トランザクションの実行をサポートするハードウェアとを備える装置であって、前記ハードウェアはさらに、前記デコード論理が前記領域チェック命令をデコードすると、ハードウェア利用メトリックの表現を利用メトリック格納エレメントに提供し、前記利用メトリック格納エレメントは、前記トランザクションの条件コミットが前記トランザクションの終了の前に実行されるべきかを判断する際に利用される、装置。前記ハードウェアは、投機的キャッシュメモリ、格納バッファ、投機的レジスタファイル、および投機的チェックポイントレジスタファイルからなる群から選択される、請求項請求項6に記載の装置。前記領域チェック命令は、利用予想メトリックの表現を含み、前記トランザクションの条件コミットが前記トランザクションの終了前に実行されるべきかを判断する際に利用される前記利用メトリック格納エレメントは、前記利用予想メトリックの表現を、前記利用メトリック格納エレメントに提供される前記ハードウェア利用メトリックの表現と比較して、利用比較結果を得て、前記利用比較結果に基づいて前記トランザクションの条件コミットを前記トランザクションの終了前に実行すべきかを判断するハードウェアを有する、請求項6に記載の装置。前記領域チェック命令はさらに、分岐対象アドレスを含み、前記ハードウェアは、予め定義されたアルゴリズムを利用して前記利用比較結果に基づいて前記トランザクションの終了前に前記トランザクションの条件コミットを行うかを判断し、前記予め定義されたアルゴリズムを利用して前記利用比較結果に基づいて前記トランザクションの終了前に前記トランザクションの条件コミットを行うと判断されると、実行が前記分岐対象アドレスにジャンプする、請求項8に記載の装置。前記ハードウェアは、予め定義されたアルゴリズムを利用して前記利用比較結果に基づいて前記トランザクションの終了前に前記トランザクションの条件コミットを行うかを判断し、前記トランザクションに関する条件コードに予め定義されたアルゴリズムを利用して前記利用比較結果に基づいて前記トランザクションの終了前に前記トランザクションの条件コミットを行うかの判断を表し、前記条件コードは、実行されると、前記ハードウェアが前記トランザクションの終了前に前記トランザクションの条件コミットを行うという表現を表したことに応じて、条件コミット分岐アドレスにジャンプし、前記トランザクションにコミットし、新たなトランザクションを開始する、請求項8に記載の装置。前記利用メトリック格納エレメントは、前記トランザクションに関する条件コードによって読み出されるレジスタを含み、前記条件コードは、実行されると、ハードウェアのソフトウェア予想利用メトリックとの比較で前記ハードウェア利用メトリックを評価して、前記ソフトウェア予想利用メトリックとの比較における前記ハードウェア利用メトリックの評価に基づいて、前記トランザクションの終了前に前記トランザクションの条件コミットを行うかを判断する、請求項6に記載の装置。前記条件コードは、実行されると、前記ソフトウェア予想利用メトリックとの比較における前記ハードウェア利用メトリックの評価に基づいて、前記トランザクションの終了前に前記トランザクションの条件コミットを行うと判断されると、さらに、コミット経路にジャンプして、前記トランザクションの終了前に前記トランザクションにコミットして、新たなトランザクションを開始する、請求項11に記載の装置。トランザクションの条件コミット点に関しており、宛先アドレスを参照する条件コミット命令をデコードするデコード論理と、前記デコード論理が前記条件コミット命令をデコードすると、ハードウェアリソースが前記トランザクションのある領域の実行をサポートするために利用可能なスペースを十分含んでいるかを判断し、前記ハードウェアが前記トランザクションの前記領域の実行をサポートするために利用可能なスペースを十分含んでいないと判断すると、前記宛先アドレスにジャンプ実行するハードウェアとを備える装置。前記ハードウェアリソースはメモリデバイスを有し、前記ハードウェアは、さらに、前記トランザクションの第2の条件コミット点の前に利用が予想されるエントリ数と、前記メモリデバイスにおける利用可能なエントリ数とに基づいて、前記トランザクションの前記領域の実行をサポートするために利用可能なスペースを前記メモリデバイスが十分含んでいるかを判断し、前記ハードウェアは、前記利用可能なエントリ数が前記予想されるエントリ数より少ない場合に、前記メモリデバイスが前記トランザクションの前記領域の実行をサポートするために利用可能なスペースを十分含んでいないと判断する、請求項13に記載の装置。前記条件コミット命令は、さらに、前記トランザクションで前記第2の条件コミット点の前に利用されることが予想される前記エントリ数を参照する、請求項14に記載の装置。アトミック領域の末尾の前に条件コミット命令を含む最適化されたコードを有する前記アトミック領域を含むプログラムコードを保持するメモリと、前記メモリに連結されたプロセッサとを備えるシステムであって、前記プロセッサは、前記コミット命令を認識するデコード論理と、前記条件コミット命令を前記デコード論理が認識すると、前記アトミック領域の末尾の前に前記アトミック領域にコミットする必要があるかを判断するハードウェアとを有する、システム。前記条件コミット命令を前記デコード論理が認識すると、前記アトミック領域の末尾の前に前記アトミック領域にコミットする必要があるかを判断する前記ハードウェアは、前記アトミック領域を実行するために利用される前記プロセッサの利用可能なハードウェアリソースの量を追跡して、前記アトミック領域の一部を実行する際の前記ハードウェアリソースの利用予想量を判断して、前記利用可能なハードウェアリソースの量が前記ハードウェアリソースの利用予想量より少ない場合には、前記アトミック領域の末尾の前に前記アトミック領域をコミットすべきであると判断する、請求項16に記載のシステム。前記条件コミット命令は、前記アトミック領域の一部を実行するために利用されるハードウェアリソースの予想量への参照を含み、前記条件コミット命令を前記デコード論理が認識すると、前記アトミック領域の末尾の前に前記アトミック領域にコミットする必要があるかを判断する前記ハードウェアは、前記アトミック領域を実行するために利用される、前記プロセッサの利用可能なハードウェアリソースの量を追跡して、前記利用可能なハードウェアリソースの量が前記ハードウェアリソースの利用予想量より少ない場合には、前記アトミック領域の末尾の前に前記アトミック領域をコミットすべきであると判断する、請求項16に記載のシステム。前記ハードウェアリソースは、キャッシュメモリ、投機的キャッシュメモリ、格納バッファ、レジスタファイル、投機的レジスタファイル、および、投機的チェックポイントレジスタファイルからなる群から選択される、請求項18に記載のシステム。前記メモリは、シンクロノスダイナミックランダムアクセスメモリSDRAM、読み出し専用メモリROM、およびフラッシュメモリからなる群から選択される、請求項16に記載のシステム。ループを含むトランザクションを実行する実行論理と、前記ループの繰り返し数をカウントするカウンタと、繰り返し閾値に前記繰り返し数が達すると、トランザクションの終了前に前記トランザクションのコミットを開始するハードウェアとを備える装置。前記繰り返し閾値は、前記ループの実行分析に基づいて動的に調節される、請求項21に記載の装置。前記繰り返し閾値は、最初は初期値にセットされており、前記初期値に前記カウンタが達して、前記ハードウェアが前記トランザクションの終了前に前記トランザクションのコミットを開始する前に、ハードウェア制約によるロールバックがないことにより増分され、前記初期値に前記カウンタが達して、前記ハードウェアが前記トランザクションの終了前に前記トランザクションのコミットを開始する前に、ハードウェア制約によるロールバックがあったことにより低減され、前記初期値は、前記ループの投機的な格納数、メモリデバイス内で利用可能なエントリ数を前記ループの繰り返し中に利用されると推定されるエントリ数で除算して得られる値、ソフトウェアの開始値、および、前記ループの前の実行中のハードウェア制約によりロールバックする前のループ繰り返し数からなる群から選択される、請求項21に記載の装置。前記ループの繰り返し数をカウントする前記カウンタは、初期値にセットされており、ゼロに向かってカウントダウンするカウンタを有し、前記繰り返し閾値に前記繰り返し数が達すると、トランザクションの終了前に前記トランザクションのコミットを開始する前記ハードウェアは、前記カウンタがゼロに到達すると、前記トランザクションの終了前に前記トランザクションのコミットを開始するハードウェアを有する、請求項21に記載の装置。以下の詳細な記載においては、特定の種類のプロセッサコア、特定のプロセッサ構成、特定の種類の命令、特定のハードウェア構造、特定のコード最適技術等数多くの特定の詳細を述べて本発明の実施形態の完全な理解を促している。しかし当業者であれば、本発明の実施形態がこれら特定の詳細なしに実行可能であることを理解する。また、特定の、および別のプロセッサアーキテクチャ、記述されたアルゴリズムのための特定の論理回路/コード、特定のコード実装、特定のコンパイラの詳細、その他の特定のマイクロプロセッサの動作の詳細等の公知のコンポーネントまたは方法については詳細な記載を省くことで、本発明の実施形態を曖昧にしないようにしている箇所もある。ここに記載する方法および装置は、ハードウェアの制約に基づいて動的にトランザクションのサイズを変更することで、コードを最適化する。具体的には、コードの最適化は、ハードウェアの制約を利用した、投機的なチェックポイント実行および/またはトランザクションの条件コミットに関して説明されている。しかし、ここで記載される装置および方法はこれらに限定はされず、任意の形態の動的なトランザクションのサイズの変更として実装することができる。例えば、コードの最適化は、静的に行われても動的に行われてもよく、ハードウェア、ソフトウェア、またはこれらの組み合わせで行われてもよい。図1は、複数のコアを含むプロセッサの一実施形態を示す。プロセッサ100は、マイクロプロセッサ、エンベデッドプロセッサ、デジタル信号プロセッサDSP、ネットワークプロセッサ、その他の、コードを実行するデバイスであってよい。一実施形態ではプロセッサ100が、非対称コアまたは対称コアを含んでよい少なくとも2つのコアコア101および102を含む実施形態。しかしプロセッサ100は、対象であっても非対称であってもかまわないプロセッサエレメントを任意の数含むことができる。一実施形態では、処理エレメントとは、プロセッサの状態例えば実行状態またはアーキテクチャ状態を保持することができるスレッドユニット、スレッドスロット、処理ユニット、コンテキスト、論理プロセッサ、ハードウェアスレッド、コア、および/または、任意のその他のエレメントのことを指してよい。つまり、一実施形態では、処理エレメントが、ソフトウェアスレッド、オペレーティングシステム、アプリケーション、その他のコードに独立して関連付けることができる任意のハードウェアであってよい。通常、物理プロセッサとは、任意の数の他の処理エレメントコアまたはハードウェアスレッドを含むことのできる集積回路のことであってよい。コアとは、独立したアーキテクチャ状態を、それぞれが少なくともいくつかの専用実行リソースに関連付けられるように、維持することができる集積回路に位置する論理のことである。コアに対して、ハードウェアスレッドとは通常、独立維持されるアーキテクチャ状態同士が実行リソースに対するアクセスを共有するような独立アーキテクチャ状態を維持することのできる集積回路に位置している任意の論理のことを指す。このことから分かるように、共有リソースと、あるアーキテクチャ状態に専用のリソースとが混在する場合、ハードウェアスレッドとコアとは一概に切り離せない。しかしまたしばしば、コアとハードウェアスレッドとが、オペレーティングシステムからは個々の論理プロセッサとしてとらえ、オペレーティングシステムが個々に各論理プロセッサの処理をスケジュールする場合もある。図1に示すような物理プロセッサ100は、2つのコアコア101および102を含む。ここでコア101および102は、対称なコアとしてとらえられるつまり、同じ構成、機能ユニット、および/または、論理を有するコアのこと。別の実施形態では、コア101が、アウトオブオーダプロセッサコアを含み、コア102が、インオーダプロセッサコアを含んでいる。しかし、コア101および102は、任意の種類のコア例えばネーティブコア、ソフトウェア管理コア、ネーティブ命令セットアーキテクチャISAを実行するよう適合されたコア、変換命令セットアーキテクチャISAを実行するよう適合されたコア、共通設計されたコア、その他の公知のコアから選択されてよい。コア101内に示されている機能ユニットを以下で詳述するが、コア102のユニットも同様の動作をする。図示されているように、コア101は2つのハードウェアスレッド101aおよび102bを含むハードウェアスレッドスロット101aおよび101bとも称される。従って、一実施形態ではソフトウェア実体例えばオペレーティングシステムは、プロセッサ100を潜在的に4つの別個のプロセッサつまり、4つのソフトウェアスレッドを同時実行可能な4つの論理プロセッサまたは処理エレメントとしてみることができる。第1のスレッドは、アーキテクチャ状態レジスタ101aと関連付けられており、第2のスレッドは、アーキテクチャ状態レジスタ101bと関連付けられおり、第3のスレッドはアーキテクチャ状態レジスタ102aと関連付けられていてよく、第4のスレッドは、アーキテクチャ状態レジスタ102bと関連付けられていてよい。図示しているように、アーキテクチャ状態レジスタ101aは、アーキテクチャ状態レジスタ101bに複製されており、論理プロセッサ101aおよび論理プロセッサ101bについて個々のアーキテクチャ状態/コンテキストを格納できる。コア101では、他のより小さなリソースが、スレッド101aおよび101bについて複製されていてよい。リオーダ/リタイヤユニット135、ILTB120、ロード/格納バッファおよびキューなどのリオーダバッファ等の一部のリソースは、分割により共有されてよい。他方で、汎用内部レジスタ、ページテーブルベースレジスタ、低レベルデータキャッシュおよびデータTLB115、実行ユニット140、およびアウトオブオーダユニット135の部分等の他のリソースは、完全に共有されていてよい。通常、プロセッサ100は、完全に共有されていたり、分割により共有されていたり、処理エレメント専用であったりしてよい、他のリソースを含む。図1には、プロセッサの論理ユニット/リソースの一例を有するプロセッサの純粋な例が示されている。プロセッサにはこれら機能ユニットのいずれかが含まれていても、これら機能ユニットのいずれかがなくてもよく、または、図示されていない任意の他の公知の機能ユニット、論理、またはファームウェアが含まれていてもよいことに留意されたい。図示されているように、コア101は、アウトオブオーダOOOプロセッサコアの簡略化された代表例を含む。OOOコアは、実行される/とられる分岐を予測するための分岐対象バッファ120と、命令のためのアドレス変換エントリを格納するための命令変換バッファI-TLB120とを含む。コア101はさらに、フェッチされたエレメントをデコードするフェッチユニット120に連結された復号モジュール125を含む。一実施形態ではフェッチ論理は、それぞれスレッドスロット101a、101bに関連付けられた個々のシーケンサを含む。通常、コア101は、プロセッサ100で実行可能な命令を定義/特定する第1の命令セットアーキテクチャISAを含む。ここで、第1のISAの一部である機械コード命令が、実行する命令または処理を参照/特定する、命令の一部オペコードと称されるを含んでいる。デコード論理125は、自身のオペコードからこれら命令を認識して、デコードした命令を、第1のISAにより定義されているように処理させるためにパイプラインに送る回路を含む。例えばデコーダ125の説明で詳述するように、一実施形態では、条件コミット命令および/または投機的なチェックポイント命令等の、具体的な新たな命令を認識するよう設計または適合されている論理を含む。この結果、またはデコーダ125の認識により、アーキテクチャまたはコア101は、適切な命令に関連付けられたタスクを実行するために、具体的な予め定義された動作を行う。一例では、割り当ておよびリネームブロック130は、リソースを保持するためのアロケータ例えば、命令処理結果を格納するためのレジスタファイルを含む。しかし、スレッド101aおよび101bは、割り当ておよびリネームブロック130も、命令結果を追跡できるリオーダバッファのように他のリソースをリザーブするアウトオブオーダ実行を行うことができる。ユニット130はさらに、プロセッサ100の内部の他のレジスタに、プログラム/命令参照レジスタをリネームするレジスタレネーマを含んでもよい。リオーダ/退避ユニット135は、上述したリオーダバッファ、ロードバッファ、および格納バッファ等のコンポーネントを含み、アウトオブオーダ実行をサポートして、後になっては、アウトオブオーダを実行した命令をインオーダでの退避をサポートする。一実施形態におけるスケジューラおよび実行ユニットブロック140は、実行ユニットにおける命令/動作をスケジュールするためのスケジューラユニットを含む。例えば浮動小数点命令は、利用可能な浮動小数点実行ユニットを有する実行ユニットのポートにスケジュールされる。実行ユニットに関連付けられているレジスタファイルも、情報命令処理結果を格納するために含まれていてよい。例である実行ユニットには、浮動小数点実行ユニット、整数実行ユニット、ジャンプ実行ユニット、ロード実行ユニット、格納実行ユニット、およびその他の公知の実行ユニットが含まれてよい。低レベルデータキャッシュおよびデータ変換バッファD-TLB150が、実行ユニット140に連結されている。データキャッシュは、潜在的にメモリコヒーレンシー状態で保持される、エレメントに対する最近の利用/動作例えばデータオペランドを格納する。D-TLBは、最近の仮想/線形から物理へのアドレス変換を格納する。具体的な例としては、プロセッサは、複数の仮想ページに物理メモリを分割するためにページテーブル構造を含んでよい。ここでコア101および102は、最近フェッチされたエレメントをキャッシュする、高レベルまたは更なるアウトキャッシュ110に対するアクセスを共有する。ここで高レベルまたは更なるという用語は、実行ユニットから増加するまたは更に離れる方向のキャッシュレベルのことである。一実施形態では、高レベルキャッシュ110は、最後のレベルのデータキャッシュのことでありつまりプロセッサ100のメモリ階層の最後のキャッシュ、例えば第2または第3レベルのデータキャッシュのことである。しかし、高レベルのキャッシュ110はこれに限定はされず、命令キャッシュに関連付けられていても、命令キャッシュを含んでもよい。逆にトレースキャッシュは、命令キャッシュの一種であり、デコーダ125の後に連結され、最近デコードされたトレースを格納してよい。図示されている構成では、プロセッサ100が、システムメモリ175、チップセット、ノースブリッジ、その他の集積回路等のプロセッサ100外部のデバイスと通信するバスインタフェースモジュール105を含んでいる。メモリ175は、プロセッサ100専用であってもよいし、システム内の他のデバイスと共有されてもよい。よく知られたメモリの種類の例には、ダイナミックランダムアクセスメモリDRAM、スタティックRAMSRAM、不揮発性メモリNVメモリ、およびその他の公知の格納デバイスが含まれる。一実施形態では、プロセッサ100が、ハードウェアトランザクション的な実行、ソフトウェアトランザクション的な実行、またはこれらの組み合わせ、混合物を実行することができる。ここでトランザクションとは、コードのクリティカルセクションまたはアトミックセクション/領域のことを意味しており、アトミック群として実行される命令、演算、またはマイクロ演算のグループを含んでよい。例えば、命令または動作は、トランザクションまたはクリティカルなセクションを区別するために利用されてよい。一実施形態では、後で詳述するように、これら命令は、上述したデコーダ等のプロセッサ100のハードウェアにより認識可能な命令セット例えば命令セットアーキテクチャISAの一部である。これら命令は、高レベル言語からハードウェアが認識できるアセンブリ言語にコンパイルされると、デコーダがデコード段階で認識できるオペレーションコードオペコード、その他の命令の部分を含む。通常、トランザクション実行中、メモリへの更新は、トランザクションがコミットされるまではグローバルに見ることができない。たとえば、ある位置へのトランザクション書き込みは、ローカルスレッドからは見ることができるが、別のスレッドからの読み出しがあった場合、トランザクション書き込みを含むトランザクションがコミットされるまで、書き込みデータは転送されない。トランザクションが係属している間は、メモリからロードされた、またはメモリに書き込まれたデータのアイテム/エレメントがトラックされるが、これについては以下で詳述する。トランザクションがコミット点に到達すると、そのトランザクションについてコンフリクトが検知されない限り、トランザクションにコミットが行われ、トランザクション中に行われた更新がグローバルに見ることができるようになる。しかしトランザクションが係属中に無効になると、トランザクションがアボートされて、更新をグローバルに見ることができるようになる前に、再開させられる。従って本明細書では、トランザクションの係属とは、実行が開始されているが、コミットもアボートも行われていない、という意味で係属されていることを意味する。ソフトウェアトランザクションメモリSTMシステムとはしばしば、アクセス追跡、コンフリクト解決、または、内部のトランザクションメモリのタスクの実行、または、少なくとも一義的に、ソフトウェアコードの実行によるタスクのことを示すために利用される。一実施形態では、プロセッサ100は、ハードウェア/論理を利用してつまりハードウェアトランザクションメモリHTMシステム内で、トランザクションを実行することができる。HTMの実装にあたっては、アーキテクチャおよびマイクロアーキテクチャ両方の観点から、いくつも具体的な実装の詳細があり、その殆どについてはここでは説明を避けて、本発明を不当に曖昧にしないようにする。しかし、一部の構造、リソース、および実装については例として説明する。しかし、これら構造および実装は必須ではなく、異なる実装の詳細を有する他の構造を追加したり、および/または、他の構造で置き換えたりすることもできる点に留意されたい。組み合わせにより、プロセッサ100は、無制限トランザクションメモリUTMシステム内のトランザクションを実行することができ、STMおよびHTMシステム両方の利点を享受することができる。例えばHTMは、アクセス追跡、コンフリクト検知、検証、およびトランザクションへのコミットにソフトウェアを利用しないので、小さなトランザクション実行には高速で効率的である。しかしHTMは、小さなトランザクションの処理のみが可能である場合が多く、一方でSTMは、無限サイズのトランザクションを処理することができる。従って一実施形態では、UTMシステムが、小さなトランザクションの実行にはハードウェアを利用して、ハードウェア処理には大きすぎるトランザクションはソフトウェアに行わせる。後述する事項から分かるに、ソフトウェアがトランザクションを実行中であっても、ハードウェアを利用してソフトウェアを助けたり加速させたりすることが可能である。さらに、同じハードウェアを利用して、純粋なSTMシステムのサポートおよび加速を行うこともできる点も言及に値する。上述したように、トランザクションには、プロセッサ100内のローカル処理エレメント、および、他の処理エレメントの両方からのデータアイテムに対するトランザクションメモリアクセスが含まれている。トランザクションメモリシステムの安全メカニズムがない場合、これらアクセスの一部が無効なデータおよび実行を行う可能性を秘めているつまり、データへの書き込みによって、読み出しを無効化してしまったり、無効なデータを読み出してしまったりする場合。この結果、プロセッサ100は、潜在的に、読み出しモニタおよび書き込みモニタ等の、データアイテムへのメモリアクセスを追跡またはモニタして、潜在的なコンフリクトを特定する論理を含んでいるが、これについては後述する。データアイテムまたはデータエレメントは、ハードウェア、ソフトウェア、またはこれらの組み合わせにより定義される、任意の粒度レベルのデータを含んでよい。このデータ、データエレメント、データアイテム、またはこれらの参照の非排他的な例としては、メモリアドレス、データオブジェクト、クラス、ある種の動的言語コードのフィールド、ある種の動的言語コード、変数、オペランド、データ構造、およびメモリアドレスへの間接参照が含まれる。しかし、任意の公知のデータの分類を、データエレメントまたはデータアイテムと称してもよい。上述した例のいくつか例えば、動的言語コード型のフィールド、および、動的言語型コードは、動的言語コードのデータ構造と称される。例としては、動的言語コード例えばSunMicrosystems,Inc.社のJava登録商標は、強い型の言語である。各変数は、コンパイルの時点で分かる型を有している。型は2つのカテゴリに分類されるプリミティブ型ブールまたは値、例えばint、floatおよび参照型クラス、インタフェース、および配列。参照型の値はオブジェクトへの参照である。Java登録商標では、フィールドからなるオブジェクトが、クラスインスタンスまたはアレイであってよい。クラスAのオブジェクトaがあるとすると、A::xという表記を利用して、タイプAのフィールドxを現し、a.xという表記を利用して、クラスAのオブジェクトaのフィールドxを示す。例えば、a.x=a.ya.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の非トランザクションロードと同じデータアイテムへのメモリアクセスなので、モニタされない。これら例から推定すると、モニタは、任意のデータ粒度レベルでモニタ/バッファリングが可能であると思われる。一実施形態では、プロセッサ100は、データアイテムに関して、アクセスおよび後続することが予想されるコンフリクトのモニタおよび検知を行うモニタを含む。一例としては、プロセッサ100のハードウェアが、モニタすると決めたロードおよび格納を追跡するための読み出しモニタおよび書き込みモニタを含む。一例では、ハードウェア読み出しモニタおよび書き込みモニタは、基礎にある格納構造の粒度とは独立して、データアイテムの粒度でデータアイテムをモニタする。一実施形態では、データアイテムを、格納構造の粒度で関連付けられているメカニズムをトラックすることで制限することで、少なくともそのデータアイテム全体を適切にモニタすることができる。具体例として、読み出しモニタおよび書き込みモニタは、キャッシュ位置に関連する属性を含むことで例えば、投機的なキャッシュを含みうる低レベルデータキャッシュ150内の位置、これらの位置に関するアドレスへのロードおよび格納をモニタすることができる。ここで、データキャッシュ150へのキャッシュ位置の読み出し属性は、同じアドレスへの潜在的なコンフリクト書き込みをモニタするためのキャッシュ位置に関するアドレスへの読み出しイベントがあると設定される。この場合には、書き込みイベント同様に書き込み属性が機能して、同じアドレスに対してコンフリクトを生じうる読み書きがモニタされる。この例で説明を続けると、ハードウェアは、そのキャッシュ位置をモニタする旨を示すように設定されている読み出しおよび/または書き込み属性を有するキャッシュ位置への読み書きスヌープに基づいてコンフリクトを検知することができる。逆に、一実施形態では、読み書きモニタの設定、または、キャッシュ位置のバッファリング状態への更新が、スヌープ読み出し要求または所有者要求の読み出し等を生じさせ、他のキャッシュでモニタされているアドレスとのコンフリクトが検知される。従って、設計によって、キャッシュコヒーレンシー要求およびモニタされているキャッシュラインのコヒーレンシー状態のさまざまな組み合わせにより、コンフリクトが生じる可能性がある例えば、共有読み出しモニタ状態としてデータアイテムを保持しているキャッシュラインおよびデータアイテムへの書き込み要求を示すスヌープ等。逆に、バッファリングされている書き込み状態にあるデータアイテムを保持するキャッシュラインおよびデータアイテムへの読み出し要求を示す外部スヌープは、潜在的にコンフリクトを生じさせるものとして捉えられる。一実施形態では、これらアクセス要求および属性状態スヌープロジックの組み合わせの検知をコンフリクト検知/報告論理例えばコンフリクト検知/報告モニタおよび/または論理およびコンフリクトを報告するステータスレジスタに連結させることができる。しかし、条件およびシナリオのどの組み合わせも、トランザクションにとっては無効であるとみなされる場合がある。トランザクションの非コミットとしてみなされうる要素の例としては、トランザクション的にアクセスされたメモリ位置に対するコンフリクトを検知すること、モニタ情報をなくすこと、バッファリングされたデータをなくすこと、トランザクション的にアクセスされたデータアイテムに関するメタデータをなくすこと、他の無効化イベント割り込み、リング遷移、または明示的なユーザ命令を検知することを含む。一実施形態では、プロセッサ100のハードウェアは、バッファリングによりトランザクション的な更新を保持する。上述したように、トランザクション書き込みは、トランザクションにコミットが行われるまではグローバルに見られる状態にされない。しかし、トランザクション書き込みに関するローカルソフトウェアスレッドは、後続するトランザクションアクセスのトランザクション更新にアクセスすることはできる。最初の例として、別個のバッファ構造をプロセッサ100内に提供して、バッファリングされた更新を保持させ、更新を、ローカルスレッドには提供するが、他の外部スレッドには提供しない。別の例では、キャッシュメモリ例えばデータキャッシュ150が、更新をバッファリングするために利用され、同時に同じトランザクション機能を提供してもよい。ここでキャッシュ150は、バッファリングされたコヒーレンシー状態でデータアイテムを保持することができ、場合によっては新たなバッファリングコヒーレンシー状態をキャッシュコヒーレンシープロトコル例えばMESIModifiedExclusiveSharedInvalidプロトコルに追加して、MESIBプロトコルを形成する。バッファリングされているデータアイテムのローカルな要求に対してはデータアイテムはバッファリングコヒーレンシー状態に保持されている、キャッシュ150は、データアイテムをローカル処理エレメントに渡して、内部的なトランザクション連続順序付けを守らせる。しかし外部アクセス要求に対しては、ミス応答を提供して、コミットが行われるまでは、トランザクションで更新されたデータアイテムをグローバルには見られない状態にする。さらに、キャッシュライン150がバッファリングされたコヒーレンシー状態に維持されており、退去が選択された場合、バッファリング更新を高レベルレベルキャッシュメモリに書き戻さず、つまり、コミットされるまでは、バッファリング更新をメモリシステム内に増殖させないグローバルに見える状態にしない。トランザクションをアボートしてよいつまり、退去させるラインを、犠牲キャッシュのような高レベルキャッシュメモリとデータキャッシュとの間の投機的な構造に格納することができる。コミットされると、バッファリングラインを修正済み状態にして、データアイテムをグローバルに見える状態にする。内部および外部という用語は、しばしば、キャッシュを共有するトランザクションまたは処理エレメントの実行をスレッドの観点からみた場合のものである。例えば、トランザクションの実行に関するソフトウェアスレッドを実行する第1の処理エレメントが、ローカルスレッドと称される。従って上述した説明では、保持されているアドレスのキャッシュラインをバッファリングされたコヒーレンシー状態にする第1のスレッドが前に書き込んだアドレスから格納またはロードが受信される場合、これがローカルスレッドなので、キャッシュラインのバッファリングされているバージョンを第1のスレッドに提供する。これに対して、第2のスレッドは同じプロセッサ内の別の処理エレメントで実行されている場合があるが、バッファリング状態に保持されているキャッシュラインの責任を有さないトランザクションの実行には関与しないので外部スレッド、第2のスレッドからのアドレスへのロードまたは格納は、キャッシュラインのバッファリングバージョンをミスして、通常のキャッシュの置き換えを利用して、キャッシュラインのバッファリングされていないバージョンを高レベルメモリから取得する。一実施形態では、プロセッサ100は、コンパイラ/最適化コード177を実行してアプリケーションコード176をコンパイルすることで、トランザクション実行をサポートし、且つ、アプリケーションコード176を最適化する可能性がある。ここでコンパイラは、処理、呼び出し、機能、その他のトランザクションの実行を行うためのコードを挿入することができる。コンパイラは、ソーステキスト/コードを対象テキスト/コードに変換するプログラムまたはプログラムセットを含む場合が多い。通常、コンパイラを有するプログラム/アプリケーションコードのコンパイルは、複数段階またはマルチパスで行われ、上位のプログラミング言語コードを低レベルの機械またはアセンブリ言語コードに変換するためにパスを行う。しかし、ワンパスのコンパイラも、単純なコンパイルには利用可能である。コンパイラは、辞書解析、前処理、パース、セマンティック解析、コード生成、コード変換、およびコード最適化等の任意のコンパイル技術を利用して、任意の公知のコンパイラ処理を実行することができる。ここで記載する、トランザクション的実行と動的コードコンパイルとの融合により、より積極的に最適化を行い、且つ、必要なメモリ順序付けを保護措置として留保しておくことができる。より大きなコンパイラが、複数の段階を含む場合もあるが、これらは概して2つの一般的な段階1概して統語的処理、セマンティック処理、および変換/最適化が行われる前段階、2概して解析、変換、最適化、およびコード生成が行われる後段階に含まれる場合のほうが多い。コンパイラの中には、コンパイラの前段階と後段階との間の区別が曖昧な中間エンドと称されるものもある。この結果、挿入、関連付け、生成、その他のコンパイラの動作は、前述した段階またはパスのいずれかで、且つ、コンパイラの任意の他の公知の段階またはパスで行うことができる。ある例では、コンパイラが潜在的にトランザクション処理、呼び出し、関数等を潜在的に1以上のコンパイル段階に挿入して、例えばコンパイルの前段階に呼び出し/処理を挿入した後、トランザクションメモリ変換段階において、呼び出し/処理の変換を、低レベルのコードに変換してよい。動的コンパイル中には、コンパイラコードまたは動的最適化コードがこれら処理/呼び出しを挿入して、且つ、ランタイム中に実行のためにコードを最適化することができる。具体例としては、バイナリコード既にコンパイルされているコードをランタイム中に動的に最適化してよい。ここでプログラムコードには、動的最適化コード、バイナリコード、またはこれらの組み合わせが含まれてよい。しかし、コンパイラの実行環境および動的または静的な性質にも関わらず、一実施形態におけるコンパイラは、トランザクション実行を実現するべく、および/または、プログラムコードのセクションを最適化するためにプログラムコードをコンパイルする。従って一実施形態では、プログラムコードの実行というと、1コンパイラプログラムの実行または最適化コード最適化装置を動的または静的に実行して、主要なプログラムコードをコンパイルしたり、トランザクション構造を維持したり、他のトランザクション関連の処理を実行したり、コードを最適化したりする、2トランザクション処理/呼び出し最適化された/コンパイルされたアプリケーションコード等を含む主要なプログラムコードを実行する、3主要なプログラムコードに関連する、ライブラリ等の他のプログラムコードを実行する、または、4これらの組み合わせの実行であってよい。ソフトウェアトランザクションメモリSTMシステム内では、コンパイラが、コンパイルするアプリケーションコードに沿って、いくつかの処理、呼び出し、他のコードを挿入して、同時に、他の処理、呼び出し、関数、およびコードをライブラリ内に別個に提供する、ということがよく行われる。これにより潜在的に、ライブラリ配信者が、アプリケーションコードをコンパイルしなおさずにライブラリを最適化したり更新したりすることができるようになる。具体例では、コミット関数の呼び出しを、アプリケーションコード内のトランザクションのコミット点に挿入して、同時にコミット関数を更新可能なライブラリ内に提供することができる。加えて、具体的に処理および呼び出しをどこに配置するかの選択によって、アプリケーションコードの効率に影響が出る場合がある。背景技術で述べたように、マルチスレッドシステムにおける積極的なコードの最適化は、メモリの順序体系を脅かす場合がある。しかし一実施形態では、コードの最適化を、トランザクションメモリの保護機能と組み合わせることで、メモリの順序の保護機能を留保しつつ、積極的な最適化を可能としている。一例として、最適化されたコードが実行されてもトランザクション的な保護機能によってメモリの順序が脅かされないようにすることができるような、最適化されたコードを含むアトミック領域をプログラムコードに挿入する。この結果、最適化されたコードの積極的に最適化を許可しつつも、アトミック領域が、メモリ順序が脅かされたときにはそれを検知して、領域をコミットさせないようにすることができる。また、コードの最適化とアトミック領域との組み合わせは、別の修正を行う場合にも利点を生じる。従って、一実施形態では、プロセッサ100が、プロセッサ100内のハードウェアリソースの利用可能性に基づいてプログラムコード176内のトランザクションのサイズを動的に変更することができる。従来は、アトミック領域は、完全にコミットされるか、アボートされるか、であった。しかし本例では、トランザクションの最終点到達前にトランザクションにコミットすることができる。つまり、たとえばトランザクションを完全に実行するにはまたはトランザクションのコードの一部を実行するにはリソースが少なすぎる、または足りない場合、より小さなトランザクションへの動的サイズ変更が可能になる。一例として、キャッシュメモリ150を利用して、仮のトランザクション情報に、トランザクション追跡情報を関連付けて保持する場合を想定する。このシナリオでは、キャッシュ150の利用可能なキャッシュエントリが少なくなったとき、または溢れてしまったとき退出すべくトランザクション的にアクセスされたラインを選択して、犠牲キャッシュが満杯の場合、実行中のトランザクションをその時点でコミットするが、これにより仮の情報をグローバルに公開する。次に新たなトランザクションは、コミット点から元のトランザクションの最終点まで再開することができる。この結果、この例ではキャッシュメモリ150であるトランザクションハードウェアリソースが解放される。そしてトランザクションは、2つの小さなハードウェアトランザクションとして完了させることができ、トランザクション全体をロールバックしたり、トランザクションをUTMシステム等におけるソフトウェアに拡張したりする必要がない。従って一実施形態では、プロセッサ100が、HTM、STM、またはUTMであっても、トランザクションメモリシステムをサポートするハードウェアを含んでいる例えば、デコーダ、キャッシュメモリ、投機的格納構造、追跡メカニズム、格納バッファ、レジスタファイル、チェックポイント格納メカニズム、および、トランザクションの実行をサポートするために公知なその他の任意のハードウェアの任意の組み合わせが含まれる。さらにプロセッサ100は、ハードウェアがトランザクション的な実行をサポートするための利用可能性、有用性、または、その表現を追跡、提供、または示すよう適合されたハードウェア/論理を含む。最初の例としては、利用メトリックハードウェア利用表現が、キャッシュメモリ、犠牲キャッシュ、格納バッファ、またはロードバッファ等の格納構造における、利用可能なエントリ数、または、逆占拠率を含んでいる。別の例では、利用メトリックが、メモリのオーバフロー、割り込みイベント、またはエントリの退出等のイベントの発生を含んでいてもよい。しかし、利用メトリックは任意のものであってよい実際のものであっても抽象的なものであってもよい。より抽象的な利用メトリックの一例として、カウンタがコード内のループ繰り返し数をカウントして、カウンタが閾値に到達すると、トランザクションにコミットする場合を考える。ここでは閾値を、一定の期間のコードのプロファイリングに基づいて動的に調節することができる例えば、トランザクションがハードウェアリソースの不足を理由にアボートされた場合には、閾値を低下させる。この場合には、ハードウェアまたは特定のイベントが正確且つ実際には利用されない。しかし、カウンタ閾値を動的に調節することにより、ハードウェアが実質的には、ハードウェアが枯渇するまでのつまり、リソース利用率が高くなることによりアボートまたはロールバックが行われるまでのループ数を推定する。この結果一実施形態では、このようなハードウェア推定は、コード実行のリソース利用性を推定することから、ハードウェアリソースの利用のまたは利用の表現と称される。一実施形態では、プロセッサ100のハードウェアは、トランザクションを動的にサイズ変更すべきときを非同期的に決定することができる。例えばハードウェアリソースの利用率が高いときには、プロセッサ100はトランザクションにコミットして、プロセッサ100上で実行中のプログラムコード176の観点からトランスペアレントに別のトランザクションを再開してよい。ここでトランザクションを含むプログラムコード176が実行論理140で実行中である。プログラムコードの観点からは、トランザクションが途切れなく実行されている。しかしハードウェアの観点からは、格納バッファ等のリソースの利用率が高いオーバフローしていることから、ハードウェアはトランザクションの終了点の前にトランザクションにコミットして、コミット点において第2のトランザクションを再開してから、トランザクションの元の終了点で第2のトランザクションにコミットした。別の実施形態では、トランザクションの動的サイズ変更を、ハードウェアとファームウェア/ソフトウェアの組み合わせで実行する。ここでプロセッサ100は、トランザクション実行のサポートおよびリソースの利用率/利用可能性の追跡の両方のためにハードウェアリソースを含んでいる。プログラムコード176からの条件コードが実行されると、このハードウェアリソースの利用率/利用可能性に基づいて、実行論理140に動的サイズ変更を行わせる終了点の前にトランザクションにコミットさせる。本質的に、リソース利用率および潜在的な条件コミットのチェックは、ソフトウェア命令で行う結果、同期して行われるつまり、ハードウェアの非同期に行われる特定の命令の実行から独立して行われるのではない。例えば、動的コンパイラコードの一部でありうる動的最適化コード177は、プロセッサ100のランタイム中に、実行論理140/141によってプログラムコード176を動的コンパイル/最適化を行う。このコンパイル/最適化中に、アトミック領域がプログラムコード176のセクションに、アトミック領域の条件コミットコードとともに挿入される。次に実行論理140/141は、コード176を動的に最適化して、ランタイム中に動的に最適化されたコード176を実行する。具体的には、実行論理140/141は、アトミック領域およびその中の最適化されているコードを実行する。デコード段階125が条件コミットコードに遭遇/デコードすると、ハードウェアリソース利用率を決定する。利用率/利用可能性は、前に追跡済みであってよいが、利用率の報告/評価は、条件コミットコードに遭遇/デコードしたときに行われる。次いで、ハードウェアリソース利用可能性/利用率に基づいてアトミック領域にコミットするかについて決定することができる。一実施形態では、リソース利用率に基づくコミットの決定は、条件コードに応じてハードウェアが行うこともできる。言い換えると、ハードウェアが独立してハードウェア利用率を評価して、利用率が高い場合には早期コミットを行う必要があると決定するのである。一例では、条件コミットコードが、デコーダ125が認識可能な条件コミット命令を含んでいる。条件コミット命令または領域チェック命令が、分岐対処アドレスを含んでいる。ハードウェアは、デコード論理125が条件コミット命令をデコードすると、ハードウェアリソースの利用率が高いすぎないかを判断する、または、不十分なリソースしかないかを判断する。利用率が高すぎる場合、または、不十分なリソースしかない場合には、実行論理140が分岐対象アドレスにジャンプ実行する。一実施形態では、ハードウェアが、利用率が高すぎるか、不十分なリソースしかないかを、所定のアルゴリズムに基づいて決定する。例えばハードウェアリソースが格納バッファを含むときには、利用率が高すぎることは、所定数の格納バッファエントリが利用されている、またはオーバフロー格納バッファエントリが利用不可能であるが生じている、ということで判断できる。ハードウェアはさらに、前の実行コードプロファイリングに基づいてコードの予想利用量を推定して、現在のハードウェア利用率とともにこの推定値を利用することで、条件コミットなしに実行を続けることができるに足るリソースが存在しているかを判断する。または、条件コミット命令が予想利用量を含んでもよい。ハードウェアは、不十分なリソースしかない場合にはハードウェア利用率とこの予想利用量とを比べる。例えば、条件コード176がプログラムコード176のアトミック領域内のループに挿入されたと想定する。この結果、ループが繰り返されるごとに条件コードが実行される。ここで条件コミット命令は、コードによる推定またはコードの動的プロファイリングにより得られる固有の格納バッファエントリ数に基づいていてよい、ループの繰り返し中に利用されるべきバッファエントリの格納予定数を参照する。デコード論理125が条件コミット命令をデコードすると、予測されるエントリ数を、プロセッサ100のハードウェアが決定する格納バッファで利用可能なエントリ数と比べる。予測されるエントリ数が利用可能なエントリ数より多い場合には、実行は、条件コミット命令が参照する分岐対象アドレスにジャンプする。分岐対象アドレスは、プログラムコード176内のアドレス参照コード、または、アトミック領域の早期コミットを実行して第2のアトミック領域を再開するための他のコード例えばライブラリコードを含んでよい。別の実施形態では、ソフトウェアが、ハードウェア利用率が高いとき、またはハードウェア利用可能性が非常に低いときを判断する。この例では、プロセッサ100が、ハードウェア利用率表現ハードウェア利用メトリックを保持する、レジスタ等の格納エレメントを含んでいる。ここで、条件コードは、利用メトリックをロードして/読み出して、評価して、早期コミットを実行するかを判断する処理を含む。早期コミットを実行する場合には、条件コードはジャンプ動作を含み、これは実行論理140により実行されると、分岐対象アドレスに実行をジャンプさせ、これにより現在のトランザクションがコミットされ、別のアトミック領域を始めることができる。ハードウェアとソフトウェアとは同様の評価を行ってよい。しかしハードウェアによる解決法は、ハードウェアを完全に早期コミットを処理させたり、条件コミット命令のみを受信したりするなど、コードの簡潔化が可能である。しかしソフトウェアに評価を行わせることで、早期コミットを行うときの決定がより柔軟に行われるようになる。この結果、ハードウェアとソフトウェアの組み合わせを任意の割合で利用して、ハードウェア利用率/利用可能性が高すぎたり低すぎたりしないかを、実装と所望の利点とに基づいて決定することができる。図1は、様々なモジュール、ユニット、および/または論理の表現を有するプロセッサ例の抽象的な論理的視点を示す。しかし、ここで記載する方法および装置を利用するプロセッサは、例示されているユニットを必ず含まねばならないわけではない。プロセッサは示されているユニットの一部または全てを備えなくてもよい。加えて図1は2つのコアのみを示しているが、プロセッサには任意の数が含まれていてよい例えば同じタイプの複数のコア、またはそれぞれが異なるタイプの3つ以上のコア等。図1は、インタフェースで外部メモリコントローラコントローラハブ170にポイントツーポイント連結されているプロセッサの一実施形態を示す。しかし、現在では多くのプロセッサが、複数のコアを相互接続するためにリング構成および共有キャッシュその他のインタフェースを有するオンプロセッサのメモリインタフェースモジュールオンチップモジュールを含みはじめている。図示されてはいないが、一実施形態形態ではプロセッサ100が、コア、キャッシュ、およびメモリコントローラコンポーネントを連結するリング相互接続を含んでいる。ここではキャッシュエージェントを利用して、物理的に分散配置されているキャッシュの一部を管理している。一例として、各キャッシュコンポーネントがキャッシュの一部を配列コアキャッシュの分散配置されている部分を管理する目的でキャッシュエージェントと関連付けられているコアのことのために管理する。キャッシュエージェントがリング相互接続における通信に対処してキャッシュの部分とインタフェースするのと大体同じように、コアエージェント/コンポーネントが、コアとの通信およびインタフェースに対処する。加えて、リング相互接続は、メモリコントローラインタフェース論理MCILおよび/またはその他のコントローラを、他のモジュール例えばメモリおよび/またはグラフィックプロセッサとインタフェースするように連結する。図2aは、アトミック領域を利用するコードの最適化方法のフロー図を示している。図2aのフローのブロックは、実質的に直列方式で描かれているが、例示される方法のフローは任意の順序で実行されてよく、且つ、その一部または全体が並列処理されてもよい。例えば条件コミットコードがアトミック領域の開始および終了命令の挿入前に挿入されてもよい。さらに、図示されているブロックは実行されなくてもよい。また図示されていない他のブロックが、図示されているブロックとともに、またはその代わりに実行されてもよい。ブロック205で、プログラムコードのうち最適化すべきセクションを特定する。上述したようにプログラムコードとはコンパイラコード、最適化コード、アプリケーションコード、ライブラリコード、その他の任意の公知のコードの成り立ちであってよい。具体例として、プログラムコードは、実行準備の整った、プロセッサ100での実行用に動的にコンパイルされた、および/またはプロセッサ100での実行用に動的に最適化されたバイナリコード等の、プロセッサ100で実行されるコードを含む。加えて、コード演算、関数呼び出し等の挿入、およびコードの最適化は、プログラムコード例えばコンパイラおよび/または最適化コードの実行により行われる。一例として、最適化コードは、プロセッサ100でランタイムにおいて動的に実行されて、プロセッサ100でプログラムコードが実行される直前にプログラムコードが最適化される。一実施形態では、最適化すべき擬似コードBの領域等のプログラムコードの1つのセクションを特定することには、コードが、最適化すべきプログラムコードの1つのセクション/領域を示すことを含む。例えば、特定の命令またはデマケーションを利用して、最適化すべき、または、最適化により利点があることが想定されるコードの1つのセクションを示すことが含まれる。別の選択肢としては、プログラマが、プログラムコードのセクションに関するヒントを提供して、これを最適化コードが最適化するセクションを特定する際に利用する、ということも可能である。別の実施形態では、領域をプロファイリング情報に基づいて特定/選択する。例えば、プログラムコードを、ハードウェア、プロセッサで実行されるソフトウェア、ファームウェア、またはこれらの組み合わせで実行している間にプロファイリングを取る。ここでコードのプロファイリングは、ヒントを生成したり、元のソフトウェアを修正したり、最適化のための領域を直接特定したりする。加えて、コードのあるセクションは、具体的なタイプ、フォーマット、またはコードの順序といった特定の属性により潜在的に特定可能である。具体例では、ループを含むコードが、潜在的な最適化対象とされる。そして実行中のループのプロファイリングによって、最適化すべきループが決定される。さらに、ループが最適化すべきロードおよび格納といった特定のコードを含む場合には、これらのコードを含む領域を最適化するべきであるとして特定する。擬似コードBから分かるように、領域には、ループの実行を最適にするために、ループに対するホイスト、サンクができるロードおよび格納も含まれている。一実施形態では、最適化すべきであるとして特定されるコードのセクションをアトミック領域に変換する。または、コードのセクションの少なくとも一部をアトミック領域に変換する。ここで、開始部分および最終部分、トランザクションアトミック領域命令によってコードの部分が区分されるブロック210から215を参照。擬似コードCから分かるように、領域の開始および領域のコミット命令が、コードの領域の前後にそれぞれ挿入される。一実施形態では、コードには、複数の入力と複数の退出とが含まれている。この結果、開始アトミック領域命令および終了アトミック領域命令が、各入力点および各退出点にそれぞれ挿入されてよい。しかし、領域をアトミックであると示すためには任意の公知の方法を利用することができる。ブロック220で、条件コミット点を決定する。ここで、最適化するコードの領域には、複数の条件コミット点を決定/割り当て可能であるが、説明の便宜上、1つのコミット点のみを以下で詳述する。条件コミット点の決定は、条件コミット点の間でハードウェアリソースが枯渇してしまうことを避けるための任意の公知の割り当て/決定アルゴリズムに基づいて行うことができる。最初の例では、繰り返しごとに条件コミット点に遭遇するよう、ループに条件コミット点を挿入する。ここで、条件コミット点は、ループの最初に決定される。別の例として、コードの動的プロファイリングが、しばしばハードウェアリソースを枯渇させてしまう実行経路を示している。従って、条件コミット点をこのような実行経路に割り当てて、これら経路の実行中にリソースが枯渇しないようにすることができる。同様に、リソースを過度に独占しがちであるとして知られている実行経路にも、条件コミット点を割り当てておくことができる。ブロック225で、条件コミットコードを少なくとも条件コミット点に挿入する。条件コミットコードによって、次のコミット点までの実行をサポートするにはハードウェアリソースが足りないと判断された場合に、トランザクションのサイズ変更早期コミットが行われる。図2bを簡単に説明すると、条件コミットコードを挿入するフロー図の一実施形態が示されている。フロー226で、条件コミット命令を条件コミット点に挿入する。擬似コードDから分かるように、一実施形態では条件コミット命令が、アトミック領域のコミット点L1に挿入された領域チェック命令を含んでいる。最初の例として、条件コミット命令には、分岐対象アドレスへの参照が含まれている。次のコミット点までの実行をサポートするにはリソースが足りないと判断した結果、条件コミット命令に呼応して、実行は分岐対処アドレスにジャンプする。ここで条件コミットコードは、さらに、分岐対象アドレスにコミットコードを含んでよい。この例では本質的に、条件コミット命令は、十分なリソースが存在しているかを判断するためのテスト/クエリを開始するものである。そして分岐対象アドレスのコードは、十分なリソースがないとき早期にトランザクションにコミットするものである。従ってブロック227で、分岐対象アドレスにコミット命令を挿入する。擬似コードDで、第1のregion_commit命令が、B4のアトミック領域の退出/終了点に挿入され、第2のregion_commit命令が、ブロックB6の分岐対象アドレス点L2に挿入される。ここで、L1のregion_check命令によりリソースが不十分であると判断されると、実行はregion_check命令が参照する分岐対象アドレスB6にジャンプする。トランザクションライブラリ内のコミット関数の呼び出しまたはアーキテクチャ的に認識されたコミット命令等のregion_commit命令は、アトミック領域を早期にコミットする終了点B4の前に。そしてさらに、ブロック228で擬似コードDのB7で、第2の開始アトミック領域命令region_startが、region_commit命令の後に挿入される。この結果、アトミック領域の実行はB3region_startから始まる。そしてL1でregion_checkによって十分なリソースがないと判断されるまで、または終了点B4に到達するまで続けられる。しかし、L1で十分なハードウェアリソースがないと判断されると、元のトランザクションのサイズ変更を行うつまり、コミット点L2、B6でコミットする。そして、第2のアトミック領域がB7で始まり、領域実行は、コミット点B4になるまで、またはリソースが再度L1で制約されるまで、続けられる。従って1つのアトミック領域を、より小さなトランザクションにサイズ変更することで、ハードウェアリソースが枯渇しないようにしており、以前にはソフトウェアトランザクション実行がアボートされたりソフトウェアに拡張されていたりしたのとは対照的である。ここで、条件コミット命令には任意の情報が含まれてよい。例えば前述したように、一実施形態の条件コミット命令には、次のコミット点までに予想されるハードウェアリソース利用率擬似コードDのコードB2までのループ中に利用が見込まれるエントリ数が含まれてよい。ここで予想される利用率は、ループB2の別の繰り返しの実行をサポートするために十分なリソースがあるかを判断するために利用される。具体例を挙げると、予想される利用率には、次のコミット点までのコード領域の実行のみにより一意に触れることが予想される格納構造のエントリ数が含まれる。加えて、条件コードは、条件コミット命令に限定はされない。例えばハードウェアが利用率を決定してレジスタに格納する実施形態では例えば図5を参照して後で詳述する、条件コードが、レジスタからの利用率を読み出し/ロードし、利用率を評価してから、擬似コードDのB6およびB7に類似したコミットおよび再開コードに分岐するジャンプまたは分岐動作を発行する。他の実施形態では、ソフトウェアは、ハードウェアと通信したりクエリを行ったりする代わりに、ハードウェア利用率の推定を行ってもよい。この場合には、条件コードが、推定を行うコードを含んでいる。例えば、図6を参照して後で詳述するカウントを、ソフトウェア実行中ずっと維持しておいて、条件コミットを行う前のループの繰り返し数に制限を課してもよい。この例では、カウントを維持するために実行されるコードを、条件コミットコードと考えることができる。ブロック230で、プログラムコードのセクションを最適化する。擬似コードEは、最適化の後のコードの例を示す。アトミック領域のデマケーションおよび条件コミットコードの挿入は、一部の実施形態ではプログラムコードの最適化と捉えられるが、他の実施形態では、プログラムコードのセクションをさらに最適化することで実行の利点を享受することができ、同時にトランザクション実行のメモリ順序の保護機能も利用することができる。具体例を挙げると、PRLEおよびPDSEを利用するループ以外でロードおよび格納をホイスト、サンクすることもできる。擬似コードEでは、PRLEがR2R24ロードをホイストして、PDSEがR24格納をサンクした後のアトミック領域を示している。一実施形態では、別のメモリ順序規則も適用可能である点に留意されたい。ここでは、メモリ順序に違反するメモリ最適化は開始およびコミット領域を超えないよう徹底すると好適である。この一例が擬似コードEに示されており、ここではr24格納がB6のregion_commitの前に挿入されており、R2R24ロードが、B7のregion_start命令の後に再度挿入されている。この結果、領域が早期コミットされると条件コミット点にサイズ変更されると、B6で領域がコミットされる前にR24格納が実行される。そしてR2R24ロードが、B7での新たなトランザクションの再開の後に実行される。上述したようにロードおよび格納が最適化されると、任意の公知のコード最適化技術を利用することができるようになる。コード最適化の例をもう少し紹介すると全部を網羅することは意図しておらず、純粋に例示を目的としている、ループ最適化、ソフトウェアパイプライン、データフロー最適化、コード生成最適化、制限チェック除去、分岐オフセット最適化、デッドコード除去、およびジャンプスレッドなどがある。図3aは、アトミックコードの動的サイズ変更を示すフロー図の一実施形態である。ブロック305で、最適化されたプログラムコードを含むトランザクションアトミック領域を実行する。一実施形態では、最適化されたプログラムコードは、ランタイム中に動的に最適化されるつまり、実行に間に合わせるために、オンザフライ方式でプログラムコードを最適化するために、ランタイムに動的最適化コードを実行する。しばしばこの種の動的最適化またはコンパイルは、プログラム全体例えば静的なコンパイル中を認識しないことがあるが、セクションにおけるコードのいくつかの部分をコンパイル/最適化することはできる。ブロック310で、領域チェック命令に遭遇する。一実施形態では、領域チェック命令に遭遇することには、デコード論理が命令をデコードすることが含まれている。しかし、この遭遇は、命令または命令の一処理を受信するまたは処理するパイプラインの任意の段階のことであってよい。例えば、この代わりに、領域チェック命令に遭遇することが、命令に関する処理についてバッファにエントリを割り当てること、処理のディスパッチ、命令の処理またはマイクロ処理を行うための実行ユニットによる命令の実際の実行、またはパイプラインの任意の他の公知の段階であってもよい。上述したように、一実施形態では、領域チェック命令は、プロセッサのデコーダが、ハードウェアのクエリをする際に認識可能なISAの一部である。クエリは単に、利用についてハードウェアにクエリする際のロードであってよい。そしてソフトウェアは、ハードウェアからの関与をうけずに、十分なリソースが利用可能であるかを判断する。これに対して、クエリは、アトミック領域の実行を継続するのに十分なリソースがあるかの調査をハードウェアに要求することを含んでよい。ここでクエリは、リソースが不十分である場合にハードウェアが分岐する対象アドレスを提供する。しかしクエリの関与が強く、領域チェック命令も、十分なリソースが利用可能であるかを決定する際にハードウェアが利用することが想定される利用率を提供している場合もある。領域チェック命令に呼応して、ブロック315で、領域チェック点で、ハードウェアユニットが、例えば次の条件コミット点まで、トランザクションの領域を完了するために十分なリソースを有しているかを判断する。十分なハードウェアリソースがあるかの判断は、実際に計測されてもよいし、どのような方法で概算されてもよい。最初の例では、ハードウェア自身が利用レベルを追跡したり、および/または、決定したりする。ハードウェア、ファームウェア、ソフトウェア、またはこれらの組み合わせは、利用レベル/メトリックが、トランザクションの領域の完了までに十分利用可能かを判断する。しかし、利用レベルは、ソフトウェアの命令で純粋に近似/計測されてもよい。この場合には、計測は、上述した、ハードウェアが自分で追跡する例より精度が落ちるかもしれないが、計測を行うためにハードウェアフックを追加する必要がない。図3bは、トランザクションの領域の実行を完了するために十分なリソースがあるかを決定するためのフロー図の一実施形態である。フロー350で、ハードウェアユニット、または複数のハードウェアユニットの予想される利用率を決定する。ハードウェア、ファームウェア、ソフトウェア、またはこれらの組み合わせを利用して、利用率を予想する。あるシナリオでは、トランザクションを含むプログラムコードの実行のプロファイリングをとる。プロファイリング中に、リソースの欠如からアボートされた数、アボートされずにコミットされた数、および/または、ハードウェアの利用率を追跡する。そして、コード例えばコンパイラが、過去の実行プロファイリングに基づいて、予想される利用率のヒントまたは示唆を提供する。別のシナリオでは、予想される利用率に推定が含まれてもよい。例えばハードウェアユニットが格納バッファである場合、予想される利用率は、コード領域の固有の格納数を含む新たな格納バッファエントリに割り当てられる可能性のある格納処理。本質的に、コードの格納数は、コード領域の実行中に利用される格納バッファエントリ数の推定である。しかし、予想される利用率の判断は、ソフトウェアプロファイリングまたは推定に限定はされない。ハードウェアが、同様にプロファイリングまたは推定を行ったり、コードと協同して、予想利用率を決定したりしてもよい。同様にフロー355で、ハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせのいずれであってもよいので、ハードウェアユニットの利用可能性を決定する。上述した例を説明するために、条件コミット命令が、ハードウェアに、32個のエントリ格納バッファの予想される利用率が、推定または過去のプロファイリングに基づいて10個の格納バッファエントリを含むと想定する。すると、格納バッファは、先頭および最終ポインタを利用しており、20個のエントリが現在割り当てられていると判断する12個の利用可能なエントリがある。この決定によって、フロー360で比較を行ってよい。利用可能なエントリ数が、予想される利用率より高いので、フロー360で、実行を続けるのに十分なリソースがあると判断される。もしも9個のエントリしか利用可能でない場合には、フロー370で、十分なリソースがないと判断される。しかし、比較は、ハードウェアリソースにきっちり十分な空間があることを確かめることに限られない。この代わりに、閾値を利用してバッファゾーンを提供してもよい。例えば利用率が高い場合閾値を超える場合、または利用可能性が低い場合閾値を下回る場合、同様の決定をフロー365、370で行ってよい。具体例として、6個のエントリを含むバッファゾーンが利用されていると想定する。この場合、利用が予想されるエントリの数は10であり、20個が32個のエントリバッファで利用されているため、12個のエントリのみが利用可能である。従って予想される10個のエントリ利用を割り当てるとすると、残りは2個のエントリのみが利用可能となる。6個のエントリのバッファゾーンが利用されているので、フロー370でリソースが足りないと判断される。もしも20個のエントリが利用可能な場合12個のエントリのみが利用中であるには、コード領域に10個のエントリを割り当ててもまだ10利用可能なエントリがあるので、十分なリソースがあることになるフロー365参照。加えて、利用率および利用可能性には、スレッドの優先度および利用率を考慮に入れてもよい。ここで複数のスレッドが共通してあるハードウェアリソースにアクセスする場合には、リソースを分割したり、完全に共有化したりすることができる。この結果、予想される利用に比べたときの利用および利用率は、この共有を考慮して、1つのスレッドが1つのハードウェアリソースを占有しないようにする別のスレッド用に十分な利用可能性が残らないようではいけない、ということである。例えば2つのスレッドが共通してあるキャッシュに分割によりアクセスする場合には、1以上のスレッドからのトランザクションが、キャッシュのエントリの半分に抑えられる。従って利用および利用可能性は、キャッシュ全体ではなくて、キャッシュの半分に対するものとなる。上述の説明は、バッファ格納に関するもの、または少しキャッシュに関するものであったが、利用/利用可能性は、格納バッファ、ロードバッファ、キャッシュメモリ、犠牲キャッシュ、レジスタファイル、キュー、実行ユニット、またはその他の公知のプロセッサハードウェアといったハードウェアリソースの1つまたは組み合わせに対するものであってよい。例えば、ハードウェアリソースがキャッシュメモリを含む場合、予想される利用率には、触れられる/利用されるキャッシュライン数が含まれてよく、利用には、共有されている、排他的な、または修正されたキャッシュライン数等の、コヒーレンシー状態にある、またはないキャッシュライン数またはデータを保持するキャッシュライン数が含まれてよく、利用可能性は、例えば無効なコヒーレンシー状態である特定のコヒーレンシー状態にある、またはない利用可能なエントリまたはライン数を含んでよい。加えて、利用可能性/利用率はさらに、利用可能性/利用率を計測するハードウェアとの関連でも説明したとおりである。しかし上述したように、利用および利用可能性を直接または間接的に計測したり、ソフトウェア、ハードウェア、またはこれらの組み合わせで推定したりしてもよい。図3aに戻り、領域を完成するために十分なリソースがあると判断されると、実行フローはフロー305に戻る。言い換えると、実行は、次の条件コミット点に到達するまで続けられ、この時点になると、ハードウェアリソースが再評価されてよい。しかし、十分なリソースがないと判断された場合には、フロー320で、トランザクションが終わる前に、トランザクションにコミットする動的サイズ変更。一実施形態では、途切れなく実行するために、新たなトランザクションをフロー325で開始して、アトミック実行を続ける。ここで1つの、大きなトランザクションを、本質的に仮想またはシステムメモリに拡張しなくてもハードウェアが処理可能になるよう小さなトランザクションに動的に分割して、実行空間を大きくする。図4に戻ると、トランザクションの実行をサポートする論理ブロックの一実施形態が記載されている。図示されているメモリ405は、オペレーティングシステムOSコード、ハイパーバイザコード、アプリケーションコード、動的コンパイラコード等のプログラムコード410を保持するよう適合されている。一例としては、プログラムコード410が、図2aから図2bに従って動的に最適化されるランタイムまたは部分的なプログラムコンパイル時にアプリケーションコードの少なくとも一部を含んでいる。ランタイムには、動的サイズ変更をサポートするコードを有するトランザクションを持つ最適化されたコードを含むコード410が実行される。一実施形態では、前述したように、プログラムコード410が、条件コミット命令415例えば領域チェック命令を含んでいる。ここでデコーダ425プロセッサのデコード論理が、条件コミット命令415を認識するように適合されている。例えばデコード論理425は、オペコード418を、命令セットアーキテクチャの一部として特定するよう設計および相互接続される。この結果、特定の予め定義された処理/マイクロ処理を、デコーダ425がオペレーションコードオペコード418を含む条件命令415をデコードすると、論理430、ハードウェア435、および実行論理440により実行される。図示されているように、条件命令415には、予想されるハードウェア利用率ハードウェア利用メトリック416および分岐アドレス420ベースアドレス、コード内から別の対象アドレスへのオフセットへの参照を含む。一実施形態ではデコーダ425が条件命令415をデコードすると、または遭遇すると、ハードウェアが、条件コミット命令415が示す実行されたハードウェア利用に見合うような、ハードウェアリソースが十分利用可能かを判断する。任意の公知の方法および装置を利用して、ハードウェアリソース利用を決定して、ハードウェアリソースの予想される利用率を満たすために利用可能なリソースが十分あるかを判断してよい。しかし、以下の具体例は、これら決定を実装するための一実施形態を例示する。ここでデコーダ425が条件命令415を受信すると、他の処理/マイクロ処理が、デコーダ425および論理430によってプロセッサパイプラインで実行される。例えば、デコーダ425は、条件コミット命令415を、実行すべき処理のトレース等の複数の処理マイクロ処理にデコードすることができる。上述した説明から、トレースは、デコードの後にトレースキャッシュに格納/構築することができる。例えば処理の1つが、ハードウェアリソースの利用レベルを示すレジスタの読み出し、またはハードウェア435からのロードを含む場合、論理430は、エントリをロードバッファに割り当てて、実行論理440でのロードの実行をスケジュールする。さらに、ハードウェア435は、条件命令415に応じて提供、決定、またはロードされるべき利用レベル435を決定するよう適合されている。上述したように、決定された利用レベルを有しうるトランザクション実行をサポートするハードウェアのいくつかの例に、キャッシュメモリ、投機的キャッシュメモリ、格納バッファ、ロードバッファ、レジスタファイル、投機的レジスタファイル、チェックポイントレジスタファイル等を有してよい。この結果、命令415は、1以上のハードウェアリソースについて1以上の予想される利用メトリックを含んでよい。別個のハードウェアまたはリソース自身のいずれかが、その利用レベルを追跡するべく適合される。例えば、一実施形態では、キャッシュメモリ用のキャッシュ制御論理を、キャッシュメモリに保持される無効なキャッシュライン数またはキャッシュメモリ内で利用可能なライン数等のキャッシュメモリの利用レベルを追跡するべく適合する。次いで、決定されたハードウェア利用レベルに比べたときの予想利用レベルに基づいて、早期コミット動的サイズ変更を行わずにトランザクションの実行を続けるに足るリソースが存在しているかを判断する。早期コミットを実行する場合には、図示している例では、実行論理440が、条件コミット命令415が提供する分岐対象アドレス420にジャンプする。上述したように、分岐対象アドレスは、実行されると、早期にトランザクションにコミットして、別のトランザクションを再開してアトミック実行を続けさせるコードを含んでいてよい。具体例として、条件コミット命令415がデコーダ425に受信された場合を考える。条件命令415は、10個の格納バッファエントリおよび10個のキャッシュラインについて予想される利用メトリック416を含んでいる。ハードウェア435トランザクションキャッシュメモリおよび格納バッファは、これらの利用レベルを決定する。これらハードウェアエントリは、利用の追跡を続けてよく、条件コミット命令415によるクエリ/要求があると、この利用率を提供する。または、条件コミット命令415からの要求を受けたとき、論理が実際に利用率を判断してもよい。いずれにしても、ハードウェア利用レベル/メトリック436が格納エレメントに実行論理440による処理用の情報を保持するレジスタ等に提供される。そして、ハードウェア利用レベル436および予想されるハードウェアメトリック416を比較して、早期コミットをせずに実行を続けるために利用可能なリソースが十分あるかを判断する。上述したように、比較は、バッファゾーン、閾値、または直接的な比較を利用することで、設計者のアルゴリズムの好みに基づいて利用可能なリソースが十分あるかを判断することができる。ここで、格納バッファが32個の格納バッファエントリのうち16個を利用しておりつまり16個のエントリが利用可能である、トランザクションキャッシュの64個のエントリのうち60個がトランザクション的にアクセスされたとマークされている場合を想定するつまり、トランザクションがこれらラインに既にアクセスしており、これらのラインの置き換えにより、情報がなくなり、アボートまたはソフトウェアトランザクション実行へと拡張される、つまり4つのエントリが利用可能である。そして、設計者のアルゴリズムにより、予想されたエントリ数を考慮して、4つの利用可能なエントリがなくてはならないと規定されている場合を想定する。この場合、10個の予想格納バッファエントリがあり16個の利用可能なエントリがあるので、次の条件コミット点に到達するまでのアトミック実行に対応するために格納バッファには利用可能な空間が十分あることになる。しかし、トランザクション的にアクセスされたとしてマークされていないキャッシュエントリは4つしかないので、十分なトランザクションキャッシュ空間があるとはいえない。この結果、実行論理ジャンプ実行ユニット等が、分岐対象アドレス420にジャンプして、トランザクションに早期にコミットして動的にトランザクションを縮小する、別のトランザクションを再開するべくコードをフェッチ、デコード、および実行する。上述した例は、予想されたハードウェア利用メトリックおよび分岐対象アドレスを含む条件コミット命令に関するものであった。しかし、条件コミット命令には、ハードウェアが、コードの実行をサポートする上で十分なハードウェアが利用可能であるかを判断する、または推定することができる任意の命令が含まれていてよい。例えば、条件コミット命令は、トランザクションをコミットするかを判断するために、現在の利用レベルを過去のコードのハードウェアプロファイリング条件と比べて評価する、というジャンプ命令のみであってもよい。評価した後で、ハードウェアは、条件コミット命令が提供する分岐アドレスにジャンプすることができる。別の実施形態では、ハードウェアが非同期的に、トランザクションにコミットするかを判断してよい特定の条件コミット命令に関連せず、またはその応答としてではなく。ここで、プロセッサがトランザクションコードを実行している間、またはオーバフローイベントを実行している間これは、既にトランザクション的にマークされたエントリの退去等、ハードウェアリソースにスペースがないことを意味するイベントである、ハードウェアが、ハードウェアトランザクションをコミットして、コードがその他のよい方法を知らなければ新たなトランザクションを再開しうる。図5は、ハードウェアが動的なトランザクションのサイズ変更をサポートしている別の実施形態を示す。図4を参照して、実行論理440により処理用に利用されるレジスタ等の格納エレメントに、決定されたハードウェア利用レベル/メトリックを設けてよいことが説明されていたかと思う。ここでも前の例同様に、決定されたハードウェア利用レベル/メトリックを、格納エレメント例えばレジスタ550にロードしてよい。しかし一実施形態では、モデル特定レジスタMSRを含んでよいレジスタ550が、プログラムコード例えばユーザレベルのアプリケーションコードにより、ハードウェアリソースの利用可能性を評価すべくアクセス可能なよう適合されている。前の例では、ハードウェアが、ソフトウェアが予想した利用率に基づいて評価を行っていた。しかしこの例では、ソフトウェアはハードウェアMSR550にクエリを行い、1以上のハードウェアリソースの利用レベルを受信することができる。そしてソフトウェアは、次のコミット点までアトミック実行を続けることができるリソースを有しているかを、自身のガイドラインに基づいて決定することができる。この方法は、ユーザに利用するハードウェア量を決定させることができるため、ユーザ側により柔軟性がある方法である。この結果、プロセッサ設計者は、プロセッサ側に大きな制御を与えるか、ユーザ側にその決定権を与えるかを選択することができるようになる。具体例として、プロセッサが、潜在的に動的なサイズ変更を行うことのできる挿入/最適化されたトランザクションを含むプログラムコード510を最適化、実行する動的コンパイラコードを実行する場合を想定する。ここで、プロセッサのフェッチ論理不図示が、プロセッサこれも不図示のスレッドの命令ポインタに基づいて、ロード処理515をフェッチする。ロードバッファエントリは、ロードバッファの論理530/ハードウェア535に割り当てられる。ロードは論理530によりスケジュールされ、ディスパッチされ、且つ、論理540により実行されて、ハードウェア535キャッシュ、バッファ、またはレジスタファイル等のトランザクション実行をサポートするリソースから決定された利用レベル536がロードされる。ロードまたは前の命令は、同期して、ハードウェア535に、利用を決定させたり、および/または、MSR550の利用を配置させたりする。または、ハードウェア535が、非同期的に、MSR550に利用レベルを配置してもよいイベントに基づいて、であっても、周期的に、であってもよい。いずれにしても、利用レベルは処理516により読み出され、評価される。例えば処理516は、ロードされた、ハードウェア利用レベルを、ソフトウェアが定義する予想利用レベルその他の閾値レベルに対して評価するブール式を含んでよい。実際、ブール式は、条件ステートメントおよび/またはジャンプ命令517の一部であってよいが、これに関しては後述する。ここで、ハードウェア利用レベルの評価が、トランザクションが早期にコミットされることを示している場合には、デコーダ525がオペコード517oにより認識するジャンプ命令517が実行されて、宛先アドレス520に上述したように分岐して、トランザクションにコミットして、別のトランザクションを再開する。図6を参照すると、トランザクションの動的サイズ変更をサポートしているハードウェアのまた別の実施形態が示されエチル。一実施形態では、カウンタ650が、ループ615の実行による繰り返し数をカウントするよう適合されている。カウンタ650は、ハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせで実装されてよい。例えばカウンタ650は、値を保持するレジスタであってよい。ソフトウェアコードは、ループが繰り返されるたびに、現在の値を読み出し、現在の値を新たな値に修正し増分/低減、レジスタに格納する。本質的には、ソフトウェアがカウンタを維持している。しかしハードウェアカウンタが、ループの各繰り返しの開始および終了時に、増分/低減を行ってよい。一実施形態では、カウンタ650のカウンタ値を利用して、トランザクションの早期コミットを行うときを決定する。例えばカウンタ650は、閾値に到達するまでループの繰り返し数をカウントする。閾値に到達すると、カウンタが期限切れになり、または、オーバフローして、早期コミットが行われる。カウンタはゼロから開始され、閾値に到達するオーバフローまでカウントされてもよいし、あるいは、ある値で開始され、ゼロまでカウントダウンされてもよい期限切れまたはアンダーフローとなる。閾値またはゼロまで低減されるカウンタの開始値は、いずれの方法で決定されてもよい。ハードウェアに含まれる、またはソフトウェアにより設定される、静的な、予め定義された値であってもよい。ここで、静的な、予め定義された値は、プロセッサに含まれるハードウェアの種類またはサイズ、および、実行中のコードの種類またはサイズ等の、すでにわかっている特性に基づいてハードウェアまたはソフトウェアにより知的に選択されてよい。あるいは、静的な、予め定義された値は、たとえばループの繰り返し数を制限するための保守的な値から、ロールバックが顕著に低減するような十分小さい値に、レイジーに選択されてもよい。別の実施形態として、閾値開始値を、動的選択および変更の両方を可能としてもよい。ここで、ハードウェア、ソフトウェア、またはこれらの組み合わせにより、任意の特性に基づいて開始初期値閾値を選択することもできる。例えば、利用可能なキャッシュラインまたは格納バッファエントリの数例えば32を、コードの1つのループ繰り返しの格納数のカウント例えば8で除算して、閾値を求めてもよい例えば4。一実施形態では、複数格納すると、1つのキャッシュラインしか触れられなくなるので、格納数の推定を合理的に保守的に行う。従って、より積極的な初期値を利用することもできる。別の例としては、コードまたはハードウェアのいずれかが、積極的または保守的な値を、コードサイズ/タイプ、ハードウェアユニットサイズ/タイプ、ループの実行が完了するために必要なリソースがあるようにするためのその他の公知の要素に基づいて選択してもよい。さらに、ハードウェアまたはソフトウェアが、コードのプロファイリングをとり、開始値/閾値を提供してもよい。ここで、閾値の数を含むソフトウェアのヒントを、ループの実行の開始前に提供して、カウンタを閾値の数に基づいてセットしてもよい。または、ハードウェアが同様にコードのプロファイリングをとり、コードの領域のプロファイリング履歴に基づいてカウンタをセットしてもよい。一実施形態では、カウンタを初期化した後で、閾値開始値を動的に修正する例えば、ループのコードプロファイリングまたはロールバック決定等の実行分析に基づいて調節する。一実施形態では本質的に、カウンタ650が、ハードウェアリソースが限られていることから許容範囲のロールバック数に達してしまったりロールバックしたりする前にロールバックをループ615が実行することができる繰り返し回数を推定するために利用される。従って、許容できるロールバック数の範囲を超えるロールバックが生じると、コミットを行う前の繰り返し数を低下させて前の閾値を低減させることで、ロールバック数を低下させる。この場合には、あまりにロールバックを頻繁に行いすぎて、実行時間が無駄になり、遅延を生じる可能性がある。しかし、閾値が保守的すぎないようにするために利用可能なリソースがまだ沢山あるとき、外部的に早期にトランザクションにコミットして、アトミック実行が非効率になる、一実施形態では、ロールバックが生じるまで閾値を増分させる。増分/低減回数は、1つ、複数、または指数であってよい。一例としては、開始値を63に初期設定することを想定するつまり、コミットされるまでに64回の繰り返しが許可される。ハードウェア制約によってアボート/ロールバックが複数検知されると、閾値を62に低下させる。後でロールバックが起こると、さらに260、456、848等に低下されて、最終的にはバランスのとれた開始値に落ち着いて、完全に実行を効率的に行うことができるようになる。図6の説明は、条件コミット命令は特に利用せずに、ループの繰り返し数をカウントするカウンタを参照して行われている。ここで、カウンタが閾値に達すると、ハードウェアで非同期的にコミットを開始することができる。しかし別の実施形態では、カウンタ650が、図5および図6の条件コミットコードと協働してよい。一例として、カウンタは、利用可能なハードウェアリソース量を決定/推定するハードウェアメカニズムであってよく、条件コミット命令は、ハードウェアカウンタに基づいてコミットコードにジャンプさせる。例えば、カウンタ650が、9に初期化された場合を想定しよう条件コミットが生じる前に10回の繰り返しが許可される。ループ615が繰り返されるごとに、条件コミット命令例えば条件ジャンプ命令を実行して、カウンタが期限切れになるとゼロになると、分岐対象アドレスにジャンプする。10回目の繰り返しが完了して、条件ジャンプが実行されると、実行フローは、実行中のアトミック領域にコミットするために対象アドレスにジャンプする。カウンタは正確ではないが、個々のハードウェアユニットの具体的な利用レベル測定値は、全て包括した測定値である可能性がある。上述したように、動的な閾値調節により、ハードウェアの制約に基づいてロールバックを減らすための最適な繰り返し回数を見つけることができる。従って、前に特定されていないハードウェアの限定によってロールバックが生じている場合、動的なカウンタ閾値がこれを捉え、一方で、設計者またはプログラマによる個々の特定により、このような特定されていない原因をなくすことができる。さらに、カウンタが特定のハードウェアユニット利用計測値とともに利用されることで、ユニットレベル粒度と、広く網羅できているグローバルな粒度が達成される。前述したことは、主にハードウェアリソースが枯渇する前にトランザクションの条件コミットに注目したものである。または、実行のためのリソースが利用可能かを確かめるために、予想される利用率との比較においてハードウェア利用率を決定する。しかし、一部の実施形態では、アトミック領域により実行すると好適であると思われる。また定期的にユーザ命令、イベント、またはハードウェア定義時間に応じてアトミック領域をチェックポイント実施するとよい。実際のハードウェアの制約、例外、割り込み、その他の不備に遭遇すると、アトミック領域は、最近の内部チェックポイントに戻り、リソースの占有解除にコミットすることができる。本質的に、将来の推定およびトランザクションに先回りしてコミットする代わりに、一実施形態では、トランザクションは、通常トランザクション全体のアボートおよび再開を必要とする実際のリソースの制約に遭遇した場合のみにサイズ変更される。これは、トランザクション内の複数のチェックイベントを実行することで、ロールバックが起こると、許容できる実行量だけがロールバックされるようにすることで達成される。図7aを参照すると、トランザクション内に投機的なチェックポイントを提供することを含むコードの最適化方法のフロー図の一実施形態を示す。ブロック705で、最適化すべきプログラムコードの1つのセクションを特定する。図2aの説明同様に、コードのセクション/領域は、そのセクションに関するユーザの特定/ヒント、プログラム分析、コードプロファイリング、コード属性特定のタイプ、フォーマット、順序、またはその領域の特性ループまたは格納数、またはその他の最適化すべきコード領域を特定する公知の方法に基づいて特定されてよい。一例ではコードがバイナリコードを含む。バイナリコードの実行中に、動的に最適化される。この結果、実行のための最適化中に、バイナリコードにループが遭遇する。ロールバックにより実行の大きな損失がない程度にチェックポイント間の距離を短くするために、ループを最適化すべきであると判断する投機的チェックポイントの挿入。一例としては、以下の擬似コードFが、最適化すべきコード領域の一例を示している。図2aの説明同様に、フロー710、715では、コードの領域を区分するセクションの初めにアトミック領域開始命令を挿入して、セクションの末尾にアトミック領域終了命令を挿入する。前述したように、コード領域は、複数のエントリと複数の退出とを含みうる。ブロック720で、プログラムコード内の投機的チェックポイント位置を決定する。最適化すべきコードの領域内には複数の投機的チェックポイントが決定/割り当てられる可能性があるが、説明の便宜上、1つのチェックポイントのみを例にとって説明する。投機的なチェックポイントの決定は、アトミック領域内のロールバック効果を最小限に抑える任意の公知の割り当て/決定アルゴリズムに基づいて行われてよい。最初の例として、投機的チェックポイントをループ内に挿入して、繰り返しごとに投機的チェックポイントに遭遇するようにする。ここで投機的チェックポイントは、ループの最初またはループのエッジに決定されてよい。コードの動的プロファイリングが、しばしばハードウェアリソースを欠いたり、高い命令カウントを有したりするような実行経路を示している別の例を考える。この例では、投機的チェックポイントをこのような実行経路に割り当てることで、長い実行経路内でのアボートによってアトミック領域全体がロールバックしないようにすることができる。同様に、独占またはリソースがたくさん必要な状態が生じやすいことで知られている実行経路にも投機的チェックポイントを割り当てておく。本質的に、トランザクション全体の前の先行技術のチェックポイントおよび関連するトランザクション全体のロールバックの代わりに、トランザクション内でチェックポイントローカル、内部、または一時的なチェックポイントを利用することでより小さなロールバックあまり無駄がでない実行が実行される。この結果、より大きな領域を最適化することができる。リソースの制約に遭遇すると、小さなロールバックを実行する。加えて、ロールバック点では、トランザクションに潜在的にコミットして、最終的な不備を処理して、別のトランザクションを再開する。フロー725で、投機的なチェックポイントコードを投機的なチェックポイントの位置に挿入する。投機的なチェックポイントコードは、メモリ、キャッシュメモリ、および/またはレジスタファイル等の投機的なハードウェアリソースのチェックポイント実行である。一実施形態では、投機的なチェックポイントコードも、後続するアボート条件に応じてチェックポイントにハードウェアリソースを復元するコードを含んでよい。図7bを簡単に参照すると、投機的なチェックポイントコードを挿入するフロー図の一実施形態が示されている。擬似コードGはさらに、投機的なチェックポイントコードの挿入後のコードの例を示している。フロー726で、投機的チェックポイントB2、B5のループバックエッジに投機的チェックポイント命令/処理B5のL1を挿入する。一実施形態では、投機的なチェックポイント命令が、投機的なハードウェアリソースのチェックポイント現在のスナップショットを開始するためのいずれの命令を含んでもよい。例えば、投機的なチェックポイント命令はプロセッサのデコーダにより認識可能である。デコードされ、スケジュールされ、実行されると、投機的なレジスタファイル、格納バッファ、またはこれらの両方が、チェックポイント投機的レジスタファイルおよび投機的なキャッシュ等のチェックポイント格納構造へと、チェックポイント実行される現在の状態のスナップショットがとられる。さらに一実施形態では、投機的なチェックポイントコードが、現在のロールバックを生じさせたのと同じロールバック状況を潜在的に避けるためになんらかの動作を実行するためのその他のコードを含む。例えば、ハードウェアリソースの制約によりロールバックが生じた場合、何らかの補正措置がとられなければ常に同じハードウェアの制約が生じる場合があり、前に進めなくなる。一例として、擬似コードHの左側のコードを最適化する場合を考える。ここで、最適化されたコード内のロールバック処理方法には複数のシナリオがある。以下の擬似コードIに示す最初の例では、投機的なチェックポイント命令を、通常のループ実行か、投機的なチェックポイントへのロールバック後の再実行かを差別化することができる条件分岐命令と対にする。分岐命令は、実行されると、前のチェックポイントの状態にロールバックするための任意の公知の方法でロールバックを処理することができる。下の擬似コードJに示す別の例では、一部の実施形態で説明されたように、投機的なチェックポイント命令を分岐命令と組み合わせて、1つのチェックポイントと分岐命令とすることができる。擬似コードGの説明に戻ると、一実施形態では、投機的なチェックポイントコードが修正を含みロールバック、復元、再構成、復帰等と称される場合もある、実行されると、チェックポイント格納構造の最新のチェックポイントの正確な状態を復帰または復元する。一部の実施形態では、上述した他のシナリオも、投機的なチェックポイントコードおよび/または修正と捉えられる場合がある。しかしここでは、擬似コードGに示すように、修正コードが、トランザクション/アトミック領域にコミットするためのコミットコードB6も含むことができる、とする。本質的には、投機的なチェックポイントコードが、投機的なハードウェアのチェックポイントを実行する。投機的なハードウェアがなくなること、または、アボートを生じさせるイベントに遭遇すること割り込み、動的なアサート、メモリエイリアスチェック等が生じると、チェックポイントコードが、投機的なハードウェアの正確な状態を復元する。代替策として、再実行および継続した実行のために、投機的なハードウェアを解放するべく、トランザクションにコミットしてもよい。従い、修正コードを得る方法は複数あることが分かるだろう。いくつかの例として、1チェックポイント格納構造が投機的ハードウェアチェックポイントに十分なスペースを有さない場合、投機的なチェックポイント処理を実行する、2投機的なハードウェアに対応できない投機的な処理を実行する、3投機的な実行中の例外、または、4トランザクション内の一時的な内部チェックポイントになりうる任意の他のイベントから修正コードを入力することができる。さらに、投機的なチェックポイントを条件コミットと組み合わせると、投機的リソースがないのでアボートが回避され、且つ、チェックポイント実行で、不備、例外、その他の予測不可能な事象をアトミック領域の開始の代わりにチェックポイントに戻るとき実行をあまり無駄にしない、ということより安価なものとすることができ、さらなる利点が得られる。以下の擬似コードKは、これら組み合わせの一例を示している。さらに一実施形態では、以下の擬似コードLのように、条件コミット命令に、投機的チェックポイントを認識させる。この場合、システムにリソースがなくなると上述したとおりである、または、ロールバックリプレーが実行されると実行が投機的チェックポイントにロールバックした後で、region_check条件コミット命令は、L2にジャンプする。加えて、投機的チェックポイントおよび条件コミット命令を一緒に利用するだけでなく、一実施形態では、これら命令自身が組み合わせられて、以下の擬似コードMとして記述される。ここで、組み合わせられた命令が実行されるとき、チェックポイントを行い、条件コミットを評価するハードウェアリソースなくなりかけていたり、少なくなっていたりする状態であれば、コミットする。ここで、もしシステムの投機的リソースが少なくなった場合、または実行が記録されている投機的なチェックポイントにロールバックした場合には、実行はL2にジャンプして、この例では投機的リソースにコミットして最終的な欠陥に対処することで対処する。前述した説明は、ハードウェアが少なくなってきたとき、不備が検知された場合、例外が生じたとき、またはその他の予測不能なイベントが割り込みを生じたときに前のまたは最近の投機的なチェックポイントにロールバックすることに関していたが、これらの割り込みに応じて他の経路を探すこともできる。一実施形態では、割り込みが生じると、ハードウェア、ソフトウェア、またはこれらの組み合わせで、次に何をするかが決定される。例えば、ハードウェアが不備のある/イベントを生成した場合等、不備がアトミック実行中に生じたと想定する。アトミック実行が中断される。通常は制御がソフトウェアに渡されて、不備の種類が判断され、不備に対する対処が行われる。ここで、ハンドラ等のソフトウェアが、不備の種類、最新の投機的なチェックポイントにロールバックする難しさ、最新の投機的なチェックポイントではなく末尾のコミット点にロールバックすることで失われる実行量または命令数、または、戻るためのプログラムの実行点を選択する際に考慮するその他の要素等、任意の数の要素に基づいて次にすべきことを決定してよい。本質的に、この例では、ハンドラ等のソフトウェアが、実行がアトミック領域の最初、アトミック領域の末尾のコミット点、または、アトミック領域の最新の投機的なチェックポイントのいずれにロールバックすべきかを決定している。例では決定を行うソフトウェアに着目されているが、ハードウェアも決定を行う。一実施形態では、新たな命令speculative_rollbackが決定に利用される。ここでspeculative_rollback命令が、プログラムコードの適切なもの投機的なチェックポイントまたは最近のコミット点に戻すための結果をデコードおよび実行した任意の情報を含んでいる。ここで記載するコードは、同じブロック、領域、プログラム、またはメモリ空間内に連結される必要はない。実際、投機的なチェックポイント処理は、主要なプログラムコード内のループバックエッジに挿入されてよい。一番近いチェックポイントにロールバックし、任意でトランザクションにコミットするコードを含む修正コードが、コードのライブラリまたはその他の部分に配置されてよい。ここでは、主要なプログラムコードが実行中である。修正コードが入力されると、ライブラリコードの1以上の関数の呼び出しを実行して、ロールバックおよびコミットを実行する。さらに、ハードウェアは、ソフトウェアの命令なしに同様のチェックポイント処理を実行してよい。ここで、ハードウェアはトランスペアレントに例えば周期的に、またはイベント駆動ベースで投機的なハードウェアをチェックポイント実行してよい。投機的なハードウェアがなくなると、プロセッサは実行を最新のチェックポイントにロールバックして、トランザクションにコミットして、トランザクションを再開して、チェックポイントとロールバック点との間の命令をリプレーする。ソフトウェアの観点からは、通常の実行が続いているよう見えるが、ハードウェアは、リソースの制約および再実行の全てを処理している。しかし、ハードウェアとソフトウェアとの間の任意のレベルの協力を利用して、ローカルな内部トランザクション的チェックポイントを達成することができる。図7aに戻ると、ブロック730で、プログラムコードのセクションを最適化する。以下の擬似コードNが、最適化後の擬似コードMからのコード領域の一例を示している。最適化の別の例として、以下の擬似コードOが、別の最適化の例を示している擬似コードGのコード領域の最適化。上述したように、任意の公知の最適化技術をアトミック領域内のコードに実行することができる。コード最適化の数例としては全部を網羅することは意図しておらず、純粋に例示を目的としている、PRLE,PDSE,ループ最適化、データフロー最適化、コード生成最適化、デマケーションチェック除去、分岐オフセット最適化、デッドコード除去、およびジャンプスレッドが含まれる。擬似コードOでは、B6にコミットした後で、B6で別のトランザクションが開始され、B2で実行が引き続き行われる。他の実施形態不図示では、B3でコードを再入力する。アトミック領域のデマケーションおよび条件コミットコードの挿入も、一部の実施形態ではプログラムコードの最適化とみなすことができる。次に図8に戻ると、トランザクションの実行中に投機的にメモリをチェックポイント実行する方法のフロー図の一実施形態が示されている。フロー805で、トランザクションを実行する。一例として、トランザクションが、ランタイム中に動的に最適化されるバイナリコードとされて、コード最適化の周りにトランザクションを挿入して、アトミック性能を保つ。フロー810で、トランザクションからの投機的なチェックポイント命令に遭遇する。投機的なチェックポイント命令がさらに最適化装置により投機的チェックのポイントにランタイム中に挿入されたことは、図7aから図7bを参照して上述したとおりである。プロセッサは、投機的チェックポイント命令を認識する通常は、予め指定され/定義されたオペレーションコードを検知するデコーダであってよい。投機的なチェックポイント命令に呼応して、フロー815で、投機的なレジスタファイルをチェックポイント投機的レジスタファイルにチェックポイント実行を行う。加えて、フロー820で、投機的なキャッシュには、格納バッファをチェックポイント実行するために十分なスペースが含まれているかが判断される。フロー825で、もし利用可能なスペースが十分な場合には、格納バッファを投機的なキャッシュにチェックポイント実行する。しかし十分なスペースがない場合には、修正/ロールバック手順以下で詳述するブロック845-855を実行する。この結果、トランザクションの実行中に短期のロールバックイベントに遭遇すると、現在の実行に利用されている投機的なレジスタファイルおよび格納バッファが、チェックポイント実行された状態に復元される。一例として、フロー830で、格納処理に遭遇する。フロー835で、格納バッファが利用可能なエントリ例えば格納処理のために割り当て可能なエントリ等を含むかを判断する。容易に利用可能なエントリが存在する場合、または、割り当て解除、再割り当てが可能なエントリが存在している場合には、そのエントリをブロック840で割り当てる。格納バッファエントリが利用可能ではない場合には、ロールバック手順を実行するブロック845-855。ロールバック/復元手順845-855は、前のチェックポイントからの正確なアーキテクチャ状態を復元するものである。ここでロールバックは、コミットされていないグローバルに見られる状態にされていない投機的実行中に生じる。従ってグローバルに見ることができる状態非投機的格納構造は同じ状態に留まる必要がある。しかし、現在の投機的な実行をサポートしている投機的なハードウェア構造が復元される。投機的なキャッシュは既に格納バッファから最新のチェックポイントまでの投機的な更新を保持しているので、格納バッファをブロック850でフラッシュする。言い換えると、トランザクションの最初から最近のチェックポイントまでの格納が投機的キャッシュに保持される。そして、最近のチェックポイントから現在の実行ユニットまでを、格納バッファに保持する。そして、ロールバックされた格納を、格納バッファから単にアボートする。加えて、投機的レジスタファイルをチェックポイントレジスタファイルから復元する。ここで投機的レジスタファイルは、最近のチェックポイントからのものを含むトランザクションの開始からの更新の全てを保持しており、投機的なレジスタファイルはチェックポイントレジスタファイルからの値でリロードされる。元のチェックポイントが投機的なレジスタファイル全体のコピーを含む場合投機的な実行中に修正されたレジスタのみを選択的に格納するだけでなく、チェックポイントレジスタファイルのラベルを、投機的なレジスタファイルとしてつけなおし利用し、前の投機的なレジスタファイルをフラッシュして、チェックポイントレジスタファイルとして後で利用する点に留意されたい。または、投機的なレジスタファイルを、投機的なチェックポイントレジスタファイルにフラッシュコピーする1またはいくつかのサイクルで。フロー860で、任意にトランザクションをコミットしてもよい。例外、投機的なキャッシュのスペース不足、または格納バッファのスペース不足により、ロールバック手順に達するので、トランザクションをコミットしてこれらリソースを解放する。ここで、格納バッファおよび投機的なキャッシュ更新は、非投機的なキャッシュメモリにコミットされ、これらリソースが解放されるフロー875-880。そして同様に投機的なレジスタファイルを非投機的なレジスタファイルにコミットして、さらなる投機的な実行用に解放するフロー875-880に示す。さらに、トランザクションの完全なアボートを実行して865、格納バッファおよび投機的なキャッシュをフラッシュして、ブロック870のトランザクション前の非投機的状態に復元する。図9を参照すると、投機的なチェックポイント実行をサポートするよう適合されたハードウェアの論理表現の一実施形態が示されている。デコーダデコード論理910を適合させ、または相互接続して、投機的なチェックポイント命令SCPI905を認識する。例えば、図9のハードウェアを含むプロセッサの命令の予め定義されたフォーマットが特定されて、ハードウェア内に設計される。特定のビットパターンを持つ命令の一部が特定の命令に対応しており、その1つがSCPI905である。次にSCPIに呼応して、投機的格納構造に格納されている投機的値935を、投機的チェックポイント格納構造の投機的チェックポイント値940としてチェックポイント実行する。実行論理920は、SCPI920を実行するデコーダに連結されたものとして示されている。しかし明らかにデコードと実行との間のパイプラインには数多くの段階が存在する。例えばSCPIは、1つのトレースキャッシュ内の処理トレースにデコードされてよく、これら処理はバッファにキュー待ち状態にされ、ここで記載する処理/方法を実行するためにスケジュール、ディスパッチ、および実行されてよい。簡単に上述したように、チェックポイントは、ある時点での値の状態のスナップショットを含み、または、少なくともその時点での値の状態を復元するために十分な情報を含む。従って、一実施形態では、チェックポイントが、投機的な値935全体の写しを投機的なチェックポイント値940として含む。投機的な値935は、投機的なレジスタファイルからの投機的なレジスタファイル値を含んでよく、投機的なチェックポイント値940は、時間的に最近のチェックポイント投機的なレジスタファイルのコピーを含む。別の例としては、投機的なチェックポイント値が、最後のチェックポイントから修正された投機的な値935のみを含む。ここで投機的な値935は、投機的なレジスタファイルからの投機的なレジスタファイル値を含んでよく、投機的なチェックポイント値940は、最後のチェックポイントから修正された投機的なレジスタファイル内のレジスタだけの最後のチェックポイントからの投機的なレジスタファイル値を含む。また別の例では、投機的なチェックポイント値940が、時間的にアトミック領域からチェックポイント時点までの値全てを含み、一方で、投機的な値935が、チェックポイントから現在の実行店までの投機的な値全てを含む。ここで、格納バッファが投機的な値935を保持してよく、これは投機的キャッシュに保持されている古い値最初から最後のチェックポイントまでに加えられる。図10を参照すると、レジスタファイルの投機的なチェックポイント実行をサポートするよう適合されているハードウェアの論理表現の別の実施形態を示す。上述の説明同様に、デコーダ1010および実行論理1020は、それぞれSCPI1005を受信して、認識して、実行するよう適合されている。SCPI1005に呼応して、投機的なレジスタファイル1035を投機的なチェックポイントレジスタファイル1040にチェックポイント実行する。上述したように、チェックポイントは、レジスタファイル1035のフラッシュコピーをチェックポイントレジスタファイル1040に含んでいてよい。または、ファイル1035のレジスタを修正する場合には、古い値をレジスタファイル1040にチェックポイント実行する。ここでSCPI1005に呼応して値をコピーする代わりに、ファイル1035の対応するものを修正したものをコピーした、ファイル1040からの古いチェックポイント値をクリアして、無効とする。実行が続けられる場合、修正されたレジスタを再度ファイル1040にチェックポイントとして入力する。ロールバック図8のブロック820等の投機的キャッシュのスペース不足、図8のブロック840等の格納バッファのスペース不足、例外、その他のロールバックイベントから最近のチェックポイントに呼応して、チェックポイント値修正版のみであっても全コピーであってもを、投機的チェックポイントレジスタファイル1040から投機的レジスタファイル1035に復元する。しかしトランザクション領域の最初の部分にロールバックがある場合例えばトランザクションのアボート等、一実施形態では、投機的なレジスタファイル1035を非投機的案レジスタファイル1030からリロードする。本質的に、投機的なファイル1035は、作業用の投機的なレジスタファイルである。従ってトランザクションは投機的なレジスタファイル1035とともに作動する読み出し、書き込み。トランザクションの最初でロードを再実行する場合、非投機的値をリロードしない場合、ロードは、アボート前に投機的なレジスタファイル1035に保持されていた、後に修正された投機的な値を不注意でロードしてしまう場合がある。加えて、トランザクションのコミットに呼応して、投機的レジスタファイル1035を非投機的レジスタファイル1030にコミットコピーする。ここでは、投機的な更新を非投機的な結果としてグローバルに見えるようにする。ここでもまた、レジスタファイル1035全体を非投機的なレジスタファイル1030にコピーしてよい。修正された投機的なレジスタファイル1035のレジスタだけを、非投機的なレジスタファイル1030にコピーしてよい。図11を参照すると、キャッシュメモリの投機的なチェックポイントをサポートするよう適合されたハードウェアの論理的表現の別の実施形態が示されている。図9から図10に関して上述したように、デコーダ1110および実行論理1120は、SCPI1105をデコードして実行するよう適合されている。ここで実行論理1120は、アトミック領域から投機的格納を実行するとき、投機的な更新を保持するために格納バッファ1140を利用する。ここで、前の格納からロードする同じ領域ローカルスレッドからのロードは、格納バッファ1140に保持されている投機的値からロードされる。従って、機内の同様のロード格納メカニズムを格納バッファ1140と実行論理1120のロード実行ユニットとの間で利用することができる。しかし、格納バッファ1140のストアのアドレスへの非投機または非ローカルのロードが、格納バッファ1140の値ではなく、キャッシュ1130に保持されている非投機の値を受ける。加えて、アトミック領域の読み出し/ロードから、チェックポイントされたり、投機的なキャッシュ1135に移動されたりしたストアのアドレスがある場合には、直接または格納バッファ1140経由で投機的なキャッシュ値がロードに提供されるべきである。SCPI1105に呼応して、バッファ1140内の格納バッファ更新が、投機的なキャッシュ1135に移動させられる。この結果、投機的なキャッシュ1135は、アトミック領域の最初から、最近のチェックポイントへの投機的な更新を保持する。そして格納バッファ1140が、最近のチェックポイントから現在の実行チェックポイントへの投機的更新を保持する。従ってアトミック領域がコミットされると、投機的キャッシュ1135および格納バッファ1140の全ての更新が、非投機的なキャッシュ1130にコミット/移動/コピーされる。例示したように、このコミットは、格納バッファ1140を投機的なキャッシュ1135に、および、投機的なキャッシュ1135を非投機的なキャッシュ1130にコミットすることで実行される。別の実施形態では、格納バッファ1140および投機的なキャッシュ1135両方からの更新を、非投機的なキャッシュ1130に直接提供することができる。コミット後、更新がグローバルに見えるようになり、メモリ階層1150を介して伝播されてよいより高いレベルのメモリおよびホーム位置に。さらに、本実施形態では、ローカルの内部ロールバックに呼応して、格納バッファ1140をフラッシュする。上述したように、本実施形態では、格納バッファ1140が本質的に最近のチェックポイントから現在の実行ポイントまでの更新を保持している。従いロールバックが生じると、これら更新はアボートされる。一例では、格納バッファ1140がアトミック領域からの新たな格納処理に対応できないことに呼応して図8のブロック840ローカルロールバックが開始されてもよい。ブロック820で、ロールバックは、投機的キャッシュ1135が満杯であり、SCPI1105に格納バッファ1140更新を行えない場合に開始されてもよい。しかし、アボートアトミック領域全体のロールバックが生じると、格納バッファ1140と投機的なキャッシュ1135の両方がアトミック領域から現在の実行点までの更新フラッシュされる。ここで利用するモジュールとは、ハードウェア、ソフトウェア、またはこれらの組み合わせのことであってよい。別個に描かれているモジュールのデマケーションは共通変化して、潜在的に重なっている。例えば第1モジュールおよび第2モジュールが、ハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせを含み、一方で、独立したハードウェア、ソフトウェア、ファームウェアを維持してもよい。一実施形態では、論理という用語の利用には、トランジスタ、レジスタ、その他のハードウェアプログラム可能論理デバイス等のハードウェアが含まれる。しかし別の実施形態では、論理に、ソフトウェアまたはハードウェアと集積されたコード例えばファームウェアまたはマイクロコードが含まれる。ここで利用する値とは、数、状態、論理状態、またはバイナリ論理状態の公知の表現形態を含む。論理レベル、論理値、または論理値は、1および0で表されることが多く、単にバイナリ論理状態を表している。例えば1は高論理状態を表し、0は低論理状態を表す。一実施形態では、格納セル例えばトランジスタまたはフラッシュセルは、1つの論理値または複数の論理値を保持することができてよい。しかしコンピュータシステムにおける他の値の表現形態をとってもよい。例えば10進法の数は1010のバイナリ値、または16進法の文字Aで表すことができる。従って値は、コンピュータシステムでの保持が可能な情報の任意の表現形態を含む。さらに、状態は値または値の部分で表すことができる。一例としては、第1の値例えば論理1が、初期値または最初の状態を表してよく、第2の値例えば論理0が、初期値ではない値を表してよい。加えて、リセットおよびセットという用語は、一実施形態では、初期値または更新値または状態と称される。例えば初期値は潜在的に高い論理値つまりリセットを含んでよく、一方で、更新値は、潜在的に低い論理値つまりセットを含んでよい。値の任意の組み合わせを利用することで任意の数の状態を表すことができる。上述した方法、ハードウェア、ソフトウェア、ファームウェア、またはコード処理エレメントが事項可能な機械アクセス可能または機械可読媒体に格納される命令またはコードを介して実装可能であってよい。機械アクセス可能/可読媒体は、機械例えばコンピュータまたは電子システムが可読な形態の情報を提供する格納する、および/または、送信する。例えば、機械アクセス可能媒体は、ランダムアクセスメモリ静的RAMSRAMまたは動的RAMDRAM、ROM、磁気または光格納媒体、フラッシュメモリデバイス、電気格納デバイス、光格納デバイス、音響格納デバイス、その他の形態の、伝播信号例えば搬送波、赤外線信号、デジタル信号等を保持するための格納デバイスであってよい。本明細書全体で、一実施形態1つの実施形態といった言い回しは、その実施形態との関連で記載されている特定の特徴、構造、または特性が、本発明に含まれる少なくとも1つの実装例に含まれることを意味している。従って、一実施形態1つの実施形態という言い回しが使われていても、これらが必ずしも同じ実施形態のことを言及しているわけではない。さらに、特定の特徴、構造、または特性は、記載された特定の実施形態以外の適切な形態で実装することもでき、これら全ての形態が本願の請求項の範囲に含まれることが意図されている。前述の明細書では、詳細な説明が特定の実施形態を参照していた。しかし、本発明の広義の精神および範囲から逸脱せずに、添付請求項に示すようなさまざまな変形例および変更例が可能であることは明らかである。従い明細書および図面は、限定的な意味ではなく例示的な意味で捉えられるべきである。さらに、前述した実施形態および例は、必ずしも同じ実施形態または同じ例のことばかりではなく、異なる別の実施形態のことを指している場合もあり、同じ実施形態である場合もある。"