JP2004295889A - データ処理システム内での処理タスクの実行を制御する方法および装置 - Google Patents

Abstract

【課題】データ処理システム内での処理タスクの実行を制御する方法および装置を提供する。
【解決手段】データ処理システム内での処理タスクの実行は、データ記憶装置に対するメモリエリアの割当てを含むその処理タスクを実行し（段階１２０）、次に実行点において前記処理タスクの実際の実行経路を中断し（段階１３０）、メモリ管理を行うことにより制御される。そのメモリ管理は、実行のコースにおいて生じ、メモリエリアのそれぞれをポイントする基準値を指定する実行点における処理タスクによりアクセス可能である、１つまたはそれ以上のデータアイテムの識別（段階１４０）を含む。識別されたデータアイテムに対応する基準値と、与えられた実行点までの実行中に割当てられたメモリエリアと、の間の相関が決定される（段階１５０）。その相関に依存して、割当てられたメモリエリアに対するメモリ管理動作が行われる（段階１６０）。
【選択図】図１

Description

本発明は、コンピュータシステムにおけるメモリの再生利用プロセス、すなわち「ガーベジコレクション」に関する。

多くの現代のプログラム言語は、プログラマがメモリを動的に割当て、また再生利用することを可能とする。動的に割当てられた記憶装置は、ガーベジコレクションとして公知のプロセスを用い、コンピュータプログラムの実行中に、しばしば自動的に管理される。ガーベジコレクションを用いるプログラム言語の特定の例は、ジャバ（Ｒ）（Ｊａｖａ（Ｒ））である。ジャバ（Ｒ）は、オブジェクト指向プログラム言語である。オブジェクト指向プログラミングシステムにおいて、「クラス」は、そのクラスの特徴を有する「オブジェクト」（すなわち、データアイテム）の作成に用いるテンプレートを提供することができる。オブジェクトは、一般に、（ジャバ（Ｒ）においては、「新」オペレータと呼ばれるオペレータを用いて）プログラムの実行中に作成される。クラスに関連する方法は、一般に、同じクラスのオブジェクトに対する操作を行う。

ジャバ（Ｒ）のソースコードは、バイトコードとして公知の、ランタイムコードを生成するようにコンパイルされる。しかし、バイトコードは、現存のコンピュータの２進コードではない。むしろ、ジャバ（Ｒ）のバイトコードは、任意の特定のコンピュータ上において働くものと解釈できる、アーキテクチャ中立マシンコードである。ジャバ（Ｒ）プログラムは、ジャバ（Ｒ）仮想マシン（ＪＶＭ）と呼ばれるインタプリタプログラムを走らせることにより実行される。ＪＶＭは、バイトコードプログラムを読取って、それがインストールされているコンピュータの固有命令セットに対し、それを解釈または翻訳する。バイトコードは、ソースコードの再コンパイルの必要なしに、ＪＶＭがインストールされている任意のコンピュータプラットホーム上で走行する。「バイトコードの検査」と呼ばれるプロセスが、ジャバ（Ｒ）プログラムのリンキングの一部として、実行の前に用いられる。この検査プロセスは、バイトコードを、正しく形成されているジャバ（Ｒ）のクラスファイルを定めたルールのセットに確実に従わせる。例えば、クラスファイル内の方法が、２つの整数を、「ｉａｄｄ」（すなわち、整数加算）命令の実行の前にオペランドスタック上にプッシュしていることを、もし検査機が確認できなければ、検査機はそのクラスファイルを拒否する。

ジャバ（Ｒ）は、プロセスのマルチスレッド型の実行を可能とする。スレッド（「制御のスレッド」の省略形）は、プロセス内における実行のシーケンスである。スレッドは、自身のアドレス空間を持たないという点では簡単なプロセスであるが、それが実行されるプロセスのメモリその他のリソースは用いる。１つのプロセスには、いくつかのスレッドが存在し、ＪＶＭは、それらのスレッドを管理し、それらの実行のためのスケジュールを作る。スレッドは、単一のプログラム内において同時に実行される、いくつかの異なる機能の間のスイッチングを可能とする。ＪＶＭが、１つのスレッドの実行から他のスレッドへスイッチする時、同じアドレス空間内においてコンテキストスイッチが行われる。

ガーベジコレクションは、割当てられたメモリを明示的に解放するプログラマの負担を軽減し、メモリを間違って割当て解除する可能性を減少させることにより、プログラムの完全性の確保を助ける。しかし、ガーベジコレクションの潜在的な欠点は、もっと多くのメモリが必要な場合において、予測できない時に大量のガーベジコレクションが開始される可能性があることである。ジャバ（Ｒ）においては、この問題は、ガーベジコレクションがユーザコードにより並列に実行されることを可能にする、システムのマルチスレッド性により時には改善される。ガーベジコレクションのアルゴリズムは、２つの基本機能を行わなければならない。第１に、それは、いずれのオブジェクトがガーベジとして回収するのに適切であるかを決定しなければならず、第２に、それは、ガーベジオブジェクトにより用いられているメモリ空間を再生し、プログラムにより利用可能であるようにしなければならない。ガーベジとは、プログラムにとって、もはやアクセスできないメモリとして定義される。

このプロセスの第１の段階は、一般に、「ルート（ｒｏｏｔ）」のセットを定め、それらのルートからの到達可能性を決定することを行う。ルートを経て到達可能でないオブジェクトは、ガーベジであると考えられる。その理由は、プログラムがそれらにアクセスできないために、それらは、プログラムの実行の将来のコースに影響を与えることができないからである。

ＪＶＭにおいては、ルートのセットは、実施に依存するが、常にローカル変数内にオブジェクト基準を有する。ＪＶＭは、４つの基本成分、すなわち、レジスタと、スタックメモリと、ヒープメモリと、方法エリアと、を含む。全てのジャバ（Ｒ）のオブジェクトは、ヒープメモリ内に存在し、ガーベジが収集されるのはヒープメモリにおいてである。さまざまな記憶片が、特定の順序なしにヒープから割当てられ、またヒープへ返還される。ジャバ（Ｒ）における「新」オペレータを割当てられるメモリは、ヒープから与えられる。ヒープは、全てのスレッドにより共有される。方法エリアは、バイトコードが存在する場所である。方法エリア内のあるバイトをポイントする（すなわち、そのバイトのアドレスを含む）プログラムカウンタは、実行のスレッドの跡をたどるために用いられる。ジャバ（Ｒ）のスタックは、バイトコード命令に用いるパラメータおよびバイトコード命令の結果を記憶するため、パラメータを方法へ送りまたパラメータを方法から返還するため、また、それぞれの方法の呼出しの状態を保持するために用いられる。ＪＶＭは、わずかなレジスタしかもっていない。その理由は、バイトコード命令は、主としてスタック上において動作するからである。スタックは、後入れ先出し方式で動作するので、いわゆる後入れ先出し型のものである。方法の呼出しの状態は、その「スタックフレーム」と呼ばれる。制御のスレッド内において実行するそれぞれの方法は、スタックフレームを割当てる。方法が復帰した時は、スタックフレームは廃棄される。

要するに、ＪＶＭにおいては、全てのオブジェクトはヒープ上に存在し、ローカル変数はスタック上に存在し、実行のそれぞれのスレッドは自身のスタックを有する。それぞれのローカル変数は、整数、文字、または浮動小数点数のような、オブジェクト基準またはプリミティブタイプ（すなわち、非基準）である。従って、ルートは、ことごとくのスレッドのスタック上の、ことごとくのオブジェクト基準を含む。

多くの公知のガーベジコレクションのアルゴリズムが存在し、それらの中には、基準カウントガーベジコレクションアルゴリズム、マーク付けおよび掃出しガーベジコレクションアルゴリズム、および生成的ガーベジコレクションアルゴリズムが含まれる。これらの詳細および他のガーベジコレクションアルゴリズムは、１９９６年にジョン・ワイリ・アンド・サンズ（Ｊｏｈｎ Ｗｉｌｅｙ ＆ Ｓｏｎｓ）から発行された、リチャード・ジョーンズ（Ｒｉｃｈａｒｄ Ｊｏｎｅｓ）およびラファエルス・リンス（Ｒａｐｈａｅｌｓ Ｌｉｎｓ）著「ガーベジコレクション、自動的動的なメモリ管理のためのアルゴリズム（Ｇａｒｂａｇｅ Ｃｏｌｌｅｃｔｉｏｎ， Ａｌｇｏｒｉｔｈｍｓ ｆｏｒ Ａｕｔｏｍａｔｉｃ Ｄｙｎａｍｉｃ Ｍｅｍｏｒｙ Ｍａｎａｇｅｍｅｎｔ）」に説明されている。

ガーベジコレクションアルゴリズムは、スタックのような基準源における基準値をどのようにして識別し、その跡をたどるかという点で、精密（正確）であるか、または不精密（保存的）であるかの、いずれかに分類される。不精密なガーベジコレクタは、メモリの特定領域（例えば、スタックフレーム内のスロット）が基準を含んでいることがわかっても、その特定領域のどこに記憶されている与えられた値が基準であるかはわからない。従って、不精密なガーベジコレクタは、いずれの潜在的な基準オブジェクトをも存続させておかなければならない。この公知の技術の欠点は、もし変数値が偶然にメモリアドレスと一致すれば、プリミティブタイプが、不精密なガーベジコレクタにより基準として誤って識別されるかもしれないことである。これは、ガーベジオブジェクトが、不精密なコレクタにより、「生きている」ものと誤って考えられることを意味する。その理由は、オブジェクト基準によく似たもの（すなわち、プリミティブタイプ）かそれに関連しているからである。

一方、精密なガーベジコレクタは、純粋なオブジェクト基準と、基準のように見せかけているプリミティブタイプとを識別できる。従って、精密なガーベジコレクタは、オブジェクト基準によく似たものに相当するガーベジコレクションオブジェクトに対する、不精密なコレクタの失敗の問題を軽減する。精密なガーベジコレクションを行うためには、システムは、基準と非基準とを明確に識別できなければならない。オブジェクトにおいては、それぞれのオブジェクトに対し、そのオブジェクトのいずれのデータフィールドが基準を含んでいるかを記述する「レイアウトマップ」を生成することができる。このレイアウトマップは、オブジェクトの全存続期間の間不変であり、かつ同じタイプの全てのオブジェクトは、同じレイアウトマップを有するので、オブジェクトにおける基準識別は比較的に簡単である。しかし、スタックフレームのレイアウトは、その存続期間中に変化しやすいので、スタックフレームにおける基準識別プロセスは、もっと複雑である。例えば、与えられたスタックフレームスロットは、方法の開始時に初期化されなくてもよく、方法の１つのブロックに対しては整数を、また方法のもう１つのブロックに対しては基準を含むことができる。

現在、精密なガーベジコレクションを実施するために必要な情報を記憶する、２つの公知の方法が存在する。第１の方法は、バイトコードの検査段階中における一連のスタックマップの作成を含む。「スタックマップ」は、ガーベジコレクションが行われるそれぞれの実行点における、基準を含むスタックフレームスロットを示す、スタックフレームのちょうどよい時のスナップショットを表すデータ構造である。スタックマップは、ことごとくの検査された方法における複数の実行点のために記憶されなければならず、従って、この方法はランダムアクセスメモリ（ＲＡＭ）上で集中的に行われなければならない。

第２の方法は、検査されたバイトコードの実行中に、それぞれのスタックの書込み動作の跡をたどるステップと、基準が書込まれたそれぞれのスタックスロットにタグをつけるステップと、非基準値がそのスタック位置に書込まれた時にスタックタグをクリアするステップと、を含む。これは、スタックに書込まれた基準値および非基準値が、自己記述性のものであること、すなわち、それぞれの値が、その値が基準であるかどうかを表示するために用いられる１つまたはそれ以上のビットを有すること、を必要とする。タグデータ自身は、タグフィールドを含めるために、存在するスタックを広げることにより、または、並列スタックを保持することにより、記憶される。このスタックのタグ付けプロセスは、プログラムの実行を遅くする。その理由は、スタックおよび変数の双方が、スタックに書込まれたそれぞれの値に対し、基準または非基準としてマーク付けされなければならないからである。

従って、公知の方法よりも、メモリへの集中が少なく、プログラムに対する影響が少ない、精密なガーベジコレクションの方法を提供することが望ましい。

１つの特徴から見ると、本発明は、データ処理システム内における処理タスクの実行を制御する方法を提供し、その方法は、
データ記憶装置に対するメモリエリアの割当てを含む前記処理タスクを実行するステップと、
メモリ管理を行うために、実行点において前記処理タスクの実際の実行経路を中断するステップと、を含み、前記メモリ管理は、
実行のコースにおいて生じ、前記メモリエリアのそれぞれをポイントする基準値を指定する前記実行点における前記処理タスクによりアクセス可能である、１つまたはそれ以上のデータアイテムを識別するステップと、
識別されたデータアイテムに対応する基準値と、前記実行点までの前記実行中に割当てられたメモリエリアと、の間の相関を決定するステップと、
前記相関に依存して、割当てられたメモリエリアに対するメモリ管理動作を行うステップと、
を含む。

メモリ空間を有効に再生利用するためには、処理タスクによりアクセス可能であるいずれのデータアイテムが基準値であり、いずれのデータアイテムが非基準値であるかを、正確に識別する必要がある。公知のメモリ再生利用技術は、処理タスクの実行の前の検査段階において基準を識別するために必要な解析を行うか、または、データの書込み動作を連続的にモニタし、それぞれの書込まれたデータアイテムが基準値であるか否かをログする。本発明は、基準識別のプロセスが、処理タスクの実行の開始後（すなわち、検査後）に、必要に応じ、かつ必要になった時にのみ、基準識別を行うことにより、メモリへの集中が少なく、プロセッサへの集中が少ないようにされうることを認めた。本発明は、基準が、ガーベジコレクションが開始される実行点において動的に識別され、かつ前に記憶された情報に依拠しない技術を用いる。

基準値を指定するオペランドスタックデータアイテムを識別するプロセスは、現在の実行点までの全ての可能な実行経路を徹底的に探索して、実際の実行経路を見出すことにより行うことができた。本発明の実施例は、これが不必要であることを認識し、現在の実行点に至る任意の可能なデータ経路、例えば、最初に遭遇したデータ経路が、いずれのオペランドスタックエントリが基準に対応するかを識別するために用いられるように動作する。これは、経路発見アルゴリズムを促進し、しかもスタックスロットを含む基準が、命令の実行に関連する制約に従う任意のプログラム言語において、信頼性をもって識別されることを可能にする。

本発明の実施例により行われるメモリ管理動作は、例えば、タグ付け動作、コピー動作、または再割当て動作を含むことができることを認識すべきである。しかし、データアイテムがオペランドスタックのデータアイテムである実施例においては、メモリ管理動作は、基準値を指定する識別されたデータアイテムを介して直接または間接に処理タスクによりアクセス可能である、全てのメモリエリアへのマーク付けを含む。マーク付けされなかったメモリエリアは、次に、処理タスクのその後の実行における再割当てのために収集される。基準は、メモリ管理動作が行われる実行点において、必要に応じ、かつ必要になった時にのみ、識別されるので、そのような実施例は、公知のガーベジコレクションアルゴリズムよりも効率的なメモリ再生利用の機能性を提供する。

マーク付けされていないメモリエリアは、後のプログラミングタスクの実行中に直接再割当てされうるが、マーク付けされていないメモリエリアを再割当てのために解放する前に、それらのメモリエリアの圧縮を行うと、処理タスクが、メモリのより大きい隣接エリアを再割当てのために利用できるようになる利点が得られる。

基準を指定する処理タスクによりアクセスできるデータアイテムの識別において、それらのデータアイテムがローカル変数を表す場合、複数の可能な実行経路の１つに沿った基準に関連するローカル変数は、基準値として分類されうるが、その利用は不精密である。しかし、実施例においては、異なった実行経路に沿った、異なったデータタイプに関連するローカル変数（従って、不確定タイプのもの）は、プログラム命令および分類用変数を走査することにより、確定タイプのローカル変数から、マルチプルタイプとして識別され、従って非基準である。全てのその時可能な、現在の実行点までの実行経路は、それぞれのマルチプルタイプ変数に対して次々にシミュレートされ、それぞれの実行経路のためのそれぞれのプログラム命令におけるデータタイプが決定される。決定されたデータタイプは、次に、現在の実行点のためにチェックされ、このチェックの結果に依拠してメモリ管理動作が行われる。これは、現在の実行点において不確定タイプを有するマルチプルタイプ変数に関連するメモリエリアが、メモリ管理動作中に再割当ての効果的要求を受けられるという利点を有する。不確定タイプの変数の識別は、まずマルチプルタイプの変数を識別し、次にマルチプルタイプ変数として分類されたローカル変数の部分集合のみに対し完全なデータフロー解析を行うことにより、著しく簡単化される。

本発明は、メモリが動的に割当てられる、任意のコンピュータプログラミング言語に関連する処理タスクに適用可能であることを認識すべきである。しかし、実施例は、スモールトークまたはジャバ（Ｒ）のようなオブジェクト指向プログラム言語における処理タスクを行う。特に実施例は、ジャバ（Ｒ）における処理タスクを行う。有利なことに、ジャバ（Ｒ）仮想マシンの仕様は、プログラムコードが、ローカル変数またはオペランドスタック値のようないずれのデータアイテムが基準に対応するかを識別するために用いられるアルゴリズムを相当に簡単化するために直接利用できるルールに、従わなければならないことを意味する。

もう１つの特徴から見ると、本発明は、データ処理システム内における処理タスクの実行を制御する動作が可能なデータ処理装置を提供し、そのデータ処理装置は、
データ記憶装置に対するメモリエリアの割当てを含む前記処理タスクを実行する動作が可能な実行ロジックと、
メモリ管理を行うために、実行点において前記処理タスクの実際の実行経路を中断する動作が可能なタスク中断ロジックと、
実行のコースにおいて生じ、かつ前記メモリエリアのそれぞれをポイントする基準値を指定する前記実行点における前記処理タスクによりアクセス可能である、１つまたはそれ以上のデータアイテムを識別する動作が可能な基準識別ロジックと、
識別されたデータアイテムに対応する基準値と、前記実行点までの前記実行中に割当てられたメモリエリアと、の間の相関を決定する動作が可能な相関ロジックと、
前記相関に依存して、割当てられたメモリエリアに対するメモリ管理動作を行うよう操作可能なメモリ管理ロジックと、
を含む。

さらなる特徴から見ると、本発明は、コンピュータを制御してデータ処理システム内における処理タスクの実行を制御するコンピュータプログラムを有するコンピュータプログラム製品を提供し、そのコンピュータプログラムは、
データ記憶装置に対するメモリエリアの割当てを含む前記処理タスクを実行する動作が可能な実行コードと、
メモリ管理を行うために、実行点において前記処理タスクの実際の実行経路を中断する動作が可能な中断コードと、
実行のコースにおいて生じ、かつ前記メモリエリアのそれぞれをポイントする基準値を指定する前記実行点における前記処理タスクによりアクセス可能である、１つまたはそれ以上のデータアイテムを識別する動作が可能な基準識別コードと、
識別されたデータアイテムに対応する基準値と、前記実行点までの前記実行中に割当てられたメモリエリアと、の間の相関を決定する動作が可能な相関コードと、
前記相関に依存して、割当てられたメモリエリアに対するメモリ管理動作を行うよう操作可能なメモリ管理コードと、
を含む。

本発明の、上述の、またその他の、目的、特徴、および利点は、添付図面と関連して読まれるべき、以下の実施例の詳細な説明から明らかとなる。

図１は、本技術によるガーベジコレクションを概略的に示すフローダイアグラムである。このプロセスは、段階１１０において開始され、そこでは方法のバイトコード検査が行われる。この検査プロセスは、ジャバ（Ｒ）のバイトコードが、ＪＶＭ仕様のルールに従っていることを保証する。プロセスは次に段階１２０へ進み、そこでは本方法のバイトコードがＪＶＭ上で実行される。ヒープは、ＪＶＭの立上げの時に作成され、全てのクラスの具体化物（すなわち、オブジェクト）およびアレイは、実行中にヒープからメモリ割当てを受ける。段階１３０においては、全ての実行中の方法の実行が、ガーベジコレクションの目的のために中断される。この場合、ガーベジコレクションは、使い尽くされたヒープからのメモリ割当ての要求によりトリガされる。プロセスは段階１４０へ進み、そこでは、ガーベジコレクションの第１の段階が行われる。これは、プログラムのルートを形成する基準値に対応するデータ値の識別を含む。グローバル変数、ローカル変数（スタックフレーム上に記憶されている）、およびオブジェクトが、基準を求めて探索される。この段階において、ガーベジコレクションがトリガされた実行点に対応するスタックマップが、動的に作成される。これは、バイトコードの検査中に多数のスタックマップを作成し、メモリから現在の実行点に対して適切なスタックマップを検索する公知の方法とは異なる。基準値の識別は、「マーク付けおよび掃出し」アルゴリズムのマーク付けプロセスの初期段階に対応する。基準値が識別されると、プロセスは段階１５０へ進み、そこでは識別された基準値が、割当てられたヒープメモリエリアと相関されて、いずれのヒープオブジェクトがガーベジであるか確認される。段階１４０から１７０は、用いられている全ての方法に対し行われる。

図２は、相関プロセスを概略的に示す。図２は、ルートのセット２１０と、複数のメモリエリア２２２、２２６、２２８、２３０を含むヒープ空間２２０と、２つのスタックフレーム２６２、２６４を含むスタック２６０と、処理タスクのためのバイトコードを含むメモリエリア２５０と、を示す。

図２に示されているように、それぞれのジャバ（Ｒ）スタックフレームは、３つのセクション、すなわち、ローカル変数、実行環境、およびオペランドスタックを有する。それぞれの方法は、関連するスタックフレームを有することを想起すべきである。ローカル変数セクションは、現在の方法呼出しにより用いられている全てのローカル変数を含む。実行環境セクションは、スタック自身の動作を維持するために用いられる。オペランドスタックは、バイトコード命令により作業空間として用いられる。

プログラムが直接アクセスできる値は、プロセッサのレジスタに保持されているものと、プログラムスタック上に保持されているもの（ローカル変数および一時変数を含む）と、グローバル変数内に保持されているものと、である。計算のルート２１０は、（メモリアドレスに対するポインタまたはハンドルのような）ヒープ２２０のメモリエリアに対する基準を保持する直接アクセス可能な値である。整数のようなプリミティブタイプはルートではなく、基準のみがルートでありうることに注意すべきである。ルート２１０は、プログラムにとって常にアクセス可能であるオブジェクトを表す。ルートオブジェクト自身は基準フィールドを含むので、基準のチェーンをそれぞれのルートから形成することができる。オブジェクトは、もし別のライブオブジェクト内のフィールドがそれを基準とすれば、ライブであると考えられる。ルートを経て到達可能である全てのオブジェクトは、ライブであると考えられる。図２は、アルゴリズムがどのように、計算のルート２１０から出発し、それぞれのルートから基準のチェーンを走査し、ルートから到達可能なそれぞれのデータアイテムに、マークビット２２４をセットすることによりマーク付けするかを示す。このプロセスにおいて、ルートに関連する基準のチェーンを追跡するときに巡視されたそれぞれのデータは、ライブオブジェクトとしてマーク付けされる。例えば、オブジェクト２２２はルートにより基準とされ、オブジェクト２２２内のフィールドは、今度はオブジェクト２２６に対する基準を含む。従って、オブジェクト２２４および２２６は、それらがライブであることを示すマークビットを有し、従って、ガーベジコレクションのために用いることはできない。もしルートからのある基準の経路が存在し、その経路により実行中のプログラムがオブジェクトにアクセスできるならば、そのオブジェクトはルートから到達可能である。マーク付け相の終了は、すでにマーク付けされているデータアイテムから追跡されないことにより強要される。マーク付けされずに残っているデータアイテムは、ルートから到達可能ではなく、従って、ガーベジに違いない。データアイテム２２８は、データアイテム２３０に対する基準を含むが、これらのデータアイテムのいずれもルート２１０の１つを経て追跡可能ではなく、従って、それらはガーベジである。

ここで図１のフローチャートに帰る。プロセスのマーク付け相が完了し、ライブメモリエリアがガーベジから識別され終わると、プロセスは段階１６０へ進み、そこでは、メモリ管理動作が行われる。この場合は、段階１６０において「掃出し」動作が行われる。掃出し相においては、ガーベジコレクタはヒープメモリを掃出し、マーク付けされていないメモリエリアを、ヒープメモリの割当て可能な（自由な）プールへ返し、次のガーベジコレクションサイクルの準備として、アクティブセルのマークビットをクリアする。この段階において行われるさらなるメモリ管理タスクは、「圧縮」として公知のプロセスであり、これはヒープの断片化を防止するために用いられる。圧縮は、ライブオブジェクトを自由メモリ空間を経て、ヒープの一方の端部に向かって移動させることを含む。これは、ヒープの他端部に、隣接する自由メモリエリアを残す。圧縮中に、移動されたライブオブジェクトに対する全ての基準は更新されて、新しい位置に関連するものとされる。最後に、段階１７０において、方法は実行を再開し、新しく自由化されたヒープメモリは、実行中のプログラムにより再割当てのために使用可能となる。

本技術による方法が、公知の精密ガーベジコレクションと異なる点は、基準値が、ガーベジコレクションの開始される実行点における、ちょうどよい時のスナップショットに対応する別個のマップの動的作成により識別されることである。公知の精密なガーベジコレクションは、検査段階において複数のそのようなマップ（スタックマップ）を形成し、それらの全てはＲＡＭ内に保持されて、後にプログラムの実行中に用いられなければならない。この公知のアプローチには、かなりの冗長性がある。その理由は、実際に用いられる記憶されたスタックマップは、ガーベジコレクションがシステムにより開始される実行点に依存するからである。本技術は、基準フラグがオブジェクト自身内にセットされ、かつスタックがプログラム実行中のことごとくの書込み動作のためにマーク付けされる公知の技術とは異なる。特に、双方の技術において、基準は処理タスクの実行が開始された後に識別されるが、本技術によれば、基準は、ガーベジコレクションが開始される実行点において、必要に応じてのみ識別される。

本技術によるガーベジコレクションは、ルートおよびライブオブジェクトの、もっと信頼できる正確な識別に焦点を合わせている。これは、２つの異なった要素の解析であって、その一方の要素はオペランド（または表現）スタック内における基準の発見を含み、他方の要素は変数アレイ内における基準の発見およびマルチプルタイプ変数の識別を含む、前記解析を行うことにより達成される。次に、ここで、これら２つの要素のそれぞれを順番に考える。

図３は、オペランドスタック内において基準を見出すプロセスを概略的に示す。本技術によれば、（スタックマップに類似した）オペランドスタック基準テーブルが、ガーベジコレクションが開始される実行点において、検査後に動的に作成される。図４は、オペランドスタック基準テーブルを概略的に示す。図４には、隣接するメモリロケーションまたはスロットのブロックを含む論理スタック４１０が示されており、スタック基準テーブル４５０は、論理スタックを伴うビットベクトルであり、それは、いずれのスタックスロットが基準を含むかを指定する。この実施例においては、スタックは、連続メモリブロックを含むが、別の実施例においては、スタックは、不連続メモリロケーションを含む。スタックスロット４１２、４１４、４１６、４１８は、ビットベクトルロケーション４５２、４５４、４５６および４５８にそれぞれ対応する。それぞれのスタックスロットは、整数（ＩＮＴ）または浮動小数点数（ＦＬＯＡＴ）のようなプリミティブ値を記憶するため、または、ポインタのような基準（ＲＥＦ）を記憶するために用いられる。スタックスロット４１２および４１８は基準を含み、対応するビットベクトルロケーション４５２および４５８は、これを反映するために１にセットされたタグビットを有する。論理スタック４１０内の実際のデータは、基準を明確に識別しないが、ガーベジコレクションアルゴリズムは、ビットベクトルを検査して、いずれのスタックスロットが基準を含むかを決定することができる。この基準テーブル４５０の構成は、方法コードにより２パスの実行を行うことによって実現される。

本技術によるオペランドスタック解析は、以下の２つのルールを用い、これらのルールはジャバ（Ｒ）のためのＪＶＭ仕様に定められている。
Ｉ． 「それぞれの命令は、その呼出しに至る実行経路にかかわらず、オペランドスタックおよびローカル変数アレイ内のアーギュメントの適切なタイプおよび数によってのみ実行されなければならない。整数型の値を操作する命令はまた、ブール型、バイト型、文字型、およびショート（ｓｈｏｒｔ）型の値を操作することもできる。」
II． もし命令を、いくつかの異なる実行経路に沿って実行することができれば、オペランドスタックは、とる経路にかかわらず命令の実行の前に同じ深さをもたなければならない。」

基準テーブルは、ガーベジコレクションアルゴリズムの開始点において動的に作成されるので、現在の実行点に到着するためにたどられた実際の実行経路についての情報は得られない。もしか／ほかに、方法コードに分岐がある可能性により、複数の可能な実行経路を経て現在の実行点に到着できることは十分にありうる。一般に、与えられたスタックフレームスロットが、方法の実行における与えられた点に基準を含むかどうかは、現在の実行点に依存するのみでなく、その実行点に到着するためにたどられた制御経路にも依存する。例えば、１つの制御経路に沿っては、与えられたスタックフレームに整数値が割当てられ、一方、別の制御経路に沿っては、同じスタックスロットに基準が割当てられることができる。

しかし、ＪＶＭ仕様の上述の２つのルールを適用するとき、スタックのいずれのスロットが基準を含むかを識別するために、実際の実行経路を決定することは本質的に重要ではないことが推測できる。実際には、現在の実行点に至る複数の可能な実行経路のいずれかを見出し、必ずしも実際の実行経路ではないその見出された経路を用い、スタック基準テーブルを生成すれば十分である。実行経路は、現在の実行点に対応するゼロのバイトコードインデックスにおいて開始されなければならない。それぞれの可能な実行経路のためのスタック基準テーブル（そこでは、基準に対応するスタックスロットはタグを付けられている）は、ＪＶＭのルールＩおよびII（上記参照）が守られている限り、同じになるはずである。

ここで図３のフローチャートを参照すると、プロセスは段階３１０において開始され、そこでは、任意の制御経路が見出される。次に、段階３２０においては、この経路が現在のバイトコードインデックスに至るものであるかどうかが決定される。もし実行された経路を経て、現在の実行点に実際に到達するならば、プロセスは段階３３０へ進み、そうでなければ、フロー制御は段階３１０へ復帰し、そこでさらなる経路が見出される。段階３３０においては、識別された実行経路がたどられ、その経路に沿ってモニタ動作が行われる。特に、その経路に沿っての方法エリアのことごとくのバイトコードは、それがスタックを変更するかどうかを見るためにチェックされる。これにより、スタックの深さが追跡され、識別された実行経路に沿って、スタックによりどのような変数タイプがプッシュされポップされるかがモニタされる。段階３３０において作成されたスタック基準テーブルは、次の段階３４０において、マーク付けプロセスを完成するために用いられ、それにより、ルートから到達可能な全てのヒープメモリが明確に識別される。このようにして、段階３４０は、スタックスロット内に記憶されているメモリの基準値と、処理タスクによりメモリエリアを割当てられたヒープメモリ内のオブジェクトと、の相関を含む。段階３１０から３４０は、用いられている全ての方法に対して行われる。段階３４０において、ライブヒープメモリエリアが識別されると、プロセスは段階３５０へ進み、そこでは、ガーベジに対応する全ての相関していないヒープメモリエリアが、メモリ管理動作を受ける。このメモリ管理動作の結果、それらのヒープメモリエリアは、実行プログラムによる再割当てのために自由化される。

図５は、オペランドスタック内においてではなく、変数リスト内において基準を見出すプロセスを概略的に示すフローダイアグラムである。方法により用いられる変数は、アレイ内に記憶される。それらの変数は、静的（グローバル）変数、ローカル変数または方法のアーギュメントである。ＪＶＭは、変数アレイ内のそれぞれの変数が、基準または非基準値を記憶しているかどうかを決定する必要がある。方法のシグネチャは、それぞれのアーギュメントのタイプを指定し、これにより、アーギュメントはあらかじめタグ付けされることができる。しかし、ローカル変数は、初期化されていないとしてマーク付けされ、後にタグ付けされなければならない。

ある変数が不確定タイプのものでありうるという事実により、一定の変数を、基準または非基準として分類することには問題がある。この状況は、例えば、共通の実行点に至る少なくとも２つの異なる制御経路が存在し、変数が、１つの制御経路に沿っては整数値を割当てられるが、別の制御経路に沿っては基準値を割当てられる場合に生じうる。上記のルールＩによれば、それぞれの命令は、その命令の呼出しに至る実行経路にかかわらず、ローカル変数アレイ内の適切な数またはアーギュメントのタイプによってのみ実行されなければならない。現在の実行点において不確定タイプであるいずれのローカル変数も、当然の結果として基準とみなされないことになる。

原理的には、与えられた変数が、方法の１つのブロックにおいては非基準として用いられるが、同じ方法の別のブロックにおいては基準値として用いられることは可能である。これは、プログラム実行のそれぞれのステップにおけるそれぞれの変数のタイプを追跡しつつ行われる、全ての制御経路を経てのステップバイステップの解析が必要であることを示唆する。しかし、本技術は、変数のマルチプルタイプの使用が実際には比較的に稀であり、例えば、変数の５％がマルチプルタイプであることを認めている。マルチプルタイプを有する方法変数の一部が少ない事実は、２段階の変数解析を行うことにより利用される。この変数解析の第１の段階は、いずれの変数がマルチプルタイプ変数として識別可能であるかを決定するための、方法の全てのバイトコードの１パス走査を含む。この変数解析の第２の段階は、第１の段階においてマルチプルタイプであるとして識別された小さい割合の変数に対してのみ、完全なデータフロー解析を行うことを含み、好ましくは、一時に１つの変数をチェックする。

図５のフローチャートを参照すると、変数に対する基準識別プロセスは段階５１０において開始され、そこでは、それぞれのローカル変数のために、方法の完全なバイトコードが走査される。与えられたローカル変数において、記憶命令により影響されるそれぞれの変数に関連するデータタイプはログされる。それぞれの可能なデータタイプに、１つのタグビットが割当てられる。この段階の終了時には、方法の変数の総数に等しいサイズの変数アレイが存在する。それぞれの変数に対し、このアレイは、完全な方法の実行中のある点における、その変数に関連する全てのデータタイプを示すデータフィールドを有する。プロセスは次に段階５２０へ進み、そこでは、段階５１０のタグビットが、マルチプルタイプの変数と、公知のタイプの変数とを、識別するために用いられる。段階５３０においては、それぞれのマルチプルタイプ変数に対し、完全なデータフロー解析が行われる。この完全なデータフロー解析は、それぞれのマルチプルタイプ変数のためのバイトコードを通る全ての可能な実行経路の追跡と、それぞれのバイトコードにおける変数のデータタイプのロギングとを含む。従って、この段階の終了時には、それぞれのマルチプルタイプ変数のための方法におけるバイトコードの数と同じ長さのアレイが存在する。プロセスは次に段階５４０へ進み、そこでは、ガーベジコレクションアルゴリズムが、現在の実行点のバイトコード番号に対応するそれぞれのマルチプルタイプ変数アレイエントリをチェックして、現在の実行点におけるマルチプルタイプ変数の実際のデータタイプを確立する。段階５４０において、現在の実行点におけるデータタイプが確立されると、プロセスは次に段階５５０へ進み、そこでは、メモリ管理動作が行われる。もし現在の実行点ＥＰにおいて、マルチプルタイプ変数が基準値であることが見出されたとすれば、それはライブであるとしてマーク付けされる。しかし、もしマルチプルタイプ変数が公知のタイプであるが、非基準であることが見出されたとすれば、それは無視される。同様にして、もしマルチプルタイプ変数が、現在の実行点において不確定データタイプのものであることが見出されたとすれば、それは無視される。マーク付けプロセスの第１の段階である段階５５０に続く、ガーベジコレクションのその後の諸段階は、従来の技術を用いて行われる。段階５１０から５５０は、用いられている全ての方法に対し行われる。段階５３０から５５０は、それぞれの識別された可能なマルチプルタイプ変数に対し行われる。

図６は、本技術による、変数のための基準識別プロセスの３つの段階を概略的に示す。このプロセスの第１の段階は、方法エリア６１０内の全てのバイトコードの走査と、それぞれのローカル変数のための、それぞれの関連した記憶命令のロギングとを含む。このロギングプロセスの結果は、変数テーブル６２０として編集され、このテーブルは、本例の目的のために、ローカル変数ＶＡＲ１、ＶＡＲ２、ＶＡＲ３およびＶＡＲ４のそれぞれをリストし、また、基準（ＲＥＦ）、整数（ＩＮＴ）および浮動小数点（ＦＬＴ）である可能なデータタイプのそれぞれのためのタグビットを有する。

プロセスの第２の段階は、それぞれのローカル変数のために、変数テーブル６２０内にセットされた、ビット数の検査を含む。変数テーブル６２０から、ＶＡＲ１、ＶＡＲ３およびＶＡＲ４は、それぞれ公知のタイプＩＮＴ、ＲＥＦおよびＦＬＴであることがわかる。これら３つの変数のそれぞれは、方法の全てのバイトコード６１０のための単一のデータタイプに関連している。しかし、ＶＡＲ２は、基準および整数の双方としてフラグ付けされており、従って、マルチプルタイプ（または、不確定タイプ）の変数として識別される。

プロセスの第３の段階は、方法エリア６１０内に存在するバイトコードと同じ数の要素を有する、マルチプルタイプ変数ＶＡＲ２のためのアレイ６３０の作成を含む。ＶＡＲ２のために完全なデータフロー解析が行われ、それぞれのバイトコードにおけるＶＡＲ２の可能な変数タイプが決定される。この場合には、考慮しなければならないバイトコード＃４において、現在の実行点ＥＰへの２つの可能な経路が存在する。経路１上においては、ＶＡＲ２は、バイトコード＃０ないしバイトコード＃４からの整数値を有し、一方、経路２上においては、ＶＡＲ２は、バイトコード＃１およびバイトコード＃２に対しては初期化されていないが、バイトコード＃３およびバイトコード＃４に対しては基準値をとる。従って、ＶＡＲ２アレイ６３０は、バイトコード＃１および＃２においては、（整数に対応する）エントリＩを有するが、バイトコード＃３および＃４においてはエントリＭ（マルチプルタイプ）を有する。ＶＡＲ２は、現在の実行点において、経路１上には整数値を有し、経路２上には基準値を有するので、それは不確定タイプのものであり、従って、ライブオブジェクトとしてマーク付けされることはない。

本技術による、変数アレイ内における基準の識別方法は、現在の実行点において不確定タイプを有する変数が誤ってライブオブジェクトとしてマーク付けされることを防止するという利点を有する。すなわち、本技術は、精密なガーベジコレクションを効果的に提供する。

ジャバ（Ｒ）仮想マシンの仕様は、「オブジェクトのためのヒープ記憶装置は、自動記憶管理システムにより再生利用される」と述べている。ＪＶＭは、特定のタイプの自動記憶管理システムを仮定してはおらず、記憶管理技術は実施者のシステム要求に従って選択できる。しかし、（サン（Ｒ）（Ｓｕｎ^RTM）およびマイクロソフト（Ｒ）（Ｍｉｃｒｏｓｏｆｔ^RTM）によるもののような）ジャバ（Ｒ）の全ての普及した実施は、ガーベジコレクションを用いている。

特定のオプションによりジャバ（Ｒ）を開始することによってガーベジコレクションをターンオフすることは可能であるが、ガーベジコレクションは、一般にＪＶＭにより自動的に実行される。もしガーベジコレクションが、長期にわたって走るプログラムにおいてターンオフされれば、そのプログラムは、実行が完了する前にメモリの枯渇により障害を起こす可能性がある。ＪＶＭは、一般にユーザに対し、ガーベジコレクションの方法を明示的に呼出すオプションを提供するので、ガーベジコレクションは、ユーザにより指定されたコード実行の任意の点において行われうる。

図７は、上述の技術を実施するために用いられるタイプの汎用コンピュータ７００を示す。汎用コンピュータ７００は、中央処理装置７０２と、ランダムアクセスメモリ７０４と、読取り専用メモリ７０６と、ネットワークインタフェースカード７０８と、ハードディスクドライブ７１０と、ディスプレイドライバ７１２と、モニタ７１４と、キーボード７１８およびマウス７２０を有するユーザ入出力回路７１６と、を含み、これらは全て共通バス７２２により接続されている。動作の際には、中央処理装置７０２は、ランダムアクセスメモリ７０４、読取り専用メモリ７０６およびハードディスクドライブ７１０の１つまたはそれ以上に記憶されている、または、ネットワークインタフェースカード７０８を経て動的にダウンロードされた、コンピュータプログラム命令を実行する。行われた処理の結果は、ディスプレイドライバ７１２およびモニタ７１４により、ユーザに対しディスプレイされる。汎用コンピュータ７００の動作を制御するためのユーザ入力は、キーボード７１８またはマウス７２０から、ユーザ入出力回路７１６を経て受け取られる。コンピュータプログラムは、さまざまな異なるコンピュータ言語で書けることを認識すべきである。コンピュータプログラムは、記録媒体上に記憶されて分配されるか、または、汎用コンピュータ７００へ動的にダウンロードされる。適切なコンピュータプログラムの制御下で動作する時、汎用コンピュータ７００は、上述の技術を行うことができ、また上述の技術を行う装置を形成すると考えることができる。汎用コンピュータ７００のアーキテクチャは、かなりさまざまでありえ（例えば、ハンドヘルドゲームコンピュータ、モバイルコンピュータ、パーソナルディジタルアシスタント、など）、図７は単に１つの例に過ぎない。

ここでは本発明の特定の実施例を説明したが、本発明はこれに制限されるわけではなく、本発明の範囲内において多くの改変および追加を行えることは明らかである。例えば、本発明の範囲から逸脱することなく、以下の従属請求項の特徴のさまざまな組み合わせを、独立請求項の特徴を用いて行うことができる。

本技術によるガーベジコレクションを概略的に示すフローダイアグラムである。（実施例１） どのように識別された基準値がヒープメモリと相関されて、ライブオブジェクトにマーク付けが行われるかを概略的に示す。 オペランドスタック内において基準を見出すプロセスを概略的に示すフローダイアグラムである。 オペランドスタック基準テーブルのフォーマットを概略的に示す。 変数リスト内において基準を見出すプロセスを概略的に示すフローダイアグラムである。 図５のフローチャートに対応する変数のための基準識別のプロセスの３つの段階を概略的に示す。 本技術を実施するために用いられるタイプの汎用コンピュータを概略的に示す。

符号の説明

２２０ ヒープ空間
２２２ メモリエリア
２２６ メモリエリア
２２８ メモリエリア
２５０ メモリエリア

Claims (30)

1. データ処理システム内における処理タスクの実行を制御する方法において、前記方法は、
   データ記憶装置に対するメモリエリアの割当てを含む前記処理タスクを実行するステップと、
   メモリ管理を行うために、実行点において前記処理タスクの実際の実行経路を中断するステップと、を含み、前記メモリ管理は、
   実行のコースにおいて生じ、かつ前記メモリエリアのそれぞれをポイントする基準値を指定する前記実行点における前記処理タスクによりアクセス可能である、１つまたはそれ以上のデータアイテムを識別するステップと、
   識別されたデータアイテムに対応する基準値と、前記実行点までの前記実行中に割当てられたメモリエリアと、の間の相関を決定するステップと、
   前記相関に依存して、割当てられたメモリエリアに対するメモリ管理動作を行うステップと、
   を含む、前記方法。
2. 前記１つまたはそれ以上のデータアイテムのそれぞれはオペランドである、請求項１記載の方法。
3. 前記識別するステップは、
   前記実行点に至る可能な実行経路を識別するステップであって、前記可能な実行経路は前記実際の実行経路とは異なるかもしれない、前記ステップと、
   前記可能な実行経路のシミュレートされた実行を行うステップと、を含み、
   前記処理タスクにとってアクセス可能である前記１つまたはそれ以上のデータアイテムは、前記現在の実行点への前記可能な実行経路をたどることにより識別される、
   請求項２記載の方法。
4. 前記メモリ管理動作は、前記識別されたデータアイテムを介して直接または間接に前記処理タスクによりアクセス可能である、全ての前記メモリエリアへのマーク付けと、前記処理タスクの後の実行中における再割当てのための、マーク付けされていないメモリエリアの収集と、を含む、請求項３記載の方法。
5. 前記メモリ管理動作は、前記マーク付けされていないメモリエリアの、再割当ての前における圧縮を含む、請求項４記載の方法。
6. 前記１つまたはそれ以上のデータアイテムのそれぞれはローカル変数である、請求項１記載の方法。
7. 前記識別するステップは、
   前記処理タスクに対応する複数のプログラム命令を走査し、前記１つまたはそれ以上のデータアイテムのそれぞれに対応するそれぞれの記憶命令のためのデータタイプをログするステップと、
   もしそれぞれのデータアイテムに対する異なる記憶命令のために異なるデータタイプがログされたならば、前記１つまたはそれ以上のデータアイテムの少なくとも１つをマルチプルタイプ変数として分類するステップと、
   マルチプルタイプ変数として分類された前記１つまたはそれ以上のデータアイテムのそれぞれのために、前記実行点までの全ての可能な実行経路をシミュレートし、前記可能な実行経路のそれぞれのための前記複数のプログラム命令のそれぞれにおいて、それぞれのマルチプルタイプ変数に関連するデータタイプを決定するステップと、
   前記現在の実行点に対応する前記複数のプログラム命令の１つにおいて、前記マルチプルタイプ変数のそれぞれにおける前記決定されたデータタイプをチェックするステップと、を含み、
   前記メモリ管理動作は、前記決定されたデータタイプをチェックする前記ステップの結果に依存して行われる、
   請求項６記載の方法。
8. 前記メモリ管理動作は、もし前記決定されたデータタイプが前記現在の実行点における前記可能な実行経路の異なるものに対し異なるならば、前記データアイテムに、再割当てのために適切であるとしてタグ付けすることを含む、請求項７記載の方法。
9. 前記処理タスクは、オブジェクト指向プログラム言語で書かれたコンピュータプログラムの成分である、請求項１記載の方法。
10. 前記オブジェクト指向プログラム言語はジャバ（Ｒ）である、請求項９記載の方法。
11. コンピュータを制御してデータ処理システム内における処理タスクの実行を制御するコンピュータプログラムを有するコンピュータプログラム製品において、前記コンピュータプログラムは、
    データ記憶装置に対するメモリエリアの割当てを含む前記処理タスクを実行する動作が可能な実行コードと、
    メモリ管理を行うために、実行点において前記処理タスクの実際の実行経路を中断する動作が可能な中断コードと、
    実行のコースにおいて生じ、かつ前記メモリエリアのそれぞれをポイントする基準値を指定する前記実行点における前記処理タスクによりアクセス可能である、１つまたはそれ以上のデータアイテムを識別する動作が可能な基準識別コードと、
    識別されたデータアイテムに対応する基準値と、前記実行点までの前記実行中に割当てられたメモリエリアと、の間の相関を決定する動作が可能な相関コードと、
    前記相関に依存して、割当てられたメモリエリアに対するメモリ管理動作を行うよう操作可能なメモリ管理コードと、
    を含む、前記コンピュータプログラム製品。
12. 前記１つまたはそれ以上のデータアイテムのそれぞれはオペランドである、請求項１１記載のコンピュータプログラム製品。
13. 前記基準識別コードは、
    前記実行点に至る可能な実行経路を識別する動作が可能な経路識別コードであって、前記可能な実行経路は前記実際の実行経路とは異なるかもしれない、前記経路識別コードと、
    前記可能な実行経路のシミュレートされた実行を行う動作が可能な経路シミュレーションコードと、を含み、
    前記処理タスクにとってアクセス可能である前記１つまたはそれ以上のデータアイテムは、前記現在の実行点への前記可能な実行経路をたどることにより識別される、
    請求項１２記載のコンピュータプログラム製品。
14. 前記メモリ管理コードは、前記識別されたデータアイテムを介して直接または間接に前記処理タスクによりアクセス可能である、全ての前記メモリエリアにマーク付けし、また、前記処理タスクの後の実行中における再割当てのための、マーク付けされていないメモリエリアを収集する動作が可能である、請求項１３記載のコンピュータプログラム製品。
15. 前記メモリ管理コードは、前記マーク付けされていないメモリエリアを、再割当ての前に圧縮する動作が可能である、請求項１４記載のコンピュータプログラム製品。
16. 前記１つまたはそれ以上のデータアイテムのそれぞれはローカル変数である、請求項１１記載のコンピュータプログラム製品。
17. 前記基準識別コードは、
    前記処理タスクに対応する複数のプログラム命令を走査し、前記１つまたはそれ以上のデータアイテムのそれぞれに対応するそれぞれの記憶命令のためのデータタイプをログする走査コードと、
    もしそれぞれのデータアイテムに対する異なる記憶命令のために異なるデータタイプがログされたならば、前記１つまたはそれ以上のデータアイテムの少なくとも１つをマルチプルタイプ変数として分類する動作が可能な分類コードと、
    マルチプルタイプ変数として分類された前記１つまたはそれ以上のデータアイテムのそれぞれのために、前記実行点までの全ての可能な実行経路をシミュレートし、前記可能な実行経路のそれぞれのための前記複数のプログラム命令のそれぞれにおいて、それぞれのマルチプルタイプ変数に関連するデータタイプを決定する動作が可能な経路シミュレーションコードと、
    前記現在の実行点に対応する前記複数のプログラム命令の１つにおいて、前記マルチプルタイプ変数のそれぞれにおける前記決定されたデータタイプをチェックする動作が可能なデータタイプチェックコードと、を含み、
    前記メモリ管理コードは、前記メモリ管理動作を、前記データタイプチェックコードの結果に依存して行うよう操作可能である、
    請求項１６記載のコンピュータプログラム製品。
18. 前記メモリ管理コードは、もし前記決定されたデータタイプが前記現在の実行点における前記可能な実行経路の異なるものに対し異なるならば、前記データアイテムに、再割当てのために適切であるとしてタグ付けする動作が可能である、請求項１７記載のコンピュータプログラム製品。
19. 前記処理タスクは、オブジェクト指向プログラム言語で書かれたコンピュータプログラムの成分である、請求項１１記載のコンピュータプログラム製品。
20. 前記オブジェクト指向プログラム言語はジャバ（Ｒ）である、請求項１９記載のコンピュータプログラム製品。
21. データ処理システム内における処理タスクの実行を制御する動作が可能なデータ処理装置において、前記データ処理装置は、
    データ記憶装置に対するメモリエリアの割当てを含む前記処理タスクを実行する動作が可能な実行ロジックと、
    メモリ管理を行うために、実行点において前記処理タスクの実際の実行経路を中断する動作が可能なタスク中断ロジックと、
    実行のコースにおいて生じ、かつ前記メモリエリアのそれぞれをポイントする基準値を指定する前記実行点における前記処理タスクによりアクセス可能である、１つまたはそれ以上のデータアイテムを識別する動作が可能な基準識別ロジックと、
    識別されたデータアイテムに対応する基準値と、前記実行点までの前記実行中に割当てられたメモリエリアと、の間の相関を決定する動作が可能な相関ロジックと、
    前記相関に依存して、割当てられたメモリエリアに対するメモリ管理動作を行うよう操作可能なメモリ管理ロジックと、
    を含む前記データ処理装置。
22. 前記１つまたはそれ以上のデータアイテムのそれぞれはオペランドである、請求項２１記載のデータ処理装置。
23. 前記基準識別ロジックは、
    前記実行点に至る可能な実行経路を識別する動作が可能な経路識別ロジックであって、前記可能な実行経路は前記実際の実行経路とは異なるかもしれない、前記経路識別ロジックと、
    前記可能な実行経路のシミュレートされた実行を行う動作が可能な経路シミュレーションロジックと、を含み、
    前記処理タスクにとってアクセス可能である前記１つまたはそれ以上のデータアイテムは、前記現在の実行点への前記可能な実行経路をたどることにより識別される、
    請求項２２記載のデータ処理装置。
24. 前記メモリ管理ロジックは、前記識別されたデータアイテムを介して直接または間接に前記処理タスクによりアクセス可能である、全ての前記メモリエリアにマーク付けし、また、前記処理タスクの後の実行中における再割当てのための、マーク付けされていないメモリエリアを収集する動作が可能である、請求項２３記載のデータ処理装置。
25. 前記メモリ管理ロジックは、前記マーク付けされていないメモリエリアを、再割当ての前に圧縮する動作が可能である、請求項２４記載のデータ処理装置。
26. 前記１つまたはそれ以上のデータアイテムのそれぞれはローカル変数である、請求項２１記載のデータ処理装置。
27. 前記基準識別ロジックは、
    前記処理タスクに対応する複数のプログラム命令を走査し、前記１つまたはそれ以上のデータアイテムのそれぞれに対応するそれぞれの記憶命令のためのデータタイプをログする走査ロジックと、
    もしそれぞれのデータアイテムに対する異なる記憶命令のために異なるデータタイプがログされたならば、前記１つまたはそれ以上のデータアイテムの少なくとも１つをマルチプルタイプ変数として分類する動作が可能な分類ロジックと、
    マルチプルタイプ変数として分類された前記１つまたはそれ以上のデータアイテムのそれぞれのために、前記実行点までの全ての可能な実行経路をシミュレートし、前記可能な実行経路のそれぞれのための前記複数のプログラム命令のそれぞれにおいて、それぞれのマルチプルタイプ変数に関連するデータタイプを決定する動作が可能な経路シミュレーションロジックと、
    前記現在の実行点に対応する前記複数のプログラム命令の１つにおいて、前記マルチプルタイプ変数のそれぞれにおける前記決定されたデータタイプをチェックする動作が可能なデータタイプチェックロジックと、を含み、
    前記メモリ管理ロジックは、前記メモリ管理動作を、前記決定されたデータタイプのチェックの結果に依存して行うよう操作可能である、
    請求項２６記載のデータ処理装置。
28. 前記メモリ管理ロジックは、もし前記決定されたデータタイプが前記現在の実行点における前記可能な実行経路の異なるものに対し異なるならば、前記データアイテムに、再割当てのために適切であるとしてタグ付けする動作が可能である、請求項２７記載のデータ処理装置。
29. 前記処理タスクは、オブジェクト指向プログラム言語で書かれたコンピュータプログラムの成分である、請求項２１記載のデータ処理装置。
30. 前記オブジェクト指向プログラム言語はジャバ（Ｒ）である、請求項２９記載のデータ処理装置。

Images