JP2000513851A

JP2000513851A - ガーベッジコレクションページ境界横断ポインタストアをトラップするためのライトバリアシステム及び方法

Info

Publication number: JP2000513851A
Application number: JP10546158A
Authority: JP
Inventors: オコナー、ジェイムズ・マイケル; トレンブレイ、マーク; ビシン、サンジェイ
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1997-04-23
Filing date: 1998-04-21
Publication date: 2000-10-17
Anticipated expiration: 2018-04-21
Also published as: WO1998048352A1; EP0914632B1; WO1998048352A9; US5845298A; JP4104668B2; EP0914632A1; DE69802652D1

Abstract

(57)【要約】ガーベッジコレクションページ境界横断ストアをトラップするためのアーキテクチャ的サポートが提供される。ポインタストアが境界を横断するものであるとの識別は、ガーベッジコレクションページサイズを定義するべくプログラム可能にエンコードされるガーベッジコレクションページマスクに応答するストアバリアによってなされる。ライトバリア及びガーベッジコレクションページマスクによれば、ガーベッジコレクションページマスクの、従ってトラップされるべき境界横断ポインタストアプログラム可能な定義が提供され、さまざまなジェネレーション的ガーベッジコレクション方法のためのサポートを備えたガーベッジコレクタの実施態様が提供される。このような方法には、ジェネレーション的に収集されたメモリスペースの成熟した部分を管理するためのトレーンアルゴリズム式方法が含まれる。ポインタ依存ストア命令置換手段によって、本発明に基づく実施態様において、ポインタストアに対してというだけでなく、プログラム可能に定義されたガーベッジコレクションページ境界を横断するポインタストアに対して、正確なバリアを提供することが可能となる。

Description

【発明の詳細な説明】ガーベッジコレクションページ境界横断ポインタストアをトラップするためのライトバリアシステム及び方法発明の背景発明の技術分野本発明はガーベッジコレクションに関し、特にガーベッジコレクタに於てジェネレーションを分離するためのシステム及び方法に関する。関連技術の説明多くのプログラム言語は、伝統的に、メモリの動的アロケーション（割り当て）及びディアロケーション（割り当て解除）の責任をプログラマの記憶に負わせていた。例えば、Ｃプログラム言語に於ては、mallocプロシージャによってまたはその擬似命令(variant)によってヒープからメモリを割り当てる。ポインタ変数ｐが与えられると、p=malloc(size of(SomeStruct))というステートメントに対応するマシン命令の実行により、SomeStructデータ構造を表すために必要なサイズのメモリオブジェクトのために新たに割り当てられた記憶領域にポインタ変数ｐをポイントさせる。使用後には、ポインタ変数ｐにより識別されるメモリオブジェクトは、free(p)を呼ぶことにより割り当て解除される。Pascal及びＣ++ 言語は、メモリを明示的に割り当て及び割り当て解除するための同様の構造を提供する。残念ながら、動的に割り当てられた記憶領域は、特定の演算過程のためのルート参照位置のセットに、記憶領域に対する参照、即ちポインタが残されていないと到達不能になる。このように到達不能であってしかも解放されていないメモリオブジェクトはガーベッジ(garbage)と呼ばれる。依然として参照されているメモリオブジェクトを割り当て解除することもできる。この場合、ぶら下がり参照（dangling reference）が形成される。一般に、ダイナミックメモリを正しく管理することは困難である。多くのプログラム言語に於て、データ構造を、それを生成したプロシージャの後に渡って残存させるためにはヒープ割り当てが必要となる。これらのデータ構造が更なるプロシージャまたは機能に受け継がれると、プログラマやコンパイラが、それをどの時点で割り当て解除するのが安全であるかを判定することが困難或いは不可能となる。この困難のために、ダイナミックメモリ管理の魅力的な代替モデルとして、ガーベッジコレクション即ちヒープ割り当てされた記憶領域を、プログラムによって最後に使用された後に自動的に再利用可能とするものがある。ガーベッジコレクションは、特にＪＡＶＡ言語、Prolog、Lisp、Smalltalk、Eiffel、Dylan、ML 、Haskel、Miranda、Oberon等のアルゴリズム言語にとって特に魅力的である。これらの言語はデータ共有や、遅延実行などを行い、手続き型言語に比較して、より予測困難な実行順序を伴う。ガーベッジコレクション及びそのための古典的なアルゴリズムについては、Jones & Lins,"Garbage Collection:Algorithms fo r Automatic Dynamic Memory Manegement",pp.1-41 Wiley(1996)を参照されたい。３つの古典的なガーベッジコレクション方法として、参照カウンティング(ref erence counting)、マークスイープ(mark-sweep)、コピストレージ回復(copying storage reclamation)等の方法がある。第１の参照カウンティング法は、アクティブメモリオブジェクト或いはルート参照位置から各メモリオブジェクトへの参照即ちポインタの数のカウントを継続的に維持することに基づく。新たなメモリオブジェクトが割り当てられ、それに対してポインタが割り付けられると、メモリオブジェクトの参照カウントは１にセットされる。その後、このメモリオブジェクトにポインタが参照するようにセットされる度毎に、メモリオブジェクトの参照カウントが１ずつ増大させられる。メモリオブジェクトに対する参照が削除或いは上書きされると、参照カウントが１ずつ減らされる。参照カウントが０であるメモリオブジェクトは到達不能であって、ガーベッジとして収集される。参照カウント式のガーベッジコレクタの実施態様は、通常各メモリオブジェクトに参照カウントと呼ばれる追加のフィールドを有しており、新たなオブジェクト、オブジェクトの削除或いはポインタのアップデートの機能の一部としてのカウンタの増減を行う機能を有する。それに対して、トレーシングコレクタ(tracing collector)法は、生きた即ち参照可能なメモリオブジェクトを特定するために、メモリの参照チェーンを横断することを含む。このようなトレーシングコレクタ法の一つとして、メモリの参照チェーンを横断して生きたメモリオブジェクトを識別しマークするようなマークスイープ法がある。マークされていないメモリはガーベッジであって、回収され、別のスイープフェイズの間にフリープールに戻される。マークスイープガーベッジコレクタ法は通常、各メモリオブジェクトにマークビットと呼ばれる追加のフィールドを有している。マークコンパクトコレクタ(mark-compact collecto r)は、伝統的なマークスイープ法に対して短縮(compaction)の機能を付加する。短縮は、生きたオブジェクトを再配置し、フラグメンテーションを削減する利点がある。参照カウント法も短縮を用いることができる。他のトレーシング方法、即ちコピーコレクションは、メモリまたはその一部を２つの半空間に分割し、一方に現在のデータを記憶し。他方に古いデータを記憶する。コピーガーベッジコレクションは、これらの２つの半空間の役割を逆転することにより開始される。コピーコレクタは次に、古い半空間FromSpace内の生きたオブジェクトを横断して、到達可能なオブジェクトを新たな半空間ToSpaceにコピーする。FromSpace内の全ての生きたオブジェクトを横断して、かつコピーした後、データ構造のレプリカがTo Space内に存在する。要するに、コピーコレクタはガーベッジの中から生きたオブジェクトを探し出すことになる。コピーコレクションの有意義な副次的効果は、生きたオブジェクトがToSpace内に短縮され、フラグメンテーションを減少させることである。ジェネレーション的な方法は次の２つの発見に基づくものである。(１)メモリオブジェクトは通常早死にする。(２)トレーシング方法は比較的長生きのオブジェクトを横断して、コピーし或いは再配置するためにかなりのリソースを消費する。ジェネレーション的なガーベッジコレクション方法は、ヒープを２つまたはそれ以上のジェネレーションに分け、オブジェクトを年齢によって区分し、若いジェネレーションに対して収集の努力を集中し或いは少なくともより熱心に収集する。若いジェネレーションは小さいものであるため、ガーベッジコレクションに関連する中断時間は平均的に短く保たれる。ジェネレーション内のガーベッジコレクションは、コピー、マークスイープ、その他のガーベッジコレクション方法によって行われる。ジェネレーション的なガーベッジコレクションを実施するためには、変異プロセス、ガーベッジコレクタ或いはこれら両者の組み合わせが、ジェネレーション間ポインタを識別し、それらをガーベッジコレクタによってルートセットの一部として取り扱い得るようにすることが重要である。変異とは、コンピュータシステムに於て、ガーベッジコレクションとは別に、有用な仕事を行うプロセスに於てメモリ内の参照チェーンのグラフを変更させるプロセスである。ジェネレーション間ポインタは、通常変異プロセスポインタ記憶装置またはオブジェクトを含むポインタの昇進(promotion)によって引き起こされる。昇進したジェネレーション間ポインタは、昇進に際するコレクタプロセスによって容易に検出できる。しかしながら、古いジェネレーションをスキャンしてポインタを若いジェネレーションに移すような、多大なコストを要するプロセスを行わない限り、ジェネレーション間ポインタストアを検出するために、ポインタストアをトラップし、記録しなければならない。バリアが良く知られており、通常ページングシステムからなるオペレーティングシステムのサポートにより、ハードウェアとして或いはソフトウェアとして実施される。Jone s & Lins,"GarbageCollection:Algorithms for Automatic Dynamic Memory Mane gement",pp.165-74 Wiley(1996)を参照されたい。特に、この文献は、ジェネレーション間ポインタ、ライトバリア、エントリーテーブル、想起されたセツト(r emembered set)、逐次的なストアバッファ、ハードウェアサポートを伴うページマーキング、仮想メモリサポートを伴うページマーキング及びカードマーキングについて議論している。ポインタストアチェッキングのためのインラインコードなどのようなソフトウェア技術が用いられた場合、実行時間及びインラインコードスペースのオーバーヘッドが課題となる。ソフトウェアライトバリアの１つの例がUngar(David M.Un gar,"GenerationScavenging:A Non-distruptive High Performance Storage Rec lamation Algorithm",ACMSIGPLAN Notices,19(5),pp.157-67(1984))により提案されている。このライトバリアは、（１）ポインタがストアされつつあるか否か及び（２）ポインタが若いジェネレーションのオブジェクトに向けられ、古いジェネレーションのオブジェクト内にストアされているか否かをチェックするために、ストアをインターセプトする。そのような場合には、古いジェネレーションのオブジェクトのアドレスが、想起されたセットに加えられる。ソフトウェアバリアは、それらが適用される演算に対して、大きなオーバーヘッドを課す。例えば、インラインコードにより提供されるソフトウェアバリアは、ポインタがストアであるか否か、及びポインタがジェネレーション間であるか否かをチェックするための追加の命令レイテンシーを加え、コードの全量を増大させる。コードの増大はキャッシュの性能を損なう。このようなソフトウェアバリアに代わるものとしては、オペレーティングシステムの仮想メモリページプロテクト機構を用いて、プロテクトされたページのアクセスをトラップしたり、アップデートされたジェネレーション間ポインタフィールドによってオブジェクトを含み得るページのマップとして、ページ変更汚れビット(dirty bits)を用いることがある。このような手法は、通常ポインタストアの識別を延期させ、特にジェネレーション間ポインタストアの識別を遅らせ、コレクションの時まで、全てのストアの中からの特にジェネレーション間ポインタストアの識別を遅れさせる。しかしながら仮想メモリページサイズはガーベッジコレクションサービスにあまり適していないのが一般的である。例えば、ページは、オブジェクトに比較して大きくなりがちであって、仮想メモリ汚れビットは、ポインタストアばかりでなく、関連するページに対するあらゆる変更を記憶する。その結果、ジェネレーション間ポインタを探すためにページをスキャンするためのコストが高くなる。インラインコードソフトウェアライトバリアに代わる更に別の方法としては、ハードウェアバリアサポートがある。多くのライトバリア法は、ポインタ及び非ポインタストアを区別せず、全てのライトを記録し、コレクションの時までジェネレーション間ポインタについてのチェックを延期するにも拘らず、Symbolics 3600に於けるガーベッジコレクションのためのハードウェアサポートの大幅な使用により、ページマーキングスキームを効率的に実施することができた。Symbol ics 3600の３つの特徴がこれを可能にした。第１に、ハードウェアライトバリアはジェネレーション的データに対するポインタでないあらゆるワードを無視した。ジェネレーション的メモリに対する参照をページにストアするときは、ライトバリアハードウェアが、対応するビットをガーベッジコレクションページテーブルに設定する。第２に、タグ付き構造は、オブジェクトの境界を考慮する必要を無くすと同時に、ポインタワードがタグを用いた非ポインタワードから常に区別できることにより、ジェネレーション的ポインタに対するチェックをコレクションの時に行うことができる。Symbolics 3600は２ビットメージャーデータタイプタグ、４ビットマイナータグ及び２８ビットアドレスを、３６ビットワード内に収容する。最後に、ページは２５６ワードであって、一般的な仮想メモリページよりも小さく、そのために、コレクションの時にページを高速でスキャンすることができた。Jones & Lins,"Garbage Collection:Algorithms for Automatic Dynamic Memo ry Manegement",pp．169-70 Wiley(1996)を参照されたい。この文献は、Symboli cs 3600上でのハードウェアサポートを伴うページマーキングについての記載を含む。また、Moon,"Architecture of the Symbolics 3600"，In Proceedings of the 12th Annual International Symposium on Computer Architecture,pp.76- 83(1985)も参照されたい。この文献は、オブジェクトのストアされた表現についての記載を含む。ジェネレーション間ポインタを識別するプロセスは、かなりのコレクション時スキャニングを必要とする。１つの改良方法では、収集されたメモリスペース、即ちヒープを、カードと呼ばれる小さな領域にセグメント化することである。カードマーキングは、カードが適正なサイズであれぱ幾つもの利点をもたらす。これらは仮想メモリページよりも小さいことから、コレクション時スキャニングの量が削減される。その一方、カードテーブルにより占められるスペースの大きさは、ワード毎のマーキング方法のために必要な量よりも小さい。一般に、カード内のワードか変更される度毎に、カードテーブルに１ビットが無条件にセットされる。カードマーキングコレクタは、コレクション時にジェネレーション間ポインタを求めて汚れたカードをスキャンしなければならない。カードをスキャンするためのコストは、実行されたストアの数よりも、むしろマークされたカードの数及びサイズに比例する。なぜなら、繰り返しが発生することがないからである。Wilson and Moher ,"Design of the Opportunistic Garbage Collector",ACM SIGPLAN Notices,24( 10),pp.23-35(1989)を参照されたい。ジェネレーション的な方法は、ガーベッジコレクションに要する時間を効果的に削減することができ、コレクションの多くが仕事即ちジョブの中断を伴わないものであるのに対し、古いジェネレーションのコレクションはジョブを中断させる。ジョブの中断を伴うことなくオブジェクトの古いジェネレーションを収集するために、Hudson及びMossの両氏は、各コレクション時に、成熟したオブジェクトスペースの境界の定められたサイズの領域を処理するアルゴリズムを提案した。アルゴリズムは本質的に歩進的なものであって、最終的には必ず全てのガーベッジを収集する。Hudson及びMossの両氏は、問題の解決方法を記述するために、列車の例えを用いており、客車は境界の定められたサイズの領域を表し、列車は客車を含む連結構造のグループを表す。このシステムは、特定のハードウェア即ち仮想メモリ機構に依存しない点で効率的である。Hudson and Moss，"Incremen tal Collection of Mature Object",Proceedings of International Workshop o n Memory Management,St.Malo,France(16-18 Septemper,1992)を参照されたい。発明の開示本発明は、ガーベッジコレクタの実施を容易に行い得るようにするようなシステム及び方法及び装置並びにそのようなシステム、方法及び装置を具現するようなコンピュータプログラム製品を提供するものである。特に、本発明は、ガーベッジコレクションページ境界横断ポインタストアをトラップするためのアーキテクチャ的サポート（architecturalsupport）を提供する。ポインタストアが境界を横断するものであるとの識別は、ガーベッジコレクションページサイズを定義するべくプログラム可能にエンコードされるガーベッジコレクションページマスクに応答するストアバリアによってなされる。ライトバリア及びガーベッジコレクションページマスクによれば、ガーベッジコレクションページマスクの、従ってトラップされるべき境界横断ポインタストアプログラム可能な定義が提供され、さまざまなジェネレーション的ガーベッジコレクション方法のためのサポートを備えたガーベッジコレクタの実施態様が提供される。このような方法には、ジェネレーション的に収集されたメモリスペースの成熟した部分を管理するためのトレーンアルゴリズム式方法が含まれる。ポインタ依存ストア命令置換手段によって、本発明に基づく実施態様において、ポインタストアに対してというだけでなく、プログラム可能に定義されたガーベッジコレクションページ境界を横断するポインタストアに対して、正確なバリアを提供することが可能となる。ここでいうポインタストアの正確な識別は、収集されたメモリ記憶領域に対してインラインにエンコードされたタグを必要とせず、このようなタグをサポートするための標準的でないワードのサイズを必要としない。本発明は、ガーベッジコレクションページマスクのハードウェアレジスタによる実現及びそのようなハードウェアレジスタの内容に基づくガーベッジコレクショントラップトリガ方程式の論理的な実現に特に影響を受ける。しかしながら、交互のストアまたはガーベッジコレクションページマスクのエンコード及びガーベッジコレクショントラップトリガ方程式のファームウェアまたはマイクロコードによる実現も適している。さらに、汎用または特定用途ソフトウェアによる具現も、特にハードウェアプロセッサ上での実行の代わりとなるソフトウェア仮想マシン命令プロセッサの実装において適している。ポインタ依存命令によるポインタ非依存命令の実行時間置き換え（execut ion time replacement）は、非ポインタストア命令がジェネレーション間ポインタストアトラップチェックをバイパスすることを可能とするが、実施例によってはこの利点が生じないこともあり得る。これらの及び他の変形例は本願の請求の範囲に入るものである。本発明に基づく一実施例による装置は、内部に形成されたオブジェクトにそれへのオブジェクト参照を介してアクセス可能であるような動的割り当てストレージと、プログラム可能に定義されたガーベッジコレクションページマスクと、ガーベッジコレクションページ境界横断ポインタストアに対するライトバリアとを含む。ライトバリアは、それに関連付けられた第１及び第２のポインタのそれぞれの選択された部分が異なる場合、ストア命令をトラップする。前記第１ポインタは前記ストア命令のターゲットオブジェクトを参照し、前記第２ポインタはそこへストアされるオブジェクト参照データである。前記したそれぞれ選択された部分は、前記プログラム可能に定義されたガーベッジコレクションページマスクの内容によって定義される。別の実施例では、プログラム可能に定義されたガーベッジコレクションページマスクはガーベッジコレクションページサイズを定義する。本発明に基づく更に別の実施例によると、前記ライトバリアは、ガーベッジコレクションページレジスタフィールドに応答して前記ガーベッジコレクションページマスクをエンコードするマスク及び比較論理を含む。更に別の実施例では、当該装置は、前記プログラム可能に定義されたガーベッジコレクションページマスクの表現を含む仮想マシン命令プロセッサを含む。前記ライトバリアは、前記仮想マシーン命令プロセッサ上で実行可能なポインタ依存ストア命令コードを含む。ポインタ依存ストア命令コードの実行は、前記ターゲットオブジェクト参照及び前記オブジェクト参照データのそれぞれのマスクされた部分のビット単位の比較に基づいて、前記ポインタ依存ストア命令の１つの特定の実行がガーベッジコレクションページ境界横断ポインタのストアを行うか否かを判定し、もしそうであればガーベジコレクションフォールトハンドラにトラップする。様々な他の実施例において、前記仮想マシーン命令プロセッサはハードウエアプロセッサを含んでおり、仮想マシーン命令の少なくともサブセットがそれによって直接実行可能であるか、あるいは、ハードウエアプロセッサ上で実行可能なそのインタプリタによる実現を（interpreted implementation）含むか、あるいはハードウエアプロセッサ上で実行可能なそのジャストインタイムコンパイラによる実現を含む。インタプリタによる実現及びジャストインインタイムコンパイラによる実現では、ガーベッジコレクションページマスクは前記ハードウエアプロセッサにアクセス可能なストレージ内で表現される。本発明に基づく別の実施例によると、ガーベッジコレクションページ境界横断ポインタストアをトラップするための方法であって、コンピュータで読取り可能なストレージ内にガーベッジコレクションページマスクを形成する過程と、ポインタ依存ストア命令の特定の実行に関連付けられた第１及び第２のポインタをマスキングする過程と、前記第１及び第２ポインタのそれぞれのマスクされていない部分を比較し、前記第１及び第２ポインタが各々同じガーベッジコレクションページ上のそれぞれのストレージを参照しているか否か判定する過程と、前記比較に於ける不一致結果に基づいてトラップハンドラをトリガする過程とを含むことを特徴とする方法が提供される。第１ポインタは前記ポインタ依存ストア命令のターゲットオブジェクト参照であり、前記第２ポインタは前記ポインタ依存ストア命令のオブジェクト参照データである。このマスキングは前記したガーベッジコレクションページマスクの内容に基づいてなされる。更なる実施例では、前記方法は、前記比較に於ける一致結果に基づいてトラップすることなく前記ポインタ依存ストア命令の前記特定の実行を完了する過程を含む。更に別の実施例では、前記トラップハンドラの動作が、前記ポインタ依存ストア命令に対応する想起セットエントリをストアする過程を含む。図面の簡単な説明本発明は、添付の図面を参照することにより、当業者であれば、その様々な目的、特徴及び利点と共に、より良く理解されるであろう。図１は本発明に基づくガーベッジコレクションジェネレーション分離のためのサポートを含む仮想マシンハードウェアプロセッサの実施例を示すブロック図である。図２は、図１のハードウェアプロセッサ及び例として与えられたＪＡＶＡ仮想マシン実施態様のソフトウェア要素を含むＪＡＶＡアプリケーション環境のソフトウェア及びハードウェア要素間の相互的な(buildsupon)関係を示す。図３は、図１のハードウェアプロセッサのいくつかの可能なアドオンを示す。図４は、図１のハードウェアプロセッサ上で実行される変異プロセスによりなされるジェネレーション間及びカード境界横断ポインタストアのトラッピングのための本発明の実施例に基づき提供されるライトバリアの動作を示す。図５は、本発明の実施例に基づくオブジェクト参照(objectref)フォーマットを示す。図６Ａは、本発明の実施例に基づくオブジェクトフォーマットを示す。図６Ｂは、本発明の実施例に基づく別のハンドル付オブジェクトフォーマットを示す。図７は、ジェネレーション及びカード境界横断ポインタストアのトラッピングを容易にするようなポインタ依存バイト構造に、非ポインタ依存バイトコードを動的に置換するために本発明に基づき用いられたバイトコード置換キャッシュの一実施例を示す。図８は、本発明に基づくガーベッジコレクションのための構造的サポートによりサポート可能な、想起されたセットに基づくジェネレーションコレクタ方法を示す。異なる図面に於ける同様の符合は、同様または同一の部分を示す。好適実施例の説明以下に、本発明を実施するための最良の形態と考えられる態様を詳しく説明する。この記載は、あくまでも本発明の例示であって、本発明を範囲を限定するものではないことを了解されたい。ここでガーベッジコレクションジェネレーションの分離のために本明細書に記載されている構造的サポートは、ジェネレーション間ポインタストアトラップマトリックス、オブジェクト参照ジェネレーションタグ付け、ジェネレーション間ポインタストアトラップマトリックス及びオブジェクト参照ジェネレーションタグ付けに応答するライトバリア、ガーベッジコレクショントラップハンドラ、及びライトバリアサポートによ非ポインタ依存命令のるポインタ依存命令への置換のための構造を含む。一般に、本発明に基づく実施例は、ガーベッジコレクションシステムに於けるジェネレーションを分離するための構造的なサポートの様々な分野に用いることができる。このような構造的なサポートはハードウェア、ソフトウェア或いはそれらの組み合わせとして提供されるが、概ねハードウェアとして提供される構造的サポートについての実施例は一般に性能が高く、メモリの必要量が小さいという利点がある。そこで、例として、ハードウェア式の仮想マシン命令プロセッサの実施例を以下に説明する。しかしながら、この記述に基づき、当業者であれば、ソフトウェアに基づくような別の実施例を容易に思いつくことができ、そのようなインタプリタ、ジャストインタイムコンパイラなどのソフトウェアとして実現された仮想マシン命令プロセッサなども、添付の本発明の特許請求の範囲に含まれるものである。ＪＡＶＡ仮想マシン命令プロセッサの実施例図１は、仮想マシン命令プロセッサ１００のハードウェアとして構成された実施例を示すもので、このハードウェア１００は本発明に基づく有界休止時間再配置ガーベッジコレクション(bounded pause time relocating garbage collectio n)のためのサポートを含み、プロセッサ構造に依存しないＪＡＶＡ仮想マシン命令を直接的に実行する。仮想マシン命令を実行する上でのハードウェアプロセッサ１００の性能は、インテルＰＥＮＴＩＵＭマイクロプロセッサやサンマイクロシステムのＵＬＴＲＡＳＰＡＲＣプロセッサ等のハイエンドＣＰＵよりも高い( ＵＬＴＲＡＳＰＡＲＣは、カリフォルニア州Mountain Viewに所在するSun Mircr osystemsの商標であり、ＰＥＮＴＩＵＭは、カリフォルニア州Sunnyvaleに所在するIntel Corpの商標である。)。更に、ハードウェアプロセッサ１００の性能は、ＪＡＶＡジャストインタイム(ＪＩＴ)コンパイラを備えたハイエンドＣＰＵよりも優れている。ハードウェアプロセッサ１００は低コストであって、電力消費が少ない。そのため、ハードウェアプロセッサ１００はポータブルの用途に示している。ハードウェアプロセッサ１００は、概ねハードウェアとしてＪＡＶＡ仮想マシン命令プロセッサを構成するものであって、そうでない場合にはソフトウェアインタプリタによって必要とされるような２５−５０キロバイトの、リードオンリーメモリやランダムアクセスメモリ等のメモリが不要となり、或いは、それを他の用途に転用することができる。ガーベッジコレクションのためのハードウェアサポートは、さらにガーベッジコレクションのためのインラインコード（コンパイラにより提供されるリード及びまたはライトバリアサポート）を低減し、限定されたメモリの利用状況を改善し、ガーベッジコレクションに要するオーバーヘッド或いは休止時間を削減することにより、メモリを比較的必要としないＪＡＶＡ仮想マシン構造のためのさらなる利点を提供するものである。ネットワーク製品のためのインターネットチップや、セルラーフォーンプロセッサ、その他の通信用集積回路或いは他の低電力、低コストの用途例えば埋め込み(embedded)プロセッサや、ポータブル装置など大きなメモリ伴う高コストが受け入れられないような環境に於いてハードウェアプロセッサ１００が有利である。大きなメモリが可能であるような環境に於いても、ガーベッジコレクションのためのハードウェアサポートは、バリアの実施に関連するオーバーヘッドを減少させ、メモリの有効利用を促進し、ガーベージコレクタの再配置のための休止時間を減少させることができる。特に、ハードウェアプロセッサ１００は、ＪＡＶＡ仮想マシン構造の枠組みの中で、ガーベッジコレクション方法のための利点を提供する。しかしながら、本明細書の記載に基づき、当業者であれば、インタープリットされたＪＩＴコンパイラＪＡＶＡ仮想マシン構造やその他の非ＪＡＶＡ仮想マシン構造を含む様々なＪＡＶＡ仮想マシン構造の変形例に思い至るであろう。本明細書に於いて、仮想マシンとは、命令セットを有し様々なメモリ領域を用いる、現実のコンピュータと同様な抽象的なコンピュータを意味する。仮想マシンの使用は、仮想マシン構造によって実行されるプロセッサ構造に依存しない仮想マシン命令のセットを規定する。一般に、仮想マシン構造はハードウェアプロセッサ１００のようなハードウェアによって、インタープリットされたＪＩＴコンパイラ構造の場合のようにソフトウェアとして構成され、或いはハードウェア及びソフトウェアの組み合わせとして構成される。各仮想マシン命令は、実行されるべき特定の演算を規定する。仮想マシンは、仮想マシン命令を生成するために用いられる或いは仮想マシンの実現の基礎となるようなコンピュータ言語を理解する必要がない。仮想マシン命令のための特定のフォーマットを理解するのみでよい。ある実施例に於いては、仮想マシン命令はＪＡＶＡ仮想マシン命令からなる。各ＪＡＶＡ仮想マシン命令は命令特定情報、オペランド、その他必要な情報をエンコードする１つまたは複数のバイトを含む。ある実施例に於いては、図１のハードウェアプロセッサ１００は、バイトコードを含むＪＡＶＡ仮想マシン命令を処理する。ハードウェアプロセッサ１００はバイトコードの多くを直接的に実行する。しかしながら、バイトコードのあるものの実行は、マイクロコードとして実行される。Lindholm & Yellen，"The JAVA^TM Virtual Machine Specificatlon"(Addison-Wesley，1996)，ISBN0-201-63452 -Xは、ＪＡＶＡ仮想マシン命令の例としてのセットを含み、この文献に言及することを以て、その内容の全てを本明細書の一部とするものとする。ハードウェアプロセッサ１００によりサポートされた仮想マシン命令の特定のセットは、本発明の重要な要素ではない。しかしながら、仮想マシン命令に関して、当業者であれば仮想マシン命令の特定のセットを変更したり、ＪＡＶＡ仮想マシン使用を変更することができる。ある実施例に於いては、ハードウェアプロセッサ１００はＩ／Ｏバス及びメモリインターフェイスユニット１１０、命令キャッシュ１２５を含む命令キャッシュユニット１２０、非高速から高速トランスレータキャッシュ１３１を含む命令デコードユニット１３０、一体化された実行ユニット１４０、スタックキャッシュ１５５を含むスタック管理ユニット１５０、データキャッシュ１６５を含むデータキャッシュユニット１６０、及びプログラムカウンタ及びトラップコントロールロジック１７０を含む。本明細書に記載されているガーベッジコレクションのサポートの特徴は、主にプログラムカウンタ及びトラップコントロールロジック１７０に於けるある程度の追加のサポートを備えた実行ユニット１４０の整数ユニット１４２及びレジスタ１４４に見ることができ、ここで追加のサポートとしては、トラッピングストアに続き、プログラムカウンタに次のＪＡＶＡ仮想マシン命令に進ませるためのサポートを含む。ある実施例に於いては、非高速から高速へのトランスレータキャッシュ１３１は、整数ユニット１４２のハードウェアライトバリアロジックのためのポインタ依存性を促進する。これらのユニットのそれぞれについて以下に詳しく説明する。図２は、例えばハードウェアプロセッサ１００上に部分的に規定され、かつ部分的に実行可能とされるようなＪＡＶＡアプリケーション環境のソフトウェア及びハードウェア要素の相互関係を示している。ＪＡＶＡアプリケーション／アプレットソフトウェア２１０は、ＡＷＴクラス２４１、ネット及びＩ／Ｏクラス２４２、ＪＡＶＡＯＳウィンドウズ２４３、ＪＡＶＡＯＳグラフィックス２４８、ＴＣＰ２４４、ＮＦＳ２４５、ＵＤＰ２４６、ＩＰ２４７、イーサーネット２２２、キーボード２４９、及びマウス２２１ソフトウェア要素を含むアプレット／アプリケーションプログラミングインターフェイス２２０を規定するソフトウェア要素を利用するもので、ある実施例に於いてはＪＡＶＡバイトコードを含む。図２に示された実施例に於いては、ＪＡＶＡＯＳグラフィックス２４８及びイーサーネット２２２ソフトウェア要素はまた、ベースラインＪＡＶＡ仮想マシン使用により規定されたものを越えた拡張バイトコードをも含む。埋め込みアプリケーションプログラミングインターフェイス（ＥＡＰＩ）２３０の要素は、ファンデーションクラス(foundation cl ass)２３１、ＪＡＶＡ仮想マシン仕様(JAVA Virtual Machine Specification) に基づくＪＡＶＡ仮想マシン構造２５０のハードウェア及びソフトウェア要素を含む。ＪＡＶＡ仮想マシン構造２５０は、ハードウェアプロセッサ１００と、ＪＡＶＡ仮想マシン命令を評価するために該プロセッサ上にて実行可能なトラップコードとを含む。さらに、ＪＡＶＡ仮想マシン構造２５０は、ガーベッジコレクションについて以下に記載されているようなポインタストアバイトコード及びメモリアクセスバリアを含むような拡張バイトコードのためのハードウェアサポートや、クラスローダ２５２、バイトコードベリファイア２５３、スレッドマネージャ２５４、ガーベッジコレクタ２５１ソフトウェア及びマイクロカーネル２５５を含む。ＪＡＶＡ仮想マシン構造２５０は、ＪＡＶＡ仮想マシン仕様に適合した部分２５０ａ及び構造に依存する部分を含む。ＪＡＶＡ仮想マシン仕様はガーベッジコレクションが提供されることを特定しているが、どのようなガーベッジコレクション方法を使うかはその構造に依存する。ＪＡＶＡ仮想マシン構造２５０の実施例としてのハードウェアプロセッサ１００に関して以下に記載されているガーベッジコレクションの構造的特徴は、特にジェネレーション的ガーベッジコレクション方法に適合している。しかしながら、本明細書の記載に基づき、当業者は、非ジェネレーション的コレクタ構造、インクリメント式マーク短縮コレクタ、コピーコレクタの再配置に対して制限された休止時間サポートの応用が可能であることに容易に思い至り得るものである。図３Ａは、より複雑なシステムを構成するためのハードウェアプロセッサ１００に対するいくつかの可能なアドオンを示している。ＮＴＳＣエンコーダ３０、ＭＰＥＧ３０２、イーサーネットコントローラ３０３、ＶＩＳ３０４、ＩＳＤＮ３０５、Ｉ／Ｏコントローラ３０６、ＡＴＭアセンブリ／リアセンブリ３０７及び無線リンク３０８からなる８つの機能のいずれをサポートする回路も、本発明のハードウェアプロセッサ１００と同一のチップ内に集積化することができる。さらに、当業者であれば容易に理解できるように、上記したアドオン回路のいずれかを備えたハードウェアプロセッサ１００の実施例を含むハードウェアプロセッサ１００が組み込まれた様々なコンピュータシステムに思い至り得ることができよう。例としてのコンピュータシステム１００は、物理的なメモリ（ＲＡＭ及びまたはＲＯＭ）、コンピュータ読み取り可能なメディアのアクセスデバイス（ディスク、ＣＤ−ＲＯＭ、テープ及びまたはメモリ技術に基づくコンピュータ読み取り可能メディアアクセスデバイスなど）、入出力インターフェイス（キーボード及びまたはポインティングデバイス或いはディスプレイデバイスなどのためのインターフェイス）及び通信デバイスまたはインターフェイスを含む。適当な通信デバイス及びまたはインターフェイスとしては、ネットワーク或いはテレフォニーに基づく通信、公共スイッチネットワークの有線または無線のものを含む通信ネットワークとのインターフェイス或いは専用ネットワークへのインターフェイスを含む。本発明のある実施例に於いては、ＪＡＶＡバイトコードを含む命令ストリームが、ハードウェアプロセッサ１００により実行されるべく、このような通信デバイスまたはインターフェイスを介して送信または受信される。ガーベッジコレクションのための構造的サポートハードウェアプロセッサ１００は、ガーベッジコレクションソフトウェアを実行可能なジェネレーション的コレクタ方法を含む様々なガーベッジコレクション方法のための構造的サポートを提供する。特に、ハードウェアプロセッサ１００は、プログラマブルストアフィルタリング、タグ付オブジェクト参照及びオブジェクトヘッダフォーマット及び拡張バイトコードサポートを含む。プログラマブルストアフィルタリング図４は、ストアをヒープへとプログラマブルフィルタリングするためのサポートを行うスーパバイザライタブルレジスタGC CONFIGの一実施例を示す。図１に於いて、レジスタGC CONFIGはレジスタ１４４に含まれ、実行ユニット１４０に対してアクセス可能である。ある実施例に於いては、レジスタGC CONFIGの１２ビットは、ページ間ポインタストアチェックのためのページサイズを選択するために用いられるフィールドGC PAGE MASKを規定する。フィールドGC PAGE MASKの１２ビットは、３２ビットガーベッジコレクションページマスクのビット２３：１２として用いられ、追加のさらに８つの上位ビットは、０ｘ３Ｆとして、さらに下位の１２ビットは０ｘ０００として規定される。結果として得られる３２ビットのガーベッジコレクションページマスクは、プログラマブルガーベッジコレクションページ境界を越えるポインタストアに対するストアバリアを形成するために用いられる。（スタックキャッシュ１５５により表されるオペランドスタックの最上部に位置するvalue及び objectrefに対してオペレートするaputfleld quick命令などの）ポインタストアのストアデータvalue及びobjectrefターゲットは、３２ビットガーベッジコレクションページマスクにより効果的にマスクされ、それ自身objectrefであるvalue が、ターゲットオブジェクトが存在するのとは異なるガーベッジコレクションページに向けられているか否かを決定するために比較される。このようにガーベッジコレクションページのサイズは仮想メモリページサイズに依存しない。さらに、ガーベッジコレクションページは、仮想的なメモリのサポートを伴わないような低コスト、低電力消費ポータブルデバイスの用途やインターネット装置の用途などのようなコンピュータシステムやオペレーティングシステム環境に於いて提供することが可能である。図４の実施例に於いては、レジスタGC CONFIGは、４キロバイトから８メガバイトの範囲のガーベッジコレクションページサイズのプログラマブルな定義を可能にするが、当業者であれば、このような記載に基づき、様々に異なるページサイズのガーベッジコレクションが構成可能であることが容易に理解できよう。レジスタGC CONFIGはまた、ジェネレーション間ポインタストアトラップマトリックスをプログラム可能に規定するためのフィールドＷＢ VECTORを含む。フィールドWB VECTORは、ストアデータvalueに対応するポインタデータジェネレーション及びそのobjectrefターゲットに対応するターゲットオブジェクトジェネレーションを有するポインタストアがトラップするであろうジェネレーションの対をエンコードする。図４の実施例に於いては、フィールドWB VECTORは、ガーベッジコレクショントラップが望まれるようなポインタデータ及びターゲットオブジェクトジェネレーション対の１ビット表示の４×４マトリックスを有効に規定する。他の実施例として、より大きな或いはより小さなマトリックスを規定したり、(no trap，gc notifyl，gc notify2及びgc notify3 等の)他の状態をエンコードすることも可能である。図４の実施例に於いて、ターゲットオブジェクトのobjectrefの２ビットタグは、それにストアされるべきvalueの２タグビットと連結されることによりフィールドWB VECTOR内への４ビットインデックスを形成する。２ビットタグのそれぞれは、以下に説明するようなジェネレーションメンバーシップ情報をエンコードする。フィールドWB VECTORのインデックス付けされたビットは、ライトバリアが対応するポインタストアをトラップすべきか否かをエンコードする。フィールドWB VECTORは、(ポインタデータジェネレーション及びターゲットオブジェクトジェネレーションが等しくないすべてのポインタストアとしての)全てのジェネレーション間ポインタストア、(ジェネレーション間及びジェネレーション内を問わず)あらゆるポインタストア、或い(古いジェネレーションオブジェクトへの若いジェネレーションのポインタのストアとしての)より若いジェネレーションストア等のトラップをエンコードするためにプログラム可能にコンフィギュアすることができる。一般に、任意な度合いを以て複雑化されたジェネレーション対のトラッピングがサポートされる。図４に示された実施例では、４ジェネレーションまでがサポートされているが、当業者であれば、この記載に基づき、より多数のジェネレーションのための必要な変更に思い至ることができよう。ある実施例に於いては、フィールドGC PAGE MASK及びフィールドWB VECTORは、ポインタストアに対するライトバリアの挙動をプログラム可能に規定する。特に、以下に記載されるように、ハードウェアプロセッサ１００により提供される拡張バイト構造サポートは、非ポインタストアの中からポインタライトバリアによってポインタストアを特定させ、フィールドGC PAGE MASK及びWB VECTORはさらに、ハードウェアプロセッサ１００によって、プログラム可能に規定されたポインタストアのセットをトラップするために、ライトバリアをプログラム可能にフィルタリングする。しかしながら、さらに別の実施例では、ハードウェアプロセッサ１００の拡張バイトコードサポートにより提供されるポインタストアの有意義な正確な識別を不要とし、しかも控えめなバリアの構造に於いて、見かけ上のポインタストアのプログラム可能に規定されたセットを利用可能にする。図４は、４ジェネレーションコレクテッドメモリスペース４５０に於けるプログラム可能なストアフィルタリングサポートを示す。ガーベッジコレクタプロセス４２０は、変異プロセス４１０によりなされた若いジェネレーションポインタストアを記憶されたセット４６０が記録するようなジェネレーション的コレクタを実施するための、ハードウェアプロセッサ１００上にて実行可能なバイトコードを含む。フィールドWB VECTORの内容に対応するジェネレーション間ポインタストアトラップマトリックス４７０の構成の内容は、ライトバリアを若いジェネレーションポインタストアにエンコードする。以下に記載するようにエンコードされたタグが、ストアデータポインタvalueに対応するジェネレーション及び変異プロセス４１０の(aputfield quick命令などのような)ポインタストア命令のターゲットobjectrefに対応するジェネレーション間ポインタストアトラップマトリックス４７０に対してインデックス付けを行うために用いられる。このようにインデックス付けされたジェネレーション間ポインタストアトラップマトリックス４７０に基づき、ライトバリア４３０は、若いジェネレーションオブジェクトに対する参照が、古いジェネレーションオブジェクト内にストアされ、ガーベッジコレクショントラップハンドラ（gc notify）４４０の動作を引き起こすような場合には、aputfield quickポインタストアをトラップし、ガーベッジコレクショントラップハンドラ(gc notify)４４０を呼び起こす。当業者であれば、以上の記載から、フィールドWB_VECTOR及びまたはフィールドGC_PAGE_MASKのジェネレーション間ポインタストアトラップマトリックス４７０の内容により提供される特定のプログラム可能に選択されたストアフィルタリングをサポートするガーベッジコレクショントラップハンドラ４４０のための適切な構成の種類を理解することができる。ジェネレーション間ポインタストアトラップマトリックス４７０の例として与えられた内容（図４）に基づく実施例に於いては、ガーベッジコレクショントラップハンドラ４４０は、ハードウエアプロセッサ１００上で実行可能なバイトコードを含み、トラッピングに関する情報を想起セットデータ構造にストアする。この構造は、収集されたメモリスペース４５０のジェネレーション３，２及び１にそれぞれ対応する想起セット４６１，４６２及び４６３を含む。別の実施例に於いては、ジェネレーション間ポインタストアマトリックス４７０の内容が、ジェネレーション間であるか否かを問わず、すべてのポインタストアにトラップするように、プログラム可能に規定される。関連するカードマーキング式の別実施例として与えられたガーベッジコレクショントラップハンドラ４４０は、ハードウエア１００上で実行可能なバイトコードを含み、トラッピングストアに関する情報をカードテーブルデータ構造にストアする。従来のカードマーキング法の構造に比較して、本明細書に記載されたガーベッジコレクションのための構造的サポートによれば、ハードウエアプロセッサ１００は、ポインタストアを一般的なストアから区別し、同じくジェネレーション間ポインタを一般的なポインタストアから区別することができる。このような理由により更に別のカードマーキング式実施例に於いては、ジェネレーション間ポインタストアトラップマトリックス４７０の内容が、ジェネレーション間ポインタストアのみをトラップするようにプログラム可能に規定される。想起セット式実施例及びカードマーキング式実施例のいずれに於いても、拡張バイトコードサポートにより、ハードウエアプロセッサ１００は、以下に詳しく説明するように非ポインタストアからポインタストアを正確に特定することができる。更に、ジェネレーション間ポインタストアトラップマトリックス４７０、即ちフィールドWB_VECT0Rによってヒープに対するストアのプログラム可能なフィルタリングが提供され、ライトバリア４３０によって、ハードウエアプロセッサ１００は、コレクション時ではなく、変異プロセス４１０のストア時に於いて、ジェネレーション間であるようなポインタストアを特定することができる。そのためにカードマーキングなる用語は、コレクション時にコレクタプロセス４２０により用いられるガーベッジコレクショントラップハンドラ４４０の実施例により提供されるカードテーブルなどの記憶領域の種類について記述的である。カードマーキングなる用語の使用は、ポインタまたはリテラルデータがストアされているか否かを問わずすべてのストアがトラップされる必要があることを意味するものではない。図４は、ポインタストアのトラッピングに基づくガーベッジヘコレクションページのためのサポートを示す。フィールドGC_PAGE_MASKは、aputfield_quick等のポインタストア命令のストアデータポインタvalue及びターゲットobjectrefを比較するためのプログラマブルマスクを提供する。ライトバリア４３０は、ガーベッジコレクションページがマッチしない場合には、ポインタストアをトラップする。フィールドGC_PAGE_MASKにより提供される追加のストアフィルタリングは、コレクタプロセス４２０の実施例によって古いジェネレーションの中断を伴わない収集のために用いられるHudsonのトレーンアレゴリズムに於いて、ハードウエア上で実現されるコレクタプロセス４２０のために特に有用である。Hudson and Moss,"Incremental Collection of Mature Objects"，Proc eedings of International Workshop on Memory Management,St．Malo,France（ 16-18 Septemper,1992）を参照されたい。当業者であれば、以上の記載から、フィールドGC_PAGE_MASKにより規定されるガーベッジコレクションページサイズが、Hudsonのトレーンアレゴリズムに於いて、列車の客車を規定するために用いられることが容易に理解できよう。例として、aputfield_quickバイトコードのシンタックス及びそれによるハードウエアプロセッサ１００の作動を以下に説明する。操作内容ガーベッジコレクションチェックについて、オブジェクトのフィールドを設定する。フォーマットスタック _…,objectref,value _… 詳細参照型でなければならないobjectref及び同じく参照型でなければならないvalueがオペランドスタックからポップされる。valueは、ob jectrefにより参照されるクラスインスタンスへの特定のオフセットに書き込まれる。オフセットの値は、(offsetbytel<<8)｜offsetbyte2である。実行時例外 objectrefがnullである場合、aputfield_quickはNullPointerExc eptionをスローする。各objectref及びvalueの最上位２桁は、４ビットインデックスを構成するために連結される。このインデックスは、GC_C ONFIG レジスタの１６ビットWB_VECTORフィールドから１ビットを選択する。選択されたビットがセットであれば、gc_notifyトラップが生成される。 index=((objectref＆0xC0000000)>>28｜（value>>30） if（GC_CONFIG.WB_VECTOR[index]==1） generate_gc_notify 備考この命令のオプコードの元は、putfieldであり、参照型のフィールドに対応するクラスインスタンスデータ内にオフセットを有するものと動的に判定されたフィールドを操作するものである。putfield命令により参照される一定プールエントリーが解決されると、それが参照するフィールドのオフセットが生成され、フィールドのタイプが決定される。１６ビットオフセットは、元のputfield命令の２オペランドバイトを置換する。フィールドのタイプは、putfield_quick、aputfield_quick1 或いはaputfield_quickが元のputfieldバイトコードを置換するか否かを決定する。オブジェクトの参照フィールドではなく、クラスにおける静的参照フィールドを設定するためのaputstatic_quickバイトコードのシンタックス及びそれによるハードウエアプロセッサ１００の作動も同様である。る。高速ガーベッジコレクショントラップハンドラ一実施例では、ガーベッジコレクションの高速取り扱いが、ベクトル指定されたトラップ（vectored trap）、 gc_notify(tt=0x27)、priority=17 によって与えられ、ハードウエアプロセッサ１００によって実行可能なバイトコードを含む関連づけられたガーベッジコレクショントラップハンドラ４４０をトリガーするトラップ制御論理１７０によって実現される。一実施例では、ガーベッジコレクションページ境界横断ポインタストア又はジェネレーション間ポインタストアのどちらに応答して生成されたかによらず、上述したガーベッジコレクショントラップの各々に対して１つのガーベッジコレクショントラップハンドラ４４０が処理を行う。ガーベッジコレクショントラップは、ストアのトラップが完了する前に発生するため、ガーベッジコレクショントラップハンドラ４４０はハードウエアプロセッサ１００が際限なくトラッピングを繰り返すことを防ぐため、想起セット又はカードテーブルの更新のような実行されるガーベッジコレクション機能に加えて、ストアのトラッピングをエミュレートする必要がある。その後、ガーベッジコレクショントラップハンドラ４４０はストアの後に続く命令にＰＣを強制的にセットする。ガーベッジコレクショントラップによって影響されるＪＡＶＡ仮想マシン命令には、aputfield_quick、aputstatic_quick、aastore、anewarray、multianewar ray、newarray、putfield、putstatic，及びnewがある。これらの中で、aputfie ld_quick、aputstatic_quick、及びaastoreのみが上述したWB_VECTOR及び／又は GC_PAGE_MASKの内容に基づいた動的フィルタリングのようなガーベッジコレクションチェックの実行を必要とする。他のものは、例えば適切にジェネレーションメンバーシップタグを初期化するのに使用されるガーベッジコレクションメカニズムを認識していさえすればよい。一実施例では、aastoreバイトコードはエミュレーションルーチンへとトラップし、aastoreトラップハンドラが適切なガーベッジコレクションチェックを実行する。ある直接的なトラップハンドラの実現では、arrayr efはaastoreトラップハンドラ内のオペランドスタックの一番上にストアされ、バイトコードシーケンス：dup、getfield_quick #0、aputfield_quick #0が実行され、適切なチェックがなされ、必要であればトラップがなされる。タグ付けされた参照及びオブジェクトのフォーマット第５図は、ハードウエアプロセッサ１００において表現されているようなオブジェクト参照（objectref）の一実施例を示している。objectrefの３つのビットをガーベッジコレクションの指示のために使用することができる。特に、フィールドGC_TAGは、上述したように、ライトバリア４３０がポインタストアをトラップするかどうかを決定するため、レジスタフィールドGC_CONFIG.WB_VECTORへのインデックスの一部を形成する。第５図の実施例において、フィールドGC_TAGは、上述したように、ライトバリア４３０によって使用されるジェネレーションメンバーシップ情報をエンコードする。別のハンドルビットＨは、オブジェクトが objectrefによって直接参照されているか、又はハンドル（handle）を通して間接的に参照されているかを示す。ハンドルは、別のレベルの間接的手続きが発生するという代償はあるが、メモリオブジェクトのリロケーションをそれらを指定するポインタ（又はobjectrefs）を大量に更新することなく容易に実現する参照メソッド（referencing method）を提供する。これらのフィールドはどちらもハードウエアプロセッサ１００の整数ユニット１４２（第１図）に与えられる前はマスキングされている。ハードウエアプロセッサ１００の一実施例では、オブジェクト６００はヘッダ部６１０及びインスタンス変数ストレージ部６２０を含むメモリにおいて表現される。第６Ａ図は、そのような実施例の１つを示している。ヘッダ部６１０は３２ビットワードを含んでおり、この３２ビットワードそれ自身はオブジェクトのクラスを表すためのメソッドベクタテーブルベース部６１２と、オブジェクトの同期状態及びガーベッジコレクタ用の情報のために確保された追加的なストレージ（storage）６１４の５つのビットを含んでいる。所望に応じて、第２のヘッダワード（例えばモニタポインタ６１６）に、オブジェクトに割り当てられたモニタのアドレスを格納し、それによって第１のヘッダワード内の追加的なストレージ６１４の５つのビット全てをガーベッジコレクション情報に使用可能とすることもできる。第６Ａ図の実施例では、オブジェクト参照（objectref）はメソッドの呼び出しのオーバヘッドを最小化するべく、メソッドベクタテーブルベース部６１２の場所を示している。ヘッダ部６１０の３つのビットは、例えばコレクタプロセス４２０のようなガーベッジコレクタによって使用可能である。ヘッダ部６１０において、３つの下位ビット（header[2:0]）及び２つの上位ビット（header[31:30]）はヘッダがポインタとして処理されるときはマスクされる。これらのビットの内３つ（header [31:30，2]）は、オブジェクト６００に関する情報をストアするべくガーベッジコレクタによって使用可能である。オブジェクトの同期のため、LOCK及びWANTビットを保持するべくビット１及び０を用いることができる。別の方法として、例えばモニタポインタ６１６のような第２のヘッダワードをオブジェクト６００の同期状態を管理するのに用い、５つのビット全てをガーベッジコレクションのサポートのために残すこともできる。ガーベッジコレクションのサポートのためのビットがどのように用いられるかは、コレクタプロセス４２０及びガーベッジコレクショントラップハンドラ４４０によって実現されるガーベッジコレクションメソッドの特定のタイプに依存する。可能な使用方法には、マークビット、あるジェネレーションのオブジェクトの年齢を決定するためのカウンタビット、等として使用することが含まれる。上述したように、所望に応じてなされるヘッダ部６１０の第２のヘッダワードを使用した実施態様では、５つのビットが例えばコレクタプロセス４２０のようなガーベッジコレクタに対して使用可能となる。第６Ａ図の実施例において、インスタンス変数ストレージ部６２０はメソッドベクタテーブルベース部６１２の１ワード後に始まっており、オブジェクト６００のインスタンス変数を格納する。objectrefの最下位ビットによって、参照が取り扱われる（＝＝１）か又は取り扱われない（＝＝０）かが特定される。一方の選択肢である“取り扱われる”場合のオブジェクトフォーマットが第６Ｂ図に示されている。オブジェクト６００ｂが生成されるとき、取り扱われる参照が確立され、その後の全ての参照はオブジェクトにアクセスするべくハンドル、即ちストレージポインタ６５０ｂを通過する。このようなサポートは、下層に位置するオブジェクトストレージ（インスタンス変数に対するものを含む）ではなくハンドルをコピーすることによってオブジェクトのリロケーションに伴う代償を軽減するようなガーベッジコレクタに対して提供される。ポインタ非依存バイトコードの動的置換のための拡張されたバイトコードサポートハードウエアプロセッサ１００は、実行ユニットに供給されたバイトコードを、その高速擬似命令（quick variants）で動的に置き換えることによってＪＡＶＡバイトコードの実行を加速するための特徴を備えている。しかしながら、今から述べるように、高速擬似命令バイトコードによる置換という特徴をハードウエアプロセッサ１００において利用して、ポインタ非依存ストアオペレーションバイトコードをポインタ依存ストアオペレーションバイトコードによって動的に置き換え、ガーベッジコレクションに対するライトバリアの実現をより容易にすることができる。一実施例では、オブジェクト又はクラスにおけるフィールドの設定をするためのputfield及びputstaticバイトコードが、対応する高速擬似命令（例えば、put field_quick、putfield2_quick、又はaputfield_quick、及びputstatic_quick、 putstatic2_quick、又はaputstatic_quick）によって動的に置き換えられる。どのバイトコードで置換するかは、バイトコードがその上で処理されるフィールドのタイプに依存する。例えば、参照型（type reference）のフィールド上で動作するように決められたputfieldバイトコードは、aputfield_quickバイトコードによって動的に置換される。高速擬似命令バイトコードによる置換は、上記で示した引例に述べられているような関連する非高速バイトコードが初めて実行されるときになされるローディング（loading）及びリンキング（linking）を利用するが、ガーベッジコレクションにとってより重要なのは、ポインタ依存高速バイトコードによる動的な置換によって、ハードウエアプロセッサ１００のような仮想マシン命令プロセッサがデータ型に依存しないストアバイトコードのポインタストア型プログラム出現（pointer storing program occurrence）と非ポインタストア型プログラム出現（non-pointer storing program occurrence）とを識別することが可能になるということである。ポインタ依存バイトコードによる置換により、ストアのトラッピングの回数が減少する。これは、ポインタストアバイトコード擬似命令(即ち、aputstatic_quick又はaputfield_quick)のみしかライトバリアの実行に関わる必要がないからである。動的なバイトコードの置換の一実施例について第７図を参照して説明する。第７図は、ハードウエアプロセッサ１００の一部のブロック図である。ハードウエアプロセッサ１００は、一実施例ではスタックキャッシュ１５５（第１図参照）において表現されるオペランドスタック７２３、命令デコーダ１３５、非高速から高速へのトランスレータキャッシュ１３１、トラップ論理回路１７０、ソフトウエアサーチコード３１、３２及び３３、及び実行ユニット１４０を含んでいる。非高速から高速へのトランスレータキャッシュ１３１は、命令及びデータプロセッサ１２と関連メモリ（associative memory）１４とを含んでいる。関連メモリ１４は、命令識別子メモリ部１８、データセットメモリ部２０、入力回路２２及び出力回路２４を含んでいる。命令デコーダ１３５は命令キャッシュユニット１２０から、例えばＪＡＶＡバイトコードのような命令ストリームを受信するように接続されている。本発明をＪＡＶＡバイトコードに関連して説明するが、本明細書の説明から当業者には理解されるように、別の仮想マシーン環境では、別のタイプの命令の動的な置換を行うための変更も可能である。本明細書中で述べるバイトコード置換という特徴は、上記で示した特許出願においてより一般的に述べられているように、命令パラメータの実行時間解決（execution time resolution）に基づいて命令実行の高速化に一般的に適用可能であるが、以下の説明はポインタ非依存非高速バイトコードをそのポインタ依存高速擬似命令で動的に置換することに焦点をあてると共に、そのような動的な置換の実行を容易にし、ライトバリアの実現を容易にするハードウエアプロセッサ１００について特に重点をおいている。第７図を参照されたい。命令デコーダ１３５はデコードされたバイトコードをバス１１上に出力するとともに、デコードされたバイトコードに対応するプログラムカウンタ（ＰＣ）の値をバス１３上に出力する。これらのバイトコード及びＰＣ値は実行ユニット１４０及び命令及びデータプロセッサ１２に渡される。更に、ＰＣ値は関連メモリ１４の入力回路２２にも入力される。一般に、ＰＣ値の各々はバイトコードの対応するプログラム出現を一意に特定する。オペランドスタック７２３のトップエントリは命令及びデータプロセッサ１２に送られる。関連メモリ１４に於いて、命令識別子メモリ部１８は複数（Ｎ個）のエントリを含んでいる。これらのＮ個のエントリの各々は、バイトコード識別子値ＰＣ_0 ,ＰＣ_1,ＰＣ_2,ＰＣ_3,...ＰＣ_Ｎのような対応するバイトコード識別子値をストアすることができる。命令識別子メモリ部１８内にストアされたバイトコード識別子値の各々は異なるＰＣ値に対応する。命令識別子メモリ部１８の幅はプログラムカウンタの幅に対応して選択される。データセットメモリ部２０もＮ個のエントリを含んでおり、命令識別子メモリ部１８内の各々のエントリがデータセット部２０内において関連するエントリを有することができるようになっている。データセットメモリ部２０のＮ個のエントリの各々はＤＡＴＡ_0,ＤＡＴＡ_1,ＤＡＴＡ_2,ＤＡＴＡ_3,...ＤＡＴＡ_Ｎのようなデータセットをストアすることができる。以下により詳細に説明するように、データセットメモリ部２０内に格納されたデータセットの各々はバイトコードの対応するプログラム出現の高速擬似命令の実行用データを含む。一実施例では、データセットメモリ部２０は４つの３２ビットワードの幅を有する。しかしながら、データセットメモリ部２０は別の実施例では別の幅を有してもよい。命令及びデータプロセッサ１２はバス１１上に出力されたバイトコードをモニタし、バス１１上のカレントバイトコードが、対応するデータセットがすぐにアクセス可能であれば高速化された方法で実行可能である非高速バイトコードであるかどうかを判定する。そうである場合、その非高速バイトコードの高速擬似命令が対応するデータセットと共に非高速から高速へのトランスレーターキャッシュ１３１内にキャッシュされる。一般に、非高速バイトコードは０，１，或いはそれ以上の高速擬似命令を有し得る。ＪＡＶＡ仮想マシン仕様は、以下の非高速バイトコードを記述している：anewarray，checkcast，getfield，getstatic，instanceof，invokeinterfa ce，invokespecial，invokestatic，invokevirtual，ldc，ldc_w，ldc2_w，mult ianewarray，new，putfield，及びputstatic。これらのバイトコードは、ハードウェアプロセッサ１００の一実施例では、高速擬似命令を有する。例えばputfie ld,putstatic及びaastoreのような非高速ストア指向バイトコードに対して、ターゲットオブジェクトフィールドに対応するコンスタントプールエントリの解決（resolution）により、その解決によってポインタストアオペレーションが示される場合は、例えばaputfield_quick（ガーベッジコレクションチェックと共にオブジェクト内に参照フィールドをセットする）又はaputstatic_quick（ガーベッジコレクションチェックと共にクラス内に静的な参照フィールドをセットする）による置き換えが可能となる。解決によって参照以外のタイプ（即ち非ポインタタイプ）のターゲットオブジェクトフィールドが示される場合、置換は別の高速擬似命令、例えば、putfield_quick（オブジェクト内にフィールドをセットする）、putfield2_quick（オブジェクト内にロング又はダブルフィールドをセットする）、putstatic_quick（クラス内に静的フィールドをセットする）又はput static2_quick（クラス内にロング又はダブルの静的フィールドをセットする）、によってなされる。一般に、対応するデータセットがすぐにアクセス可能であれば高速化された実行が可能であるような非高速バイトコードを、以後、高速擬似命令を有する非高速バイトコードと呼ぶ。高速擬似命令を有する非高速バイトコードは、命令デコーダ１３５によって提供されるバイトコードのサブセットを形成する。命令及びデータプロセッサ１２は、カレントバイトコードの識別部（又は複数の識別部）をデコードすることによりカレントバイトコードが高速擬似命令を有する非高速バイトコードであるかどうかを判定する。高速擬似命令を有する非高速バイトコードのＮ個までのプログラム出現に対し、命令識別子メモリ及びデータセットメモリ内のエントリによってサポートが与えられる。これらのエントリのいくつかは、対応するプログラム出現がポインタストアへと解決（resolve）される非高速ストア指向（しかしポインタ非依存）バイトコードのポインタ依存高速擬似命令のために使用することができる。トランスレーターキャッシュ１３１は、カレントＰＣ値を有するカレントバイトコードに応答して次のように動作する。命令デコーダ１３５はカレントＰＣ値及びデコードされたカレントバイトコードを実行ユニット１４０及び命令及びデータプロセッサ１２に送る。命令及びデータプロセッサ１２はデコードされたバイトコードが高速擬似命令を有する非高速バイトコード、高速擬似命令ロードバイトコード（quick variant load bytecode）或いはリトライバイトコード（ret ry bytecoe）である場合に作動される。命令デコーダ１３５によってバス１１上に送出されるカレントバイトコードが高速擬似命令を有する非高速バイトコード、高速擬似命令ロードバイトコード又はリトライバイトコードでない場合、命令及びデータプロセッサ１２はそのバイトコードに応答せず、代わりにカレントバイトコード及びカレントＰＣ値は実行ユニット１４０に渡されて実行される。しかしながら、カレントバイトコードが高速擬似命令を有する非高速バイトコードの場合、命令及びデータプロセッサ１２はカレント命令に応答して作動する。一実施例ではバイトコードputfield及びputstaticはデータプロセッサ１２を作動させる。作動すると、命令及びデータプロセッサ１２はライン２１上の信号ＮＯ_ＭＡＴＣＨの状態を判定する。最初、命令識別子メモリ部１８にストアされた命令識別子の値ＰＣ_0,ＰＣ_1,ＰＣ_2, ＰＣ_3,...ＰＣ_Ｎが無効値に設定される。別の方法として、命令識別子値に関連づけられた有効なビットをクリアすることもできる。いずれの場合も、入力回路２２に入力されたカレントＰＣ値は命令識別子メモリ部１８内に格納された命令識別子値のいずれとも一致しない。続いて信号ＮＯ_ＭＡＴＣＨがアサートされる。カレントＰＣ値と命令識別子値ＰＣ_0,ＰＣ_1,ＰＣ_2,ＰＣ_3,...及びＰＣ_Ｎとの間に一致がないことにより、カレントバイトコードを実行するのに必要なデータセットがそのとき関連メモリ１４に格納されていることが示される。そのため、命令及びデータプロセッサ１２は、非高速バイトコードを適切な高速擬似命令によって置換するために、まずこのデータセットの位置を特定し取り出さなければならない。アサートされた信号ＮＯ_ＭＡＴＣＨ及びカレントバイトコードが高速擬似命令を有する非高速バイトコードであるという判定に応答して、命令及びデータプロセッサ１２は制御信号ＴＲＡＰをアサートする。制御信号ＴＲＡＰはトラップ論理１７０に送られる。制御信号ＴＲＡＰに応答して、トラップ論理１７０は実行ユニット１４０の動作を一時的に停止し、対応するソフトウエア部分３１，３２または３３がアクセスされるようにする。アクセスされるソフトウエアコード部分は、制御信号ＴＲＡＰがアサートされるようにした非高速バイトコードに依存する。一実施例では、トラップ論理１７０は制御信号ＴＲＡＰがアサートされるようにしたバイトコードの特定のプログラム出現を確認するためカレントＰＣ値を用いて命令キャッシュユニット１２０にアクセスする。ソフトウエアによって具現されるスイッチステートメントにより、実行が適切なソフトウエアコード部分に移される（識別されたバイトコードに応答してなされる）。別の実施例では、トラップベクタ（trap vector）のような別の方法により実行を適切なソフトウエアコード部分に移すこともできる。このようにして、識別されたバイトコードが最初のバイトコードＩＮＳＴ_０に対応する場合、スイッチステートメントによって対応するソフトウエア部分３１がアクセスされる。同様に、識別されたバイトコードが第２のバイトコードＩＮＳＴ_１に対応する場合、スイッチステートメントによって対応するソフトウエア部分３２がアクセスされるようにされる。例示した実施例では、第１のバイトコードＩＮＳＴ_0はputfieldであり、第２のバイトコードＩＮＳＴ_1はputsta ticである。識別されたバイトコードが他のバイトコード（説明のためＩＮＳＴ_ Ｎとする）に対応する場合、スイッチステートメントは対応するソフトウェアコード部分３３がアクセスされるようにする。ソフトウェアコード部分３１，３２，．．．３３はそれぞれバイトコードＩＮＳＴ_0(例えばputfield)、ＩＮＳＴ_1（例えばputstatic),...ＩＮＳＴ_Ｎを実行するのに必要なデータセットの位置を特定しそれを取り出す働きをする。別の言い方をすると、ソフトウエアコード部分３１，３２，．．．３３はバイトコードＩＮＳＴ_0,ＩＮＳＴ_1，...ＩＮＳＴ_Ｎのそれぞれのプログラム出現に対しコンスタントプールエントリを解決する。いくつかの非高速バイトコード（例えばputfield及びputstatic）は複数の高速擬似命令（例えばputfield_quick,putf ield2_quick，aputfield_quick，putstatic_quick，putstatic2_quick及びaputs tatic_quick）を有するため、対応するソフトウエアコード部分も適切な高速擬似命令を選択する。対応するコンスタントプールエントリの解決によってストア指向のバイトコード（例えばputfield）の特定のプログラム出現がポインタストアであることが示される場合（例えばストアターゲットオブジェックトフィールドが参照型である場合）は、ポインタ依存高速擬似命令（例えばaputfield_quick）による置き換えが適切である。ソフトウェアコード部分３１，３２，．．．３３は更に、取り出したデータセットがオペランドスタック７２３内にロードされるようにする。ソフトウエアコード部分３１，３２，．．．３３は取り出されたデータセットがオペランドスタック７２３内にロードされた後、高速擬似命令ロードバイトコードを命令デコーダ１３５に出力する。命令デコーダ１３５は受け取った高速擬似命令ロードバイトコードをデコードする。デコードされた高速擬似命令ロードバイトコードはバス１１上に於いて命令及びデータプロセッサ１２に送られる。命令及びデータプロセッサ１２はバス１１上に存在する各高速擬似命令ロードバイトコードを識別し、応答として、前にオペランドスタック７２３にロードされた対応するデータセットを取り出す。続いて命令及びデータプロセッサ１２はカレントＰＣ値及び取り出したデータセットを関連メモリ１４にロードする。一例では、カレントＰＣ値は命令識別子メモリ部１８の第１エントリに命令識別子値ＰＣ_0として書き込まれ、対応する取り出されたデータセットはデータセットメモリ部２０の第１エントリにデータセットＤＡＴＡ_0として書き込まれる。カレントＰＣ値は命令及びデータプロセッサ１２からメモリ部１８へとバス１５を介して送られる。データセットは命令及びデータプロセッサ１２からデータセットメモリ部２０へとバス１７を通じて送られる。メモリ１４内の特定のエントリを選択するのに使用されるメソッドは、例えば、ランダム、ＬＲＵ（最も最近使用したもの）アルゴリズム又はファーストイン・ファーストアウト（ＦＩＦＯ）アルゴリズムとすることができる。カレントＰＣ値及び取り出されたデータセットがメモリ１４に書き込まれた後、命令及びデータプロセッサ１２は、ソフトウエアコードが制御信号がアサートされるようにした非高速命令をリトライするようにする。このとき、再度入力回路２２に入力されるカレントＰＣ値は、命令識別子メモリ部１８内に格納された命令識別子値（例えば命令識別子値ＰＣ_0）に一致する。その結果、命令及びデータプロセッサ１２はトラップ論理１７０及び対応するソフトウエアコード部分３１，３２，．．．３３の１つを通じて対応するデータセットの場所を特定してそれを取り出すという試みをしない。カレントＰＣ値が命令識別子値ＰＣ_0と一致しているため、出力部２４は対応するデータセットＤＡＴＡ_0を実行ユニット１４０へと渡す。実行ユニット１４０はカレントＰＣ値及び関連するデータセットＤＡＴＡ_0（高速擬似命令バイトコードを含む）を非高速から高速へのトランスレータキャッシュ１３１から受け取る。それに応じて実行ユニット１４０は高速擬似命令バイトコードを実行する。ＰＣ値及び高速擬似命令を有する非高速バイトコードに関連するデータセットが関連メモリ１４にロードされると、高速擬似命令を有する非高速バイトコードの特定のプログラム出現が、コンスタントプールを解決したり、ソフトウエアコードにアクセスしたりする必要なく実行可能となる。更に、ストア指向バイトコードの特定のプログラム出現に対し、もしその特定のプログラム出現がポインタストアへと解決される場合はポインタ依存高速擬似命令（例えばaputfield_quic k）が続いて実行され、もしその特定のプログラム出現が非ポインタ（又はリテラル値）ストアへと解決される場合は非ポインタ高速擬似命令（例えばputfield _quick又はputfield2_quick）が続いて実行される。更に、非高速バイトコードはプログラムイメージにおいてオーバライトされないため、非高速バイトコードはその元の形態で使用可能であり続ける。更に、非高速バイトコードはオーバライトされないため、それを呼み出し専用メモリに格納するようにすることもできる。以下の例によってハードウエアプロセッサ１００の動作がより明確になるだろう。特に、変異プロセス（mutator process）４１０（第４図）によりポインタストアを選択的にトラップするためのライトバリア４３０のポインタストア依存の実施例を容易にする上での非高速から高速へのトランスレータキャッシュ１３１の働きが明確になるだろう。命令デコーダ１３５は、まず高速擬似命令を有する非高速バイトコード（例えばputstatic）を受け取るが、その非高速バイトコードの特定のプログラム出現は対応するＰＣ値として０ｘ０００１００を有する。バイトコードputstaticの特定のプログラム出現が命令識別子メモリ部１８内に於いて表現されていないとすると、カレントＰＣ値０ｘ０００１００は、入力回路２２によって信号ＮＯ_ＭＡＴＣＨがアサートされるようにする。信号ＮＯ_ ＭＡＴＣＨ及びバイトコードputstaticが高速擬似命令を有する非高速バイトコードであるとの判定に応答して、命令及びデータプロセッサ１２は制御信号ＴＲＡＰをアサートする。トラップ論理１７０はＰＣ値を用いてカレントバイトコードをバイトコードＩＮＳＴ_１（即ち、putstatic）として識別する。カレントバイトコードがバイトコードＩＮＳＴ_１として識別されるのに応答してソフトウエアスイッチステートメントにより、対応するソフトウェアコード部分３２に実行が移される。ソフトウエアコード部分３２は、続いてストアターゲットオブジェクトフィールドに関連づけられたコンスタントプールエントリを解決し、バイトコードＩＮＳＴ_１を実行するのに必要なデータセットを取り出し、このデータセットをオペランドスタック７２３にロードする。ソフトウエアコード部分３２は、高速擬似命令ロードバイトコードを命令デコーダ１３５に送る。それに応答して、命令デコーダ１３５はデコードされた高速擬似命令ロードバイトコードを命令及びデータプロセッサ１２に出力する。命令及びデータプロセッサ１２はオペランドスタック７２３からデータセットを取り出し、このデータセットをデータセットメモリ部２０の第１エントリにデータセットＤＡＴＡ_0としてロードする。ソフトウエアコード部分３２はストアターゲットオブジェクトフィールドが参照型であり（即ち、putstaticの特定のプログラム出現がポインタストアである）、データセットＤＡＴＡ_0と共に適切なポインタに依存する高速擬似命令バイトコードをaputstatic_quick含むことを確定する。命令及びデータプロセッサ１２は更に０ｘ０００１００のカレントＰＣ値を命令識別子メモリ部１８の第１エントリに命令識別子値ＰＣ_0としてロードする。命令及びデータプロセッサ１２は続いて非高速バイトコードＩＮＳＴ_1（即ちpu tstatic）及びカレントＰＣ値０ｘ０００１００がそれぞれバス１１及び１３上で再アサートされるようにする。一実施例では、命令及びデータプロセッサ１２は制御信号ＴＲＡＰがアサートされるようにしたバイトコードに制御を戻すリターンフロムトラップ(ret_from_trap)バイトコードを発行することによってこれを実現する。このとき、入力回路２２はカレントＰＣ値と命令識別子値ＰＣ_0との間に一致を検出する。それに応答して、関連メモリ１４は命令識別子値ＰＣ_0 に関連するデータセット（即ちポインタに依存する高速擬似命令バイトコードap utstatic_quickを含むデータセットＤＡＴＡ_0）を出力回路２４へと供給する。この出力回路２４はこのデータセットＤＡＴＡ_0を実行ユニット１４０に渡し、実行ユニット１４０はポインタ依存高速擬似命令バイトコードaputstatic_quick を実行する。高速擬似命令を有する他の非高速バイトコード及び続いて命令デコーダ１３５に渡される同じ非高速バイトコードの他のプログラムインスタンス（program instance）も、同様に取り扱われる。例えば、関連するＰＣ値０ｘ０００２００を有する非高速バイトコードＩＮＳＴ_1（即ちputstatic）の別のプログラム出現は、０ｘ０００２００のＰＣ値が命令識別子メモリ部１８にメモリ識別値ＰＣ_1として格納され、命令ＩＮＳＴ_1に関連するデータセットがデータセットメモリ部２２データセットＤＡＴＡ_1として格納される結果となる。もしバイトコードputstaticのこの特定のプログラム出現がリテラル値ストアへと解決される場合、命令識別子値ＰＣ_1に関連するデータセット(即ちＤＡＴＡ_ 1)はポインタ依存高速擬似命令ではなく、putstatic2_quickのような高速擬似命令バイトコードＩＮＳＴ_1を含むであろう。非高速バイトコードの最初のプログラム出現に関連づけられるデータセット（例えばデータセットＤＡＴＡ_0）は非高速バイトコードＩＮＳＴ_1の第２のプログラム出現に関連づけられるデータセット（例えばデータセットＤＡＴＡ_1）とは同じでないようにすることができることに注意されたい。バイトコードputstaticの２つのプログラム出現を解決することによって、第１のプログラム出現がポインタに依存するストアバイトコードaputstatic_quick に、第２のプログラム出現が非ポインタストアバイトコードputstatic2_quickへと解決され、それによってハードウエアプロセッサ１００の非高速から高速へのトランスレータキャッシュ１３１はライトバリア４３０をポインタストアに限定する。一実施例では、バイトコードaputstatic_quickは、ガーベッジコレクションチェックと共にターゲットオブジェクト内に参照フィールドを設定する。ハードウエアプロセッサ１００によるバイトコードaputfield_quickの評価に関連して上述したように、ライトバリア４３０（ポインタに依存する高速擬似命令バイトコードによって実現される）はobjectref及びvalueオペランドの各々の最上位の２ビットを繋げることによって４ビットのインデックスを形成する。このインデックスはレジスタGC_CONFIGの１６ビツトのフィールドWB_VECTORからビツトを選択する。選択されたビットがセットされている場合、トラップgc_notifyが生成される。 index=((objectref & 0xC0000000)>>28)｜（value>>30） if(GC_CONFIG.WB_VECTOR[index]==1) generate gc_notify 実行ユニット１４０（第１図）の一実施例では、バイトコードの評価のための論理回路がレジスタGC_CONFIG（第４図）に接続しており、それによって上述した論理表現を実現している。当業者であれば様々な適切な実現方法が理解されるだろう。別の実施例では、ライトバリア４３０（ポインタに依存する高速擬似命令バイトコードによって実現される）はジェネレーション間ストアトラッピングとガーベッジコレクションページ境界横断ポインタストアトラッピングの両方をサポートする。前と同様に、ライトバリア４３０のこの実施例もobjectref及びstor_da taオペランドの各々の上位２ビットを繋げることによって４ビットのインデックスを形成する。このインデックスはレジスタGC_CONFIGの１６ビットフィールドW B_VECTORからビットを選択する。選択されたビットがセットされている場合、トラップgc_notifyが生成される。しかしながら、objectref及びstore_dataオペランドのマスクされた部分の比較によって第２のトリガーも生成される。マスクは、レジスタGC_CONFIGのフィールドGC_PAGE_MASK（即ちビット２７：１６）によってプログラム可能に定義される。この第２のトリガはプロセッサ状態レジスタＰＳＲのガーベッジコレクションページイネーブルビットＧＣＥ（garbagecollection pages en abled bit）によりガードされている。 if｛(GC_CONFIG[(objectref[31:30]##store_data[31:30])]==1) OR（(PSR.GCE==1) AND （(store_data[31:12] & 0x3F##GC_CONFIG[27:16])!= (objectref[31:12] & 0x3F##GC_CONFIG[27:16)）｝ then trap 実行ユニット１４０（第１図）の一実施例では、レジスタGC_CONFIG（第４図）にバイトコードの評価のための論理回路が接続されており、それによって上記した論理表現が実現されている。当業者には様々な適切な実施方法が理解されるだろう。ライトバリア４３０の別の実施例では、ガーベッジコレクションページ境界横断チェックを、集められたメモリスペースの特定の１ジェネレーション又は複数ジェネレーション（典型的には最も古いジェネレーション）に制限するメカニズムが提供される。変形されたページチェックトラッピングの式は、例えば以下の通りである。 if(((PSR.GCE==1)｜｜（(objectref[31:30]==store_data[31:30]）&& (GEN_PAGE_CHECK_ENABLE[objectref[31:30]]==1)))&& ((objectref[31:12] & 0x3F##GC_PAGE_MASK) != (storE_data[31:12] & 0x3F##GC_PAGE_MASK))) then trap このような式は、objectref及びstor_dataオペランドのジェネレーションタグビット（例えばビット３１：３０）が等しいことを要求する。最も古いジェネレーションのエンコーディングに対するフレキシビリティーを実現するため、レジスタＧＣ_ＣＯＮＦＩＧのそのような目的がなければ使用されない４つのビット（例えば３１：２８）を用いて、フィールドGEN_PAGE_CHECK_ENABLEをエンコードすることもできる。このファイルされた４つのビットは、ガーベッジコレクションページ境界横断ストアのトラッピングがどのジェネレーション（１つ又は複数）に制限されるかを示す。当業者であれば理解されるように、様々な適切な実現方法があるが、そのような実現方法には例えばジェネレーションに固有の、ガーベッジコレクションページ境界横断ストアトラッピングをジェネレーション間ポインタストアトラッピングと一体化した実現例が含まれる。上述したように、トランスレータキャッシュ１３１の動作により、参照型のフィールドに対応するクラスインスタンスデータ内へのオフセットを有するフィールド上で動作するように定められた元のバイトコードputfieldを、バイトコード aputfield_quickによって置換した。putfield命令によって参照されるコンスタントプールエントリが解決された場合は、それが参照するフィールドに対するオフセットが生成され、フィールドの型は参照型として決定された。非高速から高速へのトランスレータキャッシュ１３１の対応するデータセットＤＡＴＡ_1内に含まれる１６ビットのオフセットにより、元のputfield命令の２つのオペランドバイトは置換される。フィールドの型により、putfield_quick又はputfield2_qu ickバイトコードではなく、aputfield_quickバイトコードにより元のputfieldバイトコードが置換されることが決定された。レジスタGC_CONFIGのフィールドWB_VECTOR及びGC _PAGE_MASKの内容に依存して、ライトバリア４３０（一実施例では部分的に高速擬似命令バイトコードaputfield_quickによって実現される）は、ポインタストアを上述したようにトラップすることができる。上記の説明では、ハードウエアプロセッサ１００に対する動的なバイトコードの置換の１例を詳細に説明した。動的バイトコード置換の別の実施例は、自己修飾コード（self-modifying code）に基づく。トランスレータキャッシュ１３１の説明から分かるように、自己修飾コードの実施例は、キャッシュの実現が実際的でない場合又は望ましくない場合（例えばコスト的な理由による）に有利である。そのような場合、トランスレータキャッシュ１３１は除去することができる。代わりに、例えばソフトウエアコード部分３１．３２、．．．３３のようなトラップコードは、命令スペースに直接書き込むことによって元の非高速バイトコードを適切な高速擬似命令で置き換え、それによって元の非高速バイトコードの特定のプログラム出現のその後の実行によって高速擬似命令が評価されるようにする。自己修飾コードに基づいた動的バイトコード置換メカニズムの一実施例が、米国特許第５，３６７，６８５号に開示されている。ガーベッジコレクションの例上記した構造的なサポートのガーベッジコレクションに対する使用について、３つのジェネレーション型コレクタアプローチ（即ちＵｎｇａｒの想起セットに基づくジェネレーション型コレクタの実現、Ｗｉｌｓｏｎのカードテーブルに基づくジェネレーション型コレクタの実現、及びＨｕｄｓｏｎのトレーンアルゴリズムに基づくコレクタの実現）について説明する。想起セットに基づくジェネレーション型コレクタ第８図は、Ｕｎｇａｒによる想起セットを用いたジェネレーション型ガーベッジコレクションを示している。このガーベッジコレクションアプローチの実現（例えばライトバリア４３０、コレクタプロセス４２０、及びガーベッジコレクショントラップハンドラ４４０を含む）により、次のようにしてハードウエアプロセッサ１００の特徴を有益に利用することができる。１．全てのストアがトラップを必要とするわけではない。特に、ヒープへのポインタのストアのみしかチェックを必要としない。上述したaputfield_quick及びa putstatic_quickバイトコードを使用することにより、そのようなポインタストアのみのチェックが可能となる。更に、スタックキャッシュ１５５において表現されるオペランドスタック、又はローカル変数エリアへのストアがそのオペランドスタック、ローカル変数及び静的エリアがルートセットの一部であると仮定される場合はトラップの必要がない。スタックキャッシュ１５５のエントリにおいて表現されるオブジェクト参照はポインタとして識別することができる。２．上述したように、若いジェネレーションのオブジェクトのobjectrefが古いジェネレーションオブジェクト内にストアされようとしている場合、ハードウエアプロセッサ１００のライトバリア４３０によるサポートがトラップする。集められたメモリスペース８５０内において２つのジェネレーションしかサポートされていないような実施例においては、レジスタGC_CONFIGのフィールドWB_ VECTORは値0x5050を有する。objectrefのフィールドGC_TAGの１ビットのみ（即ちビット３０）がコードされる。一実施例では、値０はobjectrefを若いジェネレーション８１０内のオブジェクトを示しているものとして識別し、値１はobjectrefが古いジェネレーション８２０のオブジェクトを示しているものとして識別する。この実施例では、ビット３１は効果的に無視され得る。より多くの数のジェネレーションに対する実施例は当業者には明らかであろう。フィールドWB_VECTORの内容に基づき、ライトバリア４３０は古いジェネレーション８２０のオブジェクトから若いジェネレーション８１０のオブジェクトへのポインタがストアされるときは常にガーベッジコレクショントラップハンドラ４４０をトリガする。この実施例では、 PSR.GCEビツトは０にセットされ、フィールドGC_PAGE_MASKの内容に基づくライトバリア４３０の動作をディスエーブルする。４．ストアに対するトラップ条件は、 if｛(GC_CONFIG[(objectref[31:30]##stor_data[31:30])]==1) OR（(PSR.GCE==1) AND ((store_data[31:12] AND 0x3F##GC_CONFIG[27:16])!= (objectref[31:12］AND 0x3F##GC_CONFIG[27:16)）｝ then trap であり、ここでがstore_dataはターゲットオブジェクトにストアされようとしている３２ビットポインタであり、objectrefはストアがなされようとしているオブジェクトに対する３２ビットポインタである。５．ハードウエアプロセッサ１００がトラップする場合（即ち、ライトバリア４３０がガーベッジコレクショントラップハンドラ４４０をトリガする場合）、ハードウエアプロセッサ１００の実行はガーベッジコレクショントラップハンドラ４４０にジャンプする。ある実施例では、ガーベッジコレクショントラップハンドラ４４０が想起セット８３０についての情報をストアし、ポインタストアのトラッピングをエミュレートする。６．ガーベッジコレクションの間、オブジェクトは若いジェネレーション８１０から古いジェネレーション８２０に昇格（promoted）するが、昇格したオブジェクトに対する全ての参照のフィールドGC_TAGが更新され、昇格したオブジェクトがより古いジェネレーションの一部であることが反映される。カードテーブルに基づくジェネレーションコレクタカードに基づくジェネレーションコレクタの実施に対し、レジスタGC_CONFIG のフィールドWB_VECTORは0xFFFFにセットされる。これにより、ライトバリア４３０は全てのポインタストアをヒープへとトラップし、例えばガーベッジコレクショントラップハンドラ４４０のようなトラップハンドラをトリガする。このようなカードに基づくジェネレーション型コレクタの実施例では、ガーベッジコレクショントラップハンドラ４４０はカードテーブルデータ構造に対し追加的なストアを実行し、ストアのトラッピングをエミュレートする。Ｗｉｌｓｏｎによる従来のカードに基づくジェネレーション型コレクタの実施例とは対照的に、ここで述べている実施例ではポインタストアのみがトラップされる。別の実施例では、レジスタGC_CONFIGのフィールドWB_VECTORは、やはりジェネレーション間にまたがるポインタストアのみに対応するライトバリア４３０のトラッピング動作を定義するべく適切な値に設定される。このようにして、コレクションタイムスキャンニングは、ジェネレーション間ポインタストアが発生するようなカードに限定され得る。そのような実施例では、カードテーブルにより上述した想起セットに基づく実施例とは対照的に二重化された除去機能が与えられるという利点がある。トレーンアルゴリズムに基づくコレクタＨｕｄｓｏｎのトレーンアルゴリズムは、ジェネレーション型システムの最も古いジェネレーションをほころびなく（non-disruptive）集めることができるため、よく使用される。このアルゴリズムは、ライトバリアを用いて、最も古いジェネレーション内の異なるメモリ領域（“車両（cars）”）間の参照を追跡することにより作動する。ハードウエアプロセッサ１００による実現においては、これらの“車両”は２の累乗個の境界において整合された固定された２の累乗個の大きさの定められた領域として定義される。フィールドGC_PAGE_MASKはこのクラスのガーベッジコレクションアルゴリズムに対するライトバリア４３０の動作を定義する。プロセッサ状態レジスタビットPSR.GCEが１にセットされている場合、ガーベッジコレクションページ境界（フィールドGC_PAGE_MASKによって定義される）を横切るポインタストアは全て、ライトバリア４３０によるガーベッジコレクショントラップハンドラ４４０のトリガーを引き起こす。そのような実施例では、ガーベッジコレクショントラップハンドラ４４０は管理を行う。ページ（ “車両”）の大きさはレジスタGC_CONFIGのフィールドGC_PAGE_MASKに基づいてプログラム可能に定義される。４Ｋバイト乃至８Ｍバイトのページ範囲が上述した実施例においてサポートされる。他のコレクタライトバリアに依存するいくつかのリアルタイムガーベッジコレクタが開発されている。これらのガーベッジコレクタの実装は、ライトバリア４３０のポインタに依存する特徴を有効に利用することを可能とする。Ｓｔｅｅｌｅによって提案されているようなインクリメント的マスクスイープコレクタも、ライトバリア４３０のポインタ依存特性を有効に利用し得る（Guy L．Steele，Multiprocessi ng Compactifylng Garbge Collection，Communications of the ACM，18(9)(197 5)参照）。本発明を様々な実施例に基づいて説明してきたが、これらの実施例は例示的なものであり、発明の範囲はこれらの実施例に限定されないことが理解されるだろう。第１命令、第２命令、第３命令などのクレームで使用される用語は識別のためのものであって、命令の特定の順番を要求するものと理解されるべきではない。説明した実施例に対し様々な変形、変更、追加及び改良が可能である。例えば、本発明をＪＡＶＡプログラミング言語及びＪＡＶＡ仮想マシンに関連する実施例に基づいて説明してきたが、本発明はそれらに限定されるものではなく、様々なプロセッサ環境に対するシステム、製品、方法、及び装置を包含するものである。更に、いくつかの実施例は、ハードウエアとして説明してきたが、ソフトウエア（例えばインタープリタ、ジャストインタイムコンパイラ（just-in-time com piler）など）による仮想マシーン命令プロセッサの具現が可能であり、そのようなプロセッサは、ジェネレーション間ポインタストアトラップマトリクス、オブジェクト参照ジェネレーションタグ付け、ジェネレーション間ポインタストアトラップマトリクス及びオブジェクト参照ジェネレーションタグ付けに応答するライトバリア、ガーベッジコレクショントラップハンドラ、及び／又はライトバリアによりサポートされたポインタ非依存命令のポインタ依存命令による選択的動的置換のための機能を含むことができる。上述した又は他の変形、変更、追加、及び改良は特許請求の範囲に画定される本発明の範囲に入るものである。

───────────────────────────────────────────────────── フロントページの続き (72)発明者ビシン、サンジェイアメリカ合衆国カリフォルニア州94087・サニーベイル・マネアベニュー 1055・アパートメント＃89 【要約の続き】アを提供することが可能となる。

Claims

【特許請求の範囲】１．内部に形成されたオブジェクトにそれへのオブジェクト参照を介してアクセス可能であるような動的割り当てストレージと、プログラム可能に定義されたガーベッジコレクションページマスクと、ガーベッジコレクションページ境界横断ポインタストアに対するライトバリアとを含み、前記ライトバリアは、それに関連付けられた第１及び第２のポインタのそれぞれの選択された部分が異なる場合、ストア命令をトラップし、前記第１ポインタは前記ストア命令のターゲットオブジェクトを参照し、前記第２ポインタはそこへストアされるオブジェクト参照データであり、前記それぞれ選択された部分は、前記プログラム可能に定義されたガーベッジコレクションページマスクの内容によって定義されることを特徴とする装置。２．前記プログラム可能に定義されたガーベッジコレクションページマスクがガーベッジコレクションページサイズを定義することを特徴とする請求項１に記載の装置。３．前記プログラム可能に定義されたガーベッジコレクションページマスクが前記ターゲットオブジェクト参照及び前記オブジェクト参照データの前記それぞれの選択された部分の比較のためのビット状の比較窓を定義することを特徴とする請求項１に記載の装置。４．前記第１及び第２のポインタが各々最上位部、最下位部、及びそれらの間の中間部を含み、前記プログラム可能に定義されたガーベッジコレクションページマスクが、前記第１及び第２ポインタの前記最上位部を通過させるように定義された最上位部を有する複合マスクのプログラム可能に定義可能な中間部分を定義し、それによって前記上部及び前記中間部のマスクされていない部分が前記ストアオペレーションのトラップのために比較されることを特徴とする請求項１に記載の装置。５．前記ライトバリアが、ガーベッジコレクションページレジスタフィールドに応答して前記ガーベッジコレクションページマスクをエンコードするマスク及び比較論理を含んでいることを特徴とする請求項１に記載の装置。６．前記ライトバリアがポインタストア依存ハードウエアライトバリアを含み、そのポインタストア依存性が、ポインタ非依存ストア命令のストアターゲットフィールドタイプの実行時間解決に基づいて、前記ポインタ非依存ストア命令をポインタ依存ストア命令によって置き換えることによって与えられることを特徴とする請求項１に記載の装置。７．更に、前記プログラム可能に定義されたガーベッジコレクションページマスクの表現を含む仮想マシン命令プロセッサを含み、前記ライトバリアが前記仮想マシーン命令プロセッサ上で実行可能なポインタ依存ストア命令コードを含み、前記ポインタ依存ストア命令コードの実行が、前記ターゲットオブジェクト参照及び前記オブジェクト参照データのそれぞれのマスクされた部分のビット状比較に基づいて、前記ポインタ依存ストア命令の１つの特定の実行がガーベッジコレクションページ境界横断ポインタのストアを行うか否かを判定し、もしそうであればガーベジコレクションフォールトハンドラにトラップすることを特徴とする請求項１に記載の装置。８．前記仮想マシーン命令プロセッサがハードウエアプロセッサを含んでおり、仮想マシーン命令の少なくともサブセットがそれによって直接実行可能であることを特徴とする請求項７に記載の装置。９．前記仮想マシーン命令プロセッサがハードウエアプロセッサ上で実行可能なそのインタプリタによる実現を（interpreted implementation）含み、前記ガーベッジコレクションページマスクが前記ハードウエアプロセッサにアクセス可能なストレージ内で表現されていることを特徴とする請求項７に記載の装置。１０．前記仮想マシーン命令プロセッサがハードウエアプロセッサ上で実行可能なそのジャストインタイムコンパイラによる実現を含み、前記ガーベッジコレクションページマスクが前記ハードウエアプロセッサにアクセス可能なストレージ内で表現されていることを特徴とする請求項１２に記載の装置。１１．前記仮想マシーン命令プロセッサが、データタイプの実行時間解決に基づいて、ポインタ非依存ストア命令コードを前記ポインタ依存ストア命令コードに動的に置き換えることをもって、前記ライトバリアをポインタストアに制限し、前記プログラム可能に定義されたガーベッジコレクションページマスクは、前記ライトバリアによるトラップを、更にガーベッジコレクションページ境界横断ポインタストアに制限することを特徴とする請求項７に記載の装置。１２．前記ライトバリアの実装と、前記プログラム可能に定義されたガーベッジコレクションページマスクの表現とを含む仮想マシーン命令プロセッサと、前記仮想マシーン命令プロセッサによって実行可能な命令を含むフォールトハンドラとを含み、前記ライトバリアは、実行することによってガーベッジコレクションページ境界横断ポインタをストアするようなターゲットオブジェクト及びストアデータを有するようなストア命令の実行時に前記フォールトハンドラをトリガすることを特徴とする請求項１に記載の装置。１３．前記フォールトハンドラの前記命令が想起セットへのストアのための命令を含むことを特徴とする請求項１２に記載の装置。１４．前記仮想マシーン命令プロセッサによって実行可能な命令のジェネレーション的コレクタプロセスを更に含み、前記フォールトハンドラが、前記ジェネレーション的コレクタプロセスによって使用されるように、想起セットの表現にトラップされたストアデータを識別するための情報をストアするべく、前記仮想マシーン命令プロセッサによって実行可能な命令を含んでいることを特徴とする請求項１２に記載の装置。１５．前記ターゲットオブジェクト参照及び前記オブジェクト参照データの前記それぞれ選択された部分のマスキング及び比較のための論理回路を有する実行ユニット及び前記プログラム可能に定義されたガーベッジコレクションページマスクのレジスタによる表現を含むハードウエアプロセッサを更に有することを特徴とする請求項１に記載の装置。１６．ハードウエアプロセッサ上で実行可能なソフトウエア仮想マシーン命令プロセッサプログラムを更に含み、前記ソフトウエア仮想マシーン命令プロセッサプログラムは前記プログラム可能に定義されたガーベッジコレクションページマスクを表現するためのコンピュータによって読み取り可能なストレージを定義すると共に、前記ターゲットオブジェクト参照及び前記オブジェクト参照データの前記それぞれ選択された部分のマスキング及び比較のためのプログラム命令を含んでいることを特徴とする請求項１に記載の装置。１７．ガーベッジコレクションページ境界横断ポインタストアをトラップするための方法であって、コンピュータで読取り可能なストレージ内にガーベッジコレクションページマスクを形成する過程と、ポインタ依存ストア命令の特定の実行に関連付けられた第１及び第２のポインタをマスキングする過程であって、前記第１ポインタは前記ポインタ依存ストア命令のターゲットオブジェクト参照であり、前記第２ポインタは前記ポインタ依存ストア命令のオブジェクト参照データであり、該マスキングは前記したガーベッジコレクションページマスクの内容に基づいてなされる該マスキング過程と、前記第１及び第２ポインタのそれぞれのマスクされていない部分を比較し、前記第１及び第２ポインタが各々同じガーベッジコレクションページ上のそれぞれのストレージを参照しているか否か判定する過程と、前記比較に於ける不一致結果に基づいてトラップハンドラをトリガする過程とを含むことを特徴とする方法。１８．前記比較に於ける一致結果に基づいてトラップすることなく前記ポインタ依存ストア命令の前記特定の実行を完了することを特徴とする請求項１７に記載の方法。１９．前記トラップハンドラの動作が、前記ポインタ依存ストア命令に対応する想起セットエントリをストアする過程を含むことを特徴とする請求項１７に記載の方法。２０．前記トラップハンドラの動作が、前記ポインタ依存ストア命令をエミュレートする過程を含むことを特徴とする請求項１７に記載の方法。２１．ストアターゲットフィールドタイプの実行時間決定に基づいてポインタ非依存命令のプログラム出現をポインタ依存命令に選択的に変換する過程と、前記マスキング及び前記比較を概ね前記ポインタ依存命令に対してのみ行う過程とを含むことを特徴とする請求項１７に記載の方法。２２．その上で実行可能な変異及びガーベッジコレクタプロセスを有する仮想マシン命令プロセッサに於いてガーベッジコレクションページ境界横断ポインタストアをトラップするためのアーキテクチャ的サポートであって、プログラム可能に定義されたガーベッジコレクションページマスクと、前記プログラム可能に定義されたガーベッジコレクションページマスクに応答するライトバリア手段とを含み、前記変異プロセスのストア命令の評価によって（１）前記ストア命令がポインタストアへと解決され、且つ（２）前記ストア命令のターゲットメモリオブジェクトと前記ストアのオブジェクト参照データによって識別されるメモリオブジェクトのいづれもが同じガーベッジコレクションページ内にある場合、ガーベッジコレクションフォールトハンドラーがトリガされ、ガーベッジコレクションページ境界は前記プログラム可能に定義されたガーベッジコレクションページマスクによって定義されることを特徴とするアーキテクチャ的サポート。２３．前記ライトバリア手段が仮想マシーン命令プロセッサによって実行可能なポインタ依存ストア命令を含んでおり、前記ポインタ依存ストア命令は前記ライトバリアをポインタストアに限定することを特徴とする請求項２２に記載のアーキテクチャ的サポート。２４．前記ポインタ依存ストア命令が非高速バイトコードの高速擬似命令を含んでいることを特徴とする請求項２３に記載のアーキテクチャ的サポート。２５．前記ライトバリア手段が論理回路を含み、前記論理回路は前記ストア命令の特定の実行に関連付けられた第１及び第２ポインタの部分を効果的にマスキングすると共に、前記第１及び第２ポインタのマスキングされていない部分をビット単位で比較し、前記第１ポインタは前記ストア命令の前記ターゲットメモリオブジェクトを識別し、前記第２ポインタは前記ストア命令の前記データであり、前記論理回路は前記比較の相違結果に基づいてトラップハンドラをトリガすることを特徴とする請求項２２に記載のアーキテクチャ的サポート。２６．前記ライトバリア手段がポインタストア依存ハードウエアライトバリアを含んでおり、そのポインタストア依存性はポインタ非依存ストア命令を、該ポインタ非依存ストア命令のストアターゲットフィールドタイプの実行時間解決に基づいてポインタ依存ストア命令で置き換えることによって与えられることを特徴とする請求項２２に記載のアーキテクチャ的サポート。