(57)【特許請求の範囲】
【請求項１】
ロック要求を処理するためのデータ構造を有するモニタを利用して、複数のプロセッサにより実行される競合するスレッドによる共有リソースへのアクセスを制御するステップと、前記データ構造は、一期間における固有のスレッドのアクセスのカウントを保持する拡張フィールドを有しており、
前記一期間における競合するスレッドによるロックの固有の要求の数を前記カウントとして記憶するステップと、
前記カウントが競合の閾値を超えているかを判定して、前記ロックを「重度に競合している」ロックとして識別するステップと、
前記カウントが前記閾値を超えない場合に前記カウントを保持するステップと、
前記ロックへのアクセスを得ていない前記複数のプロセッサのうちの第一のプロセッサによりアクセス可能なメモリにフラグ変数を設定するステップと、
前記複数のプロセッサのうちの第二のプロセッサが前記ロックを解除したときに、アクセスを得ていなかった前記第一のプロセッサにアクセスを許可するため、バススヌープサイクルの間に前記フラグ変数を変更するステップとを含み、
アクセスを得ていなかった前記第一のプロセッサは、スピンループの状態のままであり、前記フラグ変数を変更するステップまでバストラフィックを発生しない
ことを特徴とする方法。
【請求項２】
当該方法は、前記カウントを記憶する前に、
モニタについてのスレッドの要求を検知するステップと、
要求しているスレッドが前に要求したスレッドと異なるかを判定するステップと、
前記要求しているスレッドが前記前に要求したスレッドと異なることを示す比較に応答して、競合を示す前記カウントをインクリメントするステップと、
を更に含む請求項１記載の方法。
【請求項３】
前記カウントが競合の前記閾値を超えているかを判定する前記ステップは、
前記カウントを前記閾値と比較するステップと、
前記カウントが前記閾値を超えるときを判定するステップと、
前記閾値を超える前記カウントに応答して、前記ロックを「重度に競合している」ロックとして識別するステップと、
を含む請求項２記載の方法。
【請求項４】
前記カウントが競合の前記閾値を超えているかを判定する前記ステップは、
ロックについて重度に競合しているために選択された方式に従ってロック要求を選択することで、前記ロックを重度に競合しているとする前記識別に応答するステップを更に含む、
請求項３記載の方法。
【請求項５】
前記カウントが競合の前記閾値を超えているかを判定する前記ステップは、
前記複数のプロセッサにより共有リソースへの前記ロックの要求を処理するステップと、
前記要求の間で調停を行うステップと、
前記第二のプロセッサである勝者のプロセッサによる前記ロックへのアクセスを提供するステップと、
前記勝者のプロセッサに対してキャッシュ可能なメモリにおける前記フラグ変数へのアクセスを発するステップと、
を含む請求項４記載の方法。
【請求項６】
アクセスを得ていない前記第一のプロセッサが、該アクセスを得ていない前記第一のプロセッサにより実行される前記スピンループを分離するためにメモリエレメントから新たな値を取得するため、リードサイクルを発するステップを更に含む、
請求項１記載の方法。
【請求項７】
前記メモリエレメントは前記メモリである、
請求項６記載の方法。
【請求項８】
プロセッサにより実行されたときに、プロセッサに、
ロック要求を処理するためのデータ構造を有するモニタを利用して、競合するスレッドによる共有リソースへのアクセスを制御し、
前記モニタのデータ構造に、一期間における固有のスレッドのアクセスのカウントを保持する拡張フィールドを設け、
競合するスレッドによるロックについて複数のプロセッサによる固有の要求の数を記録し、前記一期間における競合するスレッドの数を示すカウントを記録し、
前記カウントが閾値を超えているかを判定して、前記ロックを「重度に競合している」ロックとして識別し、
前記カウントが前記閾値を超えない場合に前記カウントを保持し、
前記ロックへのアクセスを得ていない前記複数のプロセッサのうちの第一のプロセッサによりアクセス可能なメモリにフラグ変数を設定し、
第二のプロセッサが前記ロックを解除したときに、アクセスを得ていなかった前記第一のプロセッサにアクセスを許可するため、バスサイクルの間に前記フラグ変数を変更し、
アクセスを得ていなかった前記第一のプロセッサは、スピンループの状態のままであり、前記フラグ変数の変更までバストラフィックを発生しない、
動作を実行させる命令を記憶するコンピュータ読取り可能な記録媒体。
【請求項９】
前記カウントを記録する前記命令は、
モニタについてスレッドの要求を検知し、
要求しているスレッドが前に要求したスレッドと異なるかを判定し、前記要求しているスレッドが前記前に要求したスレッドと異なることを示す比較に応答して、競合を示す前記カウントをインクリメントする、
動作を実行させる命令を含む請求項８記載のコンピュータ読取り可能な記録媒体。
【請求項１０】
前記カウントが競合の前記閾値を超えているかを判定する前記命令は、
前記カウントを前記閾値と比較し、
前記カウントが前記閾値を超えるときを判定し、
前記閾値を超える前記カウントに応答して、前記ロックを「重度に競合している」ロックとして識別する、
動作を実行させる命令を含む請求項９記載のコンピュータ読取り可能な記録媒体。
【請求項１１】
ロックについて重度に競合しているために選択された方式に従ってロック要求を選択することで、前記ロックが重度に競合しているとする前記識別に応答する、
動作を実行させる命令を更に含む請求項１０記載のコンピュータ読取り可能な記録媒体。
【請求項１２】
前記カウントが競合の前記閾値を超えているかを判定する前記命令は、
前記複数のプロセッサにより共有リソースへの前記ロックの要求を処理し、
前記要求の間で調停を行うステップと、
前記第二のプロセッサである勝者のプロセッサによる前記ロックへのアクセスを提供し、
前記第一のプロセッサに対してキャッシュ可能なメモリにおける前記フラグ変数へのアクセスを発する、
動作を実行させる命令を更に含む請求項８記載のコンピュータ読取り可能な記録媒体。
【請求項１３】
当該コンピュータ読取り可能な記録媒体は、Ｊａｖａ（登録商標）仮想マシンである、
請求項１２記載のコンピュータ読取り可能な記録媒体。
【請求項１４】
バスサイクルの間に前記フラグ変数を変更した後、前記第一のプロセッサは、前記第一のプロセッサにより実行されている前記スピンループを分離するためにメモリエレメントから新たな値を取得するため、リードサイクルを更に発する、
動作を実行させる命令を更に含む請求項８記載のコンピュータ読取り可能な記録媒体。
【請求項１５】
前記バスサイクルはスヌープバスサイクルである、
請求項１４記載のコンピュータ読取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｊａｖａ（登録商標）スレッドによる同期の性能を向上するためのソフトウェア及びハードウェアのアプローチに関する。
【背景技術】
【０００２】
サーバ、或いは上位エンドワークステーション上で実行されるＪａｖａ（登録商標）ソフトウェアは、多くのＣＰＵ（中央処理装置）による実行を可能にするように設計されている場合がある。Ｊａｖａ（登録商標）は、スレッドで一般に実行される。スレッドは、プログラムで実行する１つの連続的な制御フローである。また、スレッドは、実行環境又は軽量プロセスと呼ばれる。複数のスレッドは、同時に実行する。スレッドは、グローバルデータ、メモリ、コードのクリティカルセクション及び他のリソースのようなリソースを共有する。共有リソースは、関連する「ロック」を有している。スレッドは、あるリソースにアクセスするために、そのリソースに関するロックを取得しなければならない。性能を制限するキーとなるボトルネックは、「ロッキング」、すなわち複数のスレッドによる同じ共有リソースへのアクセスの同期を実現することである。Ｊａｖａ（登録商標）プログラムでは、一般に使用されているアクセス制御は、「モニタ」構造である。基礎になるＪａｖａ（登録商標）仮想マシン（ＪＶＭ）は、ソフトウェアで具体化され、Ｊａｖａ（登録商標）プログラムのためのランタイム環境を提供し、要求されるロック機構を実現するための役割を果たす。ＪＶＭにより採用される実現のアプローチ、及びプラットフォームにおける同期のプリミティブのためのハードウェアのサポートに依存して、マルチプロセッササーバ上で実行する電子商取引事業で使用されるＪａｖａ（登録商標）ソフトウェアに関して広いバリエーションの性能を実現することができる。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
同期のために使用され、殆どのプロセッサで実現されている一般的なハードウェア技術は、“ＸＣＨＧ”のような命令の実行によりもたらされる、極微な読出し・修正・書込みバスサイクルである。ロック（したがって、ロックによりプロテクトされるリソース）を求める競合が深刻な環境では、複数のＣＰＵは、同じロック又は一組のロックのオーナシップを確保しようとして、ロックされた読出し・修正・書込み処理を同時に実行することができる。これは、大群（ｔｈｕｎｄｅｒｉｎｇ  ｈｅｒｄ）問題と呼ばれ、システムバスでの重度の競合を引き起こす。結果的に、マイクロプロセッサのスケーラビリティが制限される。結果として、性能上の深刻な低下を受ける。
【０００４】
この問題を例示するサンプルコードが以下の表１に示される。
【０００５】
【表１】
0004739282.tif 000002
４行目において、処理ｃｍｐｘｃｈｇ命令は、利用可能なロックを探す。５行目において、利用可能なロックが発見されない場合、ロック状態は０から１に変化される。９行目において、あるロックを確保する試みがある。１０行目において、そのロックが空いているかに関して問合せがあり、１１行目で回答が提供される。この場合では、そのロックを取得するための試みは不成功であり、ロックされていないリソースを発見するまで、処理は継続されなければならない。ロックの競合に関連するオーバヘッドを最小にすることが望まれている。
【発明を実施するための最良の形態】
【０００６】
本発明は、添付図面を参照して以下の記載における例示を通して説明される。
【０００７】
従来技術のＪＶＭ又は等価なランタイム環境は、Ｊａｖａ（登録商標）プログラムと、該プログラムが実行するプラットフォームとの間の「媒介者」としてのその役割のため、ユニークな位置にある。プラットフォームは、オペレーティングシステム及びハードウェアを含んでいる。多くのＪＶＭは、プログラムが殆どの時間を費やすコードの最適化のために使用される適応型のコンパイル技術と合わせて、ジャストインタイム・コンパイラを含んでいる。図１は、モニタのデータ構造に関する図である。
【０００８】
「モニタ」は、共有リソースへのアクセスを制御するための技術である。モニタは、明示的なキューとの共有クラスである。共有クラスの効果は、たとえば、クラスを作成することによりＪａｖａ（登録商標）で達成される。Ｊａｖａ（登録商標）では、全てのフィールドは、プライベートフィールドであり、全ての方式が同期される。１を超えるスレッドによりアクセスすることができる変数のみがモニタのフィールドである。モニタの方式は、同期される。したがって、モニタにおけるアクセスは、相互に排他的である。結果的に、モニタは、スレッドへの相互に排他的なアクセスを提供するための必要を満たす。本発明の１つの特徴は、ロックの競合に関する動的なプロファイル（属性分類）情報（ｄｙｎａｍｉｃ  ｐｒｏｆｉｌｉｎｇ  ｉｎｆｏｒｍａｔｉｏｎ）を収集するための能力を提供することにある。このために、モニタデータ構造１０には、拡張フィールド１４が追加される。
【０００９】
Ｊａｖａ（登録商標）の「モニタ」方式は、２種類のスレッド同期、排他制御及び相互連動をサポートする。排他制御は、オブジェクトロックを介してＪａｖａ（登録商標）仮想マシンでサポートされており、これにより、複数のスレッドは、互いに干渉しあうことなしに共有データに関して独立に作業することができる。相互連動は、「待ち」及び「修正」方法を介してＪａｖａ（登録商標）仮想マシンにおいてサポートされており、これにより、スレッドは、共通の目的に向けて互いに作業することができる。本実施の形態に係る記載は、排他制御の環境におけるものである。
【００１０】
１つのスレッドは、あるモニタを同時に取得する。拡張フィールド１４は、ＪＶＭのソフトウェアにおけるモニタデータ構造１０に追加される。典型的なモニタデータ構造は、数ビットの追加によりメモリ使用の大幅な増加が引き起こされないように、すなわちＪａｖａ（登録商標）の性能に悪影響を及ぼさないように十分に大きい。この拡張フィールド１４は、Ｊａｖａ（登録商標）スレッドが所与のモニタに関するオーナシップを得るために要求する情報をＪＶＭに与える。あるスレッドは、オブジェクトを使用するための権利を取得し、次いで、権利の取得が行われたときにロック／モニタを解除する。そのスレッドが、そのオブジェクトを使用することを再び必要とするとき、そのロックを再び取得し、ロックの取得が行われたときに再びロックを解除する、等が行われる。拡張フィールドは、所与の時間において唯一のスレッド（ｕｎｉｑｕｅ  ｔｈｒｅａｄ）によりモニタに対して行われる唯一のアクセス（ｕｎｉｑｕｅ  ａｃｃｅｓｓ）の「カウント」を保持するために、ＪＶＭにより使用される。短時間の間に、あるモニタのオーナシップを得ることを多数のスレッドが試みた場合、カウントは、大きな数であり、ロックは、「ホットな」ロック、すなわち重度に競合しているロックとして識別される。モニタが１つのスレッドにより主としてアクセスされている場合、カウントは１であり、ロックは「コールドな」ロックである。
【００１１】
ＪＶＭがどのロックが「ホット」であるかを一旦判定すると、ＪＶＭは、このロックのグループについて使用すべき最も適切な同期技術を選択することができる。ＪＶＭは、競合に関する閾値を設定する。この閾値は、実際のカウント値に対して比較される。カウント値がホットなロックを識別するために割り当てられた閾値を超える場合、ＪＶＭは、これらのホットロックのためにハードウェア・アクセラレート技術を使用する判定を行う。図２は、所与のロックについて軽度の競合がある例での処理を説明している。図２において、ブロック２０では、あるスレッドは、あるモニタを取得する。ブロック２２で、この要求しているスレッドは、そのモニタを前に要求したスレッドと異なるスレッドであるかが判定される。異なるスレッドではない場合、特定のモニタについてのアクセスカウントをインクリメントするための動作は行われず、処理はブロック２０に戻る。前のスレッドとは異なるスレッドがロックについて競合している場合、ブロック２４で、そのモニタについてのアクセスカウントがインクリメントされる。
【００１２】
図３は、ホットロックを示す閾値とそれぞれのアクセスカウント値とを比較する処理を表している。ブロック３０では、モニタカウントは閾値と比較される。ブロック３２で、該カウント値が閾値を超えない場合、特定のロックに関して更なる動作が実行されず、処理はブロック３０に戻る。実際に、ブロック２４で達成されたカウント値が閾値を超えた場合、動作はブロック３４に進み、ここでは、あるロックがホットロックのリストに追加される。図２及び図３の処理は、ＪＶＭ又はハードウェアで実現される。このように、ホットロックの識別が提供される。
【００１３】
先の表１に関する従来技術の処理に戻り、この処理は、重度の競合を本質的に提供することがわかる。競合は、ロックを求める複数のプロセッサの要求を記録することができ、かつ、あるロックの割り当てを調停することができる中央のエンティティがないことが原因である。結果的に、プロセッサは、ロックを得ることを繰り返し試みなければならない。中央のエンティティが存在する場合、これは、余分のステップ及び余分の時間、すなわちオーバヘッドの観点で高価なものである、要求される読出し・修正・書込みのサイクル数を大幅に低減することができる。図４には、中央のエンティティを提供するハードウェアが例示されており、この図は、４つのＣＰＵのバスに基づいた構成からなるブロック図である。４つのＣＰＵの構成に焦点が当てられ、本発明の特定の実施の形態に関する説明が提供される。しかし、他の数のＣＰＵが利用される場合がある。例示される構造は、スケーラブルである。４つのＣＰＵは、フロントサイドバスに配列されて接続されている。他の装置の配列が提供される場合がある。
【００１４】
図４では、言及される４つのＣＰＵは、ＣＰＵ４０，４２，４４及び４６である。これらは、データバス５０とそれぞれ通信し、また、データバス５０は、チップセット５２と通信する。また、チップセット５４は、メモリ５６に接続されるホストメモリコントローラ５４を備えている。４つのロック５８−１〜５８−４は、メモリ５６へのアクセスの制御を示すために例示されている。メモリ５６は、共有のリソースである。
【００１５】
また、チップセット５２には、ロックレジスタ装置６０がある。必ずしも、チップセット５２にロックレジスタ装置６０を設ける必要はないが、ロックレジスタ装置６０を設けることが好ましい。ロックレジスタユニット５８は、本実施の形態では、４つのロックレジスタ６４を含んでいる。４つのロックレジスタ６４は、便宜上例示されている。通常、基準のアプリケーションにおけるロックレジスタの数は、非常に多くなる。しかし、ロックレジスタ６４の数は、説明の容易さのために制限されている。ロックレジスタ６４の数は、プラットフォームに依存する。初期化のとき、ロックレジスタの数は、ＪＶＭに伝達される。ＪＶＭによるハードウェアアクセラレーションの使用は、利用可能なロックレジスタの数に制限される。利用可能なロックレジスタ６４がない場合、ＪＶＭは、ソフトウェアで同期を管理する。
【００１６】
より多くのロックレジスタ６４をハードウェアで実現するか、ソフトウェアで実現するか関する柔軟性を提供することで、設計者には、性能対費用をトレードオフするための機会が与えられる。本実施の形態では、ロックレジスタ６４は、４つのロックのそれぞれについて提供される。これらのロックは、ロック５８−１，５８−２，５８−３及び５８−４として識別される。それぞれのロックレジスタ６４は、それぞれのロック５８について、ＣＰＵのロック要求を記憶するためのカウンタを備えている。ロックレジスタ装置６０は、あるロックへのアクセスが与えられるＣＰＵを選択するアービタ６８をさらに備える。そのロックへのアクセスが与えられた現在のＣＰＵは、「勝者」と呼ばれる。現在の「敗者」のＣＰＵには、スピンして再びアクセスを要求するためのスピンフラグが提供される。勝者のＣＰＵがロックを一旦解除すると、ロックレジスタユニット６０は、アービタ６８を介して、次の勝者を選択し、保留の要求が存在する限り、上述した処理を繰り返す。
【００１７】
ロックレジスタカウンタ６４は、ＣＰＵのロック要求を記録する。オーナシップを示すレジスタ６６は、それぞれのロックレジスタ６４に対応するために含まれており、ロック番号、スレッド番号、ＣＰＵ番号及びスピンフラグにより識別される現在のロックのオーナシップを記録する。ロックレジスタ６６は、あるスレッドのＩＤを記憶する。これは、ハードウェアのロックが一旦割り当てられていると、ＪＶＭは、ロック要求とロック解除の間で異なるＣＰＵにスレッドが移動しないことを保証する必要があるからである。この移動の防止は、スレッドの親和性結合（ａｆｆｉｎｉｔｙ−ｂｉｎｄｉｎｇ）を要求するために、標準的なオペレーティングシステムの呼出しを使用すること通して行われる。
【００１８】
代替的な実現は（理想的ではないが）、かかる親和度を要求しないが、代わりに、あるスレッドがあるＣＰＵから別のＣＰＵに移動する場合、ＣＰＵ番号のフィールドを更新して、個別のスピンフラグを発生する。
【００１９】
ロックレジスタユニット６０は、簡単なラウンドロビン方式の調停を使用して、複数の要求の間で調停することができる。この技術は、優先度に基づく調停のような、他の調停モデルに応用することができる。
【００２０】
スピンフラグの提供は、以下の例により説明されるように非常に望ましい。ＣＰＵ４４がある特定のロック６２を要求したが調停で敗者となり、ＣＰＵ４０がオーナシップを有する場合、従来技術のモデルでは、ＣＰＵ４４は、スピンして（しばらく待って）再び要求する。また、ＣＰＵは、プロセッサと呼ばれる場合がある。再び要求を試みることは、読出し・修正・書込みを発することにより作用される。先に説明したように、これは、バスの競合及び性能の問題につながる処理である。本発明では、ＣＰＵ４４が特定のロック６２にオーナシップを得たことをロックレジスタユニット６０が判定したときに、中央のエンティティとしてのその役割においてロックレジスタ装置６０は、通知をＣＰＵ４４に提供する。
【００２１】
この動作は、以下のように進行する。ＣＰＵ４４が「敗者」となったとき、ＣＰＵ４４は、キャッシュ可能なメモリにおける特定のフラグに関してスピンする。最初のアクセスの後、読出しがＣＰＵ４４のキャッシュからあり、バストラフィックを生じない。ＣＰＵ４４がオーナシップを得たと思われるとき、レジスタユニット６０は、そのメモリにおけるフラグ変数に書込みを行い、プロセッサバス５０にスヌープ・バスサイクル（ｓｎｏｏｐ  ｂｕｓ  ｃｙｃｌｅ）を発する。
【００２２】
スヌープ値は、フラグ値を無効にし、ＣＰＵ４４は、メモリ５６から新たな値を得るために、読出しサイクルを発する。新たな値により、ＣＰＵ４４は、スピンループを始動して、そのクリティカルセクションに入る。スピンフラグのアドレス値は、ＪＶＭにより、又はＪＶＭの代わりにチップセットドライバによりチップセットにプログラムされている。ドライバは、特定のスレッドのスピンフラグに対応する物理アドレスを得るために、仮想アドレスから物理アドレスへのアドレス変換を行うことが必要である。
【００２３】
なお、ロックの競合に関する動的なプロファイリング、及び同期技術を選択及び調整するためのプロファイルデータの使用は、個々の趣旨において使用される。これらは、ハードウェアと同様にソフトウェアでも実現される。
【００２４】
上述した方法は、機械読み取り可能な媒体により実行される場合がある。機械読み取り可能な媒体は、機械（たとえば、コンピュータ）により読取り可能な形式で情報を提供する（すなわち、記憶及び／又は送信）任意のメカニズムを含んでいる。たとえば、機械読み取り可能な媒体は、リードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリ装置、電気的、光学的、音響的又は他の形態の伝播信号（たとえば、搬送波、赤外線信号、デジタル信号又は他の形式の信号）を含んでいる。
【００２５】
提供される技術は、ロックの競合に関する動的なプロファイリングのための方法及び装置であり、使用される同期技術を選択及び調整するためのプロファイルデータを使用するための方法及び装置であり、及び、動的なプロファイリング及び同期技術の選択について対話型であってプラットフォーム依存型の同期アクセラレーションハードウェアである。上述した特定仕様により、当業者であれば、本発明に係る方法及び装置を提供するために、先に説明した特定の例における多くの変更を行うことができるであろう。
【図面の簡単な説明】
【００２６】
【図１】ロックの競合に関する動的なプロファイル情報をモニタするための、本発明で使用されるソフトウェアデータ構造の図である。
【図２】Ｊａｖａ（登録商標）仮想マシンにおけるロックの競合に関する動的なプロファイルを説明するフローチャートである。
【図３】Ｊａｖａ（登録商標）仮想マシンにおけるロックの競合に関する動的なプロファイルを説明するフローチャートである。
【図４】本発明に係る同期アクセラレーションを提供するハードウェアのブロック図である。
【図１】
0004739282.tif 000003
【図２】
0004739282.tif 000004
【図３】
0004739282.tif 000005
【図４】
0004739282.tif 000006