JP2005011349A - 電子システムおよびガーベジコレクション方法 - Google Patents

Abstract

【課題】スタックベース言語（たとえば、Ｊａｖａ）に関連付けられたコンピュータプログラムを格納することができるメモリを有するプロセッサ等のプログラマブル電子装置を得る。
【解決手段】プロセッサ、プロセッサに接続されたメモリ、および埋込ガーベジコレクションオブジェクトをアクティブとするアプリケーションプログラミングインターフェイスを含む電子システム。メモリは選択的にルートオブジェクトからの参照を有する一つ以上のオブジェクトを格納する。埋込ガーベジコレクションオブジェクトは、好ましくは、制御データを使用して前記メモリからオブジェクトを除去させ、除去オブジェクトは埋込ガーベジコレクションオブジェクトがアクティブである間に生成されしかもルートオブジェクトからの参照がないオブジェクトを含む。
【選択図】図２

Description

本発明は一般的にプロセッサに関し、特にプロセッサに関連付けられたメモリの管理に関する。

多種の電子装置がバッテリ操作されるため、消費電力はできるだけ少ないことが望ましい。一例はセルラー電話機である。さらに、セルホーン等の電子装置内でさまざまな種類のマルチメディア機能を実現するのは望ましいことがある。マルチメディア機能の例として、限定はしないが、ゲーム、オーディオデコーダ、デジタルカメラ、等が含まれる。

したがって、他は全て等しく、高速であって、できるだけ電力を消費せずしかもできるだけメモリを必要としないように電子装置内にこのような機能を実現することが望ましい。このエリアにおける改善が望まれる。

一実施例では、電子システムはプロセッサ、プロセッサに接続されたメモリ、および埋込ガーベジコレクションオブジェクトをアクティブにするアプリケーションプログラミングインターフェイスを含んでいる。メモリは選択的にルートオブジェクトからの参照を有する一つ以上のオブジェクトを格納する。埋込ガーベジコレクションオブジェクトは、好ましくは、制御データを使用してオブジェクトを前記メモリから除去し、除去オブジェクトは埋込ガーベジコレクションオブジェクトがアクティブであった間に作り出されしかもルートオブジェクトからの参照を有しないオブジェクトを含んでいる。

一実施例では、方法は埋込ガーベジコレクタを始動させ、メモリから除去するオブジェクトを選択するステップを含み、メモリは関連付けられたオブジェクトへの参照を選択的に有することができるルートオブジェクトを含み、選択されたオブジェクトを除去するステップを含む。除去するオブジェクトの選択はコンテキストが変化しているルートオブジェクトを識別し、識別されたルートオブジェクトを参照されたオブジェクトにトレースしてコンテキストが変化しているルートオブジェクトにどのオブジェクトが関連付けられるかを決定するステップを含んでいる。選択されたオブジェクトの除去は埋込ガーベジコレクタがアクティブであった間に生成されしかもコンテキストが変化しているルートオブジェクトに関連付けられていると決定されなかったオブジェクトを除去するステップを含んでいる。

下記の明細書および特許請求の範囲全体をとおして特定のシステム構成要素を指示するのにある用語が使用される。さまざまな半導体会社がある構成要素を異なる名称で指示することがあることを当業者ならばお判りである。本明細書では名称が違っていても機能的に同じ構成要素は区別しない。下記の検討および特許請求の範囲において、“含む（including）”および“からなる（comprising）”という用語は幅広い解釈を許すように使用され、したがって、“限定はしないが、含んでいる”ことを意味するように解釈しなければならない。また、“結合する（coupleまたはcouples）”という用語は直接または間接接続を意味するものとする。したがって、第１の装置が第２の装置に接続される場合、その接続は直接接続または他の装置や接続を介した間接接続とすることができる。

本発明の好ましい実施例をより詳細に説明するために、次に、添付図を参照する。
下記の検討は本発明のさまざまな実施例に向けられる。これらの実施例の一つ以上は好ましいものではあるが、特記なき限り開示された実施例は特許請求の範囲を含めて開示の範囲を制限するものとして解釈または使用してはならない。さらに、当業者ならば下記の説明は広い応用を有し、任意の実施例の検討は単にその典型的な実施例の意味を持つにすぎず、特許請求の範囲を含む本開示の範囲がその実施例に限定されることを暗示するものではないことを理解できる。

ここに開示された主題はスタックベース言語（たとえば、Ｊａｖａ（登録商標））に関連付けられたコンピュータプログラムを格納することができるメモリを有するプロセッサ等のプログラマブル電子装置に向けられている。コンピュータプログラムはハードウェア、ソフトウェア、またはハードウェアとソフトウェアの両方で実現することができる“仮想”マシンを介して実行することができる。仮想マシンはコンピュータプログラムを“スタック”と呼ばれるメモリの一部で基本的なコンピュータ操作を実施することができるマシンコード（たとえば、Ｊａｖａバイトコード）に変換することができる。仮想マシンにより実行される間に、Ｊａｖａバイトコードはスタックを利用して中間値を格納することができる。

スタックの他に、メモリの一部をＪａｖａオブジェクト（たとえば、変数、クラス、タイプ）を格納するために保存することができる。メモリのこの部分を“ヒープ”と呼ぶことができる。Ｊａｖａオブジェクトが生成される時、オブジェクトはヒープ内にメモリを割当てている。ヒープ内に割当てられるメモリのサイズは生成されたオブジェクト内に含まれるＪａｖａフィールドのタイプ（たとえば、int,long,array）によって決まることがある。仮想マシンはヒープに対して保存されるメモリ量を利用されるヒープのパーセンテージに応じて調節することができる。たとえば、ヒープが過剰利用されると、仮想マシンはヒープに対する付加メモリを保存する。

ヒープ内に格納されたオブジェクトは“参照”と呼ばれる機構を介してヒープ内に格納された他のオブジェクトを利用することができる。たとえば、第１のオブジェクトは第２のオブジェクトに関連付けられた変数を使用することができる。一度ヒープ内にロードされると、第１のオブジェクトは第２のオブジェクトへの参照を作り出すことができる。一度オブジェクト間の参照が生成されると、第１のオブジェクトは第２のオブジェクトに関連付けられた変数にアクセスすることができる。オブジェクトに関連付けられた全参照のセットはそのオブジェクトに対する“コンテキスト”と呼ばれる。参照は参照フィールドまたはアレイエレメント上に書き込む各Ｊａｖａバイトコードに対応する“PutRef”操作を介して挿入され修正される。このようにして、ＪａｖａオブジェクトのコンテキストはPutRef操作がオブジェクト上に発せられる時しか変化しない。

ヒープのサイズはシステムに関連付けられたメモリの総量により制限されることがある。ヒープがこの最大サイズに達して完全に利用されると、付加オブジェクトを生成することはできない。この状態が生じると、もはや不要であるかもしれない現在ヒープ内に格納されているオブジェクトがＪａｖａプロセスによりヒープから取り出されて他のオブジェクト用の場所を作る。ヒープからオブジェクトを除去する責任のあるＪａｖａプロセスは“ガーベジコレクション”プロセスと呼ぶことができる。ガーベジはヒープから永久的に除去するためにガーベジコレクションプロセスが選択するオブジェクトを表す。ガーベジコレクションプロセスがヒープからオブジェクトを永久的に除去した後で、これらのオブジェクトに関連付けられたメモリは他のオブジェクトに割当てることができる。

ガーベジコレクションプロセスは“ルート”を使用してヒープから永久的に除去することができるオブジェクトを識別する。ユーザがルートを割当てることができるが、一般的にルートは基本的なオブジェクトランタイムにより自動的に割当てられる。このオブジェクトランタイムは、アプリケーション自体から見て必要ではない、アプリケーションの第1のオブジェクトを生成するかまたはオブジェクトへの参照を含むスタック（メモリブロック）を生成し、これらのオブジェクトをルートとして割当てられる。

ルートが識別され割当てられた後で、ガーベジコレクションプロセスはルートから他のオブジェクトへの参照を調べることができる。たとえば、図１はルート１０２およびオブジェクト１０４，１０６，１０８，および１１０を含む典型的なヒープ１００を示す。明示されてはいないが、ルート１０２はガーベジコレクションプロセスによりルートとして割当てられたヒープ内に格納された任意のオブジェクトを含むことができる。ルート１０２は参照１１２を介して直接オブジェクト１０４を参照することができる。オブジェクト１０４はさらに参照１１４を介してオブジェクト１０６を参照することができる。ガーベジコレクションプロセスがヒープ１００上で実行されている時に、ルート１０２からの全参照にガーベジコレクションプロセス内の手順が続くことができる。ルートオブジェクトからヒープ内に格納された他のオブジェクトへの後続参照の手順は“トレースルーチン”と呼ぶことができる。たとえば、ヒープ１００上のトレースルーチンはルート１０２によりアクセス可能なものとしてＪａｖａオブジェクト１０４および１０６を識別することができる。トレースルーチン中に識別されたオブジェクトに基づいて、ガーベジコレクションプロセスはヒープからどのオブジェクトを除去すべきかを決定することができる。トレーシングルーチン内で識別されたオブジェクトは典型的に除去されずトレーシングルーチン内で識別されないオブジェクトが典型的に除去される。トレーシングルーチンはルートから開始するため、識別されたオブジェクトはルートから“到達可能”なオブジェクトと呼ばれ、識別されないオブジェクトは “到達不能”なオブジェクトと呼ばれる。この除去技術の背後の原理はトレーシングルーチン内で識別されないオブジェクトをアプリケーション実行には不要で除去できるものと見なす。図１の例では、オブジェクト１０８および１１０には参照がなくヒープ１００上のトレースルーチン内で識別されない。このようにして、ガーベジコレクションプロセスはこれらのオブジェクトをヒープから除去することができる。本発明の好ましい実施例では、前記したようなガーベジコレクタを後述する好ましいガーベジコレクタと組み合わせることができる。

オブジェクトがマシン（たとえば、プロセッサ、仮想マシン）により使用された後でガーベジコレクションプロセスがヒープからオブジェクトを除去することができるシステムの好ましい実施例の操作について以下に説明する。他のプロセッサアーキテクチュアおよび実施例も使用することができるため、本開示および特許請求の範囲は任意特定タイプのプロセッサに限定されるものではない。ガーベジコレクションプロセスに関する詳細がプロセッサおよび仮想マシンの説明に続く。

ここに記述されたプロセッサはＪａｖａ^ＴＭ Bytecodes、または匹敵するコードを実行するのに特に適している。よく知られているように、Ｊａｖａは埋込アプリケーションに特に適している。Ｊａｖａは比較的“稠密な”言語であり、平均して各命令はさまざまな他のプログラミング言語に比べて多数の機能を実施できることを意味する。Ｊａｖａの稠密性はスペースおよび電力を節減するために好ましくはできるだけ少ないメモリしか含んでいないポータブル、バッテリ操作装置にとって特に有利である。しかしながら、Ｊａｖａコードを実行する理由は本開示または特許請求の範囲の題材ではない。

次に、本発明の好ましい実施例に従ったシステム２００を図２に示す。図からお判りのように、このシステムは少なくとも２つのプロセッサ２０２および２０４を含んでいる。本開示の目的のために、プロセッサ２０２はＪａｖａスタックマシン（“ＪＳＭ”）と呼ばれ、プロセッサ２０４は主プロセッサユニット（“ＭＰＵ”）と呼ばれる。システム２００はＪＳＭ２０２およびＭＰＵ２０４に共に接続されたメモリ２０６も含むことができ両方のプロセッサによりアクセスすることができる。メモリ２０６の少なくとも一部は両方のプロセッサが共用することができ、両方のプロセッサが同じ共用メモリ場所にアクセスできることを意味する。さらに、所望によりメモリ２０６の一部を一方または他方のプロセッサ専用として指示することができる。システム２００はＪａｖａ仮想マシン（“ＪＶＭ”）２０８、コンパイラ２１０およびディスプレイ２１４も含んでいる。好ましくは、ＪＳＭ２０２はユーザがシステム２００のさまざまな側面を制御するのを許すキーパッド等の一つ以上の入出力（“Ｉ／Ｏ”）装置とのインターフェイスを含んでいる。さらに、データストリームをＩ／ＯスペースからＪＳＭ２０２内に受信してＪＳＭ２０２により処理することができる。所望により、他の構成要素（明示せず）も含むことができる。

やはり図２について、一般的に知られているように、Ｊａｖａコードは複数の“バイトコード”２１２を含んでいる。バイトコード２１２はＪＶＭ２０８に供給され、コンパイラ２１０によりコンパイルされ、その中で実行するためにＪＳＭ２０２および又はＭＰＵ２０４に供給することができる。本発明の好ましい実施例では、ＪＳＭ２０２は少なくともいくつかの、一般的には大概の、Ｊａｖａバイトコードを実行することができる。しかしながら、適切であればＪＳＭ２０２はそれが実行しなかったまたは実行できない一つ以上のＪａｖａバイトコードを実行するようＭＰＵ２０４に要求することができる。Ｊａｖａバイトコードを実行する他に、ＭＰＵ２０４は非Ｊａｖａ命令も実行することができる。また、ＭＰＵ２０４はシステムメモリ管理、ＪＶＭ２０８およびシステム上で実行する大概のまたは他の全てのネイティブタスクをスケジューリングするシステムタスク管理、ディスプレイ２１４の管理、入力装置からの入力受信、等を含むさまざまな機能を実施するオペレーティングシステム（“Ｏ／Ｓ”）（明示せず）もホストする。限定はしないが、Ｊａｖａコードは、Ｏ／Ｓおよび他のネイティブアプリケーションを含むことができる非ＪａｖａコードがまだＭＰＵ２０４上のシステムで実行している間に、マルチメディア、ゲームまたはウェブベースアプリケーションを含む多様なアプリケーションのいずれか一つをシステム２００内で実施するのに使用することができる。

ＪＶＭ２０８は一般的にソフトウェアとハードウェアの組合せを含んでいる。ソフトウェアはコンパイラ２１０を含むことができハードウェアはＪＳＭ２０２を含むことができる。ＪＶＭはクラスローダ、バイトコードベリファイア、ここに記述された好ましいガーベジコレクタから機能的に分離することができる一般的なガーベジコレクタ、およびＪＳＭプロセッサ２０２上で実行されないバイトコードを解釈するバイトコードインタープリタを含むことができる。

本発明の好ましい実施例では、ガーベジコレクションプロセスはアプリケーションプログラミングインターフェイス（ＡＰＩ）を使用してコンピュータプログラム内に埋め込むことができる。好ましくは、ＡＰＩはプログラムデベロッパがガーベジコレクションを制御するために実行することができる一連の機能を含んでいる。ガーベジコレクションプロセスはプログラム内に具体化されるため、プロセスはそれを実行しているプログラムと同じメモリスレッド内で実行する。同じメモリスレッド内で実行することにより、埋込ガーベジコレクションプロセスは特定のプログラムにより利用されるオブジェクトを有効に除去することができる。この埋込ガーベジコレクションプロセスはここでは埋込ガーベジコレクタ（“ＥＧＣ”）と呼ぶことができる。

好ましくは、埋込ガーベジコレクタＡＰＩ（ＥＧＣ-ＡＰＩ）はＥＧＣの操作を制御する３つの機能を含んでいる。ＥＧＣオブジェクトの生成関数である第１の関数はヒープ内にＥＧＣを生成してＥＧＣにより使用されるデータ構造を設定する。第２の関数“egc.start()”はＥＧＣを“アクティブ”状態に設定する。第３の関数“egc.stop()”は、好ましくは、トレーシングルーチンを実施し、選択されたオブジェクトをヒープから除去し、アクティブＥＧＣを終了する。egc.start()関数が実行された後egc.stop()関数が実行されるまでの任意の時間ＥＧＣの状態はアクティブであると考えられる。好ましくは、egc.start()およびegc.stop()は除去するメソッド呼出しの同じレベル内にある。それにより参照サーチに対する関連付けられたスタックフレームのコンテンツを解析する必要をなくすことができる。

好ましくは、ＥＧＣはそれがアクティブである間にヒープ内に生成されているオブジェクトだけを除去しようと考える。前記したような他のガーベジコレクタをＥＧＣと組み合わせて使用してＥＧＣにより考慮されないヒープからオブジェクトを除去することができる。さらに、トレーシングルーチンに対してルーツを自動的に割当てるのとは反対に、好ましくは、ＥＧＣはプログラムデベロッパが関連付けられたＥＧＣの生成関数のパラメータを使用してルートを指定するのを許す。

指定されたルーツは“ルートアレイ”と呼ばれるデータ構造を使用してＥＧＣ内に組み入れることができる。ＥＧＣのトレーシングルーチンに対するルーツを定義するオブジェクトへの参照をルートアレイ内に含めることができる。たとえば、デベロッパはルートアレイ内の特定オブジェクトへの参照を含むことができる。このオブジェクトに関連付けられたすべての参照をトレーシングルーチン中に識別することができる。好ましくは、トレーシングルーチン中に識別されたオブジェクトはＥＧＣによって除去されない。現在または前の活性化において、ＥＧＣがアクティブである間に生成されかつトレーシングルーチンにおいて識別されなかった他のオブジェクトは好ましくは除去される。ルートオブジェクトの指定を許すＥＧＣの能力によりプログラムデベロッパはガーベジコレクションプロセスにおいて従来のガーベジコレクタよりも制御を行うことができる。

図３はＥＧＣが使用する典型的なヒープ３５０を示す。ルートアレイは任意数のオブジェクトへの参照を含むことができるが、図３の例ではルートアレイ３００は３つのルートオブジェクト３０２，３０４，および３０６への参照を含んでいる。好ましくは、各ルートオブジェクトは３つの関連付けられたデータ変数を含んでいる。“リーチセット（reach set）”と呼ばれる第１のデータ変数はＥＧＣのトレーシングルーチン中に識別されるオブジェクトに参照を配置するのに使用することができる。これらの参照は特定のルートオブジェクトにより参照されるヒープ内に格納された全てのオブジェクトを含むことができる。したがって、ルートのリーチセット変数はルートコンテキストに対応する。ルートオブジェクト３０２，３０４，および３０６は図示するようにリーチセット３０８，３１０，および３１２を含むことができる。

第２のデータ変数は各ルートオブジェクトと関連付けられてルートオブジェクトに関連付けられた参照、直接または推移参照、のコンテキストが修正されているかどうかを示すことができる状態ビットである。この状態ビットは“修正”ビットと呼ぶことができる。たとえば、egc.start()関数を実行すると、ルーツオブジェクトの修正ビットを偽に初期設定することができる。ＥＧＣのアクティブ状態中に、参照が修正され、生成され、または現在のルートコンテキストのオブジェクトから削除されると、そのルートオブジェクトの修正ビットは真に設定される。図からお判りのように、ルートオブジェクト３０２，３０４，および３０６は、それぞれ、修正ビット３１４，３１６，および３１８を含んでいる。

本発明の好ましい実施例では、修正ビットはＪＶＭ２０８により自動的に修正することができる。参照が生成または修正される度に、“PutRef”命令がオブジェクト上のＪＶＭに発せられる。好ましくは、PutRef命令の修正はPutRefがルートコンテキスト内側のオブジェクトになされる場合にルートオブジェクトの修正ビットを真に設定するように行われる。オブジェクトがルートコンテキストの内側であるかを決定するために、“ルート識別子”と呼ばれる第３の変数について記述する。

最後に、各ルートオブジェクト内の第３のデータ変数はルート識別子である。ルート識別子はルートオブジェクトへの参照を格納する。したがって、ルートオブジェクト３０２，３０４，および３０６はルート識別子３６０，３６２，および３６４を含んでいる。

やはり図３について、２つの変数アレイをＥＧＣと組み合わせて使用することができる。“ヒープセット”と呼ばれる第１のアレイ３２０は、好ましくは、ＥＧＣがアクティブである前後にＥＧＣルートコンテキストの内側であるヒープ内のオブジェクトへの参照を格納するのに使用される。たとえば、ヒープセット３２０はＥＧＣが開始される前にヒープ内にあるオブジェクトを含むことができる。“テンプセット（tempset）”と呼ばれる第２のアレイ３２２は、好ましくは、ＥＧＣがアクティブである間にヒープ内に生成されたオブジェクトの参照を格納するのに使用される。ヒープ３５０はヒープオブジェクト３２４を含むこともできる。任意所定の時間におけるヒープ内のオブジェクトは任意数とすることができるが、図３の例ではヒープオブジェクト３２４は３つのオブジェクト３２６，３２８，３３０を含んでいる。各オブジェクト３２６，３２８，３３０にはルート識別子３３２，３３４，および３３６が関連付けられている。ルートオブジェクト内のルート識別子と同様に、このルート識別子はオブジェクトを生成している時はＮＵＬＬに設定される。ヒープオブジェクトのルート識別子は、好ましくは、ヒープオブジェクトを参照するルートオブジェクトへの参照を格納する。たとえば、ＥＧＣがアクティブである間にオブジェクトを生成してルートオブジェクトのコンテキスト内に挿入することができる。この新たに生成されたオブジェクトに関連付けられたルート識別子はオブジェクトを参照するルートオブジェクトへの参照を含むことができる。ＥＧＣアルゴリズムはトレーシングルーチン中にヒープ内のオブジェクトのルート識別子の設定を管理してどのルーツのコンテキストが変化したかを検出する。

好ましい実施例では、ルート識別子はＪＶＭ２０８により自動的に生成することができる。ヒープ内にオブジェクトが生成されるたびに、“新しい”命令がＪＶＭに発せられる。好ましくは、“新しい”命令はオブジェクトを生成してヒープ上に格納する。“新しい”命令の修正は、好ましくは、ＥＧＣがアクティブである間に生成された各新しいオブジェクトにルート識別子を関連付けるように行うことができる。最初にルート識別子はＮＵＬＬ値に設定することができる。

次に、図４-８に関してＥＧＣを使用する典型的なヒープについて検討する。ＥＧＣの機能を例示するために実行の５段階を示す。これらの５段階はＥＧＣの操作を説明するためだけに使用される。ＥＧＣの実際の操作は任意所望数の段階を使用することができる。第１段階（図４）はegc.start()関数実行中のヒープの状態および関連付けられたデータ構造を示す。第２段階（図５）はＥＧＣがアクティブでヒープ内に新しいオブジェクトが生成される間のヒープの状態および関連付けられたデータ構造を示す。第３段階（図６）はＥＧＣがアクティブでルートオブジェクトのコンテキストが修正されている間のヒープの状態および関連付けられたデータ構造を示す。第４段階（図７）はegc.stop()関数実行中のヒープの状態および関連付けられたデータ構造を示す。最後に、第５段階（図８）はegc.stop()関数実行後のヒープの状態および関連付けられたデータ構造を示す。

次に、図４に関して、ヒープ３５０は実行の第１段階で示すことができる。ルートアレイ内に任意数のルートオブジェクトを含むことができるが、検討を容易にするために３つのルートオブジェクト３０２，３０４，および３０６が示されている。これらのオブジェクトはプログラムデベロッパによりルートアレイ３００内に配置される。修正ビット３１４，３１６，および３１８はegc.start()呼出し中に偽に初期設定される。前記したように、ルートオブジェクトに関連付けられた修正ビットは、ルート識別子がＮＵＬＬではない、オブジェクトにPutRef操作が実施される時に真に設定される。

ヒープセットデータ構造はＥＧＣの前のインスタンスによりヒープ上に残されかつルートコンテキストの内側であるオブジェクトへの参照を含んでいる。典型的な目的に対して、ヒープセット３２０はこのような２つのオブジェクト３２６および３２８への参照を含むことができる。オブジェクト３２６はルート３０２のルートコンテキストの内側であり（ルート３０２とオブジェクト３２６間に参照が存在する）オブジェクト３２８はルート３０４のルートコンテキストの内側である（ルート３０４とオブジェクト３２８間に参照が存在する）。したがって、オブジェクト３２６および３２８はそれぞれ３０２および３０４に設定されたルート識別子を有する。ルート識別子は初期egc.start()呼出し中および各egc.stop()呼出し中に設定される。実行の第１段階においてテンプセット３２２だけでなくリーチセット３０８，３１０，および３１２も空である。ＥＧＣがアクティブであった間オブジェクト３３０は生成されなかったため、ヒープセット３２０には含まれずＥＧＣにより除去されるものと見なされない。

図５は実行の第２段階（ヒープ内のオブジェクト生成）におけるヒープ３５０を示す。この段階において任意数のオブジェクトを生成することができるが、検討を容易にするためこのような２つのオブジェクト３５２および３５４が示されている。オブジェクト３５２および３５４はＥＧＣがアクティブである間に生成される。したがって、オブジェクト３５２および３５４への参照はテンプセット３２２内に配置される。さらに、これらのオブジェクトのルート識別子は‘Ｎｕｌｌ’に設定される。他の全てのデータ構造は実行の第２段階において不変である。

次に、実行の第３段階（オブジェクトコンテキスト修正）における典型的なヒープ３５０が図６に示されている。典型的な目的に対して、ルートオブジェクト３０４の参照はオブジェクト３２８からオブジェクト３５２に変化する（putrefベースopcodeを使用して）。オブジェクト上にputref opcodeを実現する時に、ランタイムはそのオブジェクトのルート識別子を使用して対応するルートオブジェクトの修正ビットを真に設定する。図６においてputrefがオブジェクト３０４に実行され、オブジェクト３０４自体がルートであるため関連付けられたルート識別子３６０はオブジェクト３０４に等しい。したがって、ルートオブジェクト３０４の修正ビットは真に設定される。実行の第２段階において他の全てのデータ構造は不変である。

図７は実行の第４段階（egc.stop）におけるヒープ３５０を示す。この段階中に、いくつかのステップが行われる。第１のステップでは、その修正ビットが真に設定されている各ルートオブジェクトであって、これらのルーツだけにトレーシングルーチンが利用される。トレーシングルーチンはこのルートオブジェクトにより参照されるヒープ内の全オブジェクトを識別することができる。トレーシングルーチン中に特定のルートオブジェクトに対して識別された全てのオブジェクトを各ルートオブジェクトに関連付けられたリーチセット内に配置することができる。たとえば、ルートオブジェクト３０４に関連付けられた修正ビットは真に設定されるため、ルートオブジェクト３０４上のトレーシングルーチンが利用される。オブジェクト３５２はトレーシングルーチン内で識別されてリーチセット３１０内に配置される。好ましくは、オブジェクトは一時に一つのセット（リーチセット、ヒープセット、テンプセット）だけに含まれる。したがって、オブジェクト３５２への参照はテンプセット３２２から除去される。修正済とマークされた全ルートからのトレーシングがなされた後の第２ステップにおいて、テンプセット３２２内にまだ存在する全オブジェクトをメモリから除去することができる。典型的なケースでは、オブジェクト３５４が除去される。アルゴリズムの第３ステップはヒープセットを走査してルートコンテキストからオブジェクトが除去されているかどうか確認する。第３ステップはその修正ビットが真に設定されているルートオブジェクトがある場合だけ実施される。ヒープセットを走査する時に、オブジェクトがルート識別子を変化させておれば、それはメモリから除去することができる。たとえば、オブジェクト３２８は実行のこの段階中にヒープセット内にある。オブジェクト３２８はそのルート識別子にそのコンテキストを修正させているルートオブジェクトを参照させているため、ＥＧＣによりヒープから除去することができる。ヒープセット内の他方のオブジェクト、オブジェクト３２６（図６）、はそのルート識別子がルートオブジェクト３０２を参照しルートオブジェクト３０２はそのコンテキストを修正させていないため除去されない。この段階中の第４ステップはＥＧＣのヒープセットの形成からなっている。ヒープセットを形成するために、その修正ビットを真に設定しているルートオブジェクトの各リーチセットがヒープセット内側で併合される。したがって、ルートオブジェクトのリーチセットは空になる。

最後に、図８は実行の第５段階におけるヒープ３５０を示す。ルートオブジェクトは、好ましくは、ルートアレイ３００からクリアされる。ヒープセット内の全オブジェクトがヒープ３５０内にとどまる。ＥＧＣの任意の前のインスタンスがアクティブであった間オブジェクト３３０は生成されなかったため、オブジェクト３３０もヒープ３５０内にとどまる。他の全てのオブジェクトはヒープ３５０から除去される。全データ構造が初期状態となり、ＥＧＣはegc.start()が実行される時に再び活性化することができる。

当業者ならば前記開示を完全に理解すれば非常に多くの変更および修正が自明となる。特許請求の範囲にはこのような全ての変更および修正が含まれるものとする。
以上の説明に関して更に以下の項を開示する。

（１）．プロセッサと、プロセッサに接続されルートオブジェクトからの参照を有する一つ以上のオブジェクトを格納するメモリと、埋込ガーベジコレクションオブジェクトの状態を制御するアプリケーションプログラミングインターフェイスを含む電子システムであって、アプリケーションプログラミングインターフェイスはプログラムから呼び出され埋込ガーベジコレクションオブジェクトは制御データを使用して前記メモリからオブジェクトを除去させ、除去オブジェクトは埋込ガーベジコレクションオブジェクトがアクティブ状態である間に生成されかつルートオブジェクトからの参照がないオブジェクトを含む電子システム。

（２）．第１項に記載のシステムであって、埋込ガーベジコレクタの前記状態は初期化、アクティブ、またはイナクティブを含むシステム。

（３）．第２項に記載のシステムであって、制御データは各ルートオブジェクトに関連付けられた修正ビットを含み、修正ビットは埋込ガーベジコレクタがアクティブ状態である間にルートオブジェクトのコンテキストが修正されているかどうかを示し、さらに、テンプセットを含み、テンプセットは埋込ガーベジコレクションオブジェクトがアクティブ状態である間に生成されかつルートオブジェクトにより参照されていないオブジェクトを示すシステム。

（４）．第３項に記載のシステムであって、ルートオブジェクトに関連付けられた修正ビットはルートオブジェクトのコンテキストが変化している場合に真に設定されるシステム。

（５）．第３項に記載のシステムであって、ルートオブジェクトのコンテキストの修正はルートオブジェクトのコンテキスト内の参照の加算、変更、または除去を含むシステム。

（６）．第３項に記載のシステムであって、埋込ガーベジコレクションオブジェクトはそのコンテキストを変化させているルートオブジェクトをトレースし、そのコンテキストを変化させていないルートオブジェクトをトレースしないシステム。

（７）．第３項に記載のシステムであって、前記メモリから除去されるオブジェクトは、さらに、埋込ガーベジコレクションオブジェクトがアクティブ状態である時に割当てられしかも全修正ルートがトレースされている後でもテンプセット内に含まれるオブジェクトを含むシステム。

（８）．第３項に記載のシステムであって、埋込ガーベジコレクションオブジェクトはアプリケーションプログラミングインターフェイスを呼び出すプログラムと同じスレッドの内側で実行されるシステム。

（９）．第３項に記載のシステムであって、ルートオブジェクトはアプリケーションプログラミングインターフェイスを呼び出すプログラムにより生成され埋込ガーベジコレクションオブジェクトに通されるシステム。

（１０）．第３項に記載のシステムであって、さらに、埋込ガーベジコレクタがアクティブ状態である間に生成されないオブジェクトに対する付加ガーベジコレクションを含むシステム。

（１１）．埋込ガーベジコレクタを始動させるステップと、関連付けられたオブジェクトへの参照を有することができるルートオブジェクトを含むメモリから除去するオブジェクトを選択するステップと、選択されたオブジェクトを除去するステップと、を有するガーベジコレクション方法であって、除去するオブジェクトを選択するステップはコンテキストが変化しているルートオブジェクトを識別し、識別されたルートオブジェクトを参照されたオブジェクトにトレースしてコンテキストが変化しているルートオブジェクトにどのオブジェクトが関連付けられるかを決定するステップを含み、選択されたオブジェクトを除去するステップは埋込ガーベジコレクタがアクティブであった間に生成されしかもコンテキストが変化しているルートオブジェクトに関連付けられていると決定されなかったオブジェクトを除去するステップを含む方法。

（１２）．第１１項に記載の方法であって、埋込ガーベジコレクタが始動すると、各ルートオブジェクトに関連付けられた修正ビットをクリアし、次に前記ルートオブジェクトに関連付けられたコンテキストが変化している時にルートオブジェクトの修正ビットを設定する方法。

（１３）．第１１項に記載の方法であって、識別されたルートオブジェクトをトレースするステップはコンテキストが変化しているルートオブジェクトをトレースすることを含まない方法。

（１４）．プロセッサ、プロセッサに接続されたメモリ、および埋込ガーベジコレクションオブジェクトをアクティブとするアプリケーションプログラミングインターフェイスを含む電子システム。メモリは選択的にルートオブジェクトからの参照を有する一つ以上のオブジェクトを格納する。埋込ガーベジコレクションオブジェクトは、好ましくは、制御データを使用して前記メモリからオブジェクトを除去させ、除去オブジェクトは埋込ガーベジコレクションオブジェクトがアクティブである間に生成されしかもルートオブジェクトからの参照がないオブジェクトを含む。

電子システム内の典型的なヒープのブロック図である。 Ｊａｖａスタックマシン（“ＪＳＭ”）および主プロセッサユニット（“ＭＰＵ”）を含む本発明の好ましい実施例に従ったシステムを示す図である。 データ構造を含む本発明の好ましい実施例に従ったヒープのブロック図である。 ガーベジ実行の第１段階中の本発明の好ましい実施例に従ったヒープのブロック図である。 ガーベジ実行の第２段階中の本発明の好ましい実施例に従ったヒープのブロック図である。 ガーベジ実行の第３段階中の本発明の好ましい実施例に従ったヒープのブロック図である。 ガーベジ実行の第４段階中の本発明の好ましい実施例に従ったヒープのブロック図である。 ガーベジ実行の第５段階中の本発明の好ましい実施例に従ったヒープのブロック図である。

符号の説明

１００，３５０ ヒープ
１０２ ルート
１０４，１０６，１０８，１１０，３２６，３２８，３３０，３５２，３５４ オブジェクト
１１２，１１４ 参照
２００ システム
２０２ Ｊａｖａスタックマシン
２０４ 主プロセッサユニット
２０６ メモリ
２０８ Ｊａｖａ仮想マシン
２１０ コンパイラ
２１２ バイトコード
２１４ ディスプレイ
３００ ルートアレイ
３０２，３０４，３０６ ルートオブジェクト
３０８，３１０，３１２ リーチセット
３１４，３１６，３１８ 修正ビット
３２０ ヒープセット
３２２ テンプセット
３２４ ヒープオブジェクト
３３２，３３４，３３６，３６０，３６２，３６４ ルート識別子

Claims (2)

1. プロセッサと、
   プロセッサに接続されルートオブジェクトからの参照を有する一つ以上のオブジェクトを格納するメモリと、
   埋込ガーベジコレクションオブジェクトの状態を制御するアプリケーションプログラミングインターフェイスと、を含む電子システムであって、
   アプリケーションプログラミングインターフェイスはプログラムから呼び出され埋込ガーベジコレクションオブジェクトは制御データを使用して前記メモリからオブジェクトを除去させ、除去オブジェクトは埋込ガーベジコレクションオブジェクトがアクティブ状態である間に生成されかつルートオブジェクトからの参照がないオブジェクトを含む電子システム。
2. 埋込ガーベジコレクタを始動させるステップと、
   関連付けられたオブジェクトへの参照を有することができるルートオブジェクトを含むメモリから除去するオブジェクトを選択するステップと、
   選択されたオブジェクトを除去するステップと、を有するガーベジコレクション方法であって、
   除去するオブジェクトを選択するステップはコンテキストが変化しているルートオブジェクトを識別し、識別されたルートオブジェクトを参照されたオブジェクトにトレースしてコンテキストが変化しているルートオブジェクトにどのオブジェクトが関連付けられるかを決定するステップを含み、
   選択されたオブジェクトを除去するステップは埋込ガーベジコレクタがアクティブであった間に生成されしかもコンテキストが変化しているルートオブジェクトに関連付けられていると決定されなかったオブジェクトを除去するステップを含む方法。

Images