JP2010267291A - コンピュータ・システム、コンピュータ読取り可能な記憶媒体および同媒体を動作させる方法、およびコンピュータ・システムを動作させる方法 - Google Patents

Abstract

【課題】要求される断片のみをコンパイルするので、コンパイルが更に効率的に行われる。また、システムのメモリは、ほとんど実行されないコードのコンパイルされたバージョンで満たす必要がない。
【解決手段】方法がファイナルであると仮定する第１のクラスへの呼出しをコンパイリング・システムによりコンパイルするステップと、第２のクラスの出現を決定し、そしてさらに第２のクラスが第１のクラスの方法のインスタンスを含むか否かを決定するステップと、第２のクラスにおける方法のインスタンスが第１のクラスの方法をオーバーライドしているか否かを決定するステップと、第２のクラスにおける方法のインスタンスが第１のクラスの方法をオーバーライドしているか否かのさらなる決定に応答して第１のクラスの方法の前記コンパイルされたコードを変更するステップと、変更されたコンパイルされたコードに従って前記コンピュータ・システムを動作するステップとを含む。
【選択図】図９Ａ

Description

本発明は、大半の一般的特質において、コンピュータ・システムおよびこのシステムを動作する方法に関し、およびかかるシステム内部の種々の動作の性能における改善に関する。本発明はまた、コンピュータ読取可能な記憶媒体にも関する。コンピュータ・システムは、仮想マシンであり、あるいはこれを含み、あるいはその一部であり得る。コンピュータ読取可能な媒体は、コンピュータ・システム／仮想マシンをプログラミングするための実行可能なコードあるいは他の命令を含み得る。

最近の数年間で、オブジェクト指向言語として知られたものに向かうプログラミング言語における発展があった。最近の発展において、各々がオブジェクトに関する１組のデータあるいは属性、ならびにファンクションすなわちサブルーチンである、オブジェクトとそのデータについて実施することができるいわゆる「方法」に関する情報をみずから保持する「オブジェクト」としての概念が認められる。これは、コンピューティングおよび（または）プログラミングの当業者にはよく知られている。

コンピュータの出現およびその普及および利用可能性における急激な進展は、ＩＢＭ−ＤＯＳあるいはＭＳ−ＤＯＳあるいはＭＳ−Ｗｉｎｄｏｗｓ（登録商標）の諸アプリケーションを走らせるＩＢＭのＰＣおよびＩＢＭ互換ＰＣ、独自のアップル・システムを走らせるアップルのマシン、あるいは独自のユニックス・オペレーティング・システムを走らせる種々のユニックス・マシンのような異なる形式のシステムの自主的な開発をもたらした。独立的なシステムの急増は、１つのフォーマットのみで利用可能であり、かつアプリケーションが意図されなかったマシン上では走ることができない有効なアプリケーションをもたらした。
このような状況の下では、プログラマは、「外部」アプリケーションが、ユーザに関するかぎり、エミュレーションが見えないような方法で良好に走らせることができるように、ホスト・コンピュータのオペレーティング・システムを「エミュレート」するソフトウエアを創り出した。換言すれば、ユーザは、自分がしていることを知ることなく、例えばユニックス・ベースのオペレーティング・システムを用いてウインドウズ・ベースのアプリケーションの正常なファンクションの全てをユニックス・マシン上で実施することができる。

このような種類の特に有名な製品は、連合王国（英国）のＨｉｇｈ Ｗｙｃｏｍｂｅおよび米合衆国カルフォルニァ州Ｓａｎｔａ ＣｌａｒａのＩｎｓｉｇｎｉａ Ｓｏｌｕｔｉｏｎｓにより開発され、「Ｐｏｗｅｒｍａｃ用ＳｏｆｔＷｉｎｄｏｗｓ（登録商標） ２．０」なる名称で知られる製品である。このようなソフトウエアは、物理的なマッキントッシュ・コンピュータが、Ｉｎｔｅｌの８０４８６ＤＸプロセッサおよび８０４８７数学演算用コプロセッサにメモリ、２台のハード・ディスク、ＩＢＭスタイルのキーボード、カラー・ディスプレイおよびＰＣタイプのコンピュータの最近のバージョンに通常見出される他の特徴を備えたＰＣをエミュレートすることを可能にする。
更にまた、相互に自由に開発されオペレーティング・システムとプロトコル間の非互換性をもたらしたコンピュータのような簡単な電子装置、通信および制御システムに対する消費者による増加の一途をたどる需要が存在する。例えば、ビデオ・プレーヤ、テープ・プレーヤおよびＣＤプレーヤに対するリモート・コントロール装置は、「再生」、「前送り」、「逆送り」、「休止」などが共通する似たようなファンクションを持つが、ユーザにより操作されるリモート・コントロールすなわちコマンダ間の送信コードは、同じ製造者により作られた異なる種類の装置間、あるいは異なる製造者により作られた同じ種類の装置間では互換性がない。例えば、装置において使用される特定のハードウエアのいかんを問わない「再生」コマンドに基く正しい「再生」コードを生じ得る装置内のソフトウエアを備えるという明らかな利益が存在しよう。このようなソフトウエアは、「仮想マシン」として一般に知られる。

他の用途および応用は無数にあり、例えば、テレビジョンの送信、家庭用のリモート機器、車搭載用ナビゲーション・システム、およびいわゆる「パーソナル・ディジタル・アシスタント」のデコード用セットトップボックスである。例えば、自動車電話は、サービス・プロバイダからダウンロードされるシステムのアップグレードを受けることができる。
エミュレーション・ソフトウエア・パッケージは、とりわけ汎用ではなく専用のものであるという幾つかの特徴が共通する傾向がある。これらのパッケージは、急激な開発地域において最も利益があり、製造者がコストを節減することを可能にするという明白な利点を有する。特に、これらパッケージは、物理的なマシンからソフトウエアを分離することができ、すなわち、ソフトウエアの作用の変更を実現するのにマシンの固有ソフトウエアに立入ることを必要とすることなく、エミュレート・ソフトウエアによって物理的マシンにおけるソフトウエアの作用を変えることができる。

先に述べた実現の一部において用いられる特定のオブジェクト指向言語は、ジャバ（Ｊａｖａ；Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ社の登録商標）として知られる言語である。下記の実現の一部は、改善された性能および（または）低減したメモリ容量のゆえに、現在可能なより小型の装置においてジャバを用いることを可能にする。組込まれるソフトウエアに対して計画される将来の用途（仮想マシン）は、身に着けられるコンピュータ、事務機器、家庭用機器、およびインテリジェントな家屋および自動車を含む。
仮想マシン、特にオブジェクト指向言語を用いるマシンの使用における余裕および利点があることは認められるが、システム内で行われる動作の一部を最適化することが重要でありかつ有利である領域が当然のこととして存在する。これらは、メモリ要求を減らし、動作速度を増し、別のシステムに組込まれるときシステムの「透過」を改善することを含む。本文に述べる本発明の主たる目的の１つは、メモリの制約内でできるだけ迅速に、例えば１０、５、２Ｍバイト、更には１Ｍバイト以下で動作するよう最適化される仮想マシンを提供することである。このような制約は、例えば、コスト（またはサイズ）が主な制約となる簡単な電子装置その他の装備に適用されがちである。
適切な場合に、純粋に事例として、（上記の改善を略図的に示す）添付図面が参照される。
図１は仮想マシンの一定の構成要素を示す。

全般的考察
仮想マシンの望ましい実施の形態の特定例について、図１に関して次に記述する。
仮想マシン２０は、機器２２の特定アイテムに組込まれる実行可能なコードである。このマシンは、ハードウエアおよびオペレーティング・システムからある程度の独立性を提供することができる。仮想マシンは、典型的に、下記の特徴のどれか、一部あるいは全てを含み得る。すなわち、オペレーティング・エンジン、ルーチンのライブラリ、１つ以上のインタプリタ、１つ以上のコンパイラ、複数の命令シーケンスを記憶する記憶手段、キュー管理手段、およびバッファ管理手段である。

仮想マシンは、一方（「ハイレベル」側）では１つ以上のアプリケーション２４に結合され、他方（「ローレベル」側）ではおそらくは種々の中間的な論理ユニットを介して機器のアイテムのハードウエア２６へ結合される。ハードウエアは、種々のポートすなわちインターフェース２８（おそらくは、ユーザ入力を受入れるためのインターフェース）を含むものと見なすことができ、仮想マシンはこれらポートすなわちインターフェースからイベントを受取る。ハードウエアはまた、１つ以上のプロセッサ／制御手段３０およびメモリ３２を含む。
参照事項１−コンピュータ・システム、コンピュータ読取可能な記憶媒体およびこの媒体を動作させる方法、および前記システムを動作させる方法
本発明は、コンピュータ・システムに関し、かつコンピュータ・システムを動作させる方法に関する。特に、本発明は、実行のためのコードをコンパイルするコンパイラを含むコンピュータ・システムに関する。望ましい実施の形態において、本発明は、ドミナント・パスのダイナミック・コンパイル法に関する。
本発明は、望ましくは、ランタイムのコンパイル技術によるオブジェクト指向言語のランタイム表示の最適化に関し、かつ望ましくは、ランタイムのコンパイル技術によるオブジェクト指向言語のランタイム表示の最適化に関する。本発明の特質は、仮想マシン、特にジャバ仮想マシンの最適化された実行に関するものである。

本発明は、特に、トレース・スケジューリング、最適化コンパイラ、ダイナミック・コンパイル、プロファイルで案内される最適化、ジャスト・インタイム・コンパイラ、およびジャバＶＭ仕様に関するものである。
例えばジャバ言語を用いる一部のアプリケーションにおいて、コードは、インタプリタを用いる直接的に解釈される。インタプリタは、実行中にコードを翻訳し、これによりコードの解釈は非常に遅くなり得る。従って、このような実行は一般に解釈より非常に速いので、コンパイルされたコードの実行が選好される。
標準的なコンパイラは、アプリケーションの全てのコードを翻訳して、実行のためのコードの完全なコンパイル・ランタイム解釈を行う。このような標準的なコンパイルは、特にコンパイル・コードの最適化が要求される場合に時間を要し、通常はコードの実行前にオフラインで行われる。
ジャスト・インタイム（ＪＩＴ）・コンパイラは、コードのオンラインのコンパイルを行う。例えば、コードの実行時に最初に１つの方法に遭遇するとき、ＪＩＴコンパイラを用いると、実行は停止され、ＪＩＴコンパイラはこの方法全体をコンパイルして可能なかぎり最適化する。このように、ＪＩＴコンパイラは、使用されそうにない方法の部分を含む方法全体をコンパイルする。このようなコンパイルは、コンパイルにおける時間を浪費し、コードのコンパイルされたバージョンがメモリにおけるスペースを費やす。このため、メモリ使用の最小化が重要である場合に、組込まれるアプリケーションに対する特定の問題を生じ得る。
一般に、コンピュータ言語のランタイム表示のコンパイラ、特にいわゆるジャスト・インタイム（ＪＩＴ）・コンパイラは、方法全体の表示を一時にコンパイルするか、あるいは比較的大きなユニット（例えば、一時に１ファイルあるいは多くのクラスの１つ）の表示をコンパイルする。アプリケーションの大きな部分は、しばしば例外的な状況の取扱い、すなわちほとんど実行されないコードの取扱いに関する。典型的に、コンパイラは、コンパイルが完了するまでアプリケーションの更なる進行を阻害する。

従って、従来のコンパイル法は、ほとんど実行されないコードをコンパイルする時間を費消し、コンパイルされた結果は、ほとんど実行されないコードが存在しない場合には必要でなかったスペースを占有する。最適化の機会は、ほとんど実行されないコードによる制御パスに対応しなければならないことよりしばしば減殺される。
アプリケーションの前の実行からのプロファイル入力を用いるオフライン・コンパイラは、しばしば、アプリケーションの頻繁に実行されるパスの最適化が可能であり、後者の問題を軽減する。しかし、これらのコンパイラは、アプリケーションによる各パスのコンパイルを依然として行わねばならず、アプリケーションがプロファイルの実行について異なる挙動を呈するときは容易に応答することができない。
ＪＩＴコンパイラにおいては、方法に対する「呼出し」命令に遭遇するとき、制御がＪＩＴコンパイラへ送られ、この方法が前にコンパイルされなかったならば、コンパイルされたバージョンが生成される。コンパイルされたバージョンは、次に、方法の以降の実行に対して使用される。ＪＩＴコンパイラに利用可能な予定メモリがいったん使用されると、新たな方法のコンパイルは可能でなく、ＪＩＴコンパイラの使用は停止する。その後見出された方法が解釈され、これにより非コンパイルコードの以降の実行速度を低下させる。

コンパイラに利用可能なメモリ量は、使用されるコンピュータ・システムに応じて変化する。コンパイラに割当てられた全メモリは、要求される内部データ構造を構築するためおよびレジスタの割当てのためにコンパイラに割当てられるコード・バッファ・スペースを含んでいる。このメモリは、通常はコンパイルに先立ちコンパイラのため保留されている。
ＪＩＴコンパイラは、多量のメモリを備えるデスクトップ・コンピュータ・システムにおいて使用されるように設計された。コンパイラへ割当てられるメモリは一般に、実際にコンパイラに利用可能なバッファ・スペース量が制限されないほど大きい。
しかし、組込みシステムの場合は、コンパイラへ割当てられるメモリ量は、７０ないし８０Ｋであろう。このことは、明らかに、コンパイルされるコード量に制約を課す。

要約すれば、当該出願に記述される本発明は、下記特徴のいずれか、あるいは一部、あるいは全てを何らかの組合わせで含んでいる。すなわち、
１．方法全体ではなく主パスに対するコードの断片をコンパイルする
２．実行履歴を用いて、アプリケーションを介するどのパスが主パスであるかを判定する
３．フォールバック・インタプリタを用いて、あまり頻繁に実行されないコードを解釈する
４．アプリケーションの実行時にコードを要求と同時にコンパイルできるオンライン・コンパイルを備える。システムは、優先順位が適用される別のスレッドとして走る
５．コードの新たな断片を実行状態のマルチスレッド型システムへ組込む能力を備える
６．実行状態のマルチスレッド型システムからコード断片を除去することを支援する
７．システム実行中にダイナミック・コンパイラにより使用されるメモリ量をいつでも制限する。

本願に記述される本発明は、とりわけ、オンライン・コンパイルの性能上のインパクトを低減し、アプリケーションを介する主パスに対して最適化されるコードを生成し、時間およびメモリの制限内でコードの良好な最適化を可能にし、ほとんど実行されないコンパイルされたコードの格納オーバーヘッドを低減し、マルチスレッド型コンピュータ・システムにおけるアプリケーションの応答性を高め、コンパイラ自身により使用されるメモリ量を低減することを目的とする。
本発明によれば、アプリケーションのコードをコンパイルするためのコンパイラを含むコンピュータ・システムが提供され、このコンパイラはコードの断片をコンパイルするように構成される。
方法全体ではなくコードの断片のみをコンパイルすることにより、それほど必要でない断片はコンパイルしないままにしながら、コードの最も望ましいセクションのみをコンパイルすることが可能になる。
このような方法により、要求される断片のみをコンパイルするので、コンパイルが更に効率的に行われる。また、システムのメモリは、ほとんど実行されないコードのコンパイルされたバージョンで満たす必要がない。
コードの断片に対する参照が行われる場合、方法全体より少ないセクションを表わすコードの一部を参照することが望ましい。コードの断片は、コードの１つ以上のブロックを含むことが望ましい。コードのコンパイルの最小単位がブロックであることが望ましい。

本発明の特に望ましい特徴は、コードの断片がコードの主パスの断片であることである。
主パスの断片が、関連コードを介する望ましい実行ルートを表わす多数のブロックからなる断片を含むことが理解されよう。例えば、コードのセクションが条件付き分岐を介する場合、分岐によるコードの反復実行時に、分岐を介する１つのパスは分岐を介する別のパス上で選好されやすい。分岐を介する選好ルートと関連するコードの断片は、主パスの断片であると見なされることが望ましい。
以下に示すように、ある場合には、分岐を介する別のそれほど選好されないルートもまた、主パスであり得る。
本発明の望ましい実施の形態においては、コードの主パスの断片は、頻繁に実行されるコードを含む。主パスは、頻繁でなく実行されるコードは含まないことが望ましい。このような頻繁でなく実行されるコードは、例えば、頻繁でなく遭遇する例外を処理するためのコードを含む。

主パスのみをコンパイルすることにより、本発明の望ましい実施の形態似よれば、ほとんど実行されないコンパイルされたコードを格納する格納オーバーヘッドを最小限に抑えることができる。更に、主パスの実行を最適化するため最適化手法を用いることができ、これにより主パスのコードの実行速度を増大する。更に、コンパイラは、ほとんど実行されないコードのコンパイルにオンラインで時間を浪費する必要がなく、従ってシステムにおける全実行速度を改善することができる。
本発明の望ましい実施の形態においては、コードの断片が予め定めた回数より多く実行されるならば、このコードの断片は主パスの一部であると見なされる。
コンピュータ・システムは、コードの断片が実行される、望ましくは解釈される回数を記録するための実行履歴レコーダを更に含むことが望ましい。
実行履歴レコーダは、コードのブロックが解釈される回数を記録することが望ましい。
本発明の望ましい実施の形態において、ならびに特定のブロックが何回解釈されたかの記録において、実行履歴レコーダはまた、ブロックの実行に関する更なる情報、例えばブロックに対する制御の転送がどこからきたか、また制御がブロックからどこへ移転されたかについても記録する。当該レコーダはまた、どのタイプのコードがブロックにおいて実行されたかをも記録する。
閾値に等しいかあるいはこれより大きい回数だけ解釈された断片は、コンパイルが可能であることが望ましい。この閾値は、２．５、更には１０より大きいかこれに等しいことが望ましい。
このように、頻繁に実行されるコードのブロックがコンパイルされる。実行されないブロックがコンパイルされることは一般に望ましくない。本発明の望ましい実施の形態においては、実行されないブロックがコンパイルされることはない。

システムは更にコンパイラ・マネージャを含み、コードの断片が閾値の回数だけ解釈されたとき、実行履歴レコーダがコンパイラ・マネージャへ警報するように構成されることが望ましい。本発明の望ましい実施の形態においては、コンパイラ・マネージャが、コンパイルのため頻繁に実行されたブロックのキューを管理する。このキューは、比較的頻繁に実行されたブロックのみがコンパイラによるコンパイルのためのキューから選択されるように管理されることが望ましい。
前記閾値は、動的に同調されることが可能であることが望ましい。コンパイル・マネージャがキューを管理する上例の場合は、このキューが恒久的に長ければ、閾値は、コンパイルのためのキューへ少ない数のブロックが送られるように増加されることが望ましい。
実行履歴レコーダは、アプリケーションの実行中に記録するよう構成されることが非常に望ましい。実行履歴については、システムによるアプリケーションの特定の実行のための主パスの表示が決定されコンパイルされたコードを生成するため用いられるように、オンラインで集められることが望ましい。代替例においては、主パスに関する情報が前の実行から捕捉されるときは、条件が前の実行から変更されてしまい前の実行の主パスがその時の実行の主パスの表示ではないというリスクがある。更にまた、主パスは、実行中に変化することがある。
当該システムは更にアプリケーションの変化を解釈するためのインタプリタを含み、実行履歴レコーダがコードの断片の解釈を記録するように構成されていることが望ましい。インタプリタにとっては、実行履歴の記録を管理することがより効率的である。コードのコンパイルされる断片の実行の記録が実施可能なことは判るが、多くの場合、そのために要求される時間とメモリに関してその値打ちがないと考えられる。
実行履歴レコーダは、第１の部分から第２の部分に対する実行のパスを記録するように構成されることが更に望ましい。望ましくは、第１のブロックから第２のブロックへの実行パスが記録される。望ましい実施の形態においては、実行履歴レコーダは、制御が特定のブロックから移転されたこのブロックの実行のために記録する。このため、特定のブロックに対しては、後続する可能性が最も大きいブロックを決定することができる。このように、特定のブロックからの主パスを決定することができる。この特定ブロックが閾値の回数だけ通りかつコンパイルされるならば、後続する確率が最も高いブロックを通る前記特定ブロックからの主パスをコンパイルすることができる。
このように、コンパイラは、あるパスの断片をコンパイルするように構成されることが望ましい。

当該システムは、全てのコードが実行された断片のみがコンパイル可能であるように構成されることが望ましい。コードのあるセクションは、つねにコンパイルに適するとは限らない。このコードのセクションが実行されなかったならば、実行されなかった部分はコンパイルには適さない「隠れた」コードを含むかもしれない。このような実行されなかったコードのコンパイルは、本発明の望ましい実施の形態においては回避される。
本発明の実施の形態においては、コードのあるブロックが制御転送の全ての過程で実行されなかったならば、このブロックはコンパイルには適さない。その結果、シンボリックな解決法が依然として要求されることになり、インタプリタで実現することに終始する。
主パスのコンパイル・バージョンは、システムの残部に対して唯一の外部からのエントリ点となることが望ましい。従って、コードのコンパイルにおいては仮定がなされる。このため、コンパイラは、唯一の外部からのエントリ点を持つコンパイルされる部分を生じるように構成されることが望ましい。
コードの断片がコンパイルされる場合、コンパイラはコンパイルされるコードを最適化が可能であることが望ましい。このような最適化はインライン処理を含むことになろう。コンパイルされるコードが最適化された場合、特に後で正しくないことが判るか制約が大きすぎるコードを最適化するときに仮定がなされた場合、コンパイルされるコードは特定の最適化あるいは仮定がなされたことを表示するマーカと関連付けられることが望ましい。
本発明の望ましい実施の形態においては、おそらくは種々の仮定を用いて、主パスに対する特に有効なコンパイルされたコードを生じるために、幾つかの最適化が行われる。

当該システムは、フォールバック・インタプリタを含むことが望ましい。このフォールバック・インタプリタは、コードのコンパイル・バージョンが得られるときには用いられず、コンパイル・バージョンが得られず、あるいは例外が生じ、あるいは実行中は仮定が誤りであることを証明するときに用いられることが望ましい。
当該システムは、インタプリタと、コードの実行時にコードの少なくとも第１の部分がコンパイルされたコードから実行されるコンパイルされたコードの少なくとも１つの部分と、インタプリタによりコンパイルされないコードから実行されるコードの少なくとも第２の部分とを含むことが望ましい。当該システムはフォールバック・インタプリタを使用することが望ましい。
このような特徴は、特に重要であり、かつ独立的に提供されよう。このため、本発明の更なる特質は、インタプリタを含み、アプリケーションのコードを更に含むコンピュータ・システムを提供し、コードはコンパイルされるコードの少なくとも１つの部分を含み、これにおいてはコードの実行時に、コードの少なくとも第１の部分がコンパイルされるコードから実行され、かつコードの少なくとも第２の部分がインタプリタにより実行される。
当該インタプリタは、コードのコンパイルされないバージョンが利用可能でない場合か、あるいは、例えばコードのコンパイルにおいてなされる仮定が正しくないことが判る場合に用いることができる。このため、あらゆる場合に使用が「安全」でないおそれがある最適化コードを生じる更に積極的な最適化が可能となる。コンパイルされたバージョンが使用に安全でないケースが認められる場合、フォールバック・インタプリタは、実行に対して甚しい破壊を生じることなく、かつコードの一部の新たなコンパイル・バージョンが生成される間に実行を止める必要もなく、必要なコードの実行を完了することができる。
当該システムは更に、コードの断片のコンパイルされたバージョンがあるかどうかを判定する探索装置を含むことが望ましい。このように、得られるコンパイルされたコードの一部をインタプリタが解釈するときに時間が費やされる可能性が低減される。コンパイラは、オンラインでコンパイルが可能であることが望ましい。このため、コンパイラは、実行中に現われることがある新たな主パスの部分に対してコンパイルされたバージョンを生成することが可能である。
望ましいシステムにおいては、このシステムはマルチスレッド型である。コンパイラは、コードを実行中であるスレッドとは別のスレッド上で走ることが望ましい。

当該コンパイラは、それ自体により、かつコンパイルされた断片により使用されるメモリを制限することができることが望ましい。このため、コンパイラは、コンパイルにより使用されるメモリを制限するためコンパイラにより強化されるメモリ管理ポリシーを有することが望ましい。このことは、メモリが制限される仮想マシンにおいて特に重要である。当該システムはまた、コンパイルされたコードの削除のための削除装置をも含むことが望ましい。このため、新たなコンパイルされるコードに対してメモリを解放するため、それほど頻繁に使用されないコードのコンパイルされたバージョンを削除することが可能である。
本発明は、特に埋込みシステムにおける仮想マシンに対する特定の用途を見出すものである。本発明は、コンパイルされたコードを実行しコードを解釈する選択が存在するシステムにおける一般的用途をも有することが判る。本発明は、特にメモリ制限を持つシステムにおける使用に供される。
本発明はまた、コンピュータ・システムにおけるコードのコンパイルのためのコンパイラを提供し、このコンパイラはコードの断片のコンパイルのため構成される。このコンパイラは、コードの主パスの一部のコンパイルのため構成されることが望ましい。
従って、本発明は、コードの主パス（あるいは、主に近いパス）の一部のみがコンパイルされるアプリケーションのオペレーティング・コードをコンパイルするためのコンパイラを含むコンピュータ・システムを提供する。
当該技術は、性能を強化しかつコンパイルされたスペースを低減するという主要な利点供することができる。この技術は、小さなメモリ用途にとって重要であり、かつメモリ・サイズ、コンパイル時間、および性能間の兼ね合いの混交を含んでいる。
望ましい形態においては、前記技術は、グローバルなデータ・フロー分析のオーバーヘッドもなくループおよびインライン処理に係わる主要な最適化技術の使用をも可能にし、従ってコンパイラ自体がグローバルなデータ・フロー分析は行わないコンパイラよりはるかに速く実行することを可能にする。コンパイラ自体のメモリ使用もまたはるかに低くなる。
先に述べたシステムにおいては、有利なことに、残りのパスが解釈される間にコードを介する全てのパスではなく、実行する主パスのみがコンパイルされる。
オペレーティング・コードがコンパイルされているその実行中の部分であるとき、コードの実行が進行中に主パスがつねに変化しているという意味においてコンパイラがオンラインで動作することは、特に望ましい特徴である。
本発明は更に、コードの断片がコンパイルされるアプリケーションのコードをコンパイルするためのコンパイラを含むコンピュータ・システムを動作させる方法を提供する。
コードの断片が実行される回数は、実行履歴レコーダにより記録されることが望ましい。
望ましい実施の形態においては、システムが更にコンパイラ・マネージャを含み、コードの断片が閾値の回数だけ実行されたとき実行履歴レコーダがコンパイラ・マネージャに警報し、望ましくは実行履歴レコーダがアプリケーションの実行中に記録する。

本発明は、更なる特質において、インタプリタを含み、更にアプリケーションのコードを含むコンピュータ・システムを動作させる方法を提供し、当該コードはコンパイルされたコードの少なくとも１つの部分を含んでおり、当該方法は、コンパイルされたコードからのコードの少なくとも第１の部分を実行し、インタプリタを用いて当該コードの少なくとも第２の部分を実行することを含んでいる。
コンパイラはオンラインでコンパイルすることが望ましい。望ましくはコンパイラに利用可能なメモリが制限され、かつ望ましくは当該方法がコンパイルされたコードを削除するステップを含む。
また、本発明によれば、アプリケーションのオペレーティング・コードをコンパイルするためのコンパイラを含むコンピュータ・システムを動作させる方法が提供され、当該方法はコードの主パスの一部のみをコンパイルすることを含む。
当該方法は、性能を強化し、かつコンピュータ・システムのコンパイルされたスペース要求およびコンパイラ自体のメモリ・スペース要求を低減する。
有利なことに、主パスを識別する情報は、コードの実行履歴から提供される。この実行履歴情報は、プログラムが実行するとき動的に取得されることが望ましい。実行履歴情報は、コードの前の実行から捕捉されることが望ましい。
望ましい実施の形態においては、頻繁には実行されないコードがフォールバック・インタプリタにおいて解釈され、これにより頻繁に実行されないコードに対するコンパイルされたコードを必要とすることなくコードの実行が継続し得ることが望ましい。
有利なことに、アプリケーション／プログラムが実行するとき即時応答してコードをコンパイルすることができ、これにより新たな頻繁に実行されるパスの発生に即応してコンパイル情報を生成可能であるオンラインのコンパイル・システムが提供される。
コンピュータ・システムがマルチスレッド型システムにおいて動作するとき、新たなコード断片がこのマルチスレッド型システムへ組込まれることが望ましく、これにより実行スレッドを止めることなく平滑な動作を達成することが望ましい。
本発明は更に、アプリケーションのオペレーティング・コードをコンパイルするためのコンパイラを含むコンピュータ・システムを動作させる方法を提供し、当該方法はコードの主パス部分のみをコンパイルすることを含んでいる。
当該方法は、コードの断片をコンパイルすることを含み、かつ望ましくはコードの主パス断片をコンパイルすることを含んでいる。
本発明はまた、頻繁に実行されないコードを実行するためフォールバック・インタプリタを使用することをも提供する。
本発明により更に提供されるのはコンピュータ・システムに対するコードであり、このコードは前述の方法により生じるコンパイルされたコードを含んでいる。
本発明の特質のいずれか、あるいは一部、あるいはその全ては、他のいかなる特質にも適用することができる。
適当な場合に、純粋に事例として、（上記の改善を略図的に示す）添付図面が参照される。
以降の考察は、先に述べた本発明のいずれかおよび全ての発明に適用する。

仮想マシンの幾つかの構成要素を示す。 実行のパスを示す図である。 主パスをコンパイルする比較コストを示す図である。 ディスパッチ・テーブルを示す図である。 本発明を実施するための装置を示す概略図である。 コードを介する実行のパスを示す図である。 本発明の方法を実施するための装置を示す図である。 例外を含むコードの断片を示す図である。 本発明によるコードのコンパイルされた断片を示す図である。 コンパイル前のコードの一部を示す図である。 図Ｆ０９／０１のコードの標準的コンパイルを示す図である。 望ましい実施の形態によるコードのコンパイルを示す図である。 コード・バッファを示す図である。 コンピュータ・システムにおけるメモリ構成を示す図である。 本発明の方法を実施する装置を示す図である。 オブジェクト指向プログラムにおける階層的構造を示す図である。 ディスパッチ・テーブルに格納されたデータの構成を示す図である。 ディスパッチ・テーブルに対するインターフェース・ハッシュ・テーブルの適用を示す図である。 家庭用の装備システムの階層的構造を示す図である。 図Ｄの家庭用システムにおける諸装置の動作に用いられるディスパッチ・テーブルを示す図である。 図Ｄの家庭用システムにおける装置を動作させるためのドライバ装置におけるコントローラ・プログラムを示す図である。ｐ スタックにおけるデータ記憶を示す概略図である。 起動スタックを示す図である。 フレームにおける参照についての検査を示す図である。 手順呼出しフレームにおけるデータの構成を示す図である。 手順の実行を示す図である。 バリアの記述子ブロックの内容の構成を示す図である。 仮想マシンの原理を示す図である。 エミュレータ・スタックの動作を示す図である。 統合化されたスタックの動作を示す図である。 本発明の実施の一形態を示す図である。 本発明の装置の実施の形態を示す図である。 従来技術の手法に従うメモリの分割を示す図である。 別の従来技術の手法を示す図である。 いわゆる「並行な」環境におけるオブジェクトの構成を示す図である。 不要部分の整理作業のトレーシングを示す図である。 オブジェクトの構造を示す図である。 空のスタックを示す図である。 本発明による個々のパケットの構造を示す図である。 本発明の全般的動作を示す図である。 割込みを処理するためのＰＣコンピュータ・システムの各部を示す図である。 実施の一形態における割込みの処理におけるステップを示す図である。 割込みハンドラのコードを示す図である。 割込みハンドラのコードを示す図である。 実施の一形態を実施する装置を示す図である。 望ましい実施の形態を示すフロー図である。 コンパイル・コードの１つの部分を示す図である。 コンパイル・コードの異なる部分を示す図である。 望ましい実施の形態を実施する装置を示す図である。 リンク・リストを示す図である。 ループ状のリンク・リストを示す図である。 ループ状のリンク・リストにおけるポインタの移動を示す図である。 装置の望ましい実施の形態を示す図である。 実施の一形態のコード・バッファ形態を示す図である。 実施の一形態のコード断片を示す図である。 コンパイル・コードにおけるパッチの使用を示すフロー図である。 コンパイル・コードにおけるパッチの使用を示すフロー図である。 コンパイル・コードにおけるパッチの使用を示すフロー図である。 コンパイル・コードにおけるパッチの使用を示すフロー図である。 方法の望ましい実施の形態を示すフロー図である。 潜在的にポリモルフィックな方法によるパッチの使用を示す図である。 装置の望ましい実施の形態を示すブロック図である。

１．方法全体ではなく主パスに対するコードの断片のコンパイル
望ましい実施の形態の概要は、下記のとおりである。
コンパイラは、入力として、ソース・プログラムのランタイム表示と、（以下に述べるにように取得される）実行履歴情報とを受取る。この実行履歴情報は、ライブであり（すなわち、プログラムが実行すると共に動的に変化し）、あるいはプログラムの前の実行から捕捉することができる。
実行履歴情報は、プログラム・ソースのランタイム表示から決定される構造的情報と組合わされ、コンパイラがコンパイルすべきプログラムの主パスであるものを確定する。実行されないコードは、主パスに決して含まれないことが望ましい。
コンパイラは、主パスをスーパブロック断片として取扱い、プログラム・ソースでなくても、コードを逐次レイアウトする。主パスにフォールスルー（ｆａｌｌ−ｔｈｒｏｕｇｈ）させるのに必要な場合に、分岐およびテストが調整される。主パスが終りまで追従されるという仮定により、コードおよびレジスタが最適化される。このことは、最近のプロセッサ・アーキテクチャにおける性能を改善する。厳密に見れば、主パスのみが、１つの外部エントリ点を呈する。このことは、最適化を著しく簡素化し強化する。
図１Ａに示されるように、実行のパスが主パス外である場合、適切なランタイム・テストが、「アウトライア」１００２と呼ばれるいくつかのスタブ・コードに対する順方向分岐１０００において挿入される。このアウトライア・スタブは、断片から制御を転送する前に、主パスがまだ書き戻されない任意の状態を更新する。主パスの主ライン・コードは、１００２に示されるようなアウトライア・スタブのように、一般に一体に保持される。このことは、最近のプロセッサ、特に分岐予測ソフトウエア／ハードウエアが最初に分岐が起こりそうもないと仮定する場合における性能を改善する。これはまた、良好な命令キャッシュの挙動を提供する。
実行されないの主パスのコンパイルは、多くの最適化に要求される分析を簡素化しながら、ループの最適化およびインライン処理を実施させる。これは、コンパイラがシンボリック参照を解かねばならない必要を不要にする。このことは、フォールバック・インタプリタに残される。
例えば、フィールドに対する新たなクラスのシンボリック参照のローディングが用いられるとき、従ってはじめて参照が見えるとき、シンボリック参照を満たすクラスの階層をロードすることが必要となる。本発明の望ましい実施の形態において、全ての関連するコードが少なくとも１回解釈された場合は、シンボリック参照は、コードがコンパイルされる前にすでに解かれている。

あるグローバルな状態が変化した後に、しばしばループの間に例外が認められる必要がある。例外の検査はループ外で早期に行うことができ、コードをフォールバック・インタプリタへ強制することによりループから検査を除外させ、これら例外の存在時にコードの移動を行わせる。
フォールバック・インタプリタは、ループを実行して、比較的ゆっくりではあるが適時に例外を認識することになる。例外はほとんど生じないと見なされ、従って最適化ループの利益は短所を上回ることになる。
コードのコンパイル時に、種々の最適化を行うことができる。最適化は、ブロック・レベルで行われ、あるいは、特に幾つかのブロックが含まれる場合は更に広げられる。本発明の望ましい実施の形態の利点は、フロー分析を行う必要がないことである。コンパイルされたコードの更に速い実行を生じるため、コンパイルされたコードに対してレジスタが用いられることが望ましい。
フォールバック・インタプリタが使用できる場合、コードのコンパイル時に種々の仮定を行うこと、およびフォールバック・インタプリタが利用できなければ要求されることがある種々の安全検査を省くことが可能である。後で仮定が誤りであることが証明されるか、あるいは安全検査をしないとなにかが不都合になるならば、関連するコンパイルされなかったコードを解釈するのにフォールバック・インタプリタを用いることができる。
アプリケーションの実行時にコンパイラがオンラインで実行されているとき、コンパイルのオーバーヘッドはしばしば甚大になる。主パスのみをコンパイルすることにより、コンパイラが簡単かつ迅速になり、その分析のためのメモリ使用が少なくなり、従って、特に小さなメモリのシステムにおいて実施可能である以上に多くの最適化の実施が可能となる。

２．実行履歴を用いてアプリケーションを介するパスのどれが主パスであるかを決定
アプリケーションが実行時に、実行履歴が捕捉される。この履歴は、制御の転送が生じるときに、ブロック・レベルで維持される。ブロックに入るとき（ブロックに対する制御の転送が生じるとき）、実行履歴レコーダが記録することが望ましい。実行履歴レコーダはまた、例えば問題のブロック後に実行された次のブロックであるブロックの実行に関する他の詳細も記録することができる。これにより、個々のブロックについての情報のみではなく、コードのブロックを介する実行の望ましいルートについての情報が得られる。
各ブロックごとの１つのエントリ・カウントおよびそれ以降のリストが、それぞれに関するカウントで保持される。これらのカウントは、使用頻度の指標として働く。実行履歴レコーダは、どの命令がブロックを終了した制御の転送を生じたかの表示も含む。制御の含むまでに実行されたブロックのみが候補となる。全ての過程で実行されなかったブロックについては、どのタイプのコードが実行されなかったブロックの部分に「隠された」かは判らない。このような隠されたコードは、シンボリック解明を要求するコードを含んでいることがある。従って、このようなブロックはコンパイルされないことが望ましい。制御がブロックから転送されるときブロックのカウントが実行履歴レコーダにおいて行われる場合、終了まで実行したブロックのみがカウントされる。代替的に、あるいは更に、ブロックが終りまで実行されたかどうかを調べるため、コンパイルに先立ち検査を行うことができる。
メモリが制限されるとき、実行履歴レコーダは２つの方法で再使用される。最初に、後続ブロックのリストが小さな数に制限され、新たな後続ブロックに入ると、最も頻度の低い現存する後続ブロックが新たなブロックと置換される。空いた実行履歴レコードがないとき、使用頻度の最も低い方法と関連する履歴レコードの全てが空いたリストへ移される。

要約すると、断片のコンパイルは所与の閾値を越えるブロックのエントリ・カウントによりトリガされる。この閾値は、固定され、あるいは動的に同調される。しかし、履歴ブロックの状態が、当該ブロックがすでにコンパイルの待ち行列にあること、あるいはコンパイル不能であることを示すならば、これは無視される。このようなブロックは、コンパイルの待ち行列におかれる。
望ましい実施の形態において、コードが最初に実行されると、コードは一切コンパイルされない。実行がインタプリタによりはじめて実施される。各ブロックが解釈されると、実行履歴により保持されたブロックのカウントが１だけ増分される。実行履歴レコーダは、各ブロックごとに、ブロックへの制御の転送が生じたブロックから、制御が移転されたブロックへと記録する。実行履歴はまた、ブロックの実行についての更なる情報、例えば、ブロックにおいて実行されたコードの種類も含み得る。１つの閾値が設定され、特定のブロックに対するカウントがこの閾値に達すると、コンパイルのための待ち行列においてこのブロックへ入る。閾値が５であり、特定のブロックが５回実行されたとき、このブロックに待ち行列において入る。
コンパイラは、コンパイルのためのブロックの待ち行列を管理するコンパイラ・マネージャと関連させられる。特定のブロックが実行の閾値に達すると、実行履歴レコーダがメッセージをコンパイラ・マネージャへ送り、コンパイルのための待ち行列でブロックに入る。コンパイラは、別のスレッドにおいて実行中であり、待ち行列にコンパイルのための項目があるかどうかを調べるためある間隔で検査し、またあるときは、コンパイラが待ち行列の先頭に参照されるブロックをコンパイルし始めることになる。

望ましい実施の形態においては、待ち行列に対する新たなエントリが待ち行列の先頭で入れられ、従ってコンパイルが最もなされるように、待ち行列が管理される。待ち行列がこのような方法で管理されると、多数回閾値に達するブロックが、少数回あるいは１回しか閾値に達しないブロックよりもコンパイルされ易い。その結果、待ち行列は管理不能になることはなく、コンパイラ・マネージャは随時待ち行列の一部または全てを削除することもできる。
多すぎるブロックがコンパイル待ち行列にあることが判るならば、閾値を引上げることができる。同様に、コンパイルの待ち行列に少数のブロックしかなく、あるいは一切のブロックがなければ、閾値を引下げることができる。これは、アプリケーションの実行中に動的に行うことができる。コンパイラ・マネージャは、待ち行列の長さを監視することができ、また必要に応じて、実行履歴レコーダに対して閾値を増加あるいは減少するようにメッセージを送ることができる。
コンパイラがコンパイラ・マネージャにより待ち行列におかれるブロックをコンパイルするとき、この１つのブロックだけをコンパイルするように進行する。しかし、コンパイラは後続するブロックに関して実行履歴レコーダにより集められる情報を用いること、およびコンパイラが閾値に達した１つのブロックのみをコンパイルするのではなく最も頻度の高いブロックをもコンパイルし、これによりブロックから最も頻度の高いパス（主パス）をコンパイルすることが望ましい。後続ブロックが自身の権利におけるコンパイルの適格な閾値の回数だけ実行されあるいは実行されないが、それにも拘わらず、閾値の回数だけ実行されたブロックから主パスの一部としてコンパイルされることが判るであろう。
コンパイラがコンパイルされるブロックを選ぶと、このコンパイラは、ブロックが完了するのが望ましいものかどうか、例えばコンパイルすることが可能であるかを判定し、かつすでにコンパイルされたブロック・バージョンが得られるかどうかを判定するため検査を行う。

次に、コンパイラは、方法の終りに達するか、あるいは、例えばコンパイルされたバージョンがすでに存在するゆえに、コンパイルが望ましくない１つのコードに遭遇するまで、（ブロックの最も頻度の高い後続ブロックを介して）主パスをトレースする。コンパイルが望ましくない他のコードは、コンパイルをトリガした元のブロック以外で主パスへ再び戻るコードである。他の最適なコンパイルに対しては、フロー分析が要求されよう。コンパイラは、このような制御のフロー回帰を検出しこれが生じることを防止する（分岐においてあり得るフローを判定して、起こりそうもないフローは断片から抜けるようにコードを生成することにより処理される）。このフローは、方法の終りを通り越すことはないが、主パスに追従し、例えばこのパスに追従させられる。コンパイラは、主パスのトレーシングを停止するとき、コードのコンパイルを主パスの初めから開始する。
コンパイルがトリガするとき、主パスは、一時に１ブロックずつ最も頻度の高い後続ブロックに追従することにより決定することができ、方法の呼出しへの追従を含む。
一般に、実行中のアプリケーションの実行履歴は、どのパスが主パスであるかのよい指標である。
１つの方法により２つ以上のパスがある場合、この方法によるパスの両方または全てが主パスであり得、かつ関連するブロックが充分な回数実行されるならばコンパイルされ得ることが判るであろう。
実行履歴は、正確である必要はなく、多くの方法で更新することができる。実行を著しく速度低下させることになるコンパイルされたコードにおけるトラック実行履歴ではなく、フォールバック・インタプリタによる実行履歴が保持される。

３．頻度の低い実行コードを解釈するフォールバック・インタプリタの装備
頻度が低いかあるいは例外的なコードが実行されるときフォールバック・インタプリタ手段を備えると、これに対してコンパイルされたコードが存在することなく実行が継続することができる。フォールバック・インタプリタは、実行履歴を維持する。このインタプリタは、クラス分解と関連する全ての問題がもっぱらフォールバック・インタプリタにより対処できることも意味する。
コードの主パスのみがコンパイルされる場合で、実行のパスが主パスから外れる場合、コンパイルされないコードの解釈が必要となる。更にまた、コンパイルされたコードのコンパイルにおいて最適化が行われなければならず、また後の段階で最適化においてなされた仮定が正しくないことが判るならば、フォールバック・インタプリタを用いて関連するコードのセクションを解釈する。また、コンパイルされたコード・バージョンが生成される前にインタプリタを用いて実行が開始する。
従って、実行のための制御をコンパイルされたバージョンからインタプリタへ渡し、コンパイルされたコードが得られると制御を再びインタプリタから渡すことが必要となる多くの機会があることが判るであろう。
特定の実施の形態に対し以下に更に詳細に述べるように、インタプリタがコードを翻訳中は、次に実行されるべきコンパイルされたコードのバージョンが存在するかどうか調べるため検査が行われる。このように、不要な解釈を回避することができる。
再び以下に更に詳細に述べるように、制御がインタプリタに対しかつこれからコンパイルされたコードの個々の断片間に送られるとき、特別な変換装置が設けられる。このような装置の事例は、「グルー・コード」および「アウトライア」である。この変換装置は、コンパイルされたコード・バージョン間の実行の円滑な転送の確保を助ける。これらの装置は、例えば、コンパイル・セクションの終りに解釈されるべきコードのアドレスに関する情報を保持し、変数が最新のものであり、かつ例えば実行が転送されるときに適切なレジスタに格納されることを保証するためコンパイル・バージョンにおいて最適化が行われた場合に特に重要なものである。
例えば、コンパイルされたコードからインタプリタへジャンプが行われるとき、インタプリタはメモリ状態がカレントであると予期し、従ってもし記憶場所がコンパイル・バージョンに対するレジスタへ置かれたならば、インタプリタが動作を進める前にこれを適切な記憶場所へ戻す必要がある。

４．アプリケーションが実行するときコードをオンデマンドにコンパイルできるオンラインのコンパイル・システムの装備
アプリケーションの挙動が変化すると、ダイナミック・コンパイラは、明らかになる新たな頻繁に実行されるパスに対して最適化コードを生成することができる。このことは、別のスレッドとして動作することにより、アプリケーションがフォールバック・インタプリタを介して有効でありつづけることを許容する。

５．新たなコード断片を動作中のマルチスレッド型システムへ組込む能力の装備
動作中のスレッドを停めることなく新たなコード断片を組込むことができるならば、より円滑な動作が得られる。
コンパイラは、特定ブロックに対する主パスのコンパイルをいったん完了すると、コンパイラ・マネージャに対して、コンパイルが完了した旨のメッセージを送る。完了するまでは、コンパイルされたコードは実行可能コードから離して保持される。コンパイラ・マネージャは、コンパイルされたコードを実行可能コードにロードする。コンパイルされたコードが関連するブロックに対して得られ、そこにコンパイルされたコードがあることを示すため、必要な変更がディスパッチ・テーブルおよびコード・キャッシュにおいて行われる。
コンパイルされたコードの導入は、動作中のスレッドの停止が要求されないように最小単位で行われる。

６．動作中のマルチスレッド型システムからのコード断片の取外しのサポート
コード断片の取外しもまた、制限されるメモリ環境における可動性にとって重要である。これはまた、新たな主パスが現われるとき、１つの主パスに対して最適化されたコードを別のコードと置換することを可能にする。コードは、このコードがコンパイルされた最適の前提が破れる場合に削除することができることに基いて、最適な最適化でコンパイルすることができる。
先に述べたように、主パスについてなされた前提がコードの以降の実行に対して不適正であることが判る場合、コードを介する非主パスを解釈するのにフォールバック・インタプリタを用いることができる。しかし、コンパイルされた主パスがその後頻繁に実行されなければ、コンパイルされたコード・バージョンにより使用されるメモリを解放するためコンパイルされたコード・バージョンを外すことが望ましくなろう。
一部の実施の形態においては、コンパイルされたコードの各断片の実行回数が監視され、それほど頻繁に実行されなければ、削除の候補としてマークすることができる。
望ましい実施の形態において、コード・バッファがアクセスされる回数が記録される。制御をバッファへ送る前に、その実行カウントが増分される。使用頻度が最小のバッファは、必要に応じて削除され得る。
例えば、ある時点で、コンパイラがコード・バッファのスペースから出る。その後、バッファが削除される。回数管理がなされたカウントが色々なバッファへ送られているならば、最低使用頻度のバッファが削除される。あるいはまた、最も古いバッファが削除される。
システムに対する破壊のリスクを減じるため、バッファの削除前に種々の検査が通常行われることが判るであろう。例えば、本文の「エージェント資料第６号」参照。

本発明１０２０および典型的な従来技術１０２２の迅速なプロファイリング、コンパイリングの実行に要する比較時間が１０秒のタイム・スロットの比率で示される図１Ｂにおける概略図により、コンパイル・コストを著しく低減できるという事実が示される。
主パスの使用はまた、コンパイラがその予定メモリ制限に達するときパスの途上で断片を切捨てることにより、ダイナミック・コンパイラをメモリ制約に耐え得るものにする。これは、従来技術のコンパイラにおいては不可能である。
このように、コンパイラが全ての割当てメモリを費消したとき、断片のコンパイルを終了することができる。切捨てたコンパイル断片の終りをインタプリタへ戻すことができるようにして、必要に応じて、適正バイトのコード・アドレスにおける、かつ適正な更新パラメータおよびレジスタ構造による実行を継続できるように、通常は適切なステップをとる必要があることが理解されよう。
小メモリのコンピュータ・システムにおいては、コンパイラがメモリ限度に拘束される点は厳しいものである。従って、これらのシステムは、その入力プログラムの内部表示を構成したりデータ・フローの分析などの結果を保持するために、コンパイル中に大量のメモリを消費しがちである。
対照的に、ダイナミック・コンパイラは、システムの始動時あるいは構成時にこれに課される外部の構成され得る制限内で働く。その後、コンパイラは、その制限内で可能なかぎり多くの断片をコンパイルする。コンパイラは、必要な場合は、切捨て時に制御を受取るためフォールバック・インタプリタに依存することによって断片を切捨てる。このことは、コンパイルの単位が１つの方法あるいはそれ以上でありかつフォールバック・インタプリタとの相互動作ができない、従来技術のコンパイラにおいては不可能である。

次に、主パスの決定に実行履歴が用いられ、主パスの一部がコンパイルされ、かつコンパイルされたコードとコンパイルされないコード間に実行が切換わる実行の１つの事例について述べる。
先に述べたシステムは、仮想マシン（ＶＭ）を含み、（Ｃ言語における）インタプリタとジャバ・アプリケーションとを含む。当該システムは、マルチスレッド型であり、ジャバ主要スレッド、コンパイラ・マネージャ・スレッドおよびコンパイラ・スレッドを含んでいる。
例えば、ジャバ・アプリケーションは、下記のクラスＡを含む。

ジャバ・スレッドが開始される。
Ｊａｖａ Ａ
ｃｌａｓｓ ｌｏａｄ Ａ
クラスＡがロードされ、Ａのディスパッチ・テーブルがロードされる。ディスパッチ・テーブルは、図１Ｃに略図的に示される。図１Ｃは、種々のアドレス・エントリ１０３２を持つＡのディスパッチ・テーブル１０３０を示している。例えば、主要な方法はアドレス４０００に置かれている。
ＶＭの主要プログラムは、４０００における方法の主要Ａのアドレスを識別し、グルー・コードを呼出す。
ｃａｌｌ ｇｌｕｅ（４０００）
グルー・コードは、インタプリタの使用とコンパイルされたコードの実行との間を実行が切換えることを可能にする変換装置の一部である。グルー・コードは、コンパイルされたコードとコンパイルされないコードの実行間の平滑な転送を行うための幾つかの装置を含んでいる。グルー・コードは、下記の１つ以上に対する部分を含んでいる。すなわち、
１．状態の記憶場所とレジスタの状態を更新すること
２．コンパイルされたコード・バージョンが得られず、あるいはコードのコンパイル時に行われる最適化が不適性であることが判るとき、インタプリタへ制御を渡すこと
３．実行のためのコンパイルされたコード・バージョンが得られるときに、インタプリタから制御を外すこと
当該変換装置は、状態を更新するための先に述べたようなアウトライアを含む。例えば、コンパイルされたコードの実行時に実行に遭遇するとき、制御は、インタプリタに実行の処理のためのコードの実行を開始することを命令するためグルー・コードへの送達前に、状態が更新されるアウトライアへ最初に送られる。
次に、グルー・コードは、アドレス４０００において始まるグルー・コードの実行を開始するようインタプリタを呼出す。
ｃａｌｌ ｉｎｔｅｒｐｒｅｔｅｒ（４０００）
インタプリタは、アドレス４０００で始動し、インタプリタが呼出しをしようとしていると判定するグルー・コードへ戻る。インタプリタは、呼出しがディスパッチ・テーブルのどこにあるかを知り、グルー・コードへ通知する。
グルー・コードは、方法に対するオブジェクト参照を用いてスタックをオフし、ディスパッチ・テーブルを探して方法に対するアドレスを得る。

方法の開始のコンパイルされたバージョンが得られると、ディスパッチ・テーブルにおいてコンパイルされたバージョンのアドレスに入り、コンパイルされたバージョンが実行される。
方法の開始のコンパイルされたバージョンに対する参照がなければ、ディスパッチ・テーブルは「呼出しグルー」に対するエントリを含み、関連するアドレスにおける方法の解釈を開始するグルー・コードの個々の部分への戻りが行われる。すなわち、
ｃａｌｌ ｉｎｔｅｒｐｒｅｔｅｒ（５０００）
インタプリタが方法へジャンプすると、インタプリタがメッセージを、方法が実行しようとしている実行履歴レコーダへ送る。
方法の終りに戻りが存在し、インタプリタが、先に述べた如きコンパイルされたバージョンの解釈または実行のため前の方法へ実行を戻すグルー・コードへ戻る。
グルー・コードは、レジスタ、スタックなどが次のコード断片の実行に対して正しいことを保証する戻りを処理する専用部分を含んでいる。例えば、方法がコンパイルされたバージョンから実行され、次のコード部分が解釈される場合、コンパイルされたバージョンに対するレジスタへ置かれた全てが、次のコード部分が生成される前に適正な記憶場所へ復元されねばならない。このため、グルー・コードを処理する戻りが、コンパイルされたコードの使用の結果として変更されたどんな状態でも復元する。
このように、グルー・コードへの戻りは更に、実行がコードの次の部分へ進む前に、グルー・コードを処理する戻りへ戻る。
先に述べたグルー・コードの種々の部分は全て、グルー・コードの同じ部分の一部であり得、あるいはグルー・コードの個々の部分であり得る。状態の更新は、先に述べられ、また本明細書の「エージェント資料第３」項に述べたようなアウトライアにより行われる。

以下の更なる事例は、呼出し以外の制御の転送のためのインタプリタの動作を記述する。
当該実施の形態においては、下記の方法が呼出され、インタプリタを用いて実行される。

インタプリタは、下記のように番号を付した行で表わされるバイト・コードで当該方法を実行する。すなわち、
バイト・コード ジャバ
0 iload_1 x＝p;
1 istore_3
2 iload_2 i＝a;
3 istore 4
5 goto 16
8 iload_3 x＝x/i;
9 iload 4
11 idiv
12 istore_3
13 i inc 4 1 i++;
16 iload 4 i＜p?-reiterate if true
18 iload_1
19 if_icmplt 8
22 return

方法のボイドファンクション（ｖｏｉｄ ｆｕｎｃ）が最初に呼出される。コンパイルされたバージョンがなく、従って方法がインタプリタによる実行を開始する。実行時に、下記のブロックがインタプリタにより認識される。すなわち、
b_１＝｛0-5｝
b_２＝｛19｝
b_３＝｛8-19｝（基本ブロックではない）
b_４＝｛22｝

インタプリタが最初のブロックｂ_１を実行する。インタプリタが、ｂ_１が一回実行されたことを記録しカウント１を持つ実行履歴レコーダを走らせる。（望ましくは、このレコーダは、ｂ_１の後続ブロックがｂ_２であること、およびｂ_１は全て全過程にわたり実行されたことをも記録する。簡単にするため、このような余分な情報の記録の参照は以下では省略される。）

ブロックの終りにおいて、インタプリタがコード・キャッシュに相談し、次のブロックｂ_２のコンパイル・バージョンがあるかどうかを調べる。（当事例では、１つのブロックから別のブロックへの制御の転送がある間は、呼出しはなく、このため、グルー・コードへの戻りがないことに注目されたい。別の実施の形態においては、インタプリタは各ブロック後にグルー・コードへ戻ることになろうが、時間がかかりそうである。本文に述べる望ましい実施の形態においては、インタプリタは、
ａ．呼出しに出会う
ｂ．戻りに出会う
ｃ．コード・キャッシュから、次のブロックのコンパイル・バージョンがある ことを見出す
ｄ．例外を介する
ときにのみ、グルー・コードへ戻る。）
このような場合、コンパイル・バージョンがなく、従ってインタプリタはｂ_２へ進み、実行履歴レコーダにカウント１のｂ_２を生じる。インタプリタは、再びキャッシュを調べ、ｂ_３のコンパイル・バージョンは見出さないと、ｂ_３の実行へ進む。当該事例においては、ループが３回反復され、従ってブロックｂ_４による方法から戻りが行われると（先に述べたように、戻りハンドラを介してグルー・コードに至り）、実行履歴レコーダにおけるブロックのカウントは下記のとおりである。すなわち、
ｂ_１＝１
ｂ_２＝１
ｂ_３＝３
ｂ_４＝１

コンパイルに対する閾値が５であるならば、ブロックｂ_１、ｂ_２またはｂ_３はいずれもコンパイルのために待ち行列にない。方法のボイドファンクションが次に呼出された後、カウントは下記のとおり。すなわち、
ｂ_１＝２
ｂ_２＝２
ｂ_３＝６
ｂ_４＝２
このように、実行履歴レコーダは、コンパイラ・マネージャへメッセージを送り、ｂ_３をコンパイルの待ち行列に置く。ある時間後に、コンパイラは待ち行列に相談してｂ_３をコンパイルする。コンパイル前に、コンパイラは、ｂ_３の後続ブロックを示す実行履歴レコーダにおけるＢ_３に対するレコードを用いてｂ_２から主パスを決定する。このような簡単なケースでは、ｂ_３の最大頻度の後続ブロックはｂ_３であり、その結果ループを表わす１つのブロックｂ_３のみがコンパイルされる。ｂ_３のコンパイルは、例えば、値ｐ、ｘ、ｉ、ａを記憶するレジスタを用いることにより最適化される。事前例外条件検査を、ｉ＝０検査（ゼロで除算）（本明細書の項「エージェント資料第２」参照）のため挿入することができる。コンパイラがコンパイルを完了したとき、コンパイラは、どのコンパイルが行われたか、コンパイル・バージョンがどこにあるか、および方法のエントリ点であるかどうかをコンパイラ・マネージャへ通知する。コンパイル・バージョンは、その時は実行に使用できない。

やがて、コンパイラ・マネージャは、ｂ_３のコンパイル・バージョンをロードする。コード・キャッシュは、方法の当該部分に対するホスト・コード・アドレスがコンパイルされたコードが存在する位置をこの時指示するように更新される。
後で、方法ファンクションが呼出されると、インタプリタがｂ_２の実行後にコード・キャッシュを調べて、ｂ_３のコンパイル・バージョンが利用可能であることを見出す。
インタプリタは、グルー・コードへ戻り、これが、先に述べたように、ｂ_３のコンパイル・バージョンの実行を生じる。
更に後で、ｂ_１およびｂ_２がコンパイルのための待ち行列に置かれるように、方法ファンクションが５回実行されることになる。
ｂ_１がコンパイルに当てられると、コンパイラがｂ_１から主パスを決定する。ｂ_１の後続ブロックはｂ_２である（すでにコンパイルされたバージョンが存在するから、コンパイラは、この場合、コンパイルされるｂ_３を主パスの一部と見なすことはない）。
断片ｂ_１およびｂ_２がコンパイルされ、ディスパッチ・テーブルが更新される。

以降の実行時に、ｂ_１／ｂ_２に対してコンパイルされたコードが実行され、クロッキング・コードへの戻りが行われ、これがｂ_３でコンパイルされたコードの実行を生じる。コンパイルされたｂ_１／ｂ_２からグルー・コードを経てコンパイルされたｂ_３へのパスが充分な回数だけ生じるならば、コンパイルされたｂ_１／ｂ_２をコンパイルされたｂ_３に結合するパスが作られる。（パッチングについては、見出し「エージェント資料第１２」において更に詳細に述べる）。このように、グルーを介するステップが要求されることがないので、実行は更に有効に行うことができる。
後で、コンパイラ・マネージャと関連するメモリ・マネージャが、コンパイラに対するメモリが解放されるべきことを決定する。削除のため選択される最も古いバッファは、ｂ_３のコンパイルされたバージョンを含む。コンパイラ・マネージャは、このバッファを削除するためデリータを呼出す。削除の前に幾つかの検査が行われねばならない（例えば、見出し「エージェント資料第６」参照）。先に述べた事例では、（削除されない）ｂ_１／ｂ_２に対してコンパイルされたコードと（削除される）ｂ_３に対してコンパイルされたコードとの間にパッチが挿入されたため、ある特定の問題が生じる。この問題が克服される方法の詳細については、見出し「エージェント資料第１２」を参照されたい。
図１Ｄは、先に述べた実施の形態を実施するのに好適な装置１０４０を示している。当該装置１０４０は、コンピュータ・システムにおけるジャバ・コード１０４３を解釈するためのインタプリタ１０４２を含んでいる。インタプリタが１つのコード・ブロックの終りに達すると、呼出しか戻りがなければ、コード・キャッシュ・サーチャ１０４４を用いてコード・キャッシュを検査し、次のブロックのコンパイルされたバージョンが得られるかを調べる。もしそうであれば、コンバータ装置１０４６（先に述べたグルー・コードを含む）が、コードのコンパイル・バージョン１０４９を実行するため制御を実行装置１０４８へ送る前に、必要な変更および改変を実施する。

インタプリタ１０４２がコードのブロックを実行すると、コードのどのブロックが実行されたか、ならびにブロックの実行についての更なる詳細、例えば当該ブロックの前または後にどのブロックが実行されたか、およびどんなタイプのコードが実行されたかを実行履歴レコーダ１０５０に記録する。
実行履歴レコーダ１０５０は、ブロックが閾値の回数だけ実行されると、コンパイラ・マネージャ１０５２に通知する。このブロックは、コンパイラ・マネージャ１０５２により管理される待ち行列１０５４に保持される。閾値チューナ１０５６が、コンパイラ・マネージャ１０５２からの情報からの待ち行列の長さを監視する。待ち行列の長さに関する情報に基いて、閾値チューナ１０５６が実行履歴レコーダ１０５０に対する閾値を変更してコンパイラ・マネージャへブロックを送る。
コンパイラ１０５８は、待ち行列１０５４において参照されるブロックをコンパイルする。コンパイラ１０５８は、ブロックの実行に関する実行履歴レコーダ１０５０からの情報を用いてブロックからの主パスを決定し、コードのコンパイルされたバージョンを用意する。コンパイル・バージョンが完成すると、コンパイラ１０５８が、必要なディスパッチ・テーブルおよびコード・キャッシュを更新しコンパイル・バージョンをロードするコンパイラ・マネージャ１０５２に通知する。
コンパイラ・マネージャ１０５２は、コンパイラ１０５８が利用可能なメモリを監視するメモリ・マネージャ１０６０を含んでいる。利用可能なメモリが少なくなると、メモリ・マネージャ１０６０が、コンパイルされたコードの一部を削除するようにデリータ１０６２へ指令する。また、待ち行列１０５４が長くなりすぎると、コンパイラ・マネージャ１０５２が、待ち行列１０５４の一部または全てを削除するようにデリータ１０６２へ指令する。

図１Ｅは、一般に１０６６と呼ばれる方法のコードによる実行のパスを示している。
同図は、コードの種々の断片、例えば１０６８、１０７０、１０７２を略図的に示している。このようなコードの断片は、それぞれコードのあるブロックを表わす。
同図に示されるコードは、１つの外部エントリ点１０７４を有する。ブロック１０７２の後には、条件付き分岐１０７６、例えば例外検査が存在する。例外が生じると、実行はコード１０７８に対するパスＡに沿って進み、実行を処理する。さもなければ、コードは呼出しがあり得るコード・ブロック（ブロック１０８２に対するパスＣ）に対するパスＢに沿って進み、あるいは実行はコード部分１０８３、１０８４に対するパスＤに進む。実行は、パスＥに沿って１０８５へ進み、あるいはパスＦに沿って１０８６へ進む。
実行がコード１０６６を走る実行についての情報は、インタプリタ１０４２により動作される実行履歴レコーダ１０５０に記録される。
ブロック１０６８がインタプリタにより閾値の回数だけ実行されたことが判ると、これは待ち行列１０５４へ送られる。コンパイラ１０５８は、レコーダ１０５０における実行履歴を調べて、下記のことを見出す。すなわち、
１．１０７２の頻度の高い後続ブロックが１０８０である（すなわち、実行がパスＡより頻繁にパスＢに沿って進んだ）こと、
２．１０８０の頻度の高い後続ブロックが１０８３である（すなわち、実行がパスＣより頻繁にパスＤに沿って進んだ）こと、および
３．１０８４の頻度の高い後続ブロックが１０８５である（すなわち、実行がパスＣより頻繁にパスＤに沿って進んだ）こと。
コンパイラ１０５８は、主パスが、従ってコードを介する１０６８、１０７０、１０７２、１０８０、１０８３、１０８４、１０８５であることを決定する。この主パスは、１０８８として示される。
コンパイラ１０５８が主パス１０８８をたどる間、断片１０８４が全過程を通じて決して実行されない（決してパスＦを通らなかった）ことが判る。このため、１０８４はコンパイルの適切な候補ではなく、コンパイルのための主パス部分は断片１０８４あるいは１０８５は含まない。
このように、コンパイルされる主パス部分は、断片１０６８、１０７０、１０７２、１０８０ＡＮＥＤ１０８３を含む。

上記の一部あるいは全てにおいて、本発明の幾つかの特徴がコンピュータ・ソフトウエアを用いて実現された。しかし、無論、当業者には、これらの特徴のいずれもハードウエアまたはハードウエアとソフトウエアの組合わせを用いて実現できることが明らかであろう。更にまた、ハードウエア、コンピュータ・ソフトウエアなどにより行われるファンクションが実施されあるいは電気信号などを用いて実施されることが容易に理解されよう。
情報の格納に関する特徴は、適切な記憶場所すなわちストアによって実現することができる。情報の処理に関する特徴は、ソフトウエア、あるいはハードウエア、あるいは両者の組合わせのいかんを問わず、適切なプロセッサまたは制御手段によって実現することができよう。
上記の一部あるいは全てにおいて、本発明は、下記の形態の一部あるいは全てにおいて具現され、コンピュータ・システムの作動方法において具現され、コンピュータ・システム自体において具現され、システムの作動方法でプログラムされあるいはこの方法を実行するように適用されあるいは構成されるとき、コンピュータ・システムにおいて具現され、そして（または）システムを作動する方法に従って適用されるプログラムが記録されたコンピュータが読取り可能な記憶媒体において具現される。
本文において用いられるように、用語「コンピュータ・システム」は、「コンピュータ」、「システム」、「装備」、「装置」、「マシン」、などの用語と互換である。コンピュータ・システムは、仮想マシンであり得、あるいは仮想マシンを含み得る。
上記の一部または全てにおいて、方法および装置の特徴および特質を含む先に述べた異なる特徴および特質は、どんな適切な方法においても組合わせが可能である。
本発明が本文において純粋に事例として記述されたこと、および詳細の修正が本発明の範囲内で可能であることが理解されよう。
本文に開示された各特徴、および（適切であるかぎり）請求の範囲および図面は、独立的にあるいは適切な組合わせにおいて提示されるものである。

エージェント資料第２−コンピュータ・システム、コンピュータ読取り可能記憶媒体、およびその動作方法、および前記システムの動作方法
本発明は、コンピュータ・システムに関し、かつコンピュータ・システムの動作方法に関する。特に、本発明は、コードをコンパイルするコンパイラを含むコンピュータ・システムに関し、かつコンピュータ・システムにおいてコードをコンパイルする方法に関する。望ましくは、本発明は、解釈言語、例えばジャバを走らせるコンピュータ・システムに関する。本発明は、オブジェクト指向プログラム（望ましくは、ジャバ）に関することが望ましい。望ましい実施の形態においては、本発明は、事前例外条件検査に関する。
プログラムの過程またはジャバのようなオブジェクト指向プログラムにおける方法の実行方法において生じる諸問題を回避するために、許されない状況を検出してエラーおよび（または）例外を投与する安全システムが通常組込まれる当該システムは通常、検出される例外条件に応答して例外が検出された場所で実行を停止する。このようなシステムにおいては、実行の継続を許容する前に実行を処理するため、例えば違法な動作を締出すために、例外ハンドラが含まれる。
ジャバは、エラーと例外の両者を投与する。簡単にするため、これらは本文では「例外」と呼ばれる。本文における用語「例外」は、前後関係から明らかである場合を除いて、例えばランタイム・エラー、例外、およびジャバ言語および（または）他の言語で生じる他の出現を含むように広義に解されることを理解すべきである。

ジャバは、例外が多い言語である。ジャバはまた、例外が生じるとき、例外を処理する種々の機構も有する。
例えば、コードの一部は、項「ｙ＝ｉ／ｚ」を含む。コードが実行されるときｚ＝０ならば、例外「ゼロで除す」が投与される。コンパイルされると、あり得る例外を含む方法は、例外を投与するものとマークされる。
例外を投与する旨宣言した方法がジャバに呼出されるならば、ジャバ・コンパイラは、前記方法を呼出す方法もまた例外を宣言するか、あるいは例外を処理する例外ハンドラを提供することを要求する。このため、例外は、例外ハンドラにより捕捉され処理されるか、あるいは呼出しチェーンの終りに落ちる（ｆａｌｌ ｏｆｆ）まで、この呼出しチェーンをリップルアップ（ｒｉｐｐｌｅ ｕｐ）し得る。このことは、ジャバには実質的に２つのタイプの例外、すなわち、「検査済み」および「未検査」があることも理解するジャバ言語になじんだ者にはよく理解されよう。
例外「検査済み」は、「捕捉」されるかあるいは「投与」されることになる。コンパイラは、実際に検査済み例外を捕捉あるいは投与に強制する。対照的に、「未検査」例外は、ゼロで除算のようなランタイム・エラーによく似ており、ジャバもＣ＋＋も投与の宣言を強制しない。
ゼロで除算のような特定の例外が最上位すなわち最も前のフレームａで宣言され、最近のフレームｂ、ｃ、ｄなどはフレームａより下方で逐次付加されるものと見なされるスタックが形成される状態について考察しよう。例外がフレームｄで遭遇するならば、このフレームに対する評価スタックはクリヤされ、ＶＭは例外オブジェクトを生じてこれに対する参照は、マッチング・ハンドラによりこのフレームの評価スタックに入れられる。

オブジェクト参照は、例外のタイプを表わし、（この例外に対してなにかが存在するものとして）例外がどのように処理されるかについて命令テーブルへ進む。例えば、このテーブルは、例外が行１−２０のいずれかに生じるならば、この例外は行２１において処理されることを表わす。
フレームｄにおける例外に遭遇すると、最初に、フレームｄはハンドラについて探されるが、例外がフレームａにおいて宣言されているので、明らかに見出されず、従ってフレームｄは消され、サーチはフレームｃにおいて続行する。同じ状態がフレームｃにおいて取得され、従ってサーチは後へ続き、ハンドラを見出すことができるフレームａに達するまで、フレームｄ、ｃ、ｂを次々に消す。ローカル変数のみが消されたフレームに格納されること、従って貴重な情報の逸失がないことを強調すべきであり、全てのグローバル変数（ジャバでは、アレイ、オブジェクト、スタチック・フィールドと呼ばれる）および（例えば）フレームｃに生成されるオブジェクトは、ヒープに格納されたままである。
ジャバは、例外の多い言語である。ジャバの状態は、ジャバ・プログラムの意味論により指令されるように書かれねばならない。
しかし、ジャバ・プログラムがコンパイルされるときは、種々の最適化を行うことが可能である。１つのこのような最適化は、コンパイルされるコードの断片がループを含む場合に可能となる。ランタイムにおける実行をより効率的にするために、任意のループ不変動作をループ外へ移動することが望ましい。しかし、このことは、例外がループ内に生じる場合に問題を生じ得る。このため、下記の簡単な事例において、アレイのアクセス「ａｒｒ［ｉ］」が例外「限度外の指標（ｉｎｄｅｘ ｏｕｔ ｏｆ ｂｏｕｎｄｓ）」を生じる場合に、アレイのアクセスが実行される前に「ｘ」を更新することができない。「ｘ」に対する書込みがアクセス前に誤って移動された場合、および例外が生じた場合、「ｘ」に対する正しくない値を持つことになる。

従って、ループ不変性のような標準的なコード移動の最適化は、コードが横切って移動できないバリアとして働くような例外の存在時には阻害される。
上記の事例においては、「ｘ」はループ不変値（１０）が書込まれている。潜在的な例外が存在する場合、書込みをループ外に移動することはできない。「ａ」がアレイ「ａｒｒ」に対する許容指標値の範囲内に該当しなければ、「ａｒｒ［ｉ］」に対する最初のアクセスは例外を生じ、「ｘ」はループに対するエントリ時に同じ値が存在することになり、値１０ではない。更に、例外検査自体は、ループ本体内で実行し、従ってそれ自体の実行上のペナルティを生じる。

最適化が上記事例のコードのコンパイルの場合に行われるならば、「ｊ」が決して許容指標値の範囲外になり得ないことを証明するため分析を行う必要がある。このことが証明できるならば、ｘに対する書込みはループ外に安全に移動することができる。必要な条件を証明するためには、コードの複雑な分析が要求されることになる。ある場合には、例えば１つの方法の基本ブロックの分析から例外が生じないことを示すことができる場合には、ローカルな分析で充分であるかもしれない。しかし、大半の場合は、幾つかのブロック、アレイが証明を行うことができるように生成されたブロックに溯って見る必要がある。この場合は、グローバルなデータ・フロー分析（１つの方法全体の分析）または手順間の分析（プログラムまたはクラス全体の分析）が必要となる。明らかに、このような分析は、時間を要し、メモリの使用コストが高く、実際にオフライン・コンパイルにおける使用にのみ考え得るものである。いずれの場合も、詳細な分析の結果として例外が生じることが判るならば、最適化はいずれの場合も可能でない。このため、このような分析は、実際には制限されたメモリ・システムにおいてはランタイムではほとんど行われず、実行が生じるコードの最適化は通常は試みられることがない。

別の事例は、分母がゼロに等しい除算ステップにおいてある点に達する状態を包含する例外条件を惹起する。
この事例は、変数ｘの別の変数ｉによる除算を包含する。ｉがゼロになるある状況が生じ得、ゼロで除すことになり、下記のような計算不能なファンクションとなる。すなわち、

プログラム・ループが値であるなにものかを実行することをおそれるため、例外をあまりに早く投与することは望ましくない。例外が生じる前に、あり得る例外を含むループが非常に多くの回数（おそらくは、平均１０回）だけ循環されることはあり得ないことではない。
このため、ループの反復実行時にランタイムにおける時間を節減するためループからループ不変項を除去することが望ましいが、詳細な分析を行うことなくループ外へ項を移動するのは安全ではない。
本発明は、このような問題および（または）他の問題を軽減することを求めるものである。

本発明によれば、あり得る例外を含むコードの断片をコンパイルする方法が提供され、当該方法は、事前例外条件検査を含めるステップを含んでいる。
事前例外条件検査は、コードの断片のコンパイルされたバージョンに含まれることが望ましい。事前例外条件検査を用いることにより、例外を生じるかもしれないコードが実行される前に、例外が生じるかどうかを早く決定することができる。例外が生じないことを検査が示すならば、例外を含むコードを実行することが安全となる。
例外が起きるかもしれないコード本体の直前に事前例外条件検査が含まれるのが望ましいことが理解されよう。これにより、事前例外検査以外のコードを最適化することができる。コンパイルされる断片の初めに条件検査が含まれることが望ましい。このことは、断片がループを含む場合に特に望ましい。
例外が生じないという前提において、コードの断片がコンパイルされることが望ましい。事前例外検査が用いられるとき、検査を通るならば、例外が生じないだろうことが判る。このため、例外が生じるかどうかが判らなかったならば実施が安全でなかった最適化が可能である。このように、コンパイルされたコードは、コードの実行における速度が大きいことならびに更にコンパクトになることによりメモリ・スペースが少なて済むことの二点で更に有効であり得る。
当該方法は、条件検査が例外が生じるだろうと決定する場合に使用される救済装置を提供することを含む。多くの場合、事前例外条件検査は、例外が生じずかつコンパイルされたコードの実行を進められることを判定する。しかし、ある場合には、例外が生じるだろうこと、および条件検査が例外条件が切迫していることを決定しよう。救済装置は、例外を実行の予期される時点でインタプリタにおいて遭遇させることが望ましい。
元のコード断片が例外を処理するためのコードを含んでいたならば、このコードが最適化手順の一部としてコンパイル・バージョンには含まれないことが望ましい。いずれの場合も、コードは、頻繁には起きない例外の更なる検出および処理において用いられるコードで複雑にならないようにコンパイルされることが望ましい。従って、例外を処理するためのコードがコンパイルされるのではなく、例外の処理のためコンパイルされないコードを解釈するインタプリタが用いられることが望ましい。救済装置は、インタプリタに対して制御を渡すように構成されることが望ましい。コードのコンパイルされたバージョンがあるため、インタプリタが通常はこのコードの実行のために使用されないので、制御はインタプリタへ送られるよう強制される。

このように、実際には、コードのコンパイルされたバージョンは、例外が生じないときにのみ使用されるように調製され、このような状態に対してコンパイルされたコードを最適化するようにコンパイルされることが望ましい。例外が生じる場合、コンパイル・コードは用いられないことが望ましく、インタプリタは条件を検出し例外を生じる時点まで実行するため用いられる。コンパイル・コードの２つのバージョン、すなわち、１つは例外が生じた場合に用いられ１つは例外が生じなかった場合に用いられ、各々が関連する状況に対して最適化されるバージョンを提供することが可能である。しかし、多くの場合、特にシステムが制限されたメモリ（例えば、ＶＭ）を持つシステムであった場合、これは望ましくない。例外が生じた場合に使用されるコードのコンパイル・バージョンはそれほど頻繁に使用されず、コードのコンパイル・バージョンに対して割当てられたメモリを混乱させることになる。
コンパイル・コードが最適化された場合、例外が生じることを条件検査が明らかにするとき状態の条件（例えば、整数の変数およびレジスタの状態の値）は、対応するコンパイルされないコードに対するものと同じでないことがあり得る。救済装置は、状態を更新するためのアウトライアを含むことが望ましい。
断片はコードの主パスの一部であることが望ましい。コードの少なくとも一部がループを形成することが望ましい。特に仮想マシンにおけるように利用可能なメモリが制限される場合、それほど頻繁に実行されないコードをコンパイルしないことが非常に望ましい。当該方法はまた、コードを介する主パスを決定するステップを含むことが望ましい。それほど頻繁に実行されないコード、例えばコードの主パスでない部分はコンパイルされないことが望ましい。コンパイラは、コードの主パス部分のみをコンパイルすることが望ましい。

本発明によれば、コンパイル・コードにおける事前例外条件検査の使用が更に提供される。
本発明はまた、先に述べた方法によるコードのコンパイルのためのコンパイラを提供する。
また本発明により提供されるのは、あり得る例外を含むコードの断片をコンパイルする装置であり、当該装置は事前例外条件検査を含む手段を含んでいる。
当該装置は、コンピュータ・システムの一部、望ましくは仮想マシンであることが望ましい。本発明は、特に、解釈される言語に関し、特にジャバに関する。
コンパイラは、コンパイルされた断片の初めに条件検査を含むように構成されることが望ましく、かつコンパイラが、例外が生じないという前提でコードの断片をコンパイルするよう構成されることが望ましい。このことは、断片がループを含む場合に、特に関連する。
当該装置は、条件検査が実行が生じると決定する場合に使用される救済装置を含むことが望ましい。当該救済装置は、コンパイラによりコンパイル時に提供されることが望ましい。
当該装置は更にインタプリタを含み、前記救済装置がインタプリタに対して制御を送るように構成される。インタプリタは、例外を処理するためコードを解釈するように構成されることが望ましい。

救済装置は、状態を更新するためのアウトライアを含むことが望ましい。特に、制御がコンパイル・コードの実行から放棄される場合、および制御が送られる前に状態を更新することがしばしば必要となる場合である。
前記断片は、コードの主パスの一部であることが望ましく、かつコンパイラが主パスのコードをコンパイルするように構成されることが望ましい。コンパイラは、コードの主パス部分のみをコンパイルするように構成されることが望ましい。コンパイラはオンライン・コンパイラであることが望ましい。コンパイラの実行時間インパクトおよびコンパイラが使用するメモリ量は、コンパイラがコードの主パス部分のみをコンパイルする場合に低減することができる。
本発明はまた、先に述べた方法を用いてコンパイルされるコードを提供する。
本発明によれば、コンピュータ・システムに対するコードも提供され、このコードは、あり得る例外を含むコンパイル・コードの断片を含み、このコードは更に事前例外条件検査を含んでいる。
前記コードは更に、例外が表示されるならば使用される救済装置を含み、救済装置はインタプリタに対する制御の転送を強制する手段を含むことが望ましい。
また本発明により提供されるのは、先に述べたようなコードを含む、構造化されたデータが記録されたコンピュータ読取可能な記憶媒体であり、また先に述べたような方法を実行するためプログラムが記録されたコンピュータ読取可能な記憶媒体である。

本発明により更に提供されるのは、先に述べたような方法でプログラムされるときのコンピュータ・システムであり、かつあり得る例外を含むコードの断片がコンパイルされる方法によりプログラムされるときのコンピュータ・システムであり、当該方法は事前例外検査を含んでいる。
本発明は、ループ内の例外条件の存在時のコードの移動に関する最適化を可能にすることを目的とし、結果として得るコンパイルされる断片の実行速度を更に改善する。
この解決法は、コンパイルされる断片がループのエントリ点に先立って行われる相当の検査を含む、「事前例外条件検査」の使用によって達成される。
このような検査は、好都合にもフォールバック・インタプリタの存在に著しく依存する。検査が例外条件を検出するならば、制御は、当該ループのエントリ点において前記断片に再エントリする可能性のないフォールバック・インタプリタに関連する。フォールバック・インタプリタは、ループのエントリ点における実行を続行し、従って実行がその正しい制御点に遭遇する時点まで実行し、これにより全てのジャバの状態が正しい値を含む実行を生じる。しかし、事前例外条件検査が通るならば、断片は安全に使用可能であり、任意のコード移動の最適化が有効である。
従って、上記の事例においては、検査結果を順守するかぎり、「ｘ」のループ不変性の割当てをループ外に移動することが可能である。これにより、ループにおける元の例外検査を省くことを可能にし、これもまた改善された性能を提供する。
全ての事前例外条件検査が任意の実行ループ外で行われて、（特に、ループが多数回反復される場合に）検査の実行の時間的なペナルティを減じることが望ましい。
コンパイル・コードは、幾つかのあり得る例外について検査するため、幾つかの事前例外条件検査を含むことが望ましい。このような検査は、個々の検査の集合として構成され、あるいは任意の数の例外条件が存在するかどうかを決定する１つの検査を含む。

コンピュータ・システムは、仮想マシンを含むことが望ましい。本発明の方法は、仮想マシン（ＶＭ）の範疇における特定の用途を見出すものである。ＶＭは、体内埋設システムにおける小さなメモリ形態を必要とし、本発明は、仮想マシンにおけるコードのコンパイル・バージョンの形態の低減を許容する。
本発明は、インタプリタが使用される解釈言語、特にジャバ言語に対する特定の用途を見出す。インタプリタは、例外が表示されるときにフォールバックとして使用することができる。インタプリタが存在しなかったならば、例えば例外の存在時に、コードの多数の異なるコンパイル・バージョンが、コードを介する代替的なルートを処理するため提供されねばならない。このような構成は、コードのコンパイル・バージョンにより占有されるメモリ・スペースが減じるという利益を低減し、あるいは更にこれを打消すものとなろう。
コードのコンパイル・バージョンへ挿入することができる検査の回数（実行における時間的ペナルティを生じる検査）と、最適化されたコンパイル・コードの実行における実行時間が減じるという利益との間に均衡を生じやすい。
本発明の利益は、望ましくは実行時間およびメモリのペナルティの増加がない（条件検査の使用による）実行における安全の増進を含む。
本発明の更なる利点は、コンパイルされる断片を介する高速な（検査されない）ルート、あるいはループ内に例外条件が存在する場合でさえ、ループ外の遅い（フォールバック・インタプリタを介するルートの検出を除く。本発明は、（例外条件検査を含む）コードの移動の利点を利用する高速なルートを可能にする）ルートの選択である。このような選択は、方法全体をコンパイルした先のコンパイラ、およびそのコンパイルされた方法がフィールドの例外条件に対するインタプリタとは相互に働く能力を持たないコンパイラには得られない。
本発明により、コンパイル部分の性能は、ループ外へコードを移動する能力により著しく改善され得る。従って、従来のコンパイラには通常得られないダイナミック・コンパイラの最適化の選択および用途において、より大きな自由度が得られる。

本発明の代替的な特質によれば、（望ましくは、プログラムの実行中に）例外条件の発生を識別するため例外検査をコンパイルする手段と、解釈される言語において前記例外検査により識別されたとき例外を実行する手段とを含むコンピュータ・システムが提供される。
また、例外条件の発生を識別するため例外検査を実施する手段も任意に提供される。
本発明は、別の特質において、プログラムを実行し、切迫した例外条件の発生を識別するため例外検査をコンパイルし、前記例外検査により識別されたとき解釈される言語において例外を実行するステップを含むコンピュータ・システムの動作方法を提供する。
例外検査は、処理中のループ外で行われることにより、望ましくは例外検査がループの一巡ごとに行われる必要を避けることが望ましい。本発明の利点は、コンパイラを介する高速の（検査されない）ルートか、あるいは従来のコンパイラ・オフラインでは利用できないインタプリタを介する低速の（例外を検出する）ルートをとるよう選択することである。
本発明によれば、将来のある時点にループ外で例外に達すると決定することが可能である。この状態が生じると、制御はインタプリタへ渡され、従ってループの一巡ごとに例外について検査する必要がない。
例外検査自体はコンパイルされるが、比較的遅いインタプリタにおける例外自体の解釈はコンパイル時間を節減するのに役立ち、特にあり得る例外の処理のためコードの多数のコンパイル・バージョンを持たないことによりメモリの必要を低減するのに役立ちながら、最適化を損なうことがない。実際に、最適化は確実に可能とすることができる。（ジャバにおいては、例外処理はプログラミング・レベルで行われる。）
本発明の特質のいずれか、あるいは一部、あるいはその全ては、他の任意の特質に適用され得る。
以下の考察は、先に述べた本発明のいずれかあるいは全ての特質に適用する。
本発明の望ましい実施の形態については、純粋に事例として、（改善を略図的に表わす）添付図面を参照しながら以下に記述される。

以下の事例について考察しよう：
１つの方法が呼出される：

ｉ＝０でありゼロによる除算が試みられるならば、例外が生じることが判る。これまでは、例外が生じたならばｘへの書込みが行われてはならないから、ループ不変コード（ｙ＝ｂ）をループ外へ移動することは可能でなかった。
当該方法のファンクションが最初に呼出されると、このファンクションはインタプリタによって実行される。例外が生じるならば、この例外は通常の方法で処理され、コードが解釈されているので、ｘへの書込みは、例外が生じない場合にのみ生じることになる。望ましい特質に寄れば、方法のファンクションのコードの断片がコードの主パスの一部であると見なされるだけ充分な回数インタプリタにより実行されるならば、これら断片はコンパイルのため待ち行列に入れられる。詳細な論議は、本明細書の項「エージェント資料第１」に見出される。
この論議から、ループが最初にコンパイルされやすいこと、およびこのループに対する主パスがループを含むブロック（単数または複数）のみを含むことが判る。

項「エージェント資料第１」において説明されるように、反復ループは第３のブロックｂ_３を表わす。バイト・コード（インタプリタにより翻訳される如き）は、下記のように記号化することができる（相当するジャバ命令が示される）。すなわち、

ブロックｂ_３は、バイト・コードの行１２ないし２７により表わされる。ブロックｂ_３が充分な回数実行されると、このブロックはコンパイルのため待ち行列に入れられる。
コンパイラは、ブロックｂ_３にあり得る「ゼロで除算」の例外があることを知る。事前例外条件検査が、ブロックｂ_３のコンパイル・バージョンへ挿入される。この場合には、検査がコンパイルされる断片の初めに挿入される。（無論、コンパイル・コードに例外が生じる前に、任意の点に挿入されることもあり得る。例外がループ内に生じ得る場合、検査がループのエントリ点に先立ち挿入されることが望ましい。当例におけるように、いずれの場合も、ループのエントリ点はしばしば主パスの一部の始まりとなる。）

コンパイラはまた、ブロックｂ_３がループ不変項ｙ＝ｂを含むこと、およびループからループ不変項を除去するため最適化を行うことができることも知る。
ブロックｂ_３のコンパイル・バージョンは、例えば、以下の左欄に示されるようなものである（明瞭にするため、簡素化したコードで示される）。コンパイル・コードの各部により行われるステップについての表示は、右欄に含まれる。

コンパイルされたコード 行われるステップ
cmp i,0 ｉをゼロと比較する
ble glue_bailout ｉが０より小さいか等しければ、グルー・ コードへ進む
load r_ａ,b ｂをレジスタへロードする
store r_ａ,y ｙ＝ｂ（ループ不変ステップ）
load r_ｎ,i ループの初めにレジスタをロードする
load r_ｍ,x
div r_ｓ,rｍ,rｎ ｘ／ｉおよび結果をレジスタｓへ格納
add r_ｎ,l ｉ＋＋
cmp r_ｎ,rａ ｉ＜ｂ
blt ｉ＜ｂならば、ループを（div r_ｓ,r_ｍ,r_ｎ から）ループを繰返する

上記コードの最初の２行は、事前例外条件検査を含む。ｉがゼロより大きければ、検査は通り、コンパイル・コードの残りが（３行目から）実行される。ｉが０より小さいかこれに等しければ、以下に述べるように、コードの２行目が実行を救済装置のグルー・コードへ送る。コンパイルされたブロックｂ_３の残りはこの時は実行されない。インタプリタがループ本体の初めから例外が検出される点まで全てにわたりループを解釈することに注目されたい。このように、コンパイル・コードにおける検査は、即時の例外ではなくこれから起こる例外の早期の警告を与えている。ある場合には、このことは、制御がインタプリタへ転送される前には「行われない」はずの、コンパイル・コードにおいて実施されるステップ数を減じることができる。

ループのコンパイル・バージョンにおいて種々の最適化が行われたことが判る。特に、ループの不変項ｙ＝ｂは、ループ外へ移動されている。これは、事前例外条件検査が存在しなかったならば、安全ではなかったかもしれない。
上記の事例は、簡素化されている。実際には、ａがループ実行の限度から外れる状況に対して、（ｉが０より小さいかこれに等しいかの検査の前または後に）「限度外の指標」の事前例外条件検査もあり得る。このように、コンパイル・コードの各部は、幾つかの事前例外条件検査を持ち得る。事前例外条件検査のタイプ例については、以下に述べる。
コンパイルされた断片およびコンパイルされない断片を含むコードの実行の詳細な論議については、項「エージェント資料第１」を参照されたい。一部のステップの概要については、条件検査が例条件の存在を判定する場合における上記事例に対してここに述べる。
コンパイル・コードの最初の行は、ｉが０より小さいかこれに等しいかを調べるために実行される。もし実行されれば、コードの２行目がグルー・コードの特定のエントリ点に対して実行を指令する。グルー・コードは、制御をインタプリタへ送ることを強制する。グルー・コードは、コードの解釈をどのアドレスから始めるか（また、（コード・キャッシュがコンパイル・バージョンに対する参照を含むので。この場合は、コンパイル・バージョンは使用できない）実行前にはコード・キャッシュを調べないこと）をインタプリタに教える。グルー・コードは、インタプリタに対し、ブロックｂ_３のコンパイルされないバージョンの初めにおける（ｉｌｏａｄ＿３から、上記参照）実行の再開を示す。インタプリタは、正しい時点における例外を知り、この例外は然るべく処理される。（インタプリタは、例外をそれほど早く起こすことはできない。）
インタプリタが例外を含む断片をいったん実行すると、「エージェント資料第１」において述べたように、制御は、コードのコンパイル・バージョンの実行のためグルー・コードを介して戻される。

同様に、「バウンド外の指標」事前例外条件検査が挿入される場合、関連する検査が失敗すると、制御はグルー・コードへ送られ、更にインタプリタへ送られる。
別の事前例外条件検査は、コンパイルされるべきコードに生じ得る任意の例外に対して用いることも可能である。１つの事前例外条件検査は、幾つかのあり得る例外についての検査に用いることも可能である。
コードの移動および他の早期検査を組込まれた方法に適用することを可能にするため、早期検査予測検査、あり得る範囲のアレイ指標値に対する早期バウンド検査、早期空参照検査、早期のゼロ除算検査、および早期オブジェクト・タイプ検査を含む、このような１組の事前例外検査を使用に供することができる。
検査予測検査は、所与のタイプのオブジェクトをこのタイプに対するフィールドに格納することができるかどうかを証明し、例えば、検査は「グラフィックス」タイプのオブジェクトを「ｃａｒ」タイプ・オブジェクトに格納できるかどうかの質問に答えることができる。
ジャバ（および他のオブジェクト指向言語）は、クラスＡがクラスＯを拡張しクラスＢがクラスＯを拡張するならばクラスＡおよびクラスＢは関連しない場合に、クラスに対する階層的構造を有する。反対に、クラスＡがクラスＯを拡張しクラスＢがクラスＡを拡張するならば、クラスＢはクラスＡのサブクラスであり、システムはＡを用いる場合にＢを用いることができる。このように、コードの一部におけるオブジェクトの階層が適切でない場合に例外が生じる有効範囲があることが判る。
検査予測条件検査は、クラスのフェルミ準位が正しく、かつ検査予測検査が失敗する場合に制御が救済装置へ進むことを調べるため検査する。
名前が示唆するように、バウンド検査は、アレイ指標がアレイの許容限度すなわちバウンド内にあるかどうかを証明し、さもなければ、救済装置（グルー・コード）を参照して、指標がバウンド外にある例外を生じる。「バウンド外の指標」の例外が生じる状況について、一例が示される。
空白参照検査は、フィールド参照が空白であるかどうかを識別し、その場合このフィールドでは一切が行われない。

一例として、下記のステップを考察しよう。すなわち、

この段階で、「ｇｅｔｆｉｅｌｄ」はオブジェクトから指定されたフィールドをロードする。この状況が生じると、

次にｓが空白ならば、なにも行われ得ず、ｇｅｔｆｉｅｌｄにより例外が生成されねばならない。事前例外条件検査は、空白が存在するかどうか決定する。もしそうであれば、救済装置が呼出される。
ゼロによる除算検査は、先の事例においてすでに論述されたように、計算不能ファンクションである除数ファンクションの分母がゼロになる状況に達するかどうか決定する。

オブジェクト・タイプ検査は、方法の正しい実現によりオブジェクトがオブジェクト指向システムの階層構造に適合することを保証する検査として最もよく記述することができる。
このような検査の例示として、ドローがグラフィックス・クラスのオブジェクトを描画するための方法である場合に方法がドローを呼ぶ状況について考察しよう。ドローの異なる実現を含むこのような段階でグラフィックスのサブクラスがなければ、方法ドローが最終的なものであり新たなドロー方法によりオーバーライドされないことを仮定することができる。このように、ドロー方法は、たとえ潜在的に多形性であっても、多形性でないと仮定される。コードは、ドロー方法が最終的であるという仮定によりコンパイルされ得る。前記の仮定、例えばコードに対する方法ドローの組込みに基いて、最適化を行うことができる。項「エージェント資料第９」を参照されたい。
オブジェクト・タイプ検査は、呼出された方法を関連するオブジェクトにおいて適切に実現できるかどうか決定するために行われる。当例では、オブジェクトが他のなにものでもなくグラフィックス・タイプであるかどうか、およびドローの方法がオブジェクトに対して適切であるかどうか、検査が決定する。
本発明の方法を実施する装置が、図２Ａに略図的に示される。当該装置は、コードを解釈するインタプリタ２０００を含んでいる。実行履歴レコーダ２００２は、インタプリタ２０００によるコードの実行の詳細を記録する。コードの１つのブロックが予め決めた回数実行されるとき、実行履歴レコーダ２００２は、コンパイルのためのブロックの待ち行列を管理するコンパイラ・マネージャ２００４に通知する。コンパイラ２００６は、待ち行列を調べてコンパイルのためのブロックを選択し、実行履歴レコーダ２００２のレコードから主パスを決定する。コンパイラはまた、コンパイルされるべき主パス部分に生じる得るなんらかの例外があるかどうかを判定する。もしそうであれば、必要な事前例外条件検査がコードのコンパイルされる断片の初めに挿入される。コンパイラ２００６は、この断片をコンパイルして、救済装置２００８に対する必要なリンクを設定する。コンパイルされたコードは、実行装置２０１０により実行される。例外が生じることを事前例外条件検査が示すならば、救済装置２００８はグルー・コード２０１４へ転送し、これが例外に関するコンパイルされないコードの実行のため制御をインタプリタ２０００へ送る。

図２Ｂは、コンパイルされないジャバ・コード２１００の一部を示している。コード部分２１００は、インタプリタ２０００を用いて実行される。
セクション２１００は、ループ２１０２を含んでいる。ループ２１０２内には、あり得る例外（例えば、例外「ゼロで除算」を生じる結果となる除算）が含まれる。ループ２１０２はまた、ループ２１０２の実行速度を増すためにループから出ることが望ましいループ不変項２１０６をも含む。
コード２１００の何回かの実行後に、ループ２１０２を形成するコード部分がコードの主パス部分であることが見出され、これはコンパイルのため待ち行列に置かれる。図２Ｃは、コード部分（全体的に２１０８として示される）のコンパイル・バージョンを示している。コンパイルされたコード部分２１０８は、例外が生じるかどうかを調べるため検査する事前例外条件検査２１１２を含む。コンパイル・バージョンは、ループ２１１４を含むが、コンパイルにおいて行われる最適化により、このバージョンは以前より小さく実行が速い。ループ不変項２１１６はループ２１１４から移動されて、実行の速度を増す。事前例外条件検査２１１２は、例外が生じることが見出される場合に、救済装置２００８に対するパス２１１８を含んでいる。
以上のことのいずれかまたは全てにおいて、本発明の幾つかの特徴がコンピュータ・ソフトウエアを用いて実現された。しかし、無論、当業者には、これらの特徴のいずれもハードウエアまたはハードウエアとソフトウエアの組合わせを用いて実現されることが明らかになるであろう。更にまた、ハードウエア、コンピュータ・ソフトウエアなどにより行われるファンクションが電気信号などを用いて行われることが容易に理解されよう。

情報の格納に関する特徴は、適切な記憶場所またはストアによって実現される。情報の処理に関する特徴は、ソフトウエアまたはハードウエア、あるいは両者の組合わせのいずれかにおいて、適切なプロセッサまたは制御手段によって実現される。
上記のいずれかあるいは全てにおいて、本発明は、下記の形態のいずれか、あるいは一部、あるいは全てにおいて具現され、コンピュータ・システムを動作させる方法において具現され、コンピュータ・システム自体において具現され、システムを動作させる方法を実行するようプログラムされあるいは構成されるときコンピュータ・システムにおいて具現され、そして（または）システムを動作させる方法により動作するためのプログラムが記録されたコンピュータ読取可能な記憶媒体において具現されよう。
本文に用いられる用語「コンピュータ・システム」は、「コンピュータ」、「システム」、「装備」、「装置」、「マシン」などと互換される得る。コンピュータ・システムは、仮想マシンでありあるいは仮想マシンを含み得る。
上記のいずれかあるいは全てにおいて、方法および装置の特徴および特質を含む異なる特徴および特質は適切な方法において組合わされよう。
本発明が純粋に事例として記述されたこと、および詳細の修正が本発明の範囲内で可能であることが理解されよう。
本文の記述に開示された各特徴、および（適切な場合）請求の範囲および図面が、独立的にあるいは適切な組合わせにおいて提供される。

エージェント資料第３−コンピュータ・システム、コンピュータ読取り可能記憶媒体、および同媒体を動作させる方法、および同システムを動作させる方法
本発明は、コンピュータ・システムに関し、かつコンピュータ・システムを動作させる方法に関する。望ましくは、本発明は、コンピュータ・システムにおけるメモリの管理に関し、特にコンピュータ・システムにおけるキャッシュ・メモリの管理に関する。望ましい実施の形態においては、本発明は、低使用頻度のコードなどの空間的離隔のためのアウトライアに関する。
コンピュータ・システムにおいて、色々なレベルのキャッシュ・メモリが存在する。このことは、キャッシュ自体を有効に動作させることができるならば、改善された効率、従って速度に関してシステムにとって有利となる。本発明に関しては、キャッシュに、特に最も高速なキャッシュにおかれて頻繁に実行される見込みのあるコードを持つことが有利であることが判っていた。以下に述べる本発明の実施の形態において、ジャバ・コードは、ダイナミック・コンパイラを用いてランタイムにおいてより速く実行するようにコンパイルされる。有効なコード（密度）のキャッシュ密度を改善するため、本発明の目的の１つとして、キャッシュの最も速いものにダイナミック・コンパイラが生じたコンパイル・コードを置くことが有利となろう。

従来技術の解決法は、キャッシュ・メモリの密度を最大化するものではない。例えば、以下に更に詳細に論じるように、従来技術のシステムの高速キャッシュが、多くのキャッシュ・ミスを生じるおそれがあるキャッシュで頻繁にアクセスされるコード密度を減じる大量の頻繁にアクセスされないコードによってしばしば占有されることが判った。本発明は、上記の問題および（または）他の問題を軽減することを求めるものである。
本発明の第１の特質によれば、コードの主パス部分をコンパイルするよう構成されるコンパイラを含むコンピュータ・システムが提供される。
主パスは、コードを介する頻繁に実行される実行パスを表わし、コードの多数の個々のブロックを含む。主パスがコンパイルされるよう（かつ望ましくは主パスのみがコンパイルされるよう）構成することにより、コンパイル・バージョンが頻繁に実行されるコードのみを含むので、コードのコンパイル・バージンにおける有効コードの密度が増加される。このように、キャッシュにおける有効なコード密度を増加することができる。
主パスがコンパイルされるよう構成することにより、コードを介する最も頻繁に実行されるパスを含むコードのブロックがキャッシュに格納される見込みが多くなるように、かつ主パス・コードの他のブロックと同じ（Ｌ１）キャッシュに格納される見込みが多くなるように構成することが可能である。このように、主パスのランタイム実行を速くすることができる。

当該システムは更に、主パスについての情報を記録する実行履歴レコーダを含むことが望ましい。実行の走行中に主パスのオンライン・レコードが作られることが望ましい。従って、当該システムは、コードの実行中に主パス部分を決定する手段を含むことが望ましい。
当該システムは更にコードをコンパイルするコンパイラを含み、コンパイラは主パス部分をコンパイルするよう構成されることが望ましい。当該コンパイラはオンライン・コンパイラであることが望ましい。前記主パス部分が頻繁に実行されないコードは含まないことが望ましい。このように、コードの主パス部分がコードの頻繁に実行されない断片から切離して構成されるならば、システムのメモリの管理を改善することができる。
主パスのコンパイルにおける望ましい特徴の更なる論議は、本明細書のエージェント資料第１に見出すことができる。
当該システムは更に、実行パスが主パスを外す場合に使用されるアウトライアを含むことが望ましい。
本発明の第２の特質によれば、頻繁に実行されないコードの実行時に使用されるアウトライアを含むコンピュータ・システムが提供される。
例えば、コードの主要でない場所への条件付き転送により、あるいは検出される実行条件により、実行パスが主パスを外す場合、制御はアウトライアへ送られる。アウトライアは、制御が転送される主パスの部分と同じコード・バッファにあることが望ましい。
主パスは、その時の挙動に基いてコードを介する実行のあり得るパスの「最良の推測」である。これは、ときおりコードの特定の実行には適用し得ないことを証明する。
当該システムは更にインタプリタを含むことが望ましい。このインタプリタは、頻繁に実行されないコードの少なくとも一部を実行するため使用されることが望ましい。当該システムは更に、コンパイルされたコードとコンパイルされないコードの実行間に変換するコンバータを含むことが望ましい。このコンバータは、アウトライアを含むことが望ましい。
実行が条件付き転送により主パスを外した場合、アウトライアはインタプリタへの制御の転送を行うようになっていることが望ましい。
実行が遭遇する実行により主パスを外した場合、アウトライアが例外ハンドラヘ制御を転送するようになっていることが望ましい。

前記アウトライアは、頻繁に実行されないコードの実行前に状態を更新するようになっていることが望ましい。例えば、新たな部分がコンパイルを保証するまで典型的に解釈される新たな主要でないパスへ制御が渡される場合、例えば主パスのコードのコンパイルにおいて最適化が用いられた場合に更新が要求される。
コードは、アウトライアへの条件付き分岐を含み、条件付き分岐が条件付きテストを含み、かつ条件付きテストが失敗するならば、実行が主パスに従うようにすることが望ましい。プロセッサは、しばしば、順方向分岐が失敗し、分岐が行われる前に種々の検査を行うことを予測する。分岐の条件がめったに生じず、その結果（主パスにおける）実行が失敗するならば、この条件に対するコードがコンパイルされるとき、このコードは、条件が真であるならば制御がアウトライアへ進むように構成される。このように、順方向分岐はめったに生じず、このため、プロセッサ検査はアウトライアへのめったに実行されないジャンプ時のみに行われる。このように、条件が通常は真でなく、実行が単に主パスを通るよう終わるので、プロセッサ時間は減少し得る。
当該システムは、頻繁に実行されないコードから頻繁に実行されたコードを分離する手段を含むことが望ましい。
このことは、独立的に提供される本発明の特に重要な特徴であり、従って本発明は更に、頻繁に実行されるコードと頻繁に実行されないコードとを分離する手段を含むコンピュータ・システムを提供する。
頻繁に実行されないコードから頻繁に実行されるコードを分離することにより、システムのメモリが更に効率的に管理されることが可能になる。例えば、この方法は、少数の頻繁に実行されないコードがキャッシュへ取入れられるよう構成することを可能にする。このことは、キャッシュのミスを減らすことによりランタイムにおいて頻繁に実行されるコードの改善された実行速度を与えることができる。コードを分ける手段は、以下に更に詳細に述べるように、特定の方法でコードをコンパイルするコンパイラにより提供される。この分離は、あるタイプのコードが１つの記憶領域に格納され、かつ他のタイプのコードが別の記憶領域に格納されるように構成することによって行われる。

当該システムは更に、アウトライアと、このアウトライアから主パス部分を分離する手段とを含むことが望ましい。
このため、システムは、頻繁に実行されるコードを第１の記憶領域に格納する手段と、頻繁に実行されないコードを第２の記憶領域に格納する手段とを含むことが望ましい。システムは、主パス部分を第１の記憶領域に格納する手段と、アウトライアを第２の記憶領域に格納する手段とを含むことが望ましい。第１の記憶領域と第２の記憶領域とは、コード・バッファの領域であることが望ましい。
頻繁に実行されるコードと頻繁に実行されないコードとは、コード・バッファの異なる領域において生成されることが望ましい。例えば、システムは、頻繁に実行されないコードをバッファの「後方」へ格納する手段を含む。システムは、主パス部分とアウトライアとをコード・バッファの反対の端部に格納する手段を含むことが望ましい。
コードをこのように格納することにより、頻繁に実行されないコードはキャッシュへ取入れられにくいが、頻繁に実行されるコードはキャッシュへ取込まれやすいようにコードを構成することが可能である。従って、コードは、頻繁に実行されないコードがキャッシュへ取入れられにくいように格納されることが望ましい。
このことは、本発明の特に重要な特徴であり独立的に設けることができる。このため、本発明は更に、コード・キャッシュを含むコンピュータ・システムを提供し、このシステムは頻繁に実行されないコードがキャッシュに取入れられにくいように構成される。
主パスのコンパイルにおいて、頻繁に実行されるコードがコンパイルされた主パス部分を含むことが望ましい。これらの部分は、コード・バッファにおいて順方向に生成されることが望ましい。アウトライアは、コード・バッファにおいて逆方向に生成されて、主パス部分から空間的に分けられることが望ましい。このように、コード・バッファにおいてアウトライアにより占められるメモリは、コンパイルされないコードの頻繁に実行されないコード部分の元の部分のコンパイル・バージョンよりも非常に少なくことができる。
本発明は更に、主パスのコンパイル・コードの実質的に全て（および、望ましくはこれのみ）を一緒に１つの記憶領域に格納する手段を含むコンピュータ・システムを提供する。当該システムは更に、主要でないケースを空間的に別の領域で処理するコード記憶手段を含むことが望ましい。
本発明はまた、コンピュータ・システムを動作させる方法をも提供し、この方法はコードの主パス部分をコンパイルすることを含む。当該方法は、コードの実行中に主パスを決定することを含むことが望ましい。

アウトライアは、実行パスが主パスを外れるときに使用されることが望ましく、またアウトライアはインタプリタおよび（または）例外ハンドラに対する制御の転送を行うことが望ましい。
アウトライアは、頻繁に実行されないコードの実行前に状態を更新することが望ましい。
コードがアウトライアへの条件付き分岐を含む場合、条件付きテストが失敗するならば、前記条件付き分岐が、実行が主パスに追従するような条件付きテストを含むことが望ましい。
当該方法は、頻繁に実行されないコードから頻繁に実行されるコードを分離することを含むことが望ましい。
更に本発明により提供されるのは、頻繁に実行されるコードと頻繁に実行されないコードとを分けることを含むコンピュータ・システムを動作させる方法である。
当該方法は、アウトライアから主パス部分を分離することを含むことが望ましく、また主パス断片を第１の記憶域に格納し、アウトライアを第２の記憶域に格納することが望ましい。第１の記憶域と第２の記憶域とは、コード・バッファの領域であることが望ましい。当該方法は、主パスの断片とアウトライアとをコード・バッファの反対端部に格納することを含むことが望ましい。
当該方法は、頻繁に実行されないコードがキャッシュへ取込まれにくいようにコードを格納することを含むことが望ましい。
本発明はまた、コード・キャッシュを含むコンピュータ・システムにおけるコードの格納方法を提供し、当該方法は頻繁に実行されないコードがキャッシュに格納されにくいようにするものである。
本発明によれば、主パス・コードをコンパイルし、このコンパイル・コードを１つの記憶域に格納するステップを含む、コンピュータ・システムを動作させる方法が更に提供される。当該方法は、アウトライアを別の記憶域に格納することを含むことが望ましい。
また本発明によれば、頻繁に実行されないコードがアウトライアとは別になるように行われる、コードをコンパイルする方法も提供される。
本発明はまた、先に述べた方法によりコンピュータ・システムに格納されるコードを提供し、また本発明によりコードをコンパイルするコンパイラを提供する。
本発明は更に、本発明による方法を実施するためプログラムが記録されたコンピュータ読取可能な記憶媒体を提供する。
本発明はまた、頻繁に実行されるコードがアウトライアとは別になるように行われるコードのコンパイルのため、プログラムが記録されたコンピュータ読取可能な記憶媒体を提供する。
本発明は更に、前述のような方法に従ってプログラムされたコンピュータを提供する。

本発明はまた、頻繁に実行されるコードがアウトライアとは別になるように行われるコードのコンパイルのためプログラムされたコンピュータを提供する。
従って、本発明は、望ましくはアウトライアは空間的に別の領域にのみ格納されるが、主パスのコードの実質的に全て（および望ましくは、これのみ）を一緒に１つの記憶域に格納する手段を含むコンピュータ・システムを提供する。このようなメモリのレイアウトは、典型的にキャッシュへロードされる有効コード量を最大化する。
本発明はまた、アウトライアは別の記憶域に格納することが望ましいが、主パスのコードの全てをコンパイルし、コンパイル・コードの実質的に全てを１つの記憶域に格納するステップを含む、コンピュータ・システムを動作させる方法を提供する。
「アウトライア」は、優先して実行されるコードのため通常の記憶域外に存在するので、このように呼ばれる。このように、主要でないパスを意味する頻繁でないコードは、更に頻繁に用いられる主パス・コードとは分離され、従って、主パスが実行中であるかぎりキャッシュへロードされることがない。
本発明の特質のいずれか、あるいは一部、あるいは全てが、他の任意の特質に適用され得る。
以下の考察は、先に述べた本発明のいずれかおよび全て、および本発明の特質に適用する。
適切な場合、純粋に事例として、（上記の改善を略図的に示す）添付図面が参照される。
図３Ａは、計算１、２、３、４および５をそれぞれ実施するブロックＢ１、Ｂ２、Ｂ３、Ｂ４およびＢ５を含むジャバ・バイトコードの部分を示している。Ｂ４は、Ｂ１、Ｂ２またはＢ３において生じる例外を処理するコードである（Ｂ４に対するパス９０００、９００２および９００４を参照）。ブロックを介する主パスは、Ｂ１の終りにおける制御の条件付き転送時に制御が（ほとんど）つねにＢ１からＢ３へ進み（パス９００６）Ｂ３が制御をＢ５へ進む（パス９００８）如きものであることが判る。パス９０００、９００２および９００４は、ほとんど利用されない。

図３Ａの事例に対する元のジャバ・ソースの概要は、

主として条件が偽であり、かつ計算１、２または３はいずれも捕捉項（ブロックＢ４）により捕捉される例外に遭遇しないものとする。従って、このような動的な挙動に基く有効コードは、もっぱらブロックＢ１、Ｂ３およびＢ５からなる。
（特に、ランタイム時のコンパイルの場合における）このようなコードに対する標準的なコンパイル手法は、５つ全てのブロックに対してコードを注入することであり、コンパイル・コードの以降の実行における全ての偶然を許容する。このため、Ｂ２およびＢ５の潜在的にむだなメモリ・スペースのコンパイル・バージョンは、以下に述べるように、望ましい実施の形態に比して、有効コードのキャッシュ密度の低減をもたらし得る。このような方法の多くがこのような標準的な方法でコンパイルされるならば、コンパイル・コードを包含するため用いられるより広い範囲のアドレス・スペースは、アドレス・スペース・ページ境界にわたる制御の転送を更に頻繁にもたらし得、その結果（仮想メモリがコンピュータ・システムにおいて使用可能にされるならば）望ましい実施の形態と比してページ・フォルトの頻度が高くなる。
プログラムが走るとき、プロセッサは、メモリから命令を取出す。プログラムに対する命令が１ページの終りまで走るとき、次のページが主メモリになければ、メモリ・マネージャは次のページを見出し検査するため照会されねばならない。これは時間を要する。従って、ページ境界にクロスすると時間を要する。
コードの標準的なコンパイルが図３Ｂに示される。ブロックＢ１、Ｂ２、Ｂ３、Ｂ４およびＢ５が逐次セットアウトされる。

図３Ｃは、望ましい実施の形態によるコンパイル・コードを示している。主パスがブロックＢ１、Ｂ３およびＢ５を含むことに注意されたい。
コードのコンパイルは、ブロックＢ１における条件テストのロジックを反転させ、その結果予測されるフォール・スルーのケースはブロックＢ３に対するものとなり、制御の予測されないフローはアウトライアＯＬ１に対するものとなる。ブロックＢ１およびＢ３に対するコードは、ソースおよびバイトコードのレベルでは隣接していないにも拘わらず、スペース的に連続していることに注意されたい。このことは、分岐予測ハードウエアを備える最近のプロセッサにとって有利である。このような定義による隣接性がブロックＢ２が間に挿入された場合より小さな範囲のメモリ・アドレス・スペースで済むことも注意されたい。
ブロックＢ２およびＢ４は、これらが主パスの一部でないことが判っていたので、コードのコンパイル・バージョンには存在しない。
Ｂ５もまたブロックＢ３とスペース的に隣接しており、例外ハンドラＢ４へジャンプするためバイトコードに存在する元の無条件の制御転送は、対応するホスト命令を要求しない。ブロックＢ３は、制御フローに関して単にブロックＢ５へ直結している。このため、ブロックＢ１、Ｂ２およびＢ５は、スペース的に隣接しており、従ってブロックＢ３およびＢ４が散在されるより合計において小さな範囲のメモリ・アドレス・スペースで済む。これらのブロック（Ｂ１、Ｂ２およびＢ５）は、ジャバ・方法の今日の実行特性をモデル化するようにパッケージされてきた。

Ｂ１が最初に制御を受取り、プロセッサへキャッシュ・ラインのローディングを要求すると、直ちに影響を受けるキャッシュ・ラインに優れたキャッシュ密度をもたらす。（ブロックＢ２およびＢ４において）頻繁に実行されないコードは、キャッシュへ取込まれることがない。
次に、同様な方法で所与のコード・バッファへコンパイルされる幾つかの方法（または、その主パス）について考察しよう。これらが制御を相互に渡すので、キャッシュの摂動は，有効コードのより大きなキャッシュ密度を持つことによって低減されることになる。低いキャッシュ密度は、更に頻繁にキャッシュの衝突およびキャッシュのミスをもたらし得る。また、コンピュータ・システムが仮想メモリを用いる場合、望ましい実施の形態は、頻繁に実行可能なコードに対するアドレス・スペースの使用における低減の結果、ページ・フォルトの低減を生じ得る。プロセッサがメモリにない命令を実行しようとするとき、ページ・フォルトが生じる。ページ・フォルトが生じると、実行されるべき命令が見出されるページが仮想メモリとして用いられる恒久的記憶装置からメモリへロードされる。これは、実行速度を低下させる時間を要する動作である。

図３Ｃは、実行が主パスから外れる場合に使用されるアウトライアＯＬ１およびＯＬ２を示している。条件付きテストがＢ１の終りに通るならば、制御はＯＬ１へ進む。ＯＬ１は状態と同期し（すなわち、レジスタのキャッシュ値が再びそれらの対応する記憶場所へ溢れることを保証し）、次いで制御を１つのグルー・コードへ送りフォールバック・インタプリタを介する計算２に対応する予測されない（主要でない）パスの再開を生じる。ダイナミック・コンパイルを保証するのに充分に頻繁な主要でないパス実行の対応バイト・コードの如きときまで、これらバイトコードが解釈し続け、これによりバイト・コード実行の更に重要なパスに対するコード・バッファにおけるスペースを節減する。このように、ＯＬ１のタイプのアウトライアが、計算２の実行を必要とするように、正常な制御のフローが主パスから外れた予測されないパスをとる場合を処理する。
ＯＬ１のようなアウトライアのコードの一例は、下記のとおりである。
a＝r_ｎ //a,b,cに対する状態を更新し記憶場所を復元する
b＝r_ｍ
c＝r_ｓ
callglue (3000)//グルー・コードを呼出し、バイト・コード・アドレス3000
からコンパイルされないコードを解釈するよう指示する

インタプリタは、ブロックＢ２の初めに実行を開始する。３０００におけるバイト・コードが充分に実行されるならば、これは後でコンパイルされる。次にグルーが３０００から解釈するよう指示されると、Ｂ２のコンパイルされたバージョンが存在することを認識する。ＯＬ１の「ｃａｌｌｇｌｕｅ」ラインを（自動的に）「ｇｏｔｏ．．．」するよう変更して制御をコンパイル・バージョンへ向ける。これは、「パッチング」として知られる（本明細書のエージェント資料第１２参照）。このように、次にアウトライアＯＬ１が呼出されると、制御はグルーを用いることなく直接ｂ２へ送られる。（本明細書のエージェント資料第１も参照。）
異なるタイプのアウトライアＯＬ２は、例外条件が主パス内で認識される状況を処理する（例えば、ブロックＢ１が、その適法の境界外のアレイにアクセスしようとする）。主パスは、例外を処理するため制御をアウトライア（ＯＬ２）へ送る。ここで、アウトライアは、通常状態を同期させ、次に仮想マシン内に例外を生じるため制御をグルー・コードへ送る。

ＯＬ２のようなアウトライアのコードの一例は、下記のとおり。
a＝r_ｎ //状態の更新、a,b,cに対する記憶場所を復元する
b＝r_ｍ
c＝r_ｓ
callglueが例外Ｘを生じる //タイプＸの実行を処理するため、グルーに制御 を実行 ハンドラへ送るよう指示する
グルー・コードの使用およびインタプリタへの制御の転送の更なる論議は、本明細書の項「エージェント資料第１」に見出すことができる。
図３Ｃには明瞭にするため２つのアウトライアのみが示された。実際には、各例外および生じ得る主パスからの各偏差を処理するため、個々のアウトライアが提供される。
アウトライアは、関連する主パスと対応するこれらコードのブロックから空間的に遠く離れている。実行中に予測されない、すなわち例外の挙動に遭遇するとき、所与のコンパイルが、主パスにより使用されるアウトライアの主パスに対する１組のブロックと別の１組のブロックを生じる。
図３Ｄは、コンパイル・コードのブロックおよびコード・バッファ９０５４へ充填されるアウトライアを示している。主パスのブロックが方向９０５６においてブロックへ充填され、アウトライアは方向９０５８において充填される。主パスのブロックは、コード・ブロックの一端部を占有し、そのアウトライアは他端部を占有する。コードの新たな断片の各コンパイルが、主パスのブロックおよびアウトライアの新たな組を生じ、コード・バッファはアウトライアと主パスのブロックが相互に成長するように設計される。従って、正常な実行過程において、アウトライアが実行されない場合、これらアウトライアの存在がプロセッサのキャッシュの挙動に関してシステムにおいてトランスパレントであることが判る。こに有効コードの最大キャッシュ密度および有効コードの最大アドレス・スペース密度が得られる。

コード・バッファはコンパイラ・マネージャにより管理され、このマネージャがバッファの高メモリ端部と低メモリ端部のどこにあるかを示す。コンパイル・コードがブロックに対して生成されると、ブロックのコンパイル・バージョンがバッファに入れられ、その後アウトライアに対するコードのブロックが続く。次にアウトライアに対するコードは、ブロックの反対側へ移される。このように、主パスのブロックおよびアウトライア・ブロックが別の端部からバッファを埋める。このことは、キャッシュ密度を改善し、ページング問題を減じる。
代替的な実施の形態においては、主パスのコード・ブロックとアウトライアは、ブロックの同じ端部から埋めることができるが、コードの各断片ごとのブロック単位である。上記の事例では、バッファはｂ１、ｂ３、ｂ５、ＯＬ１、ＯＬ２、ＯＬ３、、、を（この順序で）含むことになる。コンパイルされる次の断片もまた、主パスのブロックに対するコードを展開し、その後アウトライアのコードが続く。しかし、このような構成は、アドレス・スペースがアウトライアにより費消されてアウトライアのコードがキャッシュへ取込まれる機会がより大きくなるので、望ましくない。
図３Ｅが示すように、プロセッサ・チップ９２００が４００ＭＨzの速さで動作し、オンボードの１６Ｋの第１レベルのメモリ・キャッシュ９２０２と関連させ得る。例えば５１２Ｋの第２レベルのキャッシュ９２０４は、チップ９２０６と関連させられる。これらは、第１および第２レベルのキャッシュ・メモリの４００ＭＨzより著しく低い速度で動作するおそらくは３２ＭＢの通常のＲＡＭ９２０８に加わる。動作において、プロセッサは、一時に１行ずつキャッシュから命令を取込む（３２バイト）。最も頻繁に使用されるコード、すなわちコンパイルされた主パス・コードがそれほど頻繁に使用されないコードから別の記憶域に格納されることを保証することにより、キャッシュにおいて最も頻繁に使用される命令の密度を増すことができる。この過程においては、それほど頻繁に使用されない命令もまた一緒に格納されるが、キャッシュでないメモリに格納され、これによりキャッシュを汚染することがない。

頻繁に実行される断片の識別
コードの一部の頻繁に実行されない断片から頻繁に実行される断片を分けるために、頻繁に実行されるこれら断片を最初に識別することが必要である。これは、コードの実行ランを分析して、コードを介して最も頻繁に実行されたパス（主パス）を識別することによって実施可能である。主パスは、コードの前のランから決定することができる。本発明の望ましい実施の形態において、主パスは実行中オン行で動的に決定される。主パスの決定の詳細な論議については、頭書のエージェント資料第１に見出すことができる。要約すれば、コードの各ブロックが実行される回数は、実行履歴レコーダにより記録される。実行履歴レコーダは、ブロックが実行されたことを知り、かつ制御がどこから送られたかを知り、また（制御がブロックから移る）後続ブロックをも知る。この情報から、各ブロックの最も頻繁な後続部を決定することができ、またこれにより主パスを見出すことができる。
コードがジャバ・アプリケーションのコードである場合は、このコードはインタプリタにより最初に翻訳される。実行履歴レコーダは、インタプリタにより走らされ、各ブロックの解釈についての情報を記録する。いったんブロックがインタプリタにより閾値回数だけ実行されると、インタプリタはブロックの詳細をコンパイラ・マネージャにより管理されるコンパイルの待ち行列へ送る。この回数の閾値は５である。コンパイラ・マネージャが待ち行列を調べてコンパイルされるブロックを得ると、マネージャはブロックの解釈に関して実行履歴レコーダにより記録された情報を用いて、このブロックおよびその最も頻度の高い後続ブロックから主パスを追跡する。次に、コンパイラは、以下に更に詳細に述べるように、コードの主パス部分のコンパイル・バージョンを生じる。

例えば、図３Ａに略図的に示したような全般的構造を持つコンパイルされないコードの一部については、コードのブロックを介する実行パスは通常Ｂ１、Ｂ３、Ｂ５である。ブロックＢ１が５回実行されたとき、このブロックはコンパイルのため待ち行列に置かれる。コンパイラは、Ｂ１から主パスを追跡し、実行がときに生じても、Ｂ１の最も高い頻度の後続ブロックがＢ３であったこと、およびＢ３の最も高頻度の後続ブロックがＢ５であったことを見出す。このように、Ｂ１からの主パスはＢ１、Ｂ３、Ｂ５である。その後、コンパイラは主パスのコンパイル・バージョンを生じるよう進む。

主パスのコンパイル
コードＢ２およびＢ４の頻繁に実行されない部分のコンパイル・バージョンは用意されない。代替的な実施の形態においては、コードのコンパイル・バージョンは用意され得るが、これらのコード部分のコンパイルは時間を要し、コンパイル・バージョンはメモリ・スペースを占有し、このため、代替的な実施形態は、例えば仮想マシンにおけるメモリが制限される場合には魅力がない。
断片Ｂ１、Ｂ３、Ｂ５は逐次展開される（図３Ｃの断片ｂ１、ｂ３、ｂ５参照）。例えば、公知の最適化手法を用いて、コードのコンパイルにおける最適化が行われる。例外検査は、コンパイル・コードにおける関連する位置に挿入され、この例外検査はコンパイルされないコードのブロックＢ１、Ｂ３、Ｂ５における最初の検査に対応する。例外検査はそれぞれ、アウトライアと呼ばれるコードの関連部分へのジャンプを含む（Ｂ１における例外については、ＯＬ２が示される）。先に示したように、例外の処理のためには、アウトライアがコードＢ４のコンパイル・バージョンは含まないことが望ましい。アウトライアは、コードのコンパイル・バージョンからの制御の転送前に必要な状態およびレジスタを更新するためのコードを含む。
例えば、ブロックＢ１の終りにおける転送に対応する条件付き転送時にコンパイル・コードが最適化された場合、ブロックｂ１の終りでは一部の状態がまだ更新されていないことがある。また、コードのコンパイル・バージョンは、元のコードの記憶場所とは異なる記憶場所に状態を保持しているかも知れない。アウトライアＯＬ１は、状態の全てを更新して、これら状態がブロックＢ１からＢ２への制御の転送時にそうであったものに登録する。次に、アウトライアＯＬ１は、制御を変換装置へ転送し、この装置が制御をインタプリタへ転送し、このインタプリタがＢ２に対するコードの解釈へ進む。いったん例外が処理されると、適切な場合は、制御はグルー・コードを介して再びアウトライアへ戻すことができ、このアウトライアが更新された状態を復元し、コンパイル・コードの実行がブロックｂ３において再開し得る。変換装置およびグルー・コードの役割の更なる論議については、項「エージェント資料第１」を参照されたい。
ほとんどの場合例外が生じず、実行は単にブロックｂ１、ｂ３、ｂ５を通り過ぎることが理解されよう。

先に示したように、コンパイル・コードはコード・バッファにおいて順方向に生成され、アウトライアはコード・バッファにおいて逆方向に生成され、その結果これらがバッファにおいて空間的に分けられる。このように、アウトライアは、キャッシュへ取込まれにくい。例外の（アウトライアを介する）実行は頻繁に実行されないコードが主パスのコードと共にキャッシュされた場合より遅くなるが、この速度の低下は、特に頻繁に実行されないコードの実行が非常にまれである場合に、主パスの高い実行速度による補償以上のものである。
本発明の方法を実施する装置は、図３Ｆに略図的に示されている。当該装置は、コードの解釈のためのインタプリタ９３００を含んでいる。実行履歴レコーダ９３０２は、インタプリタ９３００によるコードの実行の詳細を記録する。ブロックが予め定めた回数だけ実行されると、実行履歴レコーダ９３０２が、コンパイルのためのブロックの待ち行列を管理するコンパイラ・マネージャ９３０４へ通知する。コンパイラ９３０２は、待ち行列を調べてコンパイルされるブロックを得、実行履歴レコーダ９３０２のレコードから主パスを決定して主パスの部分をコンパイルし、この部分に対して必要なアウトライアを用意する。コンパイルされた部分は、コード・バッファ９３０８へロードされる。主パスの部分はバッファ９３０８において順方向にロードされ、アウトライアはバッファ９３０８において逆方向にロードされる。時には、バッファ９３０８におけるコンパイル・コードの行がキャッシュ９３１０へ取込まれる。コンパイルされたコードは、バッファ９３０８あるいはキャッシュ９３１０から実行装置９３１２により実行される。主パス・コードでは処理できない実行に遭遇すると、アウトライア９３１４が何らかの必要な状態を更新して、例外の処理のためコードを解釈するよう進むインタプリタ９３００へ制御を送るグルー・コード９３１６へ転送する。
本発明の上記の特徴の一部あるいは全ては、コンピュータ・ソフトウエアを用いて実現された。しかし、無論、当業者には、これらの特徴のいずれもハードウエアあるいはハードウエアとソフトウエアの組合わせを用いて実現できることが明らかであろう。更にまた、ハードウエア、コンピュータ・ソフトウエアなどにより行われるファンクションが電気信号などを用いて実施されることは容易に理解されよう。
情報の記憶に関する特徴は、適切な記憶域またはストアにより実現される。情報の処理に関する特徴は、ソフトウエアあるいはハードウエア、あるいはその組合わせにいずれかにおいて、適切なプロセッサまたは制御手段によって実現される。

上記の一部あるいは全てにおいて、本発明は、下記の形態のいずれか、あるいは一部、あるいはその全てにおいて具現され、コンピュータ・システムを動作させる方法において具現され、コンピュータ・システム自体において具現され、コンピュータ・システムを動作させる方法を実行するよう構成されたプログラムによればコンピュータ・システムにおいて具現され、および（または）システムを動作させる方法に従って動作するようになされたプログラムが記録されたコンピュータ読取可能な記憶媒体において具現される。
本文に用いられる如き用語「コンピュータ・システム」は、「コンピュータ」、「システム」、「装備」、「装置」、「マシン」などと互換であり得る。コンピュータ・システムは、仮想マシンでありあるいはこれを含むものでよい。
方法および装置を含む上記、および他の特徴および特質の一部あるいは全てにおいて、特徴および特質はどんな適切な方法においても組合わせることができる。
本発明が純粋に事例として記述されるものであり、細部の修正が本発明の範囲内で可能であることが理解されよう。
本文に開示される各特徴、および（適切な場合）請求の範囲および図面は、独立的に、あるいは何らかの適切な組合わせにおいて提供することができる。

エージェント資料第４−コンピュータ・システム、コンピュータ読取可能な記憶媒体およびその動作方法、およびコンピュータ・システムを動作させる方法
本発明は、「インターフェース」の抽象化を、特にジャバにおいて用いるオブジェクト指向言語の最適化された実行に関するものであることが望ましい。望ましい実施の形態においては、本発明は、インターフェースの諸法に対するディスパッチ機構に関するものである。
ジャバは、インターフェースによる、クラス・タイプの単一の継承をサポートする。インターフェース自体は、他のインターフェースから様々な継承内容であり得る。具体的なクラスが１組のインターフェースを実現することを要求するとき、各方法の実現方法をこれらインターフェースにより直接あるいは間接的に提供しあるいはこれを継承されねばならない。資料［２］を参照されたい。
オブジェクト指向プログラミングにおいては、オブジェクトは、各オブジェクトが属性（その特徴すなわち特質についてのデータ）および方法（オブジェクトが行うファンクション）と関連した階層的構造において分類される。このようなファンクションは、典型的に、モバイルその他の電話の関連における「鳴奏（リング）」、あるいはオーディオおよび（または）ビデオの再生装置の関連における「再生（プレイ）」である。ジャバのようなオブジェクト指向言語における特徴の１つとして、オブジェクトの上位クラスの属性および方法は、そのサブクラスにより「継承」される。

例えば、図４Ａに示されるように、「ビークル」４００は、オブジェクトの「バイク」４０２と「カー」４０４の両クラスの上位クラスである。サブクラス「カー」は、「サルーン」４０６と「スポーツ」４０８とへ再分割でき、例えば、スポーツ・カーなどの製造会社名あるいはモデルに従って更なる再分割が可能である。車輪の数、モデルなどのサブクラス「カー」の属性は、サブクラス「サルーン」および「スポーツ」により継承される。同様な特質において、「ライトの点灯」などの方法は階層内ではカーにとって一般的であり得るが、あるサブクラスにおいては、方法自体は、実際にライトが点灯できる前にあるファンクションが行われなければならない程度に従って異なり得る。例えば、ポップアップ型ヘッドライトを備えるスポーツ・カーは、点灯できる前にライトを上昇させる必要がある。このような場合、継承は、問題となるあるファンクションを実施できる前にこのファンクションを実施する必要により取消されねばならない。
別の文脈においては、モバイルその他の電話のユーザは、電話の使用が仕事であるか社交であるかに従って異なる鳴奏音を出すように自分の電話セットを構成したいと思うかも知れない。このような関連では、「リング」は「インターフェース」と呼ばれることになる。その意味は、「リング」が階層における種々のオブジェクトが（先のカーの事例における「ライトの点灯」のように）生じるが、実際の構成はオブジェクトごとに異なるファンクションであることである。従って、インターフェースは、幾階層にも横断する。このように、インターフェースは、オブジェクトが行うことができるファンクション（「リング」、または「プレイ」、あるいは「レコード」などのような）のリストである。
１つの継承は、通常は、ディスパッチ・テーブル（仮想的なファンクションテーブルとしても知られる）を用いて実現される。サブクラスは、その上位クラスのディスパッチ・テーブルを継承し、これを新たな方法で拡張し、取消されたエントリに置換わる。
Ｃ＋＋のような言語における多くの継承は、多くのディスパッチ・テーブルおよびオフセット（詳細については、資料［１］参照）を用いて通常実現される。
関連するデータは、図４Ｂに略図的に示されるディスパッチ・テーブルのスロットに格納される。テーブル４１０におけるオブジェクトの属性はつねに、オブジェクトの開始点から同じ距離に置かれる。オブジェクトは、同じファンクションの開始点からつねに同じ距離にある方法のディスパッチ・テーブル４１４に対するポインタ４１２を含む。しかし、インターフェースの方法が用いられるとき、先に述べたように、ディスパッチ・テーブルのどのスロットに特定のファンクションが現われるかを知るより所はもはやない。このことは、多くの継承に固有のものであり、特にジャバ言語において見出されるインターフェースに固有の問題である。

今日まで、ディスパッチ・テーブルは全て、アクセスした方法が適正な方法であったことを調べるため照会されねばならなかった。理想的には、インターフェースに対する一義的な識別子が必要とされるが、実際にはテーブルは含まれる全てが一義的な識別子を持つようなサイズであり得ないことが実感された。
ファンクション「プレイ」の類比に関しては、例えばビデオ・レコーダに対して１つのディスパッチ・テーブルがあり、テープ・レコーダに対して１つのディスパッチ・テーブルがあることになる。それぞれが、異なるインターフェース参照を行うことになり、従って「プレイ」は、例えば、ビデオ・レコーダではポジション２にあり、テープ・レコーダではポジション２２となる。
インターフェースの方法に関わる論理的定義は、所与のオブジェクトのクラスにより直接あるいは間接的に構成される方法のリストを探すことである。これは明らかに遅くなる。このことは、ディスパッチ・テーブルをならう「フラット」な構造を探すことにより改善することができる。
資料［３］は、インターフェースの方法が見出された最後のオフセットが思い出され、最初の考えとして関与するインターフェースに次に遭遇する最適化について記載している。この考えが誤りであることが判ると、更に完全なサーチが行われる。このような試みは、所与の呼出しサイトが同じタイプのオブジェクトに対して働く傾向があるという前提に基くものである。
この考えが正しくても、それを確認するため識別の方法を調べなければならない。この考えが誤りである場合は、やや遅いサーチが必要となる。
別の試みは、多くの継承がサポートされるＣ＋＋の類似方法を用いることである。本発明は、オブジェクト指向言語におけるプログラムの実行中ディスパッチ時間を短縮する方法によってこの問題を解決するものであり、このプログラムは多数のインターフェース方法を有する。当該方法は、
（ｉ）ディスパッチ・テーブルを作成し、
（ii）対応するディスパッチ・テーブルにおける特定の場所に対する指標として、あるいはプログラムを実行するコンピュータに格納される方法としてのポインタを有する、１つ以上のディスパッチ・テーブルに対するインターフェース・ハッシュ・テーブルを作成し、
（iii）プログラムが特定のインターフェース方法を要求するステップを実行するとき、インターフェース・ハッシュ・テーブルを用いて、ディスパッチ・テーブルを介してかあるいは直接に前記インターフェース方法を探す
ステップを含んでいる。

前記方法は、本発明がプログラムに適用される場合に妥当するが、本発明はまた、「外部アプリケーション」を走らせるためにソフトウエアが「仮想の」コンピュータ・システムをエミュレートする「仮想マシン」の形態において適用可能である。しかし、前記ステップ（ii）および（iii）は依然として同様に適用される。
特に、本発明は、仮想マシンにおいてディスパッチ時間を短縮する方法をも提供し、仮想マシンにより実行される１組のプログラムが（ＣＤのような）コンピュータ読取可能な媒体に格納され、仮想マシンは、
（ｉ）ディスパッチ・テーブルを作成し、
（ii）１つ以上のディスパッチ・テーブルに対して、対応するディスパッチ・テーブルにおける特定の場所に対する指標として、あるいはプログラムを実行するコンピュータに格納される方法としてのポインタを有するインターフェース・ハッシュ・テーブルを作成し、
（iii）プログラムが特定のインターフェース方法を実行するとき、インターフェース・ハッシュ・テーブルを用いて、ディスパッチ・テーブルを介してか、あるいは直接的に前記インターフェース方法を探す
ことにより、プログラム実行の過程においてディスパッチ時間を短縮するよう働く。
ディスパッチ時間を短縮するこれらの方法は、明らかにジャバに対して特に適用され得る。本発明の実施の一形態では、ディスパッチ・テーブルに対し１つのインターフェース・ハッシュが存在する。本発明の別の実施の形態においては、全てのディスパッチ・テーブルに対して１つのインターフェース・ハッシュが存在する。
本発明の一形態では、ディスパッチ・テーブルがインターフェース・ハッシュ・テーブルを指示する。本発明の別の形態では、ハッシュ・テーブルは開始時はディスパッチ・テーブルの一部である。本発明のこのような後者の形態は、これにより１つのレベルのインダイレクションを排除する。
インターフェース・ハッシュ・テーブルは、例えば、ディスパッチ・テーブルのスロット数を含むことができる。あるいはまた、インターフェース・ハッシュ・テーブルはファンクション点を含み得、これにより１つのレベルのインディレクションを排除する。

本発明の少なくとも望ましい実施の形態の主な利点は、多くの状況において高速であることである。これは、一般的な場合にサポート・ルーチンを用いず、発呼者側における検査を必要としない。これは、一般的な場合を高速にし、かつ生成されるコードを小さくする。これはまた、クラスがインターフェースとして実現する場合に小さなハッシュ・テーブルを必要とするので、非常に少ないメモリ・オーバーヘッドで済む。小型で高速であることは、サイズまたはコストのゆえにメモリが制限されるモバイル電話のような用途では重要な特質である。
本発明の方法は、インターフェース・ハッシュ・テーブルにおける同じインターフェース方法を探すときに生じる衝突の場合に特別な回復方法を呼出すステップを含むことが望ましい。このような場合、ハッシュ・テーブルは、コンピュータに格納される方法を指示するか、あるいはディスパッチ・テーブルにおけるフォールバック・スロットを指示することができ、これは、クラスを「仕分け」て呼出しを適切な場所へ指向するよう設計される適切な格納された方法へ呼出しを再指向する。
本発明の最も広い特質によれば、このような問題に対する解決法はハッシュ・テーブルによる余分なレベルのインディレクションを用いることである。
ハッシュ・テーブルにおける衝突がない場合の大部分では、インターフェースの呼出しが、標準的な仮想的なディスパッチより僅かに遅く、インターフェース方法を呼出す公知の手法より速い。これはまた、特にディスパッチ・テーブルのスロットが情報の１つ以上のワードを含むときに、Ｃ＋＋の多重継承法より更にコンパクトであると予期される。
インターフェース・ハッシュ・テーブルに衝突が存在する場合、ディスパッチ・テーブルにおけるフォールバック・スロットが遅いが確実なサーチを行う。
本発明の他の特質によれば、要求される情報に対する高速アクセスの問題は、種々の装置の各々に対するインターフェース・ハッシュ・テーブルならびにディスパッチ・テーブルの使用によって解決されあるいは軽減される。

下記の考察は、先に述べた本発明のいずれかあるいは全て、および本発明の特質に対して適用する。
本発明の望ましい実施の形態については、純粋に事例として、（改善を略図的に示す）添付図面を参照して次に記述する。
本発明の実施の一形態については、事例としてのみ「仮想マシン」を実際に適用できる方法を示すため次に記述する。「仮想マシン」が非常に多くの異なるシステムに適用できるから、これが例示に過ぎないことが判るであろう。これらの事例は、（ハンド・ヘルド・コンピュータを内蔵する）モバイル電話、ディジタル・テレビジョン用のセットトップボックス、ＭＰＥＧディジタル・システムに使用されるよう意図されたビデオ装置、インテリジェント・ディスク・ドライブを含む。本発明は、物理的なサイズ（例えば、モバイル電話）によりメモリが制限され、ジャバのようなオブジェクト指向言語を用いてプログラムを実行する更に有効なモードが使用できる場合に、特に有効である。モバイル電話搭載のメモリは、例えば、５００ｋｂ以下に制限され、制限されたメモリを持つ環境においては本発明が良好に働く。しかし、これはまたそのようなメモリにおいても良好に走ることができる。
図４Ｄないし図４Ｆは、コンピュータ（図示せず）またはマイクロコントローラ（図示せず）が、「水」の供給すなわち流量（例えば、弁）、「熱」（例えば、時間、弁、ポンプ）、および「光」（例えば、スイッチ）の制御、および「ビデオ」システム（例えば、スイッチ）の動作の制御において使用される動作装置４６１−４６４の状態を制御するためのコントローラ・プログラム４６０を装備した家庭の環境に対して仮想マシンを用いる一例を略図的に示している。これらの動作装置４６１−４６４は、それぞれ、所要の動作を生じるためスイッチ、弁、ポンプなどへ適切な動力が与えられるように、プログラムの実行中にコントローラ・プログラム４６０から適切な指令信号を受取る各装置ドライバ４６５−４６８に接続されるように示される。入力４６９は、コントローラ・プログラムがユーザの要求に対して特定仕様とすることを可能にし、これにより、例えば現在では、加熱システムがオン／オフされ（その温度が調整され）、ビデオ・システムが再生状態にされる、などである。
次に図４Ｄにおいて、「装置」がサブクラス「ヒーティング・システム」および「電気装置」およびサブクラス「湯水システム」（または、洗浄用に使用される家庭用湯水）、「セントラル・ヒーティング」（空間の加熱に使用される閉循環系統である）、「照明」（各室における照明を含む）、および「ビデオ」（再生、録画、録音、カセットのイジェクション、などのための制御ファンクションを含む）に共通するオン／オフの方法を有するクラスである階層的構造で分類される家庭用システムの各部がオブジェクトとして示される方法を示している。更に、「ヒーティング・システム」は室温の制御を可能にする設定温度の方法を有し、「湯水システム」は（軟水化カートリッジが交換する必要のあるときを示すことが意図される）方法「リロード」を有し、サブクラス「照明」は方法「減光」を有し、サブクラス「ビデオ」は属性「再生」および「カセット交換」を有する。
図４Ｅは、このようなクラスおよびサブクラスに対するディスパッチ・テーブルを示している。全てのディスパッチ・テーブルにおいて、「オン」および「オフ」のファンクションがポジション１および２を占めている。しかし、「湯水システム」および「セントラル・ヒーティング・システム」に対するポジション３は、「温度設定」であるが、同じポジション３は「湯水システム」および「ビデオ」に対しては減光および交換である。方法「交換」は、軟水化装置におけるカートリッジの交換と、ビデオ・システムにおけるカセットの交換とを弁別する必要があるが、属性「交換」は他の点では類似している。図４Ｅでは、図面および記述を簡単にするため少数の制御ファンクションが示され、それらのディスパッチ・テーブルは通常は更に多くのスロットすなわちエントリを含むことになろう。

図４Ｄないし図４Ｆから、動作装置における類似のファンクションの制御において同じ方法が用いられるクラス／サブクラス（または制御ファンクション、すなわち方法）間にインターフェースが存在することが明らかである。１つのインターフェースは方法「オン／オフ」であり、別のインターフェースは方法「交換」である。各インターフェース方法は、小さなハッシュ値が割当てられる。このインターフェース・ハッシュ値は多くの方法で得ることができるが、ハッシュ・テーブルのサイズを越えてはならない。ハッシュ値は、インターフェース方法間の衝突をできるだけ減じるように選択される。これを行う１つの方法は、各インターフェース方法のネームから擬似ランダム・ハッシュ値か、あるいはインターフェース方法の他のややランダムな属性を得ることである。
任意の関連するインターフェース・クラスと衝突しない開始ハッシュ値を選択し、次にこれから逐次インターフェースの各メンバー方法ごとにハッシュ数を割当てることが望ましい。ハッシュ値は、同じインターフェースまたは関連するインターフェースの方法が一義的なハッシュ値を持ち競合すなわち衝突しないように選択されるべきである。多くのインターフェースを実現しあるいは多くの方法とインターフェースするオブジェクトは、明らかに衝突を避けることができない。大きなハッシュ・テーブルは通常は衝突数を減じる。
図４Ｃは、特定の階層（例えば、図４Ｄ）内のオブジェクト（例えば、ビデオ）に対するデータがテーブル４２０のようなデータ構造で配置される本発明の実施の一形態を示している。このデータ構造は、ヘッダと複数のオブジェクト・データ・フィールドとを含むことになる。ディスパッチ・テーブル４２２におけるスロットに格納された関連方法に対する呼出が行われると、この方法が配置される正確なスロットを知ることの不確定さのゆえに、ディスパッチ・テーブル４２２が、ディスパッチ・テーブル４２２における方法の場所の圧縮バージョンを含むハッシュ・テーブル４２４へこの呼出しを自動的に再び指向させることになる。また、ハッシュ・テーブル４２４内の場所が各方法に対してつねに同じであるゆえに、ハッシュ・テーブルは、ディスパッチ・テーブル内の全てのあり得る場所のサーチよりも速くディスパッチ・テーブル４２２における正しい場所に導く指標ポインタ４２６を生成することができる。他のハッシュ・テーブル（図示せず）およびそのそれぞれのディスパッチ・テーブルでも同じプロセスが続く。
ハッシュ・テーブルにおける衝突の場合には、同じ場所が２つのインターフェース方法に対して必要とされるので、ハッシュ・テーブルは、クラスを「はじく」よう設計されたコンピュータに格納される方法を指示し、発呼者を適切な場所へ指向させる。これはまた、コンピュータに格納された「はじく」方法を指示するディスパッチ・テーブル４２２におけるスロット（例えば、最初の）を最初に指示することによっても行うことができる。

更に一般的には、各実クラスが規定された後およびこれが実現する方法の組が知られると、各ディスパッチ・テーブルが生成される（ディスパッチ・テーブルは、その上位クラスから継承される方法の構成を勘定に入れることになる）。固定サイズのハッシュ・テーブルが、対応する構成のディスパッチ・テーブル指標に対して前述のインターフェース方法のハッシュ値をマップする各クラスごとに生成される。１つのクラスが同じインターフェースのハッシュ値を持つ２つ以上のインターフェース方法を構成する場合、ハッシュ・テーブルは、衝突を「はじく」フォールバック・ルーチンのディスパッチ・テーブル指標を含むように設定される。
このハッシュ・テーブルは、ディスパッチ・テーブルの初めに含まれるか、あるいはディスパッチ・テーブルから参照される。
（レジスタにおける）所与のオブジェクトにインターフェース方法を呼出すため、
ａ．所与のオブジェクトに対するインターフェース・ハッシュ・テーブルのアドレスをロードする
ｂ．インターフェース・ハッシュ・テーブルに対する指標としてそのハッシュを用いる特定のインターフェース方法に対するスロット数を取得する
ｃ．宛て先インターフェース方法に対する一義的な識別子をレジスタへロードする
ｄ．ディスパッチ・テーブルのスロット数が与えられると、正常な仮想的呼出しを行う。
上記ステップに対する擬似アセンブラ・シーケンサは、
ディスパッチ・テーブルにより指示されたインターフェース・ハッシュ・テーブル
LOAD Rd.doffs[Ro] ディスパッチ・テーブル・アドレスをロード
LOAD Ri,ioffs[Rd] インターフェース・ハッシュ・アドレスをロード
LOAD Ri,hash[Rｉ] ハッシュ・テーブルからのスロットをロード
LOAD Ru,#uniqlfaceld 一義的なインターフェースidをロード
LOAD Ri,[Rd +Ri] 方法アドレスを取得
CALL Ri インターフェース方法を呼出す。

ハッシュ・テーブルがディスパッチ・テーブルの一部である本発明の形態においては、１つのレベルのインディレクションが排除される。
ディスパッチ・テーブルで（前に）格納されたインターフェース・ハッシュ・テーブル
LOAD Rd,doffs[Ro] ディスパッチ・テーブル・アドレスをロード
LOAD Ri,-hash[Ri] ハッシュ・テーブルからスロットをロード
LOAD Ru,#uniqlfaceld 一義的なインターフェースidをロード
LOAD Ri,[Rd+Ri] 方法アドレスを取得
CALL Ri インターフェース方法を呼出す。

インターフェース・ハッシュ・テーブルが方法ポインタを含む本発明の形態においては、別のレベルのインディレクションが排除される。
インターフェース・ハッシュ・テーブルに格納された方法アドレス（プラス、前の最適化）
LOAD Rd,doffs[Ro] ディスパッチ・テーブル・アドレスをロード
LOAD Ri,-hash[Rd] ハッシュ・テーブルからアドレスをロード
LOAD Ru,#uniqlfaceld 一義的なインターフェースidをロード
CALL Ri インターフェース方法を呼出す。

特定のクラスに対するインターフェース・ハッシュ・エントリ間に衝突がある場合、インターフェース・ハッシュ・テーブルはフォールバック方法のディスパッチ・テーブル指標を含んでいる。このフォールバック方法は、（レジスタにおいて）宛て先オブジェクトにアクセスし、インターフェース方法の場合は一義的な識別子をアクセスする。この方法は、インターフェース方法の前記オブジェクトの構成について標準的なサーチを行う。
コンピュータ技術の当業者には、情報の密集度が低い場合、さもなければデータ・セット内に高い冗長度が存在する場合、ハッシュ・テーブルがデータ・セットを管理し得る割合まで低減する手段であることが判るであろう。このように、ハッシュ・テーブルは、アプリケーション全体のスケールを減じることができ、これにより装置の大きさを減じることができ、これはジャバの重要な特徴の１つである。

要約すれば、本願の発明は下記を含んでいる。
１．インターフェース方法に対するハッシュの使用
各インターフェース方法は、小さなハッシュ値が割当てられる。このインターフェース・ハッシュ値は多くの方法で得ることができるが、以下に用いられるハッシュ・テーブルのサイズを越えてはならない。
ハッシュ値がインターフェース方法間の衝突を減じるように選定されるならば最良であり、従って同じインターフェースまたは関連するインターフェースの方法が一義的なハッシュ値を持つようにハッシュ値が選定されるべきである。明らかに、多くのインターフェースまたは多くの方法とのインターフェースを構成するオブジェクトは、衝突を避けることができないことがある。
当然のこととして、ハッシュならば、テーブルが大きくなるほど衝突数が通常少なくなる。
２．インターフェース方法を呼出すときのハッシュ・テーブルを介するインディレクト
実際の各クラスが定義されると、このクラスが構成する方法の組が判り、ディスパッチ・テーブルが生成される。ディスパッチ・テーブルは、上位クラスから敬称された方法の構成を考慮に入れる。
固定サイズのハッシュ・テーブルが各クラスごとに生成され、これが対応する構成のディスパッチ・テーブル指標へ上記のインターフェース方法のハッシュ値をマップする。１つのクラスが同じインターフェース・ハッシュ値を持つ２つ以上のインターフェース方法を構成する場合、ハッシュ・テーブルは以下に述べるフォールバック・ルーチンのディスパッチ・テーブル指標を含むように設定される。
このハッシュ・テーブルは、ディスパッチ・テーブルの初めに含まれるか、あるいはディスパッチ・テーブルから参照される。
（レジスタにおける）所与のオブジェクトについてインターフェース方法を呼出すため、
ａ．所与のオブジェクトに対するインターフェース・ハッシュ・テーブルのアドレスをロードする
ｂ．インターフェース・ハッシュ・テーブルに対する指標としてそのハッシュを用いて指定されるインターフェース方法に対するスロット番号を取得する
ｃ．宛て先のインターフェース方法に対する一義的な識別子をレジスタへロードする
ｄ．ディスパッチ・テーブルのスロット番号が与えられると、正常な仮想呼出しを行う。
３．フォールバック・ディスパッチ・テーブルのエントリ
特定のクラスに対するインターフェース方法のハッシュ・エントリ間に衝突が生じる場合、インターフェース・ハッシュ・テーブルがフォールバック方法のディスパッチ・テーブル指標を含む。フォールバック方法は、宛て先オブジェクトに対して（レジスタで）アクセスし、インターフェース方法の場合は、一義的な識別子をアクセスする。
これは、インターフェース方法の当該オブジェクトの構成について標準的なサーチを行う。

コンピューティング技術の当業者には、情報が密集しておらず、さもなければデータ・セット内に高い冗長度が存在する場合に、ハッシュ・テーブルがデータ・セットを管理可能な割合まで減じる手段であることが判るであろう。このように、ハッシュ・テーブルは、アプリケーション全体のスケールを減じることができ、これにより装置の大きさを減じることができ、これはジャバの重要な特徴の１つである。オーバーフローは、ハッシュ・テーブルの利用においてすでに知られる方法で考慮に入れられる。
従って、本発明によれば、コンピュータ・システムは、１つのクラス階層におけるオブジェクトに適する方法を含むデータ格納する１つ以上のディスパッチ・テーブルと、問題となる方法が見出されるディスパッチ・テーブルの場所を指示するインターフェース・ハッシュ・テーブルとを含む。
本発明はまた、１つのクラス階層におけるオブジェクトに適する方法を含むディスパッチ・テーブルを用いるコンピュータ・システムを動作させる方法を提供し、該方法は、１つの方法の呼出しをディスパッチ・テーブルへ指向させ、ディスパッチ・テーブルにおける方法の場所についての情報を含むハッシュ・テーブルへ呼出しを送り、この呼出しをハッシュ・テーブルから方法が格納されるディスパッチ・テーブルの前記場所へ再指向させるステップを含んでいる。
本発明はまた、オブジェクトに関するデータを格納する手段と、前記オブジェクトに適する方法に関するデータを呼出す手段と、少なくとも１つの前記方法に関するデータを含むためのディスパッチ・テーブルと、前記呼出しを前記ディスパッチ・テーブルにおける方法の場所についての情報を含むハッシュ・テーブルへ送る手段と、呼出された方法の場所にアクセスするためハッシュ・テーブルからの呼出しをディスパッチ・テーブルへ再び指向させる手段とを含むコンピュータ・システムを提供する。

本発明の一形態においては、ディスパッチ・テーブルごとに１つのインターフェース・ハッシュが存在する。本発明の別の形態では、全てのディスパッチ・テーブルに対して１つのインターフェース・ハッシュ・テーブルが存在する。
あるいはまた、本発明は、ハッシュ・テーブルを用いることによりインターフェースのディスパッチ動作の性能を改善する方法と、インターフェースのディスパッチ動作の性能を改善するハッシュ・テーブルを含むコンピュータ・システムとの両者を提供する。
本発明は、別の特質において、特定の方法に対するインターフェース参照がハッシュ・テーブルにより見出される方法およびコンピュータ・システムを提供する。
「インターフェース・ディスパッチ動作」が、特定の方法に対するスロットの場所、例えば、ビデオ・レコーダの「再生」ファンクションに対するスロットの場所番号（２）が見出され、次いで関連するデータが呼出される方法であることが理解されよう。
本発明の主な利点は、速いインターフェース・ディスパッチ動作および（または）規模の大きさの低減を含む。
いずれの場合も、前項で述べたような本発明の方法またはコンピュータ・システムは、特にジャバに対して適用され得る。
当該システムの動作は、別の方法において調べることができる。このため、図４２においては、特定の階層内のオブジェクトに対するデータがテーブル４２０のようなデータ構造で配置される。このデータ構造は、ヘッダと関連データを含む複数のフレームとを含んでいる。ディスパッチ・テーブル４２２におけるスロットに格納された関連データに対する呼出しが行われると、この方法が配置される正確なスロットを知ることが不確実であるために、ディスパッチ・テーブル４２２は、ディスパッチ・テーブルにおける方法の場合の圧縮バージョンを含むハッシュ・テーブル４２４へ呼出しを自動的に送り直すことになる。また、ハッシュ・テーブル内の場所が各方法に対してつねに同じであるので、ハッシュ・テーブルは、ディスパッチ・テーブルにおける正しい場所に導く指標ポインタ４２６を、ディスパッチ・テーブル内の全てのあり得る場所のサーチよりも更に迅速に生成することができる。

ハッシュ・テーブルにおける衝突の場合は、おそらくは２つのインターフェース方法に対して同じ場所が必要とされるので、あるいはおそらくはマルチスレッド環境における２つの異なるスレッドによって呼出されるゆえに、ハッシュ・テーブルは、クラスを「整理する」ように意図された方法を指示して、発呼者を適切な（単数または複数の）場所へ指向させることになる。
上記のことのいずれかあるいは全てにおいて、コンピュータ・ソフトウエアを用いて本発明のある特徴が構成された。しかし、無論、当業者にとっては、これらの特徴のいずれもハードウエアまたはハードウエアとソフトウエアの組合わせを用いて実現されることが明らかであろう。更に、ハードウエア、コンピュータ・ソフトウエアなどにより行われるファンクションが電気信号などを用いて行われることは容易に理解されよう。
情報の記憶に関する特徴は、適切な記憶場所またはストアによって実現されよう。情報の処理に関する特徴は、ソフトウエアまたはハードウエア、あるいは両者の組合わせのいずれかにおいて、適切なプロセッサまたは制御手段により実現されよう。
上記のことのいずれかあるいは全てにおいて、本発明は、下記の形態のいずれか、あるいは一部、あるいはその全てにおいて具現され、コンピュータ・システムを動作させる方法において具現され、コンピュータ・システム自体において具現され、前記コンピュータ・システムを動作させる方法を実行するようプログラムされるときこのコンピュータ・システムにおいて具現され、そして（または）このコンピュータ・システムを動作させる方法に従って動作するようにされるプログラムが記録されたコンピュータ読取可能な記憶媒体において具現されよう。
本文全体で用いられるように、用語「コンピュータ・システム」は、「コンピュータ」、「システム」、「装備」、「装置」、「マシン」などと互換であり得る。コンピュータ・システムは、仮想マシンであり得、あるいはこれを含み得る。
方法および装置を含む上記の異なる特徴および特質のいずれかあるいは全てにおいて、特徴および特質は任意の適切な方法で組合わされる。
本発明がこれまで純粋に事例として記述され、細部の修正が本発明の範囲内で可能であることが理解されよう。
本文の記述、および（適切な場合に）請求の範囲および図面において開示される各特徴は、独立的に、あるいは何らかの適切な組合わせにおいて証明されよう。

他の情報
関連する特許：米国特許第５，３６７，６８５号
文献：
［１］ Ｍ．ＥｌｌｉｓおよびＢ．Ｓｔｒｏｕｓｔｒｕｐ著「Ｔｈｅ Ａｎｎｏｔａｔｅｄ Ｃ＋＋Ｒｅｆｅｒｅｎｃｅ Ｍａｎｕａｌ」（Ａｄｄｉｓｏｎ Ｗｅｓｌｅｙ（ＩＳＢＮ ０−２０１−５１４５９−１）、２１７−２３７ページ）
［２］ Ｋ．ＡｒｎｏｌｄおよびＪ．Ｇｏｓｌｉｎｇ著「Ｔｈｅ Ｊａｖａ Ｐｒｏｇｒａｍｍｉｎｇ Ｌａｎｇｕａｇｅ」（Ａｄｄｉｓｏｎ Ｗｅｓｌｅｙ（ＩＳＢＮ ０−２０１−６３４５５−４）第４章）
［３］ Ｔ．ＬｉｎｄｈｏｌｍおよびＦ．Ｙｅｌｌｉｎ著「Ｔｈｅ Ｊａｖａ Ｖｉｒｔｕａｌ Ｍａｃｉｎｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ」（Ａｄｄｉｓｏｎ Ｗｅｓｌｅｙ（ＩＳＢＮ ０−２０１−６３４５２−Ｘ）２５８−２６０、４０３−４０５ページ）
［４］ Ａ．Ｗ．Ａｐｐｅｌ著「Ｍｏｄｅｒｎ Ｃｏｍｐｉｌｅｒ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ ｉｎ Ｊａｖａ」（第１４章、１９９８年３月１２日発行）Ｊａｖａは、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍの商標である。

エージェント資料第５−コンピュータ・システム、コンピュータ読取可能な記憶媒体および同媒体を動作させる方法、および前記システムを動作させる方法
本発明は、コンピュータ・システムおよび該コンピュータ・システムを動作させる方法に関し、コンピュータにおける不要部分の整理に対するいわゆるリターン・バリアに関し、コンピュータ読取可能な記憶媒体、コンピュータ・システム、仮想マシンあるいはこれらを内蔵する類似の装置に関し、かつ動作方法に関する。望ましい実施の形態においては、本発明は、不要部分の整理に対するリターン・バリアに関する。
本発明は、ランタイム環境に対する全般的な適用性を有する。特に、本発明は、自動的なダイナミック・メモリ管理に適用可能である。
本発明は、１つの特質において、スレッドのスタックが同時の不要部分の整理により検査されている間ブロッキングを最小限に抑えるため、いわゆるリターン・バリアの使用に関する。

一部のコンピュータ・システムにおいては、図５Ａに略図的に示されるように、データは、最近のアクティビティが（同様に最上位にあり得る）スタックの最下位フレームに格納されるものと見なされるように、（起動）スタック２９００２の（起動）フレーム２９０００に格納される。不要部分の整理は、全てのセルのコネクティビティをトレースすることを含む。従って、このようにトレースされないものは、見えず一切の関連性情報を含み得ない。このため、これらのセルは、システムにおいて（付加的なメモリとして）使用されるように解放され得る。ガーベッジ・コレクタは、各スレッドのスタックにおける各フレームをトレースする。
典型的な起動スタックが、図５Ｂに更に詳細に示される。便宜上、スタック（同図における２９１０２）は、「最も新しい」項目がスタックの最下部に最も近くなるように、項目が上から下へ連続的に追加されるメモリ・ストアと見なされる。各スタックは、多数のフレーム（同図に示される２９１０４）からなり、各フレームはデータと、他のフレームまたはスタックに対する１つ以上の参照またはフレーム・ポインタとを含む。典型的には、各フレームは、前のすなわち最も古いフレームに対するポインタ２９１０６と、呼出し手順の実行可能なコードに対するリターン・ポインタ２９１０８とを含む。
トレーシング・プロセスにおいては、スタックの各フレームにおける（メモリ・ヒープに格納されたメモリ・オブジェクトに対する）全てのポインタまたは参照が調べられる必要がある。これが生じるためには、これまでは、当該スレッドのスタック全体にわたってトレーシングが行われる間、スレッドが休止されることが必要であった。このことは更に、不要部分の整理プロセスが、スレッドがガーベッジ・コレクタがそのフレームを照合する許可を与えるのを待つ間、停止されることを必要とする。
換言すれば、制御の起動スタックのスレッドに含まれる任意の参照が、トレーシングするコンカレントＧＣのルート・セットの一部として処理されることを必要とし、かつＧＣプロセスの間調べられることを必要とする。調べられるスレッドが、ＧＣスレッドが調べることができるどんな情報も変更しないことが非常に重要である。これを達成する１つの方法は、調べられるスレッドの実行を中断し、ＧＣにスタックの全内容を調べさせ、次いで調べられたスレッドの実行を再開することである。

本発明に関して識別される上記手法における主な問題は、１つのスレッドが中断される時間量がスレッドのスタックのサイズにより決定されること、および長すぎるスレッドの中断がかなりの休止をもたらすことである。当該特許に記載される手法は、望ましくはＧＣスレッドが関心を持つスタックの一部を使用しようと試みないことを前提として、スレッドが実行を継続することを許容する。
１つの特質によれば、（単数または複数の）スタック制御の各スレッドにより管理されるように構成された少なくとも１つ、望ましくは複数の、あるいは更に多数の起動スタックを含むコンピュータ・システムを動作させる方法が提供され、該方法は、
その起動スタックを用いて前記スレッドを実行し、かつ
更なるスレッドが望ましくは同時に同じ起動スタックをアクセスすることを許容する
ステップを含んでいる。このような特徴により、当該システムにおける同時実行の程度を強化することができる。
あり得る衝突の問題を防止するため、前記スレッドの実行は、前記の更なるスレッドが当該スレッドの起動スタックをアクセスしている時間の一部のみ休止される。従って、例えば別のスレッドのスタックの内容を調べることを欲するどんな動作もスレッドを不当に止めることなくこれを行うことができる機構が提供される。
同じ理由から、前記スレッドおよび前記の更なるスレッドは、同時に同じ起動フレームをアクセスすることを阻止される。
同様に、前記スレッドによるその時の起動フレームの実行は、前記更なるスレッドが同じ起動フレームをアクセスするのにこのスレッドが要する時間だけ休止される。
前記スレッドがその時の起動フレームから前記更なるスレッドによりその時アクセスされているフレームへ戻ることを選択的に阻止するため、バリアが設けられる。典型的な実際の状況においては、１つのスレッドは、他のスレッド（この場合は、更なるスレッドと呼ばれる）がアクセスに要する時間より所与の起動フレームをゆっくり実行するものと予期される。従って、リターン・バリアが特に頻繁に動作状態になることは予期されない。しかし、これは、衝突が生じないことを確保する上で最も重要である。
前記バリアの阻止効果は、前記の更なるスレッドが前記スレッドのその時の起動フレームのペアレントのフレームをその時アクセスしているかどうかに従って選択的である。従って、前記の更なるスレッドがその時ペアレントの起動フレームをアクセスしているならば、前記スレッドがその時の起動フレームから前記スレッドのその時の起動フレームの前記ペアレントの起動フレームへ戻ることを阻止するためにバリアが設けられることが望ましい。
その時の起動フレームに対するバリアは、前記の更なるスレッドがその時アクセスしているフレームを変更する前に提供される。このような特徴により、「エア・ロック」の形態が生成される。

第２の更なるスレッドあるいは更に大きな数の更なるスレッドが、同じ起動スタックを望ましくは同時にアクセスすることを許容される。望ましい実施の一形態においては、前記の更なるスレッドは、望ましくは並行なガーベッジ・コレクタのスレッドであり、前記第２の更なるスレッドはデバッガのスレッドであり、かつ前記スレッドはコンピュータ・システム内の他の任意のスレッドである。
同じ起動フレームに対しては、前記の更なるスレッドおよび前記第２の更なるスレッドに対する異なるバリアが設けられる。これは、異なるファンクションを行うことを可能にする。
望ましくは、前記バリアは、同バリアのグループが１つの起動フレームと関連させられるように構成される。前記の異なる各バリアごとに１つの記述子ブロックが設けられ、この記述子ブロックは１つのリンクされたリストを形成するようにリンクされることが望ましい。これは、多数のバリアを対処するのに便利な方法である。

本発明の１つの特に重要な用途は、不要部分の整理にある。従って、前記の更なるスレッドは、望ましくは並行なガーベッジ・コレクタのスレッドであり得る。
１つのサイクルにおいては、ガーベッジ・コレクタが前記スタックのフレームの最初の走査、かつ少なくとも１つの更なる走査を行うことが望ましい。
前記の少なくとも１つの更なる走査においては、変化した唯一のフレームが走査される。走査は、時間を要し得、従ってこの特徴は不要部分の整理のために要する時間を短くし得る。
前記の少なくとも１つの更なる走査においてフレームの走査を必要とする程度のレコードが保持される。このレコードは、以降の走査を開始できる時点の決定に使用することができる。特に、このレコードは、どのフレームが変化できたか、あるいは２つの所与の走査間で生成できたかについてものである。再走査は、その時の起動フレームに対するそのままのリターン・バリアを有する最も新しいフレームからのものである。
最も関連する特質において、本発明は、
それぞれの制御スレッドにより管理されるように構成された少なくとも１つの、望ましくは複数の、あるいは更に多数の起動スタックと、
前記スレッドをその起動スタックを用いて実行する手段（望ましくは、ランタイム・エンジン）と、
望ましくは同時に同じ起動スタックをアクセスすることを更なるスレッドに許容する手段と、
を含むコンピュータ・システムを提供する。
当該コンピュータ・システムは更に、前記の更なるスレッドが前記スレッドの起動スタックのアクセスに要する時間の僅かに一部だけ前記スレッドの実行を休止する手段を含む（あるいは、例えば、ランタイム・エンジンが更に休止するようになっている）ことが望ましい。
当該コンピュータ・システムは更に、前記スレッドおよび前記の更なるスレッドが同時に同じ起動フレームをアクセスすることを阻止する（あるいは更に、阻止するための）手段を含む。
当該コンピュータ・システムは更に、前記スレッドによりそのその時の起動フレームの実行を前記の更なるスレッドが同じ起動フレームのアクセスに要する時間だけ休止する（あるいは、更に休止するための）手段を含む。
当該コンピュータ・システムは更に、前記スレッドのその時の起動フレームから前記の更なるスレッドによりその時アクセスされているフレームへのリターンを選択的に阻止する（あるいは更に阻止するための）バリアを提供する手段を含む。

当該コンピュータ・システムは更に、更なるスレッドがその時ペアレントの起動フレームをアクセスしているならば、前記スレッドのその時の起動フレームから前記スレッドのその時の起動フレームの前記のペアレントの起動フレームへのリターンを阻止するバリアを提供する（あるいは更に、提供するための）手段を含む。
当該コンピュータ・システムは更に、前記の更なるスレッドがその時アクセスしているフレームを変更する前に、その時の起動フレームに対するバリアを提供する（あるいは更に、提供するための）手段を含む。
当該コンピュータ・システムは更に、第２の更なるスレッドが同じ起動スタックをアクセスすることを許容する（あるいは更に、許容するための）手段を含む。
当該コンピュータ・システムは、前記の更なるスレッドおよび前記第２の更なるスレッドに対する異なるバリアを同じ起動フレームに対して提供するためのものである。
前記バリアは、前記バリアのグループを１つの起動フレームと関連させるように構成されることが望ましい。当該コンピュータ・システムは、前記異なるバリアごとにリンクされたリストを形成するようリンクされる記述子ブロックを提供するためのものである。
前記更なるスレッドは、ガーベッジ・コレクタのスレッドであり得る。
前記ガーベッジ・コレクタは、１つのサイクルにおいて、前記スタックのフレームの最初の走査および少なくとも１つの更なる走査を行うためのものである。
当該コンピュータ・システムは、前記の少なくとも１つの更なる走査において変化したフレームのみが走査されるようになっている。
当該コンピュータ・システムは更に、前記の少なくとも１つの更なる走査においてフレームが再び走査されることを必要とする程度のレコードを保持する（あるいは更に保持するための）手段を含む。

本発明は、不要部分の整理の関連において特にユーティリティを有する。
広義において、最も新しい起動フレームの検査に要する長さだけ非ＧＣスレッドの実行を中断し、かつある特殊なコードを参照するようフレームのリターン・アドレスを編集することにより、不要部分の整理に関して先に述べた種々の問題を解決することが提起される。その後、連続する発呼者の起動フレームが調べられる間スレッドが実行を継続することを許容される。特定のフレームの検査がいったん完了すると、次にへ進む前に、フレームのリターン・アドレスが先に述べた同じ特殊コードを参照するように編集される。
不要部分の整理は、典型的な手順呼出しの実行速度と比較して比較的迅速なイベントである。このため、不要部分の整理が完了する前に手順の呼出しからのリターンが生じることは（無論たしかにあり得るが）比較的稀である。このような稀なイベントにおいては、特殊コードが起動され、起動フレームから再び発呼者のフレームへ戻ろうとする試みを受ける。発呼者のフレームがその時ＧＣスレッドにより調べられているならば、非ＧＣスレッドは、ＧＣスレッドが別のフレームへ移るまで待機するよう強制される。
このような関連において、本発明は更に、コンピュータ・システムにおけるスレッド・スタック内に含まれる参照データの並行な不要部分の整理を改善する方法を提供し、この場合スレッドはスタック全体ではなくその時の起動フレームを調べのに要する時間だけ不要部分の整理の目的のため休止されるにすぎない。
ガーベッジ・コレクタがフレームの検査を完了するまで、当該ガーベッジ・コレクタにより内容がその時調べられている起動フレームに対する未決の手順呼出しのリターンを阻止する手段がとられることが望ましい。
本発明の範囲内で、ガーベッジ・コレクタと、スタック全体ではなくその時の起動フレームの検査に要する時間だけ不要部分の整理の目的のためスレッドを休止させる手段とを含む同様の装置もまた提供される。
緊密に関連する特質において、ガーベッジ・コレクタと、スタック全体ではなくその時の起動フレームの検査に要する時間だけ不要部分の整理の目的のためスレッドを休止する手段とを含むコンピュータまたはコンピュータ・システムが提供される。

更に緊密に関連する特質において、コンピュータ・システムにおけるスレッド・スタック内に含まれる参照データの並行な不要部分の整理を改善し、不要部分の整理の目的のためスタック全体ではなくその時の起動フレームの検査に要する時間だけスレッドが休止される方法を提供するプログラムが記録されたコンピュータ読取可能な記憶媒体が提供される。
更に緊密に関連する特質において、プログラムされたとき、コンピュータ・システムにおけるスレッド・スタック内に含まれる参照データの並行な不要部分の整理を改善し、スタック全体ではなくその時の起動フレームの検査に要する時間だけ不要部分の整理の目的のためにのみスレッドが休止される方法を提供するコンピュータが提供される。
緊密に関連する特質において、本発明は、コンピュータ・システムのスレッド・スタックにおける並行な不要部分の整理を改善する方法であって、不要部分の整理スレッドがスタックにおける問題のスレッドをアクセスすることを可能にし、最もアクティブな起動フレームの検査に必要な長さだけ問題のスレッドの実行を中断し、前記フレームのリターン・アドレスをリターン・バリア・コードに編集し、連続する起動フレームが調べられる間実行を問題のスレッドが継続することを許容し、次のフレームへ移動する前に前記各フレームのリターン・アドレスを同じリターン・バリア・コードに編集するステップを含む方法を提供する。
ガーベッジ・コレクタが起動フレームの検査を完了するときまで、ガーベッジ・コレクタにより内容がその時調べられている起動フレームへの未決の手順呼出しのリターンを阻止するため、バリア・コードが用いられる。本発明は、これにより、問題のスレッドが中断される時間を短縮する目的を達成する。本発明はまた、不要部分の整理システムにおける同時実行の程度を最大化することができ、かつ同時実行の認識を改善する。
更に緊密に関連する特質において、コンピュータ・システムのスレッド・スタックにおける並行な不要部分の整理を改善する方法を提供するプログラムが記録されたコンピュータ読取可能な記憶媒体が提供され、当該方法は、不要部分の整理スレッドがスタックにおける問題のスレッドにアクセスすることを可能にし、最もアクティブな起動フレームが検査される必要がある長さのみ問題のスレッドの実行を中断し、前記フレームのリターン・アドレスをリターン・バリア・コードに編集し、連続的な起動フレームが調べられる間問題のスレッドの実行を継続させ、次のフレームへ移る前に前記各フレームのリターン・アドレスを同じリターン・バリア・コードに編集するステップを含んでいる。

本発明は、上記方法に従ってプログラムされるときコンピュータに拡張する。
本発明はまた、
スレッドがその起動スタックを用いて実行し、かつ
更なるスレッドが同じ起動スタックをアクセスすることを許容する
ようにプログラムされたとき、各制御スレッドにより管理されるよう構成された少なくとも１つの、望ましくは複数の、更に望ましくは多数の起動スタックを含むコンピュータ・システムに拡張する。
本発明はまた、上記方法を提供するプログラムが記録されたコンピュータ読取可能な記憶媒体に拡張する。
緊密に関連する特質において、各制御スレッドにより管理されるよう構成された少なくとも１つの起動スタックを含むコンピュータ・システムを動作させる方法を提供するプログラムが記録されたコンピュータ読取可能な記憶媒体が提供され、前記方法は、
前記スレッドをその起動スタックを用いて実行し、かつ
更なるスレッドが同じ起動スタックをアクセスすることを許容する
ステップを含んでいる。
本発明は、上記コンピュータまたはコンピュータ・システムを含む仮想マシンに拡張する。
本発明は、上記方法により動作されるとき仮想マシンに拡張する。
本発明は、上記コンピュータ読取可能な記憶媒体により動作されるとき仮想マシンに拡張する。
本発明の種々の特質の異なる特徴のいずれか、あるいは一部、あるいはその全ては、他の特質に適用されよう。
本発明の望ましい特徴については、純粋に事例として、添付図面に関して次に記述される。
本発明については、まず全般的に記述し、次いで本発明が実施される特定の方法の更に総括的な記述が続く。
図５Ａに関して、本発明において、スレッドは、全ての起動フレームの検査に要する時間ではなく、最近の（すなわち、最も近いかあるいは最もアクティブな）起動フレーム２９００４の検査に要する長さだけ、ランタイム・エンジンにより休止されるだけでよいことが認められた。このフレームは、参照すなわちポインタについて検査され、リターン・アドレスは、ヒープ２９００８として知られるデータについて動作するプログラム２９００６自体へ送られる特殊コードで前のリターン・アドレスを置換することにより編集される。この特殊コードは、前のリターン・アドレスと新しいリターン・アドレスを前記フレームにリンクする。データが戻されるときにガーベッジ・コレクタが前記フレームについて動作しているならば、リターン・バリア・コードは、ガーベッジ・コレクタが別のフレームへ移るときまでリターンを休止することにより、当該フレームにおけるデータの改変を防止する。

本発明の成否は、最も新しいフレームのみがこれにおける操作の結果変化させられることの実現に依存する。スレッドが例えば不要部分の整理の間休止されると、最も新しいフレームにおける全ての参照について検査が行われる。図５Ｃにおいて、フレーム・ポインタおよびリターン・アドレスが別のストアＳ（２９２０４）へコピーされ、リターン・アドレスは特殊コードに編集される。このスレッドは次に、最も新しいフレームにおいて継続し得る。この最も新しいフレームは前のフレームへ戻ろうとしようとするとき、ガーベッジ・コレクタがこの場所でアクティブになるので戻ることができない。このような状況では、リターン・バリアがこのような要求を特殊コードへ変え、これによりＧＣが終るまでスレッドが前のフレームへ戻ることを阻止する。ＧＣは、リターン・バリアを取下げ、安全ならばスレッドがこれを除去する。
ＧＣが最も新しいフレームから移動してある距離だけ移動したフレームを探すので、大半のリターンが妨げられることがない。いかなるときもスタックにアクセスを試みるスレッド数に従って、スタックには幾つかのリターン・バリアがあり得る。後続のスレッドはできるだけ多くの前のスタック数まで戻る必要がないことになる。

次に、最初に全般的なリターン・バリアについて、次に不要部分の整理の関連においてリターン・バリアの構成について、更に詳細な記述を行う。
スレッドのスタックは、一連のフレームからなっている。１つのフレームは、１つの特定の未決の手順呼出しに関する全ての情報を含む。全てのフレームは、下記を含んでいる。すなわち、
（ａ）プログラムの実行がフレームと関連する手順呼出しが戻ったものから再開するはずの場所を示すある実行可能なコードのアドレスであるリターン・アドレス（リターン・アドレスは、特定タイプの命令ポインタである）、および
（ｂ）呼出し手順のフレームを示すアドレスを指示するメモリに対する特定タイプのポインタであるペアレントのフレーム・ポインタ（ペアレントのフレーム・ポインタは、特定タイプのフレーム・ポインタである）。
手順パラメータ１、２、、、ｎ（２９３０４）、リターン・アドレス２９３０６、ペアレントのフレーム・ポインタ２９３０８および１組のローカル・データ２９３１０を含む手順呼出しフレーム２９３０２におけるデータの構成の表示について図５Ｄを参照する。
従って、図５Ｅに略図的に示されるように、手順呼出しスタック２９４０２を用いてスレッドがその時実行中である未決の手順呼出しを記述するカレントのすなわち最も新しいフレーム２９４０８の概念が存在する。前記の最も新しいフレーム２９４０８のフレーム・ポインタ２９４０４は、典型的に特定マシンのレジスタ（フレーム・レジスタとして知られる）に保持される。２９４０６のような連続的なペアレント・フレーム・ポインタは、逓増的に古くなるフレーム２９４１０、２９４１２を指す。
上記において行われる手順は、下記のように表わされる。すなわち、

一般的なリターン・バリア機構（すなわち、ガーベッジ・コレクタの関連における使用に限定されない機構）について、次に記述するが、これにより、特定のバリア付きフレームの関連において実行する手順が戻ろうと試みるときはつねに、一連の任意のファンクションが実行されるように構成することができる。
リターン・バリア機構は、多数の異なるクライアントを多分（あるいは更に、おそらくは）同時に持つ（その結果フレーム当たり１つ以上のリターン・バリアが必要となる）。ここで、１つの特定のクライアントである、実行されるファンクションが有効に停止ファンクションであるガーベッジ・コレクタについて更に詳細な記述を行う。別のあり得るクライアントはデバッギング・インターフェースであり、この場合は停止ファンクションではなく、ファンクションはデバッガに対して情報の提供に関する。このような関連において重要な特徴は、リターン機構に割込みを行う能力である。

リターン・バリアのレイダウンは、これにより任意のファンクションｐに対してフレームｆに構成する機構であり、先に述べたように、このファンクションは典型的に最終クライアントに依存し、例えば、不要部分の整理のため使用できる特定のファンクション（後では、コードＢと呼ばれる）がある。バリアの記述子ブロック２９５０２の内容の一般的構成が図５Ｆに略図的に示され、１つのバリア記述子ブロックがリターン・バリア当たりメモリに設けられている。リターン・バリアのレイダウンについて記述する下記の擬似コードにおいて、先に触れた、後で更に詳細に述べる特殊なコードはＣと呼ばれる。

上記の如き概念は、多数のバリアがバリアのリンク・フィールドを介してリンクされた記述子ブロックの連鎖として表わされる１つの特定のフレームにレイダウンできることである。各ブロックは元のフレーム・ポインタのコピーをもつが、各々が異なるバリア・ファンクションを持ち得、その結果各々が別の１つのクライアントを持ち得る。
例えば、（比較的早い速度で実行する）不要部分の整理の関連において、最も新しい起動フレームから試みられるリターンが特に生じにくいことが理解されよう。しかし、バリア付きフレームの関連において実行する手順が戻ろうと試みるとき、Ｃのコードが実行される。これは更にバリア・ファンクションの各々を実行し、次いでバリアがあたかも存在しないかのように完了する役割を負う。コードＣ（「特殊なコード」）は、擬似コードの以降の項により記述され、このコードが典型的に全てのリターン・バリアに対して一般的であることが知られよう。この項は、リンクされたリストに対する参照を含み、これは一連のリンクされたポインタである。

以上のことは、一般的なリターン・バリア機構の望ましい実施の形態について記述する。

不要部分の整理の特定の関連においては、ガーベッジ・コレクタがリターン・バリアを用いて、実行されていないフレームにおける実行を許容しながら、その時ＧＣにより吟味されているフレームにおける実行を継続する試みが別のスレッドによりなされないことを保証する。
次に、リターン・バリアの構成について述べる。ガーベッジ・コレクタは、下記の方法でスレッドのスタックの内容を調べる。ｇｃｆは、その時ＧＣスレッドにより調べられている起動フレームに対する参照を含むシステム・ワイドなグローバル変数とする。どのスレッドによってもこの変数を読むことはできても、ＧＣのみがこの変数を変えることができる。従って、ｇｃｆは、ガーベッジ・コレクタがその時調べているそのフォーカスの概念を表わす。
ＧＣスレッドは、擬似コードの次のセクションで述べるように、スレッドｔのスタックを調べる。

このように、ガーベッジ・コレクタは、スレッドｔのスタックの全てのフレームにわたり最も新しいものから最も古いものまで進行可能である。
バリア・インタセプタ・コードＢは、手順が１つのフレームからペアレント（発呼者の）フレーム（ｐｆ）へ戻ろうとする比較的生じにくいイベントにおいて呼出され、これが戻ろうとしているフレームに対するポインタが与えられる。これは、ＧＣがその時調べている（すなわち、ペアレント・フレームへ戻ろうとトラップする）フレームへ戻る試みがなされないことを保証する。

ＧＣスレッドのフォーカス（関心の点）がいったん動くと、非ＧＣスレッドはその発呼者へ完全に安全に戻ることを許すことができる。
早期のスレッド検査により確定されたリターン・バリアがそのまま以降の検査に残り得ることがあり得る。このような場合、すでにバリアがあるならば、ＧＣスレッドはバリアを確定しようとしない。ＧＣが動作していない間は、ｇｃｆはあり得ない値を指すようにセットされる。従って、リターン・バリアは無視される。従って、ＧＣが動作していないときはリターン・バリア機構がセルフ・クリーニングし、リターン・バリアは所定位置に残るが、その実行に関与した唯一のオーバーヘッドはｐｆ＝＝ｇｃｆの実行であリ、これは小さなオーバーヘッドである。

用いられる特定のＧＣは、新たなアクティビティが関連スレッドにおいて検出されなくなるまで、特定のスレッドのスタックが１つのＧＣサイクルで多数回調べられることを必要とする（ときに、このプロセスは、ヒープが小さなサイズであるからある時点で終了するように保証される）。これまでに述べた手法では、各スタックにおける各フレームが適切な回数調べられることを必要とする。しかし、ここで述べる１つの望ましい変更例では、バリア・ファンクションＢは、これが呼出された最近のフレームのレコード（実際に、起動スタック当たり１つのレコード）を保持するように強化される。このレコードは、スタックにおけるアクティビティの「高水位マーク」を有効に表わす。これは、連続的な戻りが行われるとき引込む（古いフレームへ移動する）が、このようなフレームにはリターン・バリアがないので、新規の起動フレームへの呼出しはレコードの値を変えることはない。ＧＣは、スタックを調べるとき、最近のフレームより古い全てのフレームが変化できなかったものから呼出されたものであり、従って再び走査されないことを前提とし得る。従って、最初の走査は、各スタックにおいて各フレームを調べるＧＣを呼出す。以降の再走査は、スタックにおける最も新しいフレームから、前の走査において初めに置かれたリターン・バリアをまだ有する最も新しいフレームまで生じる。より古いフレームは、走査間の間隔では変化し得ない。
最小限の再走査をサポートするため要求される強化の詳細にについては、次に述べる。先に述べた変数に加えて、各スレッドは変数ｔｌ−ｈｗｆを持ち、これがつねに最も新しいフレームを同じＧＣのリターン・バリアを持つスレッドに保持する。

下記の強化された手法がスレッドｔのスタックを調べる。すなわち、

コードＢはｔｌ−ｈｗｆの実行中スレッドのコピーを維持するように高められる。

但し、「このスレッド」は、コードＢを実行するスレッドを指す（幾つかのスレッドがこれを同時に行うことができる）。
先に述べた手法は、並行なＧＣ構成が各スレッドとの対話に要する時間量を最小化することを許容し得、これが更に全てのスレッドを更に迅速に再走査することを可能にし、これによりＧＣサイクル全体を、全てのスレッドのスタックを全体に再走査しなければならない場合に要するよりも少ない時間で完了することを可能にする。
要約すれば、（特に）２つの基本的な特質について述べた。第一に、一般的なリターン・バリア機構が提供され、手順が戻るとき任意の動作を行うことを可能にする。この機構は、リターン・バリアが使用されていないとき、過剰なオーバーヘッドを生じることがない。現フレームのみが、必要に応じて休止しなければならず、その後手順がそれ自体のペースで進み得る方向に自己調整し、同期または初期手続きはほとんど必要でない。

第二に、特に並行な不要部分の整理の関連において、その時機密保護されているフレームに再エントリする試みが行われないことを保証するためリターン・バリアを用いることができる。これに付随するのは、１つのスレッドが動作中にＧＣがそのスレッドのスタックを調べることを許す能力である。記述した更に他の特徴は、スレッドのスタックが再走査されるならば、スレッドのどの部分が調べねばならないかを決定することができることであり、これは高水位マーク機構によって達成される。
上記のいずれかあるいは全てにおいて、本発明の幾つかの特徴がコンピュータ・ソフトウエアを用いて実現された。しかし、無論、当業者には、これらの特徴のいずれもハードウエアまたはハードウエアとソフトウエアの組合わせを用いて実現できることが明らかであろう。更に、ハードウエア、コンピュータ・ソフトウエアなどにより行われるファンクションが電気信号などを用いて行われることが容易に理解されよう。
情報の格納に関する特徴は、適切な記憶場所またはストアによって実現されよう。情報の処理に関する特徴は、ソフトウエアまたはハードウエア、あるいは両者の組合わせのいずれかにおいて適切なプロセッサまたは制御手段により実現されよう。

上記のいずれかあるいは全てにおいて、本発明は、下記の形態のいずれか、あるいは一部、あるいはその全てにおいて具現され、コンピュータ・システムを動作させる方法において具現され、コンピュータ・システム自体において具現され、コンピュータ・システムを動作させる方法を実行するようプログラムされあるいは構成されるときコンピュータ・システムにおいて具現され、そして（または）コンピュータ・システムを動作させる方法に従って動作するためのプログラムが記録されたコンピュータ読取可能な記憶媒体において具現されよう。
本文に用いられるように、用語「コンピュータ・システム」は、「コンピュータ」、「システム」、「装備」、「装置」、「マシン」などの用語と互換であり得る。コンピュータ・システムは、仮想マシンであり得、あるいはこれを含み得る。
上記のいずれかあるいは全てにおいて、方法および装置の特徴および特質を含む先に述べた異なる特徴および特質は、いかなる適切な方法においても組合わせることができよう。
本発明が本文において純粋に事例として記載され、細部の修正が本発明の範囲内で可能であることが理解されよう。
本文の記述、請求の範囲および図面において開示された各特徴は、独立的に、あるいはいかなる適切な組合わせにおいても提供されよう。

エージェント資料第６−コンピュータ・システム、コンピュータ読取可能な記憶媒体および同媒体を動作させる方法、および前記システムを動作させる方法
本発明は、コンパイルされたコードのセクションを削除することを許容するためコンピュータ・システムにおけるメモリを検査する方法および装置に関し、かつコンピュータ・システムにおいてコンパイルされたコードを削除する方法および装置に関する。本発明は、スタックのウォーキング（ｗａｌｋｉｎｇ）がコンパイル・コードを削除することを許容する統合化されたスタックの仮想マシンの環境における特定の用途を（これに限定されず）を見出すものである。望ましい実施の形態において、本発明は、統合化スタック仮想マシンのマルチスレッド環境におけるコンパイル・コードの削除を許容するスタック・ウォーキングに関する。

本発明は、仮想マシンにおいて走るコードのコンパイルされた部分が現われ、仮想マシン、例えば動的にコンパイルする仮想マシンの実行時の色々な時点で除去する必要がある仮想マシンに適用する。
仮想マシンを用いてコードを実行するとき、エミュレートされたコードの一部または全てのコンパイル・バージョンを生成することが有利であることが判った（「主パスの動的にコンパイル」参照）。前記コンパイル・バージョンの一部あるいは全てを実質的に除去することがときに望ましいかあるいは必要であると信じる。また、エミュレートされたマシンと仮想マシンのコード自体の必要の両方のスタックの要件をサポートするため１つのスタックを使用すること、およびエミュレートされた呼出し（呼び出す）と相当することを行うネイティブな呼出し命令を使用すること、および仮想マシンをランするコードにおけるエミュレートされたリターンに相当することを行うためネイティブなリターン命令を使用することが有利であろうことも信じる。
コンピュータ・システムが特定のファンクションを行うため用いたメモリの使用を終了した場合、更なる使用のためできるだけ速く使用したメモリが返される速度と効率が問題となることが判った。
仮想マシンに対して今日知られる手法は、バックグラウンド情報部分にリストされる１つ以上の最適化手法がシステムの効率を阻害する別個の検査を利用されないことを要する。

特に、システムからのコンパイル・コードの削除は、諸問題を生じ得る。削除されないコンパイル・コードの部分から削除されたコードのセクションへのリンクが存在し得る。仮想マシンにおける呼出しまたは関与をエミュレートするためネイティブ呼出し命令（あるいは、等価物）の意図された使用のゆえに特定の問題が生じ得、このことは典型的に、呼出しまたは呼が行われるスタック点における、あるいはその付近におけるスレッドに対する前記スタックにおいて呼出された方法がいったん完了すると実行が継続するアドレスを外すことになる。ネイティブ呼出し命令がコード部分のコンパイル・バージョンの部分であるならば、リターン・アドレスはコンパイル・バージョンを指示する。このことは、コンパイル・バージョンの削除の時点までは何の問題も生じない。リターン・アドレスは、コンパイル・バージョンが使用される場所を指したままではあり得ない。実行中、コンパイル・コードが使用されたアドレスへ戻ろうとするとエラーが生じ、このスレッドによる実行は通常終了することになる。このような構成では、戻り動作を行うことが安全であることを保証するため、戻りが行われようとしている各場所において検査を行うことが必要となろう。

本発明は、上記および（または）他の問題を軽減することを目的とする。
本発明の望ましい実施の形態におけるこれらの問題に対する解決法は、コンパイル・コードの削除の時点において、仮想マシンの検査を行い、削除されるコンパイル・コードの断片内の位置を指示するスタックにリターン・アドレスが存在する場合を探し、削除されようとするコードのコンパイル・バージョンなしに前記スレッドの実行のシームレスな継続を可能にするためスタックの内容を再構成することである。この機構は、動作のコストが削除の時点で負担され、２つの状況の相対的頻度がコードの削除操作より多くの呼出し／戻り操作があるようなものであるため、正常な呼出し／戻り時にはほとんどあるいは全くコストが生じないように構成されることが望ましい。
従って、本発明は１つの特質において、コンパイル・コードの部分を削除することを許容するためコンピュータ・システムにおけるメモリを調べる方法を提供し、当該方法は、
コンピュータ・システムにおけるスタックのフレームを調査し、
コンパイル・コードの部分のアドレス範囲内にあるリターン・アドレスをフレームが含むかどうかを識別し、
このようなリターン・アドレスが識別されるときフレームの内容を変更することを含んでいる。
上記方法を実施することにより、削除されるべきコンパイル・コードのセクションをリターン・アドレスが指示したままにすることと関連する問題を克服することができる。

本発明の緊密に関連する特質において、コンピュータ・システムにおけるコンパイル・コードを削除する方法が提供され、当該方法は、
削除されるべきコンパイル・コードのセクションを選択し、
コンピュータ・システムにおけるスタックのフレームを調査し、
コンパイル・コードの部分のアドレス範囲内にあるリターン・アドレスをフレームが含むかどうかを識別し、
このようなリターン・アドレスが識別されるときフレームの内容を変更し、
コンパイル・コードの部分を削除する
ことを含んでいる。
このような任意のリターン・アドレスは、連続コードの断片のアドレスへ変更されることが望ましい。連続コードは、コードが削除されることなくリターン後に継続するよう実行を可能にする。連続コードは、インタプリタへ制御を渡すように構成されることが望ましい。連続コードは、例えばコンパイル・バージョンがあるエミュレートされた命令の部分に遭遇するまで、以降の命令が解釈されるように構成され、あるいはまた、コンパイル・バージョンが存在するならば、削除されるコードのこのようなコンパイル・バージョンへジャンプするように構成される。リターンに後続する命令の実行のためフォールバック・インタプリタの使用することは、命令の新たなコンパイル・バージョンを生じるオーバーヘッドなしに、削除されたコンパイル・コードの命令の実行を可能にする。
フレームがこのようなリターン・アドレスを含むならば、フレームにおける値が変更されることが望ましい。フレームにおける値は、コードが削除されることなく実行が継続することを可能にするように構成されることが望ましい。例えば、フレームに格納される一時的なレジスタ情報は、削除されるコードがコンパイルされたときに行われた最適化を勘定に入れるように変更される。このような変更は、例えば、以降の実行のため制御がインタプリタへ渡される場合に要求される。（エージェント資料第１参照）。
フレームの変更は削除の時点に行われることが望ましい。このため、リンクおよびフレームのリターン・アドレスはいずれも削除後はべコンパイル・コードを指示することがなく、実行中の時間のかかる検査を避けることができる。
スタックにおける複数のフレームが調べられることが望ましい。例えば、スタックにおける全てのフレームを調べることができ、さもなければ、コンパイル・コードの部分を指示するリターン・アドレスを含む各フレームが調べられる。
本発明の望ましい実施の形態においては、コンピュータ・システムがマルチスレッド環境を使用する。各スレッドはそれ自体のスタックを有する。

コンピュータ・システムにおける複数のスレッドのスタックが調べられることが望ましい。例えば、コンピュータ・システムにおける全てのスレッドのスタックが調べられ、さもなければ、削除されるコードがアクセスする各スレッドのスタックが調べられる。
このように、リターン・アドレスが削除されるコンパイル・コードのセクションを指示しないことを保証することができる。
一部のスレッドが削除されるコンパイル・コードのセクションにアクセスできないことが判る。このようなスレッドのスタックを調べないことにより、実行時間を節減することができる。
しかし、調べられるスタックのスレッドに対しては、検査が行われる間はスレッドを停止することがしばしば必要となる。あるいはまた、スレッドをコードのあるセクションへ限定するためリターン・バリアが挿入される（「リターン・バリア」参照）。
本発明の別の特質においては、コンピュータ・システムにおけるコンパイル・コードを削除する方法が提供され、該方法は、
システムにおける各スレッドの各スタックの各フレームを調査し、
リターン・アドレスが削除されるべきコンパイル・コードの部分を指示するかどうかを識別し、
削除されるコンパイル・コードの部分のないスレッドが実行を継続することを可能にするため、リターン・アドレスを含む各スタックの内容を再構成する
ことを含む。
本発明の更なる特質においては、コンピュータ・システムにおけるコンパイル・コードのセクションを削除する方法が提供され、該方法は、コンピュータ・システムのメモリを調べ、コンパイル・コードのセクションに対するリンクを識別し、このリンクを変更することを含む。
コンパイル・コードの部分に対するリンクは、フレームにおけるリターン・アドレスであることが望ましい。このように、フレームを実行するとき識別されるリターン・アドレスは、削除されるコンパイル・コードのセクションのアドレスの範囲内にあるリターン・アドレスであることが望ましい。
あるいは更に、またはこれに加えて、メモリの検査が、削除されるコンパイル・コードに対するパッチまたはジャンプを識別することができる。前記リンクは、削除されるコンパイル・コードに対して直接的あるいは間接的なリンクである。例えば、リンクは、コンパイル・コードのセクションに対するグルー・コードのセクションである。

コンピュータ・システムは、仮想マシンとして構成されることが望ましい。
本発明の更なる特質において、コンパイル・コードのセクションを削除することを許容するため、コンピュータ・システムにおけるメモリを調べる装置が提供され、該装置は、
コンピュータ・システムにおけるスタックのフレームを調べる手段と、
削除されるコードのセクションのアドレスの範囲内にあるリターン・アドレスをフレームが含むかどうかを識別する手段と、
フレームの内容を変更する手段と、
を含む。
本発明の別の特質において、コンピュータ・システムにおけるコンパイル・コードを削除する装置が提供され、該装置は、
削除されるコンパイル・コードのセクションを選択する手段と、
コンピュータ・システムにおけるスタックのフレームを調べる手段と、
削除されるコンパイル・コードのセクションのアドレスの範囲内に含まれるリターン・アドレスをフレームが含むかどうかを識別する手段と、
フレームの内容を変更する手段と、
コンパイル・コードのセクションを削除する手段と、
を含む。
当該装置は更に、以降の命令を実行する手段を含み、フレームの内容を構成する手段が、任意の前記リターン・アドレスを以降の命令を実行する手段のアドレスへ変更するためのものである。当該装置は更に、フォールバック・インタプリタを含むことが望ましい。以降の命令を実行する手段は、コンパイル・バージョンが存在するエミュレートされた命令のセクションに遭遇するまで、以降の命令を解釈するように構成される。
フレームの内容を構成する手段は、フレームがリターン・アドレスを含むならば、コードを削除することなく実行が継続することを可能にするようフレームにおける値を変更するためのものである。
本発明の望ましい実施の形態において、例えば、インタプリタによる以降の実行を可能にするよう値を更新するためどんな変更が要求されるかに関して「クリーンアップ」情報が利用可能になるように、コードのコンパイルにおいて実施された最適化のレコードが保持される。当該装置を含むコンピュータ・システムの場合、当該システムが更に、コードがコンパイルされるとき「クリーンアップ」情報を記録するレコーダを含むコンピュータ・システムを含むことが望ましい。
スタックにおけるフレームを調べる手段は、当該スタックにおける複数のフレームを調べるためのものである。スタックにおけるフレームを調べる手段は、コンピュータ・システムにおける複数のスレッドの各々のスタックを調べるためのものである。

本発明はまた、先に述べた装置を含む仮想マシンをも提供する。
本発明は更に、先に述べた装置を含むコンピュータ・システムを提供する。
別の特質において、本発明は、コンパイル・コードを削除する手段を含み、更にシステムにおける各スレッドの各スタックの各フレームを調べる手段と、リターン・アドレスが削除されるべきコンパイル・コードの部分を指示するかどうかを識別する手段と、削除されようとするコンパイル・コードの部分なしに前記スレッドが実行を継続することを可能にするように、リターン・アドレスを含む各スタックの内容を再構成する手段とを含むコンピュータ・システムを提供する。
本発明は更に、先に述べたような方法を実施するためのプログラムが記録されたコンピュータ読取可能な記憶媒体を提供する。
上記特質のいずれか特徴は、任意の適切な組合わせにおいて他の任意の特質が提供される。装置の特徴は方法の特質に適用され、あるいは反対に方法の特質は装置の特質に適用される。
本発明の望ましい特徴については、純粋に事例として、添付図面に関して次に記述する。
望ましい実施の形態の記述に先立ち、望ましい実施の形態の背景について最初に論述する。

仮想マシンは、１つのオペレーティング・システムに対して書かれたソフトウエアが別のオペレーティング・システムで走ることを可能にし、このソフトウエアは、「非ネイティブ」なソフトウエアと呼ばれる。非ネイティブなソフトウエアが走ることを可能にするために、仮想マシンは、ソフトウエアが書かれたオペレーティング・システムの動作をエミュレートする。このような状況が、図６Ａに示される。仮想マシンは、非ネイティブなソフトウエアの命令を、ホスト・オペレーティング・システムにより走ることができるネイティブな命令へ翻訳する。従来のエミュレータは、実行中に非ネイティブな命令を解釈することにより働く。
任意の実行パス、すなわち「スレッド」は、これと関連するスタックを有する。スタックは、一時的なレジスタ情報とサブルーチンのリターン・アドレスとからなるフレームを格納するメモリにおける領域である。従来のエミュレータにおいては、非ネイティブなアプリケーションが、ホスト・オペレーティング・システムのスタックとは別個のそれ自体のスタック（エミュレータ・スタック）を有する。
エミュレータ・スタックの動作の一例が、図６Ｂに示される。同図によれば、非ネイティブ・コード５００８の部分は、アドレスｂｂｂに配置されたサブルーチン５０１０を呼出すアドレスａａａに呼出し命令を有する。エミュレータが呼出し命令に遭遇すると、アドレスａａａ（リターン・アドレス）は、一時的レジスタ情報と共にエミュレータ・スタック５００９に入れられ、この時実行のパスはアドレスｂｂｂへジャンプする。サブルーチンの終りに、エミュレータがリターン命令に遭遇する。このエミュレータはレジスタ情報と共にスタックからリターン・アドレスを取得し、主ルーチンにおける呼出し命令に続く命令へ戻る。
望ましい実施の形態の仮想マシンにおいては、非ネイティブ命令の解釈ではなく、命令の一部または全てが、ホスト・オペレーティング・システムで走ることができるネイティブ命令へコンパイルされる。コンパイルにはある量の時間が必要であるが、コンパイル・コードを走らせるとき著しい時間の節減が可能である。
色々な方法で時間の節減が可能である。第一に、コードの一部が１回以上実行されるならば、コンパイル・バージョンを実行するのが更に効率的になる。第二に、エージェント資料第１において先に述べたように、コンパイル・コードの最適化を可能にする種々の仮定がコンパイルの間にできる。第三に、ホスト・オペレーティング・システムのスタックを用いることにより、またサブルーチンの呼出しのため（エミュレートされた呼出し命令ではなく）ネイティブ呼出し命令を用いることによって、時間の節減が可能である。
図６Ｃにおいて、非ネイティブな主ルーチン５００８および非ネイティブなサブルーチン５０１０が、ネイティブなルーチン５０１２およびネイティブなサブルーチン５０１４へコンパイルされる。アドレスｘｘｘにおける呼出し命令はネイティブな呼出し命令である。この呼出し命令に遭遇すると、アドレスｘｘｘ（リターン・アドレス）が一時的レジスタ値と共にホスト・スタック５０１５へ入れられる。アドレスｙｙｙにおけるサブルーチンの命令がピックアップされる。このサブルーチンの終りにおけるリターン命令に遭遇すると、リターン・アドレスとレジスタ値がホスト・スタックから取入られ、主ルーチンの実行が再開する。

先に述べた方法でコンパイル・コードを用いるとき、ある状況では、コンパイル・コードのあるセクションを削除することが望ましいかあるいは必要である。これは、コンパイル・コードが格納される記憶域がほかに要求されるゆえであり、あるいはコンパイルの間に行われる場合の仮定がもはや無効であるゆえある。また、特に制限されたメモリ環境で用いるときは、将来必要とされることが予期されないコードを除去することが望ましい。
コンパイル・コードのセクションから呼出されたサブルーチンをプロセッサが実行中である間コンパイル・コードのセクションが廃棄される場合は、問題が生じる。このような状況では、リターン・アドレスが、もはや存在しないコードの部分を指示するスタックに残される。
望ましい実施の形態によれば、コンパイル・コードのセクションの削除に先立ち、スタックがフレーム単位で調べられて、削除されるコードのセクションを指示する何らかのリターン・アドレスを識別する。このようなリターン・アドレスが識別されると、アドレスが、本文では「グルー・コード」と呼ばれる継続コードの部分のアドレスへ変更される。このグルー・コードは、削除されるコード部分なしに実行を継続することを可能にする。これは、コンパイル・バージョンがあるコード部分に遭遇するまで元の非ネイティブなコードにおける命令を解釈することによるか、あるいはコードの別のコンパイル・バージョンが存在するならば、このコンパイル・バージョンへジャンプすることによって行われる。
グルー・コードの使用およびコンパイル・コードと非コンパイル・コードとの間の実行の転送の論議は、エージェント資料第１において見出すことができる。
先に述べたように、サブルーチンが呼出されると、一時的レジスタ情報もまたリターン・アドレスと同じフレームにおいてスタックへ入れられる。種々の最適化がコードのコンパイルの間に行われるから、コンパイル・コードの残りが実行されるならば、このレジスタ情報のみが有効となる。例えば、コードのセクションがコンパイルされると、コンパイラがこのコードのセクションでは全てのパラメータが必要とされるわけではないことを識別することになる。このような場合、コンパイル・コードの残りの実行に必要でないので、レジスタ情報の一部が残されることになる。しかし、実行が元の解釈されたコードへ戻るならば、パラメータの全てが必要となる（インタプリタがどのパラメータが必要か必要でないかを知ることを見越し得ないので）。このように、コードの解釈されたバージョンを実行できる前に見失ったレジスタ情報が追加されることを必要とすることになる。

正しくないレジスタ情報の問題は、サブルーチンが呼出されるとき、コンパイル・コードの残りが実行されなかった場合でさえ、スタックに入れられるレジスタ情報の全てが有効であることを確認することによって避けることもできる。あるいはまた、レジスタ情報に影響を及ぼす最適化が行われると、この事実は、コンパイル・コードの残りが実行されなくとも、最適化を行わないことを許容するのに必要な情報と共に記録することもできる。リターン・アドレスを含むフレームが識別されると、グルー・コードが行われた最適化を調べて、必要な場合にこのフレームにおけるレジスタ情報を変更することができる。
望ましい当該実施の形態は、マルチスレッド環境、すなわち非同期で走るが同じ作業スペースを共有する２つ以上のプロセッサすなわちスレッドがある環境において動作するよう意図される。この望ましい実施の形態では、コンパイル・コードがアクセスしたかもしれない各スレッドのスタックが調べられ、あるいは単に各スレッドのスタックが調べられる。
１つのスタックを調べるため、このスタックが関連するスレッドが、ある期間だけ停止される。実施の一形態では、このスレッドは、スタックにおける全てのフレームが調べられる間停止される。別の形態においては、スレッドは、スタックにおける最近のフレームか、あるいは予め定めた数の最近のフレームを調べるだけ充分に長い間停止される。これらのフレームがいったん調べられると、「リターン・バリア」が、エージェント資料第５に記載される方法でスタックへ挿入される。従って、このスレッドは、スタックがリターン・バリアに留まる長さだけ実行を継続することを許され得る。
図６Ｄに関して、望ましい実施の形態の動作について次に述べることにする。
ステップ５０２０において、あるコード・バッファが削除されることが決定される。コード・バッファは、コンパイル・コードを格納するメモリにおける１つの領域である。ステップ５０２２において、そのスタックが調べられるスレッドが選択される。ステップ５０２４において、このスレッドが停止される。あるいは、ステップ５０２６において、リターン・バリアがスタックへ挿入され、リターン・バリアにスタックが留まる長さだけスレッドの動作が継続することを許される。
ステップ５０２８において、スタックにおけるフレームが選択される。調べられる最初のフレームは、典型的に、このスタックにおける最も新しいフレームとなる。ステップ５０３０において、選択されたフレームが削除されるバッファにおけるリターン・アドレスを含むかどうか知るために、このフレームが調べられる。

このようなリターン・アドレスがあることが判ると、ステップ５０３２において、リターン・スレッドが指示するバッファないの断片が識別される。ステップ５０３４において、他のフレーム・フィールドが、行われているかも知れないローカル変数値または仮想マシンに固有の変数の最適化の「クリーンアップ」を行うように調整される。ステップ５０３６において、リターン・アドレスがグルー・コードの一部を指示するように変更される。
フレームが削除されるバッファへのリターン・アドレスを含まなければ、あるいはフレームにおける値がいったん調整されると、ステップ５０３８において、スタックにおける全てのフレームが調べられたかどうか決定される。もし調べなかったならば、ステップ５０４０において、スタックにおける次に新しいフレームが選択され、このフレームが調べられる。スタックにおける全てのフレームが調べられると、ステップ５０４２において、スレッドが再開され、あるいはリターン・バリアが除去される。ステップ５０４４において、全てのスレッドのスタックが調べられたかどうか決定される。もし調べられなかったならば、スタックが調べられなかった別のスレッドが選択され、このプロセスが反復される。
スレッドの全てにおける全てのスタックのフレームの全てが調べられ、このスタックに対する適切な変更がなされると、ステップ５０４６において、コード・バッファが削除される。

次に図６Ｅに関して、当該形態を具現する装置について記述する。
図６Ｅは、非ネイティブ・コード５０５２をホスト・コンピュータ５０５４で走らせる仮想マシン５０５０を含むコンピュータ・システムを示している。この仮想マシンは、制御手段５０５６と、非ネイティブなアプリケーション・コードを解釈するインタプリタ５０５８と、非ネイティブなアプリケーション・コードの各部をコンパイルするコンパイラ５０６０と、「スタック・ウォーカ」５０６２とを含んでいる。ホスト・コンピュータは、プロセッサ５０６４とメモリ５０６８とを含む。図６Ｅには、各スレッド間にその時間を適切に分けることにより、幾つかのスレッドを同時に実行する１つのプロセッサが示されるが、それぞれが１つ以上のスレッドを実行する２つ以上のプロセッサを設けることもできる。
コンパイラ５０６０によりコンパイルされたコンパイル・コード５０７０は、メモリ５０６８に格納される。またメモリ５０６８には、プロセッサにより実行されているスレッド数と対応する複数のスタック５０７２、５０７３、５０７４が配置される。
動作において、制御手段５０５６は、ある時点において、例えばメモリの領域を他の目的に用いることを許容するため、コンパイル・コード５０７０のセクションが削除されるべきことを決定する。次に、制御手段はスタック・ウォーカ５０６２に対しコードの当該セクションが削除されるべきことを表示する。このスタック・ウォーカは各スレッドの動作を逐次休止させ、スレッドのスタックにおけるフレームを調べて削除されるコードのセクションを含む記憶域にあるリターン・アドレスを含むフレームを識別する。このようなアドレスは、グルー・コード５０７６の部分のアドレスへ変更され、フレームにおける他のフィールドが、行われたかも知れない、ローカル変数値あるいは仮想マシンに固有の変数の最適化を「クリーンアップ」するように調整される。グルー・コードは、図６Ｄに関して先に述べた方法で動作する。スレッドの全てにおける全てのスタックのフレームの全てが調べられ、スタック内容への適切な変更がなされると、スタック・ウォーカ５０６２が制御手段５０５６に対しコードの当該部分が削除されたことを表示する。次に、制御手段５０５６は、コンパイル・コード５０７０のセクションを削除するように削除手段５０７８を制御する。
要約すると、コードの削除時に、仮想マシンにおける各スレッドが逐次休止させられ、これらスレッドのスタックが、削除されるコードを指示するリターン・アドレス値を探して走査される。これらのケースの１つが見出されると、リターン・アドレス値付近のスタックの状態が、リターンに遭遇する時点（すなわち、スレッドに対する将来のある時点）に当該スレッドに対する仮想マシンの状態を「クリーンアップ」するように調整され、リターン・アドレス値自体は、実行のフローをコードの少数の中央部分の１つへ変えさせるように調整される。コードのこれらの中央部分（「グルー・コード」と呼ばれる）は、ある一般的な検査を行い、当該スレッドに対する適切な方法での実行のフローの継続を生じ、これは通常、コンパイル・バージョンが存在するエミュレートされた命令のセクションに遭遇するまで、以降のエミュレートされる命令の解釈を含む。
上記のいずれかあるいは全てにおいて、本発明の幾つかの特徴がコンピュータ・ソフトウエアを用いて実現された。しかし、無論、当業者には、これら特徴のいずれもハードウエア，またはハードウエアとソフトウエアの組合わせを用いて実現されることが明らかであろう。更に、ハードウエア、コンピュータ・ソフトウエアなどにより行われるファンクションが電気信号などを用いて行われることが容易に理解されよう。

情報の格納に関する特徴は、適切な記憶場所またはストアにより実現されよう。情報の処理に関する特徴は、ソフトウエアあるいはハードウエア、あるいは両者の組合わせにおいて、適切なプロセッサまたは制御手段により実現されよう。
上記のいずれかあるいは全てにおいて、本発明は、下記の形態のいずれか、あるいは一部、あるいはその全てにおいて具現される。すなわち、本発明は、コンピュータ・システムを動作させる方法において具現され、コンピュータ・システム自体において具現され、コンピュータ・システムを動作させる方法を実行するようにプログラムされあるいは構成されるとき、該システムにおいて具現され、そして（または）システムを動作させる方法に従って動作するためのプログラムが記録されたコンピュータ読取可能な記憶媒体において具現されよう。
本文全体に使用されるように、用語「コンピュータ・システム」は、「コンピュータ」、「システム」、「装備」、「装置」、「マシン」などと互換であり得る。コンピュータ・システムは、仮想マシンであり得、あるいは仮想マシンを含み得る。
上記のいずれかあるいは全てにおいて、方法および装置の特徴および特質を含む先に述べた異なる特徴および特質は、適切な方法で組合わせることができる。
本発明が純粋に事例として記述され、細部の修正が本発明の範囲内で可能であることが理解されよう。
本文の記述、および（適切な場合に）請求の範囲および図面に開示された各特徴は、独立的に、あるいは任意の適切な組合わせにおいて提供されよう。

エージェント資料第７−コンピュータ・システム、コンピュータ読取可能な記憶媒体およびこれを動作させる方法、および前記システムを動作させる方法
本発明は、コンピュータ・システムにおいてガーベッジ・コレクタ特に、並行なガーベッジ・コレクタ）を動作させる方法に関し、不要部の整理のためのコンピュータおよびコンピュータ・システムに関し、コンピュータ読取可能な記憶媒体に関し、および仮想マシンに関するものである。望ましい実施の形態にいて、本発明は、グレー・パケットに関し、すなわち、非常に多くのスレッド環境において並行なマーキングＧＣのための低競合グレー・オブジクトに関する。

一般的なレベルでは、本発明は、ランタイム環境に適用可能であり、更に特殊なレベルにおいては、自動的なダイナミック・メモリ管理に適用可能である。
ここでは、「メモリ・オブジェクト」を参照する。これらオブジェクトは、典型的に、フィールドに組織されたメモリの任意の離散領域であり、その一部は他のオブジェクト、更には同じオブジェクトに対する参照であり得る（オブジェクト指向プログラムにおけるオブジェクトと混同してはならない）。
コンピュータ・システムにおけるメモリの効率的な使用のためには、その時の使用がいったん終了すると、再び使用されるようにメモリを再び割当てるため解放させるある機構が所定位置にあることが重要である。
このような「メモリ管理」は、典型的には、ファンクションを実行するためメモリを必要とすることを示すコード、およびこのメモリの使用が終了したときを示すコードをプログラム自体が含む、「手動」であり、あるいはプログラムがコンピュータ・システムにメモリの使用が終了したときを知らせず、その代わりシステム自体が使用されたメモリを識別して復元する方法を実現しなければならない「自動」である。後者は、便宜上「不要部分の整理」と呼ばれ、プログラムによりその時使用されているメモリ・オブジェクト全体にわたりサーチするプロセスを開始するコンピュータ・システムに依存する。サーチの間遭遇するこのようなオブジェクトがその時使用中であると見なされ、遭遇しない他のオブジェクトはその時使用中ではあり得ず、デッド状態と見なされ、従って再割当てに利用可能である。

不要部分の整理（ＧＣ）を行う前の試みにおいて、３つの特定手法が堤案されてきた。「参照カウント」として知られる第１の手法においては、種々のメモリ・オブジェクトに対する参照すなわちポインタの数は保持され、システムは参照がゼロになることにより、前に指示したオブジェクトが再割当てのため「自由」になることを示す機会を探す。このような手法における短所は、マルチスレッド環境において非効率的であること、および循環構造（例えば、オブジェクトＡがオブジェクトＢを参照し、このオブジェクトＢが再びオブジェクトＡを参照するとき）がガーベッジになったときを検出できないことである。
「コピーイング」として知られる第２の手法においては、メモリが、図７Ａにおいて「ＦＲＯＭスペース」１２１０２と「ＴＯスペース」１２１０４として示される２つの部分へ分けられる。オブジェクトに対するメモリは、ＦＲＯＭスペースが一杯になるまでこのスペース内の直線的に増加するアドレスに割当てられる。この時点で、全てのライブ・オブジェクト１２１０６を「ＴＯスペース」における更にコンパクトな領域１２１０８へコピーするＧＣのための全ての作業が停止するよう強制される。同時に、「ＴＯスペース」における新たな場所を勘案するように参照も変更される。ＦＲＯＭスペースとＴＯスペースの役割は逆であり、新たなメモリ割当ては、こんどは前のＦＲＯＭスペースが用いられたと同じ方法でＴＯスペースを用いて継続する。このような手法の主な短所はメモリ要求が多くなること、およびＧＣルーチンが実現されるごとにダウンタイムが生じてＦＲＯＭスペースとＴＯスペース間の役割の切換えが生じることである。
いわゆる「マーク／掃引」手法である第３の手法は、オブジェクトを含む１つの論理ユニットに配置される全てのメモリを呼出す。ＧＣは、割当て要求を満たすのに充分に大きなメモリ領域がヒープにないときに呼出され、この時ＧＣが全てのオブジェクトを「白」に色つけし、参照によりライブ・オブジェクトに対する全てのあり得るパスをトレースすることになる。ＧＣが達したどのオブジェクトも「黒」に色つけされてライブであると見なされるが、達しない領域は「白」のままであり、デッド状態であり再割当てに利用可能であると見なされ得る。この手法の最終段階は、白でマークされた全ての領域が解放されて作業が継続することを許される「掃引」動作を呼出す。

更に詳細に述べれば、マーク／掃引手法では、図７Ｂから判るように、オブジェクトに遭遇するが参照する全てのオブジェクトに達しないマーキング（トレーシング）相においては、これはグレーでマークされ、それに対する参照はグレー・スタックと呼ばれるメモリ・スタックの形態におけるデータ構造１２２０２へ置かれる。（これに関して、典型的なメモリ・スタックは、「最も新しい項目がスタックの最下部に最も近くなるように」項目が上から下へ次々に追加される変更可能なサイズのメモリ・ストアと見なされる。このような規則は、例示の目的のために過ぎない。これは、新たな項目が上へあるいは下へ系統的に追加されるスタックの動作と全く異ならない。）図７Ｂもまた、色つけを含む、メモリ・オブジェクトに対する記憶域であるメモリ・ヒープを１２２０４で示している。
参照自体もまた、データ構造における最初の参照を見つけることにより調べられる。この参照は、グレー・スタックから除かれ、これが参照するオブジェクトは「黒」にされる。次に、トレーシング・プロセスによりまだ遭遇しない他のオブジェクトにおける参照１２２０６は、グレー・スタックへ入れられ、これらのオブジェクトは「グレー」にされる。図７Ｂにおいて便宜上１２２０８で拡大して示される各オブジェクトは、参照の黒／白状態の表示１２２１０、およびスタックにおける他のオブジェクトに対する１２２１２のようなポインタを含む。このプロセスは、グレーのスタックが空になるまで反復される。このトレーシング・プロセスの後に、黒いものが白にされ白いものが将来の使用に供される掃引相が存在する。不要部分の整理の終りに、グレー・スタックが存在しなくなることが理解されよう。
マーク／掃引（トレーシング）手法の主な欠点は、作業が停止する間ダウンタイムが無いことであり、先の２つの手法のいずれよりも更に複雑になることである。コピーするＧＣに対するその主な利点は、空間的な冗長度がほとんどないかあるいは全くないことである。

いわゆる「並行な」環境においては、オブジェクトは、トレースされている間に操作され得る。図７Ｃにおいて、特にオブジェクトにおける参照フィールド「ｂ」（１２３０６）は、異なる参照「ｄ」（１２３０８）を参照するように更新することができる。更新されているオブジェクトＡ（１２３０２で示される）は黒である（すなわち、ＧＣにより完全にトレースされた）が、新たなオブジェクトＢ（１２３０４で示される）は「白」であり、従って、ＡがＢに対する唯一のルートとなるならば、Ｂがデッド状態であると誤識別され得るというリスクがある。このことは、ＧＣがＡに再び達する理由がなく、従ってＢが決してトレースされないゆえに生じる。並行なＧＣを用いるシステムは、オブジェクトＢを「グレー」にして、これらオブジェクトに対する参照をグレー・スタックへ当てるような状況を捕らえるため「白いバリア」を用いる。各仮想マシンに対しては通常１つのグレー・スタックしかないので、ＧＣにより使用されるときは、メモリおよびグレー・スタックの使用における競合が生じやすい。
事実、グレーのオブジェクトの組は、制御について幾つかのスレッド間で共有されるリソースであり、その全てはこれを変更し得る。従って、任意の変更はある種のロッキング機構により取締られねばならない。グレー・セットは、トレーシング・プロセスの間頻繁に使用され、従ってグレー・セットに対してアクセスしようとする試みがすでに使用中であることを見出す可能性が高い。更に、前記ロッキング機構により課されるオーバーヘッドが増加する傾向を有する。換言すれば、並行なＧＣにおいては、システムの他の部分がオブジェクトを変更しようと試み得るが、ＧＣは依然としてライブな記憶場所とデッドである記憶場所を見出す方法をトレースし続ける。ライブなオブジェクトがデッドであると不正に識別され、これにより再割当てが行われないようにするために特殊な処置をとることが必要となる。これにより、データの消滅および（または）逸失が結果として生じ得る。このような問題に対する典型的な解決策は、オブジェクトの内容を変更するおそれがある全ての操作に対して「書込みバリア」を用いることであった。
ＧＣに対する更なる問題は、たとえ非常に生じやすい場合でも、グレー・スタック全体に対するスペースがＧＣサイクルの初めに割当てられねばならないこと、および通常は最悪の偶発性に対処するに充分に大きくなければならないことである。従って、グレー・スタックのため留保されたスペースの大部分が浪費される。

本発明は、グレー・スタックへのアクセスに多くの競合が生じる問題を克服するためには、１つの特質においてグレー待ち行列の管理と関連するものと見なすことができる。
本発明は、１つの特質において、コンピュータ・システムにおいてガーベッジ・コレクタを働かせる方法を提供し、ガーベッジ・コレクタが（典型的には、所与の時点において）１組の部分的にトレースされたメモリ・オブジェクト（典型的には、「グレー」オブジェクト）を持ち、前記方法は複数の離散パケットにおいて前記オブジェクトの組を処理する（あるいは、この組を前記複数の離散パケットへ分ける）ことを含む。
複数の離散パケットにおける前記組を処理することにより、この組は必要とするスペースを占めるに過ぎない。このことは、実質的大きな固定サイズである公知のグレー・スタックと対照され得る。
ガーベッジ・コレクタは、例えば、増分型あるいは休止するガーベッジ・コレクタでよい。しかし、動作の速度については、ガーベッジ・コレクタは並行なガーベッジ・コレクタであることが望ましい。（典型的に、並行なガーベッジ・コレクタは、少なくとも１つの他の制御のスレッドの実行と同時に動作する、すなわち、不要部分の整理と同時に生じる変化を阻止しない。非並行型ガーベッジ・コレクタにおいては、コレクタのスレッドが実行している唯一のスレッドであり、従ってロッキングが必要とされない。）この場合、各パケットがたかだか任意の所与の時点に１つの制御のスレッドによりアクセス可能であることが望ましい。このことは、１つのスレッドが１つのパケットで終了しかつ別のパケットが働くことを必要とする機会に必要とされるロッキングの量を制限し得る。このことは更に、非常に頻繁に使用されるシステムにおけるＧＣの性能を改善することができ、そして（または）メモリを使用されないように解放することによりコンピュータ・システムのメモリ要求を減じることができる。
異なるパケットは、異なる制御のスレッドにより同時にアクセスすることができることが望ましい。このことは、システムにおける同時実行の程度を強化することができる。
同時実行を強化するためには、異なるスレッドにより使用できるようにパケットが個々に処理されることが望ましい。

その時特定の制御のスレッドにより使用中である各パケットが「チェック・アウト」とマークされ、その時使用する特定の制御のスレッドを持たない各パケットは「チェック・イン」とマークされ、チェック・アウトされたパケットのみが特定の制御の前記スレッドによりオンに操作することができることが望ましいが、チェック・インされた（グレーの）各パケットの場合は、内容がスレッドにより読出すことができる前に、手動の実行ロックが課されることが望ましい。このことは、パケットを管理する便利な方法を供することができる。
パケットの最小数は２であり、後で述べるように、１つはグレー・オブジェクトに関して充填するためのものであり、他は「黒くする」間に空にするためのものである。パケットは、（特に多数のスレッドが実行中であるとき）パケットへの分割の利点を許しかつ多すぎるメモリを使用する欠点を避けるのに充分な長さであることが望ましいが、管理ができず過剰数のロックを生じるほど長くないことが望ましい。従って、各パケットが１つのオブジェクトへの参照ごとに１つずつ多数のスロットを含むことが望ましく、この数は少なくとも２、５、１０、５０あるいは１００の１つである。同様に、各パケットが１つのオブジェクトへの参照ごとに１つずつ多数のスロットを含むことが望ましく、この数は５０００、１０００、５００あるいは１００より少ない１つである。これらのおおよそのサイズが広範囲の用途にわたり最適であることが判った。
パケットのサイズのそれほど重要でない処置は、バイト数に関するその長さである。これは２の冪であることが望ましい。各パケットは、少なくとも８、１６、３２、６４、１２８および２５６バイトの長さの１つであることが望ましい。各パケットは、１０２４、５１２、２５６、１２８および６４バイト長より短いことが望ましい。
前記各パケットは、固定されたサイズであることが望ましい。各パケットは、固定数のスロットと、当該パケット内でその時使用されるスロット数の表示（典型的には、ヘッダ）とを含むことが望ましい。
メモリ要求を節減するために、パケットは、パケットがデマンドに従って生成され破壊されることが望ましい。換言すれば、パケットが必要に応じて生成、破壊できるようにダイナミックに管理される。後で述べるように、存在するパケット数は、マーキング・プロセスと黒くするプロセス間の間隔のファンクションである。
パケットの破壊は、全パケットの一部の内容を一緒にマージすることによって少なくとも部分的に達成できる。

本発明は、緊密に関連する特質において、１組の部分的にトレースされるメモリ・オブジェクトを持つガーベッジ・コレクタと、複数の離散パケットにおいて前記１組のメモリ・オブジェクトを処理する手段とを含むコンピュータ・システムを提供する。
ガーベッジ・コレクタは、並行なガーベッジ・コレクタであることが望ましい。
各パケットが、所与の時点にたかだか１つの制御のスレッドによりアクセス可能であることが望ましい。
当該コンピュータ・システムは更に、同時に異なる制御のスレッドにより異なるパケットをアクセス可能にする（あるいは、可能にするための）手段を含むことが望ましい。
コンピュータ・システムは更に、パケットを異なるスレッドにより使用できるように個々に処理する（あるいは、処理するための）手段を含むことが望ましい。
コンピュータ・システムは更に、その時「チェックアウト」された特定の制御のスレッドにより使用中である各パケット、およびその時「チェックイン」された特定の制御のスレッドを持たない各パケットをマーキングする（あるいは、マーキングするための）手段と、前記の特定の制御のスレッドによりチェックアウトされたパケットのみについて動作を許容する手段とを含むことが望ましい。
各パケットは、１つのオブジェクトに対する参照ごとに１つずつ多数のスロットを含むことが望ましく、この数は少なくとも２、５、１０、５０あるいは１００の数である。また、各パケットが、１つのオブジェクトへの参照ごとに１つずつ多数のスロットを含むことが望ましく、この数は５０００、１０００、５００あるいは１００より少ない数である。前記各パケットは、固定サイズである。各パケットは、固定数のスロットと、該パケット内でその時使用されるスロット数の表示とを含む。
コンピュータ・システムは更に、デマンドに従ってパケットを生成し破壊する（あるいは、生成し破壊するための）手段を含むことが望ましい。
コンピュータ・システムは更に、全パケットの一部の内容を一緒にマージすることにより、パケットを少なくとも部分的に破壊する（あるいは、破壊するための）手段を含むことが望ましい。
本発明は、緊密に関連する特質において、使用されることのないメモリを解放するように、コンピュータ・システムにおける並行なガーベッジ・コレクタ・システムを多重スロット環境において動作させる方法を提供し、該方法は、
１つのメモリ・グループにおける各オブジェクトの状態をトレースし、
トレーシング・プロセス（白）中にオブジェクトが遭遇されなかったか、オブジェクトとこれが参照する全てのオブジェクトがトレーシング・プロセス（黒）により遭遇されたか、およびオブジェクト自体が遭遇されたがこれが参照するオブジェクトの一部が達しなかった（グレー）かに従って識別子を割当て、
グレーの識別子で割当てされた組を離散パケットへ分け、
前記各スレッドがその各々のパケットにおいて他の前記スレッドおよびパケットと独立的に動作できるように、前記各パケットを各スレッドに割当てる
ことを含んでいる。

本発明は、緊密に関連する特質において、コンピュータ・システムを提供し、該コンピュータ・システムは、
（望ましくはランタイム・エンジンである）並行なガーベッジ・コレクタと、
１つのメモリ・グループにおける各オブジェクトの状態をトレーシングする手段と、
オブジェクトがトレーシング手段により遭遇されなかったか、オブジェクトとこれが参照する全てのオブジェクトがトレーシング手段（黒）により遭遇されたか、およびオブジェクト自体が遭遇されたがこれが参照するオブジェクトの一部が達しなかった（グレー）かに従って識別子を割当てる手段と、
グレーの識別子で割当てられた組を離散パケットに分ける手段と、
前記各スレッドがその各々のパケットにおいて前記スレッドおよびパケットとは独立的に動作するように、前記各パケットを各スレッドに割当てる手段と、
を含んでいる。
本発明は、並行な不要部分の整理システムを動作させる手段と、各パケットが任意の時点で多くとも１つのスレッドによりアクセスできるようにグレー待ち行列をパケットに分ける手段とを含むコンピュータ・システムに拡張する。
本発明は、緊密に関連する特質において、コンピュータ・システム環境における並行な不要部分の整理システムを動作させる方法を提供し、これにおいてはグレー待ち行列は各々が任意の時点で多くとも１つのスレッドによりアクセスできるパケットに分けられる。
当該コンピュータ・システムは、マルチスレッド環境において動作するようになっていることが望ましい。
コンピュータ・システムは更に、パケットに対するマネージャを含むことが望ましい。
本発明は、上記方法によりプログラムされたときのコンピュータに拡張する。
本発明は、１組のメモリ・オブジェクトを複数の離散パケットにおいて処理するように、プログラムされたとき、１組の部分的にトレースされたメモリ・オブジェクトを持つガーベッジ・コレクタを含むコンピュータ・システムに拡張する。
本発明はまた、上記方法を提供するプログラムが記録されたコンピュータ読取可能な記憶媒体に拡張する。
本発明は、緊密に関連する特質において、コンピュータ・システムにおいて１組の部分的にトレースされたメモリ・オブジェクトを持つガーベッジ・コレクタを動作させる方法であって複数の離散パケットにおいて前記１組のメモリ・オブジェクトを処理することを含む方法を提供するプログラムが記録されたコンピュータ読取可能な記憶媒体を提供する。
本発明は、上記コンピュータまたはコンピュータ・システムを含む仮想マシンに拡張する。

本発明は、緊密に関連する特質において、上記方法により動作されるとき仮想マシンを提供する。
本発明は、緊密に関連する特質において、上記コンピュータ読取可能な記憶媒体により動作されるとき仮想マシンを提供する。
本発明の望ましい実施の形態については、純粋に事例として、添付図面に関して次に記述する。
最初に、本発明を実施することができる特定の方法の更に包括的な記述の続いて、本発明の性質の概要を述べる。
不要部分の整理（ＧＣ）は、ランタイム環境が任意の時点で使用されたが現在は使用されていないメモリを識別することができ、かつ他の目的のため再使用に供することができるプロセスである。並行なＧＣは、プログラムまたはシステムにおける他のアクティビティを現在進行中のＧＣアクティビティにより妨げる必要がないようなＧＣを実現する方法である。
トレーシングＧＣの（コンカレントあるいはその他の）作業は、所与のあるルートの組１２４０４から始まる１２４０２として全体的に示されるメモリ・オブジェクト間の図７Ｄにおいて矢印１２４００として示される参照に従うことにより働き、「ライブ」として取扱われねばならない全てのオブジェクトの組を確定する。前記の組にないオブジェクトは、「デッド」であると見なされ、そのメモリ・スペースは再使用することができる。ルートの組は、不要部分の整理のためのある開始条件であり、典型的に、関心スタックに対する参照を含む１組のパブリック参照である。
任意の時点におけるトレーシング・プロセスの状態は、トリコロール・アブストラクションを用いて要約することができる。各オブジェクトは、これと関連するカラーを有する。すなわち、
白：このオブジェクトは、トレーシング・プロセスの間まだ遭遇されない。
黒：このオブジェクトおよびこれが参照する全てのオブジェクトはトレーシング・プロセスにより遭遇されたものである。
グレー：このオブジェクト自体は遭遇されたが、これが参照するオブジェクトの一部は到達していない（換言すれば、グレーの色づけは進行中の作業を示す）。

トレーシングＧＣアルゴリズムは、下記のように働く。すなわち、

このアルゴリズムがいったん完了すると、どれかの「白の」オブジェクトにより占有されるスペースは再使用できる。
コピーイングＧＣと違い、マーキングＧＣはこのアブストラクションをやや逐語的に構成する傾向があり、オブジェクトのカラーはメモリにおけるその絶対的位置により黙視的に決定される。本発明は、種としてマーキングＧＣアルゴリズムおよび手法に関する。
マーキングＧＣにおいては、オブジェクトのカラーはオブジェクト自体にオブジェクトのヘッダ（図７Ｅの１２５０２）の一部として格納される。このカラーは、４つの状態、白、黒、グレーおよび自由（すなわち、オブジェクトが割当てに供し得る）の１つにあるマーク情報Ｍ、１２５０４としてコード化される。
Ｍは、典型的に、４つの個別の状態を一緒にコード化させる１対のビットとなる。オブジェクトの再色づけは、オブジェクトのヘッダにおけるＭの状態情報を適切な方法で変えるものである。望ましい実施の形態においては、オブジェクトの色づけはオブジェクトの寿命の間記憶される。ＧＣの動作外では、全てのオブジェクトは白に色づけされる。
効率の考察は、グレーのオブジェクトの組は（グレーに再色づけすることにより）追加でき、あるいは（黒に再色づけすることにより）除去することができる個別のエンティティとして処理できることを示す。この組は、これまでは、スタックとして実現されてきた。通常は、グレーのスタックは、どこにアレイにおける読出しおよび書込みが生じるかを示すように変更可能である付加的な指標を持つ別のスタックまたはアレイとされる傾向がある。図７Ｆは、空のスタック１２６０２を示している。

並行なＧＣアルゴリズムにおいては、ＧＣがトレーシング中である間はシステムの他の部分は変化するオブジェクトであり得る。注意しないと、ライブのオブジェクトはデッドとして誤認識され得る。この問題を取除く典型的な方法は、オブジェクトの内容を変え得る全ての動作に対して書込みバリアを用いることである。異なる構成が異なる方法で働き得るが、これらの構成は全て、制御の非ＧＣスレッドがグレーのオブジェクトの組を変え得ることを必要とする傾向がある。
一般に、各アクセスごとに全体としてロックされねばならない１つのモノリシックなグレー・オブジェクトの組を持つ代わりに、本発明は、望ましくは各スレッド（および、このスレッドのみ）が切離した状態で働き得るセグメントを与えられるように、前記の組を離散的なセグメント、すなわちパケットへ分ける（図７Ｄにおける事例１２４０６参照）。これは、スレッドが１つのパケットで終り且つ働く別のパケットを必要とする場合に要求されるロッキング量を最小化することができる。従って、パケットは、グレーのスタックを完全に置換える（これは、図７Ｄのスタックからヒープへの矢印がなぜ点線で示されるかの理由である）。
従って、本発明は、いわゆる「グレーのパケット」に関係し、特に、高度のマルチスレッド環境において並行な不要部の整理をマーキングするための競合度の低いグレー・オブジェクトの組の提供に関する。
あるＧＣは、メモリにおけるオブジェクトを移動する。ここで使用されるシステムは、並行なＧＣではそうすることが困難であるゆえにこれを行わない。その代わり、「マークおよび掃引」動作が行われる。この場合、白である全てがトレーシングすなわち「マーク」プロセスの終りに解放される。トレーシング・プロセス以降に、掃引相が生じる。この掃引相では、黒いものが白くされ、白いものが将来の使用のため利用できるようにされる。
グレー・パケット・マネージャ（ＧＰＭ）は、グレーのパケットを管理するために本文に述べた手法によって提供される。ＧＰＭは、プログラムの開始時に現われるが、典型的には、ガーベッジ・コレクタもまた動作するまでは動作しない（ハウスキーピングの目的を除いて）。
特にＧＣスレッドに限定しないが任意のスレッドは、ときにグレーになることがある。例えば仮想マシン（ＶＭ）においては、ＧＰＭがその時グレー・パケットと呼ばれるものに対するそれ自体のメモリについてスレッドにより問合わされる。グレー・オブジェクトの組を別のパケットへ分ける理由の１つは、スレッドがそれ自体のグレー・パケットを自由にできるようにするためである。スレッドが一杯であるかそれに非常に近いグレー・パケットへの書込みを続けることを欲するならば、ＧＰＭはこのスレッドへ新たなパケットを与え、一杯のパケットを捨ててこれを記憶する。ＧＰＭは、空のパケットの待ち行列を用意完了状態に保持することができる。どんな数のスレッドでも、それ自体の別のパケットを自由にするようにでき、その結果このグレー・スタックを多数の排他的なアクセス領域へ分けることができ、かつグローバルなロックは要求されない。
グレー・パケットは同じ小さなアレイであり、要求次第で作成され且つ破壊される。これらパケットは、完全なパケットとして取扱われる。グレー・パケットは、典型的に、サイズが２５６バイトであり、６０参照まで保持することができる。これは、６０回に１回のアクセスしかグレー・パケットがＧＰＭと通信することを必要としないことになる。カレントなＧＣがないときは、アクティブなグレー・パケットは存在しない。

このような手法の最も有効な特徴は、ロッキング量が最小限であることであり、要求に従ってグレー・パケットのダイナミックな作成および破壊が生じ、かつメモリ要求を最小化するように全パケットを部分的にマージするシステム能力が存在する。また、全ておよび一部の完全パケットの分離は、ＧＰＭ内部でさえある程度の同時実行を許容し、その結果、ＧＰＭに対して呼出しが行われるならば、これはロックされたエンティティではない。
図７Ｄに略図的に示されたように、１組のグレー・パケット１２４０６は、プログラムまたはシステム内のブロックとして存在する。各ブロックは、固定数のスロット１２４０８を含み（それぞれが１つのオブジェクト参照を記述することができ）、かつこのブロック内でどれだけ多くのスロットがその時使用中であるかの表示を含む。望ましい実施の形態においては、チェック・インされたパケットが、チェーンを形成するようにリンクされることが望ましい組に分けられる。個々のパケット１２４０６の構造は図７Ｇに示される。各グレー・パケットは、チェック・アウトされ、その場合１つの特定の制御のスレッドによりその時使用されており、あるいはチェック・インされ、この場合は特定の制御のスレッドはこれを使用していない。
グレー・パケットは、プログラムまたはシステム内の個々のモジュール、すなわち、グレー・パケット・マネージャすなわちＧＰＭにより管理される。ＧＰＭは、下記のリソースを内部に保持する。すなわち、
一杯：一杯のパケットのリスト
一部一杯：一部一杯のパケットのリスト
上記リストはそれぞれ、これに対するアクセスを制御する個々のロックを有する。パケットは、これが上記リストのいずれかにあるならば、チェック・インされる。
外部では、ＧＰＭが下記の基本的サービスを提供する。すなわち、
・ｇｅｔＥｍｐｔｙＰａｃｋｅｔ（）：空のパケット（あるいは、一部一杯であるが、完全に一杯ではないパケット）を取得し、これを呼出しスレッドへ戻す。
・ｇｅｔＦｕｌｌＰａｃｋｅｔ（）：一杯のパケット（あるいは、一部一杯であるが、空でないパケット）をチェック・インされたパケットから取得し、その状態をチェック・アウトへ変更し、かつこれを呼出しスレッドへ戻す。空のパケットしか存在しなければ、ＮＵＬＬを返す。
・ｓｕｂｍｉｔＰａｃｋｅｔ（ｐ）：グレー・パケットｐがその時チェック・アウトされることを検証し、次にその状態をチェック・インへ変更する。
ＧＰＭは、上記動作の各々をロック状態下で行う。
ＧＰＭは、これが選択したどんな順序でも取扱うことができ、「後入れ、先出し」のシステムはない。

外部では、ＧＰＭは下記ＡＰＩにより用いられる。すなわち、

各制御のスレッド（ＧＣを含む）は、スレッドのローカルパケットインハンドの（すなわち、ｔｌ−ｐｉｈ）グレー・パケット・ポインタを有する。このポインタは、ＮＵＬＬ（スレッドが自由になるパケットを持たないことを示す）であり得るが、ＮＵＬＬでなければ、これはチェック・アウトされたパケットを参照しなければならない。
オブジェクトｉをグレーとしてマークすると、

もし占有されたフィールドがパケットに可能なスロットの最大数と一致するならばパケットは一杯にされたといわれる。
黒くする主アルゴリズムは、下記となる。すなわち、

黒くするパケットを取得することは、

この概念は、マーキングおよび黒化の両プロセスが存在するならば他のスレッドには見えないことが保証され得る、自由になるスレッドのパケットにおいてのみ動作することである。従って、パケットを提示して、黒にする空のパケット（単数または複数）を取得するため、ＧＰＭとの相互動作が要求されるときを除いて、ロッキングしない大半の時間が要求される。

ＧＣでない各スレッドが周期的に自由になるパケットをＧＰＭへ再び提示する（ＧＣのみがパケットを黒にすることができる）。これは、ＧＣが非ＧＣスレッドのローカル・データ構造を調べる必要があるときに典型的に行われる。これらのパケットが部分的に完全であるから、ＧＰＭにおける部分リストがエントリをどのように取得するかである。できるだけ少ないグレー・パケットが割当てられることが望ましいので、ｇｅｔＥｍｐｔｙＰａｃｋｅｔ（）は、２つの部分的パケットの内容を１つの更に一杯になったパケットへ「フォーカス」することにより部分的なリストから空のパケットを作ることが可能な場合を選好し、呼出し側へ戻すことができる空のパケット（あるいは、少なくとも一杯の程度が少ないパケット）は残したままにする。完全に新しい空のパケットは、部分的なパケット・リストが空である場合だけ作成される。
以上のことから判るように、この手法の主な目的は、グローバル・データ構造に対するロックされたアクセスを最小限にするお蔭で、スレッドが非常に多い環境における並行なＧＣの性能を改善することである。従って、この手法によるコンカレントＧＣを用いる商品は、更に伝統的な手法を用いる商品より良好に動作することになろう。
グレー・パケット・マネージャの主要ファンクションの一部の要約は、下記の表に示される。この表では、各ファンクションはアンダーラインを付けて示され、このファンクションのステップはファンクション自体に従う。各ステップは、これが一杯の、ほぼ一杯の、あるいは空のパケットを用いて行われかどうかに従って、３つの欄（「一杯のパケット」、「部分的に一杯のパケット」あるいは「空のパケット」）の１つまたは２つに示される。
一杯のパケット 部分的に一杯のパケット 空のパケット

マーキング相−マークするオブジェクトがこれ以上なくなるまで下記の反復段階で進行する
（a） 空のパケットを取得（新しい空のパケットを取得しそしてグレーとしてマークする）
（ｂ）一杯のパケットを依頼する（一杯のグレーのパケットを依頼する）
（ｃ）空のパケットを取得（別の新しいパケットを取得）
黒くする相−これは、ステップ（ｂ）が失敗するまで反復的に進行する
（a） 空のパケットを取得（黒にする目的のために）
（ｂ）「空の」パケットを依頼（ＧＰＭの中へ）
スレッドのデッド
スレッドのデッドと同時に、ｔｌ−ｐｉｈをＧＰＭへ依頼する
全般的な準備
ＧＣは他のスレッドのｔｌ−ｐｉｈをＧＰＭへ周期的に依頼する

最後に図７Ｈに関して、望ましい実施の形態の全ファンクションについて、特に種々の主構成要素間のパケットのフローを参照して、次に要約する。

図７Ｈにおいて、グレー・パケット・マネージャ（ＧＰＭ）が１２７００で示され、ガーベッジ・コレクタ（ＧＣ）が１２７０２で示され、種々の制御のスレッド（ミューテータ）が１２７０４、１２７０６、１２７０８で示され、パケットは１２４０６で示される。スレッド１２７０８は「ｎ番目」のミューテータを表わし、トリガする書込みバリアを持たないから、パケットのフローを示さない。種々のパケット・フローが丸つき番号で示され、その意味は下記のとおり。
１）新たな空のパケットを取得
２）一杯のパケットを依頼
３）ほぼ一杯パケットを依頼
４）黒くする一杯のパケットを取得
５）空のパケットを依頼

並行および他のＧＣ手法全般の概要は、Ｒ．ＪｏｎｅｓおよびＲ．Ｌｉｎｓ著「不要部分の整理：自動的なダイナミック・メモリ管理のためのアルゴリズム（Ｇａｒｂａｇｅ Ｃｏｌｌｅｃｔｉｏｎ：Ａｌｇｏｒｉｔｈｍｓ ｆｏｒ Ａｕｔｏｍａｔｉｃ Ｄｙｎａｍｉｃ Ｍｅｍｏｒｙ Ｍａｎａｇｅｍｅｎｔ）」（Ｊｏｈｎ Ｗｉｌｅｙ発行、ＩＳＢＮ ０−４７１−９４１４８−４）に見出すことができる。この文献の開示は、参考のため本文に援用される。

上記のいずれかまたは全てにおいて、本発明の幾つかの特徴がコンピュータ・ソフトウエアを用いて実現された。しかし、無論、当業者には、これらの特徴のいずれもハードウエアまたはハードウエアとソフトウエアの組合わせを用いて実現されることが明らかであろう。更に、ハードウエア、コンピュータ・ソフトウエア、などにより行われるファンクションが電気信号などを用いて行われることが容易に理解されよう。
情報の格納に関する特徴は、適切な記憶場所またはストアにより実現されよう。情報の処理に関する特徴は、ソフトウエアあるいはハードウエアにおいて、あるいは両者の組合わせにおいて、適切なプロセッサまたは制御手段により実現されよう。
上記のいずれかあるいは全てにおいて、本発明は、下記の形態のいずれか、あるいは一部、あるいはその全てにおいて具現されよう。すなわち、コンピュータ・システムを動作させる方法において具現され、コンピュータ・システム自体において具現され、コンピュータ・システムを動作させる方法によりプログラムされ、あるいはこれを実行するよう構成されるときこのシステムにおいて具現され、そして（または）コンピュータ・システムを動作させる方法に従って動作するためのプログラムが記録されたコンピュータ読取り可能な記憶媒体において具現されよう。
本文において用いられるように、用語「コンピュータ・システム」は、「コンピュータ」、「システム」、「装備」、「装置」、「マシン」などに対して互換である。コンピュータ・システムは、仮想マシンであり得、あるいはこれを含み得る。
上記のいずれかあるいは全てにおいて、方法および装置の特徴および特質を含む上記の異なる特徴および特質は、任意の適切な方法で組合わせることができる。
本発明は純粋に事例として記述され、細部の修正が本発明の範囲内で可能であることが理解されよう。
本文の記述、および（適当な場合に）請求の範囲および図面に開示された各特徴は、独立的に、あるいは適切な組合わせにおいて提供されよう。

エージェント資料第８−コンピュータ・システム、コンピュータ読取り可能な記憶媒体およびこれを動作させる方法、および前記システムを動作させる方法
本発明は、コンピュータ・システムおよびコンピュータ・システムを動作させる方法に関する。本発明は、コンピュータ・システムおよび割込みの処理のための方法に関することが望ましい。本発明は、仮想マシンおよび（または）多重スレッド環境に関する特定の（しかし、これに限定しない）用途を見出すものである。本発明の望ましい実施の形態は、ジャバで書かれたデバイス・ドライバ割込みハンドラを実行することに関する。

コンピュータ・システムにおける割込みハンドラは、ＣＰＵと、このＣＰＵに接続された他の装置（通常は、ハードウエア品目）との間の通信を管理する方法として用いられる。ＣＰＵと装置は、デバイス・ドライバとして知られ特定の装置に一義的であるソフトウエアを介して相互に働く。用語「装置」は、キーボード、プリンタ、マウス、スキャナなどのようななじみのある品目、実際には任意の入出力装置を含む。
デバイス・ドライバ・ソフトウエアの実現においては、通常は装置の割込みがドライバ自体の内部のコードにより処理されることが要求される。
このような割込みを処理するためドライバの一部として書かれたコードは、通常はこれに課される著しい制約を有し、これは、このようなコードが、オペレーティング・システムにより提供される小さな固定サイズの別個のスタックを用いてほとんど任意の時点で主幹アプリケーションに関して実行されるゆえである。このため、オペレーティング・システムは割込みを直接処理する。
割込みの処理の確認されている問題に照らして、非ネイティブなソフトウエアを含むコンピュータ・システムの場合に、割込みハンドラが（ホストの）オペレーティング・システムにより提供される。割込みができるだけ速く処理されることが重要であり、従って、オペレーティング・システムは割込みを取扱うように選定される。このような手法には、共に非ネイティブ・システムが実際の割込みレベルから著しく隔てられるという事実から生じる２つの主な問題がある。第一に、非ネイティブなシステムが割込みを直接処理せず、非ネイティブ・システムが割込みについて知らされる前に、実際の割込みがホスト・システムによりすでに切離されているから、特殊な装置の処理（装置のレジスタから／への特殊な値の読出し／書込み）がもはや有効でないという問題が存在する。第二に、生じる実際の割込みと、これと関連して実際に実行する非ネイティブなコードとの間に実質的な長さの時間が経過してしまっている。

本発明の第１の特質によれば、ネイティブなオペレーティング・システムと非ネイティブなソフトウエアを含み、非ネイティブなソフトウエアが割込みを直接処理するように構成されるコンピュータ・システムが提供される。このため、（ホスト）オペレーティング・システムにより割込みが直接処理され非ネイティブなソフトウエアが後で生じている割込みについて知らされるのではなく、割込みが非ネイティブなソフトウエアにより同期的に処理される。非ネイティブなソフトウエアが翻訳された言語を含むことが望ましい。本発明の特に望ましい実施の形態においては、非ネイティブなソフトウエアがジャバ言語を含む。本発明はまた、ジャバに似た言語にも適用可能である。コンピュータ・システムは、仮想マシンとして構成されあるいは仮想マシンを実現することが望ましい。
本発明の第１の特質によれば、コンピュータ・システムを動作させる方法も提供され、コンピュータ・システムがネイティブなオペレーティング・システムと非ネイティブなソフトウエアを含み、割込みが非ネイティブなソフトウエアにより直接処理される。
望ましい実施の形態においては、本発明は、（本発明の多くの部分はたしかに他の翻訳言語にも同様に適用するが）非ネイティブ・ソフトウエアにおける、特にジャバにおけるその割込みハンドラを含むデバイス・ドライバの完全な実現に関する。
非ネイティブな言語、特にジャバの使用時には、割込みレベルにおいて色々な問題に遭遇する。例えば、ジャバ（および他の言語）は不要情報が収集された言語であるという事実が、割込みハンドラ・コードが、干渉することなくあるいはそれ自体をそれゆえに損なうことなく、不要部分の整理プロセスにおける任意の時点で良好に走るために必要であるという問題の複雑さを加える。上記および他の問題については、以下において更に詳細に論述される。
この問題の処理のため出願人が知る唯一の従来の堤案が、一般的な方法で割込みを処理した後に非割込みレベルで走る高い優先順位のジャバ・スレッドに対して生じる記事を送る前に廃棄した非翻訳言語（アセンブラまたはＣ）で実現されたそれ自身の専用の割込みハンドラを有する（ジャバの）仮想マシン（ＶＭ）に関与するものであった。
このような手法には、共に装置割込みを処理するよう書かれたジャバ・コードが実際の割込みレベルから著しく異なるという事実から生じる２つの主な問題があり、すなわち、第一に、問題となる装置のタイプに従って、処理する（装置レジスタから／へ特殊な値を読出す／書込む）特殊な装置はもはや必ずしも有効でないという問題である。実際の割込みはすでに見切られ、第二に、実際の割込みの発生とジャバ・コードの実際の実行との間には実質的な長さの時間が経過していることである。

ジャバは幾つかの規則に固執しなければならず、また割込みレベルにおいてジャバに特有の規則への固執があり得ることを保証するのは難しいため、割込みの処理のためジャバを使用することは実用的でないと考えられた。
例えば、コードの一部が待ち行列、挿入する動作および取出す動作を維持するため１つのコードにおいて動作しようとする同時の試みを阻止するためミューテックス（ｍｕｔｅｘ）のようなセマフォーを必要とするときは、信号が取得されるまで動作が行われない。セマフォーは、割込みレベルでは取得できない。セマフォーが非割込みレベルですでに取得されていたならば、信頼し得る動作は割込みレベルでは不可能である。
ジャバ（および、他の翻訳言語）の場合にも、コード管理に問題がある。
従来技術における問題は、割込みをリアルタイムに処理できないことである。例えば、先に示した堤案においては、システムは正規のスレッドにおける割込みをできるだけ早く処理する要求を出すだけである。
しかし、このような解決法では非ネイティブな（ジャバ）コードが実際の割込みレベルで決して走らないという事実は、不要部分の整理における問題、すなわち先に示したことにおける問題を実質的に軽減する。
非ネイティブなコードを実際の割込みレベルで実際に走らせる問題に対する解決法は，下記の小さな問題のいずれか、あるいは一部、あるいはその全てにおいて、下記のように解決される小さな問題へ分解し、この解決法のいずれも任意の適切な方法で組合わせることができよう。
本発明の第２の特質によれば、を含む割込み処理方法を含むコンピュータ・システムが提供され、該方法においては、割込み処理方法の実行が最初の割込みに先立って開始されるようになされ、実行は待機中の状態へ進み、割込みが生じるときに再開させられる。この割込み処理法は、コンピュータ・システムの初期設定時に開始されるように構成されることが望ましい。
本発明の実施の一形態においては、非ネイティブなソフトウエアによって特殊な割込みハンドラ方法が提供される。割込みが生じると、当該方法が呼出される。この方法の呼出しと同時に、種々のステップ、例えば必要なスタックおよびフレームのセットアップが行われる必要がある。割込みが処理されると、当該方法が閉じられる。異なる方法を異なる割込み、すなわち異なるＩＲＱに対して書込むこともでき、従って、各方法が適切な方法で特定の割込みを処理する。
本発明の第２の特質によれば、割込み方法はシステムのセットアップの一部として開かれることが望ましく、この方法は用意ができて、割込みが生じるときを待機する。このように割込みハンドラの実行は、従って割込みの処理を速くすることができる。このことは、非ネイティブな言語が翻訳言語である場合に特に重要である。解釈は、ネイティブな命令の実行と比較するとより遅い。割込みをできるだけ速く処理することが重要であるので、割込みがオペレーティング・システムにより処理されることが望ましいと考えられてきた。しかし、本発明の第２の特質によれば、非ネイティブなコードによる割込みの処理を、割込みが生じたときにいつでも使用できるスタックを提供することによって速くすることが可能である。このように、割込みを処理するための翻訳言語の使用に固有の実行速度の損失の少なくとも一部を避けることができる。

当該割込み処理方法は、待機状態に固執するスタックを開始時に生成するように構成されることが望ましい。割込み処理方法は、スタックが待機状態に固執するように恒久的にアクティブでない状態にされる実行スレッドを開始時に含むように構成されることが望ましい。このため、スタックを開くためのステップがすでにとられており、割込みが生じるとき直ちに割込みを処理することができる。
ある場合、例えばジャバが非ネイティブ言語として用いられる場合、スレッドを完全に破壊することが可能である。多くの場合、スレッドにより使用されるメモリを解放することができるので、このことが選好される。他の場合は、スレッドの破壊は可能ではない。スレッドは、割込みが生じるまで休止状態にある。
当該方法は、割込みが生じるときスタックを用いて制御の割込みフローを行うことによってスレッドが明らかに再活動化させられるように構成されることが望ましい。このような再活動化は、スタックを用いて制御の割込みフローを行う結果であることが望ましい。
制御の割込みフローは、割込み処理方法スレッドが再活動状態になったように見えるように、割込み処理方法のスタックへ切換わる。
当該割込み処理方法は、複数の異なる待機状態を含むことが望ましい。このため、本発明の第２の特質に従って、所与の装置に対する異なるタイプの割込みが１つの割込みハンドラ方法を用いて処理されることが可能である。
本発明の第２の特質はまた、割込みが生じるとき非ネイティブな割込みスレッドのスタックが切換えられるコンピュータ・システムをも提供する。この割込みスレッドのスタックは、ジャバ・スタックであることが望ましい。
非ネイティブな割込みスレッド・スタックがほぼ一杯であることが望ましい。
コンピュータ・システムは、仮想マシンとして構成され、あるいは仮想マシンを構成することが望ましい。
本発明の第２の特質のコンピュータ・システムは、本発明の第１の特質の特徴をも含むことが望ましい。

本発明の第２の特質は、コンピュータ・システムを動作させる方法をも提供することが望ましく、該方法は、最初の割込みに先立って割込み処理方法を開始することを含み、この方法の実行は待機へ進み、割込みが生じるときに再開する。
本発明の第２の特質は、コンピュータ・システムにおける割込みを処理する方法をも提供し、当該方法においては、割込み処理方法が待機状態において動作の半ばで終了させられてスタックを残す。この割込みハンドラ方法のスレッドは、望ましくは割込みが生じるときスタックを用いて制御の割込みフローを行うことにより明らかに再活動化されることが望ましい。本発明の望ましい実施の形態においては、割込みハンドラ方法が非ネイティブな割込み方法であり、望ましくはジャバ割込み方法である。
本発明は、その最も一般的な特質の１つにおいて、非ネイティブな（望ましくは、ジャバの）スレッド・スタックが準備完了状態に保持されて割込みが検出されるとき切換えられるのを待機するコンピュータ・システムまたはコンピュータ・システムを動作させる方法を含む。
割込みハンドラに対して用いられる翻訳言語の場合は、割込みが生じたときに割込みハンドラ方法が呼出されるならば、当該方法に入るとき大きなオーバーヘッドが生じることになる。
本発明は、その望ましい形態において、ソフトウエアＶＭの関連において存在し、本発明の重要な特徴は、システムまたは方法が非ネイティブな（望ましくは、ジャバの）バイト・コードを割込みレベルで走らせることである。
要約すると、問題が実際の割込みレベルが非ネイティブなバイト・コード実行エンジンによる使用に適さない小さな個々のＯＳによるスタックで走ることであることが判った。本発明の実施の形態は、正常な非ネイティブなスレッドのスタックが準備完了状態であり、割込みが生じるとき切換えられるのを待機している。
本発明は、第２の特質において、仮想マシンとして構成されたコンピュータ・システムにおけるデバイス・ドライバを実現する方法を提供し、当該方法は割込み呼出しが受取られる瞬間に走る容易ができた特殊な割込みスタックを備えることを含んでいる。

前項に述べたような本発明の望ましい実施の形態において、当該システムは、翻訳言語（例えば、ジャバ・コード）を走らせる用意ができている。１つの修正においては、前記の特殊な割込みスレッド・スタックは、割込みが生じるとき切換えられる通常の（ジャバ）スレッド・スタックである。
本発明はまた、デバイス・ドライバの割込みを実現する手段が設けられたコンピュータ・システムに拡張し、割込み呼出しが受取られる瞬間に走る用意のある特殊な割込みスタックを含む。
前項に述べたような本発明の望ましい形態においては、システムは、翻訳言語（例えば、ジャバ・コード）を走らせる用意がある。１つの修正においては、この特殊な割込みスレッド・スタックは、割込みが生じるときに切換えられる通常の（ジャバ）スレッド・スタックである。
当該システムは、割込みハンドラ方法が実行される間は潜在的にブロックする同期動作が行われないようなものであることが望ましい。
割込み処理中に潜在的にブロックする同期動作が行われないことが重要である。
本発明の第３の特質によれば、非ネイティブな割込みハンドラを有する割込みハンドラを含むコンピュータ・システムが提供され、当該システムは最初の割込みに先立って最初の実行アクティビティを実施する手段を含んでいる。
多くの場合、最初の実行アクティビティは、避けられないセマフォー（例えば、クラスのローディングにおいて用いられるもの）を含んでいる。割込みが生じる前に（例えば、システムの初期設定時に）このようなアクティビティを実施することにより、このようなセマフォーの使用を回避することができる。
割込みハンドラのコードは予め解かれている。このため、ミューテックス、例えばクラスの分解を不可避的に呼出すステップは、割込みレベルの処理が生じる前に実施することができる。割込みハンドラのコードは予めコンパイルされることが望ましい。
コンピュータ・システムは、仮想マシンとして構成されあるいは仮想マシンを実現することが望ましい。
本発明の第３の特質のコンピュータ・システムは、第１の特質および（または）第２の特質の特徴をも含むことが望ましい。
割込みを処理する方法が、割込み処理方法を実行している間は、潜在的にブロックする同期動作を行わないことを含むことが望ましい。
本発明の第３の特質によれば、非ネイティブな割込みハンドラ方法を用いてコンピュータ・システムにおける割込みを処理する方法が提供され、当該方法は最初の割込みに先立って最初の実行アクティビティを実施することを含む。
当該方法は、割込みハンドラ方法のコードを予め解くステップを含むことが望ましく、また割込みハンドラ方法のコードを予めコンパイルするステップを含むことが望ましい。

要約すると、バイト・コード実行エンジンは、割込みハンドラのバイト・コードを実行中は、潜在的にブロックする同期動作を試みてはならない。
本発明の第３の特質によれば、バイト・コード実行エンジンを介する通常のルートが潜在的にブロックする同期動作を持たないことが保証でき、このことはどんな性能の観点からも望ましい！更に、割込みハンドラのバイト・コードの性質が決してバイト・コード実行エンジンを介する通常ルート以外を要求しないことを保証することが望ましい。
本発明の第２の特質は、仮想マシンとして構成されあるいは仮想マシンを実現するコンピュータ・システムにおけるデバイス・ドライバ割込みを実現する方法をも提供し、当該方法は、前記割込みハンドラのバイト・コードを実行する間は、バイト・コード実行エンジンが潜在的にブロックする同期動作を試みることを阻止することを含む。
本発明の第２の特質は更に、デバイス・ドライバ割込みを実現する手段が設けられたコンピュータ・システムに拡張し、前記割込みハンドラのバイト・コードを実行する間は、バイト・コード実行エンジンが潜在的にブロックする同期動作を試みることを阻止する手段を含む。
本発明の第４の特質によれば、割込みハンドラとガーベッジ・コレクタとを含むコンピュータ・システムが提供され、該システムは割込みハンドラとガーベッジ・コレクタとの間の相互動作が阻止されるようなものである。
本発明の第４の特質は、特に不要部分の整理システムを備える非ネイティブなソフトウエアに適用する。
割込みレベルが例えばオブジェクトをガーベッジ・コレクタ（ＧＣ）がアクセスするヒープへ入れるならば、ＧＣは、例えば、オブジェクトのＧＣを試みるかあるいは単にオブジェクトを調べるだけによりオブジェクトを変えることもできる。
割込みハンドラはオブジェクトを含み、この割込みハンドラのオブジェクトがガーベッジ・コレクタから切離されることが望ましい。割込みハンドラはヒープを含み、このヒープがガーベッジ・コレクタから切離されることが望ましい。このように、ＧＣは、割込みハンドラに帰属するオブジェクトを変更あるいは収集することができない。
当該システムは更に、割込みハンドラによる以外に割込みハンドラのオブジェクトにおける参照フィールドの変更を阻止する手段を含むことが望ましい。このため、割込みハンドラは、非割込みレベルのスレッドによる干渉からも保護され得る。割込みレベルは、非割込みレベルのオブジェクトを直接変更しあるいはこれと接触することができないことが望ましい。このように、割込みレベルは非割込みレベルから完全に切離されることが望ましい。
コンピュータ・システムは、仮想マシンとして構成され、あるいは仮想マシンを実現することが望ましい。

本発明の第４の特質のコンピュータ・システムは、本発明の第１、第２、および（または）第３の特質のコンピュータ・システムの特徴をも含むことが望ましい。
本発明の第４の特質は、割込みハンドラとガーベッジ・コレクタとを含むコンピュータ・システムを動作させる方法をも提供し、該割込みハンドラとガーベッジ・コレクタとの間の相互動作が阻止される。
当該割込みハンドラ装置はオブジェクトを含むことが望ましく、割込みハンドラによる以外の割込みハンドラのオブジェクトにおける参照フィールドの変更が阻止される。
要約すると、バイト・コード実行エンジンは，非割込みレベルにおいて（おそらくは同時に）生じる不要部分の整理のいずれかの不要部分の整理相と干渉し得あるいはそのゆえに障害を生じ得るなにものも行ってはならない。このことは、割込みレベル・コードの不要部分が整理されたジャバ・ヒープの完全な柔軟性を否定することにより、望ましい実施の形態において達成することができる。
本発明は更に、仮想マシンとして構成されあるいは仮想マシンを実現するコンピュータ・システムにおけるデバイス・ドライバの割込みを実現する方法を提供し、当該方法は、バイト・コード実行エンジンが非割込みレベルにおける同時の不要部分の整理と干渉することを阻止することを含む。
本発明は更にまた、デバイス・ドライバの割込みを実現する手段が設けられたコンピュータ・システムに拡張し、バイト・コード実行エンジンが非割込みレベルにおける同時の不要部分の整理と干渉することを阻止する手段を含んでいる。
本発明の第５の特質は、仮想マシンとして構成されあるいは仮想マシンを実現するコンピュータ・システムを提供し、該システムは割込みレベルにおける非ネイティブな割込みハンドラを含み、該システムは割込みレベルからの情報が他のレベルへ移ることを可能にする手段を含んでいる。割込みレベルと非割込みレベルとの通信は必要であるが、割込みの処理における潜在的な干渉を避けるためには、割込みレベルが非割込みレベルへある情報を移すために特殊な手法を用いることが必要である。
当該システムは、割込みレベルから他のレベルへ情報を送るためネイティブな呼出しを用いる手段を含むことが望ましい。このように、情報は、割込みの処理中の擾乱のリスクを最小限に抑えながら、非割込みレベルへ送ることができる。
第５の特質のコンピュータ・システムは、第１、第２、第３、および（または）第４の特質のコンピュータ・システムの特徴を含むことが望ましい。
本発明の第５の特質は、割込みレベルにおける非ネイティブな割込みハンドラを含む仮想マシンとして構成されあるいは仮想マシンを実現するコンピュータ・システムを動作させる方法をも提供し、該方法は割込みレベルから他のレベルへ情報を移すことを含んでいる。
要約すると、第３および第４の特質の本発明は、割込みレベルのジャバと非割込みレベルのジャバとの間の通信は不可能ではないが難しいことを示すように見える。本発明の望ましい実施の形態においては、ジャバのアプリケーション・プログラマが情報を割込みレベルで走るジャバ・コードから他のアプリケーションへ移すことを可能にするため、特殊な機構が利用可能にされる。
これらの小さな問題が試みられ克服された方法については、特定の記述の後の項で説明される。

本発明は更に、仮想マシンとして構成されあるいは仮想マシンを実現するコンピュータ・システムにおけるデバイス・ドライバ割込みを実現する方法を提供し、該方法は、割込みレベルで走る（ジャバ）コードからの情報が残りのアプリケーションへ移ることを可能にすることを含んでいる。
本発明は、割込みハンドラのコードが干渉することなく不要部分の整理プロセスの任意の点において良好に走ることを可能にするという利点を有する。
本発明は更にまた、デバイス・ドライバの割込みを実現する手段が設けられたコンピュータ・システムに拡張し、割込みレベルで走る（ジャバ）コードからの情報が残りのアプリケーションへ移ることを可能にする手段を含んでいる。
本発明は、割込みハンドラのコードが干渉することなく不要部分の整理プロセスにおける任意の点で良好に走ることを可能にするという利点を有する。
本発明はまた、本発明の上記特質のいずれかに従って方法を実施するようプログラムされたコンピュータを提供する。
本発明はまた、本発明の第１、第２、第３、第４、および（または）第５の特質の方法を実施するプログラムが記録されたコンピュータ読取り可能な記憶媒体を提供する。

本発明の実施の形態については、入水に事例として次に記述する。適切な場合に、（上記の改善を略図的に示す）添付図面を参照する。
背景として、図８Ａに示されるＰＣ形態のコンピュータ・システムにおいては、ＣＰＵ１８１０２およびその関連するＲＡＭ１８１０４が、プログラム割込みコントローラすなわちＰＩＣ回路として知られる（通常は）２つの回路ブロック１８１０６、１８１０８の第１のブロック１８１０６に電気的に接続されている。各ＰＩＣは、電気的接続が行われる合計８つの端子すなわちピンを有する。これまでは、第１のＰＩＣ１８１０６の第２のピンが第２のＰＩＣ１８１０８の入力に接続されている。ＰＩＣ１８１０６の残りの７ピンにＰＩＣ１８１０８の８ピンを加えたもの、すなわち全てで１５ピンが、先に述べたような更に他の装置における電気的接続のため利用可能である。
装置が接続されるピン数は、そのアイデンティティとなり、むしろそのＩＲＱ番号となる。従って、第５のピンに接続されたキーボードは、ＩＲＱ＝５ラベルを持つことになる。ＣＰＵが（例えば）ピン５で信号を受取るとき、リストにおける対応コード・アドレスを活動状態にできるように、ＣＰＵは、１５の割込みレベルのコード・アドレスのリスト１８１１０と通信する。
ＰＩＣ信号をＣＰＵに接続する線における電圧を上げることにより、ＰＩＣがＣＰＵに対して信号する。ある場合には、各文字が対応する装置へ送られた後に、このような信号がＣＰＵへ送られる。ＣＰＵが、例えばドキュメント全体またはテキストのページの印刷ではなく、その時のジョブ、すなわちＣＰＵが作業しているマシン命令をいったん終了すると、ＣＰＵは割込み信号に応答して、例えば装置へ送られる次の文字に対して適切な動作を行うため対応する装置のアドレスを活動状態にする。
従って、ＣＰＵからのアテンションの要求を割込み数が非常に大きくなり得ること、およびこれらを管理する良い方法が前記ＣＰＵを含むＰＣの有効な動作のために不可欠であることが容易に理解できる。ある事例においては、高い優先順位を持つジョブの部分が割込みによる干渉から保護されることが必要である。このような場合は、処理されるコードの部分は、コードのこの部分の終りの「割込みセット」すなわちＳＴＩコードに達するまで割込みが確認されることを阻止する「割込みクリヤ」すなわちＣＬＩ命令により先行される。このような保護を強化するために、ＣＰＵは、割込みがＣＰＵにすでに生じるプロセスと干渉するかも知れないリスクを更に減じるように、物理的に別の割込みスタックへ切換わる。
ＣＰＵとＰＣにおける（例えば）ＣＯＭポートを介して接続される装置との間の通信が一般にプロセッサ速度と比較して中程度の速度で生じることを念頭に置くと、通信は遅い。ＣＰＵが装置に対して主幹線呼出しを行うとき、ＣＰＵはこれを装置へ書込み、呼出しの最初の文字をとってこれをＣＯＭポートのハードウエアへ書込む。次に、ＣＰＵはこれが行っていたジョブ、例えばワード・プロセッシング・パッケージにおけるドキュメントを再取得するジョブへ戻る。
割込みが受取られてＣＰＵがどの装置が割込みを行ったかおよびＣＰＵが応答して行うべきことを確定すると、ＣＰＵはその時のプロセスから離れて割込みを処理させるのに充分なデータを記憶する。記憶されたリストは、ＣＰＵが例えば「割込みコードがいつ到達するとき、Ｘへ行く」ことを可能にするスタート・アドレスを含む。但し、「Ｘ」は割込みに対する適切な応答を表わす。明らかに、割込みハンドラは、割込みが到達したとき、ＣＰＵの状態を知らず、従ってハンドラを処理データから分ける先に述べた必要を知らない。
割込みリターン（ＩＲＥＴ）・コードは、割込みが完了したこと、およびＣＰＵが割込み前に動作していたプロセスへの戻りを行うことをＣＰＵへ知らせるため割込みの終りに置かれる。

仮想マシンは、１つのオペレーティング・システムに対して書込まれたソフトウエアが別のオペレーティング・システムで走ることを許容し、従ってこのソフトウエアは「非ネイティブな」ソフトウエアと呼ばれる。非ネイティブなソフトウエアを走らせるためには、仮想マシンはソフトウエアが書込まれたオペレーティング・システムの動作をエミュレートする。仮想マシンは、非ネイティブ・ソフトウエアの命令をホスト・オペレーティング・システムにより走らせることができるネイティブな命令へ翻訳する。従来のエミュレータは、実行中に非ネイティブな命令を翻訳することにより働く。
どの実行パス、すなわち「スレッド」は、これと関連するスタックを有する。スタックは、一時的なレジスタ情報とサブルーチンのリターン・アドレスとからなるフレームを格納する記憶域である。
これまで、デバイス・ドライバが書かれる言語について特に付言しなかった。望ましい実施の形態では、これらのドライバはジャバにおけるものであり、本項の残りはそれだけではないが、特にジャバまたは他の翻訳言語におけるデバイス・ドライバの実現により生じる問題の解決に関するものである。
先に述べた問題がどのように解決されたかについての詳細は、下記のとおりである。
公知の堤案では、実際の割込みレベルは、ジャバのバイト・コード実行エンジンによる使用には適さない小さな別個のＯＳで提供されるスタックにおいて走る。本発明の望ましい実施の形態は、通常のジャバ・スレッドのスタックが準備完了の状態で割込みが生じるときに切換えられるのを待機しており、これは、特殊なネイティブな方法、ｗａｉｔＦｏｒＦｉｒｓｔＩｎｔｅｒｒｕｐｔにおける呼出しによりジャバ・アプリケーション・スタートアップ・コードの一部として生成された通常のジャバ・スレッドを部分的に自らを部分的に破壊したことによって達成される。

要約すると、割込みハンドラ方法を下記のように全体的に表わすことができる。すなわち、

第２の線ｗｈｉｌｅ（ｔｒｕｅ）は無限ループを実行する。「ｗａｉｔＦｏｒＦｉｒｓｔＩｎｔｅｒｒｕｐｔ」の上流側は、別のスタックを持つ実際のジャバ・スレッドおよび実際のオペレーティング・システム（ＯＳ）スレッドである。割込みハンドラ・ジャバ・スレッドおよびその関連するスタックは、システムの初期設定において形成される。当該方法は、割込みが生じるまでｗａｉｔＦｏｒＦｉｒｓｔＩｎｔｅｒｒｕｐｔを待機し、ＯＳに関する限り、スレッドが終了されるがスタック自体が存続する。このスタックは、有効に準備完了状態にあり、割込みが生じるとただちに動作することを待機する。最初の割込みが生じると、制御の割込みフローは終了されたスレッドのスタックを用いて割込みを提供する。割込みが処理された後、割込みハンドラ方法が再び休止状態になり、この時別の割込みが生じるまでｗａｉｔＦｏｒＦｉｒｓｔＩｎｔｅｒｒｕｐｔにある。
イベントのシーケンスおよび対応する擬似コードの更に完全な説明が、図８Ｂおよび図８Ｃに関してそれぞれ与えられる。
図８Ｂは割込みの処理において呼出された種々のシステム構成要素に対するイベントシーケンスを示し、図８Ｃは、興味のある事例とするために２つの動作モード、すなわち同期および非同期のモードを持つものと見なされる仮想的な装置のデバイス・ドライバからのジャバ割込みハンドラの対応する擬似コードの概要である。
初めに、パワーアップ時に、主デバイス・ドライバのスレッドが新たな割込みハンドラ・スレッド（図のＦ１８／０２）を要求して登録する。これに応答して、具現された仮想マシン（ＥＶＭ）割込みハンドラのエントリ点が、ＥＶＭのネイティブ・コードを介してリアルタイム・オペレーティング・システム（ＲＴＯＳ）割込処理サービスで登録される。次に新たなスレッドが始動され、擬似コードにおける行「ｗａｉｔＦｏｒＦｉｒｓｔＩｎｔｅｒｒｕｐｔ」（図８Ｃ）に達する点まで走る。むしろ、スタックは関連する割込みと関連させられ、ＲＴＯＳスレッドのない状態「ｌｉｍｂｏ」へ進み、ジャバのスレッドが方法の途中で終了される位置から後で活動状態にされるのを待機する。
ある時間後に、主デバイス・ドライバのスレッドが、後で割込みを生じさせ、本発明を具現するネイティブ・コードを呼出すためＲＴＯＳへ信号を生じる装置（図８Ｂでは、ハードウエア列に示される）へ入出力（Ｉ／Ｏ）命令を発する。次に、ＥＶＭネイティブ・コードが休止状態のジャバ・スタックへ切換わって戻りを生じる。ここから、ジャバ命令ハンドラ・コードが走り続けるが、このコードはあたかも元のスレッド内で続いていたかのように外からは見える。割込みがいったん処理されると、割込みハンドラ方法は、ｗａｉｔＦｏｒＩｎｔｅｒｒｕｐｔにおいてなされた呼出しで終了し、制御は再びＲＴＯＳスタックへ切換わって戻る。ＲＴＯＳがハードウエア割込み（ＩＲＥＴ）を終え、割込みが終了される。ループは図８Ｂの主デバイス・ドライバ・スレッド列における「Ｉ／Ｏの発行」ブロックの初頭へ戻り、装置に対する新たな命令が開始されるときこのシーケンスを再び始める。このループは、図８Ｂの主デバイス・ドライバ・スレッドにおけるフィードバック「ｌｏｐ ｆｏｒｅｖｅｒ」により無限となる。
割込みハンドラのジャバ方法がすでに「アクティブ」でありかつ割込みが生じると直ちに実行する用意があるので、より速い実行が可能である。

図８Ｃに示された擬似コードは、先に述べたように、図８Ｂの時間線に示されたイベントのシーケンスが判りさえすれば、全く自明である。しかし、図８Ｃが同期および非同期のモードに対する特定の規定を行うものであることが判るであろう。しかし、これは、モードを示すルーチン・コードがないため、割込みが生じるごとにシステムがどのモードが動作しているか確定しなければならないという結果を生じる。
多くの呼出しサイトが存在する場合に図８Ｃにおけるようなコードの使用によって、ハンドラが関連する点において割込みハンドラ方法のコードへ入りこみ得、かつ次に呼出しが生じるとき、このハンドラが別の場所に入りこみ得る。このことは、方法が開かれる用意ができておらず割込みが生じるとき呼出しが存在するときに開かれる代替的な実施の形態と対照されるべきである。このような方法は比較的遅いばかりでなく、実行がつねにコードの頭で開始するので、このような特徴はあり得ない。同期／非同期の質問の処理のためには、異なるループを用いられ得る。
図の１８／０３の事例においては、装置は２つの特殊な状態、すなわち非同期と同期の状態を有する。例えば、プロッタ装置は、絶対的と相対的の２つのモードを有し、各モードにより要求される割込みの異なる処理を有する。
方法「ｗａｉｔＦｏｒＦｉｒｓｔＩｎｔｅｒｒｕｐｔ」は、望ましい実施の形態のジャバ・ＶＭの割込み処理機構の重要な特徴である。これは、スタックとは別に（このスタックは、ジャバ・アプリケーションにおけるｗａｉｔＦｏｒＦｉｒｓｔＩｎｔｅｒｒｕｐｔに対する特定の呼出しが行われた場所のみに関する情報を含んでいる）、任意のＯ／Ｓと関連するスレッドを（可能な場合に）破壊し、このスタックの場所は、特定の装置または割込みに関して後で使用されるインシニア・ジャバ・ＶＭの割込み処理機構が登録される。
要約すると、最初の割込みが関連する装置から受取られると、オペレーティング・システムがインシニア・ジャバ・ＶＭの割込み処理機構の割込みハンドラに入り、−これがスタックを先に予約されていた関連するジャバ・スタックへ切換え、次いでネイティブな方法戻しシーケンスを実行することになり、このシーケンスはつねに、（スタックに記録された如き）ネイティブな方法に続く場所でジャバ実行エンジンを再開する。
この時、バイト・コード実行エンジンがＯ／Ｓ割込みレベルでジャバ・バイト・コードを実行しており、このことが、ブロックするスレッド同期動作は試みないようなバイト・コードを実行している間、種々の制約をバイト・コード実行エンジンに課し、非割込みレベルで（おそらくは、同時に）生じるどのような不要部分の整理の段階のゆえに干渉しあるいは障害を生じ得ることは何も行わず、これらの小さな問題は後で述べる。

この時、このような解決法がどこかに述べたダイナミック（あるいはオフラインの事前）コンパイル手法と完全に互換であることは注意に値する。参照されるバイト・コードが高速実行のためマシン・コードへコンパイルされることは全くあり得ることで、バイト・コード単位の翻訳のためのインタプリタが存在するかあるいはこれを選択するならば、ネイティブな方法戻し機構がマシン・コード・バージョンを選定することになる。
割込みハンドラのジャバ・コードが、ｉ）装置の特定仕様および生じた割込みタイプに適するものとしてインシニア・ハードウエア・アクセス・ジャバ・パッケージの一部として提供されるネイティブな方法を用いる装置と相互動作したとき、およびii）適切なものとしてインシニア割込み処理パッケージにおけるネイティブな方法の使用により装置（すなわち、アプリケーションの非割込み部分）と関与したジャバ・アプリケーションの残部と相互動作したとき、このハンドラは通常の非割込みコードの実行が継続することを許容しなければならない。これは、別の特殊なネイティブな方法「ｗａｉｔＦｏｒＩｎｔｅｒｒｕｐｔ」（前述の「ｗａｉｔＦｏｒＦｉｒｓｔＩｎｔｅｒｒｕｐｔ」とは対照的に）の呼出しによって達成される。
このネイティブな方法「ｗａｉｔＦｏｒＩｎｔｅｒｒｕｐｔ」は、別の割込みによりジャバ・スタックを以降の活性化のため準備完了状態にし、次いでＯ／Ｓの小さな専用割込みスタックへ再び切換わり、次に特定のＯ／Ｓに適する戻りを行い、割込みのない実行へ戻るのに必要な動作を行わせる。
ジャバにおける割込みハンドラの使用の結果として生じる個々の問題については、次に更に詳細に論述する。
第一に、先に述べたように、バイト・コード実行エンジンは、割込みハンドラのバイト・コードを実行中に任意の潜在的にブロックする同期動作を試みてはならない。
スレッドを同期させるためセマフォーが用いられる。例えば、多重スレッド環境における下記の状況を考察しよう。非割込みスレッドが、セマフォーを取得した動作を開始する。この非割込みスレッドは、割込みが呼出されるとき動作途上である。制御が割込みスレッドへ切換わる。割込みがつねに優先順位で取扱われるので、制御はその後、割込みが処理されるまで割込みスレッドから切換わることがない。
割込みハンドラが非割込みスレッドにより実施されている動作を実施する必要がある場合は、非割込みスレッドがセマフォーを解放するまで割込みスレッドが動作に入ることができず、また割込みが処理されるまでは割込みスレッドが走ることができないため、問題が生じる。
このように、割込み方法が実行中である間はブロッキング呼出しが避けられねばならないことが判る。
従って、バイト・コード実行エンジンを介する通常のルートが潜在的にブロックする同期動作を持たないこと─このことは性能の観点から望ましい─を保証することが重要である。更に、割込みハンドラのバイト・コードの性質がバイト・コード実行エンジンを介する通常のルート以外を決して要求しないことを確認しよう。このため、割込みレベルで使用できる全てのパスを知り、ブロッキング呼出しがないことを確認する。特定の方法に対するネイティブな呼出し（以下参照）もまた、非割込みレベルと通信するときブロッキング呼出しがないことの要求の問題を克服するために用いることができる。
（更に一般的な翻訳言語とは対照的に）ジャバの場合は、このような後者の点は、一定のプール・エントリが予め解決されねばならないことを意味する（一定のプール解決法は、最初に特定のバイト・コードが実行されるときに通常生じるプロセスであり、多くの潜在的にブロックする同期動作およびＩ／Ｏ動作を結果として生じ得るプロセスである）。

実質的に、ヒープ、ミューテックス、あるいは同期動作のいずれも安全に使用することができない。ジャバは、同期を使用する２つの方法を持ち、すなわち、（１）同期したキーワードを用いること、あるいは（２）それ自体が同期されるものと宣言される方法を用いることによる。ブロッキング呼出しがないことを確認する負担は、ジャバ・コードの作者にかかる。例えば、コンパイラがソース・ファイルをジャバ拡張版（すなわち、 ジャバ）を用いてコンパイルするとき、これがクラスを作成する。これらのクラスにおける参照がランタイムにおいて従われ、２回目および以降の遭遇時にプロセスを反復する必要がないように関連情報が取得される、などである。その結果、先に述べたように、割込みジャバ・バイト・コードが予め解明されねばならない。
望ましい実施の形態においては、割込みハンドラのジャバ・バイト・コードは、予めコンパイルされる（ダイナミック・コンパイル・システムが当然のこととして何らかの潜在的にブロッキングする同期動作を行うためインタプリタを必要としなければ、これは厳密には必要でないが）。
ブロッキング呼出しが初めから使用される２つのタイプの状況が生じる。
制御のフローが通常の実行パスに従う安定状態の場合は、割込みハンドラにより遭遇され取得され得るセマフォーを含まないようにコードが書かれる必要がある。このため、このような通常の制御パスの場合は、ブロッキング呼出しが使用されてはならない。
特殊な状況は、コードが最初に遭遇され実行される場合を含む。このような場合では、セマフォーを要求する動作、例えばクラスのローディングが必要とされる。このような動作では、セマフォーが不可欠である。このため、セマフォーが割込みレベルで使用できないので、最初の割込みに遭遇する前に必要な全てのクラスがすでにロードされているように、このようなコードが予め分解される。
このような事前分解は、非ネイティブな割込みハンドラ・コードのコードの事前コンパイルを含む。事前分解は、始動時に行われるか、あるいはシステムの構築中に行われる。
第二に、バイト・コード実行エンジンは、非割込みレベルで（おそらくは、同時に）生じる不要部分の整理相のゆえに干渉しあるいは障害を生じ得る割込みレベルでは何もしてはならない。望ましい実施の形態においては、これは、割込みレベル・コードの不要部分が整理されたジャバ・ヒープの完全な柔軟性を否定することによって、下記のように基本的に達成される。すなわち、
割込みハンドラを含む特別なジャバ・スレッドは、（特殊なネイティブな方法、ｗａｉｔＦｏｒＦｉｒｓｔＩｎｔｅｒｒｕｐｔをクロックす前に）その始動相の一部としてオブジェクトを割付けることが許容され、これらオブジェクトはシステムの全寿命だけ保つ（これらは決してガーベッジとして廃棄されない）。ジャバ・スレッドが正規であることを止める（先に述べたように、割込みレベルで使用されるまさにスタックとなる）とき、このようなヒープ・オブジェクトの組は、割込みレベルのジャバ・コードが見ることができるヒープ・オブジェクトのみの組となり、このように、当該オブジェクトの組は不要部分の整理アクティビティとは独立するジャバ・ヒープにおける固定された存在であり、このように、割込みレベル・コードがそれ自体のオブジェクトの組のみを処理するゆえに、非割込みレベルで走るガーベッジ・コレクタが割込みレベルのジャバ・コードが決してその動作と干渉し得ない（あるいは、その逆）という確信において存続し得る。

非割込みジャバ・コードが割込みジャバ・オブジェクトに対する参照を知ることが許される。割込みジャバ・コードが見える割込みオブジェクトに対する非割込みジャバ・オブジェクトへの参照を格納する機会としてこれを使用してはならないという厳密なタイミングがある。割込みジャバ・コードは、非割込みジャバ・オブジェクトに対する参照を知ることは許されない。
このようなポリシーが犯されないことを保証するため、ＶＭの開発時に取締まり機構を組込むことができる。例えば、非割込みレベルのジャバが何かを割込みレベルのジャバ・オブジェクトに格納することを阻止する機構を組込むことができる。
先に示したように、ＧＣを割込みレベルから分離することが重要である。割込みが終ると、ＧＣはシステムのどこか別の場所にあり得る。例えば、ＧＣがセマフォーを取得したならば、このことが先に述べたように割込みレベルにおける問題をもたらすことがある。
更に、割込みハンドラが非割込みオブジェクトを変更することができるものとすれば、ハンドラがＧＣにより削除のためすでにマークされたオブジェクトに何かを書込むかも知れず、あるいはＧＣシステムを混乱させることになるオブジェクトを変更するかも知れない。
このように、割込みレベルのオブジェクトの割付けは、メモリの別の部分からなされ、これらはＧＣからは切離されている。
更に、割込みハンドラは、非割込みオブジェクトを変更しようと試みることができないようにこれらオブジェクトを知ることができない。このことは、例えば、割込みが生じたときＧＣが移動の途中であったオブジェクトを割込みハンドラが変更しようとしたならば、問題を生じるおそれがある。
第三に、最後の２つの問題の解決は、割込みレベルのジャバと非割込みレベルのジャバとの間の通信が不可能でなくとも難しいことを示すように思われる。本発明の望ましい実施の形態においては、ジャバ・アプリケーション・プログラマが割込みレベルで走るジャバ・コードからアプリケーションの残部へ情報を移すこと可能にするため、特殊な機構が利用可能にされる。
ブロッキング呼出および新たなオブジェクトを作ることがともにできるだけ避けるべきであるから、割込みレベルのジャバ・コードはどのようにアプリケーションの残部と通信するのだろうか？
通常は「ｗａｉｔ」および「ｎｏｔｉｆｙ」が用いられるが、本文のコンテキストではジャバ・オブジェクトにおける同期を必要とすることになろう。しかし、（例えば、オブジェクト０＝新たなオブジェクト（０）であり、コードが待機および通知に対して同期される（０）場合における）同期が割込みには許されないことを前に述べた。従って、ジャバ・方法における呼出しのように見えるがＣ言語またはアセンブラ言語で書かれる独自のネイティブな方法を提供する。
ネイティブな方法は、情報を割込みレベルから非割込みレベルへ移すことを許し、これが非割込みコードを実際のネイティブ方法における呼出し中に中断させ、割込みが完了して関連する書込み方法（図８ＣにおけるＳｐｅｃｉａｌＣｈａｎｎｅｌ．ｗｒｉｔｅ）における呼出しを行ったとき働くことを許す割込みパッケージの一部として提供される。

このＳｐｅｃｉａｌＣｈａｎｎｅｌ．ｗｒｉｔｅは、ＳｐｅｃｉａｌＣｈａｎｎｅｌ．ｗｒｉｔｅのネイティブ・方法の仮想的な呼出しである。このため、Ｃのオペレーティング・システムの場合は、Ｃのファンクションが書込み方法を実行するため呼出される。次に、Ｃのネイティブ方法が、メッセージを対応する「実際の」ネイティブ方法へ非割込みレベルで送出する。非割込み割込み方法は、中断されて「読出し」を待機する。このように、割込みレベルは、ブロッキング呼出しが要求されることなく、非ネイティブ・コードの非割込みレベルと通信することができる。
図８Ｄは、本発明の実施の形態を実施するための装置を示している。この装置は、ハードウエア１８０００（割込みを生じる）と、リアルタイム・オペレーティング・システム１８００２と、関連するＥＶＭネイティブ・コード装置１８００４とを含む。装置は更に、ハードウエア１８０００に対してＩ／Ｏを発行することができるジャバの主デバイス・ドライバ１８００６を含む。ＥＶＭのネイティブ・コード装置１８００４は、ジャバ割込みハンドラ１８００８に接続される。装置のこれら構成要素の相互動作については、図８Ｂに関して記述する。
当該装置はまた、ガーベッジ・コレクタ１８０１０を含んでいる。ガーベッジ・コレクタ１８０１０がジャバの主デバイス・ドライバ１８００６と別のジャバ・スレッド１８０１２とにアクセスするが、ガーベッジ・コレクタ１８０１０から隔離されるオブジェクト１８０１６とヒープ１８０１４とを含むジャバ割込みハンドラ１８００８にはアクセスしないことが判る。割込みハンドラ１８００８はまた、スタック１８０１８も含んでいる。ネイティブな呼出しは、割込みハンドラからＯＳ（１８００４、１８００２）から非割込みレベル１８００６、１８０１２へ行うことができる。
上記のいずれかあるいは全てにおいて、本発明の幾つかの特徴がコンピュータ・ソフトウエアを用いて実現された。しかし、無論当業者には、これらの特徴のいずれもハードウエアまたはハードウエアとソフトウエアの組合わせを用いて実現できることが明らかであろう。更に、ハードウエア、コンピュータ・ソフトウエアなどにより行われるファンクションが電気信号などを用いて行われることが容易に理解されよう。
情報の記憶に関する特徴は、適切な記憶場所またはストアにより実現されよう。情報の処理に関する特徴は、適切なプロセッサまたは制御手段によってソフトウエアまたはハードウエアにおいて、あるいは両者の組合わせにおいて実現されよう。

上記のいずれかあるいは全てにおいて、本発明は、下記の形態のいずれか、あるいは一部、あるいはその全てにおいて具現され、コンピュータ・システムを動作させる方法において具現され、コンピュータ・システム自体において具現され、コンピュータ・システムを動作させる方法を実行するようプログラムされあるいは構成されるときコンピュータ・システムにおいて具現され、および（または）コンピュータ・システムを動作させる方法に従って動作するためのプログラムが記録されたコンピュータ読取り可能な記憶媒体において具現されよう。
本文に用いられるように、用語「コンピュータ・システム」は、「コンピュータ」、「システム」、「装備」、「装置」、「マシン」などと互換である。コンピュータ・システムは、仮想マシンであり得、あるいは仮想マシンを含み得る。
上記のいずれかあるいは全てにおいて、方法および装置の特徴および特質を含む先に述べた異なる特徴および特質は、任意の適切な方法で組合わせることができる。
本発明が、純粋に事例として記述され、細部の修正が本発明の範囲ないで可能であることが理解されよう。
本文の記述、および（適切な場合に）請求の範囲および図面において開示された各特徴は、独立的に、あるいは適切な組合わせにおいて提供されよう。

エージェント資料第９−コンピュータ・システム、コンピュータ読取り可能な記憶媒体および同媒体を動作させる方法、および前記システムを動作させる方法
本発明は、コンピュータ・システムに関し、コンピュータ・システムを動作させる方法に関する。特に、本発明は望ましくは、コンピュータ・システムに関し、オブジェクト指向プログラムを含むコンピュータ・システムを動作させる方法に関する。望ましい実施の形態においては、本発明は、ファイナルでないインスタンス方法の直接的な呼出しを可能にするクラス・ローダの使用に関する。

本発明は望ましくは、問題となるオブジェクトのクラスが仮想マシンにより動的にロードおよび（または）発見されるオブジェクト指向（ＯＯ）プログラムを実行する仮想マシン（ＶＭ）に関する。本発明は特に、例えば仮想マシンを動的にコンパイルする際にクラスの潜在的にポリモルフィック（ｐｏｌｙｍｏｒｐｈｉｃ）な方法がポリモルフィックでないと安全に仮定することができる、一部の最適化が実施可能である仮想マシンに適用する。
本発明は、方法の継承（ｉｎｈｅｒｉｔａｎｃｅ）に関し、「方法」は、既に述べたように、例えば円の「面積」のようなファンクション、および「再生」、「点灯」などのような他の任意のファンクションに対するジャバその他のプログラミング言語における用語である。
ファイナルでないインスタンス「方法」の直接的な呼出しを許容するクラス・ローダの使用に関する本願の部分において、「方法」（大文字「Ｍ」を付す）は、プログラミング言語の方法に関して用いられ（また、「ファンクション」および「ルーチン」を含む他の用語によっても、これに限定されないが知られる）、用語「方法」（小文字「ｍ」を付す）は、（前後関係から他の意味が明らかである場合を除き）本発明を実施する手順に関して用いられる。
従来のシステムおよび方法（Ｍ）において、所与のネームの方法（Ｍ）に対する呼出しは、方法（Ｍ）と名付けられた多くの異なる構成の１つを１つのオブジェクトが関心を持たれるもの（例えば、ビデオ・レコーダ、テープ・レコーダなどにおける「再生」ファンクション）に従って実行させる。これは、「ポリモルフィックな呼出し」と呼ばれる。このような状況においては、オブジェクトに従って異なるようにコンパイルする。これらの問題のゆえに、目的の方法（Ｍ）について仮定を行わず、従ってこれを最適以下に呼出しをコンパイルしなければならない。
ジャバは、非常にオブジェクト指向的である言語の一例であり、ジャバは単一の継承を許容する。他の言語、例えばＣ＋＋は多くの継承を許容する。継承は、ポリモルフィズムを導く。
オブジェクト指向環境においては、方法（Ｍ）は、方法（Ｍ）の多くの異なる構成がシステムにおいて利用可能であるならば、ポリモルフィックであると言われ、使用される構成は方法（Ｍ）が呼出される各点およびプログラムの実行時に呼出し点に達するごとにおいて選定される。このような状況は、典型的に、継承によりオブジェクト指向システムにおいて起生し、これによりクラス（あるクラスのインスタンスにおいて呼出され得る方法（Ｍ）を含むあるタイプのオブジェクトの記述）が以降のクラスに対するベースと見なされる。このような新たなクラスは、スーパークラスと呼ばれる元のクラスのサブクラスと呼ばれ、スーパークラスの全ての特質（方法（Ｍ）を含む）を継承すると言われる。しかし、新しいサブクラスは、スーパークラスから継承された方法（Ｍ）の一部または全てをオーバーライドし得、これら方法（Ｍ）のそれ自体の構成を提供し、これらのオーバーライドされた方法（Ｍ）はポリモルフィックであり、これらのオーバーライドされた方法（Ｍ）の１つが呼出される場合に用いられるように選択される構成は呼出が関連させられるオブジェクトのクラスにより支配される。
例えば、単一のネームを付した方法（Ｍ）は、クラスの階層において何度も現われ、ネームを付した方法（Ｍ）の各外観は方法（Ｍ）の異なる構成に対応し得る。走らせられる実際の方法（Ｍ）は、ネームを付した方法（Ｍ）に関するオブジェクトに依存することになる。

方法（Ｍ）のクラスまたは方法（Ｍ）の一部がコンパイルされた形態に変換された後のある時点に発見および（または）ロードされるクラスにより影響をシステムが受け得る状況に対する１つの試みは、動的な機構により呼出される方法（Ｍ）についてのコンパイル・バージョンにおいて仮定を行わないことである。ジャバの環境においては、方法（Ｍ）は、これら方法を以降のサブクラスにおいてオーバーライドすることが違法であることを意味する「ファイナル」とマークすることができる。これは、どの方法（Ｍ）の構成が呼出されているについて仮定を行うことを許容するが、典型的なジャバ・クラスにおける方法（Ｍ）の大部分は柔軟性を理由としてそのようにマークされない。
上記の試みは働くシステムを生じるが、方法（Ｍ）が（方法（Ｍ）に対する呼出しのコンパイルが試みられる時にポリモルフィックでなければ）非ポリモルフィックのままである場合が通常の使用において優勢であると見えるので、潜在的に多数の最適化の機会が失われる。しかし、この方法（Ｍ）がポリモルフィックでないという仮定が行われると、仮定が新たなクラスがシステムへロードされるゆえに偽であると後で見出されるならば、システムは問題となるように走る。
本発明の１つの特質においては、システムを最適化する問題に対する解決法は、その時ロードされたクラスの組に対して最適化することを目的とする。本発明の第２の特質において、前にロードされたクラスのある方法（Ｍ）をオーバーライドする別の組がロードされると、最適化が新たなクラスがオーバーライドする方法（Ｍ）に対する呼出しに対して変更され、すなわち方法（Ｍ）がポリモルフィックであることを発見すると、戻って特定の最適化の仮定を取り消す。
本発明の第１の特質によれば、潜在的にポリモルフィックである方法（Ｍ）に対する呼出しを含むコードをコンパイルする方法が提供され、この方法は方法（Ｍ）がポリモルフィックでないという仮定に基いてコードをコンパイルすることを含む。

オブジェクト指向プログラムにおいては、方法（Ｍ）はポリモルフィックである可能性を有するが、実際には非ポリモルフィックである。方法（Ｍ）が非ポリモルフィックであるという仮定を行うことにより、種々の最適化がコードのコンパイルにおいてなされ、これは例えばコンパイル・コードにより占有されるメモリ量の低減およびコンパイル・コードのより速い実行を生じる。
方法（Ｍ）が非ポリモルフィックであるという仮定がなされると、方法（Ｍ）が「仮定されたファイナル」としてマークされることが望ましい。
コンパイルは方法（Ｍ）に対する呼出しの最適化を含むことが望ましい。
本発明の第１の特質の実施の一形態においては、最適化は、インライニングを含む。特に、呼出される方法（Ｍ）の１つの構成のインライニングがあることが望ましい。以下に更に詳細に述べるように、呼出される方法（Ｍ）は、コードの各部間のジャンプがコードの実行時に少なくて済みフレームの生成コストがなくなるように、方法（Ｍ）の呼出しを含むコードと一致するようにコンパイル時に移動される。このことは、コンパイル・コードのより速い実行を招来する。
本発明の第１の特質の代替的な実施の形態においては、最適化はパッチの形成を含む。方法（Ｍ）がポリモルフィックでないという仮定がなされる場合、方法（Ｍ）を呼出すコンパイル・コードと方法（Ｍ）のコンパイル・コードとの間にパッチが形成される。パッチの形成については、「エージェント資料第１４」とタイトルを付した本発明に関して本文に更に詳細に論述される。
先に示したように、方法（Ｍ）がそれに対する呼出しのコンパイル時にポリモルフィックでない場合、大半の場合に方法（Ｍ）がポリモルフィックでないままであることがしばしば発見される。しかし、仮定が偽であることが見出される幾つかの場合が生じる。例えば、ロードされる新たなクラスは、先にポリモルフィックでないと仮定された方法（Ｍ）の新たなインスタンスを含む新たなサブクラスを含み得る。
当該方法は、この仮定がなされたならば、マーカを生成するステップを更に含むことが望ましい。マーカは、ポリモルフィックでないと仮定された方法（Ｍ）と関連することが望ましく、またマーカがポリモルフィックでないと仮定された方法（Ｍ）ののデータ構造で作られることが望ましい。
方法（Ｍ）がポリモルフィックでないという仮定がなされたことを示すマーカを生成することにより、オーバーライドされるべき仮定がなされたかどうかを調べるため検査を行うことができる。このようなサーチは、新たなクラス、特に新たなサブクラスがシステムへロードされるときに行われることが望ましい。
コードが主パスの断片であることが望ましい。コンパイラは、コードの主パス断片のみをコンパイルするよう構成されることが望ましい。コンパイラの望ましい特徴の論議および主パスの断片のコンパイルの方法については、本明細書の項「エージェント資料第１」を参照されたい。コードの主パスの断片をコンパイルすることによって、頻繁に実行される断片のみがコンパイルされ、これによりコードの頻繁に実行されるセクションのコンパイルにより要する時間およびメモリを低減する。
コードが望ましくはジャバであるオブジェクト指向言語のコードであることが望ましい。

本発明の第１の特質は、コンピュータ・システムを動作させる方法をも提供し、該方法は先に述べたようにコードをコンパイルする方法を含んでいる。
本発明の第１の特質は、コードをコンパイルするコンパイラを含むコンピュータ・システムをも提供し、コンパイラは潜在的にポリモルフィックである方法（Ｍ）に対する呼出しを含むコードをコンパイルするとき、コンパイラが方法（Ｍ）がポリモルフィックでないという仮定に基くコードをコンパイルするように構成される。
方法（Ｍ）がポリモルフィックでないという仮定がなされるならば、当該システムは、方法（Ｍ）を「仮定されたファイナル」としてマークする手段を含むことが望ましい。コンパイル・システムは、方法（Ｍ）を「仮定されたファイナル」としてマークすることが望ましい。このマーキングは、コンパイラ・マネージャによって行われる。
コンパイラは、方法（Ｍ）に対する呼出しを最適化する手段を含むことが望ましい。このコンパイラは、方法（Ｍ）とインラインとなるよう、あるいは方法（Ｍ）に対するパッチを生じるように構成されることが望ましい。
当該システムは更に、前記仮定がなされたならば、マーカを生成する手段を含むことが望ましい。マーカはコンパイル・システムにより、望ましくはコンパイラ・マネージャによって生成されることが望ましい。
当該コードは、オブジェクト指向言語、望ましくはジャバのコードであることが望ましい。
本発明の第１の特質によれば、先に述べた方法によりコードをコンパイルするコンパイラも提供される。
本発明の第１の特質はまた、先に述べた方法によりコンパイルされえるコードを提供する。

本発明の第２の特質によれば、クラスをコンピュータ・システムへ導入する方法が提供され、この方法はクラスの方法（Ｍ）が前にポリモルフィックでないと仮定されたかどうかを決定するステップを含む。この決定は、例えば、本発明の第１の特質に従って提供されるマーカの存在を調べることによって行われる。この決定は、方法（Ｍ）のデータ構造を調べることにより行われる。
このように、本発明の第２の特質は、例えば本発明の第１の特質に従って、コードのコンパイルにおいて仮定が行われた特定のアプリケーションを見出す。
クラスの導入は、新たなクラスのシステムへのローディングを含み得る。
本発明の第２の特質は、ロードされつつある新たなクラスがすでにシステムにおけるクラスのサブクラスであるシステムへの新たなクラスのローディングにおける特定の用途を見出す。
新たなクラスの方法（Ｍ）がポリモルフィックでないと仮定されたことが見出されると、方法（Ｍ）がポリモルフィックでなかったという仮定時に行われた任意の最適化に関して変更が行われることが望ましい。
当該方法は、方法（Ｍ）がポリモルフィックでないと仮定されたと判定されると、コンパイル・コードを調整することを更に含むことが望ましい。この調整は、方法（Ｍ）に対する呼出しを含むコンパイル・コードに対するものである。
コンパイル・コードの調整は、コンパイル・コードのセクションの削除を含む。削除されたコードは、方法（Ｍ）に対する呼出しを含む。例えば、コードのコンパイルの最適化がインラインで含んだ場合、インライン化されたセクションを含むコードのコンパイルのセクションの削除が要求される。
代替的に、あるいはこれに加えて、コンパイル・コードの調整がパッチの取り消しを含むこともある。例えば、コードのコンパイルの最適化が方法（Ｍ）に対する方法（Ｍ）の呼出しから直接指示するパッチを含んだ場合、パッチは行われないことが望ましい。あるいはまた、パッチおよび（または）パッチと関連するコンパイル・コードが削除される。
コンパイル・コードの変更は自動的に行われることが望ましい。これは、幾つかのスレッドが同時に実行中である多重スレッド環境において特に重要である。このような環境において調整が自動的に行われず、仮定が行われた間にスレッドが実行を活発に継続することを許されたならば、コードの領域の調整が行われると同時にスレッドがコンパイル・コードの領域において活発に実行中であるというリスクが存在する。これは、明らかに最も不利となろう。調整が自動的に行われなかったならば、調整が行われた間に調整されるコード領域に進む全てのスレッドの実行を停止することが必要となろう。コードの関連部分を変更することが安全であることを保証するため、特に削除においてコードの変更に先立ち検査が行われることが望ましい。当該方法は、コンパイル・コードの変更に先立ちスタック・ウォーキングを行うステップを含むことが望ましい（「エージェント資料第６」項および「エージェント資料第１４」項を参照）。スタック・ウォーキングは、パッチのアンドゥのためには通常は必要でないが、コードのブロックのコンパイル・バージョンの削除前に行われることが望ましい。
多くの場合に、コンパイル・コードの関連部分が仮定が正しくないと判るとできるだけ早く削除されることが望ましいが、コードのコンパイルされたセクションは実行のため利用できなくなる。コンパイルのセクションにより占有されたメモリを解放するため、コンパイル・コードの関連部分がしかるべきときに削除されることが望ましい。しかし、この部分が削除されるまで、コンパイル・コードは使用されてはならないことをマークされるか、あるいはコンパイル・コードが使用されないように調整がどこかに行われることが望ましい。例えば、「エージェント資料第１」の本発明の実施の一形態においては、方法（Ｍ）のいずれかの部分のコンパイルされたバージョンが存在するならば、方法（Ｍ）のディスパッチ・テーブルがマークされる。このため、仮定が正しくないと見出されるならば、方法（Ｍ）のディスパッチ・テーブルはコンパイルされた断片を参照しないように変化することができ、これにより実行のため利用できないようにする。
新たなクラスの方法（Ｍ）がポリモルフィックでないと仮定されたと判定されるならば、インタプリタが使用されることが望ましい。従って、インタプリタを用いて実行が続くことが望ましい。仮定を行わない新たなコンパイル・バージョンが作られる間を待機することは可能であるが、これは望ましくない。コンパイル・コードが削除されるか利用できなくされる場合、コンパイル・コードが置換されないかあるいは置換されるまでフォールバック・インタプリタが用いられることが望ましい。フォールバック・インタプリタの使用についての更なる論議については、「エージェント資料第１」に見出すことができる。
本発明の第２の特質のコンピュータ・システムを動作させる方法もまた、コードのコンパイルに関する本発明の第１の特質の方法の特徴を含んでいる。

本発明の第２の特質は、
所与のクラスに対する方法（Ｍ）への呼出しをコンパイルし、
新たなサブクラスについて、クラスの方法（Ｍ）が前にファイナルとして処理されたかどうか決定し、
方法（Ｍ）がファイナルでなければ、所与のクラスに対する方法（Ｍ）への呼出しのコンパイルを調整する
ステップを含むコンピュータ・システムの方法をも提供する。
前項による方法は、呼出されている方法（Ｍ）が「ファイナル」であるという仮定を有効に利用する。
コンパイル・コードの調整は、クラスが導入される前に行われることが望ましい。例えば、新たなクラスがシステムへロードされている場合、ポリモルフィックでない方法（Ｍ）に対するサーチと、コンパイル・コードに必要な調整とがともに、新たなクラスのローディングがコンパイルされる前に行われる。
新たなサブクラスの導入は、クラス・ローダの使用によって行われる。クラス・ローダはコンパイル・システムへの呼出しを行うことが望ましい。ロードされるクラスによりオーバーライドされるコードのコンパイル中に仮定がなされたならば、例えばコードの削除が行われるまで方法（Ｍ）のディスパッチ・テーブルの削除および（または）変更によって、パッチを取り消しするか、あるいはコンパイル・コードのコンパイル・バージョンを実行のため利用されないようにすることにより、コンパイラ・マネージャが状況を処理することが望ましい。
本発明の第２の特質によれば、クラス・ローダを用いてコンパイル・コードを含むシステムへクラスをロードする方法が提供され、これにおいてクラス・ローダが、クラスによりオーバーライドされるコンパイル・コードにおいて仮定がなされたかどうかを決定する。
オーバーライドされる仮定がなされたならば、クラス・ローダがコンパイル・コードのマネージャへの呼出を行うことが望ましい。この呼出しは、先に示したようにコンパイル・コードの調整に導く。
本発明は、更なる特質において、本発明は、所与のクラスに対する方法（Ｍ）への呼出しをコンパイルする手段と、方法（Ｍ）がファイナルとして処理できるかどうか判定する手段と、この判定に基いて所与のクラスに対する方法（Ｍ）への呼出しのコンパイルを調整する手段とを含むコンピュータ・システムを提供する。
従って、本発明は、コンピュータ・システムの最適化に対する機会を強化する。
本発明の第２の特質は、新たなクラスを導入する手段を含むコンピュータ・システムをも提供し、当該システムはクラスの方法（Ｍ）がポリモルフィックでないと前に仮定されたかどうかを決定する手段を含んでいる。新たなクラスを導入する前記手段は、クラス・ローダであり得る。
前記システムは更に、新たなクラスの方法（Ｍ）がコードのコンパイルにおいてポリモルフィックでないと仮定されたと決定されるならば、コンパイル・コードを変更する手段を含むことが望ましい。コンパイル・コードの変更は、コンパイル・システムにより、望ましくはコンパイラ・マネージャによって行われることが望ましい。

当該システムは、パッチを取り消しする手段を含む、コンパイル・コードを削除する手段を含むことが望ましい。このコンパイラ・マネージャは、削除装置を含む。
当該システムがスタック・ウォーキング装置を含むことが望ましい。
前記システムが更にインタプリタを含むことが望ましい。
本発明の第２の特質によれば、
所与のクラスに対する方法（Ｍ）への呼出しをコンパイルするコンパイラと、
クラスの方法（Ｍ）が前にファイナルとして処理されたかどうかを新たなサブクラスについて決定する手段と、
所与のクラスに対する方法（Ｍ）がファイナルでなければ、該方法（Ｍ）への呼出しの前にコンパイルされたバージョンを調整する手段と、
を含むコンピュータ・システムが提供される。
新たなクラスを導入する前記手段がクラス・ローダを含むことが望ましい。
本発明の第２の特質が更に、先に述べたようにコンピュータ・システムにおいて使用されるクラス・ローダを提供する。
本発明は、更に他の特質において、所与のクラスに対する方法への呼出しをコンパイルする手段と、方法が前にファイナルとして処理されたかどうかを決定する手段と、方法が前にファイナルとして処理されるならば所与のクラスに対する方法への呼出しのコンパイルを調整する手段とを含むコンピュータ・システムを提供する。
また、本発明によれば、先に述べたように、本発明の第１および（または）第２の特質に従って方法を実施するためのプログラムが記録されたコンピュータ読取り可能な記憶媒体が提供される。
本発明は、コードをコンパイルする方法を実施するためのプログラムが記録されたコンピュータ読取り可能な記憶媒体に拡張し、当該コードは潜在的にポリモルフィックである方法（Ｍ）への呼出しを含み、当該方法は方法（Ｍ）がポリモルフィックでないという仮定に基いてコードをコンパイルすることを含む。
本発明はまた、クラスをコンピュータ・システムへ導入する方法を実施するためのプログラムが記録されたコンピュータ読取り可能な記憶媒体に拡張し、当該方法は、クラスの方法（Ｍ）が前にポリモルフィックでないと仮定されたかどうかを判定するステップを含む。
本発明は更に、先に述べたような方法に従ってプログラムされるとき、コンピュータに拡張する。
本発明はまた、コードをコンパイルする方法に従ってプログラムされたとき、コンピュータに拡張し、当該コードは潜在的にポリモルフィックである方法（Ｍ）への呼出しを含み、当該方法は方法（Ｍ）がポリモルフィックでないとの仮定に基いてコードをコンパイルすることを含む。
更に、本発明は、コンピュータ・システムへクラスを導入する方法に従ってプログラムされたとき、コンピュータに拡張し、当該方法は、クラスの方法（Ｍ）が前にポリモルフィックでないと仮定されたかどうかを決定するステップを含む。

要約すると、先に概要を述べた問題は、多数の要因を用いて本発明の種々の特質によって解決される。これらの第２の要因は、このような状況におけるクラス・ローダの動作を、先のコンパイルの間に行われた方法（Ｍ）のファイナルであることについての仮定が誤りであることが判ったときにコンパイル・コードについてマネージャに通知するように調整する能力である。第２の要因は、任意の時点で理由のいかんを問わずシステムから要求されないコンパイル・コードを除去する能力である。第３の要因は、存在するコンパイル・コードのシーケンスにパッチを使用することであり、コードが「ライブ」である間にコード動作の調整を許容して、１つ以上の仮想マシンにより潜在的に実行される。
本発明の特質のいずれか、あるいは一部、あるいはその全ては、他の特質に適用されよう。下記の考慮は、先に述べた本発明のいずれかおよび全て、および本発明の特質に適応する。
本発明の望ましい実施の形態については、純粋に事例として、（改善を示す）図面を参照して次に記述することにする。
潜在的にポリモルフィックである方法は、実際には特定の時点においてポリモルフィックでないことがある。このような方法（Ｍ）がコンパイル時にポリモルフィックでなければ、方法（Ｍ）に関する呼出しのコンパイルにおいて、特に方法（Ｍ）への呼出しに関するコードに対して最適化が可能である。
コードの各セクションがコンパイルのため仮想マシンにより考察されるとき、コード部分からの任意の潜在的にポリモルフィックな呼出しもまた考察される。このような各呼出しに対して、呼出しの決定がコンパイル時に固定される（すなわち、この時この方法（Ｍ）の１つの構成のみが存在する）ならば、コンパイル・システムにより状況がそうあり続けるという仮定がなされる。これは、呼出された方法（Ｍ）の１つの構成のインライニングに限定はしないがこれを含む種々の最適化を行うことを可能にする。

例えば、クラスＸは、方法（Ｍ）バーへの呼出しを含む方法（Ｍ）ｐｕｌｉｃ ｉｎｔ ｆｏｏ（ｉｎｔ）を定義する。

ｐｕｌｉｃ ｉｎｔ ｆｏｏ（ｉｎｔ）内の呼出しは、コードの当該部分からバーへのジャンプを生じる。バーがいったん実行されると、スレッドはしばしば、この場合はｐｕｌｉｃ ｉｎｔ ｆｏｏ（ｉｎｔ）へ再びジャンプすることにより、元のファンクションへ戻ることになる。このように、ｐｕｌｉｃ ｉｎｔ ｆｏｏ（ｉｎｔ）の実行において、少なくとも２つのジャンプが要求される。
バーへの呼出しを含むコード部分のコンパイル・バージョンを生じる決定がされるならば、バーがファイナルであるという仮定がなされると、バーへの呼出しのコンパイルに対して種々の最適化が可能である。バーがファイナルでないことが判らなければ、これがそうであるという仮定はコンパイル時に行われる。バーへの呼出しの２つの最適化例は、インライニングおよびパッチングである。
インライニングの最適化法においては、方法（Ｍ）のバーは、このバーが呼出されるｐｕｌｉｃ ｉｎｔ ｆｏｏ（ｉｎｔ）のコードの残部と一致するように移動される。

バーへの／からのジャンプが要求されず、要求されるフレームの生成および破壊のためのコードがないため、最適化が達成される。バーのコンパイル・コードは、逐次方法（Ｍ）に置かれる。これは更に、最適化のための更なる最適化を表わす。

パッチングにおいては、バーへの呼出しとバーの方法（Ｍ）との間に直接リンク（パッチ）が行われる。このパッチは、バーの方法（Ｍ）へのジャンプを生じるコードの一部である。パッチを用いることにより、バーへのジャンプの実行はランタイムにおいて速く行うことができる。パッチの形成については、項「エージェント資料第１４」に更に詳細に記述される。
最適化は、方法（Ｍ）のバーがファイナルであるという仮定を用いて行われた。コードの結果として得るコンパイル・バージョンが実行環境の潜在的部分として仮想マシンの残部に利用可能とされる前に、呼出される方法（Ｍ）がそのＶＭデータ構造において、オーバーライドされない（すなわち、ファイナルの方法（Ｍ）である）ことを仮定するコンパイル・コードを持つものとマークされる。先に示した事例では、このマークは、何かが方法（Ｍ）をオーバーライドするようになされるならば何かがなされた仮定に照らして行われねばならないことを示す、方法（Ｍ）のバーと関連するデータ構造において作られる。

後のある時間に、方法（Ｍ）のバーの新たなバージョンを含むクラスＹ（クラスＸのサブクラス）が導入される。

バーがファイナルであるという仮定は、現在あるコンパイル・コードに対してすでになされ、このコンパイル・コードの調整が要求される。
図９Ａは、クラス・ローダが例えばロードされる新たなクラスの方法（Ｍ）を調べる望ましい実施の形態に関するフロー図を示している。
当該クラス・ローダは、システムへのローディング４０００のための新たなクラスを見出す。クラス・ローダは、種々の検査が行われるまでクラスをロードしない。第１のステップ４００２として、クラス・ローダが、クラスがロードされるべきシステムに対して有効なクラスであるかを知るため標準的な検査を行う。もしそうでなければ、例外が投入される。もしそうであれば、クラス・ローダはロードされるべきクラスにおけるインスタンスの方法（Ｍ）を探す４００６。ステップ４００８において、クラス・ローダは、方法（Ｍ）について、この方法（Ｍ）が別の方法（Ｍ）をオーバーライドする方法（Ｍ）であるかどうか、例えば、これがロードされるクラスのペアレント・クラスの方法（Ｍ）をオーバーライドするかどうかを知るために調べる。もしそうでなければ、クラス・ローダは、次の方法（Ｍ）を調べる。この方法（Ｍ）がペアレントの方法（Ｍ）をオーバーライドすることを見出すならば、クラス・ローダは、マークされたかどうかを知るためにペアレントの方法（Ｍ）のデータ構造を調べる４０１２。先に述べたように、マーカは、方法（Ｍ）のコンパイル・バージョンに対するコンパイルされた呼出しが、ペアレントの方法（Ｍ）がファイナルであるという仮定に基いて用意されたことを表わす。マーカがなければ、クラス・ローダは、新たなクラスにおける別の方法（Ｍ）を探し続ける４０１４。マーカがあれば、クラス・ローダは、ペアレントの方法（Ｍ）がファイナルであったという仮定に基いてコンパイルされたコンパイル・コードについて何かがなされねばならないことを示すためコンパイル・システムに呼出しを行う４０１６。次いで、クラス・ローダは、ロードされるクラスの別の方法（Ｍ）を探し続ける。

以下において、バーがファイナルであったという仮定によりコードのコンパイルにおいてなされた最適化はパッチである。図９Ｂは、方法（Ｍ）のバーに対する呼出し４０２２を含むコードの断片を含んでいるコンパイル・コードのセクション４０２０を示している。最適化においては、方法（Ｍ）のバー４０２８のコンパイルされたクラスＸの形態へ直接移る（パス４０２７）ため、呼出し４０２２が行われるように、パッチが行われる。
方法（Ｍ）のバーがファイナルであることが正しくないことが判ったという仮定がなされる場合、パッチは下記のように取り消される。すなわち、
呼出し４０２２は、方法（Ｍ）に対する一般的呼出し４０２４への移動４０２３へ変更される。呼出し４０２２のリダイレクションは自動的に行われる。
呼出し４０２４の一般的形態は、コンパイルされる方法（Ｍ）ｆｏｏ４０２０が生成されたのと同時にアウトライアとして用意され、方法（Ｍ）のバーの多くの異なる構成（４０２８、または４０２６）へ転移することができる（４０２９、または４０２５）。
パッチのリダイレクションおよび削除の更なる詳細については、「エージェント資料第１４」を参照されたい。
以下においては、バーがファイナルであるという仮定によりコードのコンパイル時になされた最適化はインライニングである。図９Ｃは、第１の部分４０３２、第２の部分４０３４、および第３の部分４０３６を含むコンパイル・コード４０３０の各部を示している。第２の部分４０３４は、バーに対する呼出しを含むコードのコンパイル・バージョンである。方法（Ｍ）のバーは、バーがこの時部分４０３４に部分４０３８として含まれるようにインラインされている。
仮定が正しくないことが後で判るならば、コンパイル・コード部分４０３４は削除されることになる。部分４０３４を含む方法（Ｍ）のディスパッチ・テーブルは、コードのコンパイル・バージョン４０３４を参照しないように変化される４０３４。
部分４０３０の以降の実行時に、コンパイル・コードの部分４０３２が部分４０３２の終りに最初に実行され、制御はグルー・コードへ進む。グルー・コードは、次の部分４０３４のコンパイル・バージョンがあるかどうか知るために調べる。コンパイルされた部分が見出されず、従って、更なる実行のため制御をインタプリタへ送るために準備がなされる。
制御は、最初に状態を更新するためアウトライアへ送られる。（「エージェント資料第３」参照）

グルー・コードは、インタプリタに対し、部分４０３４に対応するコードのコンパイルされないバージョンの実行を開始するよう通知する。
後の時点で、コンパイルされた部分４０３４が削除される。前記部分が削除される前にスタック・ウォーキングが行われる。（「エージェント資料第６」参照）
このように、方法（Ｍ）がファイナルであるという仮定が正しくないことが後で発見されるならば、パッチの最適化がインライニングよりも容易にアンドゥされることが判る。しかし、インライニングの使用から更に優れた最適化および少ない実行時間が得られ、仮定がまれにのみ正しくないと証明されることが考えられるならば、多くの場合にインライニングが選好される。
要約すれば、新たな各クラスがロードされると、クラス・ローダが、新たなクラスの方法（Ｍ）のどれかがそのデータ構造においてセットされたマーカで方法（Ｍ）をオーバーライドするかどうか知るために調べる。もしそうであれば、クラス・ローダは、仮想マシンのコンパイル・コードのマネージャ部分に対する呼出しを再び行い、全ての影響を受けたコンパイル・コードが削除されるかあるいはアクセス不能にされることを要求する。
呼出しコードのコンパイル・バージョンが呼出している方法（Ｍ）の内部の詳細について多くの仮定を行わないように構成されると、上記機構と平行して使用できるより簡単な機構は、呼出される方法（Ｍ）のコンパイル・バージョンに対し直接呼出す呼出しコードのコンパイル・バージョンののパッチングを可能にすることである。このような直接のパッチは、先に述べたものと同じ検出機構を用いて以降にロードされるクラスが問題の方法（Ｍ）をオーバーライドすることが判るならば、比較的容易にアンドゥできる。パッチされるバージョンの利点は、これがどの構成が呼出しのため選択するかについての呼出しの時点における動的な決定を行うことのオーバーヘッドを避けることである。１つの可能性しかなくとも、パッチされる形態が使用されなければ、オーバーヘッドは存在する。
図９Ｄは、望ましい実施の形態を実施するための装置を示している。この装置は、コンパイラ４０４２とコンパイラ・マネージャ４０４４を含むコンパイル・システム４０４０を含んでいる。コンパイラ４０４２は、パッチを生成する最適化装置４０４６とインライニングを行う最適化装置４０４８とをそれぞれ有する。コンパイラ・マネージャ４０４４は、呼出しがこれがファイナルであるという仮定に基いてコンパイルされることを示す方法（Ｍ）をマークするためのマーキング装置４０５０を含んでいる。
当該装置は更に、新たなクラスをローディングするクラス・ローダ４０５２を含む。このクラス・ローダは、ロードされるクラスの方法（Ｍ）が、これがファイナルであるという仮定に基いてコンパイルされた方法（Ｍ）をオーバーライドするかどうか判定する方法（Ｍ）・チェッカ４０５４を有する。この方法（Ｍ）・チェッカ４０５４は、方法（Ｍ）のデータ構造におけるマーカについてサーチする。

オーバーライドされた方法（Ｍ）が見出されると、クラス・ローダ４０５２は、変更装置４０５６を用いるコンパイラ・マネージャ４０４４にコンパイル・コードに対する必要な変更を行うように通知する。変更装置４０５６は、コンパイル・コードの関連部分を実行のため使用できないようにする絶縁装置を含む。変更装置４０５６は更に、パッチ・アンドゥ装置４０６０と、例えば不要なコンパイル・コードの部分を削除する削除装置４０６２とを含む。変更装置４０５６はまた、コンパイル・コードを安全に削除することを許容するスタック・ウォーカも含んでいる。
当該装置は更に、コンパイル・コードを実行する実行装置４０６６を含んでいる。グルー・コード４０６８およびアウトライア４０７０は、必要な場合にインタプリタによる実行の転送を行うために設けられる。インタプリタ４０７２は、インタプリタによるコードのブロックの実行を記録するための実行履歴レコーダ４０７４を含む。この情報は、主パスのコンパイルのために使用される（「エージェント資料第１」参照）。
上記のいずれかあるいは全てにおいて、本発明の幾つかの特徴はコンピュータ・ソフトウエアを用いて実現された。しかし、当業者には、これらの特徴のいずれもハードウエアまたはハードウエアとソフトウエアの組合わせを用いて実現されることが無論明らかであろう。更に、ハードウエア、コンピュータ・ソフトウエアなどにより行われるファンクションが電気信号などで行われあるいはこれを用いて行われることが容易に理解されよう。
情報の格納に関する特徴は、適切な記憶場所またはストアによって実現されよう。情報の処理に関する特徴は、ソフトウエアまたはハードウエアにおいて、あるいは両者の組合わせにおいて、適切なプロセッサまたは制御手段によって実現されよう。

上記のいずれかあるいは全てにおいて、本発明は、下記の形態のいずれか、あるいは一部、あるいはその全てにおいて具現され、すなわち、本発明は、コンピュータ・システム自体において具現され、コンピュータ・システムを動作させる方法でプログラムされあるいはこれを実行する酔う構成されるとき、コンピュータ・システムにおいて具現され、および（または）コンピュータ・システムを動作させる方法に従って動作するためのプログラムが記録されたコンピュータ読取り可能な記憶媒体において具現されよう。
本文において用いられるように、用語「コンピュータ・システム」は、「コンピュータ」、「システム」、「装備」、「装置」、「マシン」などと互換であり得る。コンピュータ・システムは、仮想マシンであり得、あるいは仮想マシンを含み得る。
上記のいずれかまたは全てにおいて、方法および装置の特徴および特質を含む上記の異なる特徴および特質は、任意の適切な方法で組合わされよう。
本発明が、純粋に事例として本文に記述され、細部の修正が本発明の範囲内で可能であることが理解されよう。
本文の記述、および（適切な場合に）請求の範囲および図面において開示された各特徴は、独立的に、あるいは任意の適切な組合わせにおいて提供されよう。

エージェント資料第１０−コンピュータ・システム、コンピュータ読取り可能な記憶媒体および同媒体を動作させる方法、および前記システムを動作させる方法
本発明は、特に排他的ではないが多重スレッド環境において、一般にデータ構造のアクセスに関するものである。望ましい実施の形態において、本発明は、多重スレッド環境における無秩序なリストに対するサーチ時間の短縮に関するものである。

多重スレッド環境においては、共有されるデータ構造（すなわち、同時に１つ以上のスレッドによりアクセスできるもの）が改変されるときにいつでも実行が行われねばならない。このような注意がないと、スレッドは部分的に更新されたデータを調べ、従ってデータ構造の損なわれた表示を取得する。頻繁な構成手法は、相互に排他的なアクセス機構「ミューテックス」を用いてデータ構造に対するアクセスをロックすることである。これは、修正を行うコードにより一時に１つのスレッドによるアクセスを許容する。その結果は、アクセスを競合するスレッドの数が多くなるほど遅くなる非常に遅いプロセスとなる。あるデータ構造は、修正を行うアクセスよりも多くのデータ構造を読出すアクセスを生じ、これらはデータを読むだけのアクセスのためにはミューテックスを使用しないアクセス機構から利益を蒙る。
本発明の第１の特質は、特に、コンピュータ・システムにおけるエントリのリストにおいて特定のエントリをアクセスする方法に関するものであり、エントリの１つに対する開始ポインタを読出し、特定のエントリが見出されるまで開始ポインタにより指示されるエントリから更に開始するリストにおけるエントリを調べ、見出された特定のエントリをアクセスするステップを含んでいる。
当該方法の公知の構成においては、このリストは、明白な初めと明白な終りとを持ち、開始ポインタはつねにリストの初めを指示し、次のエントリ・ポインタに対する空値を持つ最後のエントリを除いて、各エントリはリストにおける次のエントリに対するポインタを含んでいる。
アクセスされる特定のエントリがリストの終りにあるならば、この特定のエントリが見出される前にリストにおける全てのエントリを調べることが必要である。多くの用途において、見出された特定のエントリがリストが次にアクセスされることが要求されるエントリとなるという平均以上の確率が存在する。このような場合、当該方法の公知の構成によれば、特定のエントリが見出される前にリストの全てのエントリを調べすることが必要であれば、次のアクセスにおいて特定のエントリが見出される前にリストの全てのエントリを調べることも必要となるという平均以上の確率が存在する。
更に他の手法においては、特定のエントリが見出されると、見出されたエントリをリストの前方に移すためリストが記録される。このため、見出されるエントリは、次にリストがアクセスされるとき最初に調べられるものとなる。リストがこの方法で記録される場合、データ構造へのアクセスをミューテックスを用いてロックすることが必要である。２つのスレッドが同時にリストを並べ替えようと試みたならば、リストの改変が生じ易い。

本発明の第１の特質によれば、コンピュータ・システムにおけるエントリ・リストにおける特定のエントリをアクセスする方法であって、各エントリがリストにおけるエントリを指示するそれぞれの次のエントリ・ポインタを含む結果次にエントリ・ポインタが１つの閉ループを形成することになる方法が提供され、当該方法は、エントリの１つに対する開始ポインタを読出し、次にどのエントリを調べるかを決定するために、調べられるエントリに対する次のエントリ・ポインタが読出される、特定のエントリが見出されるまで開始ポインタにより指示されたエントリ・ポインタから更に始まるリストにおけるエントリを調べ、同じか異なる特定のエントリに対する上記ステップの反復において調べるステップが最初に述べた特定のエントリの検査から始まるように、見出された特定のエントリを指示するように開始ポインタを重ね書きするステップを含んでいる。
同じか異なる特定のエントリに対する前記ステップの反復において検査ステップが最初に述べた特定のエントリを調べることから開始するように、見出された特定のエントリを指示するように開始ポインタを重ね書きすることにより、多くのアプリケーションにおいて、アクセスを速くかつ効率的にするために、見出された特定のエントリが次にリストがアクセスされるときに要求されるエントリとなる、平均以上の確率が生じるという利点が得られる。
本発明によれば、エントリはそれぞれ、リストにおけるエントリを指示する次の各エントリ・ポインタを含み、検査ステップにおいて、調べられるこのようなエントリに対する次の各ポインタが、次にどのエントリを調べるかを決定するために読出される。従って、リストは、先に述べた公知の構成におけるように、空の次のエントリ・ポインタを有する明白な初めと明白な終りを持つリストではなく、無限ループであると考えることができる。
リストが１つのエントリしか持たない場合は、エントリの次のエントリ・ポインタはそれ自体を指すことになる。しかし、通常は、次のエントリ・ポインタは、リストにおけるエントリの異なる１つを指すことになる。
方法が無限にループすることを阻止するために、特定のエントリが検査ステップの間は見出されない場合は、各エントリが１回調べられるごとに検査ステップが１回終了され、アクセス・ステップと重ね書きステップとは省かれることが望ましい。

本発明の第２の特質は、コンピュータ・システムの動作方法を提供し、該方法は、複数のスレッドを実行するステップを含み、各スレッドが本発明の第１の特質による各アクセス・方法をエントリのこのような共通リストに関して実施し、各アクセス・方法がエントリ・リストに関してこのような共通の開始ポインタを読出す。
本発明の第１および第２の特質の方法においては、開始ポインタを重ね書きするステップが、自然あるいは特殊な設計のいかんを問わずアトミックであることが望ましい。このことは、多重スレッド環境において特に有利である。ポインタ位置がアトミックに変更可能である場合、２つのスレッドが同時にポインタ位置を変えようと試みるときのデータ破壊のリスクが低減される。このため、ミューテックスの保護によらずポインタ位置の変更を許容することが可能となる。また、特定のエントリをアクセスするステップは、読出しアクセス・ステップであることが望ましい。
本発明の第３の特質は、コンピュータ・システムにおけるエントリのリストを形成する方法を提供するもので、該方法は、
各エントリに次のエントリ・ポインタを与え、
エントリ・ポインタの閉ループを形成するように次のエントリ・ポインタを構成し、
異なるエントリを指示するため重ね書きが可能である、エントリを指示する開始ポインタを提供する
ステップを含んでいる。
本発明の第４の特質は、本発明の第３の特質によりエントリのリストを形成する方法と本発明の第１の特質によりエントリをアクセスする方法とを含む、コンピュータ・システムを動作させる方法を提供する。
本発明の第５の特質は、本発明の第１および第２の特質の方法を実施するようプログラムされるコンピュータ・システムを提供する。
本発明の第６の特質は、エントリのリストを記憶する手段と、エントリの１つに対する開始ポインタを記憶する手段と、開始ポインタを読出す手段と、特定のエントリが見出されるまで開始ポインタにより指示されるエントリから始まるリストにおけるエントリを調べる手段と、見出された特定のエントリをアクセスする手段とを含むコンピュータ・システムを提供し、該システムは、見出された特定のエントリを指示するように開始ポインタを重ね書きする手段を特徴とする。
本発明の第７の特質は、エントリのリストとこれらエントリの１つに対する開始ポインタとが記憶され、各エントリが次の各エントリ・ポインタを含み、次のエントリ・ポインタの全てがリストにおけるエントリを指示する、コンピュータ・メモリを提供する。

次のエントリ・ポインタが一緒に閉ループを形成することが望ましい。
本発明の第８の特質は、本発明の第７の特質によるメモリと、開始ポインタを読出し、特定のエントリが見出されるまで開始ポインタにより指示されるエントリから始めるリストにおけるエントリを調べ、見出された特定のエントリをアクセスするようにプログラムされたプロセッサとを含むコンピュータ・システムであって、見出された特定のエントリを指示するように、プロセッサが開始ポインタを書直すようにプログラムされることを更に特徴とするコンピュータ・システムを提供する。
本発明の第９の特質は、コンピュータ・システムにおけるリストにおけるデータをアクセスする方法であって、リストをループの形態に構成し、所与の要素をループでアクセスし、該要素を次のアクセスのためのループの始まりであるように選定するステップを含む方法を提供する。
本発明の第１０の特質は、リストにおけるデータをアクセスするコンピュータ・システムであって、閉ループの形態でデータを構成する手段と、所与の要素をループでアクセスする手段と、該要素を次のアクセスのためループの開始時に選定する手段とを含むコンピュータ・システムを提供する。
本発明の上記特質において、エントリあるいは要素の少なくとも一部がそれぞれコンパイル・コードの各セグメント（または、チャンク）を含み、そして（または）エントリあるいは要素の少なくとも一部がそれぞれ各キーを含むことが望ましい。
本発明の第１１の特質は、全くの方法の特質のいずれかをコンピュータ・システムに実施させ、あるいは本発明のシステムの特質のいずれかに従って動作させるように実行可能なコンピュータ・プログラムが記録されたコンピュータ読取り可能な記憶媒体を提供する。

本発明の少なくとも一部の実施の形態の主な利点は、リストにおけるデータに対するアクセス時間を短縮すること、および相互に排他的なアクセス機構あるいはミューテックスとして知られる機構の必要を避けることである。
当該方法は、多重スレッド環境において特に有利である。選択は１つの書込み操作として行われる、すなわち、アトミックであることが望ましい。これは、安定性が維持されるものとすれば多重スレッド環境において非常に有利である。
本発明、あるいは本発明の少なくとも特定の実施の形態は、ミューテックスによらず読むことができる無秩序の単にリンクされたリストのアクセスにおける最適化を提供する。本発明は、新たなエントリをこのようなリストに挿入する問題、あるいは古いエントリを取除く更に困難な問題を目的とするものでもなく、いずれのタスクの複雑さを増すものでもない。このような種類の修正が要求される場合、ある種のバルブ機構が提供されることが望ましい。同様に、リストが秩序のあるリストであるならば、本発明は通常は適用され得ない。
本発明の任意の特質のいずれか、あるいは一部、あるいはその全てが他の任意の特質に適用されよう。
本発明の望ましい特徴については、純粋に事例として、添付図面に関して次に記述される。

図１０Ａのデータ構造は、エントリ２６１１０、２６１１２、、、２６１０６のリストと、このリストの初めに対するポインタｌｉｓｔ＿ｈｅａｄ２６１０４とを含んでいる。エントリの各々は、リストにおける次のエントリに対するポインタｎｅｘｔ＿ｐｔｒとキーとデータを含んでいる。リストにおける最後のエントリ２６１０６において、次のエントリ・ポインタｎｅｘｔ＿ｐｔｒの値はＮＵＬＬ値である。
図１０Ａに示されるデータ構造が非常に頻繁に読出すためアクセスされ、ミューテックスを持たないアクセス機構が有効であるならば、ミューテックスを取得し解放するために要する時間はデータ構造をアクセスする時間の著しい割合となる。
図１０Ａの事例において、スレッドは通常、ポインタｌｉｓｔ＿ｈｅａｄ２６１０４を介して第１の要素２６１１０に進入し、更に逐次リストにおける他のポインタを介して移動することになる。ポインタｌｉｓｔ＿ｈｅａｄ２６１０４が（例えば）第２の要素２６１１２へ移動されるならば、この点においてリストに進入するスレッドがリストにおける要素の全てを「知る」ことがない。このような問題を克服するため、全ての要素が判るようにリストが並べ直されねばならないが、ミューテックスが設けられねばならない。
特に図１０Ｂによれば、本発明の実施の形態において、リストの終りであったものにエントリ２６１０６におけるポインタｎｅｘｔ＿ｐｔｒの追加によりリストをループに作ることにより、次にアクセスされる確率の最も高い要素を示すためどのスレッドも、ポインタｌｉｓｔ＿ｈｅａｄ２６１０４をループの初めに独立的に変更することができる。以降のアクセス時に、サーチされるアイテムが調べられた最初のアイテムに更になりがちである。これは、スレッドが探している要素を見出すごとに、図１０Ｃにおける破線２６３１２により示されるようにループに対する次のアクセス時に次のスレッドがアクセスされた最後の要素へ向けられるように、このスレッドがポインタｌｉｓｔ＿ｈｅａｄ２６１０４を書き換えるゆえであり、仮定はこれが再び必要とされる可能性が最も高いことである。
本発明の当該実施の形態では、スレッドがアクセスされた最後の点においてループにアクセスし、これが必要とする要素を見出すまでループを循環し続ける。１つ以上のスレッドがこの状態を同時に行い、各スレッドがアクセス時に遮断する試みにおけるポインタｌｉｓｔ＿ｈｅａｄを書直すならば、これは問題にならない。２つのスレッドが同時にポインタｌｉｓｔ＿ｈｅａｄを変更しようとするならば、この変化が生じる順序は、各変更がアトミックであるかぎり問題ない。この変化は非常にしばしばアトミックであるが、もしそうでなければ、そうなるように容易に保証され得る。ミューテックスを設けることよりも項の計算時にポインタを（自動的に）変更することの方がはるかにやさしい。
スレッドが付加または削除を必要とするならば、別のスレッドが同時に同じことを試みるのを阻止するためミューテックスが介挿される。しかし、ミューテックスが読出し専用スレッドには適応しないので、読出しスレッドは妨げられない。読出しスレッドに対する修正はアトミックに見えるが、修正をアトミックに変更することはできない。

先に述べたように、図１０Ａにおいて、伝統的なリストの終了エントリがノード２６１０６における空ポインタにより示される。ポインタｌｉｓｔ＿ｈｅａｄ２６１０４が第１のノード２６１１０を指示する。本発明の当該実施の形態は、ノード２６１０６における空ポインタをリスト２６１１０の初めに対するポインタｎｅｘｔ＿ｐｔｒ２６２０２（図１０Ｂ）と置換する。このことは、更に伝統的なリストではなく周期的なループを生じる。データ構造をループとして構成することにより、リストが有効に自然に指導するノードを持たない特性を創製した。選択するノードがどちらであってもリストの先頭として処理することができ、処理はスタート点に再び達するまで全てのノードを巡ることによって達成される。従って、伝統的なリストを下記により処理することになる。すなわち、

ループを下記アルゴリズムにより処理するとき、同じ効果が本発明の実施の一形態において達成される。すなわち、

本発明の当該実施の形態の利点は、ステップ１５においてミューテックスなしにポインタｌｉｓｔ＿ｈｅａｄを読出しアクセスが書き換えることを許すことによって達成される。

ループ内の任意のノードがリストの先頭として等しく有効に処理することができるから、スレッドがポインタｌｉｓｔ＿ｈｅａｄをアトミックに更新することができるものとして、ミューテックスが要求される。すなわち、２つのスレッドがほとんど同時にｌｉｓｔ＿ｈｅａｄを更新するならば、どのスレッドが最初にアトミックに書くかは問題ではなく、データ構造はつねに一貫している。
上記プロセスにおいて、ｆｉｒｓｔ＿ｐｔｒはステップ１１においてｐｔｒに等しくセットされ、これは更にステップ１０においてｌｉｓｔ＿ｈｅａｄに等しくセットされ、ステップ１９におけるテストがｌｉｓｔ＿ｈｅａｄではなくｆｉｒｓｔ＿ｐｔｒに関して行われ、その結果異なるスレッドは、その間ステップ１３と１９間でループを阻止することなくｌｉｓｔ＿ｈｅａｄを変更することができ、おそらくはループにおけるエントリの全てのキーをテストする。
リストが無秩序であるがリストのサーチにおいて見出される最後のアイテムもまたリストが次にサーチされるときについて問い合わされる環境においては、先に述べたようにｌｉｓｔ＿ｈｅａｄを変えることにより、サーチにおいて尋ねるノード数を減らし、従ってサーチ時間を減らす。

明らかなように、本発明は特に有効かつ簡単であり、実現が安価である。更に、本発明は、付加／削除手順を複雑にせず、ミューテックスを必要とすることなく行うことができる。
このような環境の一例は、チェーンを持つハッシュ・テーブルを用いてソース・ジャバおよび任意の相当コンパイル・ホスト・コードにおけるバイト・コード間をマップする。
無秩序なリストに多くの、例えば約１０，０００あるいはそれ以上のノードがあることはあまりない。このようなサイズの１つのリストにおけるサーチ時間が異常に長くなるので、１つのチェーンをこのような多数ノードで形成することは実用的でない。従って、それぞれが管理可能なノードまたは要素の数を持つ個々のチェーンを生成することが実際的である。コンピュータ・システムは、ビジット・スレッドを正しいチェーンへ送るためある種のアドレス指定装置またはソフトウエアを必要とする。
２つのチェーンしかない場合は、基本的な事例を選択するためには、キーについての１回のテストで充分である。このテストは、キーが偶数であればバケットの１つのチェーンを指示し、キーが奇数であれば異なるチェーンを指示することを含む。当該システムは、チェーン当たり比較的少ないバケットがある場合に良好に働くことができる。しかし、規準は、チェーン当たり数十あるいは数百のバケットがざる場合であり、領域に１０，０００バケットがある場合は、管理するかなりの数のチェーンが存在することになる。このような状況は、索引テーブル（望ましくは、ハッシュ・テーブル）の使用により処理することができる。１つのチェーンを他のチェーンから分けて識別するには、素数による除算のようなキーについての簡単なテストを用いることができる。これは、略々同数のエントリがこのようなチェーンごとに割付けられる場合にも望ましい。このハッシュ・アルゴリズムは、適切に選定されることを必要とする。実行の決定は、通常、ハッシュをどれだけ広く規定するかについて必要である。
図１０Ｄにおいて、先に述べた方法を実施するためのコンピュータ・システム２６１００は、ポインタｌｉｓｔ＿ｈｅａｄ２６１０４およびエントリ２６１１０、２６１１２、、、２６１０６を記憶するメモリ２６１０２、メモリ２６１０２をアクセスして方法を実施するプロセッサ２６１０７、および方法の実施のためプロセッサ２６１０７をプログラミングするためプロセッサ２６１０７により読むことができるプログラムを含む記憶媒体２６１０８を含んでいる。
上記のいずれかまたは全てにおいて、本発明の幾つかの特徴は、コンピュータ・ソフトウエアを用いて実現された。しかし、当業者には、これらの特徴のいずれもハードウエアまたはハードウエアとソフトウエアの組合わせを用いて実現されることが無論明らかであろう。更に、ハードウエア、コンピュータ・ソフトウエアなどにより行われるファンクションが電気信号などにおいてあるいはこれを用いて行われることが容易に理解されよう。
情報の記憶に関する特徴は、適切な記憶場所またはストアによって実現されよう。情報の処理に関する特徴は、ソフトウエアまたはハードウエアにおいて、あるいは両者の組合わせにおいて、適切なプロセッサあるいは制御手段によって実現されよう。

上記のいずれかあるいは全てにおいて、本発明は、下記の形態のいずれか、あるいは一部、あるいはその全てにおいて具現され、すなわち、本発明は、コンピュータ・システムを動作させる方法において具現され、コンピュータ・システム自体において具現され、コンピュータ・システムを動作させる方法を実行するようプログラムされあるいは実行するようになされたコンピュータ・システムにおいて具現され、および（または）コンピュータ・システムを動作させる方法に従って動作するようになされたプログラムが記録されたコンピュータ読取り可能な記憶媒体において具現されよう。
本文において用いられるように、用語「コンピュータ・システム」は、「コンピュータ」、「システム」、「装備」、「装置」、「マシン」などの用語と互換であり得る。コンピュータ・システムは、仮想マシンであり得、あるいは仮想マシンを含み得る。
上記のいずれかあるいは全てにおいて、方法および装置の特徴および特質を含む上記の異なる特徴および特質は、任意の適切な方法で組合わされよう。
本発明が本文において純粋に事例として記述され、細部の修正が本発明の範囲内で可能であることが理解されよう。
本文の記述、および（適切な場合に）請求の範囲および図面において開示された各特徴は、独立的に、あるいは任意の適切な組合わせにおいて提供されよう。

エージェント資料第１１−コンピュータ・システム、コンピュータ読取り可能な記憶媒体および同媒体を動作させる方法、および前記システムを動作させる方法
本発明は、特定仕様の特定のｉｐｌであるコンピュータ・コードのテストに関する。望ましい実施の形態においては、本発明は、自動テストおよび仮想マシンにおける動的にコンパイルされたコードの検証のための方法に関する。
動的にコンパイルされたコードにおけるエラーは、エラーが実際に生じた後も長い間しばしば顕われて、真の原因を識別することを困難にする。エラーは、これが生じるとき良性に見える（例えば、すぐに使用されない誤った計算）が、その影響は招来のある時点またはイベントにおいて（例えば、正しくない値が使用されるとき）ひどいことになるおそれがある。
ダイナミック・コンパイラに対する最適化を変更および（または）付加するとき、結果として生じたコードが正しいことを立証するのは難しい。従って、本発明は、このようなエラーについてテストすることに関する。

１つの公知手法において、このようなテストは順方向では行われなかった。その代わり、エラーが判ったとき、プロセスはエラーの出所を見つけるため逆方向い調べられることになる。このような手法は、明らかに、遅すぎるまで生じる潜在的にひどい結果となるエラーを気が付かないでいるリスクに通じるものであった。
先に述べたばかりの手法についての改善である別の公知の手法では、２つの実行エンジンが同じプロセス内で用いられ、その結果が比較される。１つの実行エンジンは信用さ成果構成（マスタ）であり、他方はテスト中の成果（スレーブ）である。このテスト・プロセスは、１つのスレッドのあるアプリケーションに限定され、実行エンジンを逐次走らせねばならないため、かさ高であると共に時間がかかるものであり得る。このプロセスは、初期の状態（状態１）をセーブし、マスタの一部を走らせ、マスタの最終状態（状態２）をセーブし、状態１を復元し、スレーブの一部を走らせ、次いでセーブされた状態２に対してスレーブの最終状態を調べて矛盾を検出するものである。
（インシニア社の）Ｓｏｆｔｗｉｎｄｏｗにおいて実現されるテスト手法は、今概要を述べたばかりのタイプのものであった。その目的のためには有効であっても、この手法は単一のスレッド環境にのみ適応し得ること、およびＣＰＵエミュレータに用いられるとき、ただ大きいだけの実行能力を持つものであったことにおいて、限定されたものであると言うのが順当であろう。マスタおよびスレーブに対するこの実行能力は、逐次行われねばならないテストと同じ実行能力にあった。更に、このテスト手法は、マスタとスレーブ間に自らバグおよび不統一性をもたらし得る。状態の比較がなされた点は、たかだか制御の移転に過ぎないものであった。
いったん識別されたエラーの原因を識別するための手法は、テスト中のシステムをしばしば障害の挙動を変更しあるいは（一時的に）取除く程度に混乱させる傾向がある。従って、本発明の目的は、望ましくはダイナミック・コンパイラにより生じた実行可能コードの各部をテストするための、より迅速でより信頼し得るシステムおよび方法を提供することである。
アンチ・アリアシングの第１の特質は、別の成果であるコンピュータ・コードの第２の部分に対し特定仕様の成果であるコンピュータ・コードの第１の部分をテストする方法を提供し、該方法は、コードの両部分における対応同期点を規定し、コードの両部分を実行し、同期点におけるコードの両部分により生じる状態を比較するステップを含んでいる。
多くの場合、コードの第１の部分は仕様の信用される成果（マスタ）であり得るが、コードの第２の部分はテスト中の成果（スレーブ）であり得る。
生じた状態において矛盾が見出されると、この矛盾は、前の同期点以降にコードの２つの部分により生じた挙動が異なっていることを示す。最後の同期点以降にスレーブにより実行されたコードは、容易に識別することができる。
矛盾が見出されると、この矛盾は、コードの１つ（あるいは、おそらくは両方）の部分がエラーを含むことを示す。このエラーは、これが単に新しく、更に複雑でかつ信用されるマスタよりテストされ易くないゆえに、一般にスレーブにおいて見出されるが、この方法は、スレーブが正しいかあるいは少なくとも別の点で正しくないものとすれば、信用されるマスタにおけるエラーを識別し得る。
コードの第１および第２の部分がそれぞれ第１および第２の異なる実行能力により、例えば、別のアドレス・システムおよび別のスタックを持つマシンにより実行されることが望ましい。

本発明のこのような特質は、コードの第１および第２の部分がそれぞれ第１および第２の異なる仮想マシンにより実行されるときに特に適用し得、これにより効率性を高める。仮想マシンは、必ずしも同じアーキテクチャおよび（または）オペレーティング・システムを用いる必要がない。システムは、独立的なプロセスを働かせることができ、かつ任意に同時的であり得る。
コードの第１および第２の部分がそれぞれネイティブな方法またはファンクションを含む場合は、コードの第２の部分により要求されるこのようなネイティブな方法またはファンクションの少なくとも１つが第１の実行能力（例えば、マスタ）により実行され、その結果は第２の実行能力へ戻される。この場合は、方法が第１の実行能力から第２の実行能力へ第１の実行能力により実行されるべきこのようなネイティブな方法またはファンクションのリストを与えるステップを更に含むことが望ましい。
コードの第１の部分における各同期点における比較ステップにおいて、第１の実行能力（望ましくは、マスタ）が、コードの第２の部分における対応する同期点において第２の実行能力の状態を調べる。コードの第２の部分における同期点ごとに、第２の実行能力（望ましくは、スレーブ）が最新のものでないその状態要素の少なくとも一部の値をセーブし、これらの状態要素の値を更新し、その状態要素の値を第１の実行能力へ移し、それから更新された状態要素のセーブされた値を復元する。
効率を増すために、コードの第１および第２の部分は並列に実行されることが望ましい。
本発明のこのような特質は、動的にコンパイルされるコードの各部に対して特に適用し得る。

同期点は、制御の条件付き移転、方法／ファンクション／手順または戻り、および制御の逆方向の移転から選択されることが望ましい。
コードの第１および第２の部分がそれぞれ実行の複数のスレッドを有する場合は、コードの第１および第２の部分により生じる対応するスレッド間に対応が識別されることが望ましく、このような場合、対応する同期点はこのような対応するスレッドにおいて規定されることが望ましい。
プログラミング言語がジャバであり、同期がスレッド単位で行われることが望ましい。特に、複数の非同期的に処理されるスレッド対があることが望ましい。
また、コードの第１および第２の部分により動的に割付けられる対応するオブジェクト間に対応が識別されることが望ましい。
本発明の第２の特質は、本発明の第１の特質の方法を行うようプログラムされたコンピュータ・システムを提供する。
本発明の第３の特質は、対応する同期点がコードの両部分において規定される同じ仕様の異なる実現であるコンピュータ・コードの第２の部分に対して特定仕様の実現であるコンピュータ・コードの第１の部分をテストするコンピュータ・システムを提供し、該システムは、コードの両部分を実行する手段と、同期点におけるコードの両部分により生じる状態を比較する手段とを含む。
本発明の第４の特質は、対応する同期点がコードの両部分において規定される同じ仕様の異なる実現であるコンピュータ・コードの第２の部分に対して特定仕様の実現であるコンピュータ・コードの第１の部分をテストするコンピュータ・システムを提供し、該システムは、コードの第１の部分を実行する第１の実行能力と、コードの第２の部分を実行する第２の実行能力とを含み、該第１の実行能力が同期点におけるコードの両部分により生じる状態を比較するようにも動作可能である。
本発明の第４の特質において、第１および第２の実行能力は、それぞれ第１および第２の異なる仮想マシンにより提供されることが望ましい。
本発明の第３または第４の特質による装置は、本発明の第１の特質の方法を行うようにプログラムされることが望ましい。
本発明の第５の特質は、特定仕様の実現であるコンピュータ・コードの第２の部分と、対応する同期点がコードの両部分に規定される同じ仕様の異なる実現であるコンピュータ・コードの第２の部分とが記録されたコンピュータの記憶媒体を提供する。

本発明の第６の特質は、コンピュータ・システムに本発明の第１の特質の方法を実施させあるいは本発明の第２ないし第４の特質のいずれかに従って動作させるプログラムが記録されたコンピュータの記憶媒体を提供する。
特に仕様がジャバ・バイト・コードに対する実行エンジンである場合は、２つの成果が異なる仮想マシン（ＶＭ）へ構築されることが望ましい。信用される成果を含むＶＭはマスタＶＭと呼ばれ、テスト中の成果を含むＶＭはスレーブと呼ばれる。両方のＶＭは、同じアプリケーションを実行し、仮想マシンの状態を交換して比較するため既知の同期点で相互に通信する。
上記システムおよび方法において、同期点がコードの長さに（および、望ましくはこれに比例して）（少なくとも部分的に）従って選択されることが望ましい。このことは、テスト中でないときなどに同じ最適化を行う最良の機会をダイナミック・コンパイラに与え、従って律動を減じる。
本発明の特定の実施の形態においては、スレーブＶＭは最小限の律動を生じ、障害のある挙動を変化させる可能性を減じる。また、各実現により操作される状態は、他の実現により操作される状態とは独立している。更に、スレーブＶＭは、本発明に対して少ない余分なリソースを要求し、その安定性を増加する。
本発明の実施の形態においては、スレーブＶＭにおけるテストされない実現における負担は低減される。明らかなように、テストされない実現における負担は、これも以下に述べる同期点における最終状態で信用される実現へ単に移転される。テストされない実現は、能動的な役割を演じるのではなく、有効に受動的になり、信用される実現により要求される如きデータのみを信用される実現へ送る。両方の実現は同じ初期の状態で始動し、従って同期点は予測し得る。更に、信用される実現は通常、強力な目標マシン上で走り、その結果マスタＶＭは重装備となり得るが、テスト用の実現は比較的小さな、おそらくは手持ち型の目標マシン上で走らせ得る。通常は、スレーブＶＭが走らせられる目標マシンへマスタＶＭをポートする必要はない。
本発明はまた、同じ仕様の別の実現に対して特定仕様の１つの実現をテストする方法を提供し、該方法は、
両方の実現における対応する同期点を規定し、前記１つの実現と前記類似の実現とを実行し、同期点においてコードの両部分により生じる状態を比較する
ステップを含んでいる。
本発明はまた、特定仕様の１つの実現を同じ仕様の異なる実現に対してテストするコンピュータ・システムを提供し、該システムは、両方の実現における対応する同期点を規定する手段と、実現を実行する手段と、同期点において両方の実現により生じる状態を比較する手段とを含んでいる。
本発明の任意の特質の特徴のいずれか、あるいは部分、あるいはその全てが、他の任意の特質に対して適用し得る。
本発明の望ましい特徴については、純粋に事例として、添付図面に関して次に記述する。
当該方法は主としてジャバの仮想マシンに対して開発されたが、使用される手法は更に一般的に適用し得る。当該テスト手法の実現におけるコード・バッファ形態およびコード断片をそれぞれ示す図１１Ａおよび図１１Ｂを参照する。
同期点の選択
両方のＶＭは、同じ同期点を使用しなければならない。適切な選択は、下記の全てまたは一部を含むことができる。すなわち、制御の条件付き移転、方法／ファンクション／手順の呼出し、方法／ファンクション／手順の戻し、および制御の逆方向の転送である。

同期点の選択については、以下の項「スレーブ仮想マシン」において更に論述される。
仮想マシンが動的に割付けされるオブジェクトをサポートするならば、マスタＶＭおよびスレーブＶＭは、対応するオブジェクトがそれぞれのＶＭにおいて識別されることを保証しなければならない。
仮想マシンが多数のスレッドをサポートするならば、マスタＶＭおよびスレーブＶＭは、対応するスレッドが各ＶＭにおいて識別されること、および各スレッドが独立的に同期されることを保証しなければならない。
仮想マシンがネイティブな方法またはファンクション（すなわち、仮想マシンの実行エンジンを介してではなく、直接的に実行されるもの）をサポートするならば、大半はもっぱらマスタおよび戻り値において実行されねばならず、任意の必要な副作用はスレーブへ送られねばならない。例えば、時刻を返すネイティブなファンクションは、つねにマスタ上で実行されることになる。これは、２つの異なるマシン（この文脈においては、ＶＭ）上で走るクロックが正確に同期していたならば、実際にまれなイベントであるゆえであり、複雑なテスト手法におけるこのような矛盾に供するのは無意味な高価なふるまいとなるゆえである。一方、仮想マシンから抜けさせるネイティブなファンクションは、マスタとスレーブの両者で実行されるべきである。これらの基本的な注意が然るべく払われなければ、スプリアスな同期エラーが生じ得る。マスタは一般にこれだけが行い得るファンクションのリストを含み、これがスレーブに対して、スレーブがこのファンクションを走らせることを許容されたかどうかを知らせ、あるいはもしそうでなければ、他の動作を行うことを必要とするものを知らせる。ジャバの仮想マシンの場合は、ネイティブな方法がジャバで書かれた方法における呼出しを行う。ネイティブな方法自体が両方のＶＭ上で実行されているか、あるいはもっぱらマスタで実行されているかのいかんに拘わらず、このようなジャバ方法は両方のＶＭにおいて実行されねばならない。

マスタ仮想マシン
マスタの（信用される）仮想マシンは、仮想マシンの状態の全ての読みと仮想マシンの状態の全ての修正を記録するため重装備である。
各実行スレッドは、スレーブＶＭにおける対応する実行スレッドと独立的に同期する。基本的な同期ループが、下記の先頭のプレスレッド同期ループに示される。
プレスレッド同期ループ

マスタは、その同期ループを状態情報のデータベースをクリヤすることによって始動する。この同期ループは、次の同期点へ走り、その状態情報データベースに仮想マシンの状態のどのアイテムがいつ書込されあるいは書込まれるかを追加する。任意の読出し時、および任意の書込みの前後におけるアイテムのタイプおよび値がセーブされる。
同期点において、マスタが前の状態「ＳＢ」メッセージをスレーブへ送り、スレーブがいったん対応する同期点に達すると対応する後の状態（ＳＡ）メッセージをスレーブから受取るまで待機する。マスタがＳＡメッセージをスレーブから受取ると、マスタは、前の同期点が正しいタイプと値を持って以来全ての仮想マシンの状態アイテムがスレーブにより書込まれたことを調べる。どれかのアイテムが正しくなければ、エラーをユーザに対してただちに送るかあるいは後の検査のためバッチすることができる。次に、マスタは同期ループの次の繰返しへ進むことができる。

マスタ・ループに対する最適化は、スレーブからのＳＡメッセージを待つのではなくＳＢメッセージの直後にこのループをその次の同期ループへ続けさせることである。この待機は、待機が非常に少なくなりおそらくはゼロになることを期待して、マスタがその次のＳＢメッセージを送る用意ができるまで延ばすことができる。更なる最適化は、スレーブを待たねばならない前に幾つかの同期ループを走らせることができるように、マスタが幾つかのＳＢメッセージのバッファを保持することである。これらの最適化は、マスタの同期ループがスレーブよりも遅くなりがちであるので、価値がある。マスタの実行エンジンは、典型的に、スレーブの実行エンジンよりも非常に遅い実現であり、更に本発明のコストの大半となる。
多くの実施の形態において、マスタはコードの実行のためインタプリタを使用する。ダイナミック・コンパイラをスレーブＶＭにおいてテストすることができる。あるいはまた、マスタとスレーブはともに、コードのコンパイルされたバージョンを走らせることができ、あるいはともに、例えばスレーブＶＭにおける新たなインタプリタをテストするためコードを解釈することもできる。

スレーブ仮想マシン
スレーブ仮想マシン（テスト中のＶＭ）は、前の同期点以来書かれた状態アイテムのタイプおよび値を集めてマスタへ送るることができるように、その仮想マシンの状態を最新の状態に保持し、あるいは同期点で容易に更新可能に保持しなければならない。スレーブの通常の動作モードに対する摂動を最小化する方法で、このような要件が実現されることが非常に重要である。スレーブが最適化ダイナミック・コンパイラを含むときは、通常の動作において生じるコードに比してテストするとき異なるコードを生じないことが特に重要である。
これは、コンパイル・コードが正しい場所になければ必要な状態を利用可能にし易いときと一致するよう同期点の慎重な選択の組合わせ、および同期点においてダイナミック・コンパイラにコードの特殊な断片を生成させて、まだ最新でない任意の状態アイテムの内容をセーブし、これらアイテムを更新し、ＳＡメッセージを生成して送り、最後に同期点に対して特に更新されたこれら状態アイテムのセーブされた内容を復元することによって達成することができる。
同期点に対する望ましい選択については、すでに述べた。しかし、制御の各移転が必ずしも同期点として選択される必要がないことを更に述べねばならない。バイト・コードの各点を用いることも可能であるが、摂動のリスクも増加される。同期点の選定における重要な特徴は、これら同期点がその時の状態が例えば全ての要素がそれらの本来の状態にある場合に容易に識別できるか、あるいはその状態に容易に置くことができる点でなければならないことである。通常は、ある部分内の要素の順序が実行の結果として変更され、スレーブとマスタの実現に対する共通の参照点がなくなるので、実行の部分内の点を選定することはできない。同様に、同期点は、エラーがこれら同期点間のコードの集まりが、エラーがその集まりにおいて生じるならば、有効な検査にはおそらく大きくなり得るので、あまりかけ離れて選択してはならない。
これらの理由から、同期点において、実行が「ピグライヤ（ｐｉｇｌｉｅｒ）」と呼ばれるコードの別の断片へ外れることが望ましく、そのファンクションは必要な状態を更新することである。同期およびデータの必要な移転がいったん完了すると、ピグライアは更新に遭遇し、コンパイル・バージョンへ戻る。この状態においては、バグがコンパイル・バージョンへインポートされあるいはこれから除かれることがないことが重要である。
典型的なコード・バッファの形態が図１１Ａに示され、同図において、その左側が全般的な概略を示し、右側は同期点周囲に含まれるコード・バッファの内容を示している。

断片７１００は、コード・バッファ７１０２の一端部に生成され、アウトライア（ピグライア）７１０４は他端部に生成される。
コードの生成時に、コンパイラが、同期点を検出するまで、断片コードを通常のように配置する。コンパイラは、その状態をこの点にセーブし（すなわち、図１１Ａにおける「ダイナミック・コンパイラの状態Ａ」）、次いでピグライア７１０６自体およびこれに対するジャンプ（すなわち、「ＪＭＰピグライア」）を配置する。ピグライア７１０６に対して配置されたコードは、最新ではないがこの同期点に対するものである必要があるＶＭ状態要素をその時の内容を除いてセーブするコード、これらの状態要素を更新するコード、ＳＡメッセージを送るファンクションに対する呼出し、ＶＭの状態要素の前の内容を復元するコード、およびセーブされたコンパイラの状態（ダイナミック・コンパイラの状態Ａ）を復元するのに必要な任意のコードからなる。例えば、同期点が所与のレジスタにおける特定の値を持つ前の断片コードおよびピグライア・コードがレジスタにおける値を変更すると、あるコードが前記レジスタの元の値を復元するように配置される。ピグライア７１０６に配置された最後のコードは、「ＪＭＰピグライア」命令に続く断片コードへ戻るジャンプである。
同じプロセスであるがこの時は断片に関して表わされるプロセスが、ピギング状態がない場合とピギング状態がある場合の状態で図７Ｂに示される。このような概略図から判るように、同期点ＳＰのいずれかの側のコード部分はＢおよびＣで示される。「ピギング状態でない」場合は、コード生成時のＳＰにおけるダイナミック・コンパイラの状態は、「ダイナミック・コンパイラ状態Ｒ」と呼ばれる。「ピギング状態」の場合は、ダイナミック・コンパイラは、コード部分ＢおよびＣが「ピギング状態でない」場合にそれぞれ生成されるコード部分ＢおよびＣと同じにるように、従って「ピギング状態」の場合におけるピグライア・コードの生成の前と後の両方のダイナミック・コンパイラの状態が「ピギング状態でない」場合における同期点ＳＰにおける「ダイナミック・コンパイラ状態Ｒ」と同じになるように、コードを生成しなければならない。このことは、生成されたコードが実行されるときピグライアの実行が実質的にトランスパレントであり生成された断片コードにおける副作用がないことを保証する。
ピグライアが行内で実現されることがあり得るが、デバッグを試みるときは役にたたず、エラーが生じた同期点間のコード部分を識別して調べることを更に困難にするので、望ましい選択ではない。
ピグライアにおいてなされる処理が多くなるほど、状態を復元することが難しくなることが一般的である。また、同期点が頻繁になるほど、エラーの生じる可能性が大きい場合に最適化をオフにすることなく同じコードを走らせることが困難になる。
同期点に対する望ましい選択は、制御の前後両方向における、また任意に呼出し点における、条件付き移転である。これは、ファンクション／方法を戻すためには望ましいことではない。

多重スレッデイング発行
仮想マシンが多重スレッドであるならば、マスタおよびスレーブのＶＭは各実行スレッドを個々に同期させる。これらＶＭは、両方のＶＭにおける対応する実行スレッドを識別し、かつスレッドのような重要点においてメッセージを交換し、状態の変化と生成を監視する方法を持たねばならない。
同期に関しては、所与の開始スレッドがあり、従ってマスタおよびスレーブにおける開始条件が判る。別のスレッドの生成時のスレッドの挙動は、スレッドの生成／停止の順序のように予測し得る。従って、マスタとスレーブ間のメッセージの交換がスレッドの始動点で生じることが可能である。
マスタ・スレッドＡがスレッドＢを生成するとき、スレーブにおける対応するスレッドＡが生じる次のスレッドがＢでもある（あるいは、Ｂでもあるべき）ように、情報がスレーブへ送られる。マスタ（および、スレーブ）は、マスタ・スレッドのアイデンティティ（例えば、「スレッドＢはすなわち５」）と、メッセージの交換のため使用することができるスレーブ・スレッドのアイデンティティ（例えば、「マイスレッドＢはすなわち５」）とを含むテーブルを作成する。同じ原理が、オブジェクトの生成のために用いられる。マスタおよびスレーブ間に送られるＳＡおよびＳＢのメッセージは、送る側のスレッドのアイデンティティを含まねばならない。

通信機構
当該方法に要求される通信は、任意の適切な駆動機構、例えばソケットまたはネームを付したパイプの先頭において実現することができる。
信用される実現に対して用いられるＶＭがピギングをサポートするため特に構築されたＶＭであることが望ましい。ＶＭはピギング以外に用いることができるが、一般に速度が遅くなる。テスト中実現のため用いられるＶＭがピギングおよびピグライアをサポートするため特に構築されたＶＭであることが望ましい。
上記のいずれかあるいは全てにおいて、本発明の幾つかの特徴がコンピュータ・ソフトウエアを用いて実現された。しかし、当業者には、これらの特徴のいずれもハードウエアあるいはハードウエアとソフトウエアの組合わせを用いて実現されることが無論明らかであろう。更に、ハードウエア、コンピュータ・ソフトウエアなどにより行われファンクションが電気信号などにおいてあるいはこれを用いて行われることが容易に理解されよう。
情報の記憶に関する特徴は、適切な記憶場所またはストアにより実現されよう。情報の処理に関する特徴は、ソフトウエアまたはハードウエアにおいて、あるいは両者の組合わせにおいて、適切なプロセッサまたは制御手段によって実現されよう。
上記のいずれかあるいは全てにおいて、本発明は、下記の形態のいずれか、あるいは一部、あるいはその全てにおいて具現され、コンピュータ・システムを動作させる方法において具現され、コンピュータ・システム自体において具現され、コンピュータ・システムを動作させる方法を実行するようプログラムされあるいは構成されるときコンピュータ・システムにおいて具現され、および（または）コンピュータ・システムを動作させる方法に従って動作するためのプログラムが記録されたコンピュータ読取り可能な記憶媒体において具現されよう。
本文に用いられるように、用語「コンピュータ・システム」は、「コンピュータ」、「システム」、「装備」、「装置」、「マシン」などの用語と互換であり得る。コンピュータ・システムは、仮想マシンであり得、あるいは仮想マシンを含み得る。
上記のいずれかあるいは全てにおいて、方法および装置の特徴および特質を含む上記の異なる特徴および特質は、適切な方法において組合わせされよう。
本発明が本文において純粋に事例として記述され、細部の修正が本発明の範囲内で可能であることが理解されよう。
本文の記述、および（適切な場合）請求の範囲および図面において開示された各特徴は、独立的に、あるいは任意の適切な組合わせにおいて提供されよう。

エージェント資料第１２─コンピュータ・システム、コンピュータ読取り可能な記憶媒体および同媒体を動作させる方法、および前記システムを動作させる方法
本発明は、１つの特質において、コンパイル・コードの第１の部分からコンパイル・コードの第２の部分までリンクを生成する方法と、コードをコンパイルする方法とに関するものである。本発明は、別の特質において、コンパイル・コードの一部を削除することを許容するためコンピュータ・システムにおけるメモリを調べる方法および装置に関し、かつ特にコンパイル・コードの各セクション間にリンクが存在する場合にコンピュータ・システムにおいてコンパイル・コードを削除する方法および装置に関する。本発明は、自己修正する多重スレッド環境に対する特定の（これに限定しないが）用途を有する。望ましい実施の形態においては、本発明は、多重スレッド型の断片パッチングに関する。

自己修正環境は、コンパイル・コードのセクションが実行中に動的に作成され削除される環境である。このような環境は、エージェント資料第１に記載されている。多重スレッド環境は、幾つかのプロセスすなわちスレッドが同じ作業スペースにおいて非同期的に動作する環境である。
自己修正環境においては、コードの２つの部分間に実行の移転を可能にするため、コンパイル・コードの第１のセクションと作業スペースのどこか他の場所に置かれるコンパイル・コードの第２のセクション間にリンクが作られねばならない状況があり得る。コードの１つの部分から他の部分へ実行を移転するプロセスは、一般に、レジスタ値と共にスタックにおけるコードの第１の部分のアドレスを置き、コードの第２の部分の場所を識別するコードの中間部分へ実行を移転し、次いでコードの第２の部分へ実行を移転する多くのステップを呼出す。このように実行を移転することの問題は、比較的多くの時間が移転の実施に費やされることである。
本発明の第１の特質において、自己修正多重スレッド型コンピュータ・システムにおいてコンパイル・コードの２つの部分間にリンクを設ける方法であって、コンパイル・コードの１つの部分から他の部分へパッチを挿入することを含む方法が提供される。
コンパイル・コードの１つの部分から他の部分へパッチを提供することにより、パッチが作らなかった場合より迅速に実行が移転することができる。
パッチを挿入するステップは、コンパイル・コード内の制御移転命令を変更することを含む。制御移転命令は、ジャンプ命令または呼出し命令のような、実行を別のアドレスへ移転させる任意の命令でよい。この制御移転命令は、パッチが行われるコードの部分のアドレスを指示するように変更することができる。
制御移転命令の変更ステップは、アトミックに行われる。アトミックにとは、他のスレッドが部分的に変更される形態において変更される領域を見ることができないことを意味することが望ましい。これは、パッチを挿入するステップが１つの書込み動作として行われることを保証することにより、単一プロセッサ・システムにおいて達成される。あるいはまた、一部のプロセッサは、アトミック性を保証するよう定義される１つ以上の特殊な命令あるいは一連の特殊な命令を提供し、このような命令は単一プロセッサ・システムおよび多プロセッサ・システムにおけるアトミック性を保証するため用いられる。このように、作業スペースに影響を及ぼすかも知れない他の任意の動作が行われる前にパッチの操作が完了することを保証することができる。
本発明の第１の特質は、自己修正多重スレッド型コンピュータ・システムにおいてコンパイル・コードの２つの部分間にリンクを設ける装置であって、コンパイル・コードの１つの部分から他の部分へパッチを挿入する手段を含む装置をも提供する。

本発明の第１の特質は、実行の２つのあり得るパスを含むコードをコンパイルする方法であって、実行パスの１つに対応するコードをコンパイルすることを含み、コンパイルされたコードにおいてコードの別の部分のアドレスを指示するようにアトミックに変更することができる制御移転命令を含む方法をも提供する。
このように、特に他のパスを実行することを可能にするため、コンパイル・コードは、コードがコンパイルされた後に、コードの別の部分に対するパッチを行うことができるように構成することができる。
制御移転命令は、この制御移転命令の最も最適な形態が用いられた場合よりもそれ自体のアドレスとは更に別のアドレスを指示できるタイプであることが望ましい。このような特徴は、パッチが他の場合よりも離れたコードの部分にさせ得る。
当該方法は、制御の転送命令を含むコードの外部のセクションを形成することを含む。
本発明の第１の特質はまた、コンパイル・コードの上記方法のいずれかを実施するためのコンパイラを提供する。
ある状況では、例えば、コンパイル・コードの部分を含むコード・バッファが削除されるゆえに、あるいはコンパイル・コードの部分の付近になされた場合に家庭が有効でないことを証明するゆえに、パッチを取除くことが望ましいかあるいは必要となる。
このため、本発明の第２の特質において、自己修正する多重スレッド型コンピュータ・システムにおけるコンパイル・コードのセクションを含むメモリを調べる方法であって、コンピュータ・システムに対するパッチを識別し、このようなパッチのいずれかを指向し直すことを含む方法が提供される。当該方法は、例えば、コンパイル・コードの１つのセクションが削除されるゆえに、あるいはコンパイル・コードのセクションがもはや使用されないゆえに、実施される。パッチの指向し直すことで、コンパイル・コードのセクションなしにパッチにおいて実行を持続することを可能にする。
本発明の第２の特質は更に、自己修正多重スレッド型コンピュータ・システムにおけるコンパイル・コードを削除する方法であって、削除されるコンパイル・コードのセクションを選択し、コンパイル・コードのセクションに対するパッチを識別し、このようなパッチを指向し直し、コンパイル・コードの部分を削除することを含む方法を提供する。
このようなパッチがコンパイル・コードのアドレスへ指向されることが望ましい。このコンパイル・コードは、コードのセクションなしに実行を継続することを可能にする。コードの継続は、以降の命令の解釈を行うように構成され、あるいはディスパッチ・テーブルの移転を行うように構成される。
パッチを指向し直すステップは、パッチ動作が部分的にのみ完了されるとき他のスレッドがパッチされる場所をアクセスできないことを保証するためアトミックに行われることが望ましい。代替的な解決法は、パッチが指向しなお割れた間に全ての実行するスレッドを停止させることであるが、これはスレッドが停止される間実行時間が失われるゆえにそれほど望ましくない。
コンパイル・コードの部分へゆくパッチを識別するために、当該方法は、コンパイル・コードのセクションのアドレスのハッシュ値を計算し、コンパイル・コードのセクションに対するパッチを識別するためパッチ・ブロックのハッシュ・テーブルを調べることを含む。
有効なメモリ使用の関心では、（コード・バッファからのパッチのような）使用されないパッチは削除されるべきであり、従ってパッチと関連するオーバーヘッドを再生することができる。従って、当該方法は、コンパイル・コードのセクション外のパッチを識別し、このようなパッチを取除くことを更に含むことが望ましい。
このため、本発明の第２の特質は、コンパイル・コードのセクションが削除されるべきとき自己修正する多重スレッド型コンピュータ・システムにおけるメモリを調べる方法であって、コンパイル・コードのセクション外のパッチを識別し、このようなパッチを取除くことを含む方法をも提供する。
メモリを調べる方法は更に、
コンピュータ・システムにおけるスタックのフレームを調べ、
削除されるコンパイル・コードのセクションのアドレスの範囲内にあるリターン・アドレスをフレームが含むかどうかを識別し、
このようなリターン・アドレスが識別されるとき、フレームの内容を変更する
ステップを含むことが望ましい。

このように、本発明の第２の特質は、コンパイル・コードのセクションを削除させるため自己修正する多重スレッド型コンピュータ・システムにおけるメモリを調べる方法であって、
コンピュータ・システムにおけるスタックのフレームを調べ、
コンパイル・コードのセクションのアドレスの範囲内にあるリターン・アドレスをフレームが含むかどうかを識別し、
このようなリターン・アドレスが見出されると、フレームの内容を変化し、
コンパイル・コードのセクションに対するパッチを識別し、
このようなパッチを指向し直す
ステップを含む方法をも提供する。
このように、本発明の第２の特質は、エージェント資料第６に記載される本発明の１つ以上の特質の１つ以上の特徴を含むことが望ましい。
当該方法は更に、コンパイル・コードのセクション外のパッチを識別し、このようなパッチを取除くことを含むことが望ましい。
フレームの内容の変更および（または）パッチの指向し直しが、例えば、削除されたコードへのパッチまたは戻りが実行中に見出されるときではなく、コンパイル・コードのセクションの削除の時間に行われることが望ましい。
本発明の第２の特質は、自己修正する多重スレッド型コンピュータ・システムにおけるメモリを調べる装置であって、コンパイル・コードの部分に対するパッチを識別する手段と、このようなパッチを指向し直す手段とを含む装置をも提供する。このように、実行は、コンパイル・コードのセクションのないパッチにおいて継続する。
本発明の第２の特質は、自己修正する多重スレッド型コンピュータ・システムにおいてコンパイル・コードを削除する装置であって、削除されるコンパイル・コードのセクションを選択する手段と、コンパイル・コードのセクションに対するパッチを識別する手段と、このようなパッチを指向し直す手段と、コンパイル・コードのセクションを削除する手段とを含む装置をも提供する。
当該装置は、コンパイル・コードのセクションのアドレスのハッシュ値を計算する手段と、コンパイル・コードのセクションに対するパッチを識別するためパッチ・ブロックのハッシュ値を調べる手段とを含むことが望ましい。
当該装置は更に、コンパイル・コードのセクション外のパッチを識別する手段と、このようなパッチを取除く手段とを含むことが望ましい。
本発明の第２の特質は、コンパイル・コードのセクションを削除させるため自己修正する多重スレッド型コンピュータ・システムにおいてメモリを調べる装置であって、コンパイル・コードのセクション外のパッチを識別する手段と、このようなパッチを取除く手段とを含む装置をも提供する。
１つの特質の特徴は他の特質に適用され、同様に、方法の特徴は装置に適用され、およびその逆も真である。
本発明の望ましい特徴については、純粋に事例として、添付図面に関して次に記述する。

下記の考察は、先に述べた本発明のいずれかおよび全て、および本発明の特質に適用する。
エージェント資料第１に記載されるように、ダイナミック・コンパイルが、方法全体ではなくコンパイルされる方法においてコードの断片を結果として生じる。コンパイルされる当該断片は、例えばソース・プログラムのランタイム表示および実行履歴情報から決定されるような主パスに対応する。以降の段階において、コードの他の断片は、例えば、主パスについてなされた元の仮定が正しくないことを証明する場合にコンパイルされる。
一例として、コードが条件付き制御移転命令（条件付き分岐命令または条件付き呼出し命令のような）を含むならば、コンパイラは、移転が行われ易いかどうかを判定し、次いで最も後続し易いパス（主パス）に対応するコードをコンパイルする。しかし、実行中は、実際には他のパスによるべきものと判定される。このような状況においては、移転命令に遭遇すると、実行は「グルー・コード」として知られるコードの部分へ移る。追従されるパスがコンパイルされなかったならば、グルー・コードがとられるべきパスにおける以降の命令の解釈を生じる。解釈されたパスがある回数だけ追従されると、コンパイラがコードの部分がコンパイルの価値があるものと判定し、次いでコードのコンパイル・バージョンを生じることになる。
これにより、自己修正環境が生成され、これにおいては、コンパイル・コードの部分が実行中に動的に生成され（あるいは、削除され）る。このような環境は、典型的に、幾つかのプロセスが同じ作業スペースにおいて同時に動作する多重スレッド型である。
望ましい実施の形態によれば、このような状況では、コードの新たにコンパイルされるセクションへのコードの元のセクションにおける移転命令から、パッチが行われる。このパッチは、コードの新たにコンパイルされるセクションのアドレスへ直接コードを移転させるように、転送命令を修正する。パッチが行われることを許容するため、コンパイルの時点において、必要ならば、パッチが後の段階で挿入できるようにコンパイル・コードが構成される。これは、例えば、元のコンパイル・コードに対して必要であるよりも長い形態の移転命令をコンパイルすることによって行われ、コードの更に離れた部分への転送を後の段階で行わせる。
パッチはまた、必要ならば、コードの新たにコンパイルされるセクションから再びコードの元のセクションに対しても行われる。
多重スレッド環境においては、先に述べたようなパッチングがアトミックに、すなわち単一命令として行われる必要があり、従って他のスレッドが複数の変更形態において変更される領域を見えないことに注意すべきである。従って、コードは、パッチをアトミックに行うことができるように構成される。アトミック性を保持するため、パッチングは１回の書込み操作として行うことができる。あるいはまた、あるプロセッサは、アトミック性を保証する１つ以上の特殊な命令または一連の特殊命令を提供する。多プロセッサ環境においては、パッチされる場所のアドレスは、おそらくは、多くのプロセッサにおいて、（アドレスが動作サイズの整数倍になるように）パッチ・データのサイズに従って整合されることを必要とする。

次に第１の事例について、図１２Ａおよび図１２Ｂに関して記述する。この事例は、非ネイティブ・コードが呼出し命令を含む場合に関する。
図１２Ａにおいて、第１のコード部分２３００２は、アドレスａａａに呼出し命令２３００３を有する。元の非ネイティブ・コードでは、この呼出し命令はサブルーチン「バー」を呼出した。コンパイルの間、このサブルーチン「バー」は、（例えば、バーのどのバージョンが使用されるかが確かでなかったゆえに）コンパイルされなかったが、その代わり、バーが呼出される状況を処理するため外部コード２３００４の部分が作成された。呼出し命令２３００３は、外部コードにおけるアドレスａｂｄを指す。このアドレスでは、実行をグルー・コードの部分へ移す呼出し命令２３００５が存在する。グルー・コードは、バーのコンパイル・バージョンが存在しなければ、サブルーチン・バーを翻訳させる。このため、呼出し命令２３００３が実行されると、グルー・コードが呼出される。
次に図１２Ｂにおいて、ある後の時点に、サブルーチン・バーがコンパイルされる。バーのコンパイル・バージョンは、当例ではアドレスｘｙｚにコンパイル・コード２３００６として格納される。次に、パッチ２３００８は、直接にあるいは外れたコード２３００４を介して、コード断片２３００２からコンパイル・コード２３００６に対して行われる。
図１２Ｂは、パッチが直接行われる場合を示している。この場合、呼出し命令２３００３が、直接アドレスｘｙｚを指すように変更される。これは、呼出し命令２３００３がアドレスｘｙｚにアトミックにパッチ可能である形態でコンパイルされたならば可能である。
図１２Ｃは、アウトライア２３００４を介してパッチが行われる場合を示している。この場合、アウトライアにおけるアドレスａｂｃのジャンプ命令２３００７がアドレスｘｙｚへジャンプするようにセットされ、呼出し命令２３００３はアドレスａｂｃを指すように変更される。あるいはまた、呼出し命令２３００３はアドレスａｂｃを恒久的に指すことができ、この場合は、ジャンプ命令２３００７が（グルー・コードを呼出すため）最初アドレスａｂｄを指し、次に（パッチを行うため）アドレスｘｙｚを指すように変更される。
いずれ場合も、アドレスｘｙｚを指すように変更される命令は、比較的離れたアドレスへの転送を許す長い形態である。このため、コードをコンパイルするとき、そのためのアローアンスがなされなければならない。例えば、呼出し命令２３００３は、この命令がアドレスａｂｄを指すだけの場合に必要なよりも長いバージョンになるようにすることができ、命令を将来における更に離れたアドレスを指すように変更させる。命令がこれが指すアドレスをアトミックに変更させ得るタイプであることもまた保証されねばならない。

サブルーチン・バーのコンパイル・バージョンの終りにおいて、戻り命令が制御を直接コード２３００２へ戻るよう移転させる。パッチがなされると、実行はコンパイル・コード２３００２からコンパイル・コード２３００６へ、またグルー・コードを必要とせずに再び戻るように移転し得る。
各パッチ時に、パッチに関する情報は、パッチが始まるコード・バッファ（メモリの領域）に記憶されるパッチ・ブロックに記録される。
図１２Ｄは、コード２３０１２の部分が条件付き分岐命令２３０１３をアドレスａａａに含む事例を示している。コンパイルの間、コンパイラは、分岐命令が続いて起こりにくいと判定し、従って元の（非ネイティブな）分岐命令が指示したアドレスにおける命令が完了しなかったと判定した。このような仮定が間違っている状況に対処するため、コンパイラはアウトライア２３０１４を挿入した。最初に、命令２３０１３がアウトライアにおけるアドレスａｂｄを指示する。このアドレスには、グルー・コードに対する呼出しが存在する。グルー・コードは、元の（非ネイティブな）分岐命令が指示したアドレスに命令を解釈させる。
後の段階において、例えばこれらの命令が実行されにくいという最初の仮定が正しくないことを証明したゆえに、分岐命令が指示する命令がコンパイルされる。これら命令のコンパイル・バージョンが、当例ではアドレスｘｙｚに示される。パッチは、直接アドレスｘｙｚのコンパイル・コードに対してなされる。これは、アドレスａｂｃのジャンプ命令をアドレスｘｙｚを指すように変更することにより、また命令２３０１３をアドレスａｂｃを指すように変更することによって行われる。あるいはまた、命令２３０１３は恒久的にアドレスａｂｃを指すことができ、このアドレスのジャンプ命令は最初にａｂｄを指すことができ、次にｘｙｚを指すように変更することができる。再び、コンパイル時に、パッチを行うように変更される命令は、パッチがアトミックに行うことができるようにセットアップされる。
このように、上記の手法の重要な特質が、パッチが後で挿入されるようにコンパイル・コードが構成されることであることが判る。これは、２つ以上の可能な実行パスがあり１つのパスのみがコンパイルされる場合、実行を比較的離れたアドレスへ移転するようアトミックに修正できる（呼出しまたはジャンプ命令のような）制御転送命令が存在することを保証することによって行うことができる。
先に述べたアウトライアもまた、コードのコンパイル・バージョンから制御を転送する前にレジスタおよび状態を更新するコードを含む。このようなアウトライアについては、エージェント資料第３に更に詳細に記載されている。
ある状況においては、行われたパッチを取除くことが望ましいか、あるいは必要である。例えば、ある段階では、コンパイル・コードの一部を含むコード・バッファを削除されることがある。これは、コード・バッファが他の場所で使用するため要求されるゆえか、あるいはコンパイルの間行われた仮定が妥当しないゆえである。また、特に制限されたメモリ環境で使用するときに、将来必要となることが予期されないコードを除去することが望ましい。コード・バッファに対するパッチが存在する場合、コード・バッファの削除は、すでに存在しないコードの部分に対するパッチを残すことになる。

コード・バッファの削除時に、バッファに出入りするパッチがあるかどうか知るために、コード・バッファが調べられる。コード・バッファに入るパッチは、例えば、パッチをグルー・コードまたはアウトライア・コードの部分へ送り直すことによって、バッファを削除することなく実行を継続させるように指向し直される。バッファから出されるパッチに関するデータ構造は、オーバーヘッドを再利用するために除去される。
先に述べたように、パッチが行われるとき、パッチに関する情報はパッチ・ブロックに格納される。各パッチ・ブロックは、これが関連するパッチの「から」アドレスおよび「へ」アドレスを与える。このパッチ・ブロックは、パッチが発生するコード・バッファにチェーンとして格納される。従って、各コード・バッファは、このブロックからのパッチに関してパッチ・ブロックのチェーンを有する。パッチ・ブロックは同時に、パッチがどれに対するものかに従って、第２のチェーン上で一緒に連鎖させられる。同時に、種々のチェーンに対するアクセスを許容するハッシュ・テーブルが維持される。ハッシュ・テーブルは、任意の機械的ファンクションに従って要素が分類される多数のブロックのチェーンからなるデータ構造である。ハッシュ・テーブルについては、エージェント資料第４に更に詳細に記述されている。
削除されるべきバッファへいくパッチを見出すために、ハッシュは（ハッシュ・テーブルと同じ数学ファンクションを用いて）、パッチがパッチ「へ」に関するパッチ・ブロックを含むチェーンを見出すために転送を生じるバッファのアドレスから作られる。チェーンにおけるパッチ・ブロックは、削除されるバッファに対するハッシュと関連するかどうかを知るために調べられる。このようなパッチ・ブロックが見出されると、これが関連するパッチが、例えばグルー・コードまたはアウトライア・コードの部分へ送り直され、パッチ・ブロック自体はチェーンから除去される。グルー・コードは、例えば、以降の命令の解釈により、あるいはコンパイル・コードの別の部分へジャンプすることによって、ある一般的な検査を行い、実行のフローの継続を生じるように意図される。グルー・コードの動作の更なる論議については、エージェント資料第１に見出すことができる。
削除されるバッファからのパッチが存在するかどうかも決定することができる。これは、先に述べた第１のチェーンを用いて削除されるバッファに格納されたパッチ・ブロックのチェーンを調べることによって行うことができる。このチェーンにおけるパッチ・ブロックが調べられ、まだ削除されていないパッチが存在するならば、このパッチが削除される。このように、パッチと関連するオーバーヘッドを再利用することができる。

図１２Ｅにおいて、コード・バッファが削除されるときパッチを除去する方法が示される。ステップ２３０２０において、あるコード・バッファが削除されるべきことが決定される。ステップ２３０２２において、バッファのアドレスについてハッシュが行われる。ステップ２３０２４において、パッチ・ブロックがハッシュ・テーブルの「への」チェーンから選択される。ステップ２３０２６において、パッチ・ブロックから、削除されるべきバッファに対するパッチ・ブロックが存在するかどうかが判定される。このようなパッチが存在するならば、ステップ２３０２８において、パッチが例えばグルー・コードの部分のアドレスへ再指向され、パッチ・ブロックがハッシュ・テーブルにおけるチェーンから除去される。ステップ２３０３０において、パッチ・ブロックがチェーンにおける最後のものかどうかが判定される。もしそうでなければ、パッチ・ブロックに対する選択およびテストのシーケンスが反復される。
コード・バッファに対する全てのパッチについてハッシュ・テーブルが調べられると、コード・バッファから出すパッチについて調べられる。ステップ２３０３２において、削除されるべきコード・バッファにおける「からの」（ジャンプ・ソース）チェーンからのパッチ・ブロックが選択される。ステップ２３０３４において、「への」バッファ・アドレスからハッシュが行われる。ステップ２３０３６において、当該パッチに対する「への」バッファに関するハッシュ・チェーンからパッチ・ブロックが除去される。ステップ２３０３８において、パッチ・ブロックが「からの」チェーンにおける最後のものであるかどうかが決定され、もしそうでなければ、全てのパッチ・ブロックが調べられるまで、チェーンにおける他のパッチ・ブロックに対するシーケンスが反復される。最後に、ステップ２３０３９において、コード・バッファが削除される。
別の事例において、コードが格納されるコード・バッファが削除されるからではなく、例えばコンパイルの間にされた仮定がもはや有効でないゆえにコンパイル・コードがもはや使用されないため、コンパイル・コードへの／からのパッチが除去される。例えば、潜在的にポリモルフィックな方法が最後であると仮定されたとき、およびパッチがこの方法のコンパイル・バージョンに対してなされたとき、この方法が最後でないことが後で発見されるならば、コンパイル・バージョンに対するパッチは除去されねばならない。これについては、エージェント資料第９を参照されたい。
図１２Ｆにおいて、コンパイル・コード２３０７２の部分がポリモルフィックである方法に対する呼出しを含む。呼出される方法は、最初にコンパイルされない。呼出し命令２３０７３は、外部コード２３０７４の部分におけるアドレスａｂｃを指示する。このアドレスには、グルー・コードに対する呼出しがある。グルー・コードは、方法のどのバージョンを使用するかを決定し、このバージョンを実行させる。

後で、当該方法が最後であるという仮定がなされ、この方法がコンパイルされる。方法のコンパイル・コードは、アドレスｘｙｚに示される。パッチ２３０７８は、方法のコンパイル・バージョンに対して直接なされる。これは、命令２３０７３をアドレスｘｙｚを直接指すように変更することによってなされる。コード２３０７２への戻り２３０７９が行われる。
更に後で、前記方法が最後のものであったという仮定が誤りであることが判る。このような状況においては、方法のどのバージョンが用いられるべきか確かでないため、パッチ２３０２８が除去される。次に、命令２３０７３がアドレスａｂｄを指すように変更される。このアドレスには、ディスパッチ・テーブルに対する呼出しがある。ディスパッチ・テーブルは、方法のどのバージョンが使用されるべきか、およびコンパイル・バージョンが存在するかを決定する。コンパイル・バージョンが存在するならば、実行はこのバージョンへジャンプし、もしそうでなければ、実行は方法を解釈させたグルー・コードへジャンプする。
コンパイル・コードを削除する手法は、エージェント資料第６に記載される「スタック・ウォーキング」手法、および（または）本文に述べた他の手法と組合わせて用いられる。
図１２Ｇに関して、当該実施の形態を実施する装置が記述される。図１２Ｇは、非ネイティブ・コード２３０４２をホスト・コンピュータ２３０４４上で走らせる仮想マシン２３０４０を含むコンピュータ・システムを示している。この仮想マシンは、制御手段２３０４６と、インタプリタ２３０４８と、コンパイラ２３０５０と、グルー・コード２３０５４と、削除手段２３０５６とを含んでいる。ホスト・コンピュータは、プロセッサ２３０５８と、コード・バッファ２３０６２を含むメモリ２３０６０とを含んでいる。コード・バッファ２３０６２は、コンパイラによりコンパイルされたコードを含む。コンパイラは、先に述べた方法のどれかでコードをコンパイルするためのものである。図１２Ｇにも示されるのは、コンパイル・コードの１つの部分から他の部分へパッチを挿入するためのパッチング手段２３０５５である。このパッチング手段２３０５５は、先に述べた方法のいずれかでパッチを行うためのものである。
動作において、制御手段２３０４６は、あるとき、コード・バッファ２３０６２が削除されるべきことを決定する。この制御手段は、先に述べた方法で、ハッシュ・テーブル２３０５２を調べてコード・バッファに入れる／から出すパッチを識別する。コード・バッファから出すパッチを見出すと、制御手段はこれらのパッチを例えばグルー・コード２３０５４へ再指向する。コード・バッファから出すパッチを見出すと、制御手段はこれらパッチに関するパッチ・ブロックを除去する。次に、制御手段は、削除手段２３０５６にコード・バッファを削除するように指令する。

図１２Ｇに示された仮想マシンが一般にソフトウエアの形態でありホスト・コンピュータ２３０４４のメモリに格納されることが理解されよう。
本発明が純粋に事例として本文に記述され、細部の修正が本発明の範囲内で可能であることが理解されよう。
本文の記述、および（適切な場合）請求の範囲および図面に開示された各特徴は、独立的に、あるいは適切な組合わせにおいて提供されよう。
上記のいずれかまたは全てにおいて、本発明の幾つかの特徴はコンピュータ・ソフトウエアを用いて実現された。しかし、当業者には、これらの特徴がハードウエア押ハードウエアとソフトウエアの組合わせを用いて実現されることが無論明らかであろう。更に、ハードウエア、コンピュータ・ソフトウエアなどにより行われるファンクションが電気信号などにおいてあるいはこれを用いて行われることが容易に理解されよう。
情報の格納に関する特徴は、適切な記憶場所またはストアによって実現されよう。情報の処理に関する特徴は、ソフトウエアまたはハードウエアにおいて、あるいは両者の組合わせにおいて、適切なプロセッサまたは制御手段により実現されよう。
上記のいずれかあるいは全てにおいて、本発明は、下記の形態のいずれか、あるいは一部、あるいはその全てにおいて具現されよう。すなわち、本発明は、コンピュータ・システムを動作させる方法において具現され、コンピュータ・システム自体において具現され、コンピュータ・システムを動作させる方法を実行するようプログラムされあるいは実行するためのコンピュータ・システムにおいて具現され、および（または）コンピュータ・システムを動作させる方法に従って動作するためのプログラムが記録されたコンピュータ読取り可能な記憶媒体において具現されよう。

本文に用いられるように、用語「コンピュータ・システム」は、「コンピュータ」、「システム」、「装備」、「装置」、「マシン」などの用語と互換であり得る。 コンピュータ・システムは、仮想マシンであり得、あるいは仮想マシンを含み得る。
上記のいずれかあるいは全てにおいて、方法および装置の特徴および特質を含む上記の異なる特徴および特質は、任意の適切な方法において組合わせることができる。
本発明が本文において純粋に事例として記述され、細部の修正が本発明の範囲内で可能であることが理解されよう。
本文の記述、および（適切な場合）請求の範囲および図面に開示された各特徴は、独立的に、あるいは適切な組合わせにおいて提供されよう。
先に使用された用語のあるものは、ジャバ言語およびジャバ・タイプの言語に特有のものである。本発明およびその実施の形態の種々の特質もまた、他の言語の使用において適用可能である。本文に用いた用語が他の言語に関する類似のおよび（または）対応する特徴を含むように広義に解釈されるべきことが理解されよう。
本発明が本文において純粋に事例として記述され、細部の修正が本発明の範囲内で可能であることが理解されよう。
本文の記述、および（適切な場合）請求の範囲および図面に開示された各特徴は、独立的に、あるいは適切な組合わせにおいて提供されよう。
本発明のいずれかの１つの特質の特徴は、本発明あるいは本文に記述した他の発明の他の特質に適用されよう。同様に、方法の特徴は装置の特徴に適用され、その逆も真である。

Claims (9)

1. コンピュータ・システムにおける第１のクラスの方法を呼出す方法であって、
   前記方法がファイナルであると仮定する前記第１のクラスへの呼出しをコンパイリング・システムによりコンパイルするステップと、
   第２のクラスの出現を決定し、そしてさらに前記第２のクラスが前記第１のクラスの方法のインスタンスを含むか否かを決定するステップと、
   前記第２のクラスにおける方法のインスタンスが前記第１のクラスの方法をオーバーライドしているか否かを決定するステップと、
   前記第２のクラスにおける方法のインスタンスが前記第１のクラスの方法をオーバーライドしているか否かのさらなる決定に応答して前記第１のクラスの方法の前記コンパイルされたコードを変更するステップと、
   前記変更されたコンパイルされたコードに従って前記コンピュータ・システムを動作するステップと、
   を含む方法。
2. 前記第１のクラスの方法をファイナルとしてマーキングするステップをさらに含む、請求項１に記載の方法。
3. 前記第１のクラスの方法が前記コンパイルコードを変更する前にファイナルであるか否かを決定するステップをさらに含む、請求項１に記載の方法。
4. 前記第２のクラスが有効であるか否かを決定するステップをさらに含む、請求項１に記載の方法。
5. 前記第２のクラスが有効でない場合は例外にするステップをさらに含む、請求項４に記載の方法。
6. 前記コンパイルするステップは前記呼出しのコードを含む、請求項１に記載の方法。
7. 前記コード最適化するステップはパッチを作成するステップを含む、請求項６に記載の方法。
8. 前記コンパイルされたコードを変更するステップはパッチを取り消すステップを含む、請求項７に記載の方法。
9. 前記コンパイルされたコードを変更するステップはコードを削除するステップを含む、請求項１に記載の方法。

Images