JP5868429B2 - 領域に基づくガベージ・コレクタを用いてクラスを漸進的にアンロードするための方法、コンピュータ・プログラム製品、および装置 - Google Patents

Description

本発明は、メモリ管理に関し、より詳細には、領域に基づくガベージ・コレクタを用いてクラスを漸進的にアンロードするための装置および方法に関する。

Ｊａｖａ（Ｒ）仮想マシン（ＪＶＭ）、マイクロソフト共通言語ランタイム（ＣＬＲ）、またはＳｍａｌｌｔａｌｋランタイムなどのオブジェクト指向のマネージド・ランタイムにおいて、主なメモリ・リソースは、ガベージ・コレクションされるオブジェクトのヒープである。オブジェクトのヒープはオブジェクトのためのメモリを提供し、オブジェクトのそれぞれはクラスのインスタンスである。すべてのマネージド・ランタイムは、オブジェクトのガベージ・コレクションをサポートする。Ｊａｖａ（Ｒ）仮想マシンなどの一部のマネージド・ランタイムは、クラスのガベージ・コレクションも提供する。

Ｊａｖａ（Ｒ）においては、クラスは、Ｊａｖａ（Ｒ） ＣｌａｓｓＬｏａｄｅｒ、プログラマによって指定された関連するクラスの基本的に任意のグループの粒度（granularity）で収集される。クラス・ローダは、（ａ）そのクラス・ローダに対する参照がなく、（ｂ）そのクラス・ローダの定義されたクラスのいずれに対する参照もなく、（ｃ）いずれのスタックにもいかなる定義されたクラスからの実行中のメソッドもなく、（ｄ）そのクラス・ローダの定義されたクラスのいずれのインスタンスもないと、ガベージ・コレクションされ得る。（ａ）および（ｂ）の場合は、クラス・ローダとクラスの両方がそれらを表すプロキシ・オブジェクト（proxy object）を有するので、判定するのが比較的簡単である。通常のガベージ・コレクタのアルゴリズムは、これらに対する参照を「コストなしで（for free）」見つける。（ｃ）の場合も、各ガベージ・コレクション・サイクルの初めにスタックがクローリングされなければならないので判定が容易である。しかし、（ｄ）の場合は、判定がより困難である。

単純な実装では、ガベージ・コレクタは、どのクラスが生きているインスタンスを有するのかを判定するためにすべての生きているオブジェクトを調べなければならない。これは、コレクタがグローバルな収集を実行しているときに行うのは、十分に簡単である。しかし、最近のガベージ・コレクタは、より良い停止時間をもたらすために漸進的である傾向がある。そのようなコレクタは、ヒープの一部しか調べない。通常、これらのコレクタは、「記憶集合（remembered set）」を用いて、コレクション集合（collection set）外のオブジェクトからコレクション集合内のオブジェクトへの参照を追跡する。単純なクラスをアンロードするガベージ・コレクタは、同じ解決策を用いる可能性がある。しかし、これは明らかに実用的でない。記憶集合は、ほとんどのオブジェクトがごくわずかしか参照を持たない傾向があるので成功する。しかし、あらゆるオブジェクトはクラス・ポインタを有するので、これらのそれぞれを記憶することは実用的でない。

別の単純な解決策は、「参照カウント」を使用することである。この解決策は、いくつかのはっきりした欠点を有する。この解決策は、割り当てのたびにクラス内のカウンタをインクリメントし、オブジェクトが回収されるたびにそのカウンタをデクリメントすることをともなう。この解決策は、典型的な循環参照の参照カウントの問題には陥りにくいが、２つの重大な問題を確かに抱えている。第１に、この解決策は、すべての割り当てスレッド（allocating thread）が共有されたカウンタを更新することを必要とするのでうまく並列化しない。第２に、この解決策は、すべての回収されたオブジェクトが調べられることを必要とし、それは、最近のガベージ・コレクタが避けようと懸命に努力することである。

この問題に対する別の解決策は、トレイン・アルゴリズム（train algorithm）に基づくコレクタを使用することである。そのようなコレクタは、領域に基づくコレクタである。しかし、一般的な領域に基づくコレクタとは異なり、そのようなコレクタは、ラウンドロビンの順序で領域を収集しなければならないという点で制限されている。この制限のために、トレイン・アルゴリズムは、より大きな数を割り振られた領域からより小さな数を割り振られた領域への参照のみを記憶する必要がある。漸進的なクラスのアンロードを可能にするために、この解決策は、「最も若い列車（youngest train）」の識別子を各クラスに追加し、各クラスは、クラスのインスタンスを有する最も小さな数を割り振られた領域を記録する。この単純な解決策は、トレイン・アルゴリズムに適しているが、一般的な領域に基づくガベージ・コレクタには適用することも容易に適用範囲を広げることもできない。

以上のことから、必要とされているのは、ガベージ・コレクションされるオブジェクトのヒープ内の領域の任意のサブセットからクラスを効率的にアンロードするための装置および方法である。そのような装置および方法は、領域がいかなる特定の順序でガベージ・コレクションされることも必要としないことが理想的である。

本発明は、当技術分野の現状に対応して、より具体的には、現在利用可能な装置および方法によってまだ完全に解決されていない当技術分野の問題およびニーズに対応してなされた。したがって、本発明は、領域に基づくガベージ・コレクタを用いてクラスを漸進的にアンロードするための装置および方法を提供するためになされた。本発明の特徴および利点は、以下の説明および添付の特許請求の範囲からより完全に明らかになり、または以降で説明されるように本発明を実施することによって知ることができる。

以上のことを踏まえて、領域に基づくガベージ・コレクタを用いてクラスを漸進的にアンロードするための方法が、本明細書において開示される。一実施形態において、そのような方法は、クラス集合（class set）に関する記憶集合を保守するステップを含み、クラス集合は、クラス・ローダに関連するクラスの集合、クラスのグループ、および単一のクラスのうちの１つを含む。記憶集合は、クラス集合のインスタンスがメモリ内の１つまたは複数の領域に含まれるかどうか、およびどの領域にインスタンスが含まれるかを示す。メモリ内の領域のサブセットに対してインクリメンタル・ガベージ・コレクション・プロセスを実行するときに、方法は、記憶集合を調べて、クラス集合がサブセットの外の領域にインスタンスを含むかどうかを判定する。記憶集合が、クラス集合が領域のサブセットの外にインスタンスを含むことを示す場合、方法は、クラス集合が「生きている」と判定する。これは、領域のサブセットからそのクラス集合をアンロードできなくする。

対応するコンピュータ・プログラム製品および装置も、本明細書において開示され、特許請求される。

本発明の利点が容易に理解されるために、上で簡潔に説明された本発明のより具体的な説明が、添付の図面において図示される特定の実施形態を参照することによってなされる。これらの図面が本発明の典型的な実施形態を示すに過ぎず、したがって、本発明の範囲を限定すると見なされるべきでないことを理解した上で、本発明が、以下に添付の図面を用いてさらに具体的かつ詳細に示され、説明される。

本発明のさまざまな実施形態で使用するのに好適なコンピュータ・システムの一例を示す高レベルの構成図である。 オブジェクト指向のマネージド・ランタイムの一例、この例においてはＪａｖａ（Ｒ）仮想マシンを示す高レベルの構成図である。 記憶集合、この例においては記憶集合フィールドおよび任意的なビット・ベクトルが、ランタイム環境内の各クラス・ローダに対して保有される本発明の一実施形態を示す図である。 記憶集合フィールドの表現の間の遷移の例を示す流れ図である。 オブジェクトのヒープからクラス・ローダをアンロードするための方法の一実施形態を示す流れ図である。 ビット・ベクトルが各クラス・ローダに対して保有される本発明の代替的な実施形態を示す図である。 ビット・ベクトルが各クラスに対して保有される本発明の代替的な実施形態を示す図である。 ビット・ベクトルを使用せず、記憶集合フィールドが各クラス・ローダに対して保有される本発明の代替的な実施形態を示す図である。

本明細書において全体的に説明され、図面に示される本発明のコンポーネントは、多種多様な異なる構成で配置され、設計され得ることが容易に理解されるであろう。したがって、図に示される本発明の実施形態の以下のより詳細な説明は、特許請求される本発明の範囲を限定するように意図されておらず、むしろ、本発明による現在考えられる実施形態の特定の例を表すに過ぎない。本明細書に記載の実施形態は、同様の部分が全体を通して同様の参照番号によって示される図面を参照することによって最も深く理解されるであろう。

当業者に理解されるであろうように、本発明は、装置、システム、方法、またはコンピュータ・プログラム製品として具現化され得る。さらに、本発明は、ハードウェアの実施形態、ハードウェアを動作させるように構成された（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）ソフトウェアの実施形態、または本明細書においてはすべてが全体的に「モジュール」もしくは「システム」と呼ばれる可能性があるソフトウェアの態様とハードウェアの態様とを組み合わせる実施形態の形態をとる可能性がある。さらに、本発明は、コンピュータが使用可能なプログラム・コードを記憶する任意の有形の表現媒体で具現化されたコンピュータが使用可能なストレージ媒体の形態をとる可能性がある。

１つまたは複数のコンピュータが使用可能なまたはコンピュータが読み取り可能なストレージ媒体の任意の組み合わせが、コンピュータ・プログラム製品を記憶するために利用され得る。コンピュータが使用可能なまたはコンピュータが読み取り可能なストレージ媒体は、例えば、電子、磁気、光、電磁気、赤外線、または半導体システム、装置、またはデバイスである可能性があるがそれらに限定されない。コンピュータが読み取り可能なストレージ媒体のより具体的な例（非網羅的なリスト）には、以下、すなわち、１つもしくは複数の配線を有する電気的な接続、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、消去可能プログラマブル読み出し専用メモリ（ＥＰＲＯＭもしくはフラッシュ・メモリ）、光ファイバ、ポータブル・コンパクト・ディスク読み出し専用メモリ（ＣＤＲＯＭ）、光ストレージ・デバイス、または磁気ストレージ・デバイスが含まれる可能性がある。本明細書の文脈においては、コンピュータが使用可能なまたはコンピュータが読み取り可能なストレージ媒体は、命令実行システム、装置、またはデバイスによって、またはそれらに関連して使用するためのプログラムを収容、記憶、または伝送することができる任意の媒体である可能性がある。

本発明の動作を実行するためのコンピュータ・プログラム・コードは、Ｊａｖａ（Ｒ）、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋などのオブジェクト指向プログラミング言語と、「Ｃ」プログラミング言語または同様のプログラミング言語などの通常の手続き型プログラミング言語とを含む１つまたは複数のプログラミング言語の任意の組み合わせで記述され得る。本発明を実装するためのコンピュータ・プログラム・コードは、アセンブリ言語などの低級プログラミング言語で記述される可能性もある。

本発明が、本発明のさまざまな実施形態による方法、装置、システム、およびコンピュータ・プログラム製品の流れ図または構成図あるいはその両方を参照して以下で説明される可能性がある。流れ図または構成図あるいはその両方の各ブロック、および流れ図または構成図あるいはその両方のブロックの組み合わせは、コンピュータ・プログラム命令またはコードによって実装され得ることが理解されるであろう。コンピュータ・プログラム命令は、コンピュータまたはその他のプログラム可能なデータ処理装置のプロセッサによって実行される命令が、流れ図または構成図あるいはその両方の１つのブロックまたは複数のブロックで規定された機能／動作を実施するための手段をもたらすように、汎用コンピュータ、専用コンピュータ、または機械を製造するためのその他のプログラム可能なデータ処理装置のプロセッサに与えられる可能性がある。

コンピュータ・プログラム命令は、コンピュータが読み取り可能なストレージ媒体に記憶された命令が、流れ図または構成図あるいはその両方の１つのブロックまたは複数のブロックで規定された機能／動作を実施する命令手段を含む製品をもたらすように、コンピュータまたはその他のプログラム可能なデータ処理装置を特定の方法で機能させることができるコンピュータが読み取り可能なストレージ媒体に記憶される可能性もある。コンピュータ・プログラム命令は、コンピュータまたはその他のプログラム可能な装置で実行される命令が、流れ図または構成図あるいはその両方の１つのブロックまたは複数のブロックで規定された機能／動作を実施するためのプロセスを提供するように、コンピュータで実施されるプロセスを生成するために一連の動作のステップがコンピュータまたはその他のプログラム可能な装置で実行されるようにするために、コンピュータまたはその他のプログラム可能なデータ処理装置にロードされる可能性もある。

図１を参照すると、コンピュータ・システム１００の一例が示されている。コンピュータ・システム１００は、本発明による装置および方法が実装され得る環境の一例を示すために示される。コンピュータ・システム１００は、例として示されるに過ぎず、限定するように意図されていない。実際、本明細書において開示される装置および方法は、示されたコンピュータ・システム１００だけでなく多種多様な異なるコンピュータ・システムに適用できる可能性がある。本明細書において開示される装置および方法は、潜在的に、複数のコンピュータ・システム１００に分散される可能性もある。

コンピュータ・システム１００は、少なくとも１つのプロセッサ１０２を含み、２つ以上のプロセッサを含む可能性がある。プロセッサ１０２は、プロセッサ１０２の状態を示すデータを記憶し、ソフトウェア・システムの実行を容易にする１つまたは複数のレジスタ１０４を含む。レジスタ１０４は、プロセッサ１０２の内部にある可能性があり、またはメモリ１０６に記憶される可能性がある。メモリ１０６は、動作データおよび実行可能なデータを記憶し、プロセッサ１０２は、それらのデータに基づいて動作する。メモリ１０６は、メモリ・コントローラ１０８を用いてプロセッサ１０２によってアクセスされ得る。メモリ１０６は、揮発性メモリ（例えば、ＲＡＭ）および不揮発性メモリ（例えば、ＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ハード・ディスク、フラッシュ・メモリなど）を含み得る。

プロセッサ１０２は、ソフトウェアの実行およびユーザとのインタラクションをサポートする追加的なデバイスに結合され得る。例えば、プロセッサ１０２は、マウス、キーボード、タッチ・スクリーン、マイクロホンなどの１つまたは複数の入力デバイス１１０に結合され得る。プロセッサ１０２は、ディスプレイ・デバイス１１２、スピーカなどの１つまたは複数の出力デバイスにも結合され得る。プロセッサ１０２は、ＬＡＮ、ＷＡＮ、またはインターネットなどのネットワーク１１４を用いて１つまたは複数のその他のコンピュータ・システムと通信することができる。ネットワーク１１４を介した通信は、ネットワーク・アダプタ１１６によって容易にされ得る。

図２を参照すると、オブジェクト指向のマネージド・ランタイムの一例、この例においてはＪａｖａ（Ｒ）ランタイム環境が示されている。Ｊａｖａ（Ｒ）ランタイム環境は、本発明のさまざまな実施形態が動作することができるランタイム環境の一例を示すために示される。しかしながら、本明細書で開示されるインクリメンタル・ガベージ・コレクション技術は、Ｊａｖａ（Ｒ）ランタイム環境に限定されず、ガベージ・コレクションされるオブジェクトのヒープを用いてオブジェクトを記憶する任意のオブジェクト指向のマネージド・ランタイムで動作し得るか、または動作するように適合され得る。本発明の実施形態が動作することができるランタイム環境のその他の非限定的な例には、マイクロソフト共通言語ランタイム（ＣＬＲ）およびＳｍａｌｌｔａｌｋランタイムが含まれる。したがって、本明細書においてはＪａｖａ（Ｒ）ランタイム環境に関する特定の言及がなされるが、本明細書において教示される原理は、Ｊａｖａ（Ｒ）ランタイム環境に限定されず、多くのランタイム環境に適用できる可能性がある。

図２に示されるように、Ｊａｖａ（Ｒ）ランタイム環境において、Ｊａｖａ（Ｒ）仮想マシン２０２が、基礎となるハードウェアおよびオペレーティング・システム・アーキテクチャ２０４、２０６を含む可能性がある特定のプラットフォームで動作するように構成され得る。示されるように、Ｊａｖａ（Ｒ）仮想マシン２０２は、「バイトコード」２００と呼ばれる中間形態にコンパイルされたプログラム・コード２００を受け取る。Ｊａｖａ（Ｒ）仮想マシン２０２は、バイトコード２００を、基礎となるプラットフォーム２０４、２０６で実行するためのネイティブのオペレーティング・システム・コールおよび機械命令に変換する。バイトコード２００を特定のハードウェアおよびソフトウェア・プラットフォーム２０４、２０６のためにコンパイルする代わりに、バイトコード２００は、一旦すべてのＪａｖａ（Ｒ）仮想マシン２０２で動作するようにコンパイルされる。対称的に、Ｊａｖａ（Ｒ）仮想マシン２０２は、基礎となるハードウェアおよびソフトウェア・プラットフォーム２０４、２０６に合わせて作成され得る。このようにして、Ｊａｖａ（Ｒ）バイトコード２００は、プラットフォームに依存しないと見なされ得る。

上述のように、Ｊａｖａ（Ｒ）ランタイム環境において、主なメモリ・リソースは、ガベージ・コレクションされるオブジェクトのヒープ２１０である。オブジェクトのヒープ２１０はオブジェクトのためのメモリを提供し、オブジェクトのそれぞれはクラスのインスタンスである。ガベージ・コレクション・モジュール２０８またはサブシステム２０８が、プログラムによってもはや使用されていないオブジェクトまたはオブジェクトに関連するクラスによって占有されたメモリを回収するためにＪａｖａ（Ｒ）ランタイム環境内に設けられる。とりわけ大きな利点として、ガベージ・コレクション・モジュール２０８は、もはや必要とされないオブジェクトを開放することをプログラマが気に掛けなくてよいようにし、そうでなければ、プログラマはオブジェクトを開放することに多大な設計の労力を取られる。

上述のように、Ｊａｖａ（Ｒ）では、クラスが、プログラマによって指定された関連するクラスの基本的に任意のグループであるクラス・ローダの粒度でアンロードされる。クラス・ローダは、（ａ）そのクラス・ローダに対する参照がなく、（ｂ）そのクラス・ローダの定義されたクラスのいずれに対する参照もなく、（ｃ）いずれのスタックにもいかなる定義されたクラスからの実行中のメソッドもなく、（ｄ）そのクラス・ローダの定義されたクラスのいずれのインスタンスもないと、アンロードされ得る。クラス・ローダとクラスの両方がそれらを表すプロキシ・オブジェクトを有するので、ガベージ・コレクション・モジュール２０８は、（ａ）および（ｂ）の場合を容易に判定することができる。各ガベージ・コレクション・サイクルの始めにスタックがクローリングされなければならないので、ガベージ・コレクション・モジュール２０８は、（ｃ）の場合も容易に判定することができる。しかし、ガベージ・コレクション・モジュール２０８は、（ｄ）の場合を判定することがより困難である可能性がある。（ｄ）の場合を効率的に判定するためのさまざまな新規性のある技術が、図３から８に関連して説明される。

停止時間を減らすために、ガベージ・コレクション・モジュール２０８は、漸進的に動作するように構成され得る。つまり、ガベージ・コレクション・モジュール２０８は、オブジェクトのヒープ２１０全体とは対称的に、１回あたりオブジェクトのヒープ２１０の一部に対してガベージ・コレクションを実行するように構成され得る。これを実現するために、オブジェクトのヒープ２１０は、いくつかの領域（例えば、数百個または数千個の領域）に分割される可能性がある。それから、ガベージ・コレクション・モジュール２０８は、任意の特定の時間にこれらの領域のサブセット（本明細書においては「コレクション集合」とも呼ばれる）に対してガベージ・コレクションを実行することができる。これは、メインプログラムの中断を可能な限り最小化する。ガベージ・コレクション・モジュール２０８は、漸進的に動作し得るので、どのクラス・ローダがコレクション集合の中および外に生きているオブジェクトを有するかを判定して、クラス・ローダがアンロードされ得るかどうかを判定することができる必要がある。クラス・ローダがコレクション集合の中または外に生きているオブジェクトを有するかどうかを判定するためのさまざまな技術が、図３から８に関連して検討される。

図３を参照すると、本発明による特定の実施形態においては、ランタイム環境内の各クラス集合に対して記憶集合が設けられる可能性がある。本開示において、「クラス集合」は、クラス・ローダに関連するクラスの集合、クラスのグループ、単一のクラスなどを指すために使用される。Ｊａｖａ（Ｒ）はクラス・ローダの粒度でクラスをアンロードすることができるが、その他のランタイム環境は、個々のクラスまたはクラスのグループなどの異なるレベルの粒度でクラスをアンロードする可能性がある。表現「クラス集合」は、これらの異なるレベルの粒度を包含するように意図される。

図３は、クラス集合がクラス・ローダ３００に関連するクラスの集合である実施形態を示す。この実施形態においては、記憶集合３０４が、ランタイム環境内の各クラス・ローダ３００に関連付けられる。記憶集合３０４は、クラス・ローダ３００に関連する任意のクラスがオブジェクトのヒープ２１０の任意の領域３０２内にインスタンスを含むかどうかを記憶するために使用される。記憶集合３０４は、インスタンスが位置する領域３０２も示す可能性がある。

図３に示されるように、選択された実施形態において、記憶集合３０４は、フィールド３０４、この例においてはタグ付きポインタ（tagged pointer）３０４として具現化され得る。特定の実施形態においては、そのようなフィールド３０４は、クラス・ローダ３００の内部構造に追加される可能性がある。例えば、Ｊａｖａ（Ｒ）ランタイム環境においては、フィールド３０４は、内部のＣｌａｓｓＬｏａｄｅｒの構造に追加され得る。このフィールド３０４は、クラス・ローダ３００によって定義されたクラスのインスタンスを含む領域３０２の記憶集合３０４を構築するために、ガベージ・コレクション・モジュール２０８によって使用され得る。

メモリを効率的に使用するために、フィールド３０４は、特定の実施形態において、図３に示される表現のうちの１つを使用する可能性がある。これらの表現は、（１）「空」表現３０４ａ−この表現は、メモリ２１０内の領域３０２のいずれにもクラス集合のインスタンスが含まれていないことを示す−、（２）「直接（immediate）」表現３０４ｂ−この表現は、クラス集合のインスタンスを含むメモリ２１０内の領域３０２を指す１つまたは複数のポインタを記憶する−、（３）「オーバーフロー（overflow）」表現３０４ｃ−この表現は、実際にはそうでないとしてもすべての領域３０２がクラス集合のインスタンスを含むと想定するエラー状態である−、および（４）「ビット・ベクトル」表現３０４ｄ−この表現は、領域３０２ごとに１ビットを有するビット・ベクトル３０６を指すポインタを記憶し、ビット・ベクトル３０６のビットを設定することは、対応する領域３０２にクラス集合の少なくとも１つのインスタンスが含まれることを示す−を含む。示された実施形態において、各フィールド３０４の最後の２ビットは、どの表現が使用されるかを示すための「タグ」を提供する。例えば、図３に示されるように、タグ「００」は、フィールド３０４が「空」表現３０４ａを使用していることを示し、タグ「０１」は、フィールド３０４が「直接」表現３０４ｂを使用していることを示し、タグ「１１」は、フィールド３０４が「オーバーフロー」表現３０４ｃを使用していることを示し、タグ「１０」は、フィールド３０４が「ビット・ベクトル」表現３０４ｄを使用していることを示す。

引き続き図３を全体的に参照しながら図４を参照すると、クラス集合（例えば、クラス・ローダ）がオブジェクトのヒープ２１０にロードされるとき、クラス集合に関連するフィールド３０４は、最初に、空表現３０４ａで始まる可能性がある。空表現３０４ａは、どのビットも設定されていないビット・ベクトル３０６と等価である可能性がある。次に、フィールド３０４は、クラス集合のインスタンスが領域３０２に導入されるときに直接表現３０４ｂに遷移し得る。直接表現３０４ｂは、インスタンスを含む領域に関するビットだけが設定されたビット・ベクトル３０６と等価であるものとして扱われ得る。上述のように、直接表現３０４ｂは、クラス集合のインスタンスが記憶される領域３０２を指す少数のポインタのためにメモリを割り当てることができる。これは、クラス集合のインスタンスが少数の領域３０２にしか含まれない場合に、ビット・ベクトル３０６全体を割り当てるコストを回避する。例えば、シングルトン・クラス・ローダ（単一のインスタンスしか含まない単一のクラスに関連するクラス・ローダ）が、Ｊａｖａ（Ｒ）でよく使用される−標準的なｊａｖａ．ｌａｎｇ．ｒｅｆｌｅｃｔパッケージはそれらのクラス・ローダを大いに使用している。単一の領域３０２または少数の領域３０２を指し示す能力は、ビット・ベクトル３０６全体を割り当てるのに比べて大幅な節約をもたらすことができる。特定の実施形態において、直接表現３０４ｂは、インデックスによって少数の領域３０２を特定するように拡張され得る。

クラス集合のインスタンスを含む領域３０２の数が直接表現３０４ｂによって記憶され得るポインタの数を超えると、フィールド３０４は、ビット・ベクトル表現３０４ｄに遷移することができる。この表現３０４ｄに遷移すると、ビット・ベクトル３０６が、クラス集合に割り当てられる。上述のように、このビット・ベクトル３０６は、オブジェクトのヒープ２１０内の各領域３０２に関するビットを含み得る。ビットを設定することは、クラス集合に関連するクラスの少なくとも１つのインスタンスが対応する領域３０２内に記憶されていることを示す。

特定の実施形態において、ガベージ・コレクション・モジュール２０８は、ビット・ベクトル３０６によって使用されるメモリの量を制限する可能性がある。メモリの制限に達したか、またはシステムがメモリ不足であるかのどちらかのために、ガベージ・コレクション・モジュール２０８がビット・ベクトル３０６を割り当てることができない場合、ガベージ・コレクション・モジュール２０８は、フィールド３０４の状態をオーバーフロー表現３０４ｃに設定することができる。オーバーフロー表現３０４ｃは、ビット・ベクトル３０６と異なりオーバーフロー表現３０４ｃからはビットがクリアできないことを除いて、すべてのビットが設定されたビット・ベクトル３０６と等価であるものとして扱われ得る。フィールド３０４は、オーバーフロー表現３０４ｃを使用すると、対応するクラス集合がオブジェクトのヒープ２１０からアンロードされるまでオーバーフロー表現３０４ｃに留まる可能性がある。同様に、フィールド３０４は、ビット・ベクトル表現３０４ｄを使用すると、対応するクラス集合がオブジェクトのヒープ２１０からアンロードされるまでビット・ベクトル表現３０４ｄに留まる可能性がある。

図５を参照すると、インクリメンタル・ガベージ・コレクション・プロセス中にオブジェクトのヒープ２１０からクラス集合およびより具体的にはクラス・ローダ３００をアンロードするための方法５００の一実施形態が示されている。方法５００は、図３および４に示された４つの表現３０４ａ〜ｄのすべてを扱うように容易に適合され得るが、各クラス・ローダ３００が独自のビット・ベクトル３０６を含むと想定する。示されるように、コレクション集合内の各クラス・ローダ３００に関して、方法５００は、コレクション集合内にある領域３０２に関するビット・ベクトル３０６のビットをクリアする５０４。ビットをクリアした後、方法５００がビット・ベクトル３０６が空であると判定する５０６場合、クラス・ローダ３００は、コレクション集合からのアンロードの候補である。一方、方法５００がビット・ベクトル３０６が空でない（少なくとも１つのビットが設定されている）と判定する５０６場合、クラス・ローダ３００は、コレクション集合の外の領域に少なくとも１つのインスタンスを含む可能性があるのでコレクション集合からのアンロードの候補ではない。そのような場合、方法５００は、クラス・ローダ３００に「生きている」と印を付ける５０８。

インクリメンタル・ガベージ・コレクション・プロセス中、生きているオブジェクトがコレクション集合内で発見されることになる。発見されたそれぞれの生きているオブジェクトに関して、方法５００は、生きているオブジェクトに関連するクラス・ローダと、生きているオブジェクトが含まれる領域とを判定する。方法５００は、生きているオブジェクトに関連するクラス・ローダ３００に「生きている」と印を付け５１２、生きているオブジェクトが存在する領域に関するクラス・ローダのビット・ベクトル３０６のビットを設定する５１４。

インクリメンタル・ガベージ・コレクション・プロセスの終わりに、方法５００は、コレクション集合内のクラス・ローダ３００をもう一度調べる。コレクション集合内の各クラス・ローダ３００に関して、方法５００は、そのクラス・ローダ３００が「生きている」と印を付けられているかどうかを判定する５１８。クラス・ローダ３００が「生きている」と印を付けられていない場合、クラス・ローダ３００は死んでいる（到達不可能である）こと、およびクラス・ローダ３００に関連するいかなるクラスのインスタンスもコレクション集合の中または外のどちらにも存在しないことが推定され得る。そのような場合、方法５００は、コレクション集合からクラス・ローダ３００をアンロードする５２０。そうでない場合、方法５００は、クラス・ローダ３００をコレクション集合に残す。

図６を参照すると、上述のインクリメンタル・ガベージ・コレクション・プロセスのさまざまな変更が可能であり、それらは本発明の範囲内にある。例えば、図３および４に関連して説明された４つの表現３０４ａ〜ｄを使用して記憶集合を実装する代わりに、各クラス・ローダ３００などの各クラス集合に対してビット・ベクトル３０６が割り当てられる可能性がある。この実施形態は、特に、非常に多くのクラス・ローダ３００がシングルトン・クラス・ローダである場合、またはクラス・ローダ３００がわずかな数のクラスを定義するか、もしくはオブジェクトのヒープ２１０にそれらのクラスのわずかな数のインスタンスを有する場合、上述の４つの表現３０４ａ〜ｄほど効率的にメモリを使用しない可能性があるが、簡潔さの点で有利である可能性がある。オブジェクトのヒープ２１０内に比較的少ない数の領域３０２が存在する場合、このことは各ビット・ベクトル３０６のビット数と、ひいては各ビット・ベクトル３０６によって利用されるメモリの量とを削減するので、この実施形態は、効率的でもあり得る。

図７を参照すると、別の実施形態において、各クラス・ローダ３００に対してビット・ベクトル３０６を設ける代わりに、各クラス７００に対してビット・ベクトル３０６が設けられる可能性がある。クラスが領域３０２に含まれるとき、領域３０２に関連するビットが設定され得る。インクリメンタル・ガベージ・コレクション・プロセス中、ビット・ベクトル３０６は、コレクション集合のクラス７００のインスタンスがコレクション集合の中または外の領域３０２に含まれるかどうかを判定するために調べられる可能性がある。クラス７００がそのクラスのビット・ベクトル３０６を用いて死んでいると判定される場合、クラス７００は、コレクション集合からアンロードされ得る。代替的に、プロセスは、コレクション集合からクラス７００のうちのいずれかをアンロードする前に、クラス・ローダ３００またはクラスのその他のグループに関連するすべてのクラス７００が死ぬまで待つ可能性がある。すべてのクラス７００が死んでいるとき、クラス７００はグループとしてアンロードされ得る。この実施形態は、個々のクラス７００に対して、図３および４で示された表現３０４ａ〜ｄのいずれかを使用するように修正される可能性もある。

図８を参照すると、本発明のさらに別の実施形態において、ビット・ベクトル３０６を利用するあらゆる表現３０４ｄを省略しながら最初の３つの表現３０４ａ〜ｃが使用される可能性がある。そのような実施形態においては、「直接」表現３０４ｂが、何らかの限界まで、選択された数の領域３０２を特定するための特定の数のポインタを記憶するように構成される可能性がある。限界に達すると、クラス集合に関連するクラスのインスタンスがすべての領域３０２に含まれると想定するオーバーフロー表現３０４ｃが使用され得る。クラス集合がオーバーフロー表現３０４ｃを使用するとき、クラス集合は、グローバルなガベージ・コレクションが実行され、クラス集合がアンロードされるまでオーバーフロー表現３０４ｃに留まる可能性がある。この実施形態は、多くのクラス集合が直接表現３０４ｂで利用可能なポインタの数を超える領域にインスタンスを含む場合を除いて、効率的にメモリを利用することができる。これは、多くのクラス集合にオーバーフロー表現３０４ｃを使用させることになり、そのことは、非効率的である可能性がある。

図３、６、７、および８に示された実施形態は、記憶集合３０４を実装するためのさまざまな技術の単なる例である。それぞれは、異なるランタイム環境で利点および欠点を有する可能性がある。実施形態は、例として示されているに過ぎず、限定することを意図されていない。したがって、その他の変更が可能であり、それらは本発明の範囲内にある。

図面の流れ図および構成図は、本発明のさまざまな実施形態によるシステム、方法、およびコンピュータが使用可能な媒体のあり得る実装のアーキテクチャ、機能、および動作を示す。これに関連して、流れ図または構成図の各ブロックは、（１つまたは複数の）規定された論理的な機能を実装するための１つまたは複数の実行可能命令を含むモジュール、セグメント、またはコードの一部を表す可能性がある。一部の代替的な実装においては、ブロックで示された機能が、図面に示された順序とは異なる順序で行われる可能性があることにも留意されたい。例えば、連続で示された２つのブロックが、実際には実質的に同時に実行される可能性があり、またはそれらのブロックは、関連する機能に応じて逆順に実行されることもあり得る。一部のブロックが削除される可能性があり、またはその他のブロックが関連する機能に応じて追加される可能性がある。ブロック図または流れ図あるいはその両方の各ブロックと、ブロック図または流れ図あるいはその両方のブロックの組み合わせとは、規定された機能もしくは動作を実行する専用のハードウェアに基づくシステム、または専用のハードウェアとコンピュータ命令との組み合わせによって実装され得ることも認められるであろう。

Claims (9)

1. 領域に基づくガベージ・コレクタを用いてクラスを漸進的にアンロードするための方法であって、
   クラス集合に関する記憶集合（remembered set）を保守するステップであって、前記記憶集合は、前記クラス集合のインスタンスがメモリ内の１つまたは複数の領域に含まれるかどうか、およびメモリ内のどの領域に前記インスタンスが含まれるかを示す、ステップと、
   メモリ内の前記領域のサブセットに対してインクリメンタル・ガベージ・コレクション・プロセスを実行するときに、前記記憶集合を調べて、前記クラス集合が前記サブセットの外の領域にインスタンスを含むかどうかを判定するステップと、
   前記記憶集合が、前記クラス集合が前記サブセットの外の領域にインスタンスを含むことを示す場合に、前記クラス集合を「生きている(live)」ものとして特定するステップと、
   前記インクリメンタル・ガベージ・コレクション・プロセスにおいて発見された前記サブセット内の生きているインスタンスに前記クラス集合が関連する場合に、該クラス集合を「生きている(live)」ものとして特定するステップと、
   前記クラス集合が「生きている」と判定されない場合に、前記クラス集合をアンロードするステップと、
   を含む、方法。
2. 前記クラス集合が、クラス・ローダに関連するクラスの集合、クラスのグループ、および単一のクラスのうちの１つである請求項１に記載の方法。
3. 前記記憶集合が、前記クラス集合に割り振られたビット・ベクトルを含み、前記ビット・ベクトルの各ビットが、メモリ内の領域に割り振られている請求項１に記載の方法。
4. 各ビットの値が、前記クラス集合の少なくとも１つのインスタンスがメモリ内の対応する領域に含まれるかどうかを示す請求項３に記載の方法。
5. 前記サブセットに対して前記インクリメンタル・ガベージ・コレクション・プロセスを実行する前に、前記サブセット内の領域に関する前記ビット・ベクトルのビットをリセットするステップをさらに含む請求項４に記載の方法。
6. 前記サブセットに対して前記インクリメンタル・ガベージ・コレクション・プロセスを実行するときに、前記クラス集合のインスタンスが発見される前記サブセット内の領域に関する前記ビット・ベクトルのビットを設定するステップをさらに含む請求項５に記載の方法。
7. 前記ビット・ベクトルのビットのいずれかが設定されている場合に前記クラス集合を「生きている」ものとして特定するステップをさらに含む請求項６に記載の方法。
8. 領域に基づくガベージ・コレクタを用いてクラスを漸進的にアンロードするためのコンピュータ・プログラムであって、コンピュータに、請求項１乃至７のいずれか１項に記載の前記方法の全てのステップを実行させる前記コンピュータ・プログラム。
9. 領域に基づくガベージ・コレクタを用いてクラスを漸進的にアンロードするための装置であって、請求項１乃至請求項７のいずれか１項に記載の前記方法の全てのステップを実行するように適合された手段を含む、前記装置。

Images