コードを含む機械可読媒体であって、前記コードは、前記機械によって実行されたときに、前記機械に:最適化されるべきプログラムコードのセクションを同定する動作と;前記プログラムコードの前記セクション内の条件付きコミット点を決定する動作と;前記条件付きコミット点を決定することに応答して前記条件付きコミット点において条件付きコミット命令を挿入する動作と;最適化されるべきプログラムコードの前記セクションを同定することに応答してプログラムコードの前記セクションを最適化する動作とを実行させる、機械可読媒体。最適化されるべきプログラムコードのセクションを同定する動作が、前記プログラムコードの動的プロファイリングに基づき、条件付きコミット点を決定する動作が、前記プログラムコードの前記セクション内のループの先頭に前記条件付きコミット点を割り当てる、動的プロファイリングに基づいてある実行経路に前記条件付きコミット点を割り当てる、およびハードウェア資源を独占すると知られている実行経路に前記条件付きコミット点を割り当てる、からなる群より選択される割り当てアルゴリズムに基づく、請求項1記載の機械可読媒体。前記条件付きコミット命令が、実行されたときに、第一の分枝として、プログラムコードの前記セクションの実行を継続する、または、第二の分枝として、条件付きコミットコード位置にジャンプする条件付き分岐命令を含む、請求項1記載の機械可読媒体。前記コードが、前記機械によって実行されたときに、前記機械にさらに:プログラムコードの前記セクションの先頭に第一の領域開始命令を挿入する動作と;プログラムコードの前記セクションの末尾に第一のコミット命令を挿入する動作と;前記条件付きコミットコード位置に第二のコミット命令を挿入する動作と;前記第二のコミット命令後に、前記条件付きコミットコード位置における第二の領域開始命令を挿入する動作とを実行させる、請求項3記載の機械可読媒体。プログラムコードの前記セクションを最適化する動作が、前記第一および第二の領域開始命令より上にメモリ順序付けを破るロードを持ち上げることなく、かつ前記第一および第二のコミット命令より下にメモリ順序付けを破るストアを押し出すこともなく、コードの前記セクションを動的に最適化することを含む、請求項4記載の機械可読媒体。ランタイムの間にコードを動的に最適化する方法であって:最適化されるべきプログラムコードのセクションを同定する段階と;最適化されるべきプログラムコードの前記セクションを同定することに応答して、プログラムコードの前記セクションの少なくとも一部を原子的領域として画定する段階と;前記原子的領域内の条件付きコミット点を決定する段階と;前記条件付きコミット点を決定することに応答して前記条件付きコミット点において領域チェック命令を挿入する段階と;最適化されるべきプログラムコードの前記セクションを同定することに応答してプログラムコードの前記セクションを最適化する段階とを含む、方法。プログラムコードの前記セクションの少なくとも一部を原子的領域として画定する段階が、コードの前記セクションの前記一部の先頭に開始トランザクション命令を、コードの前記セクションの前記一部の末尾に終了トランザクション命令を挿入することを含む、請求項6記載の方法。プログラムコードの前記セクションを最適化する段階が、部分冗長性ロード消去PRLE、部分デッドストア消去PDSE、ループ最適化、データフロー最適化、コード生成最適化、境界チェック消去、分岐オフセット最適化、デッドコード消去およびジャンプ接続からなる群より選択される最適化技法を利用してコードの前記セクションを最適化することを含む、請求項6記載の方法。前記領域チェック命令が、実行されたときにハードウェアに問い合わせする条件付き分岐命令を含み、前記条件付き分岐命令は、前記ハードウェアの前記問い合わせへのあらかじめ定義された応答に応答して、早発premature領域コミット命令および領域再開命令に分岐するものである、請求項6記載の方法。前記領域チェック命令を挿入する段階が、前記プログラムコードの前記セクションの前記一部の中のループの先頭において行われ、前記領域チェック命令は前記ループの反復工程毎に実行される、請求項6記載の方法。コードを含む機械可読媒体であって、前記コードは、前記機械によって実行されたときに、前記機械に:動的に最適化されたプログラムコードを含むトランザクションを実行する動作と;前記トランザクションの終わりより前の領域チェック点において、前記トランザクションの実行をサポートするハードウェアユニットが前記トランザクションのある領域を完遂するための利用可能な十分な資源を含んでいるかどうかを判定する動作と;前記トランザクションの実行をサポートするハーウェアユニットの資源が少ないと判定することに応答して前記領域チェック点において前記トランザクションをコミットする動作とを実行させる、機械可読媒体。前記領域チェック点において前記トランザクションをコミットしたあと新たなトランザクションを開始することをさらに含む、請求項11記載の機械可読媒体。前記ハードウェアユニットが、ストアバッファ、ロードバッファ、キャッシュメモリおよびレジスタファイルからなる群より選択されるユニットを含む、請求項11記載の機械可読媒体。前記ハードウェアユニットがキャッシュメモリを含む請求項11記載の機械可読媒体であって、前記トランザクションの実行をサポートするハードウェアユニットが前記トランザクションの前記領域を完遂するための利用可能な十分な資源を含んでいるかどうかを判定する動作が:前記トランザクションの前記領域を完遂することにおいてタッチされると期待されるキャッシュラインの数を決定し;前記キャッシュメモリ中の利用可能なエントリーの数を決定し;期待されるキャッシュラインの数を利用可能なキャッシュラインの数と比較し;前記トランザクションの実行をサポートする前記キャッシュメモリが前記トランザクションの前記領域を完遂するための利用可能な十分な資源を含むかどうかを、期待されるキャッシュラインの数と利用可能なキャッシュラインの数との前記比較に基づいて、判定することを含む、機械可読媒体。前記領域を完遂することにおいてタッチされると期待されるキャッシュラインの数を決定することが、前記トランザクションに挿入されたコンパイラヒントに基づき、前記コンパイラヒントは、前記トランザクションの前記領域の以前の実行の動的プロファイリングに基づく、請求項14記載の機械可読媒体。コードを含む機械可読媒体であって、前記コードは、前記機械によって実行されたときに、前記機械に:最適化されるべきプログラムコードのセクションを同定する段階と;前記プログラムコードの前記セクション内の投機的チェックポイントを決定する段階と;前記投機的チェックポイントを決定することに応答して前記投機的チェックポイントにおいて投機的チェックポイントコードを挿入する動作と;最適化されるべきプログラムコードの前記セクションを同定することに応答してプログラムコードの前記セクションを最適化する動作とを実行させる、機械可読媒体。最適化されるべきプログラムコードのセクションを同定する動作が、前記プログラムコードの動的プロファイリングに基づき、投機的チェックポイントを決定する動作が、前記プログラムコードの前記セクション内のループの先頭に、前記プログラムコードの前記セクション内のループのループバック端に前記投機的チェックポイントを割り当てる、動的プロファイリングに基づいてある実行経路に前記投機的チェックポイントを割り当てる、ハードウェア資源を独占すると知られている実行経路に前記投機的チェックポイントを割り当てる、および、投機的ハードウェア資源の枯渇を回避するよう実行経路に前記投機的チェックポイントを割り当てる、からなる群より選択される割り当てアルゴリズムに基づく、請求項16記載の機械可読媒体。前記コードが、前記機械によって実行されたときに、前記機械にさらに:プログラムコードの前記セクションに原子的領域開始命令を挿入する動作と;プログラムコードの前記セクションに原子的領域終了命令を挿入する動作とをさらに実行させる、請求項16記載の機械可読媒体。前記投機的チェックポイントコードが投機的チェックポイント動作を含み、前記投機的チェックポイント動作は、実行されたときに、前記機械に、投機的レジスタファイルおよびストアバッファをチェックポイント記憶構造においてチェックポイント化させ、前記コードは、前記機械によって実行されたとき、前記機械に、コードの前記セクションの実行中に前記ストアバッファの資源が尽きることに応答して前記投機的レジスタファイルの前記チェックポイントにロールバックするフィックスアップコードを挿入する動作をさらに実行させる、請求項16記載の機械可読媒体。プログラムコードの前記セクションを最適化する動作が、部分冗長性ロード消去PRLE、部分デッドストア消去PDSE、ループ最適化、データフロー最適化、コード生成最適化、境界チェック消去、分岐オフセット最適化、デッドコード消去およびジャンプ接続からなる群より選択される最適化技法を利用してコードの前記セクションを最適化することを含む、請求項16記載の機械可読媒体。最適化されるべきプログラムコードのセクションを同定する段階と;最適化されるべきプログラムコードの前記セクションを同定することに応答して、プログラムコードの前記セクションの少なくとも一部を原子的領域として画定する段階と;前記原子的領域内の投機的チェックポイントを決定する段階と;前記投機的チェックポイントを決定することに応答して前記投機的チェックポイントにおいて投機的チェックポイントコードを挿入する段階と;最適化されるべきプログラムコードの前記セクションを同定することに応答してプログラムコードの前記セクションを最適化する段階とを含む、方法。プログラムコードの前記セクションの少なくとも一部を原子的領域として画定する段階が、コードの前記セクションの前記一部の先頭に開始トランザクション命令を、コードの前記セクションの前記一部の末尾に終了トランザクション命令を挿入することを含む、請求項21記載の方法。前記投機的チェックポイントコードが投機的チェックポイント動作を含み、前記投機的チェックポイント動作は、実行されたときに、前記機械に、投機的レジスタファイルを投機的チェックポイントレジスタファイルにおいてチェックポイント化させ、ストアバッファを投機的キャッシュにおいてチェックポイント化させ、前記コードは、前記機械によって実行されたとき、前記機械に、コードの前記セクションの前記一部の実行中に前記投機的キャッシュまたは前記ストアバッファの資源が尽きることに応答して前記投機的チェックポイントレジスタファイルに保持されている前記投機的レジスタファイルの前記チェックポイントにロールバックするフィックスアップコードを挿入する動作をさらに実行させる、請求項21記載の方法。コードの前記セクションの前記一部の実行中に前記ストアバッファの資源が尽きることは:前記ストアバッファがコードの前記セクションの前記一部の実行の間に利用可能なエントリーを全く含まないことであり、前記投機的キャッシュの資源が尽きることは:前記投機的キャッシュが、前記機械が前記投機的チェックポイント動作を実行する際に前記ストアバッファからのエントリーを保持するための十分な利用可能なエントリーを含まないことである、請求項23記載の方法。プログラムコードの前記セクションを最適化する動作が、部分冗長性ロード消去PRLE、部分デッドストア消去PDSE、ループ最適化、データフロー最適化、コード生成最適化、境界チェック消去、分岐オフセット最適化、デッドコード消去およびジャンプ接続からなる群より選択される最適化技法を利用してコードの前記セクションを最適化することを含む、請求項21記載の方法。コードを含む機械可読媒体であって、前記コードは、前記機械によって実行されたときに、前記機械に:動的に最適化されたプログラムコードを含むトランザクションを実行する動作と;前記トランザクション内のチェックポイントにおいて、投機的レジスタファイルをチェックポイントレジスタファイル中にチェックポイント化する動作と;前記トランザクションの実行をサポートするハードウェアユニットの資源が少ないことを判別する動作と;前記ハーウェアユニットの資源が少ないことを判別することに応答して前記チェックポイントレジスタファイルを前記投機的レジスタファイル中に復元し、前記ストアバッファをフラッシュする動作とを実行させる、機械可読媒体。前記トランザクション内のチェックポイントにおいて、投機的レジスタファイルをチェックポイントレジスタファイル中にチェックポイント化する動作が、投機的チェックポイント命令の実行に応答して行われ、前記コードは、前記機械によって実行されたとき、前記機械に、やはり投機的チェックポイント命令の実行に応答して、前記トランザクション内の前記チェックポイントにおいて、ストアバッファを投機的キャッシュ中にチェックポイント化する動作をさらに実行させる、請求項26記載の機械可読媒体。前記ハードウェアユニットが前記ストアバッファを含み、前記トランザクションの実行をサポートするハードウェアユニットの資源が少ないことを判別する動作が、前記トランザクションからのストアに遭遇する際に前記ストアバッファの資源が少なく、前記ストアバッファが利用可能なストアバッファエントリーを含まないことを判別することを含む、請求項27記載の機械可読媒体。前記ハードウェアユニットが投機的キャッシュをも含み、前記トランザクションの実行をサポートするハードウェアユニットの資源が少ないことを判別する動作が、やはり投機的チェックポイント命令の実行に応答して、前記トランザクション内の前記チェックポイントにおいて、前記ストアバッファを前記投機的キャッシュ中にチェックポイント化する際に、前記ストアバッファからのエントリーを保持するために十分な利用可能なエントリーを前記投機的キャッシュが含まないことに応答して、前記投機的キャッシュの資源が少ないことを判別することを含む、請求項28記載の機械可読媒体。前記コードが、前記機械によって実行されたとき、前記機械に、前記ハーウェアユニットの資源が少ないことを判別することに応答して前記チェックポイントレジスタファイルを前記投機的レジスタファイル中に復元し、前記ストアバッファをフラッシュすることに応答して、前記トランザクションの一部の領域コミットを実行する動作を実行させる、請求項26記載の機械可読媒体。前記ハーウェアユニットの資源が少ないことを判別することに応答して前記チェックポイントレジスタファイルを前記投機的レジスタファイル中に復元し、前記ストアバッファをフラッシュする動作が:前記ハーウェアユニットの資源が少ないことを判別し、前記ハードウェアユニットに関連する因子に基づいて、前記復元が、最も最近のコミットされた点ではなく前記チェックポイントレジスタファイルに関連するチェックポイントまでであることを判別するコードを実行し、前記復元が前記チェックポイントレジスタファイルに関連する前記チェックポイントまでであることを判別するのに応答して、前記チェックポイントレジスタファイルを前記投機的レジスタファイル中に復元し、前記ストアバッファをフラッシュすることを含む、請求項26記載の機械可読媒体。投機的チェックポイント命令をデコードしてデコードされた投機的チェックポイント命令を得るよう適応されたデコード論理と;デコードされた投機的チェックポイント命令を実行するよう適応された実行論理と;最適化されたコードを含むことになるソフトウェアスレッドの原子的領域の開始前から前記ソフトウェアスレッドに関連付けられた非投機的な値を保持するよう適応された第一のメモリと;前記原子的領域の実行中および前記デコードされた投機的チェックポイント命令が前記実行論理によって実行されたあとに、前記ソフトウェアスレッドに関連付けられた投機的な値を保持するよう適応された第二のメモリと;前記実行論理が前記デコードされた投機的チェックポイント命令を実行するのに応答して前記第二のメモリからの投機的チェックポイント値を保持するよう適応された第三のメモリとを有する、装置。前記第一のメモリが非投機的レジスタファイルを含み、前記第二のメモリが投機的レジスタファイルを含み、前記第三のメモリが投機的チェックポイントレジスタファイルを含む、請求項32記載の装置。前記投機的レジスタファイルが前記原子的領域の実行中および前記デコードされた投機的チェックポイント命令が前記実行論理によって実行されたあとに、前記ソフトウェアスレッドに関連付けられた投機的な値を保持するよう適応されていることが、前記投機的レジスタファイルが、前記原子的領域の実行中および前記デコードされた投機的チェックポイント命令が前記実行論理によって実行されたあとに、前記ソフトウェアスレッドに関連付けられた投機的なアーキテクチャ状態値を保持するよう適応されていることを含み、前記投機的チェックポイントレジスタファイルが前記実行論理が前記デコードされた投機的チェックポイント命令を実行するのに応答して前記投機的レジスタファイルからの投機的チェックポイント値を保持するよう適応されていることが、前記投機的チェックポイントレジスタファイルが、前記実行論理が前記投機的レジスタファイルからの前記投機的チェックポイント命令を実行する際に、前記ソフトウェアスレッドに関連付けられたアーキテクチャ状態値を、投機的チェックポイントアーキテクチャ状態値として前記投機的チェックポイントレジスタファイル中にロードするよう適応されていることを含む、請求項33記載の装置。不十分なハードウェア資源に基づく、前記投機的チェックポイント命令に関連付けられたチェックポイントへのロールバックに応答して、前記投機的チェックポイントレジスタファイル中に保持されることになる前記投機的チェックポイントアーキテクチャ状態値が前記投機的レジスタファイル中に再ロードされ;前記原子的領域のコミットに応答して、前記投機的レジスタファイル中に保持されることになる前記投機的アーキテクチャ状態値が前記非投機的レジスタファイル中にロードされ;前記原子的領域の始まりへのロールバックに応答して、前記非投機的レジスタファイル中に保持されることになる前記非投機的な値が、前記投機的レジスタファイル中にロードされる、請求項32記載の装置。前記第一のメモリがキャッシュメモリを含み、前記第二のメモリがバッファを含み、前記第三のメモリが投機的キャッシュメモリを含む、請求項32記載の装置。前記バッファが前記原子的領域の実行中および前記デコードされた投機的チェックポイント命令が前記実行論理によって実行されたあとに、前記ソフトウェアスレッドに関連付けられた投機的な値を保持するよう適応されていることが、前記バッファが、前記原子的領域の実行中および前記デコードされた投機的チェックポイント命令が前記実行論理によって実行されたあとに、前記ソフトウェアスレッドに関連付けられた投機的なメモリ値を保持するよう適応されていることを含み、前記投機的キャッシュメモリが前記実行論理が前記デコードされた投機的チェックポイント命令を実行するのに応答して前記バッファからの投機的チェックポイント値を保持するよう適応されていることが、前記投機的キャッシュメモリが、前記実行論理が前記バッファからの前記投機的チェックポイント命令を実行する際に、前記ソフトウェアスレッドに関連付けられた投機的なメモリ値を、投機的チェックポイントメモリ値として前記投機的キャッシュメモリ中にロードするよう適応されていることを含む、請求項32記載の装置。前記原子的領域のコミットに応答して、前記バッファおよび前記投機的キャッシュが、前記投機的メモリ値および前記投機的チェックポイントメモリ値を前記キャッシュメモリ中にロードするよう適応されており;前記投機的チェックポイント命令に関連付けられたチェックポイントへのロールバックに応答して、前記バッファがフラッシュされるよう適応されており;前記原子的領域より前の点へのロールバックに応答して、前記バッファおよび前記投機的キャッシュがフラッシュされるよう適応されている、請求項32記載の装置。前記デコード論理、実行論理、第一のメモリ、第二のメモリおよび第三のメモリが複数処理要素のマイクロプロセッサ内に含まれており、前記複数処理要素のマイクロプロセッサは、同期的動的ランダムアクセスメモリSDRAM:SynchronousDynamicRandomAccessMemory、読み出し専用メモリROMおよびフラッシュメモリからなる群より選択されるシステムメモリを含むコンピュータシステム内に結合されるよう適応されている、請求項32記載の装置。投機的チェックポイント命令をデコードしてデコードされた投機的チェックポイント命令を得るよう適応されたデコード論理と;デコードされた投機的チェックポイント命令を実行するよう適応された実行論理と;原子的領域の実行中の投機的更新を保持するよう適応されたストアバッファと;前記実行論理が前記デコードされた投機的チェックポイント命令を実行するのに応答して前記ストアバッファからの前記投機的更新をチェックポイント化するよう適応された投機的キャッシュと;前記原子的領域の始まりより前からの非投機的な値を保持するよう適応された非投機的キャッシュとを有しており、前記原子的領域のコミットに応答して、前記投機的キャッシュからの前記投機的更新が前記非投機的キャッシュ中にロードされる、装置。前記投機的キャッシュおよび前記ストアバッファが、前記原子的領域のコミットに応答して、投機的更新をもって前記非投機的キャッシュを更新するようさらに適応されている、請求項40記載の装置。前記ストアバッファがさらに、前記投機的チェックポイント命令に関連付けられたチェックポイントへのロールバックまたは前記原子的領域の始まりへのロールバックに応答してフラッシュされるよう適応されている、請求項40記載の装置。前記投機的キャッシュがさらに、前記原子的領域の始まりへのロールバックに応答してフラッシュされるよう適応されている、請求項42記載の装置。前記投機的キャッシュがさらに、前記投機的キャッシュが前記ストアバッファからの前記投機的更新を保持するための十分なエントリーを含まないことに応答して、前記ストアバッファからの前記投機的更新の前記チェックポイントを完遂するために十分な投機的キャッシュエントリーが利用可能でないことを示すよう適応されており;前記ストアバッファがさらに、前記原子的領域からのストアに遭遇する際にストアバッファエントリーが利用可能でないことに応答して、ストアバッファエントリーが利用可能でないことを示すよう適応されており;前記原子的領域内のチェックポイントへのロールバックは、前記投機的キャッシュが、前記ストアバッファからの前記投機的更新の前記チェックポイントを完遂するために十分な投機的キャッシュエントリーが利用可能でないことを示すこと、または、前記ストアバッファが、前記原子的領域からのストアに遭遇する際にストアバッファエントリーが利用可能でないことに応答して、ストアバッファエントリーが利用可能でないことを示すことに応答して開始される、請求項43記載の装置。前記非投機的キャッシュがさらに、前記原子的領域からの投機的読み出しに応答してロードバッファにエントリーを与えるよう適応されている、請求項42記載の装置。前記非投機的キャッシュがより上位レベルのメモリからのラインをキャッシュするよう適応されており、前記より上位レベルのメモリは:同期的動的ランダムアクセスメモリSDRAM:SynchronousDynamicRandomAccessMemory、読み出し専用メモリROMおよびフラッシュメモリからなる群より選択されるシ、請求項42記載の装置。この最適化は単一スレッド環境では機能するかもしれないが、複数スレッドアプリケーションでは、他のスレッドがループ実行の間にr2またはr24におけるメモリへの書き込み/該メモリからの読み出しを行うことがある。これは潜在的には、メモリ操作の実行順の変更のため、無効な実行につながる。本発明は例として付属の図面の図によって例解されるが、該図によって限定されることは意図されていない。以下の記述では、本発明の十全な理解を与えるために、個別的な型のプロセッサコア、個別的なプロセッサ構成、個別的な命令型、個別的なハードウェア構造、個別的なコード最適化技法などの例のような数多くの個別的詳細が記載されるが、当業者にとって、これらの個別的詳細が本発明を実施するために用いられることは必須ではないことは明白であろう。一方、個別的および代替的なプロセッサアーキテクチャ、記載されるアルゴリズムのための個別的論理回路/コード、個別的なコード実装、個別的なコンパイラ詳細およびマイクロプロセッサの他の個別的な動作の詳細といったよく知られた構成要素または方法は、本発明を無用に埋没させるのを避けるため、詳細には記述しなかった。本稿に記載される方法および装置は、ハードウェア制約条件に基づいて動的にサイズを決められるトランザクションを利用してコードを最適化するためのものである。具体的には、コードの最適化は、ハードウェア制約条件を利用する投機的なチェックポイント作成および/またはトランザクションの条件付きコミットに関して論じられる。しかしながら、本稿に記載される装置および方法は、それに限定されるものではなく任意の形の動的にサイズを決められるトランザクションにおいて実装されうる。たとえば、コードの最適化は、静的にも動的にも、またハードウェア、ソフトウェアまたはそれらの組み合わせの中で、実行されうる。図1を参照するに、複数コアを含むプロセッサのある実施形態が示されている。プロセッサ100は、マイクロプロセッサ、組み込みプロセッサ、デジタル信号プロセッサDSPdigitalsignalprocessor、ネットワークプロセッサまたはコードを実行する他の装置といった任意のプロセッサを含む。ある実施形態では、プロセッサ100は、少なくとも二つのコア――コア101および102――を含む。これらは非対称的なコアまたは対称的なコア図示した実施形態を含みうる。しかしながら、プロセッサ100は、対称的であっても非対称的であってもよい任意の数の処理要素を含んでいてよい。ある実施形態では、処理要素は、スレッドユニット、スレッドスロット、プロセスユニット、コンテキスト、論理プロセッサ、ハードウェアスレッド、コアおよび/または実行状態またはアーキテクチャ状態のようなプロセッサのための情報を保持することのできる他の任意の要素を指す。換言すれば、ある実施形態での処理要素は、ソフトウェアスレッド、オペレーティングシステム、アプリケーションまたは他のコードのようなコードに、独立して関連付けられることのできる任意のハードウェアを指す。物理的なプロセッサは典型的には集積回路を指す。集積回路は、潜在的には、コアまたはハードウェアスレッドのような任意の数の他の処理要素を含む。コアはしばしば、それぞれが少なくともいくつかの専用の実行資源に関連付けられる独立したアーキテクチャ状態を維持することのできる、集積回路上に位置される論理を指す。コアとは対照的に、ハードウェアスレッドは典型的には、実行資源へのアクセスを共有する独立したアーキテクチャ状態を維持することのできる集積回路上に位置される任意の論理を指す。見て取れるように、ある種の資源が共有され、他の資源があるアーキテクチャ状態に専用であるとき、ハードウェアスレッドとコアの命名法の間の境界線には重なりがある。それでも、コアおよびハードウェアスレッドはしばしば、オペレーティングシステムによって、個々の論理プロセッサと見られる。ここで、オペレーティングシステムは各論理プロセッサ上の動作を個々にスケジュールすることができる。図1に示されるような物理的プロセッサ100は二つのコア、コア101および102を含む。ここで、コア101および102は対称的コア、すなわち同じ構成、機能ユニットおよび/または論理をもつコアと考えられる。もう一つの実施形態では、コア101は順序外outoforderプロセッサコアを含み、一方、コア102は順序内inorderプロセッサコアを含む。しかしながら、コア101および102は、ネイティブコア、ソフトウェア管理されるコア、ネイティブなnative命令セットアーキテクチャISAInstructionSetArchitectureを実行するよう適応されたコア、変換されたtranslated命令セットアーキテクチャISAを実行するよう適応されたコア、協調設計されたcodesignedコアまたは他の既知のコアといった任意の型のコアから個々に選択されてもよい。しかしながら、今の議論を進める上で、コア101において示される機能ユニットについて以下で詳述する。コア102における諸ユニットは同様の仕方で動作するからである。描かれているように、コア101は二つのハードウェアスレッド101aおよび101bを含む。これらはハードウェアスレッドスロット101aおよび101bと称されてもよい。したがって、オペレーティングシステムのようなソフトウェアエンティティは、ある実施形態では、潜在的に、プロセッサ100のことを四つの別個のプロセッサ、すなわち四つのソフトウェアスレッドを並行して実行することができる四つの論理プロセッサまたは処理要素と見る。上記で言及したように、第一のスレッドはアーキテクチャ状態レジスタ101aに関連付けられ、第二のスレッドはアーキテクチャ状態レジスタ101bに関連付けられ、第三のスレッドはアーキテクチャ状態レジスタ102aに関連付けられ、第四のスレッドはアーキテクチャ状態レジスタ102bに関連付けられてもよい。図示したように、アーキテクチャ状態レジスタ101aはアーキテクチャ状態レジスタ101bに複製され、よって個々のアーキテクチャ状態/コンテキストは、論理プロセッサ101aおよび論理プロセッサ101bについて記憶されることができる。コア101では、命令ポインタおよび名前変更割り当て器論理renameallocaterlogic130における名前変更論理のような他のより小さな資源もスレッド101aおよびスレッド101bについて複製されてもよい。並べ替え/リタイアユニット135内の並べ替えバッファ、ITLB120、ロード/ストアバッファおよび待ち行列のようないくつかの資源は、パーティショニングを通じて共有されてもよい。汎用内部レジスタ、ページテーブルベースレジスタ、低レベルデータキャッシュおよびデータTLB115、実行ユニット単数または複数140および順序外ユニット135の諸部分のような他の資源は潜在的に完全に共有される。プロセッサ100はしばしば、完全に共有されていても、パーティショニングを通じて共有されても、または処理要素によって/処理要素に専用にされてもよい他の資源を含む。図1では、純粋に例示的なプロセッサのある実施形態が、プロセッサの例示的な論理ユニット/資源とともに示されている。プロセッサはこれらの機能ユニットの任意のものを含んだりまたは省略したりしてもよいし、また、図示しない他の任意の既知の機能ユニット、論理またはファームウェアを含んでいてもよい。図示したように、コア101は単純化された、代表的な順序外OOOプロセッサコアを含む。OOOコアは、実行されるべき/取られるべき分岐を予測するための分岐ターゲットバッファ120および命令のためのアドレス変換エントリーを記憶するための命令変換バッファITLBinstructiontranslationbuffer120を含む。コア101はさらに、フェッチされた要素をデコードするためのフェッチユニットに結合されたデコードモジュール125を含む。フェッチ論理はある実施形態では、それぞれスレッドスロット101a、101bに関連付けられた個々のシーケンサを含む。通例、コア101は、プロセッサ100上で実行可能な命令を定義/指定する第一の命令セットアーキテクチャISAに関連付けられる。ここで、しばしば、第一のISAの一部である機械コード命令は、該命令の、実行されるべき命令または動作を参照/指定する部分であるオペコードと称される。デコード論理125は、これらの命令をそのオペコードから認識し、デコードされた命令を、第一のISAによって定義されるような処理のためにパイプラインにおいて先に渡す回路を含む。たとえば、のちにより詳細に論じるように、デコーダ125はある実施形態では、条件付きコミット命令および/または投機的チェックポイント命令のような特定の新しい命令を認識するよう設計または適応された論理を含む。デコーダ125による認識の結果として、アーキテクチャまたはコア101は、適切な命令に関連付けられたタスクを実行するための、特定のあらかじめ定義されたアクションを行う。一例では、割り当て器および名前変更器ブロック130は、命令処理結果を記憶するためのレジスタファイルのような資源をリザーブするための割り当て器を含む。しかしながら、スレッド101aおよび101bは潜在的に、順序外実行をできる。ここでは、割り当て器および名前変更器ブロック130は、命令結果を追跡するための並べ替えバッファのような他の資源をもリザーブする。ユニット130はまた、プログラム/命令参照レジスタをプロセッサ100内部の他のレジスタに名前変更するレジスタ名前変更器をも含んでいてもよい。並べ替え/リタイアユニット135は、順序外実行および順序外で実行された命令の、のちの順序内リタイアをサポートするために、上述した並べ替えバッファ、ロードバッファおよびストアバッファのようなコンポーネントを含む。スケジューラおよび実行ユニット単数または複数ブロック140はある実施形態では、実行ユニット上の命令/動作をスケジュールするスケジューラユニットを含む。たとえば、浮動小数点命令が、利用可能な浮動小数点実行ユニットをもつ実行ユニットのポート上でスケジュールされる。実行ユニットに関連付けられたレジスタファイルも、情報命令処理結果を記憶するために含められる。例示的な実行ユニットは浮動小数点実行ユニット、整数実行ユニット、ジャンプ実行ユニット、ロード実行ユニット、ストア実行ユニットおよび他の既知の実行ユニットを含む。より低レベルのデータキャッシュおよびデータ変換バッファDTLB150が実行ユニット単数または複数140に結合される。データキャッシュは、データオペランドのような、最近使用された/作用された要素を記憶する。記憶される要素は潜在的にはメモリコヒーレンシー状態に保持される。DTLBは最近の仮想/線形アドレスから物理アドレスへの変換を記憶する。具体例として、プロセッサは、物理的なメモリを複数の仮想ページに分解するページテーブル構造を含んでいてもよい。ここで、コア101および102は、最近フェッチされた要素をキャッシュする、より高いレベルまたはより外側のキャッシュ110へのアクセスを共有する。より高いレベルまたはより外側というのは、実行ユニットから増大するまたはより遠くに行くキャッシュレベルを指すことを注意しておく。ある実施形態では、より高いレベルのキャッシュ110は、第二または第三レベルのデータキャッシュのような、最終レベルデータキャッシュ――プロセッサ100上のメモリ階層における最後のキャッシュ――である。しかしながら、より高いレベルのキャッシュ110はそれに限定されるものではなく、命令キャッシュに関連付けられたり命令キャッシュを含んでいたりしてもよい。代わりに、最近デコードされたトレースを記憶するために、トレースキャッシュ――命令キャッシュの一つの型――がデコーダ125のあとに結合されてもよい。図示した構成では、プロセッサ100は、システムメモリ175、チップセット、ノースブリッジまたは他の集積回路といったプロセッサ100の外部の装置と通信するためのバスインターフェースモジュール105をも含む。メモリ175はプロセッサ100の専用であってもよいし、またはシステム内の他の装置と共有されていてもよい。メモリ175の一般的な型の例は、動的ランダムアクセスメモリDRAM、静的RAMSRAM、不揮発性メモリNVメモリおよび他の既知の記憶装置を含む。ある実施形態では、プロセッサ100はハードウェアトランザクション実行、ソフトウェアトランザクション実行または両者の組み合わせもしくはハイブリッドの機能をもつ。コードのクリティカルまたは原子的アトミックなセクション/領域とも称されうるトランザクションtransactionは、原子的なグループとして実行される命令、動作またはマイクロ動作のまとまりを含む。たとえば、トランザクションまたはクリティカルなセクションを画定するために命令または動作が使われてもよい。のちにより詳細に述べるある実施形態では、これらの命令は、上記のデコーダのようなプロセッサ100のハードウェアによって認識可能な、命令セットアーキテクチャISAのような命令のセットの一部である。しばしば、これらの命令は、ひとたび高水準言語からハードウェアに認識可能なアセンブリー言語にコンパイルされたら、動作コードオペコードまたは該命令の他の部分を含み、それをデコード段の間にデコーダが認識する。典型的には、トランザクションの実行中、メモリへの更新は、トランザクションがコミットされるまでグローバルに可視にはされない。たとえば、ある位置へのトランザクション書き込みは、ローカルなスレッドに対して潜在的に可視であるが、そのトランザクション書き込みを含むトランザクションがコミットされるまでは、別のスレッドからの読み出しに応答して書き込みデータは転送されない。トランザクションがいまだペンディングである間は、メモリ内からロードされ、メモリ内に書き込まれるデータ項目/要素は追跡される。これについてはのちにより詳細に論じる。ひとたびトランザクションがコミット点に達すると、そのトランザクションについて衝突が検出されていなければ、そのトランザクションはコミットされ、そのトランザクション中になされた更新がグローバルに可視にされる。しかしながら、そのトランザクションがペンディング中に無効にされる場合、そのトランザクションはアボートされ、潜在的には、更新をグローバルに可視にすることなく改めて開始される。結果として、本稿で用いるところでのトランザクションのペンディング状態は、実行を開始しており、まだコミットもアボートもされていない、すなわちペンディングであるトランザクションをいう。ソフトウェアトランザクショナルメモリSTMsoftwaretransactionalmemoryシステムはしばしば、ソフトウェアコードの実行の範囲内で、または少なくとも主としてソフトウェアコードの実行を通じてアクセス追跡、衝突解決または他のトランザクションメモリタスクを実行することをいう。ある実施形態では、プロセッサ100は、ハードウェア/論理を使って、すなわちハードウェアトランザクショナルメモリHTMHardwareTransactionalMemoryシステム内で、トランザクションを実行することができる。HTMを実装する際には、アーキテクチャおよびマイクロアーキテクチャの両方の観点から、数多くの個別的な実装の詳細が存在し、そのほとんどは本発明を無用に埋没させることを避けるためにここでは論じない。しかしながら、いくつかの構造、資源および実装は例示的な目的のために開示される。しかしながら、これらの構造および実装は必須ではなく、異なる実装詳細をもつ他の構造で増強および/または置換されてもよい。組み合わせとして、プロセッサ100は、STMシステムおよびHTMシステム両方の利点を活用しようと試みる無制限トランザクショナルメモリUTMunboundedtransactionalmemoryシステム内でトランザクションを実行することができてもよい。たとえば、HTMは、トランザクションについてのアクセス追跡、衝突検出、有効確認およびコミットのすべてを実行するためにソフトウェアに頼らないので、小さなトランザクションを実行するために高速かつ効率的である。しかしながら、STMが無制限のサイズのトランザクションを扱うことができる一方、HTMは通例、より小さなトランザクションを扱うことができるだけである。したがって、ある実施形態では、UTMシステムは、小さめのトランザクションを実行するためにハードウェアを利用し、ハードウェアにとっては大きすぎるトランザクションを実行するためにソフトウェアを利用する。以下の議論から見て取れるように、ソフトウェアがトランザクションを扱っているときでも、ハードウェアがソフトウェアを支援および加速するために利用されてもよい。さらに、同じハードウェアが純粋なSTMシステムをサポートおよび加速するために利用されてもよいことを注意しておくことが重要である。上述したように、トランザクションは、プロセッサ100内のローカルな処理要素および潜在的には他の処理要素の両方による、データ項目へのトランザクショナルメモリアクセスを含む。トランザクショナルメモリシステム内の安全機構なしでは、これらのアクセスのいくつかが、潜在的には、無効なデータおよび実行を、すなわち読み出しを無効にするデータへの書き込みまたは無効なデータの読み出しを、結果として与えることになる。結果として、プロセッサ100は潜在的に、潜在的な衝突の識別のためにデータ項目への/からのメモリアクセスを追跡またはモニタリングするための論理を含む。のちに論じる読み出しモニタおよび書き込みモニタのようなものである。データ項目またはデータ要素は、ハードウェア、ソフトウェアまたは両者の組み合わせによって定義される任意の粒度レベルのデータを含んでいてもよい。網羅的ではないデータ、データ要素、データ項目またはその言及の例のリストは、メモリアドレス、データオブジェクト、クラス、ある型の動的言語コードのフィールド、ある型の動的言語コード、変数、オペランド、データ構造およびメモリアドレスへの間接参照を含む。しかしながら、いかなる既知のデータのまとまりがデータ要素またはデータ項目と称されてもよい。ある型の動的言語コードのフィールド、ある型の動的言語コードのような上記の例のいくつかは、動的言語コードのデータ構造を指す。例解すると、サンマイクロシステムズ社からのジャバJava登録商標のような動的言語コードは強い型付けのstronglytyped言語である。各変数は、コンパイル時に知られている型をもつ。それらの型は二つのカテゴリーに分けられる――プリミティブ型ブーリアンおよび数値、たとえば整数int、浮動小数点floatおよび参照型クラス、インターフェースおよびアレイ。参照型の値はオブジェクトへの参照である。ジャバ商標では、フィールドからなるオブジェクトはクラスインスタンスまたはアレイであってもよい。クラスAのオブジェクトaを与えられたら、型Aのフィールドxを指すのにはAx、クラスAのオブジェクトaのフィールドxを指すのにはaxという記法を使うのが慣習である。たとえば、ax=ayazのような表現ができる。ここで、フィールドyおよびフィールドzがロードされて加算され、結果がフィールドxに書き込まれる。したがって、データ項目へのメモリアクセスのモニタリング/バッファリングは任意のデータレベルの粒度で実行されうる。たとえば、ある実施形態では、データへのメモリアクセスは型のレベルでモニタリングされる。ここで、フィールドAxへのトランザクション書き込みおよびフィールドAyの非トランザクションロードは、同じデータ項目、すなわち型Aへのアクセスとしてモニタリングされてもよい。もう一つの実施形態では、メモリアクセスモニタリング/バッファリングはフィールドレベルの粒度で実行されてもよい。ここでは、Axへのトランザクション書き込みおよびAyの非トランザクションロードは、同じデータ項目へのアクセスとしてはモニタリングされない。両者は別個のフィールドへの参照だからである。データ項目へのメモリアクセスを追跡するに当たり、他のデータ構造またはプログラミング技法が考慮に入れられてもよいことを注意しておく。例として、クラスAのオブジェクトのフィールドxおよびy、すなわちAxおよびAyがクラスBのオブジェクトをポイントしており、新たに割り当てられたオブジェクトに初期化され、初期化後一度も書き込みが行われていないとする。ある実施形態では、AxによってポイントされるオブジェクトのフィールドBzへのトランザクション書き込みは、AyによってポイントされるオブジェクトのフィールドBzの非トランザクションロードに関して、同じデータ項目へのメモリアクセスとしてはモニタリングされない。これらの例から敷衍して、モニタがいかなるデータ粒度レベルでモニタリング/バッファリングを実行してもよいことを決定できる。ある実施形態では、プロセッサ100は、データ項目に関連付けられたアクセスおよび潜在的なその後の衝突を検出または追跡するモニタを含む。一例として、プロセッサ100のハードウェアは、モニタリングされることが決定されたロードおよびストアを追跡するための読み出しモニタおよび書き込みモニタを含む。たとえば、ハードウェアの読み出しモニタおよび書き込みモニタが、根底にある記憶構造の粒度によらず、データ項目の粒度でデータ項目をモニタリングする。ある実施形態では、データ項目は、少なくとも該データ項目全体が適切にモニタリングされることを保証するために、記憶構造の粒度で関連付けられた追跡機構によって境を定められる。個別的な例解のための例として、読み出しおよび書き込みモニタは、低レベルデータキャッシュ150これは投機的キャッシュを含んでいてもよい内の位置のようなキャッシュ位置に関連付けられた属性を、そうした位置に関連付けられたアドレスからのロードおよび該アドレスへのストアをモニタリングするために含む。ここで、データキャッシュ150のキャッシュ位置についての読み出し属性は、該キャッシュ位置に関連付けられたアドレスへの読み出しイベントに際して、同じアドレスへの潜在的な衝突する書き込みがないかどうかモニタリングするために、設定される。この場合、書き込み属性は、同じアドレスへの潜在的な衝突する読み出しおよび書き込みがないかどうかモニタリングするために、書き込みイベントについて同様の仕方で動作する。この例をさらに進めると、ハードウェアは、しかるべくキャッシュ位置がモニタリングされることを示すよう設定された読み出しおよび/または書き込み属性をもつキャッシュ位置に対する読み出しおよび書き込みについてののぞき見snoopsに基づいて衝突を検出することができる。逆に、読み出しおよび書き込みモニタを設定すること、あるいはあるキャッシュ位置をバッファリングされる状態に更新することは、ある実施形態では、読み出し要求または所有権要求についての読み出しのようなのぞき見につながり、これは、他のキャッシュにおけるモニタリングされるアドレスとの衝突の検出を許容する。したがって、設計に基づいて、キャッシュラインのキャッシュコヒーレンシー要求およびモニタリングされるコヒーレンシー状態の種々の組み合わせは潜在的な衝突につながる。たとえば、キャッシュラインがあるデータ項目を、共有された読み出しモニタリング状態に保持し、のぞき見がそのデータ項目への書き込み要求を示す。逆に、バッファリングされた書き込み状態にあるデータ項目を保持するキャッシュラインと、そのデータ項目への読み出し要求を示す外部のぞき見は、潜在的に衝突すると考えてもよい。ある実施形態では、アクセス要求および属性状態のそのような組み合わせを検出するために、のぞき見論理が、衝突検出/報告のためのモニタおよび/または論理および衝突を報告するための状態レジスタのような衝突検出/報告論理に結合される。しかしながら、条件およびシナリオの任意の組み合わせが、あるトランザクションにとって、無効にする要因であると考えられてもよい。トランザクションの非コミットのために考えられうる因子の例は、トランザクション的にアクセスされるメモリ位置への衝突の検出、モニタ情報の喪失、バッファリングされたデータの喪失、トランザクション的にアクセスされるデータ項目に関連付けられたメタデータの喪失および割り込み、リング遷移もしくは明示的なユーザー命令のような他の無効にするイベントの検出を含む。ある実施形態では、プロセッサ100のハードウェアはバッファリングされた仕方でトランザクション的更新を保持する。上述したように、トランザクション書き込みはトランザクションのコミットまでグローバルに可視にされない。しかしながら、トランザクション書き込みに関連付けられるローカルなソフトウェアスレッドは、その後のトランザクションアクセスのためにトランザクション更新にアクセスすることができる。第一の例として、バッファリングされた更新を保持するためにプロセッサ100内に別個のバッファ構造が設けられる。これは、該更新を、ローカルなスレッドに提供し、他の外部スレッドには提供しないことができる。対照的に、もう一つの例として、データキャッシュ150のようなキャッシュメモリが、同じトランザクション的機能を提供しつつ前記更新をバッファリングするために利用される。ここで、キャッシュ150は、バッファリングされたコヒーレンシー状態においてデータ項目を保持することができる。ある場合には、新しいバッファリングされたコヒーレンシー状態が、修正排他共有無効MESIModifiedExclusiveSharedInvalidプロトコルのようなキャッシュコヒーレンシープロトコルに加えられて、MESIBプロトコルをなす。バッファリングされたデータ項目、つまりバッファリングされたコヒーレンシー状態に保持されているデータ項目に対するローカルな要求に応答して、内部的なトランザクション的逐次的順序付けを保証するよう、キャッシュ150はそのデータ項目をローカルな処理要素に提供する。しかしながら、外部アクセス要求に応答しては、トランザクション的に更新されたデータ項目がコミットまでグローバルに可視にされないことを保証するよう、ミス応答が提供される。さらに、キャッシュ150のあるラインがバッファリングされたコヒーレンシー状態に保持され、放逐のために選択されるとき、バッファリングされた更新はより高いレベルのキャッシュメモリに書き戻されない――コミット後まで、バッファリングされた更新はメモリシステムを通じて増殖されない、すなわちグローバルに可視にされない。その代わり、トランザクションはアボートしてもよく、または放逐されたラインが、犠牲者キャッシュvictimcacheのような、データキャッシュとより高いレベルのキャッシュメモリとの間の投機的な構造に記憶されてもよい。コミットに際して、バッファリングされたラインは、そのデータ項目をグローバルに可視にするために、修正された状態に遷移させられる。内部および外部という用語はしばしば、トランザクションの実行またはキャッシュを共有する処理要素に関連付けられたスレッドの観点に対するものであることを注意しておく。たとえば、トランザクションの実行に関連付けられたソフトウェアスレッドを実行するための第一の処理要素がローカルスレッドと称される。したがって、上記の議論において、前記第一のスレッドによって以前に書き込まれたアドレスへのストアまたは該アドレスからのロードこの結果、そのアドレスについてのキャッシュラインはバッファリングされたコヒーレンシー状態に保持されるが受領される場合、そのキャッシュラインのバッファリングされたバージョンは、前記第一のスレッドに提供される。それがローカルなスレッドだからである。対照的に、同じプロセッサ内の別の処理要素で第二のスレッドが実行中であることがあるが、該第二のスレッドは、前記キャッシュラインがバッファリングされた状態に保持される原因となった前記トランザクションの実行には関連付けられていない――外部スレッドである;したがって、この第二のスレッドから前記アドレスへのロードまたはストアは、前記キャッシュラインのバッファリングされたバージョンをミスし、より高いレベルのメモリから前記キャッシュラインのバッファリングされていないバージョンを取得するために、通常のキャッシュ置換が利用される。ある実施形態では、プロセッサ100は、トランザクション的実行をサポートするようアプリケーションコード176をコンパイルするとともに、潜在的にはアプリケーションコード176を最適化するためのコンパイラ/最適化コードを実行することができる。ここで、コンパイラはトランザクションの実行を可能にするための演算、呼び出し、関数および他のコードを挿入してもよい。コンパイラはしばしば、ソーステキスト/コードをターゲットテキスト/コードに変換するプログラムまたはプログラムの集合を含む。通例、コンパイラによるプログラム/アプリケーションコードのコンパイルは、高水準プログラミング言語コードを低水準機械語もしくはアセンブリー言語コードに変換するための複数のフェーズおよびパスにおいて行われる。それでも、単純なコンパイルのためには、単一パスのコンパイラも利用されうる。コンパイラは、任意の既知のコンパイル技法を利用し、語彙解析、前処理、構文解析、意味解析、コード生成、コード変換およびコード最適化といった任意の既知のコンパイラ動作を実行してもよい。本稿で述べられるように、トランザクション的実行と動的コードコンパイルの結び付きは、必要なメモリ順序付けの防護策を保持しつつ、潜在的には、より積極的な最適化を可能にすることになる。大きめのコンパイラはしばしば複数のフェーズを含むが、たいていそれらのフェーズは二つの一般的なフェーズの範囲内に含まれる:1フロントエンド、すなわち一般に統語処理、意味処理および若干の変換/最適化が行われうるところと、2バックエンド、すなわち一般に、解析、変換、最適化およびコード生成が行われるところである。いくつかのコンパイラはミドルエンドを使う。これはコンパイラのフロントエンドとバックエンドの間の境界をあいまいにすることになる。結果として、挿入、関連付け、生成またはコンパイラの他の動作は、上述したフェーズまたはパスの任意のものおよびコンパイラの他の任意の既知のフェーズまたはパスにおいて行われてもよい。例解用の例として、コンパイラは潜在的に、トランザクション的動作、呼び出し、関数などをコンパイルの一つまたは複数のフェーズにおいて挿入する。コンパイルのフロントエンドフェーズにおける呼び出し/動作の挿入、次いでトランザクションメモリ変換フェーズの際の該呼び出し/動作の低レベルコードへの変換である。動的コンパイルの間、コンパイラコードまたは動的最適化コードがそのような動作/呼び出しを挿入するとともに、ランタイムの間に実行のためのコードを最適化してもよいことを注意しておく。個別的な例解用の例として、バイナリーコードすでにコンパイルされたコードはランタイムの間に動的に最適化されてもよい。ここで、プログラムコードは動的最適化コード、バイナリーコードまたはそれらの組み合わせを含んでいてもよい。それでも、コンパイラの実行環境および動的または静的な性質にもかかわらず、コンパイラは、ある実施形態では、トランザクション的実行を可能にするおよび/またはプログラムコードの諸セクションを最適化するためにプログラムコードをコンパイルする。したがって、プログラムコードの実行への言及は、ある実施形態では、1コンパイラプログラム単数または複数または最適化コード最適化器を動的または静的に実行して、主たるプログラムコードをコンパイルする、トランザクション構造を維持する、他のトランザクション関係の動作を実行する、またはコードを最適化する;2最適化/コンパイルされたアプリケーションコードのようなトランザクション動作/呼び出しを含む主たるプログラムコードの実行;3主たるプログラムコードに関連付けられたライブラリのような他のプログラムコードの実行または4それらの組み合わせのことをいう。しばしば、ソフトウェアトランザクショナルメモリSTMシステム内で、コンパイルされるべきアプリケーションコードとインラインで、いくつかの動作、呼び出しおよび他のコードを挿入するためにコンパイラが利用され、一方、他の動作、呼び出し、関数およびコードはライブラリ内で別個に提供される。これは潜在的に、ライブラリ配布者が、アプリケーションコードを再コンパイルする必要なしにライブラリを最適化および更新する能力を提供する。具体例として、コミット関数への呼び出しがアプリケーションコード内でトランザクションのコミット点においてインラインで挿入されてもよい。一方、コミット関数は更新可能なライブラリにおいて別個に提供される。さらに、特定の動作および呼び出しをどこに置くかの選択は潜在的にアプリケーションコードの効率に影響する。背景セクションにおいて上述したように、複数スレッドシステムにおけるコードの積極的な最適化は、潜在的には、メモリ順序付け問題に関して危険がある。しかしながら、ある実施形態では、コード最適化はトランザクション的メモリ防護策と組み合わされて、メモリ順序付けの防護策を保持しつつ積極的な最適化を許容する。ここで、最適化されたコードを含む原子的な領域がプログラムコード中に挿入されてもよい。それにより、最適化されたコードの実行時に、トランザクション的防護策はメモリ順序付け違反が起こらないことを保証する。結果として、最適化されたコードは積極的に最適化されることができ、原子的な領域はメモリ順序付け違反が検出されることを保証するので、該領域はコミットされない。それでも、原子的領域とコード最適化の組み合わせは、さらなる修正から利益を受けることもありうる。したがって、ある実施形態では、プロセッサ100はプロセッサ100内のハードウェア資源の利用可能性に基づいてプログラムコード176内のトランザクションを動的にサイズ変更することができる。伝統的には、原子的領域は完全にコミットされるか、アボートされるかのいずれかである。しかしながら、この例では、トランザクションは、該トランザクションまたは該トランザクション内のコードの一部分の完全な実行のために低いまたは不十分な資源が存在しているときは、該トランザクションの終点より前にコミットされることがある。すなわち、より小さなトランザクションに動的にサイズ変更されるのである。例解用の例として、キャッシュメモリ150が一時的な、トランザクション的情報を、付随するトランザクション的追跡情報とともに保持するために利用されるとする。このシナリオでは、キャッシュ150が利用可能なキャッシュエントリーが少なくなるまたはオーバーフローするトランザクション的にアクセスされたラインを放逐のために選択し、犠牲者キャッシュが満杯とき、実行中のトランザクションはその点においてコミットされ、それにより前記一時的な情報がグローバルに可視になる。次いで、そのコミット点からもとのトランザクションの終点まで、新しいトランザクションが改めて開始されてもよい。結果として、トランザクション的ハードウェア資源――この例ではキャッシュメモリ150――が解放される。そしてトランザクションは、UTMシステムでのようにトランザクション全体をロールバックしたりソフトウェアに移行してトランザクションを拡大したりする代わりに、二つの、より小さなハードウェアトランザクションとして完遂することができる。したがって、ある実施形態では、プロセッサ100は、HTM、STMまたはUTMのいずれであれ、トランザクション的メモリシステムをサポートするためのハードウェアを含む。例は、デコーダ、キャッシュメモリ、投機的記憶構造、追跡機構、ストアバッファ、レジスタファイル、チェックポイント記憶機構およびトランザクションの実行をサポートする他の任意の既知のハードウェアである。さらに、プロセッサ100は、トランザクション的実行をサポートするそのようなハードウェアについての利用可能性availability、使用usageまたはそれらの表現を追跡、提供または指示するよう適応されたハードウェア/論理をも含む。第一の例として、使用メトリックハードウェア使用の表現は、キャッシュメモリ、犠牲者キャッシュ、ストアバッファまたはロードバッファのような記憶構造における利用可能なまたは反占有されたinverselyoccupiedエントリーの数を含む。もう一つの例として、使用メトリックは、メモリのオーバーフロー、割り込みイベントまたはエントリーの放逐といったイベントの発生を含んでいてもよい。しかしながら、実際のものであれ抽象的なものであれ、任意の使用メトリックが利用されうる。より抽象的な使用メトリックの例として、カウンタがコード内のループ反復工程の数を計数し、カウンタが閾値に達したとき、トランザクションがコミットされるとする。ここで、閾値は、不十分なハードウェア資源のためトランザクションのアボートが発生するときは閾値を下げるなど、時間を追ったコードプロファイリングに基づいて動的に調整されてもよい。その場合、ハードウェア資源または特定のイベントの正確な実際の使用度は提供されない。しかしながら、カウンタ閾値の動的調整を通じて、ハードウェアは本質的に、ハードウェア資源がなくなる前に、すなわち高い資源利用のためにアボートまたはロールバックが実行される前に、ループ数を推定している。結果として、ある実施形態では、そのようなハードウェア推定が、ハードウェア資源についての使用または使用の表現と称される。コード実行のための資源利用可能性を推定しているからである。ある実施形態では、プロセッサ100内のハードウェアは、トランザクションがいつ動的にサイズ変更されるべきかを非同期的に決定することができる。たとえば、ハードウェア資源の利用度が高い場合、プロセッサ100は、プロセッサ100上で実行されているプログラムコード176の観点からは透明に、トランザクションをコミットして、別のトランザクションを再開してもよい。ここで、トランザクションを含むプログラムコード176は実行論理140によって実行されている。プログラムコードの観点からは、トランザクションはシームレスに実行される。しかしながら、ハードウェアの観点からは、ストアバッファのような資源が高い利用度を有していたオーバーフローしたので、ハードウェアはそのトランザクションを、該トランザクションの終点より前にコミットし、そのコミット点において第二のトランザクションを改めて開始し、次いで第二のトランザクションを該トランザクションのもとの終点においてコミットしたのである。もう一つの実施形態では、トランザクションの動的サイズ変更はハードウェアおよびファームウェア/ソフトウェアの組み合わせを用いて実行される。ここで、プロセッサ100は、トランザクション的実行をサポートし、それらの資源の利用度/利用可能性を追跡するためのハードウェア資源を含む。そして、プログラムコード176からの条件付きコードは、実行されたとき、実行論理140に、それらのハードウェア資源の利用度/利用可能性に基づいて動的にサイズ変更終点より前にトランザクションをコミットさせる。本質的には、資源利用度のチェックおよび潜在的な条件付きコミットは、ハードウェアによる特定の命令の実行と独立非同期なのではなく、同期的に――ソフトウェア命令の結果として――実行される。たとえば、動的コンパイラコードの一部であってもよい動的最適化コード177は、実行論理140/141によって実行されて、プロセッサ100のランタイムの間にプログラムコード176を動的にコンパイル/最適化する。そのようなコンパイル/最適化の間、原子的領域が、その原子的領域内の条件付きコミットコードとともに、プログラムコード176のセクションに挿入される。実行論理140/141は次いで、ランタイムの間に、コード176を動的に最適化し、動的に最適化されたコード176を実行する。具体的には、実行論理140/141は原子的領域およびその中の最適化されたコードを実行する。条件付きコミットコードに遭遇/条件付きコミットコードをデコードするデコード段125に応答して、ハードウェア資源利用度が決定される。利用度/利用可能性はすでに前に追跡されていてもよいが、条件付きコミットコードに応答して、利用度が報告/評価されることを注意しておく。次いで、ハードウェア資源の利用可能性/使用に基づいて原子的領域をコミットするか否かについての決定がなされてもよい。ある実施形態では、資源使用に基づいてコミットするか否かを決定することは、条件付きコードに応答してハードウェアによって実行される。換言すれば、ハードウェアは独立してハードウェア使用を評価し、利用度が、早期コミットを引き起こすのに十分高いかどうかを判定してもよい。例として、条件付きコミットコードは、デコーダ125によって認識可能な条件付きコミット命令を含む。条件付きコミット命令または領域チェック命令は分岐ターゲットアドレスを含む。そしてハードウェアは、デコード論理125で条件付きコミット命令をデコードするのに応答して、ハードウェア資源利用度が高すぎるかどうか、あるいは不十分な資源が存在しているかどうかを判定する。利用度が高すぎる、または不十分な資源が存在する場合、実行論理140は実行を、分岐ターゲットアドレスにジャンプさせる。ある実施形態では、ハードウェアは、所定のアルゴリズムに基づいて、利用度が高すぎるかどうかまたは不十分な資源が存在しているかどうかを判定する。たとえば、ハードウェア資源がストアバッファを含むとき、利用度が高すぎることは、所定数のストアバッファエントリーが利用されているまたはオーバーフロー利用可能なストアバッファエントリーがないことが発生していることを含む。ハードウェアはまた、前の実行に基づいてコードの期待される使用を推定しコードプロファイリング、その推定を現在のハードウェア使用と一緒に用いて、条件付きコミットなしに実行を継続するのに十分な資源が存在するかどうかを判定してもよい。あるいはまた、条件付きコミット命令は、期待される使用を含んでいてもよい。そしてハードウェアは、期待される使用をハードウェア使用と比較し、不十分な資源が存在するかどうかを判定する。たとえば、条件付きコード176がプログラムコード176の原子的領域内でループに挿入されるとする。結果として、条件付きコードはループの反復工程毎に実行される。ここで、条件付きコミット命令はループの反復工程中に利用されるストアバッファエントリーの期待される数を参照する。この数は、前記コードによって、または前記コードの動的プロファイリングによって推定されるところによる、タッチされる一意的なストアバッファエントリーの数に基づいていてもよい。条件付きコミット命令をデコードするデコード論理125に応答して、エントリーの期待される数が、プロセッサ100のハードウェアによって決定されるところのストアバッファ内の利用可能なエントリーの数に対して比較される。期待されるエントリーの数が利用可能なエントリーの数より大きければ、実行は、条件付きコミット命令によって参照される分岐ターゲットアドレスにジャンプする。分岐ターゲットアドレスは、原子的領域の早期コミットを実行して第二の原子的領域を改めて開始するために、プログラムコード176またはライブラリコードのような他のコード内のアドレス参照コードを含んでいてもよい。もう一つの実施形態では、ハードウェア利用度が高すぎるまたはハードウェア利用可能性が低すぎるときをソフトウェアが決定する。この例では、プロセッサ100は、ハードウェア使用の表現ハードウェア使用メトリックを保持するレジスタのような記憶要素を含む。ここで、条件付きコードは、使用メトリックをロード/読み込みし、それを評価し、早期コミットが実行されるべきかどうかを判定する動作を含む。早期コミットが実行される場合、条件付きコードはジャンプ動作を含む。ジャンプ動作は、実行論理140によって実行されたとき、実行を、現在のトランザクションをコミットして別の原子的領域を開始してもよい分岐ターゲットアドレスにジャンプさせる。ハードウェアおよびソフトウェアが同様の評価を実行してもよいことを注意しておく。しかしながら、ハードウェアソリューションは潜在的に、ハードウェアが完全に早期コミットを扱うまたは条件付きコミット命令を受信するだけであることを許容することを通じて、コードのコンパクトさを可能にする。それでも、ソフトウェアが評価を実行することを許容すれば、早期コミットをいつ実行するかの決定において、より柔軟性が提供される。結果として、実装および所望される利点に基づいて、ハードウェア利用度/利用可能性が高すぎる/低すぎるときを決定するために、ハードウェアとソフトウェアの間の組み合わせの任意の階調が利用されうる。図1は、例示的なプロセッサの抽象化された論理的なビューを示しており、種々のモジュール、ユニットおよび/または論理を表現している。しかしながら、本稿で記載される方法および装置を利用するプロセッサは図示したユニットを含む必要はないことを注意しておく。さらに、図1は二つのコアしか描いていないが、プロセッサは、同じ型の複数のコア、それぞれ異なる型の二つより多くのコアなど、任意の数を含んでいてよい。図1は、外部メモリコントローラへのインターフェースコントローラハブ170をもつ、ポイントツーポイント式に結合されたプロセッサのある実施形態を示している。しかしながら、多くの現在のプロセッサはプロセッサ上メモリインターフェースモジュール――オンチップモジュール――を、複数のコアを相互接続するリング構成、共有されるキャッシュおよび他のインターフェースとともに含めるようになってきている。図示していないが、プロセッサ100はある実施形態では、コア、キャッシュおよびメモリコントローラコンポーネントを結合するリング相互接続を含む。ここで、キャッシュエージェントが、物理的に分配されたキャッシュのスライスを管理するために利用される。例として、各キャッシュコンポーネントは共位置のコア――キャッシュの分配されたスライスを管理するためにキャッシュエージェントが関連付けられているコア――についてキャッシュのスライスを管理する。キャッシュエージェントがリング相互接続上のトラフィックを扱い、キャッシュスライスとインターフェースをもつのと同様、コアエージェント/コンポーネントはトラフィックを扱い、コアとインターフェースをもつ。さらに、リング相互接続は、メモリコントローラインターフェース論理MCILMemoryControllerInterfaceLogicおよび/または他のコントローラを、メモリおよび/またはグラフィックプロセッサのような他のモジュールとインターフェースをもつよう結合してもよい。図2aに目を転じると、原子的領域を利用してコードを最適化する方法の流れ図のある実施形態が描かれている。図2aにおけるフローのブロックは実質的に逐次的な仕方で示されているが、図示した方法のフローはいかなる順序で実行されても、または部分的もしくは完全に並列に実行されてもよい。たとえば、条件付きコミットコードは、原子的領域開始および終了命令を挿入する前に挿入されてもよい。さらに、描かれているブロックが実行されることは必須ではない。そして描かれているブロックと関連してまたは描かれているブロックの代わりに、図示されていない他のブロックが実行されてもよい。ブロック205では、最適化されるべきプログラムコードのセクションが同定される。上述したように、プログラムコードは、コンパイラコード、最適化コード、アプリケーションコード、ライブラリコードまたは他の任意の既知の形式のコードを指しうる。具体的な例解用の例として、プログラムコードは、プロセッサ100上で実行のために動的にコンパイルされたおよび/またはプロセッサ100上で実行されるよう動的に最適化された実行準備のできたバイナリーコードのような、プロセッサ100上で実行されるべきコードを含む。さらに、コード動作、関数呼び出しなどの挿入およびコードの最適化は、コンパイラおよび/または最適化コードのようなプログラムコードの実行を通じて実行される。例として、最適化コードは、ランタイムにおいてプロセッサ100上で動的に実行されて、プロセッサ100上でのプログラムコードの実行の直前に、該プログラムコードを最適化する。ある実施形態では、擬似コードBからの領域のような、最適化されるべきプログラムコードのセクションを同定することは、該コードが最適化されるべきプログラムコードのセクション/領域を指示することを含む。たとえば、最適化されるべきまたは最適化から裨益する可能性の高いコードのセクションを指示するために特定の命令または境界が利用される。もう一つのオプションとして、プログラマーがプログラムコードの諸セクションに関するヒントを提供し、それが最適化コードによって最適化のためのセクションを同定するために利用される。もう一つの実施形態では、プロファイリング情報に基づいて領域が同定/選択される。たとえば、プログラムコードは、ハードウェア、プロセッサ上で実行されるソフトウェア、ファームウェアまたはそれらの組み合わせによる実行の間に、プロファイリングされる。ここで、コードのプロファイリングはヒントを生成するまたはもとのソフトウェアヒントを修正するとともに、最適化のための領域の直接的な同定を提供する。さらに、コードのセクションは、特定の型、フォーマットまたはコードの順序といったある種の属性によって潜在的に同定される。具体的な例解用の例として、ループを含むコードが潜在的な最適化のターゲットとされる。そして実行中のループのプロファイリングがどのループが最適化されるべきかを決定する。また、ループが最適化されるべきロードおよびストアのような特定のコードを含む場合、そのようなコードを含む領域が最適化のために同定される。擬似コードBから見て取れるように、この領域は、ループ実行を最適化するためにループの外に持ち上げたり押し出したりすることができるロードおよびストアを含んでいる。ある実施形態では、最適化のために同定されたコードのセクションは原子的領域に変換される。あるいは、コードの該セクションの少なくとも一部分が原子的領域に変換される。ここで、コードの前記一部分は、ブロック210~215に示されるように、開始および終了コミットトランザクション原子的領域命令によって区画される。擬似コードCから見て取れるように、領域開始regionstartおよび領域コミットregioncommit命令がそれぞれコードの当該領域の前および後に挿入される。ある実施形態では、コードは複数の入口および複数の出口を含む。結果として、開始原子的領域および終了原子的領域命令は、それぞれ各入口点および各出口点に挿入されてもよい。しかしながら、領域が原子的であることを指示する任意の既知の方法が利用されうる。ブロック220では、条件付きコミット点が決定される。最適化されるべきコードの領域内で複数の条件付きコミット点が決定/割り当てされてもよいことを注意しておく。ただし、議論の簡単のため、以下では一つのコミット点のみをより詳細に論じる。条件付きコミット点を決定することは、条件付きコミット点どうしの間でハードウェア資源の枯渇を避けようとするためのいかなる既知の割り当て/決定アルゴリズムに基づいていてもよい。第一の例として、反復工程のたびごとに条件付きコミット点に遭遇するよう、条件付きコミット点がループ内に挿入される。ここで、条件付きコミット点はループの先頭に決定される。もう一つの例として、コードの動的プロファイリングが、ハードウェア資源の枯渇につながることが多い実行経路を示す。よって、そのような経路の実行の間に資源の枯渇を避けるために、そのような実行経路に条件付きコミット点が割り当てられる。同様に、独占するまた資源的にヘビーであることが知られている実行経路に条件付きコミット点が割り当てられてもよい。ブロック225では、条件付きコミットコードが少なくとも前記条件付きコミット点に挿入される。条件付きコミットコードは、次のコミット点までの実行をサポートするために不十分なハードウェア資源が存在していることが判定される場合に、トランザクションのサイズ変更、すなわち早期コミットを引き起こす。暫時図2bに目を転じると、条件付きコミットコードを挿入するための流れ図のある実施形態が示されている。フロー226では、条件付きコミット命令が条件付きコミット点に挿入される。擬似コードDから見て取れるように、条件付きコミット命令は、ある実施形態では、原子的領域内のコミット点L1において挿入された領域チェックregioncheck命令を含む。第一の例として、領域チェック命令または条件付き分岐命令のような条件付きコミット命令は、分岐ターゲットアドレスへの参照を含む。次のコミット点まで実行をサポートするのに不十分な資源が存在していると判定する結果として、実行は、条件付きコミット命令に応答して分岐ターゲットアドレスにジャンプする。ここで、条件付きコミットコードは、分岐ターゲットアドレスにおけるコミットコードをも含んでいてもよい。本質的に、この例では、条件付きコミット命令は、十分な資源が存在するかどうかを判定するための試験/問い合わせを開始する。そして分岐ターゲットアドレスにおけるコードは、不十分な資源が存在しているときにトランザクションを早期にコミットする。したがって、ブロック227では、分岐ターゲットアドレスにおいてコミットcommit命令が挿入される。擬似コードDでは、第一の領域コミットregioncommit命令はB4における原子的領域の出口/終点において挿入され、第二の領域コミットregioncommitはブロックB6における分岐ターゲットアドレス点L2において挿入される。ここで、L1における領域チェック命令に応答して不十分な資源が判別される場合、実行は、領域チェック命令によって参照される分岐ターゲットアドレスB6にジャンプする。トランザクションライブラリ内のコミット関数への呼び出しまたはアーキテクチャ上認識されるコミット命令のような領域コミット命令は、原子的領域を早期に終点B4より前にコミットするよう実行される。さらに、ブロック228擬似コードDからのB7では、第二の開始原子的領域命令regionstartが領域コミット命令のあとに挿入される。結果として、B3において原子的領域の実行が始まるregionstart。そしてL1において領域チェック命令によって不十分な資源が判別されるか終点B4に遭遇するまで続く。しかしながら、L1において不十分なハードウェア資源が判別される場合には、もとのトランザクションがサイズ変更される、すなわちコミット点L2、B6においてコミットされる。次いで、第二の原子的領域がB7において開始され、領域実行は、コミット点B4までまたはL1で資源がいま一度制限されるまで、第二のトランザクションとして継続される。したがって、ハードウェア資源の枯渇を避けるために、単一の原子的領域は、動的に、より小さなトランザクションにサイズ変更されうる。そのようなハードウェア資源の枯渇は従来であればアボートまたはソフトウェアトランザクション的実行への拡張を引き起こすところである。条件付きコミット命令はいかなる情報を含んでいてもよいことを注意しておく。たとえば、先述したように、条件付きコミット命令は、ある実施形態では、次のコミット点までの期待されるハードウェア資源使用を含む。たとえば、擬似コードDにおけるコードB2を通じたループの間に利用されるエントリーの期待される数である。ここで、この期待される使用は、ループB2のもう一回の反復の実行をサポートするのに十分な資源が存在しているかどうかを判定する際に利用される。具体的な例解用の例として、期待される使用は、次のコミット点までにコードの当該領域の実行に応答して一意的にタッチされると期待される記憶構造内のエントリーの数を含む。さらに、条件付きコードは条件付きコミット命令に限定されない。たとえば、ハードウェアが使用を判別し、その使用をレジスタ図5を参照してより詳細に論じるに入れる実施形態では、条件付きコードは、レジスタから該使用を読み/ロードし、該使用を評価し、次いで擬似コードDからのB6およびB7と同様のコミットおよび再開コードに分岐するジャンプまたは分岐動作を発する。他の実施形態では、ソフトウェアは、ハードウェアと通信したりハードウェアに問い合わせたりするのではなく、ハードウェア使用を推定してもよい。そのシナリオでは、条件付きコードは、そのような推定を実行するコードを含む。たとえば、条件付きコミットを実行するまでのループの反復回数を制限するため、図6を参照してより詳細に述べるカウントが、ソフトウェアの実行を通じて保持される。この例では、カウントを保持するために実行されるべきコードが条件付きコミットコードと考えられる。ブロック230では、プログラムコードのセクションが最適化される。擬似コードEは最適化後のコードの例を描いている。原子的領域の画定demarcationおよび条件付きコミットコードの挿入はいくつかの実施形態ではプログラムコードを最適化すると考えられるが、プログラムコードのセクションは、他の実施形態では、トランザクション的実行のメモリ順序付け防護策に依拠しつつ、実行利益を得るためにさらに最適化される。具体例として、ロードおよびストアが、部分冗長性ロード消去PRLEおよび部分デッドストア消去PDSEを利用して、ループの外側に持ち上げられたり押し出されたりする。擬似コードEは、PRLEがr2およびr24のロードを持ち上げ、PDSEがr24のストアを押し出したあとの原子的領域を描いている。ある実施形態では、さらなるメモリ順序付け規則が適用されることを注意しておく。ここで、メモリ順序付けを破るいかなるメモリ最適化も領域開始およびコミットを横断しないことを保証することが有利でありうる。この例は擬似コードEにおいて見て取れる。ここで、r24ストアはB6における領域コミットの前に挿入されており、r2およびr24のロードはB7における領域開始regionstart命令のあとに再挿入されている。結果として、領域が早期にコミットされる条件付きコミット点までとなるようサイズ変更される場合には、r24ストアは領域がB6においてコミットされる前に実行される。そしてr2およびr24ロードはB7における新しいトランザクションの再開後に実行される。上記ではロードおよびストア最適化について追求したが、いかなる既知のコード最適化技法が利用されてもよい。非網羅的なリストであり純粋に例示するものとして、コード最適化のさらにいくつかの例を挙げておくと、ループ最適化、ソフトウェアパイプライン化、データフロー最適化、コード生成最適化、境界チェック消去boundscheckingelimination、分岐オフセット最適化、デッドコード消去およびジャンプ接続jumpthreadingがある。図3aを参照するに、原子的コードを動的にサイズ変更するための流れ図のある実施形態が描かれている。ブロック305では、最適化されたプログラムコードを含むトランザクション原子的領域が実行される。ある実施形態では、最適化されたプログラムコードはランタイムの間に動的に最適化される、すなわち、プログラムコードをオンザフライでちょうど実行に間に合うように最適化するために、動的最適化コードがランタイムにおいて実行される。しばしば、この型の動的最適化またはコンパイルは、静的なコンパイルの際のようにプログラム全体を認識することはせず、セクションに分かれたコードの諸部分をコンパイル/最適化できる。ブロック310では、領域チェック命令に遭遇する。ある実施形態では、領域チェック命令に遭遇することは、デコード論理がその命令をデコードすることを含む。しかしながら、遭遇はその命令またはその命令の動作の受け取りまたはサービスのパイプラインのいかなる段階を指していてもよい。たとえば、領域チェック命令に遭遇することは、上記の代わりに、その命令に関連付けられた動作のためのバッファ内にエントリーが割り当てられること、該動作のディスパッチ、該命令のための動作またはマイクロ動作を実行する実行ユニットによる該命令の実際の実行またはパイプラインの他の任意の既知の段階を指してもよい。上述したように、領域チェック命令は、ある実施形態では、ハードウェアに問い合わせするための、プロセッサのデコーダによって認識可能なISAの部分である。問い合わせは単に、使用についてハードウェアに問い合わせするためのロードであってもよい。次いでソフトウェアが、ハードウェアからのそれ以上の関与なしに、十分な資源が利用可能であるかどうかを判定する。対照的に、問い合わせは、原子的領域の実行を継続するために十分な資源が存在しているかどうかをハードウェアが判定することの要求を含んでいてもよい。ここで、問い合わせは、不十分な資源が存在している場合にハードウェアが分岐するターゲットアドレスを提供する。それでも、問い合わせは、十分な資源が利用可能であるかどうかを判定する際にハードウェアが利用するための期待される使用をも領域チェック命令が提供する、より込み入ったものであってもよい。領域チェック命令に応答して、ブロック315では、領域チェックのための点において、ハードウェアユニット単数または複数が、次の条件付きコミット点までなどのトランザクションのある領域を完遂するために十分な資源を有しているかどうかが判定される。十分なハードウェア資源が存在するかどうかの判定は、任意の仕方で、実際に測定されても、あるいは近似されてもよい。第一の例として、ハードウェア自身が使用レベルを追跡および/または判別する。そしてハードウェア、ファームウェア、ソフトウェアまたはそれらの組み合わせが、その使用レベル/メトリックがトランザクションのある領域を完遂するための十分な利用可能性を含んでいるかどうかを判定する。しかしながら、使用レベルは純粋にソフトウェアの指令で近似/測定されてもよいことを注意しておく。この場合、測定は、ハードウェアが独自の追跡を実行する上述した例ほど正確ではないことがあるが、測定をサポートするために追加的なハードウェアフックを追加する必要はない。暫時図3bを参照するに、トランザクションのある領域の実行を完遂するための十分な資源があるかどうかを判定するための流れ図のある実施形態が示されている。フロー350において、ハードウェアユニットまたは複数のハードウェアユニットの期待される使用が決定される。ハードウェア、ファームウェア、ソフトウェアまたはそれらの組み合わせが期待される使用度を決定するために利用されてもよい。あるシナリオでは、トランザクションを含むプログラムコードの実行がプロファイルされる。プロファイリングの際、限られた資源に起因するアボートの数、アボートなしのコミットおよび/またはハードウェア使用が追跡される。その後、コンパイラのようなコードが、過去の実行プロファイルに基づいて期待される使用のヒントまたは示唆を提供する。もう一つのシナリオでは、期待される使用は推定値を含んでいてもよい。たとえば、ハードウェアユニットがストアバッファである場合、期待される使用は、この状況では、コード領域における一意的なストア新たなストアバッファエントリーに割り当てられる可能性の高いストア動作の数を含む。本質的に、コード中のストアの数は、コード領域の実行の間に利用されるストアバッファエントリーの数を推定している。しかしながら、期待される使用を判定することは、ソフトウェアプロファイリングまたは推定に限定されない。その代わり、ハードウェアが同様のプロファイリングまたは推定を実行するとともにコードと連携して動作して、期待される使用を決定してもよい。同様に、フロー355では、ハードウェアユニットの利用可能な使用がハードウェア、ソフトウェア、ファームウェアまたはそれらの組み合わせにおいて判別される。上記からの例を続けると、条件付きコミット命令がハードウェアに、32エントリーストアバッファの期待される使用が、推定または過去のプロファイリングに基づいて10個のストアバッファエントリーを含むことを知らせるとする。次いで、ストアバッファは、その先頭および末尾ポインタを利用して、20個のエントリーが現在割り当てられている12個の利用可能なエントリーと判定することができる。この判定から、フロー360において比較が実行されうる。そして利用可能なエントリーの数が期待される使用より多いので、フロー360において、実行を継続するための十分な資源が存在していると判定される。あるいはまた、9個のエントリーしか利用可能でない場合には、フロー370において、十分な資源が存在していないと判定される。しかしながら、比較は、厳密に十分なスペースがハードウェア資源中で利用可能であることを保証することに限定されない。その代わり、閾値の使用を通じて緩衝バッファゾーンが設けられてもよい。たとえば、使用が高いある閾値より上または利用可能性が低いある閾値より下場合、フロー365、370において同様の判定がなされてもよい。具体的な例解用の例として、6エントリーの緩衝ゾーンが利用可能性について利用されるとする。この場合、利用されるべく期待されるエントリーの数が10であり、32エントリーバッファにおいて20個が利用されている場合、12個のエントリーしか利用可能でない。よって、10エントリーの期待される使用が割り当てられたとしたら、利用可能なものとして2個のエントリーしか残らない。利用可能に残される6エントリーの緩衝ゾーンが利用されるので、フロー370において不十分な資源が判定される。その代わり、20個のエントリーが利用可能であれば12個のエントリーが利用されている、十分な資源が存在するフロー365のように。そのコード領域について10個のエントリーを割り当ててもまだ10個の利用可能なエントリーが残るからである。さらに、使用および利用可能性はスレッド優先度および使用を考慮に入れてもよい。ここで、複数のスレッドがハードウェア資源へのアクセスを共有していた場合、資源は分割されるか、または完全に共有されてもよい。結果として、期待される使用と比較しての使用および利用可能性は、この共有を考慮に入れてもよい。よって、一つのスレッドがハードウェア資源を独占他のスレッドのために十分な利用可能性を残さないしない。たとえば、二つのスレッドが分割を通じてキャッシュへのアクセスを共有する場合、一方のスレッドからのトランザクションは、キャッシュのエントリーの半分に制限されうる。よって、使用および利用可能性は、この点で、キャッシュ全体ではなく、キャッシュの半分である。上記の議論は、ストアバッファを参照し、暫時キャッシュを参照したが、使用/利用可能性は、ストアバッファ、ロードバッファ、キャッシュメモリ、犠牲者キャッシュ、レジスタファイル、待ち行列、実行ユニットまたは他の既知のプロセッサハードウェアのようないかなる単数のハードウェア資源またはハードウェア資源の組み合わせに関していてもよい。たとえば、ハードウェア資源がキャッシュメモリを含む場合、期待される使用はタッチされる/利用されるキャッシュラインの数を含んでいてもよい;使用はデータを保持するキャッシュラインの数またはコヒーレンシー状態にある/ないキャッシュラインの数、たとえば共有される、排他的なまたは修正されたキャッシュラインの数を含んでいてもよい;利用可能性は、無効なコヒーレンシー状態のような特定のコヒーレンシー状態にある/ない利用可能なエントリーまたはラインの数を含んでいてもよい。さらに、利用可能性/使用については、利用可能性/使用を測定するハードウェアを参照してさらに論じてある。しかしながら、上述したように、使用および利用可能性は、直接または間接的に測定されてもよいし、ソフトウェア、ハードウェアまたはそれらの組み合わせによって推定されてもよい。図3aを参照するに、当該領域を完遂する十分な資源があると判定される場合、実行フローはフロー305に戻る。換言すれば、実行は、次の条件付きコミット点まで継続し、その点において、ハードウェア資源の評価が再び実行されてもよい。それでも、十分な資源が存在しないと判定される場合には、フロー320において、トランザクションはトランザクションの末尾より前に、コミットされる動的にサイズ変更される。ある実施形態では、シームレスな実行を提供するため、原子的実行を継続するよう新しいトランザクションがフロー325において開始される。ここで、単一のより大きなトランザクションが本質的には、より多くの実行スペースを与えるための仮想またはシステムメモリへの拡張なしにハードウェアによって扱うことのできる、より小さなトランザクションに動的に分割されている。図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に遭遇するとき、ある実施形態では、条件付きコミット命令415によって示される実行されるハードウェア使用を受け入れるために利用可能な十分なハードウェア資源があるかどうかをハードウェアが判定する。ハードウェア資源使用およびハードウェア資源の期待される使用を受け入れるために十分な資源が利用可能であるかどうかを判定するには、いかなる既知の方法および装置が利用されてもよい。それでも、以下では、そのような判定を実装するための一つの実施形態の例解を与えるため、具体例を論じている。ここで、デコーダ425が条件付き命令415を受け取ると、他の動作/マイクロ動作が、プロセッサパイプライン内のデコーダ425および論理430によって実行される。たとえば、デコーダ425は条件付きコミット命令415を、実行されるべき動作のトレースのような複数の動作マイクロ動作にデコードしてもよい。上記の議論から、トレースはデコード後にトレースキャッシュにおいて記憶/構築されてもよいことを注意しておく。たとえば、それらの動作の一つがハードウェア資源の使用レベルを示すためにレジスタの読み出しまたはハードウェア435からのロードを含む場合、論理430はロードバッファ中にエントリーを割り当て、実行論理440上でそのロードの実行をスケジュールしてもよい。さらに、ハードウェア435は、条件付き命令415に応答して提供、決定またはロードされるそのような使用レベル435を決定するよう適応される。上記から、使用レベルを決定させうる、トランザクション的実行をサポートするためのハードウェアの数多くの例が、キャッシュメモリ、投機的キャッシュメモリ、ストアバッファ、ロードバッファ、レジスタファイル、投機的レジスタファイル、チェックポイントレジスタファイルなどを含む。結果として、命令415は、一つまたは複数のハードウェア資源についての一つまたは複数の期待される使用メトリックを含みうる。別個のハードウェアまたは当該資源自身が、その使用レベルを追跡するよう適応される。たとえば、キャッシュメモリのためのキャッシュ制御論理が、ある実施形態では、キャッシュメモリ中に保持される無効なキャッシュラインの数またはキャッシュメモリ中の利用可能なラインの数といった、キャッシュメモリの使用レベルを追跡するよう適応される。次いで、決定されたハードウェア使用レベルと比較しての期待される使用レベルに基づいて、早期コミット動的サイズ変更なしにトランザクションの実行を継続するために十分な資源が存在するかどうかが判定される。早期コミットが実行されるべきであれば、描かれている例では、実行論理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個しかないので、十分なトランザクション的キャッシュスペースはない。結果として、ジャンプ実行ユニットのような実行論理440は、当該トランザクションを早期にコミットしてトランザクションを動的に縮小して別のトランザクションを改めて開始するようコードをフェッチし、デコードし、実行するために、分岐ターゲットアドレス420にジャンプする。上記の例は、期待されるハードウェア使用メトリックおよび分岐ターゲットアドレスを含む条件付きコミット命令を参照して論じられていることを注意しておく。しかしながら、条件付きコミット命令は、コードの実行をサポートするために十分なハードウェア利用可能性があるかどうかをハードウェアに評価または推定させる任意の命令を含んでいてもよい。たとえば、条件付きコミット命令は、単なる条件付きジャンプ命令であってもよい。ここでは、ハードウェアが現在の使用レベルを当該コードの過去のハードウェアプロファイリングと突き合わせて評価して、トランザクションがコミットされるべきかどうかを判定する。そして、該評価を行ったあとのハードウェアは、条件付きコミット命令によって与えられる分岐アドレスにジャンプすることができる。もう一つの実施形態では、ハードウェアは非同期的に特定の条件付きコミット命令に縛られたり特定の条件付きコミット命令に応答したりするのでなくトランザクションがコミットされるべきであると判定してもよい。ここで、プロセッサがトランザクション的コードを実行していて、オーバーフローイベントすでにトランザクション的にマークされているエントリーの放逐のような、ハードウェア資源にスペースが残っていないことを示すイベントが発生するとき、ハードウェアは、当該コードが何も知らないうちに、そのハードウェアトランザクションをコミットして、新しいトランザクションを改めて開始してもよい。次に図5を参照するに、トランザクションの動的サイズ変更をサポートするハードウェアのもう一つの実施形態が示されている。以前に図4に関して、判別されたハードウェア使用レベル/メトリックが、実行論理440による動作のために利用されるレジスタのような記憶要素に入れられてもよいことを論じた。その例と同様に、判別されたハードウェア使用レベル/メトリックは、同様に、レジスタ550のような記憶要素中にロードされてもよい。しかしながら、ある実施形態では、モデル固有レジスタMSRModelSpecificRegisterを含んでいてもよいレジスタ550は、ハードウェア資源利用可能性の評価を実行するためにユーザーレベルのアプリケーションコードのようなプログラムコードによってアクセス可能であるに対して明かされるよう適応される。前の例においては、ソフトウェアからの期待される使用に基づいてハードウェアが評価を実行した。ここでは、ソフトウェアがハードウェアMSR550に問い合わせをして、一つまたは複数のハードウェア資源の使用レベルを受け取ることができる。次いで、ソフトウェアは、次のコミット点まで原子的実行を継続するのに十分な資源があるかどうかを、独自のガイドラインに基づいて判定することができる。これは、ハードウェアのどのくらい多くを使用するかをユーザーが決定できるようにするので、ユーザーに対してより大きな柔軟性を提供しうる。結果として、プロセッサ設計者は、プロセッサがより多くの制御を保持するべきか、あるいはユーザーがそのような決定をできるかを選択しうる。具体的な例解用の例として、プロセッサが、潜在的に動的なサイズ変更のための挿入された/最適化されたトランザクションを含むプログラムコード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を、当該コードの単一ループ反復工程におけるストアの数の計数たとえば8で割って、閾値たとえば4を決定する。複数のストアが単一のキャッシュラインにタッチするだけのこともあるので、ストアの数の推定は、ある実施形態では、合理的な程度に保守的である。よって、より積極的な初期値が使用されてもよい。もう一つの例として、コードまたはハードウェアは、ループの実行が完遂するための十分な資源をもつことを保証するために、コードサイズ/型、ハードウェアユニットサイズ/型または他の既知の因子に基づいて積極的なまたは保守的な値を選択する。さらに、ハードウェアまたはソフトウェアはコードをプロファイリングしてもよく、開始/閾値を提供してもよい。ここで、ループの実行が始まる前に、閾値数を含むソフトウェアヒントが提供され、カウンタはその閾値数に基づいて設定される。あるいは、ハードウェアが同様にコードをプロファイリングして、コードのある領域のプロファイル履歴に基づいてカウンタを設定する。ある実施形態では、カウンタを初期化したのち、閾値開始値は動的に修正される。たとえば、ループの実行解析コードプロファイリングまたはロールバック判別に基づいて調整される。本質的には、ある実施形態では、ループ615の反復回数を推定するために使われているカウンタ650は、限られたハードウェア資源のためにロールバックが起こるまたは受け容れ可能な数のロールバックが起こる前に、実行することができる。したがって、受け容れ可能な数より多くのロールバックが起こると、コミットが起こるまでの反復工程数を減らすことによってロールバックの数を減らすために、以前の閾値は減らされる。このシナリオでは、あまりに頻繁なロールバックは実行時間を浪費し、潜在的に遅延を引き起こす。しかしながら、閾値があまりに保守的まだ利用可能な資源がたっぷりあるときに早期にトランザクションを無思慮にコミットして、非効率的な原子的実行につながるでないことを保証するために、ある実施形態では、ロールバックが実際に起こるまで閾値が増大させられる。インクリメント/デクリメントは単一の、複数のまたは指数的なきざみで行われうることを注意しておく。例として、開始値が初期に63に設定されるとするすなわち、コミットまでに64回の反復工程が許容される。ハードウェア制約条件に起因するいくつかのアボート/ロールバックが検出されたら、閾値は62にデクリメントされる。その後の諸ロールバックに際しては、実行が効率的に完了することが許容されるバランスの取れた開始値が決定されるまで、閾値はさらに260、456、848などだけデクリメントされる。図6の議論は、条件付きコミット命令に特に言及することなく、ループ反復回数を数えるカウンタを参照していたことを注意しておく。ここでは、カウンタが閾値に達することは、非同期的にハードウェアを通じてコミットを開始しうる。しかしながら、もう一つの実施形態では、カウンタ650は図5および図6からの条件付きコミットコードと連携して作用する。例として、カウンタは、利用可能なハードウェア資源の量を判別/推定するハードウェア機構であってもよく、条件付きコミット命令はハードウェアカウンタに基づいてコミットコードへのジャンプを引き起こす。たとえば、カウンタ650が9に初期化されるとする条件付きコミットが起こるまでに10回の反復工程が許容される。ループ615の反復工程毎に、条件付きジャンプ命令のような条件付きコミット命令が実行されて、カウンタが満了していればゼロに達していれば分岐ターゲットアドレスへのジャンプが行われる。10回目の反復工程が完了して条件付きジャンプが実行されるとき、実行フローは、実行中の原子的領域のコミットのためのターゲットアドレスにジャンプする。カウンタは個々のハードウェアユニットの厳密で個別的な使用レベル測定ではないが、潜在的にはより包括的な推定である。上記で論じたように、閾値の動的調整を通じて、ハードウェア制限に基づくロールバックを減らすための最適な反復工程回数が見出されてもよい。したがって、何らかの以前に同定されていないハードウェア制限がロールバックを引き起こしている場合、動的カウンタ閾値はそれを捕捉することができ、一方、設計者またはプログラマーによる個々の同定はそのような同定されていない原因を逃してしまうことがありうる。さらに、カウンタは個別的なハードウェアユニット利用度測定とともに利用されて、ユニットレベルの粒度および広範なグローバル粒度の両方を提供してもよい。先の議論は主として、ハードウェア資源が尽きる前にトランザクションを条件付きでコミットすることに焦点を当てていた。すなわち、実行をサポートするために十分な資源が利用可能であるかどうかを判定するために期待される利用度に対するハードウェア利用度を判別するのである。しかしながら、いくつかの実施形態では、原子的領域を通じて実行することが有利でありうる。そして定期的にユーザー命令、イベントまたはハードウェアで定義された時間に応答して原子的領域のチェックポイントを作成するのである。よって、実際のハードウェア制限、例外、割り込みまたは他の障害に遭遇すると、原子的領域は最近の中間的なチェックポイントにロールバックされ、空いている資源にコミットされることができる。本質的には、先を見た推定をしてプロアクティブにトランザクションをコミットする代わりに、ある実施形態では、通常ならトランザクション全体のアボートおよび再開を必要とするような実際の資源の制限に遭遇したとき、トランザクションはサイズ変更されるだけである。これは、ロールバックが起こった場合にロールバックされるのが受け容れ可能な量の実行だけであることを保証するよう、トランザクション内で複数のチェックポイントを実行することによって達成される。図7aに目を転じると、トランザクション内の投機的チェックポイントのための備えをすることを含む、コード最適化方法の流れ図のある実施形態が描かれている。ブロック705では、最適化されるべきプログラムコードのセクションが同定される。図2aの議論と同様に、コードのセクション/領域の同定は、そのセクションに関するユーザーの同定/ヒント、プログラム解析、コードプロファイリング、コード属性特定の型、フォーマット、順序orderまたは当該領域の特性――ループまたはストア回数または最適化されるべきコード領域を同定するための他の既知の方法に基づいて行われてもよい。一例では、コードはバイナリーコードを含む。バイナリーコードの実行中、バイナリーコードは動的に最適化される。結果として、実行のための最適化の間、バイナリーコード中でループに遭遇する。よって、ロールバックが大量の実行の喪失につながらないほどチェックポイント間の距離が十分短くなることを保証するよう、そのループが最適化される投機的チェックポイントが挿入されるものと判別される。例として、下記の擬似コードFは最適化されるべきコード領域の例を示している。図2aの議論と同様に、フロー710、715において、コードの領域は区画される当該セクションの始めに原子的領域開始命令を、当該セクションの終わりに原子的領域終了命令を挿入する。上述したように、コード領域は複数の入口および複数の出口を含んでいてもよい。ブロック720において、プログラムコード内の投機的チェックポイント位置が判別される。複数の投機的チェックポイントが最適化されるべきコードの領域内に判別/割り当てされてもよいことを注意しておく。ただし、議論の簡単のため、下記では一つのチェックポイントだけがより詳細に論じられる。投機的チェックポイントの判別は、原子的領域内でのロールバック効果を最小限にするためのいかなる既知の割り当て/判別アルゴリズムに基づいていてもよい。第一の例として、反復工程のたびに投機的チェックポイントに遭遇するよう、ループ内に投機的チェックポイントが挿入される。ここで、投機的チェックポイントは、ループの始めまたはループの端に決定されてもよい。もう一つの例として、コードの動的プロファイリングは、しばしばハードウェア資源が使い尽くされる結果につながる、または高い命令計数をもつ実行経路を示す。よって、長い実行経路内でのアボートのために原子的領域全体をロールバックするのを避けるため、そのような実行経路に投機的チェックポイントが割り当てられる。同様に、独占するまたは資源要求がヘビーであると知られている実行経路に投機的チェックポイントが割り当てられてもよい。本質的には、従来技術の、トランザクション全体の前にあるチェックポイントおよびトランザクション全体の関連したロールバックの代わりに、トランザクション内のチェックポイントローカル、内部または一時的チェックポイントを利用することによって、より小さなロールバック無駄になる実行がより少ないが実行される。結果として、より大きな領域が最適化されうる。資源制限に遭遇した場合には、小さなロールバックが実行される。さらに、ロールバック点において、トランザクションは潜在的にコミットされ、結果的な障害が対処され、もう一つのトランザクションが改めて開始される。フロー725において、投機的チェックポイント位置に投機的チェックポイントコードが挿入される。投機的チェックポイントコードは、メモリ、キャッシュメモリおよび/またはレジスタファイルのような投機的ハードウェア資源にチェックポイントを作成する。ある実施形態では、投機的チェックポイントコードは、その後のアボート条件に応答してハードウェア資源をチェックポイントまで復元するためのコードをも含んでいてもよい。暫時図7bに目を転じると、投機的チェックポイントコードを挿入するための流れ図のある実施形態が示されている。擬似コードGも、投機的チェックポイントコードの挿入後のコードの例解用の例を描いている。フロー726では、投機的チェックポイントspeculativecheckpointB2、B5のループバック端において投機的チェックポイント命令/動作B5におけるL1が挿入される。ある実施形態では、投機的チェックポイント命令は、投機的ハードウェア資源のチェックポイント現在のスナップショットを開始する任意の命令を含む。たとえば、投機的チェックポイント命令は、プロセッサのデコーダによって認識可能である。そしてひとたびデコードされ、スケジュールされ、実行されたら、チェックポイント投機的レジスタファイルおよび投機的キャッシュのようなチェックポイント記憶構造中に投機的レジスタファイル、ストアバッファまたは両方のチェックポイント現在状態のスナップショットを作成させる。さらに、ある実施形態では、投機的チェックポイントコードは、現在のロールバックを引き起こしたのと同じロールバック状況を潜在的に回避するよう何らかのアクションを実行する他の何らかのコードをも含む。たとえば、限られたハードウェア資源のためにロールバックrollbackが起こる場合、軽減アクションが行われなければ、同じハードウェア制限に毎回遭遇して、先に進めないことになりうる。例として、擬似コードHの左側のコードが最適化されるものとする。ここで、最適化されるコード内のロールバックにいかにして対処するかについて複数のシナリオがある。第一の例として、下記の擬似コードIに示されるように、投機的チェックポイント命令は、通常のループ実行か投機的チェックポイントへのロールバック後の再実行かの区別をすることができる条件付き分岐命令と対にされる。分岐命令が実行されると、前のチェックポイント作成された状態にロールバックするための任意の既知の仕方で、ロールバックを扱う異なる実行経路にジャンプする。もう一つのシナリオでは、下記の擬似コードJに示されるように、投機的チェックポイント命令が、単一のチェックポイントへの分岐命令およびいくつかの実施形態においてすでに論じた分岐命令と組み合わされる。擬似コードGの議論に戻ると、ある実施形態では、投機的チェックポイントspeculativecheckpointコードはフィックスアップfixupロールバック、復元、再構成、リカバリーなどとも称されうるをも含む。これは、実行されたときに、チェックポイント記憶構造から最新のチェックポイントの正確な状態を復元または回復する。上記の他のシナリオも、いくつかの実施形態では、投機的チェックポイントコードおよび/またはフィックスアップコードと考えられうることを注意しておく。それでも、ここでは、擬似コードGに示されるように、フィックスアップコードは、トランザクション/原子的領域をコミットするコミットコードB6をも含んでいてもよい。投機的ハードウェアが尽きるかアボートを引き起こすイベント割り込み、動的アサーションdynamicassertion、メモリエイリアスチェックなどに遭遇すると、チェックポイントコードは投機的ハードウェアにおける正確な状態を復元する。さらに、投機的ハードウェアを再実行および継続される実行のために解放するため、トランザクションは任意的にコミットされる。この議論から、フィックスアップコードに達することは、複数の仕方でなされうることが見て取れる。例として、フィックスアップコードには:1チェックポイント記憶構造が投機的ハードウェアのチェックポイントを作成するための十分なスペースをもたない投機的チェックポイント動作の実行;2投機的ハードウェアが受け入れることができない投機的動作の実行;3投機的実行の間の例外;または4トランザクション内の一時的な内部チェックポイントへのロールバックにつながる他の任意のイベント、からはいることができる。さらに、投機的チェックポイントは、条件付きコミットと組み合わされてもよい。これにより、投機的資源の欠如に起因するアボートを回避しつつ、チェックポイント作成のため障害、例外または他の予測不能な原因に起因するそのようなロールバック/アボートをずっと安価にする原子的領域全体の始まりではなくチェックポイントに戻ることで無駄にされる実行が少なくなるといったさらなる利益が得られる。下記の擬似コードKはそのような組み合わせの一例を描いている。さらに、ある実施形態では、条件付きコミット命令が下記の擬似コードLに示されるように、投機的チェックポイントを知らされる。この場合、領域チェックregioncheck条件付きコミット命令は、システムが資源を使い尽くそうとしている場合上記のようにまたは実行が実行が投機的チェックポイントにロールバックしたあとのロールバックリプレーである場合にL2にジャンプする。さらに、投機的チェックポイントspeculativecheckpointおよび条件付きコミット命令が一緒に使用されうるのみならず、それらの命令自身も、ある実施形態では、下記の擬似コードMに描かれるように組み合わされる。ここで、組み合わされた命令が実行されると、チェックポイントが実行され、条件付きコミットが評価される資源のハードウェアが使い尽くされようとしているまたは残り少なくなる場合にコミットする。ここで、システムの投機的資源が少なくなっている場合または記録された投機的チェックポイントに実行がロールバックする場合、実行はL2にジャンプし、この例では投機的資源をコミットして結果的な障害にサービスすることによってそれに対処する。上記の議論は、ひとたびハードウェアが少なくなる、障害が検出される、例外が発生するまたは他の予測不能なイベントが割り込みを引き起こしたときの以前のまたは最近の投機的なチェックポイントへのロールバックに言及しているが、そのような割り込みに応答して他の経路が探求されてもよい。実際、ある実施形態では、割り込み時に、ハードウェア、ソフトウェアまたはそれらの組み合わせが、次に何をするかについての判断をする。たとえば、ハードウェア生成された障害/イベントのような障害が原子的実行の間に発生するとする。原子的実行は割り込まれる。そして、通常は、障害の型を決定し、障害にサービスするために制御はソフトウェアに渡される。ここで、ハンドラのようなソフトウェアは、次に何をすべきかの決定を、障害の型、最も最近の投機的チェックポイントへのロールバックにおける難しさ、最も最近の投機的チェックポイントではなく最後のコミット点にロールバックすることによって失われる反復工程の回数または実行の量または戻りのためにプログラムにおいて実行の点を選択する際の他の既知の因子など、任意の数の因子に基づいて行ってもよい。本質的には、この例解用の例では、ハンドラのようなソフトウェアが、実行が原子的領域の始まり、原子的領域内の最後のコミット点または原子的領域内の最新の投機的チェックポイントのいずれにロールバックされるべきかどうかの決定をしている。これらの例はソフトウェアがその決定をすることに焦点を当ててきたが、ハードウェアがそのような決定をしてもよい。ある実施形態では、新しい命令投機的ロールバックspeculativerollbackがその決定をするのに利用される。ここで、投機的ロールバック命令は、ひとたびデコードされて実行されたらプログラムコード中の適切な箇所投機的チェックポイントまたは最近のコミット点への戻りにつながる任意の情報を含む。本稿に記載されるコードが、同じブロック、領域、プログラムまたはメモリ空間内で共位置である必要がないことに注意しておくことが重要である。実際、投機的チェックポイント動作は、主たるプログラムコード内のループバック端に挿入されてもよい。そして直近のチェックポイントにロールバックし、任意的にはトランザクションをコミットするコードを含むフィックスアップコードは、ライブラリまたはコードの他の部分に位置していてもよい。ここで、主たるプログラムコードが実行中である。そしてフィックスアップコードにはいろうとするとき、ロールバックおよびコミットを実行するために、ライブラリコードの一つまたは複数の関数への呼び出しが実行される。また、ソフトウェアの指令なしにハードウェアが同様のチェックポイント動作を実行してもよい。ここで、ハードウェアは、定期的にまたはイベント駆動の仕方で、投機的ハードウェアを透明にチェックポイント化する。そして投機的ハードウェアが使い尽くされるのに応答して、プロセッサは実行を最新のチェックポイントにロールバックし、トランザクションをコミットし、トランザクションを改めて開始し、チェックポイントとロールバック点との間の命令をリプレーする。ソフトウェアの観点からは、ハードウェアが資源制約および再実行のすべてを扱う間、実行は通常に続いてきている。それでも、ローカルな内部的トランザクションチェックポイントを達成するために、ハードウェアとソフトウェアの間の任意のレベルの協調も使用されうる。図7aに戻ると、ブロック730において、プログラムコードのセクションが最適化される。下記の擬似コードNは最適化後の擬似コードMからのコード領域の例を描いている。最適化のもう一つの例として、下記の擬似コードOは最適化のもう一つの例擬似コードGからのコード領域の最適化を示している。上記で論じたように、原子的領域内のコードに対していかなる既知の最適化技法が実行されてもよい。非網羅的なリストであり純粋に例示するものとして、コード最適化のいくつかの例を挙げておくと、ループ最適化、データフロー最適化、コード生成最適化、境界チェック消去boundscheckingelimination、分岐オフセット最適化、デッドコード消去およびジャンプ接続jumpthreadingがある。擬似コードOでは、B6においてコミットしたのち、もう一つのトランザクションがB6において開始され、実行はB2において継続される。他の実施形態図示せずでは、コードはB3において再入されてもよい。原子的領域の区画および条件付きコミットコードの挿入は、いくつかの実施形態においてプログラムコードを最適化すると考えられてもよい。次に図8を参照するに、トランザクションの実行中にメモリを投機的にチェックポイント化する方法の流れ図のある実施形態が示されている。フロー805では、トランザクションが実行される。一例として、トランザクションは、ランタイムの間に動的に最適化されるバイナリーコードになっている。トランザクションは原子性を保証するコード最適化のまわりに挿入される。フロー810では、トランザクションからの投機的チェックポイント命令に遭遇する。投機的チェックポイント命令は、図7a~bを参照して上記で論じたように、投機的チェックポイントにおいて最適化器によってランタイムの間に挿入されたものであってもよい。プロセッサは、投機的チェックポイント命令を典型的にはあらかじめ指定された/定義された動作コードを検出するデコーダによって認識する。そして投機的チェックポイント命令に応答して、フロー815において、投機的レジスタファイルがチェックポイント投機的レジスタファイルにおいてチェックポイント化される。さらに、フロー820において、投機的キャッシュがストアバッファのチェックポイントを作成するための十分なスペースを含んでいるかどうかが判定される。もし十分なスペースが利用可能であれば、フロー825において、ストアバッファは投機的キャッシュ内でチェックポイント作成される。しかしながら、十分なスペースがない場合には、フィックスアップ/ロールバック手順下記でより詳細に論じるブロック845~855が実行される。結果として、トランザクションの実行中に短期のロールバックイベントが遭遇される場合、現在の実行に利用されている投機的なレジスタファイルおよびストアバッファはチェックポイント化された状態に復元されることができる。例として、フロー830では、ストア動作に遭遇する。フロー835では、ストアバッファstorebufferが、ストア動作のために割り当てられるよう利用可能なエントリーなどの利用可能なエントリーを含むかどうかが判定される。すぐ利用可能なエントリーがあるか、割り当て解除されて再割り当てされうるエントリーがある場合には、ブロック840において、そのエントリーがそのように割り当てられる。しかしながら、利用可能なストアバッファエントリーがない場合には、ロールバック手順ブロック845~855が実行される。ロールバック/リカバリー手順845~855は、前のチェックポイントからの正確なアーキテクチャ状態を復元するものである。ここで、ロールバックは、コミットしていないグローバルに可視にされていない投機的実行の間のものである。したがって、グローバルに可視の状態非投機的な記憶構造は同じままに留まるべきである。しかしながら、現在の投機的実行をサポートする投機的なハードウェア構造は復元される。投機的キャッシュはすでに、ストアバッファからの投機的更新を最も最近のチェックポイントまで保持しているので、ブロック850においてストアバッファはフラッシュflushされる。換言すれば、トランザクションの始まりから最も最近のチェックポイントまでのストアは投機的なキャッシュ内に保持される。そして、最も最近のチェックポイントから現在の実行点ロールバックの開始までのストアがストアバッファに保持される。よって、ロールバックされようとしているストアは単に、ストアバッファから破棄される。さらに、投機的レジスタファイルがチェックポイントレジスタファイルから復元される。ここで、投機的レジスタファイルは、最も最近のチェックポイントからのものを含め、トランザクションの開始からのすべての更新を保持する。よって、投機的レジスタファイルは、チェックポイントレジスタファイルからの値を改めてロードされる。もとのチェックポイントが投機的レジスタファイル全体のコピーを含む投機的実行の間に修正されたレジスタのみを選択的に記憶するのではなく場合、チェックポイントレジスタファイルは投機的レジスタファイルとしてラベル変更再利用されてもよく、前の投機的レジスタファイルはフラッシュされ、その後はチェックポイントレジスタファイルとして利用されてもよい。あるいは、投機的レジスタファイルが投機的チェックポイントレジスタファイルに一ないし数サイクルでフラッシュコピーされてもよい。フロー860では、トランザクションが任意的にコミットされうる。ロールバック手順に達するのは例外、投機的キャッシュにおけるスペースの欠如またはストアバッファにおけるスペースの欠如に応答してなので、そうした資源を解放するためにそのトランザクションはコミットされてもよい。ここで、ストアバッファおよび投機的キャッシュ更新は非投機的キャッシュメモリにコミットされて、それらの資源を解放するフロー875~880に示す。そして同様に、投機的レジスタファイルは非投機的レジスタファイルにコミットされて、さらなる投機的実行のために解放されるフロー875~880に示す。さらに、トランザクションの完全なアボートが実行される865場合、ブロック870において、ストアバッファおよび投機的キャッシュがフラッシュされて、トランザクション前の非投機的状態に復元される。図9に目を転じると、投機的チェックポイント作成をサポートするよう適応されたハードウェアの論理的な表現のある実施形態が描かれている。デコーダデコード論理910は、投機的チェックポイント命令SCPIspeculativecheckpointinstruction905を認識するよう適応または相互接続される。たとえば、図9のハードウェアを含むプロセッサのための命令のあらかじめ定義されたフォーマットが、指定され、ハードウェア中に設計されていてもよい。そして特定のビットパターンをもつ前記命令の一部分が、個別的な命令に対応する。その一つがSCPI905である。次いで、SCPIに応答して、投機的記憶構造に保持されている投機的な値935が、投機的チェックポイント記憶構造における投機的チェックポイント値940としてチェックポイント化される。SCPI920を実行するために実行論理920がデコーダに結合されて示されていることを注意しておく。それでも、明らかに、デコードと実行の間にはパイプラインの多数の段階があることがしばしばである。たとえば、SCPIはトレースキャッシュ内の動作のトレースにデコードされてもよく、それらの動作がバッファにおいて待ち行列化され、スケジュールされ、ディスパッチされ、実行されて、本稿で記載される動作/方法を実行してもよい。上記で手短に述べたように、チェックポイントはある時点における値の状態のスナップショットまたはその時点における値のその状態を復元するための少なくとも十分な情報である。したがって、チェックポイントは、ある実施形態では、投機的な値935の全体のコピーを投機的チェックポイント値940として含む。ここで、投機的な値935は、投機的レジスタファイルからの投機的レジスタファイル値を含んでいてもよく、投機的チェックポイント値940は時間的に最も最近のチェックポイントにおける投機的レジスタファイルのコピーを含む。もう一つの例として、投機的チェックポイント値は最後のチェックポイント以来修正されている投機的な値935のみを含む。ここでは、投機的な値935は、投機的レジスタファイルからの投機的レジスタファイル値を含んでいてもよく、投機的チェックポイント値は最後のチェックポイント以来修正されている投機的レジスタファイル中のレジスタのみからの、最後のチェックポイントからの投機的レジスタファイル値を含む。さらにもう一つの例では、投機的チェックポイント値940は原子的領域の始まりから時間的にあるチェックポイントまでの値のすべてを含み、一方、投機的な値935は該チェックポイントから現在の実行点までの投機的な値のすべてを含む。ここで、投機的な値935をストアバッファが保持してもよく、これが投機的キャッシュに保持される始まりから最後のチェックポイントまでの古い値に加えられる。図10を参照するに、レジスタファイルの投機的なチェックポイント作成をサポートするよう適応されたハードウェアの論理的な表現のもう一つの実施形態が描かれている。上記の議論と同様に、デコーダ1010および実行論理102はそれぞれSCPI1005を受け取り、認識し、実行するよう適応される。SCPI1005に応答して、投機的レジスタファイル1035は投機的チェックポイントレジスタファイル1040中にチェックポイント化される。上述したように、チェックポイントはレジスタファイル1035のチェックポイントレジスタファイル1040中へのフラッシュコピーflashcopyを含んでいてもよい。あるいは、ファイル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に保持されている投機的な値からロードすることを注意しておく。したがって、インフライトinflightストア機構の同様のロードが、ストアバッファ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および0としても言及されるが、これは単に二値論理状態を表すものである。たとえば、1が高論理レベルを指し、0が低論理レベルを指す。ある実施形態では、トランジスタまたはフラッシュセルのような記憶セルが単一の論理値または複数の論理値を保持することができてもよい。しかしながら、コンピュータシステムにおける値の他の表現が使用されてきた。たとえば、十進法の数10は二進法の値1010として表現されてもよく、十六進法の文字Aで表されてもよい。したがって、値は、コンピュータシステムにおいて保持されることのできる情報の任意の表現を含む。さらに、状態は値または値の一部によって表現されうる。例として、論理的な1のような第一の値がデフォルトまたは初期状態を表してもよく、論理的な0のような第二の値が非デフォルト状態を表してもよい。さらに、用語リセットおよびセットは、ある実施形態では、それぞれデフォルトおよび更新された値または状態を指す。たとえば、デフォルト値は潜在的に高い論理値、すなわちリセットを含み、更新された値は潜在的に低い論理値、即ちセットを含む。値のいかなる組み合わせがいかなる数の状態を表すために利用されてもよいことを注意しておく。上記で述べた方法、ハードウェア、ソフトウェア、ファームウェアまたはコードの実施形態は、機械アクセス可能または機械可読媒体上に記憶された、処理要素によって実行可能な命令またはコードを介して実装されてもよい。機械アクセス可能/可読媒体は、コンピュータまたは電子システムのような機械によって読み取り可能な形で情報を与えるすなわち、記憶するおよび/または伝送する任意の機構を含む。たとえば、機械アクセス可能媒体は静的RAMSRAMまたは動的RAMDRAMのようなランダムアクセスメモリRAM;ROM;磁気または光学式記憶媒体;フラッシュメモリデバイス;電気的記憶デバイス;光学式記憶デバイス;音響記憶デバイス;伝搬される信号たとえば、搬送波、赤外線信号、デジタル信号を保持するための他の形の記憶デバイスなどを含む。本明細書を通じた一つの実施形態またはある実施形態への言及は、その実施形態に関連して記述される特定の特徴、構造または特性が本発明の少なくとも一つの実施形態に含まれることを意味している。よって、本明細書を通じて随所に一つの実施形態ではまたはある実施形態ではという句が現れるのは、必ずしもみなが同じ実施形態に言及しているわけではない。さらに、それら特定の特徴、構造または特性は一つまたは複数の実施形態においていかなる好適な仕方で組み合わされてもよい。以上の明細書において、特定の例示的な実施形態に言及しつつ詳細に述べてきたが、付属の請求項に記載される本発明の広義の精神および範囲から外れることなくそれにさまざまな修正や変更をなしうることは明白であろう。よって、本明細書および図面は、制約する意味ではなく、例解する意味で見られるものである。さらに、実施形態および他の例示的な言辞の上記での使用は必ずしも同じ実施形態や同じ例を指すのではなく、異なる、区別される実施形態を指すことも、潜在的には同じ実施形態を指すこともある。