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

Abstract

(57)【要約】 １以上の主パスのダイナミック・コンパイルに関係する特徴を備えたコンピュータシステムであって、インターフェース方法のデスパッチ機構、コード・バッファの管理および削除、コンパイル・コードのテストおよび検証、不要部分の整理におけるグレイ・パケット管理、デバイス・ドライバ・割込みハンドラおよび/またはリストを含むデータ構造に対して、事前例外条件検査、アウトライアおよび/またはクラス・ローダーの使用を含む。本発明は仮想マシン２０００を含むシステム用の特定アプリケーションを見いだす。仮想マシン２０００は装備２００２の項目においてインストールされ、１以上のアプリケーション２００４および装備２００２のハードウエア２００６の項目と結合される。実行速度の増加およびメモリ・フットプリントの減少の利点がある。

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_a,b ｂをレジスタへロードする store r_a,y ｙ＝ｂ（ループ不変ステップ） load r_n,i ループの初めにレジスタをロードする load r_m,x div r_s,rｍ,rｎ ｘ／ｉおよび結果をレジスタｓへ格納 add r_n,l ｉ＋＋ cmp r_n,rａ ｉ＜ｂ blt ｉ＜ｂならば、ループを（div r_s,r_m,r_n から）ループを繰返する 上記コードの最初の２行は、事前例外条件検査を含む。ｉがゼロより大きけれ
ば、検査は通り、コンパイル・コードの残りが（３行目から）実行される。ｉが
０より小さいかこれに等しければ、以下に述べるように、コードの２行目が実行
を救済装置のグルー・コードへ送る。コンパイルされたブロックｂ₃の残りはこ
の時は実行されない。インタプリタがループ本体の初めから例外が検出される点
まで全てにわたりループを解釈することに注目されたい。このように、コンパイ
ル・コードにおける検査は、即時の例外ではなくこれから起こる例外の早期の警
告を与えている。ある場合には、このことは、制御がインタプリタへ転送される
前には「行われない」はずの、コンパイル・コードにおいて実施されるステップ
数を減じることができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００７３】 図３Ｃは、実行が主パスから外れる場合に使用されるアウトライアＯＬ１およ
びＯＬ２を示している。条件付きテストがＢ１の終りに通るならば、制御はＯＬ
１へ進む。ＯＬ１は状態と同期し（すなわち、レジスタのキャッシュ値が再びそ
れらの対応する記憶場所へ溢れることを保証し）、次いで制御を１つのグルー・
コードへ送りフォールバック・インタプリタを介する計算２に対応する予測され
ない（主要でない）パスの再開を生じる。ダイナミック・コンパイルを保証する
のに充分に頻繁な主要でないパス実行の対応バイト・コードの如きときまで、こ
れらバイトコードが解釈し続け、これによりバイト・コード実行の更に重要なパ
スに対するコード・バッファにおけるスペースを節減する。このように、ＯＬ１
のタイプのアウトライアが、計算２の実行を必要とするように、正常な制御のフ
ローが主パスから外れた予測されないパスをとる場合を処理する。 ＯＬ１のようなアウトライアのコードの一例は、下記のとおりである。 a＝r_n //a,b,cに対する状態を更新し記憶場所を復元する b＝r_m c＝r_s callglue (3000)//グルー・コードを呼出し、バイト・コード・アドレス3000 からコンパイルされないコードを解釈するよう指示する インタプリタは、ブロックＢ２の初めに実行を開始する。３０００におけるバイ
ト・コードが充分に実行されるならば、これは後でコンパイルされる。次にグル
ーが３０００から解釈するよう指示されると、Ｂ２のコンパイルされたバージョ
ンが存在することを認識する。ＯＬ１の「ｃａｌｌｇｌｕｅ」ラインを（自動的
に）「ｇｏｔｏ．．．」するよう変更して制御をコンパイル・バージョンへ向け
る。これは、「パッチング」として知られる（本明細書のエージェント資料第１
２参照）。このように、次にアウトライアＯＬ１が呼出されると、制御はグルー
を用いることなく直接ｂ２へ送られる。（本明細書のエージェント資料第１も参
照。） 異なるタイプのアウトライアＯＬ２は、例外条件が主パス内で認識される状況
を処理する（例えば、ブロックＢ１が、その適法の境界外のアレイにアクセスし
ようとする）。主パスは、例外を処理するため制御をアウトライア（ＯＬ２）へ
送る。ここで、アウトライアは、通常状態を同期させ、次に仮想マシン内に例外
を生じるため制御をグルー・コードへ送る。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【図面の簡単な説明】

【図１】 仮想マシンの幾つかの構成要素を示す図１において、 Ａは、実行のパスを示す図である。 Ｂは、主パスをコンパイルする比較コストを示す図である。 Ｃは、ディスパッチ・テーブルを示す図である。 Ｄは、本発明を実施するための装置を示す概略図である。 Ｅは、コードを介する実行のパスを示す図である。

【図２】 Ａは、本発明の方法を実施するための装置を示す図である。 Ｂは、例外を含むコードの断片を示す図である。 Ｃは、本発明によるコードのコンパイルされた断片を示す図である。

【図３】 Ａは、コンパイル前のコードの一部を示す図である。 Ｂは、図Ｆ０９／０１のコードの標準的コンパイルを示す図である。 Ｃは、望ましい実施の形態によるコードのコンパイルを示す図である。 Ｄは、コード・バッファを示す図である。 Ｅは、コンピュータ・システムにおけるメモリ構成を示す図である。 Ｆは、本発明の方法を実施する装置を示す図である。

【図４】 Ａは、オブジェクト指向プログラムにおける階層的構造を示す図である。 Ｂは、ディスパッチ・テーブルに格納されたデータの構成を示す図である。 Ｃは、ディスパッチ・テーブルに対するインターフェース・ハッシュ・テーブ
ルの適用を示す図である。 Ｄは、家庭用の装備システムの階層的構造を示す図である。 Ｅは、Ｄの家庭用システムにおける諸装置の動作に用いられるディスパッチ・
テーブルを示す図である。 Ｆは、Ｄの家庭用システムにおける装置を動作させるためのドライバ装置にお
けるコントローラ・プログラムを示す図である。ｐ

【図５】 Ａは、スタックにおけるデータ記憶を示す概略図である。 Ｂは、起動スタックを示す図である。 Ｃは、フレームにおける参照についての検査を示す図である。 Ｄは、手順呼出しフレームにおけるデータの構成を示す図である。 Ｅは、手順の実行を示す図である。 Ｆは、バリアの記述子ブロックの内容の構成を示す図である。

【図６】 Ａは、仮想マシンの原理を示す図である。 Ｂは、エミュレータ・スタックの動作を示す図である。 Ｃは、統合化されたスタックの動作を示す図である。 Ｄは、本発明の実施の一形態を示す図である。 Ｅは、本発明の装置の実施の形態を示す図である。

【図７】 Ａは、従来技術の手法に従うメモリの分割を示す図である。 Ｂは、別の従来技術の手法を示す図である。 Ｃは、いわゆる「並行な」環境におけるオブジェクトの構成を示す図である。 Ｄは、不要部分の整理作業のトレーシングを示す図である。 Ｅは、オブジェクトの構造を示す図である。 Ｆは、空のスタックを示す図である。 Ｇは、本発明による個々のパケットの構造を示す図である。 Ｈは、本発明の全般的動作を示す図である。

【図８】 Ａは、割込みを処理するためのＰＣコンピュータ・システムの各部を示す図で
ある。 Ｂは、実施の一形態における割込みの処理におけるステップを示す図である。 Ｃは、割込みハンドラのコードを示す図である。 Ｄは、実施の一形態を実施する装置を示す図である。

【図９】 Ａは、望ましい実施の形態を示すフロー図である。 Ｂは、コンパイル・コードの１つの部分を示す図である。 Ｃは、コンパイル・コードの異なる部分を示す図である。 Ｄは、望ましい実施の形態を実施する装置を示す図である。

【図１０】 Ａは、リンク・リストを示す図である。 Ｂは、ループ状のリンク・リストを示す図である。 Ｃは、ループ状のリンク・リストにおけるポインタの移動を示す図である。 Ｄは、装置の望ましい実施の形態を示す図である。

【図１１】 Ａは、実施の一形態のコード・バッファ形態を示す図である。 Ｂは、実施の一形態のコード断片を示す図である。

【図１２】 ＡないしＤは、コンパイル・コードにおけるパッチの使用を示すフロー図であ
る。 Ｅは、方法の望ましい実施の形態を示すフロー図である。 Ｆは、潜在的にポリモルフィックな方法によるパッチの使用を示す図である。 Ｇは、装置の望ましい実施の形態を示すブロック図である。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｇ０６Ｆ 9/44 ３２２Ｌ ３２２Ｈ ３２２Ｇ (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＵＧ，ＺＷ)，Ｅ Ａ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ， ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，Ｇ Ｅ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ， ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，Ｍ Ｎ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ， ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ，ＹＵ，Ｚ Ａ，ＺＷ (72)発明者 チャーネル，ウィリアム・トーマス イギリス国グレート・ミセンデン エイチ ピー16・０エイチジー，ナグス・ヘッド・ レーン，ベレトン (72)発明者 ダーネル，スティーブン イギリス国バークシャー エスエル６・３ エヌエイ，メイデンヘッド，ヘインズ・グ リーン 45 (72)発明者 ディアス，ブレイズ・アベル・アレック イギリス国ミドルセックス ユービー10・ ジーエヌジー，アックスブリッジ，ノー ス・ウェイ ７ (72)発明者 ガスリー，フィリッパ・ジョイ イギリス国バッキンガムシャー エイチピ ー22・４ディーエイチ，エールズベリー， ハードウィック，マナー・ファーム・コー ト ５ (72)発明者 クラムスコイ，ジェレミー・ポール イギリス国サリー ケイティー７・０エッ クスピー，ロング・ディットン，ポーツマ ス・ロード，クレアモント・テラス 12 (72)発明者 セクストン，ジェレミー・ジェームズ イギリス国ハートフォードシャー エイチ ピー３・９ユーキュー，ヘメル・ヘンプス テッド，ベネッツ・エンド，グレート・エ ルムズ・ロード 164 (72)発明者 ウィン，マイケル・ジョン イギリス国バークシャー エスエル６・７ ティーキュー，メイデンヘッド，ノース・ タウン・ロード 11 (72)発明者 ローテンバッハ，キース イギリス国バッキンガムシャー エイチピ ー11・１ジェイエル，ハイ・ワイクーム， キングスメッド・ロード 180 (72)発明者 トーマス，スティーブン・ポール イギリス国バッキンガムシャー エイチピ ー11・１ティアール，ハイ・ワイクーム， ランスダウン・ウェイ 16 Ｆターム(参考） 5B042 GA08 HH11 HH25 JJ29 LA09 5B081 AA09 CC00 DD01 5B098 BB05 GA05 GC01

Claims (416)

【特許請求の範囲】
1. 【請求項１】 アプリケーションのコードをコンパイルするためのコンパイ
   ラを含み、該コンパイラはコードの断片をコンパイルするために配列されている
   、コンピュータシステム。
2. 【請求項２】 コードの断片は１以上のブロックを含む、請求項１に記載の
   システム。
3. 【請求項３】 前記コードの断片はコードの主パス断片である、請求項２に
   記載のシステム。
4. 【請求項４】 コードの断片が実行される回数を記録する実行履歴レコーダ
   をさらに含む、請求項１から３のいずれかに記載のシステム。
5. 【請求項５】 閾値と等しいか大きい回数だけ実行された断片はコンパイル
   されることができる、請求項４に記載のシステム。
6. 【請求項６】 さらにコンパイラ・マネージャを含み、前記実行履歴レコー
   ダは、コードの断片が閾値の回数実行された時にコンパイラ・マネージャに知ら
   せるために配列されている、請求項５に記載のシステム。
7. 【請求項７】 前記閾値は動的に同調されることができる、請求項５または
   ６に記載のシステム。
8. 【請求項８】 前記実行履歴レコーダはアプリケーションの実行中に記録す
   るために配列されている、請求項４から７のいずれかに記載のシステム。
9. 【請求項９】 アプリケーションのコードを解釈するためのインタプリタを
   さらに含み、前記実行履歴レコーダはコードの断片の解釈を記録するために配列
   されている、請求項４から８のいずれかに記載のシステム。
10. 【請求項１０】 前記実行履歴レコーダは第１の断片から第２の断片までの
    実行のパスを記録するために配列されている、請求項４から９に記載のシステム
    。
11. 【請求項１１】 前記コンパイラは断片のパスをコンパイルするために配列
    されている、請求項１０に記載のシステム。
12. 【請求項１２】 コードの全てが解釈される唯一の断片がコンパイルされう
    るように前記システムは配列されている、請求項１から１１に記載のシステム。
13. 【請求項１３】 前記コンパイラは唯一の外部入力点を有するコンパイルさ
    れた断片を作成するために配列されている、請求項１から１２のいずれかに記載
    のシステム。
14. 【請求項１４】 前記コンパイラは非主パスを経た制御フローが主パスへ戻
    り併合することを防止する、請求項１から１３に記載のシステム。
15. 【請求項１５】 インタプリタとコンパイルされたコードの少なくともひと
    つの部分を含み、コードの実行において、コードの少なくとも第１の部分はコン
    パイルされたコードから実行され、コードの少なくとも第２の部分は前記インタ
    プリタにより解釈される、請求項１から１４のいずれかに記載のシステム。
16. 【請求項１６】 インタプリタを含み、さらにアプリケーションのコードを
    含み、該コードはコンパイルされるコードの少なくとも１部を含み、コードの実
    行において、コードの少なくとも第１の部分はコンパイルされたコードから実行
    され、コードの少なくとも第２の部分はインタプリタにより実行される、コンピ
    ュータシステム。
17. 【請求項１７】 コンパイルコードと非コンパイルコードの間の実行を伝送
    する伝送デバイスをさらに含む、請求項９、１５、１６のいずれかに記載のシス
    テム。
18. 【請求項１８】 コードの断片のコンパイル・バージョンがあるか否かを決
    定するための探索デバイスをさらに含む、請求項１から１７に記載のシステム。
19. 【請求項１９】 前記コンパイラはコードのコンパイルを最適化できる、請
    求項１から１８に記載のシステム。
20. 【請求項２０】 前記コンパイルコードは最適化されたことを通知するため
    のマーカーを含む、請求項１９に記載のシステム。
21. 【請求項２１】 前記コンパイラはオンラインでコンパイルすることができ
    る、請求項１から２０に記載のシステム。
22. 【請求項２２】 前記システムはマルチスレデッドであり、前記コンパイラ
    はコードを実行するスレッドに対し分離スレッド上で実行する、請求項１から２
    １のいずれかに記載のシステム。
23. 【請求項２３】 前記コンパイラは該コンパイラに有効なメモリを制限する
    手段をさらに含む、請求項１から２２のいずれかに記載のシステム。
24. 【請求項２４】 コンパイルコードの検出用の検出デバイスをさらに含む、
    請求項１から２３のいずれかに記載のシステム。
25. 【請求項２５】 前記システムは仮想マシーンを含む、請求項１から２４の
    いずれかに記載のシステム。
26. 【請求項２６】 アプリケーションのオペレーティングコードをコンパイル
    するコンパイラを含み、前記コードの唯一の主パス（または近似主パス）の断片
    はコンパイルされる、コンピュータシステム。
27. 【請求項２７】 コードの断片のコンパイル用に配列され、コンピュータシ
    ステムにおいてコードをコンパイルするためのコンパイラ。
28. 【請求項２８】 前記コンパイラはコードの主パスのコンパイルのために配
    列されている、請求項２７に記載のコンパイラ。
29. 【請求項２９】 コードの断片がコンパイルされる、アプリケーションのコ
    ードをコンパイルするためのコンパイラを含むコンピュータシステムを動作させ
    る方法。
30. 【請求項３０】 コードの断片が実行される回数が実行履歴レコーダにより
    記録される、請求項２９に記載の方法。
31. 【請求項３１】 さらにコンパイラ・マネージャを含み、実行履歴レコーダ
    はコードの断片が閾値回数実行された時にコンパイラ・マネージャを変える、請
    求項３０に記載の方法。
32. 【請求項３２】 実行履歴レコーダはアプリケーションの実行中に記録する
    、請求項２９から３１のいずれかに記載の方法。
33. 【請求項３３】 インタプリタを含み、さらにコンパイルコードの少なくと
    も一部を含むアプリケーションのコードを含むコンピュータシステムを動作させ
    る方法であって、コンパイルコードからコードの少なくとも第１の部分を実行す
    るステップと、前記インタプリタを使用するコードの少なくとも第２の部分を実
    行するステップを含む方法。
34. 【請求項３４】 前記コンパイラはオンラインでコンパイルする、請求項２
    ９から３３のいずれかに記載の方法。
35. 【請求項３５】 前記コンパイラに有効なメモリが限定されている、請求項
    ２９から３３のいずれかに記載の方法。
36. 【請求項３６】 さらにコンパイルされたコードを検出するステップを含む
    、請求項２９から３５のいずれかに記載の方法。
37. 【請求項３７】 アプリケーションのオペレーティングコードをコンパイル
    するコンパイラを含むコンピュータシステムを動作する方法であって、コードの
    主パス断片のみをコンパイルするステップを含む方法。
38. 【請求項３８】 コードの断片をコンパイルするステップを含む、コードを
    コンパイルする方法。
39. 【請求項３９】 コードの主パス断片をコンパイルするステップを含む、請
    求項３８に記載の方法。
40. 【請求項４０】 前記請求項２９から３９のいずれかの方法により生成され
    たコンパイル・コードを含む、コンピュータシステム用のコード。
41. 【請求項４１】 前記請求項１から２６のいずれかのコンピュータシステム
    または請求項２７または２８のいずれかのコンパイラにより生成された、コンピ
    ュータシステム用のコード。
42. 【請求項４２】 コードの断片がコンパイルされる、コードをコンパイルす
    るために記録されたプログラムを有するコンピュータ読取り可能な記憶媒体。
43. 【請求項４３】 請求項２９から３９のいずれかに記載の方法によって実行
    される記録されたプログラムを有するコンピュータ読取り可能な記録媒体。
44. 【請求項４４】 請求項２９から３９のいずれかに記載の方法によって実行
    するためにプログラムされたコンピュータ。
45. 【請求項４５】 実質的には図１Ａから１Ｅまでの参照番号を持って以下に
    記載されるコンピュータシステム。
46. 【請求項４６】 実質的には図１Ａから１Ｅまでの参照番号を持って以下に
    記載されるコンピュータシステムを動作する方法。
47. 【請求項４７】 実質的には図１Ａから１Ｅまでの参照番号を持って以下に
    規定される、コードをコンパイルする方法。
48. 【請求項４８】 可能な例外を含むコード断片をコンパイルする方法であっ
    て、事前例外条件検査を含むステップを含む方法。
49. 【請求項４９】 前記条件検査がコンパイルされた断片に開始に含まれる、
    請求項４８に記載の方法。
50. 【請求項５０】 例外が生起しない仮定のうえでコードの断片の本体はコン
    パイルされる、請求項４８か４９のいずれかに記載の方法。
51. 【請求項５１】 例外が起こることを条件検査が決定するならば使用のため
    の脱出デバイス与えるステップを含む、請求項４８から５０のいずれかに記載の
    方法。
52. 【請求項５２】 前記脱出デバイスはインタプリタへパスするように制御を
    強制するように配列されている、請求項５１に記載の方法。
53. 【請求項５３】 前記脱出デバイスは状態を更新するためのアウトライアー
    を含む、請求項５１または５２のいずれかに記載の方法。
54. 【請求項５４】 前記断片はコードの主パス断片を含む、請求項４８から５
    ３のいずれかに記載の方法。
55. 【請求項５５】 前記コンパイラは主パスコードを含む、請求項５４に記載
    の方法。
56. 【請求項５６】 コンパイルコードにおいて事前例外条件検査の使用。
57. 【請求項５７】 請求項４８から５５のいずれかに記載のコードをコンパイ
    ルするコンパイラ。
58. 【請求項５８】 事前条件検査を含む手段を含む、可能な例外を含むコード
    の断片をコンパイルする装置。
59. 【請求項５９】 コンパイラはコンパイル断片の開始に条件検査を含むため
    に配列される、請求項５８に記載の装置。
60. 【請求項６０】 前記コンパイラは、例外が起こらない仮定のもとにコード
    の断片をコンパイルするために配列されている、請求項５８または５９のいずれ
    かに記載の装置。
61. 【請求項６１】 例外が起こらないことを条件検査が決定したならば使用の
    ために脱出デバイスを含む、請求項５８から６０のいずれかに記載の装置。
62. 【請求項６２】 さらにインタプリタを含み、脱出デバイスはインタプリタ
    にパスするよう制御を強制するために配列されている、請求項６１に記載の装置
    。
63. 【請求項６３】 脱出デバイスは状態を更新するためのアウトライアを含む
    、請求項６１または６２のいずれかに記載の装置。
64. 【請求項６４】 断片はコードの主パス断片である請求項５８から６３のい
    ずれかに記載の装置。
65. 【請求項６５】 前記コンパイラは主パスコードをコンパイルするために配
    列されている、請求項６４に記載の装置。
66. 【請求項６６】 請求項４８から５５のいずれかの方法を使用してコンパイ
    ルされたコード。
67. 【請求項６７】 可能な例外を含むコンパイルコードの断片を含み、事前例
    外条件検査を含むコンピュータシステム用コード。
68. 【請求項６８】 前記コードは例外が起こるならば使用のための脱出デバイ
    スをさらに含む、請求項６７に記載のコード。
69. 【請求項６９】 前記脱出デバイスはインタプリタへの制御の転送を強制す
    る手段を含む、請求項６８に記載のコード。
70. 【請求項７０】 請求項６６から６９のいずれかに記載のコードを含み記録
    された構成データを有するコンピュータ読取り可能な記録媒体。
71. 【請求項７１】 請求項４４から５５のいずれかに記載の方法を実行するた
    めに記録されたプログラムを有するピュータ読取り可能な記録媒体。
72. 【請求項７２】 請求項４８から５５のいずれかの方法によりプログラムさ
    れるコンピュータシステム。
73. 【請求項７３】 可能な例外を含むコードの断片はコンパイルされ、事前例
    外条件検査を含む方法によりプログラムされるコンピュータシステム。
74. 【請求項７４】 実質的には図２Ａから図２Ｃへの参照を持ってここに記述
    されたコンピュータシステム。
75. 【請求項７５】 実質的には図２Ａから図２Ｃへの参照を持ってここに記述
    されたコンピュータシステムを動作する方法。
76. 【請求項７６】 コードの主パス断片をコンパイルするために配列されてい
    るコンパイラを含む、コンピュータシステム。
77. 【請求項７７】 さらに主パスについての情報を記録するための実行履歴レ
    コーダを含む、請求項７６に記載のコンピュータシステム。
78. 【請求項７８】 コードの実行中に主パス断片を決定する手段を含む、請求
    項７６または７７に記載の方法。
79. 【請求項７９】 実行のパスは主パスを残す使用のためのアウトライアを含
    む、請求項７６から７８に記載のコンピュータシステム。
80. 【請求項８０】 さらにインタプリタを含む、請求項７６から７９のいずれ
    かに記載のコンピュータシステム。
81. 【請求項８１】 前記アウトライアはインタプリタへ制御の転送を実効する
    ために採用されている、請求項８０に記載のコンピュータシステム。
82. 【請求項８２】 前記アウトライアは例外ハンドラへ制御の転送を実効する
    ために採用されている、請求項７９から８１のいずれかに記載のコンピュータシ
    ステム。
83. 【請求項８３】 前記アウトライアは頻繁に実行されないコードの実行の前
    に状態を更新するために適用されている、請求項７９から８２のいずれかに記載
    のコンピュータシステム。
84. 【請求項８４】 コードはアウトライアへの条件ブランチを含み、条件ブラ
    ンチは条件テストを含み且つ条件テストが失敗するなら実行は主パスの従う、請
    求項７６から８３のいずれかに記載のコンピュータシステム。
85. 【請求項８５】 頻繁に実行されないコードから頻繁に実行されるコードを
    分離するための手段を含む、請求項７６から８４のいずれかに記載のコンピュー
    タシステム。
86. 【請求項８６】 頻繁に実行されないコードから頻繁に実行されるコードを
    分離するための手段を含むコンピュータシステム。
87. 【請求項８７】 アウトライアを含み、該アウトライアから主パス断片を分
    離する手段を含む、請求項７６から８６のいずれかに記載のコンピュータシステ
    ム。
88. 【請求項８８】 第１のメモリ領域に主パス断片を記憶する手段と、第２の
    メモリ領域にアウトライアを記憶する手段を含む、請求項８７に記載のコンピュ
    ータシステム。
89. 【請求項８９】 前記第１のメモリ領域と第２のメモリ領域はコードバッフ
    ァの領域である、請求項８８に記載のコンピュータシステム。
90. 【請求項９０】 主パス断片を記憶する手段とコードバッファの反対側端に
    アウトライアを含む、請求項８９に記載のコンピュータシステム。
91. 【請求項９１】 頻繁に実行されないコードはキャシュに導かれることが有
    り得ないようにコードは記憶される、請求項７６から９０に記載のコンピュータ
    システム。
92. 【請求項９２】 コードキャシュを含み、頻繁に実行されないコードはキャ
    シュに記憶されることは有り得ないように配列される、コンピュータシステム。
93. 【請求項９３】 ひとつのメモリ領域またはキャシュに主パスコンパイルコ
    ードの実質的に全て（および好ましくは唯一）を共に記憶する手段を含む、コン
    ピュータシステム。
94. 【請求項９４】 他のコードを記憶する手段を含むシステムは空間的に分離
    した領域にある、請求項９３に記載のコンピュータシステム。
95. 【請求項９５】 コードの主パス断片をコンパイルするステップを含む、コ
    ンピュータ
96. 【請求項９６】 コードの実行中に主パスを決定するステップを含む、請求
    項９５に載の方法。
97. 【請求項９７】 実行のパスは主パスを残す時にアウトライアは使用される
    、請求項９５または９６に記載の方法。
98. 【請求項９８】 アウトライアはインタプリタへの制御の転送を実効する、
    請求項９７に記載の方法。
99. 【請求項９９】 アウトライアは例外ハンドラへ制御を転送する、請求項９
    ７に記載の方法。
100. 【請求項１００】 頻繁に実行されないコードの実行の前にアウトライアは
     状態を更新する、請求項９７から９９に記載の方法。
101. 【請求項１０１】 コードはアウトライアへの条件ブランチを含み、該条件
     ブランチは条件テストを含み且つ該条件テストが失敗するならば主パスに従う、
     請求項９７から１００のいずれかに記載の方法。
102. 【請求項１０２】 頻繁に実行されないコードから頻繁に実行されるコード
     を分離するステップを含む、請求項９５から１０１のいずれかに記載の方法。
103. 【請求項１０３】 頻繁に実行されるコードと頻繁に実行されないコードと
     を分離するステップを含む、コンピュータシステムを動作する方法。
104. 【請求項１０４】 アウトライアから主パス断片 を分離するステップを含む、請求項９５から１０３のいずれかに記載の方法。
105. 【請求項１０５】 第１のメモリ領域に記憶された主パス断片を記憶するす
     る方法と、第２の記憶領域にアウトライアを記憶するステップを含む請求項１０
     ４に記載の方法。
106. 【請求項１０６】 第１のメモリ領域と第２のメモリ領域はコードバッファ
     の領域である、請求項１０５に記載の方法。
107. 【請求項１０７】 主パス断片とアウトライアをコードバッファの反対側端
     に記憶するステップを含む、請求項１０６に記載の方法。
108. 【請求項１０８】 頻繁に実行されるコードはキャッシュに導かれることが
     有り得ないようにコードを記憶するステップを含む請求項９５から１０７のいず
     れかに記載の方法。
109. 【請求項１０９】 頻繁に実行されるコードはキャッシュに導かれることが
     有り得ないように、コードキャッシュを含むコンピュータシステムにコードを記
     憶する方法。
110. 【請求項１１０】 主パスコードをコンパイルするステップと、前記コンパ
     イルしたコードを記憶するステップとを含むコンピュータシステムを動作する方
     法。
111. 【請求項１１１】 分離メモリ領域に頻繁にアクセスされたコードを記憶す
     るステップを含む請求項１１０に記載の方法。
112. 【請求項１１２】 頻繁に実行されるコードが頻繁に実行されないコードか
     ら分離されるようにコンパイルが実効される、コードをコンパイルする方法。
113. 【請求項１１３】 請求項９５から１１２のいずれかに記載の方法によりコ
     ンピュータシステムにより記憶されるコード。
114. 【請求項１１４】 請求項９５から１１２のいずれかに記載の方法によりコ
     ードをコンパイルするためのコンパイラ。
115. 【請求項１１５】 前記コンピュータシステムは仮想マシンのように構成さ
     れるか仮想マシンを実現する、請求項７６から９４のいずれかに記載のコンピュ
     ータシステム。
116. 【請求項１１６】 請求項９５から１１２のいずれかに記載の方法を実行す
     るために記録されたプログラムを有するコンピュータ読取り可能な記録媒体。
117. 【請求項１１７】 頻繁に実行されるコードは頻繁に実行されないコードか
     ら分離されるようにコンパイルは実効される、コードをコンパイルするために記
     録されたプログラムを有するンピュータ読取り可能な記録媒体。
118. 【請求項１１８】 請求項９５から１１２のいずれかに記載の方法によりプ
     ログラムされたコンピュータ。
119. 【請求項１１９】 頻繁に実行されるコードは頻繁に実行されないコードか
     ら分離されるようにコンパイルは実効される、コードをコンパイルするためにプ
     ログラムされたコンピュータ。
120. 【請求項１２０】 実質的には図３Ａから図３Ｆを参照して記述されたよう
     なコンピュータシステム。
121. 【請求項１２１】 実質的には図３Ａから図３Ｆを参照して記述されたよう
     なコンピュータシステムを動作する方法。
122. 【請求項１２２】 オブジェクト指向言語におけるプログラムの実行中にデ
     ィスパッチ時間を減少する方法であって、前記プログラムは複数のインターフェ
     ース方法を有し、 （i）ディスパッチテーブルを作成するステップと、 （ii）１以上のディスパッチテーブルのためのインターフェース・ハッシュ
     テーブルを作成するステップと、前記インターフェース・ハッシュテーブルは対
     応するディスパッチテーブルにおける特定位置への索引として、またはプログラ
     ムを実行するコンピュータに記憶された方法に対するいずれかのポインタを有し
     、 （iii）前記プログラムが特定のインターフェース方法を要求するステップ
     を実行する時に、前記ディスパッチテーブルを介してまたは直接に特定のインタ
     ーフェース方法をルックアップするためのテーブルを有するインターフェースを
     使用するステップと、 を含む方法。
123. 【請求項１２３】 仮想マシンを有し、該仮想マシンにより実行される１組
     のプログラムはコンピュータ読取り可能媒体（ＣＤのような）に記憶され、前記
     仮想マシンはプログラム実行の過程でディスパッチ時間を減少するために動作し
     、該プログラム実行過程は、 （i）ディスパッチテーブルを作成するステップと、 （ii）１以上のディスパッチテーブルのためのインターフェース・ハッシュ
     テーブルを作成するステップと、前記インターフェース・ハッシュテーブルは対
     応するディスパッチテーブルにおける特定位置への索引として、またはプログラ
     ムを実行するコンピュータに記憶された方法に対するいずれかのポインタを有し
     、 （iii）前記プログラムが特定のインターフェース方法を要求するステップ
     を実行する時に、前記ディスパッチテーブルを介してまたは直接に特定のインタ
     ーフェース方法をルックアップするためのテーブルを有するインターフェースを
     使用するステップと、を含む、 ディスパッチ時間を減少する方法。
124. 【請求項１２４】 ディスパッチ時間を減少する方法はジャバプログラム言
     語にいおいて実行される、請求項１２２から１２３のいずれかに記載の方法。
125. 【請求項１２５】 ディスパッチテーブル当たりひとつのインターフェース
     ハッシュ、または全ての前記ディスパッチテーブル用の単一ハッシュテーブルの
     いずれかである、請求項１２２から１２４のいずれかに記載の方法。
126. 【請求項１２６】 ディスパッチテーブルはインターフェースハッシュテー
     ブルをポイントする、請求項１２２から１２５のいずれかに記載の方法。
127. 【請求項１２７】 前記ハッシュテーブルは開始にはディスパッチテーブル
     の一部である、請求項１２２から１２５のいずれかに記載の方法。
128. 【請求項１２８】 インターフェースハッシュテーブルは、ディスパッチテ
     ーブルのスロット数、または１レベルのインディレクションを削除するファンク
     ション・ポイントのいずれかを含む、請求項１２２から１２７のいずれかに記載
     の方法。
129. 【請求項１２９】 インターフェースハッシュテーブルにいて同じインター
     フェース方法をルックアップする時に生じる衝突のイベントにおいて、特殊回復
     方法を呼び出すステップを含み、前記ハッシュテーブルはコンピュータに記憶さ
     れた方法、またはディスパッチテーブルにおけるフォールバック・スロットのい
     ずれかをポインティングし、「ソートアウト：整理」クラスに設計された適切に
     記憶された方法への呼出しへ転送し、前記呼出しを適切な場所へ導く、請求項１
     ２２から１２８のいずれかに記載の方法。
130. 【請求項１３０】 請求項１２２から１２９のいずれかに記載のディスパッ
     チ時間を減少する方法を含む、コンピュータシステムを動作する方法。
131. 【請求項１３１】 請求項１２２から１３０のいずれかに記載の方法を実行
     するために適用されるコンピュータシステム。
132. 【請求項１３２】 請求項１２２から１３０のいずれかに記載の方法を実行
     するためにプログラムされたコンピュータ。
133. 【請求項１３３】 請求項１２２から１３０のいずれかに記載の方法を実行
     するために記録されたプログラムを実行するために記録されたプログラムを有す
     るコンピュータ読取り可能な記録媒体。
134. 【請求項１３４】 実質的には図４Ａから図４Ｆを参照して記載されている
     ようなコンピュータシステム。
135. 【請求項１３５】 実質的には図４Ａから図４Ｆを参照して記載されている
     ようなコンピュータシステムを動作する方法。
136. 【請求項１３６】 制御の各スレッドにより管理されるために配列された少
     なくともひとつの起動スタックを含むコンピュータシステムを動作する方法であ
     って、 起動スタックを使用する前記スレッドを実行するステップと、 同じ起動スタックをアクセスするやめの別のスレッドを許可するステップと、 を含むコンピュータシステムを動作する方法。
137. 【請求項１３７】 前記スレッドの実行は、前記別のスレッドが前記スレッ
     ドの起動スタックをアクセスする時間のほんの一部の間に休止される、請求項１
     ３６に記載の方法。
138. 【請求項１３８】 前記スレッドと前記別のスレッドは同時に同じ起動フレ
     ームをアクセスすることから防止される、請求項１３６または１３７のいずれか
     に記載の方法。
139. 【請求項１３９】 現起動フレームの前記スレッドによる実行は、同じ起動
     フレームをアクセスするために前記別のスレッドを取る時間の間休止される、請
     求項１３６から１３８のいずれかに記載の方法。
140. 【請求項１４０】 前記別のスレッドにより現在アクセスされている前記フ
     レームへの現起動フレームからの前記スレッド・リターンを選択的に防止するた
     めにバリアが与えられる、請求項１３６から１３９のいずれかに記載の方法。
141. 【請求項１４１】 もし前記別のスレッドが現在親起動フレームをアクセス
     しているならば、前記スレッドの現起動フレームの親起動フレームへの該現起動
     フレームからの前記スレッド・リターンを防止するためにバリアが与えられてい
     る、請求項１３６から１４０のいずれかに記載の方法。
142. 【請求項１４２】 別のスレッドが現在アクセスしているフレームを変える
     前に現起動フレーム用のバリアが与えられる、請求項１４０から１４１のいずれ
     かに記載の方法。
143. 【請求項１４３】 第２の別のスレッドは同じ起動スタックをアクセスする
     ために許容される、請求項１３６から１４２のいずれかに記載の方法。
144. 【請求項１４４】 同じ起動フレームに対し異なるバリアが前記別のスレッ
     ドおよび前記第２の別のスレッドにより与えられる、請求項１４０、１４１、１
     ４２に従属している請求項１４３に記載の方法。
145. 【請求項１４５】 前記バリアのグループは単一の起動フレームと関連する
     ことを許容するように配列される、請求項１４４に記載の方法。
146. 【請求項１４６】 前記各異なるバリアに対し、リンクリストを形成するた
     めにリンクされている記述子ブロックが与えられる、請求項１４４または１４５
     のいずれかに記載の方法。
147. 【請求項１４７】 前記別のスレッドはガーベッジ・コレクタのスレッドで
     ある、請求項１３６から１４６のいずれかに記載の方法。
148. 【請求項１４８】 単一サイクルにおいて、前記ガーベッジ・コレクタは前
     記スタックのフレームの初期および少なくともひとつの別の走査を作る、請求項
     １４７に記載の方法。
149. 【請求項１４９】 前記少なくともひとつの別の走査において、変化した唯
     一のフレームが走査される、請求項１４８に記載の方法。
150. 【請求項１５０】 前記少なくともひとつの走査において、記録はフレーム
     が再走査される必要がある範囲まで維持される、請求項１４８または１４９に記
     載の方法。
151. 【請求項１５１】 制御の各スレッドにより管理されるために配列された少
     なくともひとつの起動スタックと、 起動スタックを使用する前記スレッドを実行する手段と、 別のスレッドに同じ起動スタックをアクセスするために許可する手段と、 を含むコンピュータ。
152. 【請求項１５２】 前記スレッドの起動スタックをアクセスするために前記
     別のスレッドにかかる時間の一部の間に前記スレッドによる実行を休止する手段
     を含む、請求項１５１に記載のコンピュータシステム。
153. 【請求項１５３】 前記スレッドおよび前記別のスレッドを同時に同じ起動
     フレームからアクセスすることから防止する手段を含む、請求項１５１または１
     ５２に記載のコンピュータシステム。
154. 【請求項１５４】 同じ起動スレッドの起動スタックをアクセスするために
     前記別のスレッドにかかる時間の間に現起動フレームの前記スレッドによる実行
     を休止する手段を含む、請求項１５１から１５３のいずれかに記載のコンピュー
     タシステム。
155. 【請求項１５５】 前記現起動フレームから現在前記別のスレッドによりア
     クセスされているフレームへの戻りを選択的に防止するバリアを与える手段を含
     む、請求項１４１から１５４に記載のコンピュータシステム。
156. 【請求項１５６】 前記別のスレッドが前記親起動フレームにアクセスされ
     ているならば、現起動フレームから前記スレッド の現起動フレームの親起動フレームへの前記スレッド・リターンを防止するバリ
     アを与える手段をさらに含む、請求項１５１から１５５に記載のコンピュータシ
     ステム。
157. 【請求項１５７】 前記別のスレッドは、現在アクセスしているフレームを
     変化する前に現起動フレームに対するバリア与える手段を含む、請求項１５５か
     ら１５６に記載のコンピュータシステム。
158. 【請求項１５８】 同じ起動スタックをアクセスするための第２の別のスレ
     ッドを許可する手段を含む、請求項１５１から１５７に記載のコンピュータシス
     テム。
159. 【請求項１５９】 前記別のスレッドおよび前記第２の別のスレッドに対し
     て同じ起動フレームの異なるバリアを与えるために適用されている、請求項１５
     ８に記載のコンピュータシステム。
160. 【請求項１６０】 前記バリアのグループに単一起動フレームに関連するこ
     とを許容するために前記バリアは配列されている、請求項１５９に記載のコンピ
     ュータシステム。
161. 【請求項１６１】 リンクリストを形成するためにリンクされている記述子
     ブロックを各前記異なるバリアに対して与えるために適用されている、請求項６
     ０に記載のコンピュータシステム。
162. 【請求項１６２】 前記別のスレッドはガーベッジ・コレクタのスレッドで
     ある、請求項１５１から１６１のいずれかに記載のコンピュータシステム。
163. 【請求項１６３】 単一のサイクルにおいて、前記ガーベッジ・コレクタは
     前記スタックのフレームの初期の走査および少なくとも別の走査を作るために適
     用されている、請求項１６２に記載のコンピュータシステム。
164. 【請求項１６４】 前記少なくともひとつの別の走査において変化した唯一
     のフレームは走査されるように適用されている、請求項１６３に記載のコンピュ
     ータシステム。
165. 【請求項１６５】 前記少なくともひとつの別の走査において、フレームが
     再走査されることを必要とする範囲までの記録を維持する手段をさらに含む、請
     求項１６３から１６４のいずれかに記載のコンピュータシステム。
166. 【請求項１６６】 スレッドは、全スタックよりも現起動フレームを調べる
     ためにかかる時間の間不要部分の整理の目的のために唯一休止される、 コンピュータシステム内のスレッド・スタック内に含まれる参照データの並行不
     要部分の整理を改良する方法。
167. 【請求項１６７】 ガーベッジ・コレクタがフレームの検査を完成する時間
     まで、コンテンツが現在ガーベッジ・コレクタによろ検査されている起動フレー
     ムへの未決の手順呼出しの戻りを防止するステップを含む、請求項１６６に記載
     の方法。
168. 【請求項１６８】 ガーベッジ・コレクタと、全スタックよりも現起動フレ
     ームを調べるためにかかる時間の間不要部分の整理の目的のためにスレッドを唯
     一休止する手段と、を含む装置。
169. 【請求項１６９】 ガーベッジ・コレクタと、全スタックよりも現起動フレ
     ームを調べるためにかかる時間の間不要部分の整理の目的のためにスレッドを唯
     一休止する手段と、を含むコンピュータまたはコンピュータシステム。
170. 【請求項１７０】 スレッドは、全スタックよりも現起動フレームを調べる
     ためにかかる時間の間不要部分の整理の目的のために唯一休止される、 コンピュータシステム内のスレッド・スタック内に含まれる参照データの並行不
     要部分の整理を改良する方法を提供するプログラム、記録されたプログラムを有
     するコンピュータ読取り可能な記録媒体。
171. 【請求項１７１】 コンピュータシステム内に含まれるスレッド・スタック
     内に含まれる参照データの並行不要部分の整理を改良する方法を与えるようにプ
     ログラムされている場合に、前記スレッドは全スタックよりも現起動フレームを
     調べるためにかかる時間の間不要部分の整理の目的のために唯一休止される、コ
     ンピュータ。
172. 【請求項１７２】 スタックに関係するスレッドをアクセスするために不要
     部分の整理をイネーブルするステップと、 調べられるべき最大アクティブ起動フレームに必要とするほどの長い間のみ関
     係するスレッドの実行を中断するステップと、 戻りバリアコードへ前記フレームのリターン・アドレスを編集するステップと
     、 継続する起動フレームが審査されている間実行を継続するために関係するスレ
     ッドを許容するステップと、 次のフレームへ移動する前に同じ戻りバリアコードへ各前記フレームのリター
     ン・アドレスを編集するステップと を含むコンピュータシステムのスレッド・スタックにおける並行な不要部分の整
     理を改良する方法。
173. 【請求項１７３】 前記バリアコードは、起動フレームへの未決の手順呼出
     しの戻りを防止するために使用され、該起動フレームのコンテンツは、ガーベッ
     ジ・コレクタがフレームの検査を完了する時間まで該ガーベッジ・コレクタによ
     り現在検査されている、請求項１７２に記載の方法。
174. 【請求項１７４】 スタックに関係するスレッドをアクセスするために不要
     部分の整理をイネーブルするステップと、 調べられるべき最大アクティブ起動フレームに必要とするほどの長い間のみ関
     係するスレッドの実行を中断するステップと、 戻りバリアコードへ前記フレームのリターン・アドレスを編集するステップと
     、 継続する起動フレームが審査されている間実行を継続するために関係するスレ
     ッドを許容するステップと、 次のフレームへ移動する前に同じ戻りバリアコードへ各前記フレームのリター
     ン・アドレスを編集するステップと を含むコンピュータシステムのスレッド・スタックにおける並行な不要部分の整
     理を改良する方法を提供するプログラム、記録した該プログラムを有するコンピ
     ュータ読取り可能な記録媒体。
175. 【請求項１７５】 請求項１４６から１５０、１６６、１６７、１７２、１
     ７３のいずれかに記載のコンピュータ。
176. 【請求項１７６】 起動スタックを使用するスレッドを実行し、 同じ起動スタックをアクセスするために別のスレッドを許可するよｙにプログ
     ラムされた制御の各スレッドにより管理されるために配列された少なくともひと
     つの起動スタックを含む、コンピュータシステム。
177. 【請求項１７７】 請求項１３６から１５０、１６６、１６７、１７２、１
     ７３のいずれかに記載の方法を提供するプログラム、記録された該プログラムを
     有するコンピュータ読取り可能な記録媒体。
178. 【請求項１７８】 制御の各スレッドにより管理されるべく配列された少な
     くともひとつの起動スタックを含むコンピュータシステムを動作する方法であっ
     て、 起動スタックを使用する前記スレッドを実行するステップと、 同じ起動スタックをアクセスするために別のスレッドを許可するステップと を含む方法を提供するプログラム、記録された該プログラムを有するコンピュー
     タ読取り可能な記録媒体。
179. 【請求項１７９】 請求項１５１から１６５、１６９、１７１、１７５，１
     ７６のいずれかに記載のコンピュータまたはコンピュータシステム。
180. 【請求項１８０】 請求項１３６から１５０、１６６、１６７、１７２、１
     ７３のいずれかに記載の方法により動作される場合の仮想マシン。
181. 【請求項１８１】 請求項１７０、１７４、１７７、１７８のいずれかに記
     載のコンピュータ読取り可能記録媒体の手段により動作される場合の仮想マシン
     。
182. 【請求項１８２】 実質的に図５Ａから図５Ｆを参照して記述されまたは図
     ５Ａから図５Ｆに例示された方法。
183. 【請求項１８３】 実質的に図５Ａから図５Ｆを参照して記述されまたは図
     ５Ａから図５Ｆに例示されたコンピュータ。
184. 【請求項１８４】 実質的に図５Ａから図５Ｆを参照して記述されまたは図
     ５Ａから図５Ｆに例示されたコンピュータシステム。
185. 【請求項１８５】 実質的に図５Ａから図５Ｆを参照して記述されまたは図
     ５Ａから図５Ｆに例示された装置。
186. 【請求項１８６】 実質的に図５Ａから図５Ｆを参照して記述されまたは図
     ５Ａから図５Ｆに例示されたコンピュータ読取り可能な記録媒体。
187. 【請求項１８７】 実質的に図５Ａから図５Ｆを参照して記述されまたは図
     ５Ａから図５Ｆに例示された仮想マシン。
188. 【請求項１８８】 コンピュータシステムにおいてスタックのフレームを調
     べるステップと、 コンパイルコードのセクションのアドレスの範囲にあるリターン・アドレスを
     フレームが含むか否かを識別するステップと、 リターン・アドレスが識別される時にフレームのコンテンツを変えるステップ
     と、 を含み、コンパイルコードのセクションが削除されることを許容する、コンピュ
     ータシステムにおいてメモリを調べるために方法。
189. 【請求項１８９】 削除されるべきコンパイルコードのセクションを選択す
     るステップと、 コンピュータシステムにおいてスタックのフレームを調べるステップと、 コンパイルコードのセクションのアドレスの範囲にあるリターン・アドレスを
     フレームが含むか否かを識別するステップと、 リターン・アドレスが識別される時にフレームのコンテンツを変えるステップ
     と、 コンパイルコードを削除するステップと、 を含む方法。
190. 【請求項１９０】 何れかのリターン・コードは継続コードのアドレスに変
     更される、請求項１８８または１８９に記載の方法。
191. 【請求項１９１】 継続コードは制御をインタプリタへ転送するために配列
     されている、請求項１９０に記載の方法。
192. 【請求項１９２】 フレームはリターン・アドレスを含む時に、フレームに
     おける値は変更される、請求項１９０または１９１に記載の方法。
193. 【請求項１９３】 前記スタックにおける複数のフレームは調べられる、請
     求項１８８から１９１のいずれかに記載の方法。
194. 【請求項１９４】 コンピュータシステムにおける各複数のスレッドのスタ
     ックは調べられる、請求項１８８から１９３のいずれかに記載の方法。
195. 【請求項１９５】 システムにおいて各スレッドの各スタックのフレームを
     調べるステップと、 削除されるべきコンパイルコードの部分へリターン・アドレスがポイントして
     いるか否かを識別するステップと、 削除されるべきコンパイルコードの部分無しにスレッドの実行を継続可能であ
     るようにリターン・アドレスを含む各スタックのコンテンツを再配列するステッ
     プと、 を含むコンピュータシステムにおいてコンパイルコードを削除する方法。
196. 【請求項１９６】 請求項１８８から１９５の何れかに記載の方法を含む、
     コンピュータシステムを動作する方法。
197. 【請求項１９７】 コンピュータシステムは仮想マシンとして構成されてい
     る、請求項１８８から１９６の何れかに記載の方法。
198. 【請求項１９８】 コンピュータシステムにおいてスタックのフレームを調
     べる手段と、 削除されるべきコードのセクションのアドレスの範囲にあるリターン・アドレ
     スを前記フレームは含むか否かを識別する手段と、 前記フレームのコンテンツを変える手段と、 を含む、コンパイルコードのセクションが削除されることを許容するコンピュー
     タシステムにおけるメモリを調べる装置。
199. 【請求項１９９】 検出されるべきコンパイルコードのセクションを選択す
     る手段と、 コンピュータシステムにおいてスタックのフレームを調べる手段と、 削除されるべきコンパイルコードのセクションのアドレスの範囲にあるリター
     ン・アドレスを前記フレームは含むか否かを識別する手段と、 前記フレームのコンテンツを変える手段と、 コンパイルコードのセクションを削除する手段と、 を含む、コンピュータシステムにおけるコンパイルコードを削除する装置。
200. 【請求項２００】 継続した命令を実行する手段を含み、前記フレームのコ
     ンテンツを配列する手段は、前記継続した命令を実行する手段のアドレスへの何
     れかのリターン・アドレスを変更するために適用されている、請求項１９８また
     は１９９のいずれかに記載の装置。
201. 【請求項２０１】 継続した命令を実行するインタプリタを含む、請求項２
     ００に記載の装置。
202. 【請求項２０２】 前記フレームのコンテンツを変える手段は、継続する命
     令の実行をイネーブルするためにフレーム中の値を変えるように適用されている
     、請求項２００または２０１に記載の装置。
203. 【請求項２０３】 前記スタックにおけるフレームを調べる手段は、スタッ
     クにおける複数のフレームを調べるために適用されている、請求項１９８から２
     ０２のいずれかに記載の装置。
204. 【請求項２０４】 前記スタックにおけるフレームを調べる手段はコンピュ
     ータシステムにおける複数の各スレッドをスタックを調べるために適用されてい
     る、請求項１９８から２０３のいずれかに記載の装置。
205. 【請求項２０５】 請求項１９８から２０４のいずれかに記載の装置を含む
     仮想マシン。
206. 【請求項２０６】 請求項１９８から２０５のいずれかに記載の装置を含む
     コンピュータシステム。
207. 【請求項２０７】 コンパイルコードを削除する手段と、 システムにおける各スレッドの各スタックのフレームを調べる手段と、 削除されるべきコンパイルコードの部分へリターン・コードはポイントするか
     否かを識別する手段と、 削除されるべきコンパイルコードの部分無しに実行を継続することをスレッド
     に可能にするようにリターン・アドレスを含む各スタックのコンテンツを再配列
     する手段と、 を含むコンピュータシステム。
208. 【請求項２０８】 実質的に図６Ａから図６Ｅを参照して記述されまたは図
     ６Ａから図６Ｅに例示された装置および方法。
209. 【請求項２０９】 請求項１８８から１９７のいずれかに記載の方法を実行
     するための記録されたプログラムを有するコンピュータ読取り可能な記憶媒体。
210. 【請求項２１０】 請求項１８８から１９７の何れかに記載の方法を実行す
     るためにプログラムされたコンピュータ。
211. 【請求項２１１】 コンピュータシステムにいてガーベッジ・コレクタを動
     作する方法であって、前記ガーベッジ・コレクタは１組の部分的にトレースされ
     たメモリ・オブジェクトを有し、複数の離散パケットにおいて前記組をハンドリ
     ングするステップを含む、ガーベッジ・コレクタを動作する方法。
212. 【請求項２１２】 前記ガーベッジ・コレクタは並行ガーベッジ・コレクタ
     である、請求項２１１に記載の方法。
213. 【請求項２１３】 各パケットは何らかの所与の時間に制御のせいぜいひと
     つのスレッドによりアクセス可能である、請求項２１２に記載の方法。
214. 【請求項２１４】 異なるパケットは、同じ時間に制御の異なるスレッドに
     よりアクセスされ得る請求項２１１から２１３のいずれかに記載の方法。
215. 【請求項２１５】 パケットは異なるスレッドにより使用され得るように該
     パケットは分離して扱われる、請求項２１１から２１４のいずれかに記載の方法
     。
216. 【請求項２１６】 制御の特定スレッドにより現在使用されている各パケッ
     トは「チェックアウト」としてマークされ、制御の特定スレッドを現在持ってい
     ない各パケットは「チェックイン」としてマークされ、チェックアウトされたパ
     ケットのみが制御の前記特定スレッドによりオンに動作され得る、請求項２１１
     から２１５の何れかに記載の方法。
217. 【請求項２１７】 各パケットは、オブジェクトに対し参照当たりひとつで
     ある、複数のスロットを含み、該数は少なくとも２、５、１０、５０、１００の
     ひとつである、請求項２１１から２１６のいずれかに記載の方法。
218. 【請求項２１８】 各パケットは、オブジェクトに対し参照当たりひとつで
     ある、複数のスロットを含み、該数は少なくとも５０００、１０００、５００、
     １００の何れかより小さいひとつである、請求項２１１から２１７のいずれかに
     記載の方法。
219. 【請求項２１９】 各前記パケットは固定サイズである、請求項２１１から
     ２１８のいずれかに記載の方法。
220. 【請求項２２０】 各パケットはスロットの固定数と、該パケット内に現在
     使用されているスロット数の表示を含む、請求項２１１から２１９のいずれかに
     記載の方法。
221. 【請求項２２１】 前記パケットは作成され且つ要求に従って破壊される、
     請求項２１１から２２０のいずれかに記載の方法。
222. 【請求項２２２】 前記パケットの破壊は、部分的に完全なパケットのコン
     テンツを共に併合することにより少なくとも部分において達成される、請求項２
     １１から２２１のいずれかに記載の方法。
223. 【請求項２２３】 並行ガーベッジ・コレクタを含み、該ガーベッジ・コレ
     クタは１組の部分的にトレースされたメモリ・オブジェクトを有し、複数の分散
     パケットにおいて前記組をハンドリングする手段を含む、コンピュータシステム
     。
224. 【請求項２２４】 ガーベッジ・コレクタは並行ガーベッジ・コレクタであ
     る、請求項２２３に記載のコンピュータ・システム。
225. 【請求項２２５】 所与の時間に制御のせいぜいひとつのスレッドによりア
     クセス可能である、請求項２２４に記載のコンピュータシステム。
226. 【請求項２２６】 所与の時間に制御の異なるスレッドによりアクセス可能
     な異なるパケットをレンダリングする手段をさらに含む、請求項２２３から２２
     ５のいずれかに記載のコンピュータシステム。
227. 【請求項２２７】 パケットが異なるスレッドにより使用され得るように分
     離してパケットを扱うための手段をさらに含む、請求項２２３から２２６のいず
     れかに記載のコンピュータシステム。
228. 【請求項２２８】 制御の特定スレッドにより現在使用中である各パケット
     を「チェックアウト」としてマークし、制御の現在特定スレッドの無い各パケッ
     トを「チェックイン」としてマークする手段と、制御の前記特定スレッドにより
     チェックアウトされたパケットにおいてのみ動作を許可する手段とをさらに含む
     、請求項２２３から２２７のいずれかに記載のコンピュータシステム。
229. 【請求項２２９】 各パケットは、オブジェクトに対し参照当たりひとつで
     ある、複数のスロットを含み、該数は少なくとも２、５、１０、５０、１００の
     ひとつである、請求項２２３から２２８のいずれかに記載のコンピュータシステ
     ム。
230. 【請求項２３０】 各パケットは、オブジェクトに対し参照当たりひとつで
     ある、複数のスロットを含み、該数は少なくとも５０００、１０００、５００、
     １００の何れかより小さいひとつである、請求項２２３から２２９のいずれかに
     記載のコンピュータシステム。
231. 【請求項２３１】 各前記パケットは固定サイズである、請求項２２３から
     ２３０のいずれかに記載のコンピュータシステム。
232. 【請求項２３２】 各パケットはスロットの固定数と、該パケット内に現在
     使用されているスロット数の表示を含む、請求項２２３から２３１のいずれかに
     記載のコンピュータシステム。
233. 【請求項２３３】 前記パケットは作成され且つ要求に従って破壊される、
     請求項２２３から２３２のいずれかに記載のコンピュータシステム。
234. 【請求項２３４】 部分的に完全なパケットのコンテンツを共に併合するこ
     とにより少なくとも部分において前記パケットを破壊する手段をさらに含む、請
     求項２２３から２３３のいずれかに記載のコンピュータシステム。
235. 【請求項２３５】 メモリグループにおいて各オブジェクトの状態をトレー
     スするステップと、 トレーシング・プロセス（白）中にオブジェクトがまだ遭遇されていないかに
     従って識別子を割当てるステップと、前記オブジェクトと識別子が参照する全て
     のオブジェクトはトレーシング・プロセス（黒）により遭遇され、オブジェクト
     自体は遭遇されるが参照されたオブジェクトのいくつかは訪問されていない（グ
     レイ）、 グレイ識別子に割当てられた１組または複数の組を離散パケットに分割するス
     テップと、 各前記パケットを、各前記スレッドが他の前記スレッドとパケットと独立に各
     パケット上で作業できるように各スレッドに割り当てるステップと、 を含む、使用していないメモリを解放するように、マルチスレッド環境において
     コンピュータシステムにおける並行不要部分整理システムを動作する方法
236. 【請求項２３６】 並行ガーベッジ・コレクタと、 メモリグループにおいて各オブジェクトの状態をトレーシングする手段と、 トレーシング・プロセス（白）中にオブジェクトがまだ遭遇されていないかに
     従って識別子を割当てる手段と、前記オブジェクトと識別子が参照する全てのオ
     ブジェクトはトレーシング・プロセス（黒）により遭遇され、オブジェクト自体
     は遭遇されるが参照されたオブジェクトのいくつかは訪問されていない（グレイ
     ）、 グレイ識別子に割当てられた１組または複数の組を離散パケットに分割する手
     段と、 各前記パケットを、各前記スレッドが他の前記スレッドとパケットと独立に各
     パケット上で作業できるように各スレッドに割り当てる手段と を含むコンピュータシステム。
237. 【請求項２３７】 並行不要部分整理システムを動作する手段と、 各パケットが所与の時間にせいぜいひとつのスレッドによりアクセス可能であ
     るようなパケットにグレイ待ち行列を分割する手段と、 を含むコンピュータシステム。
238. 【請求項２３８】 マルチスレッド環境において動作するように適用されて
     いる、請求項２３７に記載のコンピュータシステム。
239. 【請求項２３９】 パケット用のマネージャをさらに含む、請求項２２３か
     ら２３４、２３６、２３７、２３８のいずれかに記載のコンピュータシステム。
240. 【請求項２４０】 請求項２１１から２２２、２３５のいずれかに記載の方
     法によりプログラムされているコンピュータ。
241. 【請求項２４１】 請求項２１１から２２２、２３５のいずれかに記載の方
     法により実行されるコンピュータ。
242. 【請求項２４２】 ガーベッジ・コレクタを備え、該ガーベッジ・コレクタ
     は１組の部分的にトレースされるメモリ・オブジェクトを有し、前記組を離散パ
     ケットにおいてハンドルするようにプログラムされている、コンピュータシステ
     ム。
243. 【請求項２４３】 請求項２１１から２２２、２３５のいずれかに記載の方
     法を提供するプログラム、記録された該プログラムを有するコンピュータ読取り
     可能な記録媒体。
244. 【請求項２４４】 コンピュータシステムにおいて、１組の部分的にトレー
     スされるメモリ・オブジェクトを有するガーベッジ・コレクタを動作し、複数の
     離散パケットにおいて前記組をハンドリングするステップを含む方法を提供する
     プログラム、該プログラムを記録するコンピュータ読取り可能な記録媒体。
245. 【請求項２４５】 請求項２２３から２３４、請求項２３６から２４２のい
     ずれかに記載のコンピュータまたはコンピュータシステムを含む仮想マシン。
246. 【請求項２４６】 請求項２１１から２２２、２３５のいずれかに記載の方
     法により動作される仮想マシン。
247. 【請求項２４７】 請求項２３４または２４４に記載のコンピュータ読取り
     可能な記憶媒体により動作される仮想マシン。
248. 【請求項２４８】 実質的に図７Ａから図７Ｈを参照して記述されまたは図
     ７Ａから図７Ｈに例示された方法。
249. 【請求項２４９】 実質的に図７Ａから図７Ｈを参照して記述されまたは図
     ７Ａから図７Ｈに例示されたコンピュータ。
250. 【請求項２５０】 実質的に図７Ａから図７Ｈを参照して記述されまたは図
     ７Ａから図７Ｈに例示されたコンピュータシステム。
251. 【請求項２５１】 実質的に図７Ａから図７Ｈを参照して記述されまたは図
     ７Ａから図７Ｈに例示されたコンピュータ読取り可能な記録媒体。
252. 【請求項２５２】 実質的に図７Ａから図７Ｈを参照して記述されまたは図
     ７Ａから図７Ｈに例示された仮想マシン。
253. 【請求項２５３】 固有オペレーティングシステムと、非固有ソフトウエア
     を含み、非固有ソフトウエアは直接に割込みをハンドルするために配列されてい
     る、コンピュータシステム。
254. 【請求項２５４】 非固有ソフトウエアは翻訳言語を含む、請求項２５３に
     記載のコンピュータシステム。
255. 【請求項２５５】 非固有ソフトウエアはジャバ言語を含む、請求項２５４
     に記載のコンピュータシステム。
256. 【請求項２５６】 仮想マシンのように構成され、または仮想マシンを実現
     する、請求項２５３から２５５に記載のコンピュータシステム。
257. 【請求項２５７】 コンピュータシステムは固有オペレーティングシステム
     と、非固有ソフトウエアを含み、割込みは非固有ソフトウエアにより直接にハン
     ドルするために配列されている、コンピュータシステムを動作する方法。
258. 【請求項２５８】 割込みハンドリング方法を含み、割込みハンドリング方
     法は第１の割込みに先だって起動されように配列され、実行は待ち状態へ進みそ
     して割込みが発生する時に再開を生じる、コンピュータシステム。
259. 【請求項２５９】 前記割込みハンドリング方法は、待ち状態に持続してい
     る起動上のスタックを発生するために配列される、請求項２５８に記載のコンピ
     ュータシステム。
260. 【請求項２６０】 前記割込みハンドリング方法は起動上に実行スレッドを
     含むために配列され、該スレッドは、スタックが待ち状態に持続する方法では永
     久に非活動にされている、請求項２５８または２５９に記載のコンピュータシス
     テム。
261. 【請求項２６１】 前記方法は、割込みが生じる時にスタックを使用する制
     御の割込みフローを有することによりスレッドは明らかに非活動にされるように
     配列されている、請求項２６０に記載のコンピュータシステム。
262. 【請求項２６２】 割込みハンドリング方法は、複数の異なる待ち状態を含
     む、請求項２５８から２６１のいずれかに記載のコンピュータシステム。
263. 【請求項２６３】 割込みが発生する時に切り換えられる非固有割込みスレ
     ッド・スタックを有するコンピュータシステム。
264. 【請求項２６４】 前記非固有割込みスレッド・スタックは部分的に充てん
     されている、請求項２６２に記載のコンピュータシステム。
265. 【請求項２６５】 前記コンピュータシステムは仮想マシンとして構成され
     、または仮想マシンを実現する、請求項２５８から２６４のいずれかに記載のコ
     ンピュータシステム。
266. 【請求項２６６】 請求項２５３から２５６のいずれかに記載のコンピュー
     タシステムをさらに含む、請求項２５８から２６５のいずれかに記載のコンピュ
     ータシステム。
267. 【請求項２６７】 第１の割込みに先だって割込みをハンドリングする方法
     を起動するステップを含み、該方法の実行は待ち状態へと進み、割込みが発生し
     た時に再開する、コンピュータシステムを動作する方法。
268. 【請求項２６８】 スタックを残している待ち状態で終了した中間方法であ
     る、コンピュータシステムにおける割込みをハンドリングする方法。
269. 【請求項２６９】 割込みハンドラ方法は、割り込みが生じた時にスタック
     を使用する制御の割り込みフローを有することにより明らかに再起動される、請
     求項２６８に記載の方法。
270. 【請求項２７０】 割り込みハンドラ方法は非固有割り込み方法である、請
     求項２６７から２６９のいずれかに記載の方法。
271. 【請求項２７１】 潜在的なブロッキング同期化オペレーションが割り込み
     ハンドラ方法が実行される間になされる、請求項２５３から２５６、２５８から
     ２６６のいずれかに記載のコンピュータシステム。
272. 【請求項２７２】 割り込みハンドラは非固有割り込みハンドラを含み、第
     １の割り込みに先だって第１回の実行活動を実行する手段を含む、コンピュータ
     システム。
273. 【請求項２７３】 仮想マシンとして構成されまたは仮想マシンを実現する
     、請求項２７１または２７２の何れかに記載のコンピュータシステム。
274. 【請求項２７４】 請求項２５８から２６６のいずれかに記載のシステムを
     さらに含む、請求項２７１から２７３のいずれかに記載のコンピュータシステム
     。
275. 【請求項２７５】 割り込みハンドリング方法を実行している間に何らかの
     潜在的ブロッキング同期化オペレーションを防止するステップを含む、請求項２
     ５７および２６７から２７０のいずれかに記載の方法。
276. 【請求項２７６】 第１の割り込みに先だって第１回の実行活動を実行する
     ステップを含む非固有割り込みハンドラ方法を使用するコンピュータシステムに
     おける割り込みをハンドリングする方法。
277. 【請求項２７７】 割り込みハンドラ方法の事前決定するステップを含む、
     請求項２７６に記載の方法。
278. 【請求項２７８】 割り込みハンドラ方法のコード事前コンパイルするステ
     ップを含む、請求項２７７に記載の方法。
279. 【請求項２７９】 割り込みハンドラとガーベッジ・コレクタを含み、割り
     込みハンドラとガーベッジ・コレクタ間の相互動作が防止される、コンピュータ
     システム。
280. 【請求項２８０】 割り込みハンドラはオブジェクトを含み、該オブジェク
     トはガーベッジ・コレクタから離隔されている、請求項２７９に記載のコンピュ
     ータシステム。
281. 【請求項２８１】 割り込みハンドラはガーベッジ・コレクタから離隔され
     たヒープを含む、請求項２７９または２８０のいずれかに記載のコンピュータシ
     ステム。
282. 【請求項２８２】 割り込みハンドラによる以外の割り込みハンドラにおけ
     る参照フィールドの変更を防止する手段をさらに含む、請求項２８０または２８
     １のいずれかに記載のコンピュータシステム。
283. 【請求項２８３】 前記コンピュータシステムは、仮想マシンとして構成さ
     れまたは仮想マシンを実現する、請求項２７９または２８２の何れかに記載のコ
     ンピュータシステム。
284. 【請求項２８４】 請求項２７１ないし２７５のいずれかひとつに記載のコ
     ンピュータ・システムを更に含む請求項１ないし２８３のいずれかひとつに記載
     のコンピュータ・システム。
285. 【請求項２８５】 割込みハンドラおよびガーベッジ・コレクタ間の相互作
     用が阻止される、割込みハンドラおよびガーベッジ・コレクタを備えるコンピュ
     ータ・システムを動作させる方法。
286. 【請求項２８６】 前記割込みハンドラ装置がオブジェクトを含み、該割込
     みハンドラによる以外の割込みハンドラのオブジェクトの参照フィールドの変更
     が阻止される請求項２８５記載の方法。
287. 【請求項２８７】 仮想マシンとして構成されあるいは仮想マシンを実現し
     、割込みレベルにおける非ネイティブな割込みハンドラを含み、情報を割込みレ
     ベルから他のレベルへ移すことを可能にする手段を備えるコンピュータ・システ
     ム。
288. 【請求項２８８】 ネイティブな呼出しを用いて情報を割込みレベルから他
     のレベルへ移す手段を備える請求項２８７記載のコンピュータ・システム。
289. 【請求項２８９】 請求項２７９ないし２８４のいずれかひとつに記載のシ
     ステムを更に備える請求項２８７ないし２８８のいずれかひとつに記載のコンピ
     ュータ・システム。
290. 【請求項２９０】 割込みレベルにおける非ネイティブな割込みハンドラを
     含む仮想マシンとして構成されあるいは仮想マシンを実現するコンピュータ・シ
     ステムを動作させる方法であって、情報を割込みレベルから他のレベルへ移すこ
     とを含む方法。
291. 【請求項２９１】 請求項２５７、２６７ないし２７０、２７５ないし２７
     ８、２８５、２８６または２９０のいずれかひとつに記載の方法を実施するよう
     プログラムされたコンピュータ。
292. 【請求項２９２】 請求項２５７、２６７ないし２７０、２７５ないし２７
     ８、２８５、２８６または２９０のいずれかひとつに記載の方法を実施するため
     プログラムが記録されたコンピュータ読取り可能な記憶媒体。
293. 【請求項２９３】 図８ないし図８Ｄに関して実質的に記述された、コンピ
     ュータ・システムを動作させる方法。
294. 【請求項２９４】 図８Ａないし図８Ｄに関して実質的に記述されたコンピ
     ュータ・システム。
295. 【請求項２９５】 潜在的にポリモルフィックである方法に対する呼出しを
     含むコードをコンパイルする方法であって、ポリモルフィックでないという仮定
     に基いてコードをコンパイルすることを含む方法。
296. 【請求項２９６】 方法がポリモルフィックでないという仮定がなされると
     き、該方法がファイナルであると仮定されるようマークされる請求項２９５記載
     の方法。
297. 【請求項２９７】 コンパイルが方法に対する呼出しの最適化を含む請求項
     ２９５または２９６記載の方法。
298. 【請求項２９８】 前記最適化が方法のインライニングを含む請求項２９７
     記載の方法。
299. 【請求項２９９】 前記最適化が方法に対するパッチを形成することを含む
     請求項２９７記載の方法。
300. 【請求項３００】 前記仮定がなされたならばマーカを生成するステップを
     更に含む請求項２９５または２９９のいずれかに記載の方法。
301. 【請求項３０１】 前記コードが主パス断片である請求項２９５ないし３０
     ０のいずれかひとつに記載の方法。
302. 【請求項３０２】 前記コードがオブジェクト指向言語のコードである請求
     項２９５ないし３０１のいずれかひとつに記載の方法。
303. 【請求項３０３】 方法が潜在的に２９５ないし３０２のいずれかひとつに
     記載の方法を含む請求項１ないし３０２のいずれかひとつに記載の方法。
304. 【請求項３０４】 潜在的にポリモルフィックである方法に対する呼出しを
     含むコードをコンパイルするとき、コンパイラが方法がポリモルフィックでない
     という仮定に基いて前記コードをコンパイルするように構成される、コードをコ
     ンパイルするコンパイラを含むコンピュータ・システム。
305. 【請求項３０５】 方法がポリモルフィックでないという仮定がなされるな
     らば、ファイナルであると仮定されるものとして該方法をマークする手段を含む
     請求項３０４記載のシステム。
306. 【請求項３０６】 コンパイラが方法に対する呼出しを最適化する手段を含
     む請求項３０４または３０５のいずれかに記載のシステム。
307. 【請求項３０７】 前記仮定がなされたならばマーカを生成する手段を更に
     含む請求項３０４ないし３０６のいずれかひとつに記載のシステム。、
308. 【請求項３０８】 前記コードがオブジェクト指向言語のコードである請求
     項３０４ないし３０７のいずれかひとつに記載のシステム。
309. 【請求項３０９】 請求項２９５ないし３０２のいずれかひとつに記載の方
     法によりコードをコンパイルするコンパイラ。
310. 【請求項３１０】 請求項２９５ないし３０２のいずれかひとつに記載の方
     法によりコンパイルされるコード。
311. 【請求項３１１】 クラスをコンピュータ・システムへ導入する方法であっ
     て、クラスの方法が前にポリモルフィックでないと仮定されたかどうか判定する
     ステップを含む方法。
312. 【請求項３１２】 新たなクラスの方法が、コードのコンパイルにおいてポ
     リモルフィックでないと仮定されたことが見出されると決定されるならば、コン
     パイル・コードに対して変更が行われる請求項３１１記載の方法。
313. 【請求項３１３】 前記変更が方法に対する呼出しを含むコードに対して行
     われる請求項３１２記載の方法。
314. 【請求項３１４】 コンパイル・コードの変更がコンパイル・コードの削除
     を含む請求項３１２または３１３のいずれかに記載の方法。
315. 【請求項３１５】 コンパイル・コードの前記変更がパッチの削除を含む請
     求項３１２ないし３１４のいずれかひとつに記載の方法。
316. 【請求項３１６】 コンパイル・コードの変更がアトミックに行われる請求
     項３１２ないし３１５のいずれかひとつに記載の方法。
317. 【請求項３１７】 コンパイル・コードの変更に先立ちスタック・ウォーキ
     ングを実施するステップを含む請求項３１２ないし３１６のいずれかひとつに記
     載の方法。
318. 【請求項３１８】 新たなクラスの方法がコードのコンパイルにおいてポリ
     モルフィックでないと仮定されたことが見出されるならば、割込みが用いられる
     請求項３１１ないし３１７のいずれかひとつに記載の方法。
319. 【請求項３１９】 請求項３１１ないし３１８のいずれかひとつに記載の方
     法を含むコンピュータ・システムを動作させる方法。
320. 【請求項３２０】 コンピュータ・システムを動作させる方法であって、 所与のクラスに対する方法に対する呼出しをコンパイルするステップと、 クラスの方法がファイナルとしてトレースされ得るかを新たなサブクラスにつ
     いて判定するステップと、 方法がファイナルでなければ、所与のクラスに対する方法への呼出しのコンパ
     イル・バージョンを調整するステップと、 を含む方法。
321. 【請求項３２１】 クラスの導入前に前記コンパイル・コードの変更が実施
     される請求項３１１ないし３２０のいずれかひとつに記載の方法。
322. 【請求項３２２】 クラスの導入がクラス・ローダによるクラスのローディ
     ングである請求項３１１ないし３２１のいずれかひとつに記載の方法。
323. 【請求項３２３】 コンパイル・コードを含むシステムに対するクラス・ロ
     ーダを用いてクラスをローディングする方法であって、クラスによりオーバーラ
     イドされる仮定がコンパイル・コードにおいて行われたかどうかをクラス・ロー
     ダが判定する方法。
324. 【請求項３２４】 オーバーライドされるべき仮定がなされたならば、クラ
     ス・ローダがコンパイル・システムに対して呼出しを行う請求項３２３記載の方
     法。
325. 【請求項３２５】 新たなクラスを導入する手段を含むコンピュータ・シス
     テムであって、クラスの方法がポリモルフィックでないと前に仮定されたかどう
     かを判定する手段を含むシステム。
326. 【請求項３２６】 新たなクラスの方法がコードのコンパイルにおいてポリ
     モルフィックでないと仮定されたと判定されるならば、コンパイル・コードを変
     更する手段を更に含む請求項３２５記載のシステム。
327. 【請求項３２７】 前記システムがコンパイル・コードを削除する手段を含
     む請求項３２６記載のシステム。
328. 【請求項３２８】 パッチを削除する手段を含む請求項３２６ないし３２７
     のいずれかひとつに記載のシステム。
329. 【請求項３２９】 スタック・ウォーキング装置を含む請求項３２６ないし
     ３２８のいずれかひとつに記載のシステム。
330. 【請求項３３０】 インタプリタを更に含む請求項３２５ないし３２９のい
     ずれかひとつに記載のシステム。
331. 【請求項３３１】 所与のクラスについて方法に対する呼出しをコンパイル
     するコンパイラと、 新たなサブクラスについて、クラスの方法がファイナルとして前に処理された
     かどうか判定する手段と、 方法がファイナルでなければ、所与のクラスについて方法に対する呼出しのコ
     ンパイル・バージョンを調整する手段と、 を備えるコンピュータ・システム。
332. 【請求項３３２】 新たなクラスを導入する手段がクラス・ローダである請
     求項３２５ないし３３１のいずれかひとつに記載のシステム。
333. 【請求項３３３】 請求項３３２に記載のシステムにおいて使用されるクラ
     ス・ローダ。
334. 【請求項３３４】 請求項２９５ないし３０３または請求項３１１ないし３
     ２４のいずれかひとつに記載の方法を実施するプログラムが記録されたコンピュ
     ータ読取り可能な記憶媒体。
335. 【請求項３３５】 潜在的にポリモルフィックである方法に対する呼出しを
     含むコードをコンパイルする方法を実施するプログラムが記録されたコンピュー
     タ読取り可能な記憶媒体において、前記方法がポリモルフィックでないという仮
     定に基いて前記コードをコンパイルすることを含む方法。
336. 【請求項３３６】 クラスをコンピュータ・システムに導入する方法を実施
     するプログラムが記録されたコンピュータ読取り可能な記憶媒体において、クラ
     スの方法がポリモルフィックでないと前に仮定されたかどうか判定するステップ
     を含む方法。
337. 【請求項３３７】 請求項２９５ないし３０３または請求項３１１ないし３
     ２４のいずれかひとつに記載の方法を実施するようプログラムされたコンピュー
     タ。
338. 【請求項３３８】 潜在的にポリモルフィックである方法に対する呼出しを
     含むコードをコンパイルする方法に従ってプログラムされたとき、該方法がポリ
     モルフィックでないという仮定に基いてコードをコンパイルすることを含むコン
     ピュータ。
339. 【請求項３３９】 コンピュータ・システムへクラスを導入する方法に従っ
     てプログラムされたとき、該方法が、クラスの方法がポリモルフィックでないと
     前に仮定されたかどうか判定するステップを含むコンピュータ。
340. 【請求項３４０】 図９Ａないし図９Ｄに関して実質的に記述されたコード
     をコンパイルする方法。
341. 【請求項３４１】 図９Ａないし図９Ｄに関して実質的に記述された、クラ
     スを導入する方法。
342. 【請求項３４２】 図９Ａないし図９Ｄに関して実質的に記述されたコンピ
     ュータ・システム。
343. 【請求項３４３】 各々がリストにおけるエントリを指す次の各エントリ・
     ポインタが一緒に閉ループを形成するように、該リストにおけるエントリを指す
     次の各エントリ・ポインタを含む、コンピュータ・システムにおけるエントリの
     リストにおける特定のエントリをアクセスする方法であって、 前記エントリの１つに対する開始ポインタを読出すステップと、 前記エントリのどれが次を調べるか判定するため調べられているエントリに対
     する次のエントリ・ポインタが読出される、前記開始ポインタにより指示される
     エントリから更に始まるリストにおけるエントリを特定のエントリが見出される
     まで調べるステップと、 見出された特定の前記エントリをアクセスするステップと、 同じあるいは異なる特定のエントリに対する前記ステップの反復において前記
     検査ステップが前記の特定エントリの検査から始めるように、見出された特定の
     エントリを指示するように開始ポインタを重ね書きするステップと、 を含む方法。
344. 【請求項３４４】 特定の前記エントリが前記検査ステップの間見出されな
     い場合に、各エントリが１回調べられると該検査ステップが１回終了され、前記
     アクセス・ステップと重ね書きステップとが省かれる請求項３４３記載の方法。
345. 【請求項３４５】 コンピュータ・システムの動作方法であって、複数のス
     レッドを調べるステップを含み、各スレッドが共通のエントリのリストに関して
     請求項３４３または３４４に記載の各アクセス方法を実施し、各アクセス方法が
     エントリのリストに関して共通の前記開始ポインタを読出す方法。
346. 【請求項３４６】 前記開始ポインタを重ね書きするステップがアトミック
     である請求項３４３ないし３４５のいずれかひとつに記載の方法。
347. 【請求項３４７】 前記特定のエントリをアクセスするステップが読出しア
     クセス・ステップである請求項３４３ないし３４６のいずれかひとつに記載の方
     法。
348. 【請求項３４８】 コンピュータ・システムにおけるエントリのリストを形
     成する方法であって、 各エントリに次のエントリ・ポインタを提供するステップと、 エントリ・ポインタの閉ループを形成するように次のエントリ・ポインタを構
     成するステップと、 異なるエントリに対する点に重ね書きが可能な、エントリを指す開始ポインタ
     を提供するステップと、 を含む方法。
349. 【請求項３４９】 請求項３４８に記載の方法と請求項３４３ないし３４７
     のいずれかひとつに記載の方法とを含む、コンピュータ・システムを動作させる
     方法。
350. 【請求項３５０】 請求項３４３ないし３４９のいずれかひとつに記載の方
     法を実施するようプログラムされるコンピュータ・システム。
351. 【請求項３５１】 エントリのリストを記憶する手段と、 前記エントリの１つに対する開始ポインタを記憶する手段と、 前記開始ポインタを読出す手段と、 特定のエントリが見出されるまで、前記開始ポインタにより指示されるエント
     リで更に始まるリストにおけるエントリを調べる手段と、 見出された特定のエントリをアクセスする手段と を含むコンピュータ・システムであって、 見出された特定のエントリを指すように、前記開始ポインタを重ね書きする手
     段を特徴とするコンピュータ・システム。
352. 【請求項３５２】 各々が次の各エントリ・ポインタを含むエントリのリス
     トと、該エントリの１つに対する開始ポインタとが記憶されるコンピュータ・メ
     モリであって、次の前記エントリ・ポインタの全てがリストにおけるエントリを
     指示するコンピュータ・メモリ。
353. 【請求項３５３】 次の前記エントリ・ポインタが一緒に閉ループを形成す
     る請求項３５２記載のコンピュータ・メモリ。
354. 【請求項３５４】 請求項３５２または３５３に記載のメモリと、 前記開始ポインタを読出し、 特定のエントリが見出されるまで、開始ポインタにより指示されるエントリ
     から更に始まるリストにおけるエントリを調べ、 見出された特定のエントリをアクセスするようにプログラムされたプロセッ
     サと を含むコンピュータ・システムであって、 前記プロセッサが、見出された特定のエントリを指示するように前記開始ポイ
     ンタを書き変えるようプログラムされる ことを更に特徴とするコンピュータ・システム。
355. 【請求項３５５】 コンピュータ・システムにおけるリストのデータをアク
     セスする方法であって、 前記リストをループの形態で構成するステップと、 所与の要素をループでアクセスするステップと、 次のアクセスのため前記ループの先頭となる要素を選択するステップと、 を含む方法。
356. 【請求項３５６】 リストにおけるデータをアクセスするコンピュータ・シ
     ステムであって、 前記データを閉ループの形態で構成する手段と、 所与の要素をループでアクセスする手段と、 次のアクセスのため前記ループの先頭として前記要素を選択する手段と、 を含むコンピュータ・システム。
357. 【請求項３５７】 前記エントリまたは要素の少なくとも一部がそれぞれコ
     ンパイル・コードの各断片を含む請求項３４３ないし３５６のいずれかひとつに
     記載の方法、システムまたはメモリ。
358. 【請求項３５８】 前記エントリまたは要素の少なくとも一部がそれぞれ各
     キーを含む請求項３４３ないし３５７のいずれかひとつに記載の方法、システム
     またはメモリ。
359. 【請求項３５９】 コンピュータ・システムに請求項３４３ないし３４９、
     請求項３５７および３５８のいずれかひとつに記載の方法を実施させ、あるいは
     請求項３５１、３５４および請求項３５６ないし３５８のいずれかひとつに従っ
     て動作させるよう実行可能なコンピュータ・プログラムが記録されたコンピュー
     タ読取り可能な記憶媒体。
360. 【請求項３６０】 請求項３４３ないし３４９、請求項３５７および３５８
     のいずれかひとつに記載の方法を実施するようにプログラムされたコンピュータ
     。
361. 【請求項３６１】 図１０Ａ、図１０Ｂ、図１０Ｃないし図１０Ｄのいずれ
     かあるいは全てに関して実質的に記述されあるいは図示されるデータをアクセス
     する方法。
362. 【請求項３６２】 図１０Ａ、図１０Ｂ、図１０Ｃないし図１０Ｄのいずれ
     かあるいは全てに関して実質的に記述され図示されるコンピュータ・システム。
363. 【請求項３６３】 特定の仕様の実現であるコンピュータ・コードの第１の
     部分を特定の仕様の異なる実現であるコンピュータ・コードの第１の部分に対し
     テストする方法であって、 両方のコード部分において対応する同期点を規定するステップと、 両方のコード部分を実行するステップと、 前記同期点において両方のコード部分により生じる状態を比較するステップと
     、 を含む方法。
364. 【請求項３６４】 第１および第２のコード部分が、第１および第２の異な
     る実行能力によりそれぞれ実行される請求項３６３記載の方法。
365. 【請求項３６５】 前記第１および第２のコード部分が第１および第２の異
     なる仮想マシンによりそれぞれ実行される請求項３６４記載の方法。
366. 【請求項３６６】 前記第１および第２のコード部分がそれぞれネイティブ
     な方法またはファンクションを含み、前記第２のコード部分により要求される少
     なくとも１つのかかるネイティブな方法またはファンクションが前記第１の実行
     能力により実行され、その結果が前記第２の実行能力に要求される請求項３６５
     記載の方法。
367. 【請求項３６７】 前記第１の実行能力により実行されるべきネイティブな
     方法またはファンクションのリストを前記第１の実行能力から前記第２の実行能
     力へ提供するステップを更に含む請求項３６６記載の方法。
368. 【請求項３６８】 前記第１のコード部分における各同期点ごとに比較する
     ステップにおいて、前記第１の実行能力が前記第２のコード部分における対応す
     る同期点における前記第２の実行能力の状態を調べる請求項３６４ないし３６７
     のいずれかひとつに記載の方法。
369. 【請求項３６９】 前記第２のコード部分における各同期点ごとに、前記第
     ２の実行能力が、最新でないその状態の要素の少なくとも一部の値をセーブし、
     かかる状態要素の値を更新し、その状態要素の値を前記第１の実行能力へ移転し
     、次いで更新された状態要素のセーブされた値を復元する請求項３６８記載の方
     法。
370. 【請求項３７０】 前記第１および第２のコード部分が並列に実行される請
     求項３６３ないし３６９のいずれかひとつに記載の方法。
371. 【請求項３７１】 前記第１および／または第２のコード部分が動的にコン
     パイルされる請求項３６３ないし３７０のいずれかひとつに記載の方法。
372. 【請求項３７２】 前記同期点が、制御の条件付き移転、方法／ファンクシ
     ョン／手順の呼出しあるいは戻し、および制御の逆方向の移転から選択される請
     求項３６３ないし３７１のいずれかひとつに記載の方法。
373. 【請求項３７３】 前記第１および第２のコード部分がそれぞれ複数の実行
     スレッドを持ち、前記第１および第２のコード部分により生じた対応するスレッ
     ド間に対応が識別される請求項３６３ないし３７２のいずれかひとつに記載の方
     法。
374. 【請求項３７４】 かかる対応する同期点がこのような対応スレッドにおい
     て規定される請求項３７３記載の方法。
375. 【請求項３７５】 前記第１および第２のコード部分により動的に割付けら
     れる対応するオブジェクト間に対応が識別される請求項３６３ないし３７４のい
     ずれかひとつに記載の方法。
376. 【請求項３７６】 請求項３６３ないし３７５のいずれかひとつの方法を実
     施するようプログラムされたコンピュータ・システム。
377. 【請求項３７７】 特定の仕様の実現であるコンピュータ・コードの第１の
     部分を同じ仕様の異なる実現であるコンピュータ・コードの第２の部分に対しテ
     ストするコンピュータ・システムであって、 対応する同期点が両方のコード部分において規定され、 両方のコード部分を実行する手段と、 前記同期点における両方のコード部分により生じた状態を比較する手段と
     、 を備えるコンピュータ・システム。
378. 【請求項３７８】 特定の仕様の実現である第１のコンピュータ・コード部
     分を同じ仕様の異なる実現である第２のコンピュータ・コード部分に対しテスト
     するコンピュータ・システムであって、 対応する同期点が両方のコード部分において規定され、 前記第１のコード部分を実行する第１の実行能力と、 前記第２のコード部分を実行する第２の実行能力と、 を備え、 前記第１の実行能力もまた、前記同期点における胴部のコード部分により生じ
     た状態を比較するよう動作可能である コンピュータ・システム。
379. 【請求項３７９】 前記第１および第２の実行能力が第１および第２の異な
     る仮想マシンによりそれぞれ提供される請求項３７８記載のシステム。
380. 【請求項３８０】 請求項３６３ないし３７５のいずれかひとつの方法を実
     施するようプログラムされる請求項３７７ないし３７９のいずれかひとつに記載
     のシステム。
381. 【請求項３８１】 特定の仕様の実現であるコンピュータの第１のコード部
     分と同じ仕様の異なる実現であるコンピュータの第２のコード部分とが記録され
     たコンピュータの記憶媒体であって、対応する同期点が両方のコード部分におい
     て規定されるコンピュータの記憶媒体。
382. 【請求項３８２】 コンピュータ・システムに請求項３６３ないし３７５の
     いずれかひとつの方法を実施させ、あるいは請求項３７６ないし３８０のいずれ
     かひとつに従って動作させるプログラムが記録されたコンピュータの記憶媒体。
383. 【請求項３８３】 図１１Ａおよび図１１Ｂに関して実質的に記述され、同
     図に図示されたコンピュータ・コードをテストする方法。
384. 【請求項３８４】 図１１Ａおよび図１１Ｂに関して実質的に記述され図示
     されたコンピュータ・コードをテストするコンピュータ・システム。
385. 【請求項３８５】 自己修正する多重スレッド型コンピュータ・システムに
     おけるコンパイル・コードの２つの部分間にリンクを提供する方法であって、コ
     ンパイル・コードの１つの部分から他の部分へパッチを挿入することを含む方法
     。
386. 【請求項３８６】 パッチを挿入するステップが制御の転送命令を変更する
     ことを含む請求項３８５記載の方法。
387. 【請求項３８７】 制御の転送命令を変更するステップがアトミックに実施
     される請求項３８６記載の方法。
388. 【請求項３８８】 自己修正する多重スレッド型コンピュータ・システムに
     おけるコンパイル・コードの２つの部分間にリンクを提供する装置であって、コ
     ンパイル・コードの１つの部分から他の部分へパッチを挿入する手段を含む装置
     。
389. 【請求項３８９】 実行の２つのあり得るパスを含むコードをコンパイルす
     る方法であって、 前記実行パスの１つに対応するコードをコンパイルするステップと、 別のコード部分のアドレスへの点へアトミックに変更することが可能である制
     御転送命令をコンパイル・コードに含めるステップと、 を含む方法。
390. 【請求項３９０】 制御転送命令が、前記前記制御転送命令の最も最適な形
     態が用いられる場合より離れたアドレスを指示し得るタイプである請求項３８９
     記載の方法。
391. 【請求項３９１】 前記制御転送命令を含む外れたコード部分を形成するこ
     とを含む請求項３８９または３９０のいずれかに記載の方法。
392. 【請求項３９２】 自己修正する多重スレッド型コンピュータ・システムに
     おけるコンパイル・コードの部分を含むメモリを調べる方法であって、 コンパイル・コードの前記部分に対する任意のパッチを識別するステップと、 任意の前記パッチを指向し直すステップと、 を含む方法。
393. 【請求項３９３】 自己修正する多重スレッド型コンピュータ・システムに
     おけるコンパイル・コードを削除する方法であって、 削除されるべきコンパイル・コードのセクションを選択するステップと、 コンパイル・コードの前記セクションに対する任意のパッチを識別するステッ
     プと、 任意の前記パッチを指向し直すステップと、 コンパイル・コードの前記セクションを削除するステップと、 を含む方法。
394. 【請求項３９４】 任意の前記パッチがコンパイル・コードのセクションの
     アドレスへ指向される請求項３９２または３９３のいずれかに記載の方法。
395. 【請求項３９５】 継続コードが、以降の命令の解釈を行い、あるいはディ
     スパッチ・テーブルの転送を行うように構成される請求項３９４記載の方法。
396. 【請求項３９６】 パッチを指向し直す前記ステップがアトミックに行われ
     る請求項３９２ないし３９５のいずれかひとつに記載の方法。
397. 【請求項３９７】 コンパイル・コードの前記セクションのアドレスのハッ
     シュ値を計算し、コンパイル・コードの前記セクションに対する任意のパッチを
     識別するためパッチ・ブロックのハッシュ・テーブルを調べることを含む請求項
     ３９２ないし３９６のいずれかひとつに記載の方法。
398. 【請求項３９８】 コンパイル・コードの前記セクションから任意のパッチ
     を識別し、かかる任意のパッチを取除くことを更に含む請求項３９２ないし３９
     ７のいずれかひとつに記載の方法。
399. 【請求項３９９】 コンパイル・コードの部分が削除されるとき、自己修正
     する多重スレッド型コンピュータ・システムにおけるメモリを調べる方法であっ
     て、 コンパイル・コードの前記セクションから任意のパッチを識別するステップと
     、 任意のかかるパッチを取除くステップと、 を含む方法。
400. 【請求項４００】 コンピュータ・システムにおけるスタックのフレームを
     調べるステップと、 削除されるべきコンパイル・コードのセクションのアドレス範囲内にあるリタ
     ーン・アドレスを前記フレームが含むかどうかを識別するステップと、 前記リターン・アドレスが識別されるときフレームの内容を変更するステップ
     と、 を含む請求項３９２ないし３９９のいずれかひとつに記載の方法。
401. 【請求項４０１】 自己修正する多重スレッド型コンピュータ・システムに
     おけるメモリを調べてコンパイル・コードのセクションを削除させる方法であっ
     て、 コンピュータ・システムにおけるスタックのフレームを調べるステップと、 コンパイル・コードの前記セクションのアドレスの範囲内にあるリターン・ア
     ドレスをフレームが含むかどうか識別するステップと、 前記リターン・アドレスが見出されるとき前記フレームの内容を変更するステ
     ップと、 コンパイル・コードの前記セクションに対する任意のパッチを識別するステッ
     プと、 任意の前記パッチを指向し直すステップと、 を含む方法。
402. 【請求項４０２】 コンパイル・コードのセクションから任意のパッチを識
     別し、任意のかかるパッチを取除くことを更に含む請求項４０１記載の方法。
403. 【請求項４０３】 請求項３８５ないし４０２のいずれかひとつに記載の方
     法を含むコンピュータ・システムを動作させる方法。
404. 【請求項４０４】 コンパイル・コードのセクションを削除させるため自己
     修正する多重スレッド型コンピュータ・システムにおけるメモリを調べる装置で
     あって、 コンパイル・コードの前記セクションに対する任意のパッチを識別する手段と
     、 任意のかかるパッチを取除く手段と、 を備える装置。
405. 【請求項４０５】 自己修正する多重スレッド型コンピュータ・システムに
     おけるコンパイル・コードを削除する装置であって、 削除されるコンパイル・コードのセクションを選択する手段と、 コンパイル・コードの前記セクションに対する任意のパッチを識別する手段と
     、 任意のかかるパッチを指向し直す手段と、 コンパイル・コードの前記セクションを削除する手段と、 を備える装置。
406. 【請求項４０６】 コンパイル・コードのセクションのアドレスのハッシュ
     値を計算する手段と、コンパイル・コードの前記セクションに対する任意のパッ
     チを識別するためパッチ・ブロックのハッシュ・テーブルを調べる手段とを備え
     る請求項４０４または４０５のいずれかに記載の装置。
407. 【請求項４０７】 コンパイル・コードのセクションから任意のパッチを識
     別する手段と、任意のかかるパッチを取除く手段とを更に備える請求項４０４な
     いし４０６のいずれかひとつに記載の装置。
408. 【請求項４０８】 コンパイル・コードのセクションが削除されるべきとき
     、自己修正する多重スレッド型コンピュータ・システムにおけるメモリを調べる
     装置であって、 コンパイル・コードの前記セクションから任意のパッチを識別する手段と、 任意のかかるパッチを取除く手段と、 を備える装置。
409. 【請求項４０９】 請求項４０４ないし４０８のいずれかひとつに記載の装
     置を含むコンピュータ。
410. 【請求項４１０】 請求項３８５ないし４０３のいずれかひとつに記載の方
     法を実施するプログラムが記録されたコンピュータ読取り可能な記憶媒体。
411. 【請求項４１１】 請求項３８９ないし３９１のいずれかひとつの方法を実
     施するためのコンピュータ。
412. 【請求項４１２】 請求項３８５ないし３８７および請求項３８９ないし４
     ０３のいずれかひとつに記載の方法を実施するようプログラムされたコンピュー
     タ。
413. 【請求項４１３】 図１２Ａないし図１２Ｇに関して実質的に記述された方
     法、コンピュータ、記憶媒体、あるいは装置。
414. 【請求項４１４】 請求項１ないし４１３のいずれかひとつに記載の方法を
     実施するようプログラムされたコンピュータ。
415. 【請求項４１５】 コンピュータまたはコンピュータ・システムを記載する
     請求項１ないし４１４のいずれかひとつに記載されたコンピュータまたはコンピ
     ュータ・システムを備える仮想マシン。
416. 【請求項４１６】 添付図面のいずれか、あるいは一部、あるいはその全て
     に関して実質的に記述され、あるいはこれに図示された方法、コンピュータ、コ
     ンピュータ・システム、コンパイラ、装置、記憶媒体、あるいは仮想マシン。