JP2001060158A

JP2001060158A - モジュールごとのベリファイ処理

Info

Publication number: JP2001060158A
Application number: JP2000152854A
Authority: JP
Inventors: Gilad Bracha; ブラーチャギラッド; Sheng Liang; リャンシェン; Timothy G Lindholm; ジー．リンドルムティモシー
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1999-05-27
Filing date: 2000-05-24
Publication date: 2001-03-06
Also published as: US7051343B2; CN1292527A; EP1056003B1; AU3643500A; CA2309769A1; AU771028B2; US20040045019A1; CN1224903C; US6618769B1; EP1056003A3; EP1056003A2

Abstract

(57)【要約】（修正有）【課題】完全要求駆動型ロードを防止することなくリン
ク中にベリファイ処理を実行する。【解決手段】コンピュータ・プログラムのモジュール内
の命令について１回１モジュール・ベリファイ処理す
る。ロードされている最初のモジュール内の命令をチェ
ックして、その最初のモジュールとは異なる参照モジュ
ール内の情報が要求されているかどうかをまず決定す
る。もし、その情報が要求されていれば、その参照モジ
ュールのための制約が、その参照モジュールをアクセス
することなく、書き込まれる。リンク中に、ロードされ
ている最初のモジュールが、ベリファイ前処理に合格し
たかどうかが決定され、制約付きモジュールに課せられ
るベリファイ前処理制約が読み込まれる。その制約付き
モジュールが既にロードされていれば、ベリファイ前処
理制約が実施される。

Description

【発明の詳細な説明】

【０００１】本特許出願は、１９９５年１２月２０日出
願の、ＹｅｌｌｉｎとＧｏｓｌｉｎｇによる、米国特許
出願第５７５２９１号（Ｐ１０００）「ＢＹＴＥＣＯＤ
ＥＰＲＯＧＲＡＭＩＮＴＥＲＰＲＥＴＥＲＡＰＰＡ
ＲＡＴＵＳＡＮＤＭＥＴＨＯＤＷＩＴＨＰＲＥ
−ＶＥＲＩＦＩＣＡＴＩＯＮＯＦＤＡＴＡＴＹＰ
ＥＲＥＳＴＲＩＣＴＩＯＮＳＡＮＤＯＢＪＥＣＴ
ＩＮＩＴＩＡＬＩＺＡＴＩＯＮ」（現在、米国特許第
５７４０４４１号）、および、１９９８年８月１４日出
願の、ＢｒａｃｈａとＬｉａｎｇによる、米国特許出願
第０９／１３４４７７号（Ｐ３１３５）「ＭＥＴＨＯＤ
ＳＡＮＤＡＰＰＡＲＡＴＵＳＦＯＲＴＹＰＥ
ＳＡＦＥ，ＬＡＺＹ，ＵＳＥＲ−ＤＥＦＩＮＥＤＣＬ
ＡＳＳＬＯＡＤＩＮＧ」に関連する。それらの米国特許
出願は、本明細書において、参照されている。

【０００２】また、本特許出願は、１９９９年５月２７
日出願の、米国特許出願第０９／３２１２２３号（５０
２５３−２２８）（Ｐ３５６４）「ＦＵＬＬＹＬＡＺ
ＹＬＩＮＫＩＮＧ」、１９９９年５月２７日出願、米国
特許出願第０９／３２１２２６（５０２５３−２３０）
（Ｐ３５６６）「ＦＵＬＬＹＬＡＺＹＬＩＮＫＩＮ
ＧＷＩＴＨＭＯＤＵＬＥ−ＢＹ−ＭＯＤＵＬＥＶ
ＥＲＩＦＩＣＡＴＩＯＮ」、１９９９年５月２７日出願
の、米国特許出願第０９／３２０５８１（５０２５３−
２３５）（Ｐ３８１０）「ＣＡＣＨＩＮＧＵＮＴＲＵ
ＳＴＥＤＭＯＤＵＬＥＦＯＲＭＯＤＵＬＥ−ＢＹ
−ＭＯＤＵＬＥＶＥＲＩＦＩＣＡＴＩＯＮ」、およ
び、１９９９年５月２７日出願の、米国特許出願第０９
／３２１２２８号（５０２５３−２３６）（Ｐ３８０
９）「ＤＡＴＡＦＬＯＷＡＬＧＯＲＩＴＨＭＦＯＲ
ＳＹＭＢＯＬＩＣＣＯＭＰＵＴＡＴＩＯＮＯＦ
ＬＯＷＥＳＴＵＰＰＥＲＢＯＵＮＤＴＹＰＥ」に
も関連する。

【０００３】（技術分野）一般に、本発明は、コンピュ
ータ・プログラミング言語に関し、詳細には、要求駆動
型（ｌａｚｙ）ロードをサポートしながら、命令をベリ
ファイ処理する動的リンクを伴うコンピュータ・プログ
ラミングに関する。

【０００４】（背景技術）一般に、コンピュータ・プロ
グラムは、ソース・コード・ステートメントとして、人
間にとって理解しやすい高級言語で書かれている。コン
ピュータ・プログラムが実際に実行されるとき、コンピ
ュータは、中央演算処理装置（ＣＰＵ）の操作を直接制
御するバイナリ信号を含む命令から成るマシン・コード
に反応する。ソース・コードを読むコンパイラと呼ぶ特
定のプログラムを使用して、そのステートメントを特定
のＣＰＵのマシン・コードの命令に変換することは、当
業者によく知られている。このようにして生成されたマ
シン・コードの命令は、プラットホーム依存である。す
なわち、異なるコンピュータ装置は異なるマシン・コー
ドによって示される異なる命令セットを有する異なるＣ
ＰＵを有する。

【０００５】また、より簡単ないくつかのプログラムを
組み合わせて、より強力なプログラムを製作すること
は、当業者によく知られている。コンパイルする前のソ
ース・コードのセグメントを一緒にコピーして、そし
て、組み合わされたソースをコンパイルすることによっ
て、プログラムが組み合わされる。ソース・コード・ス
テートメントのセグメントが変更なしで頻繁に使用され
るとき、一度に自身でコンパイルして、１つのモジュー
ルを作成し、実際にその機能が必要であるとき、そのモ
ジュールと他のモジュールとを組み合わせることはしば
しば好ましいものである。コンパイルの後のモジュール
の組み合わせをリンクと呼ぶ。どのモジュールを組み合
わせるかは、実行条件に左右され、そのモジュールの組
み合わせを実行中、実行直前に行えば、そのリンクは、
動的なリンクと呼ばれる。

【０００６】リンクする利点は、プログラムを一度に、
１つのモジュールとして開発することができ、異なる開
発者が、おそらく異なる場所で、別々のモジュールを使
って同時に作業するとき、生産性を高めることができる
ことである。

【０００７】実行時に実行されるリンク、すなわち、動
的なリンクの利点は、プログラムを実行するとき、実行
時に使用されないモジュールをリンクする必要がないこ
とであって、行わなければならない操作の数を減少させ
て、同様におそらく、実行コードのサイズも減少させ
る。一般に、リンク前に、特定され、メモリに持ち込ま
れるモジュールをロードしなければならない。モジュー
ルが要求されるまでモジュールのリンクを遅延させるこ
とによって、モジュールのロードを遅延させる。これ
を、要求駆動型ロードと呼ぶ。

【０００８】独立に書き込みを行うことのできるいくつ
かのモジュールをアセンブルするときに、各モジュール
が、モジュール自体の中で適切に作動するかどうかをチ
ェックすること、すなわち、内部モジュール・チェック
と、モジュールが他のモジュールと協調して適切に作動
するかどうかをチェックする、すなわち、相互モジュー
ルチェックとを行うことは、賢明なことである。ＪＡＶ
Ａ（登録商標）プログラミング言語の設計者が使用して
いる用語の類似性によって、そのポスト・コンパイル・
モジュール・チェックを、ベリファイ処理と呼ぶことが
できる。

【０００９】動的リンクを有効に利用するコンピュータ
・アーキテクチャの例として、ハードウエア、またはソ
フトウエアに実装できる抽象コンピュータ・アーキテク
チャであるＳｕｎＭｉｃｒｏｓｙｓｔｅｍｓ, Ｉｎ
ｃ．のＪＡＶＡ（登録商標）（ＪＶＭ）などの仮想マシ
ン（ＶＭ）がある。ハードウエア、およびソフトウエア
に実装される両ケースのＶＭについて以下に記載する。

【００１０】仮想マシン（ＶＭ）は、以下の方法で、プ
ラットホーム独立とすることができる。ＪＡＶＡ（登録
商標）プログラミング言語などの高いレベルのコンピュ
ータ言語で表現されたステートメントを、システム独立
であるＶＭ命令にコンパイルする。マシン・コードが中
央演算処理装置（ＣＰＵ）に対応するように、ＶＭ命令
が、ＶＭに対応する。したがって、ＶＭ命令を１つのマ
シンから他のマシンに転送できる。異なる計算装置に
は、それぞれの計算装置に対応するＶＭを実装する必要
がある。ＶＭは、ＶＭ命令、１度に１つまたは複数の命
令を翻訳（ｔｒａｎｓｌａｔｅ）、または、通訳（ｉｎ
ｔｅｒｐｒｅｔｅ）してＶＭ命令を実行する。ＶＭの実
装は、多くの場合、特定のコンピュータのＣＰＵ上でプ
ログラムを実行することであるが、ＶＭ命令を特定のプ
ロセッサまたは装置の固有の命令セットとして使用する
こともできる。後者の場合、ＶＭは、「現実の」マシン
である。他の操作を動的リンクおよびベリファイ操作を
含むＶＭによって実行することもできる。

【００１１】そのようなＶＭを使用してプログラムを作
る過程には、ＶＭに関連し、２つの時間区分がある。
「コンパイル時間」と「実行時間」であって、「コンパ
イル時間」は高級言語をＶＭ命令に変換するステップを
示す。そして、「実行時間」はステップを示す。ＪＡＶ
Ａ（登録商標）ＶＭ環境では、モジュールを実行するた
めに命令を解釈するステップを示す。コンパイル時間と
実行時間の間、ステートメントからコンパイルされる命
令のモジュールは、長期の任意の期間休止状態でいるこ
とができる、または、ネットワーク全体に転送される場
合を含んで、１つの記憶装置から別の記憶装置に転送さ
れることができる。

【００１２】要求駆動型ロードのあるなしにかかわら
ず、ベリファイ処理を伴う動的なリンクを実現しようと
する際の問題をＪＡＶＡ（登録商標）仮想マシンを例に
して説明できる。ＪＶＭは、オブジェクト指向のＪＡＶ
Ａ（登録商標）ハイレベル・プログラミング言語に適し
た特定のＶＭ（仮想マシン）であって、動的リンク、ベ
リファイ処理、および要求駆動型ロードを実行するよう
に設計されている。そのことは、従来のＪＶＭを説明す
る、Ｔ．ＬｉｎｄｈｏｌｍとＦｒａｎｋＹｅｌｌｉｎ
（Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ，ＭｅｎｌｏＰａｒ
ｋ，Ｃａｌｉｆｏｒｎｉａ）による、「ＪＡＶＡ^TM Ｖ
ｉｒｔｕａｌＭａｃｈｉｎｅＳｐｅｃｉｆｉｃａｔ
ｉｏｎ」、１９９７に記載されている。

【００１３】ＪＡＶＡ（登録商標）プラットホームで使
用されるようなオブジェクト指向プログラミング技法は
広く使用されている。オブジェクト指向プログラムの基
本ユニットは、メソッド（手順）と、本明細書では、メ
ンバーと呼ばれるフィールド（データ）を有するオブジ
ェクトである。メンバーを共有するオブジェクトがクラ
スに分類される。クラスは、クラス内のオブジェクトの
共有されたメンバーを定義する。そして、各オブジェク
トは、オブジェクトが属するクラスの特定のインスタン
スである。実際には、クラスは、同様の特徴を有するマ
ルチプル・オブジェクト（マルチプル・インスタンス）
を生成するテンプレートとしてしばしば使用される。

【００１４】クラスの１つの特性は、クラス内に実際に
メンバーが実装されていることが、インタフェースに曝
される場合を除いて、外部のユーザと、他のクラスから
は隠す特徴を有するカプセル化である。したがって、ク
ラスが、分散開発に適したものとなって、たとえば、異
なる開発者が、ネットワーク上の異なる場所で開発する
分散開発に適している。完全なプログラムは、必要とさ
れるクラスを集めて、それらをリンクして、結果として
得られたプログラムを実行することによって形成される
ことができる。

【００１５】クラスには、継承という特徴がある。それ
は、１つのクラスが他のクラスのメンバーのすべてを継
承できるメカニズムである。他のクラスから継承される
クラスは、サブ・クラスと呼ばれる。属性を提供するク
ラスは、スーパー・クラスである。記号表現としては、
ｓｕｂｃｌａｓｓ＜＝ｓｕｐｅｒｃｌａｓｓ、または、
ｓｕｐｅｒｃｌａｓｓ＝＞ｓｕｂｃｌａｓｓと表現でき
る。サブ・クラスは、メンバーを追加してスーパー・ク
ラスの能力を広げることができる。サブ・クラスは、同
じ名前とタイプを有する代わりのメンバーを提供するこ
とによって、スーパー・クラスの属性を無効にすること
ができる。

【００１６】ＪＶＭは、コンパイルされたクラス特定の
バイナリ・フォーマット、つまりクラス・ファイル・フ
ォ−マット上で作動する。クラス・ファイルは、ＪＶＭ
命令と、記号テーブルと、他の付属の情報を含む。セキ
ュリティ上、ＪＶＭは、クラス・ファイル内の命令に、
フォーマット上、構造上強い制約を課す。特定の例で
は、ＪＶＭ命令は、タイプ仕様であって、以下で説明さ
れるように、所定のタイプであるオペランド上で作動す
るよう意図されている。いかなるＶＭでも同様の制約を
課してきた。ＪＶＭは、有効なクラス・ファイルで表現
できる機能を有する言語であれば、どのような言語も支
持する。クラス・ファイルは、ＪＡＶＡ（登録商標）プ
ログラム言語で表現されるプログラムを表すことができ
るオブジェクト指向構造を扱うことことができる様デザ
インされているが、また、いくつかの他のプログラミン
グ言語もサポートできる。

【００１７】クラス・ファイル内では、変数は記憶位置
であって、時々、プリミティブ・タイプ、または参照タ
イプのいずれかであるコンパイル−時間タイプと呼ばれ
る、タイプを連想してきた。参照タイプは、オブジェク
トへのポインタ、または、参照するオブジェクトがない
特別なヌル参照である。サブ・クラスのタイプは、その
スーパー・クラスのサブ・タイプであると言われてい
る。ＪＶＭのためのプリミティブ・タイプは、ｂｏｏｌ
ｅａｎ（真理値、真または偽をとる）、ｃｈａｒ（Ｕｎ
ｉｃｏｄｅキャラクタ用のコード）、ｂｙｔｅ（０、ま
たは１の符号付き８ビット）、ｓｈｏｒｔ（符号付き短
整数）、ｉｎｔ（符号付き整数）、ｌｏｎｇ（符号付き
長整数）、ｆｌｏａｔ（単精度浮動小数点数）、また
は、ｄｏｕｂｌｅ（２倍精度浮動小数点数）である。

【００１８】クラス・タイプのメンバー、フィールドと
メソッドであって、スーパー・クラスから継承されたメ
ンバーを含む。また、クラス・ファイルは、スーパー・
クラスを指定する。メンバーは、パブリックであり、い
かなるクラスのメンバーもアクセスできることを意味す
る。プライベート・メンバーは、宣言を含んだクラスの
メンバーのみがアクセスできる。プロテクテッド・メン
バーには、宣言クラスのメンバー、または宣言されてい
るパッケージのどこからもアクセスできる。ＪＡＶＡ
（登録商標）プログラミング言語で、クラスを分類する
ことができて、グループを指定することができる。指定
されたグループのクラスは、パッケージである。

【００１９】ＪＶＭのための実際の命令は、クラス・フ
ァイルによってコード化されるクラスのメソッドの中に
含まれる。

【００２０】ＪＡＶＡ（登録商標）言語プログラムが操
作の制約に違反すると、ＪＶＭは、無効の状態を検出し
て、例外として、プログラムにエラー信号を送る。例外
は、例外が起きて、コントロールが転送されると言われ
ているポイントにおいてキャッチされると言われてい
る。すべての例外は、クラスＴｈｒｏｗａｂｌｅのイン
スタンス、またはそのサブ・クラスによって表される。
そのようなオブジェクトを使用して、情報を例外が起き
ているポイントから、プログラムの一部、キャッチして
処理する例外ハンドラに運ぶことができる。

【００２１】ＪＶＭは、ある特定のクラスであるメソッ
ド「メイン」を呼び出して、実行を開始し、そのメソッ
ドにストリング・アレイである単一引数を渡す。したが
って、特定のクラスがロードされ、リンクされ、初期化
されることになる。

【００２２】ロードは、通常、前にソース・コードから
コンパイルされたバイナリ表記を検索することによっ
て、特定の名前を有するクラス、またはパッケージのバ
イナリ・フォームを見出すプロセスを示す。ＪＶＭで
は、ロード・ステップによって、必要なクラスを代表す
るクラス・ファイルを検索する。ロード・プロセスは、
ブート・ストラップ・クラス・ローダまたは、ユーザ定
義のクラス・ローダによって実現される。ユーザ定義の
クラス・ローダは、クラスによって定義される。クラス
・ローダは、指定されたクラスを代表しているクラス・
ファイルを見い出すために、特定の位置系列を示すこと
ができる。クラス・ローダは、期待された使用法に基づ
いてプリ・フェッチしているクラスのバイナリ表記をキ
ャッシュする、または、関連するクラスのグループを一
緒にロードすることができる。プリ・フェッチされる
か、または、まとめてロードされるクラスが多いほど、
ローダは、より「非要求駆動型（ｅａｇｅｒ）」であ
る。「要求駆動型（ｌａｚｙ）」ローダでは、できるだ
け少ないクラスがプリ・フェッチ、またはまとめてロー
ドされる。従来のＪＶＭ仕様では、非要求駆動型と、概
要求駆動型との間のロード状況を幅広いスペクトルで可
能にしている。

【００２３】ＶＭがクラス・ローダを呼んで、現在処理
されているクラスの命令を実行するのに、そのクラスが
初めて必要である時のみにクラスをロードするならば、
ＶＭは完全要求駆動型である。実現できれば、完全要求
駆動型ロードは、実行のときに必ずしも厳密には必要と
しないクラスをロードしてシステム・メモリや実行時間
などの実行時リソースを無駄遣いすることはしない。

【００２４】ＪＶＭにおけるリンクは、メモリ内のでバ
イナリ形式のクラスをキャッチして、そのクラスを実行
状態のＶＭに組み合わせて、実行させるプロセスであ
る。クラスは、リンクされる前にロードされなければな
らない。ＪＶＭ仕様によるリンクには、３つの異なる行
動様式がある。記号参照物のベリファイ処理、準備およ
び分割の３つである。

【００２５】ベリファイ処理の間、クラス・ファイル・
フォーマットのバイナリ・クラスに課せられる必要な制
約がチェックされる。そうすることが、ＪＶＭのセキュ
リティ条項にとって基本的なことである。ベリファイ処
理によって、無意味な結果につながる、または、オペレ
ーティング・システム、ファイル・システム、またはＪ
ＶＭ自身の保全性を危険にさらす不法な操作が、ＪＶＭ
によって試みられることは確実にない。しかしながら、
それらの制約をチェックするには、他のクラスの間のサ
ブ・タイプ関係に関する知識が必要になることが時々あ
る。したがって、ベリファイ処理に成功するしないは、
通常、ベリファイ処理されるクラスが参照する他のクラ
スの特性による。その結果、ベリファイ文脈のための現
在のＪＶＭ設計仕様が脆弱なものになる。

【００２６】ＪＶＭのバイナリ・クラスは、基本的に
は、一般的なプログラム・モジュールの手本であって、
コンパイルされたソース・ステートメントから生成され
る命令を含む。妥当性チェックの文脈の脆弱性は、それ
らのチェックが、１つ以上のモジュールにわたって広が
る情報に依存していることを意味する。すなわち、本明
細書では、それらのチェックは、相互モジュール（ｃｒ
ｏｓｓ−ｍｏｄｕｌｅ、または、ｉｎｔｅｒ−ｍｏｄｕ
ｌｅ）・チェックと呼ばれる。他のモジュールから情報
を必要としない妥当性チェックは、本明細書では、内部
モジュール（ｉｎｔｒａ−ｍｏｄｕｌｅ）・チェックと
呼ばれる。

【００２７】文脈に敏感なオブジェクトのベリファイ処
理には、いくつかの欠点がある。たとえば、ＪＡＶＡ
（登録商標）プラットホームのようなオブジェクト指向
プログラミングシステムでは、ベリファイアが、まだロ
ードされていないクラスの間のサブ・タイプ関係をチェ
ックする必要があるとき、ベリファイアは、クラス・ロ
ードを開始することになる。他のクラスを参照するコー
ドが実行されなくても、そのようなロードが起こること
がある。すなわち、文脈に敏感なベリファイ処理は、完
全要求駆動型ロードの妨げとなることがある。したがっ
て、実際に実行されている命令によって参照されるので
なければ、ロードはメモリを消費し、クラスをロードし
ないプロセスと比較すると、実行時間が長くなる。

【００２８】ベリファイ処理が文脈に敏感であると、実
行前の、１回１クラス、またはモジュールのベリファイ
処理に対応できない。あらかじめ、例えば、実行前に、
クラスをベリファイ処理できないので、上記は、欠点で
あって、ベリファイ処理は、実行コストを被らなければ
ならない。したがって、実行前に、１回１モジュール・
ベリファイ処理とも呼ばれる、モジュールごとのベリフ
ァイ処理を行う必要がある。そのようなベリファイ処理
は、本明細書では、ベリファイ前処理と呼ばれる。呼び
方を変える理由は、実行中の、ＪＶＭによるリンク中に
起こるベリファイ処理と、技術的に異なっているからで
ある。

【００２９】また、べリファイ処理は実行時に実行され
るので、一度実行されてベリファイ処理に合格したクラ
スは、そのクラスをロードするたびに改めてベリファイ
処理される。たとえ、そのクラスが、同じホストコンピ
ュータ上で同じアプリケーションで使用されていて、新
しいベリファイ問題は起こりそうにない、または、ベリ
ファイ処理に悪影響があるような変更がないように構成
できる場合でも、改めてベリファイ処理される。したが
って、必要のないベリファイ処理が行われることに通
じ、その結果、必要とするメモリが増大し、実行時間
も、必要以上に長くなる。つまり、実行時に、さらなる
ベリファイ処理がない、または最小のベリファイ処理で
すむ、ベリファイ前処理されたモジュールを使用できる
オプションが必要となる。

【００３０】ベリファイ前処理と、完全要求駆動型ロー
ドとに対する必要性は、それぞれ別物である。また、完
全要求駆動型ロードと共に、モジュールごとのベリファ
イ前処理をサポートする必要性もある。

【００３１】実行時ベリファイ処理の減少を含む、ベリ
ファイ前処理に対する必要性は、不適格または、危険を
及ぼす操作を防止するために、仮想マシンに供給される
すべてのモジュール、または、いかなる計算構造も、実
行時にチェックされることを要求するセキュリティに関
連する目標と衝突することがある。たとえば、インター
ネットからのモジュールのダウンロードや、インターネ
ットからのベリファイ前処理出力などの信頼性のない状
況では、アタッカーによって、ベリファイ前処理出力が
スプーフィングされる可能性がある（おそらく悪性のク
ラスを良性のクラスに見せかけることがある）。したが
って、インターネット全体にわたって、モジュールをダ
ウンロードするような信頼性のない状況で使用可能なベ
リファイ前処理に対する必要性がある。

【００３２】完全要求駆動型ロード、またはモジュール
ごとのベリファイ前処理に対する必要性によって、タイ
プ格子の代わりになる表現の必要性が生じる。タイプ格
子は、タイプの間のサブ・タイプ関係を表現する数学的
な構造である。タイプ格子の表現は、実行時における、
クラスのタイプとサブ・タイプを示すためにＪＶＭによ
って組み込まれている。ＪＶＭは、また、リンクされて
いるクラスのすべての属性の参照とタイプを維持してい
る。同様の実行時構造が、いかなる動的なリンク・プロ
セスにも役に立つことが期待される。クラスごとのベリ
ファイ前処理、または完全要求駆動型ロードを支持する
ために、タイプ格子に関する十分な知識なしに、タイプ
・チェックを実行しなければならない。通常、タイプ格
子に関しては、そうでなければまだロードされる必要が
ない他のモジュールにおいて、大部分が定義されてい
る。特に、ＪＶＭは、通常、ベリファイ処理中に、タイ
プ格子内のＬＵＢ（最小上界）タイプを見つける必要が
ある。したがって、タイプ格子が利用できないときにさ
えＬＵＢに依存する機能を実行する必要がある。

【００３３】（発明の開示）本発明の上記のおよび他の
特徴と、態様と、利点は、添付の図面を参照して行われ
る、本発明の以下の詳細な記載によってより明らかにな
るであろう。

【００３４】本発明の目的は、完全要求駆動型ロードを
防止することなく、リンク中にベリファイ処理を実行す
ることである。命令（たとえば、メソッドについて）を
実行中に、特定の定められたポイントで、参照モジュー
ル（たとえば、クラス）の分割すべてを、要求駆動型で
行うよう要求することは、動的なリンク、特に、ＪＶＭ
にとって有利である。その利点は、・一度書き込めば、いつでも実行できる（Ｗｒｉｔｅ
ｏｎｃｅ，ｒｕｎａｎｙｔｉｍｅ（ＷＯＲＡ））特性
が改善される。リンケージ・エラーに関するプログラム
の挙動は、すべてのプラットホームと実行について同じ
である。・試験性が大いに改善される。たとえば、クラスまた
はメソッドを見つけることができない場合、クラス、ま
たはメソッドをリンクすることのできるすべての場合を
想定して、それらのすべての場合の例外処理に対応しよ
うとする必要がない。・ユーザは、確実で簡単な方法で、モジュールの存在
を決定することができる。たとえば、ユーザは、異なる
バージョンが利用可能でなければ、実行されないプログ
ラム・ブランチを参照することによって、異なるバージ
ョンの実行環境において欠けているモジュールを呼び出
すことにより生じるリンケージ・エラーを避けることが
できる。従来のＪＶＭ仕様のロード状況では、上記の利
点は生かせない。

【００３５】本発明の別の目的は、１回１モジュール・
ベリファイ前処理を提供することである。また、本発明
のさらなる目的は、実行時ベリファイ処理を抑えるため
に、ベリファイ前処理命令を利用することである。ＪＡ
ＶＡ（登録商標）プラットホームのユーザのなかには、
文脈不感性の、または文脈独立性のベリファイ・チェッ
クを数クラスについて実行することを望んでいるユーザ
もいるだろう。コンパイル中、またはコンパイル後、お
よび実行前に実行できる、文脈独立性のチェックには多
くの利点がある。その利点は、・実行前に、ベリファイ・エラーを検出することがで
きる。・まだ必要なら、実行時のリンク・コンポーネント
（ソフトウエア部品）は、含まれるベリファイ・コード
の量が減少するので、たとえ要求されたとしても、より
小さく、かつより簡単である。そして、・ユーザは、モジュールを（安全な倉庫、たとえば、
ＲＤＢＭＳ（ｒｅｌａｔｉｏｎａｌｄａｔａｂａｓｅ
ｍａｎａｇｅｍｅｎｔｓｙｓｔｅｍ）に）アプリケ
ーションごと（ａｐｐｌｉｃａｔｉｏｎｂｙａｐｐ
ｌｉｃａｔｉｏｎ）ベースではなく、モジュールごと
（ｍｏｄｕｌｅ−ｂｙ−ｍｏｄｕｌｅ）ベースで記憶さ
せることが可能で、実行前も、できるだけ多くの仕事を
することができる。したがって、必要のないベリファイ
処理を取り除いて、ベリファイ処理の実行コストを減少
させる、または取り除く。

【００３６】本発明の別の目的は、同時に両者の利点を
生かすために、１回１モジュール・ベリファイ前処理
と、完全要求駆動型ロードを可能にする実行時ベリファ
イ処理とを組み合わせることを可能にすることである。

【００３７】本発明のもう１つ目的は、信頼性のないソ
ースからのクラスをベリファイ前処理できるようにし
て、ベリファイ前処理の利点を生かせる状況を拡大する
ことである。

【００３８】本発明のさらなる目的は、相互モジュール
の妥当性チェックを簡素化するため、タイプ格子に関す
る知識に欠けているとき、ＬＵＢの代替を利用すること
である。

【００３９】本発明の上記の、および他の目的と、利点
が、リンク前に、コンピュータ・プログラムのモジュー
ル内の命令を１回１モジュール・ベリファイ処理するメ
ソッド、コンピュータ・プログラム、信号伝送装置によ
って得られる。本発明の本態様では、ロードされている
最初のモジュール内の命令をチェックして、その最初の
モジュールと異なる参照モジュール内の情報が要求され
るかどうかを決定するステップを含む。もしその情報が
要求されれば、その参照モジュールをロードすることな
くその参照モジュールの制約を書き込む。

【００４０】本発明の他の態様によれば、コンピュータ
・プログラムのベリファイ前処理されたモジュールの命
令をリンク中にベリファイ処理する。メソッド、コンピ
ュータ・プログラム生成物、伝送信号および装置は、ロ
ードされた最初のモジュールがリンク前に１回１モジュ
ール・ベリファイ処理に合格したどうかを決定するステ
ップを含む。もし、その最初のモジュールがそのような
ベリファイ処理に合格していれば、もしあれば、制約付
きモジュールに課せられるベリファイ前処理制約を読み
込む。ベリファイ前処理制約が読み込まれていれば、そ
の制約付きモジュールがロードされているかどうかを決
定する。その制約付きモジュールがロードされていれ
ば、そのベリファイ前処理制約を実施する。

【００４１】本発明のさらに他の態様によれば、ベリフ
ァイ前処理システムは、ネットワークと、コンピュータ
・プログラムのモジュールを記憶するための、ネットワ
ークに接続された、コンピュータが読み込みできる記憶
媒体を含む。モジュールをロードできるメモリもまたネ
ットワークに接続されている。ネットワークに接続され
たプロセッサは、ロードされている最初のモジュール内
の命令をチェックして、その最初のモジュールと異なる
参照モジュール内の情報が必要となるかどうかをリンク
前に決定し、そして、その情報が要求されるならば、そ
の参照モジュールをロードすることなく、その参照モジ
ュールのための制約を書き込むよう構成されている。そ
の結果、１回１モジュール・ベリファイ前処理がリンク
前に実行される。同じ、または異なる１つのプロセッサ
がネットワークに接続されて、ロードされた最初のモジ
ュールが、リンク前に１回１モジュール・ベリファイ処
理に合格したかどうかをリンク中に決定するよう構成さ
れている。その最初のモジュールがベリファイ処理に合
格していれば、もしあれば、制約付きモジュールに課せ
られるベリファイ前処理制約を読み込む。ベリファイ前
処理制約が読み込まれていて、その制約付きモジュール
が既にロードされていれば、そのベリファイ処理制約が
実施される。その結果、リンク前に１回１モジュール・
ベリファイ処理を実行し、リンク中はベリファイ処理を
抑えるシステムが得られる。

【００４２】表記法および標準名称以下の詳細な記載を、コンピュータ、または、コンピュ
ータ・ネットワーク上で実行されるプログラム・プロシ
ージャで提示することができる。それらのプロシージャ
による記載と表現は、成果物の内容を最も効率的に表現
するのに、当業者が使用する方法である。

【００４３】本明細書におけるプロシージャは、一般
に、望ましい結果に通じる自己矛盾のないステップの系
列であると考えられている。それらのステップは、物理
量を物理的に操作することを必要とする。通常、必ずし
も必須というわけではないが、それらの量は、記憶さ
れ、転送され、結合され、比較され、または、他の方法
で操作されることができる電気信号、または磁気信号の
形式で表現される。それらの信号を、ビット、バリュ
ー、要素、記号、キャラクタ、用語、数などで表現する
と、主に共通に使用されるという理由から、時には便利
であると判る。しかしながら、それらの、また同様の用
語のすべてを、適切な物理量と関連づけられなければな
らないことと、それらは、それらの量に適用された単に
便利なラベルにすぎないことに注意されたい。

【００４４】さらに、実行される操作は、通常、人間の
オペレータによって実行される精神的な操作と関連づけ
られる、加算や比較などの用語で表現されることが多
い。人間のオペレータのそのような能力は、本発明の一
部分を形成している本明細書に記載された操作において
必要なく、あるいは大部分において望まれているもので
もない。操作はマシン操作である。本発明の操作を実行
するために役に立つマシンは、汎用のデジタル・コンピ
ュータ、または同様の装置を含む。

【００４５】また、本発明は、それらの操作を実行する
ための装置に関連する。特に、その装置は、目的を果た
すために特別に組み立てることもできる。または、コン
ピュータに記憶されたコンピュータ・プログラムによっ
て、選択的に作動させられる、または再構成される汎用
計算機を含むこともできる。本明細書において提示され
たプロシージャは、必ずしも、本質的に、特定のコンピ
ュータ、または他の装置に関連しているわけではない。
本明細書の技法によって書かれているプログラムを使っ
て、様々な汎用マシンを使用できる。または、必要なメ
ソッド・ステップを実行するより専門化した装置を組み
立てると便利であることが判るであろう。様々なそれら
のマシンに要求される構造は、以下の記載から明らかに
されるだろう。

【００４６】図１Ａは、本発明の実行に適したタイプの
コンピュータを示す。図１Ａに外観図が示されたコンピ
ュータ・システムは、ディスク・ドライブ装置１１０Ａ
と１１０Ｂを有する中央演算処理装置１００を備える。
ディスク・ドライブ装置１１０Ａと１１０Ｂは、コンピ
ュータ・システムが装備可能な複数のディスク・ドライ
ブ装置を記号で表しているにすぎない。通常、それらの
ディスク・ドライブ装置は、１１０Ａなどのフロッピー
（登録商標）・ディスク・ドライブ装置と、ハード・デ
ィスク・ドライブ装置（図示されない）と、スロット１
１０Ｂによって示されるＣＤ−ＲＯＭドライブ装置また
はＤＶＤドライブ装置を含むであろう。通常、ドライブ
装置の数とタイプは、コンピュータ構成によって異な
る。コンピュータは、情報が表示される表示装置１２０
を有する。通常、キーボード１３０とマウス１４０も入
力装置として利用可能である。図１Ａに示されるコンピ
ュータを、ＳｕｎＭｉｃｒｏｓｙｓｔｅｍｓ社のＳＰＡ
ＲＣワークステーションとすることができる。

【００４７】図１Ｂには、図１Ａのコンピュータの内部
のハードウェアのブロック構成図が示されている。バス
１５０は、コンピュータの他のコンポーネントを内部接
続する主要情報ハイウエイとして機能する。ＣＰＵ１５
５は、システムの中央演算処理装置であって、プログラ
ムを実行するのに必要な計算と論理演算を実行する。読
出し専用記憶装置（１６０）とランダム・アクセス・メ
モリ（１６５）は、コンピュータの主記憶装置を構成す
る。ディスク制御装置１７０は、システム・バス１５０
に１つまたは複数のディスク・ドライブ装置を接続す
る。それらのディスク・ドライブ装置は、１７３などの
フロッピー・ディスク・ドライブ装置、１７２などの内
部または外部ハード・ディスク・ドライブ装置、１７１
などのＣＤーＲＯＭドライブ装置、またはＤＶＤドラ
イブ装置（ＤｉｇｉｔａｌＶｉｄｅｏＤｉｓｋｓ）
とすることができる。表示装置インタフェース１２５が
表示装置１２０に接続され、バスからの情報を表示装置
上で見ることができる。外部装置との通信は、通信ポー
ト１７５を通じて可能である。

【００４８】図１Ｃは、図１Ｂの１７３、または図１Ａ
の１１０Ａなどのドライブ装置とともに使用できる記憶
媒体の例を示す。通常、フロッピー・ディスク、ＣＤ−
ＲＯＭ、またはＤＶＤ（ＤｉｇｉｔａｌＶｉｄｅｏ
Ｄｉｓｋ）などの記憶媒体は、本発明に従ってコンピュ
ータが機能を実行可能にするようコンピュータを制御す
るプログラム情報を含む。

【００４９】図１Ｄは、本発明のいくつかの態様による
データとプログラムを備えるのに適したネットワーク・
アーキテクチャのブロック構成図である。ネットワーク
１９０は、プログラムとデータのダウンロードのための
サーバ１９５などの１つまたは複数のサーバとクライア
ント・コンピュータ１００とを接続する機能を有する。
また、クライアント１００’を、ＩＳＰ１８０などのネ
ットワーク・サービス・プロバイダを通して、ネットワ
ーク１９０に接続することができる。仮想マシン（Ｖ
Ｍ）、またはハードウェアまたはソフトウェアのいずれ
かに実装されている他の計算アーキテクチャに関連する
要素を、以下に記載するように、ネットワーク全体に分
配することができる。

【００５０】図１Ｅは、仮想マシンに関連するコンポー
ネントを有するよう構成された単一のコンピュータを示
す。コンポーネントには、コンピュータ内の記憶媒体の
１つまたは複数の論理ブロックの中のソース・コード・
ステートメント１６２と、また、ソース・コード１６２
をコンパイルしてＶＭ命令などの命令を含む１つまたは
複数のモジュール１６５、１６６を作成するコンパイラ
１６４と、さらに、１つまたは複数のモジュール１６
５、１６６を入力要素として、それらのモジュールが作
成するプログラムを実行する仮想マシン（ＶＭ）１６７
などのプロセッサとが含まれる。図１Ｅに１つのコンピ
ュータ内に示されているが、モジュール１６５と、プロ
セッサ、たとえばＶＭ１６７とが、少なくとも一時的に
も同じコンピュータ内に存在する必要があることを理解
されたい。コンパイラを作動させてソース・コードから
モジュールを作成する異なったコンピュータからモジュ
ールを送ることができる。たとえば、図１Ｄでは、サー
バ１９５のコンパイラ１９４とソース・コード１９２を
示し、また、クライアント・コンピュータ１００、１０
０’それぞれに実装された２つの異なる仮想マシン１５
０、１５１を示す。ソース・コード１９２（および図１
Ｅの１６２）は、いかなる言語でもよいが、好ましく
は、ＪＡＶＡ（登録商標）言語プログラミング言語であ
る。また、人間であるプログラマが書くことも可能であ
り、さらに別のプログラムが出力することもできる。サ
ーバ１９５のコンパイラ１９４が作成するモジュール１
９６をネットワーク１９０全体に伝送でき、モジュール
として、たとえば１５６として、クライアント・コンピ
ュータ、たとえば１００内に記憶できる。その場合、実
装されたプラットホーム特定のＶＭ、たとえば１５０
は、モジュール１５６内の命令を実行することができ
る。

【００５１】明らかに、本発明は、ＪＶＭを使用して記
述されているが、ＪＶＭに限定されているわけではな
い。本発明は、実行時に様々なソースからプログラム・
モジュールをリンクし、それらのプログラム・モジュー
ルを実行する前にそれらのプログラム・モジュールをベ
リファイ処理するいかなるプロセスにも適用できる。

【００５２】本発明によって解決されるべき問題を生じ
る状態を示すクラスを代表するプログラム・モジュール
のための疑似ソース・コードの例として、図２は、ＪＡ
ＶＡ（登録商標）プログラミング言語に類似のプログラ
ミング言語で書かれた疑似ソース・コードを示す。第１
行はクラスが「ＢＡＲ」であることを示し、第１の省略
符号は、クラスＢＡＲの定義に貢献する他のステートメ
ントを表すが、ここでは論じない。次の行から本図例の
終わりまでは、クラスＢＡＲ（ＢＡＲ．ＦＯＯとも表示
される）においてＦＯＯと呼ばれるメソッドを定義す
る。タイプ「ｖｏｉｄ」は、メソッドＦＯＯの呼び出し
終了時に、いかなる値も戻されないことを示す。次の行
は、実行時に２つのブランチを有する「ｉｆｅｌｓ
ｅ」コンストラクタを導入する。「ａｒｇ」と呼ぶメソ
ッド引数が真ならば、次の省略符号セットが表す、１つ
のブランチを実行する。処理ステートメントは、クラス
・タイプがＡの「ｖａｒ」と呼ばれる変数をクラスＢの
新しいインスタンス（ｉｎｓｔａｎｃｅ）とすることを
表している。したがって、そのブランチでは、２つの他
のクラス、クラスＡとクラスＢが、参照クラスとして
参照される。次の行、ｉｆｅｌｓｅコンストラクタの
ｅｌｓｅは、そのメソッドの別の１つのブランチ、ａｒ
ｇが偽のときのブランチの始まりを示している。その別
の１つのブランチを、次のブレースとの間に置き、別の
省略符号セットで表して、そのブランチでは、クラスＡ
も、クラスＢも参照されないことを示す。そのブランチ
は、変数Ｚの値に元の値を２乗した値が代入されるステ
ートメントにおいて再び１つになる。

【００５３】例示のクラスＢＡＲとそのメソッドＦＯＯ
を使用して、非要求駆動型ローディングと、概要求駆動
型ローディングと、完全要求駆動型ローディングとの
差、および本発明の利点が、ＪＶＭなどの仮想マシンに
よって説明される。もちろん、ＪＶＭは、図２にリスト
されているＪＡＶＡ（登録商標）のようなプログラミン
グ言語上では作動しないが、しかし、通常、図２にリス
トされているような高級プログラミング言語コード上で
作動するコンパイラによって生成された命令を含むモジ
ュール上では作動する。

【００５４】図３は、ＪＶＭによる例示のクラスＢＡＲ
の完全非要求駆動型ローディングを表している。ステッ
プ３１０において、クラスＢＡＲにおいて定義されたメ
ソッドＦＯＯを呼び出すときに、クラスＢＡＲが必ずし
もロードされているとは限らないと仮定して、ＪＶＭで
は、ＢＡＲのためのクラス・ローダ、たとえば、ローダ
Ｌ１を使用していずれかの記憶装置からクラスＢＡＲ
がメモリにロードされる。現在のクラスは、クラスＢＡ
Ｒである。現在のクラスのＢＡＲは、クラスＡとクラス
Ｂを参照するので、ステップ３２０において、両クラス
のためのローダがまだロードされていなければ、同様
に、両クラスのためのローダをコールする。図３では、
クラスＡとクラスＢのためのクラス・ローダは、それぞ
れＬ２およびＬ３として示される。しかし、Ｌ１、Ｌ
２、およびＬ３は、すべて同じビルトイン、またはユー
ザが定めたクラス・ローダであることもあり、または、
いずれか２つが同じであってもよく、または、いずれも
異なっていてもよい。

【００５５】ステップ３３５のリンク中に、ＪＶＭがベ
リファイ処理を遂行する。ベリファイ処理中に用いられ
る手順についての詳細は、上記で参照された米国特許第
５７４０４４１号に記載されている。その特許に記載さ
れているように、ベリファイ処理には、不正タイプの
データ、または仮想マシンのオペランド・スタックのア
ンダー・フロー、またはオーバー・フローを引き起こす
いかなる命令をも処理しようとするメソッドにおけるい
かなる命令列をも特定することを含む。ＪＶＭでの命令
は、タイプ指定型であって、命令によって作動するオペ
ランドは、命令が定義するタイプに適合しなければなら
ない。オペランド・スタックのオーバーフローは、クラ
ス・ファイルにおいて定義されたスタックの最大サイズ
を超える、すなわち、スタックが既にフルであるオペラ
ンド・スタックに、基本値やオブジェクト参照などのア
イテムを置こうとする試みである。命令が、オペランド
・スタックからアイテムを取り去ろうとするときに、ス
タックに有効なアイテムがないとき、すなわち、スタッ
クが既に空であるとき、オペランド・スタック・アンダ
ー・フローが起こる。モジュール内の命令を実行する前
に実行できる妥当性チェックすべてをベリファイ処理に
含むことができると予想される。

【００５６】モジュールのベリファイ処理に合格しない
と、仮想マシンは、エラーを特定して、そのモジュール
内にある命令を実行しないようにすべきである。ＪＶＭ
の場合、ＪＶＭは、クラス例外処理ハンドラが洗練され
た方法で処理できる、リンクまたはベリファイ・エラー
・メッセージ（図示せず）を発する。

【００５７】モジュールのベリファイ処理が成功して、
リンクが成立すると、実行開始可能となる。本図例の場
合では、ＪＶＭが各命令を翻訳して該命令を実行すると
きに、ステップ３４０において、現在のクラスＢＡＲを
初期化でき、ステップ３５０において、現在のクラスで
あるメソッドＦＯＯ．ＢＡＲを実行する。翻訳プログラ
ムは、リンク・ステップ３３５の間に実行されるベリフ
ァイ処理によって既に終了しているので、タイプ、また
は、オペランド・スタックのオーバーフローまたはアン
ダーフローをチェックする必要はない。

【００５８】上述の動的なリンクを伴うプロセスの２つ
の利点は、他の人々が開発しコンパイルしたクラスを安
全に使用できることと、リンクが成立した後の実行がよ
り速いということである。リンク成立中に実行する前
に、無効で、または危険となり得る操作を防止するよ
う、ベリファイ処理されているので、他の人々がコンパ
イルしたクラスを使用できる。タイプ・チェックと、オ
ペランド・スタック・オーバーフローおよびアンダーフ
ローの各処理をベリファイ処理中に実行終了するので、
実行時間を短縮される。同様に、ベリファイ処理中に実
行された他の妥当性チェックも、実行時に省略しても安
全である。

【００５９】要求駆動型ローディングでは、図４Ａに示
すように、実行時に必要となるまで、クラスはロードさ
れない。その利点を、図２に例示したサンプル・クラス
ＢＡＲを使用して説明できる。ａｒｇが偽ならば、「ｉ
ｆ」ブランチにおいて、クラスＡとクラスＢを参照する
よう処理することは決してなく、またクラスＡも、クラ
スＢもロードする、またはリンクする必要がなくなる。
したがって、要求駆動型ローディングを使用すると、実
行処理時間が短縮される。

【００６０】たとえば、図４Ａに示すように、ステップ
４１０において、クラス・ローダＬ１を使用してクラス
ＢＡＲをロードした後すぐ、ＢＡＲが参照するクラスＡ
とクラスＢを、ロードすることはしない。代わりに、ス
テップ４３５においてリンク中に、クラスＢＡＲをベリ
ファイ処理する。そして、クラスＢＡＲがベリファイ処
理とリンク処理に成功すると、ＪＶＭは、次のステップ
４４０において、クラスＢＡＲを初期化する。他方で
は、クラスＢＡＲのリンク処理とベリファイ処理に成功
しなければ、エラーメッセージを発し（図示されな
い）、実行処理を行わない。（図示されない）。クラス
ＢＡＲをステップ４４０において初期化した後、ステッ
プ４５０において、クラスＢＡＲの主要メソッドを実行
して、その結果メソッドＦＯＯを呼び出す。変数ａｒｇ
が偽ならば、メソッドＦＯＯにおいて、「ｅｌｓｅ」ブ
ランチを選択して、クラスＡもクラスＢも使用されな
い。上記は、現在の命令が、クラスＢへの参照を分割す
ることを要求しているかどうか決定する図４Ａの判断ス
テップ４６０によって表されている。クラスＢが必要と
されないならば、現在の命令を実行して、ベリファイ処
理すべき命令がなくなるまで、ステップ４６０にループ
処理する（繰り返し戻る）次の命令を使用して、プログ
ラムの実行が続行される。他方では、変数ａｒｇが真な
らば、「ｉｆ」ブランチを実行する。そのブランチに
は、タイプがクラスＡの変数ｖａｒをクラスＢの新しい
インスタンスにセットする処理が含まれる。クラスＢを
参照する最初の命令を処理するとき、クラスＢのメソッ
ドを呼び出さなければならない（クラスＢのコンストラ
クタ）。そして、クラスＢへの参照を分割しなければな
らない。その命令によってクラスＢを分割しなければな
らないかどうか質問するステップ４６０によって表され
るテストでは、肯定的に回答する。次に、ステップ４７
０では、クラスＢがロードされていなければ、クラス・
ローダＬ３を使用して、クラスＢをロードする。

【００６１】従来のＪＶＭでは、図４Ａのポスト・ロー
ドのステップ４７５が示されている部分では、ステップ
４７５を経ず、処理が連続して直接ステップ４８０に移
動する。クラスＢの新しいインスタンスが作成されてい
るので、クラスＢをまずリンクして、初期化しなければ
ならない。つまり、次のステップでは、クラスＢがまだ
リンクされていなければ、ステップ４８０でクラスＢを
リンクする。ステップ４８０において、クラスＢのリン
ケージ（ベリファイ処理を含む）に成功すれば、次のス
テップ４９０において、クラスＢを初期化する。次に、
ステップ４９８において処理が続行し、現在の命令によ
って新たに分割されたクラスＢを使用できる。

【００６２】この流れは、実行中に、参照を分割するよ
う要求されるまで、クラスをロードしない点で完全要求
駆動型であるように見える。しかしながら、以下に示さ
れるように、従来のＪＶＭ仕様によれば、リンク・ステ
ップ４３５においてベリファイ処理ステップがクラスＢ
のロードを要求するであろう。そのような場合では、完
全要求駆動型プロセスと考えることはできず、概要求駆
動型ロードと呼ばれる。

【００６３】図４Ａで示される概要求駆動型ロード中の
１つの問題は、クラス名があいまいであることである。
いくつかのクラスを一緒にコンパイルするとき、コンパ
イラは、中にユニークなクラス名を有する名前スペース
を作成する。しかしながら、いくつかのクラスを、異な
る時間に異なるコンパイラによってコンパイルすると、
クラスの名前のユニークさを保証することはできない。
実行時には、クラス・ローダは、複数の（ｍｕｌｔｉｐ
ｌｅ）名前スペースを導入することができる。その結
果、実行中のクラス・タイプを、そのクラス名だけでは
なく、クラス名と、定められているクラス・ローダとの
組み合わせによって、たとえば、＜ＢＡＲＬ１＞によっ
て定義する。ベリファイ処理ステップにおいてタイプを
分割するのに必要であるすべての参照クラスをロードす
る、従来のシステムにおいてさえ、上記方法によってベ
リファイアを分割できる。ベリファイ処理を含むリンク
・ステップ４３５においては、参照クラス、たとえば、
クラスＢのタイプは、現在のクラス・ローダ、たとえ
ば、Ｌ１によって与えられると仮定して、すなわち、ク
ラスＢの「タイプ」は、＜Ｂ、Ｌ１＞であると仮定され
る。その仮定が真でないならば、アクセス権の問題が起
こり得る。たとえば、クラスＢのクラス・ローダＬ３が
ＢＡＲのクラス・ローダＬ１と異なり、＜Ｂ、Ｌ３＞
が、プライベート変数であり、＜Ｂ、Ｌ１＞がパブリッ
ク変数であると表されていれば、ＶＭは、クラスＢの外
部からプライベート変数へのアクセスを許可でき、プロ
グラム・セキュリティをあいまいにする可能性がある。

【００６４】１９９９年４月にリリースした第２版の、
ＪＶＭ仕様の最新版においては、前に参照した別の関連
する出願、ＢｒａｃｈおよびＬｉａｎｇによる米国特許
出願第０９／１３４４７７号「ＭＥＴＨＯＤＳＡＮＤ
ＡＰＰＡＲＡＴＵＳＦＯＲＴＹＰＥＳＡＦＥ，
ＬＡＺＹ，ＵＳＥＲ−ＤＥＦＩＮＥＤＣＬＡＳＳＬＯ
ＡＤＩＮＧ」において記載されているように、上記の問
題は避けられている。図４Ｂは、ＪＶＭ仕様書第２版で
利用した解決策を説明するフロー・チャートを示す。そ
の解決策を利用して、別のステップを、ポスト・ロード
のステップ４７５に含む。ステップ４７３では、実際に
はＬ３を使用してロードされたクラスＢがその名前とＢ
ＡＲのローダＬ１に基づいて仮定されたタイプを作成す
るかどうかが決定される。すなわち、ステップ４７３で
は、<Ｂ、Ｌ３>と、<Ｂ、Ｌ１>が等しいかどうかを決定
する。クラスＢをロードして、仮定されたタイプと異な
ったタイプを実際に作成すると、名前／タイプ制約に合
格せず、ステップ４７４においてエラー・メッセージが
発せられる。または、ステップ４７９で実行処理が続行
される。直前に引用した米国特許出願に記載された上記
プロセスによって、ステップ４３５のリンクによって、
以下に記載されるように、クラスＢＡＲによって、クラ
スＡおよび／またはクラスＢの使用のためにサブ・タイ
プをチェックするよう、参照クラスＡおよび／またはク
ラスＢをロードすることが要求されることに変わりはな
い。つまり、引用された特許出願は、完全要求駆動型ロ
ードと干渉するという問題を必ずしも解決してはいな
い。

【００６５】図４Ａのリンク・ステップ４３５内のベリ
ファイ処理ステップを、図５Ａ、５Ｂないし５Ｃの例を
使用して、説明する。図５Ａは、ステップ４３５のリン
ク・クラスＢＡＲが、現在のクラスのＢＡＲ５１０のメ
ソッドＦＯＯがベリファイ処理を実行するステップ５３
０が後に続く現在のクラスのＢＡＲのベリファイ処理を
開始することを含むことを示すフロー・チャートであ
る。次に、ステップ４３５内のクラスＢＡＲのベリファ
イ処理をステップ５９０で終了する。図５Ｂでは、クラ
スＢＡＲのメソッドＦＯＯをベリファイ処理するステッ
プ５３０であって、従来の実施形態であるステップ５３
０ａに使用される手順を示す。そのメソッドは、ステッ
プ５３２で始まる。そのメソッドがクラスＡやクラスＢ
などの他のクラスを参照し、まだロードされていなけれ
ば、ベリファイ処理プロセスでは、クラスＡおよび／ま
たはクラスＢをロードするよう要求されることがある。
ステップ５５５において、最初の判断を行う。参照クラ
スＢを必要とするならば、次に、クラスＢが既にロード
されているかどうかを、ステップ５４０で判断する。必
要とされ、ロードされていなければ、参照クラスをス
テップ５５０でロードする。したがって、要求駆動型ロ
ードが必要とされても、メソッドのベリファイ処理にお
いては、他のクラスが実行時に実際に必要とされる前
に、他のクラスをロードすることがある。ステップ５３
７で表されるように、クラスＡとクラスＢとの間に不正
確なサブ・タイプの関係があること、および、他のベリ
ファイ問題がベリファイ処理作業中に見つけられると、
ステップ５３９において、ベリファイ・エラーを発す
る。現在の命令がベリファイ処理に合格すると、ベリフ
ァイ処理プロセスを続行し、ステップ５８２内のメソッ
ドを終了して、ベリファイ処理すべき命令がなくなるま
でステップ５５５にループ処理する。すなわち、メソッ
ドの実行が始まることができるように、十分な数の命令
をベリファイ処理する。

【００６６】図５Ｃは、たとえば、ＪＶＭで実行され、
米国特許第５７４０４４１号と図４Ｂに記載されたよう
にステップ５３７において実行できるベリファイ処理の
詳細例を示す。その詳細例では、各命令ごとにタイプの
スナップショット（内容の記録）が行われる。タイプの
スナップショットは、ローカル変数のリストと、オペラ
ンド・スタック上の各位置のためのタイプを保持する構
成である。命令をベリファイ処理する必要があるとき
は、ステップ５３３において、そのスナップショットが
ロードされる。ステップ５３４では、スナップショット
内のタイプに対する命令の実行を決定する。命令が、２
つのブランチ操作が１つになるときのように（図２の例
のメソッドＢＡＲ.ＦＯＯにおける「Ｚ」にかかわるス
テートメントのように）、他の複数の命令の後続の命令
であれば、命令に対するタイプのスナップショットと、
それぞれのブランチに関する、他のマルチプル命令の先
行する命令のスナップショットとをマージさせなければ
ならない。上記の実行時には、ステップ５３５におい
て、現在の命令の後続の命令を決定し、ステップ５３６
において、現在の命令のスナップショットと、後続の各
命令のスナップショットとをマージさせて、命令をベリ
ファイ処理する。スナップショットにおける同じ位置の
プリミティブ・タイプが一致しないとき、上記のマージ
によって、ベリファイ処理に合格しないことを検出でき
る。また、そのマージによって、マージ中のスナップシ
ョットにおける同じ位置の参照物と、結果として得られ
るマージされたスナップショット内の特定のコモン・ス
ーパー・タイプ（また、最小上界、ＬＵＢ（ｌｏｗｅｓ
ｔｕｐｐｅｒｂｏｕｎｄ）、または、よりコモンで
ないスーパータイプＬＣＳ（ｌｅａｓｔｃｏｍｍｏｎ
ｓｕｐｅｒｙｐｅ）とも呼ばれる）とを置き換える。
そして、上記を実行しなければ、ベリファイ処理はでき
ない。

【００６７】図５Ｂに示されるように、ベリファイアが
参照クラスをロードしなければならないことがあるの
で、他のクラスを参照するメソッドをベリファイ処理し
て、完全要求駆動型ロードを防止することができる。参
照クラスのロードは保証されてはいない。理由は、その
ロードは参照される文脈によるからである。本例では、
クラスＡは、処理ステートメントが適格である、クラス
Ｂのスーパー・クラスでなければならない。クラスＢを
ロードして、上記サブ・タイプの関係をチェックするこ
とができる。クラスＡがクラスＢのスーパー・クラスで
あれば、クラスＢをロードするときに、クラスＡは、ク
ラスＢとは独立にロードされる。クラスＢをロードした
後に、クラスＡがロードされていないならば、クラスＡ
は、クラスＢのスーパークラスではない。クラスＡがロ
ードされていれば、上記関係が維持されているかどうか
直接チェックすることができる。

【００６８】完全要求駆動型ロードを伴うベリファイ処
理本発明によるベリファイ処理を伴う完全要求駆動型ロー
ドを実行するためには、従来の方法によるロードをトリ
ガする、モジュールの相互関係のチェックを遅延させる
ことが可能でなければならない。

【００６９】本例のクラスＢＡＲのベリファイ処理中
に、クラスＢが既にロードされていれば、サブ・タイプ
の関係が維持されているかどうかを直ちに決定すること
ができる。クラスＢをロードするときに、スーパー・タ
イプがロードされていたか、さもなければ、スーパー・
タイプは、Ｂのスーパ・タイプではあり得ない。クラス
Ｂがまだロードされていないならば、本発明によれば、
クラスＢがロードされた後チェックされる、または実施
される、クラスＢに対する制約が加わる、または制約が
課せられることがある。本発明の実施形態の１つを、図
６Ａないし図６Ｃに示す。

【００７０】図６Ａは、図５Ａに示すメソッド・ベリフ
ァイ・ステップ５３０を実行するステップ５３０ｂのフ
ロー・チャートであって、従来のＪＶＭ仕様である図５
Ｂに示すバージョン５３０ａに代わるものである。本発
明の本実施形態によれば、メソッドのベリファイ処理
は、ステップ６３２で始まり、従来のようにロードをト
リガしたタイプの参照クラスＢに関する情報が必要かど
うかをステップ６５５で決定する。参照クラスＢが従来
のようにロードをトリガすると、次の手順としては、参
照クラスＢが既にロードされているかどうかを、ステッ
プ６４０において、チェックする。クラスＢが既にロー
ドされていれば、従来のＪＶＭと同じように、処理が続
行され、ステップ６３７において、サブ・タイプがチェ
ックされ、他の妥当性チェックが行われる。そして、命
令がベリファイ処理に合格しないと、ステップ６３９に
おいて、エラー・メッセージが発せられる。その命令に
関する、モジュールの相互チェックを含む妥当性チェッ
クに合格すると、ステップ６８２において、ベリファイ
処理されるべき命令がなくなって実行が始まるまで、十
分な数の命令をループ処理して、メソッドＦＯＯのベリ
ファイ処理が続行される。実行を開始すべき命令がベリ
ファイ処理に合格しないと、モジュールの実行は開始さ
れない。

【００７１】しかしながら、ステップ６４０において、
クラスＢがまだロードされていないことが決定される
と、今度は、クラスＢのクラス・ローダを呼び出して、
クラスＢをロードすることはない。代わりに、ステップ
６５０において、クラスＢＡＲがクラスＢを使用するた
めのベリファイ制約が書き込まれる。次に、サブ・タイ
プ・チェックなどの、クラスＢに関するモジュール相互
チェックに合格したと仮定して、メソッドＦＯＯのベリ
ファイ処理が、ステップ６８２において、前と同様、続
行される。ステップ６５０において、制約を書き込むこ
とになる情況、およびそれらの制約の形式については、
複数の実施形態に基づいて、より詳細に以下で記載され
る。本発明の本実施形態によれば、リンク中のベリファ
イ処理ステップ５３０ｂが、望まれるように、モジュー
ルの完全要求駆動型ロードの妨げとなることはない。

【００７２】ＬＵＢの記号演算を伴うベリファイ処理参照モジュール、またはクラスがまだロードされていな
いならば、完全要求駆動型リンクの間中、モジュールま
たはクラスは、ロードされないままである。したがっ
て、ＪＶＭでは、図５Ｃで説明されたように、ステップ
５３８で挿入されたＬＵＢが既知ではないかもしれない
ので、マージするスナップショット処理結果に影響がで
る。別の表現をすれば、ＪＶＭによるタイプ格子の表現
は、参照される複数の異なるタイプのために、ＬＵＢを
決定するほど十分には存在しないかもしれない。図６Ｂ
では、本発明の１つの実施形態によって、スナップショ
ットのマージがどのように機能するかを示す。ステップ
６３３、ステップ６３４、ステップ６３５、およびステ
ップ６３６は、それぞれ、対応するステップ５３３、ス
テップ５３４、ステップ５３５、およびステップ５３６
に類似している。しかしながら、ステップ６３８では、
ＬＵＢが既知でなければ、そのタイプをマージされたス
ナップショットの適切な位置に挿入することはできな
い。その代わりとして、先行する命令のスナップショッ
トの適切な固定位置にある参照タイプのリストを、マー
ジされたスナップショットの固定位置に挿入するか、ま
たは、挿入しないのであれば、固定位置に関連づけられ
る。すなわち、必要に応じて、クラス、またはモジュー
ルをロードして、タイプ格子を構成することによって、
スナップショットのその位置にあるＬＵＢを特定して、
参照する代わりに、ＬＵＢを必要とさせる、異なるタイ
プ、たとえば、クラス・タイプ、Ｘ₁、Ｘ₂、．．．、Ｘ
_nへのいくつかの参照が記号によってリストされる、お
そらくはａ＾などのサインまたは記号によって分離され
る。その記号は、タイプがＬＵＢを有するその関係を共
有しなければならないことを示している。

【００７３】制約の実施参照クラスＢを実際にロードするとき、またはロードす
るならば、ステップ６５０においてＶＭが使用するため
に書き込まれた、または、記録された制約が、実施され
る、たとえばチェックされる。その結果、ロードした直
後、図４Ａのステップ４７５によって表されるポスト・
ロード処理中に制約が実施される。図６Ｃは、本発明の
実施形態の１つによって参照クラスＢに、ベリファイ制
約を実施する例を示す。本発明の本実施形態によれば、
図４Ｂに示したステップ４７５ａを含むことができる新
しい処理ステップ４７５ｂが表わされている。ベリファ
イ制約を実施するには、ステップ６７１から始まる。本
図例では、クラスＢの実際のスーパー・タイプが使用さ
れて、前もって書き込まれたサブ・タイプのべリファイ
制約に、クラスＢが合格するかどうかを決定する。上記
のチェックは、ステップ６７３において行われる。参照
クラスＢが該制約に合格しなければ、エラー・メッセー
ジがステップ６７４において発せられる。次に、そのエ
ラー・メッセージを扱うハンドラは、実行を終了させる
か、または実行を続行させることができる。または、エ
ラー・メッセージを発することなく実行を終了すること
ができる。参照クラスＢが書き込まれた制約に合格すれ
ば、ステップ６７９においてポスト・ロード処理を終了
する。

【００７４】そのような変形例では、ＶＭは、ベリファ
イ処理を伴う完全要求駆動型ロードを実行することがで
きる。完全要求駆動型ロードの利点は、・リンケージ・エラーに関するプログラムの挙動は、
いかなるプラットホームであっても、いかなる実行時で
あっても同じである。・クラス、またはメソッドをリンクすることのできる
すべての場合を想定して、それらのすべての場合の例外
処理に対応しようとする必要性はない。・ユーザは、確実で簡単な方法で、有効なクラス、ま
たは他のモジュールを決定することができる。

【００７５】本発明の利点の１つは、プログラマが、確
実で簡単な方法で、プラットホームのクラスの有効性を
テストできることである。たとえば、プログラマが、よ
り新しいリリース版のモジュールを使用することを望
み、それらのより新しいモジュールが利用できるときの
みそれらのモジュールを使用したいと希望するとき、要
求駆動型リンクによってその処理がより簡単になる。そ
の場合、プログラマが作成したコードのどこかに、新し
いリリース版の新しいモジュールを参照するブランチが
ある。現在のバージョンのプラットホームが、そのブラ
ンチで参照されるモジュールをサポートしていないなら
ば、そのブランチが実行されないようにプログラマが設
計することができる。新しいモジュールがそのプラット
ホーム上で利用可能ではなく、ベリファイ処理されるモ
ジュールが新しいモジュールを参照するとき、完全要求
駆動型ではない仮想マシンは、欠けている新しいモジュ
ールをロードしようとするベリファイアを必要とするこ
とがある。しかし、そのロードは必ず失敗して、ベリフ
ァイ処理のステップも当然失敗する。したがって、実行
されることのないブランチにおいて、欠けているモジュ
ールは参照されるだけてあるが、そのモジュールが欠け
ているためにベリファイ処理は失敗となる。必要な完全
要求駆動型ロードがある場合、実際には実行されない命
令によってモジュールが参照されるので、ベリファイ処
理が失敗することはない。上記のように、クラスなどの
モジュールの最新版をチェック中に、ベリファイ処理に
合格することができるので、仮想マシンに必須のものと
して、本発明によってサポートされる完全要求駆動型ロ
ードを採用しようとする重要な動機となっている。

【００７６】必要な要求駆動型ロードであっても、適格
で、定義されたポイントにおいてのみ何らかの失敗が現
れるのであれば、異なるＶＭを実装して、できるだけ早
く、ロード、およびリンクすることも可能であろう。欠
陥のあるタイプであるクラスを分割しなければならない
ポイントまでそのコードを実行することができなければ
ならない。たとえば、ジャスト・イン・タイム（ＪＩ
Ｔ）方式のコード・ジェネレータは、クラス、またはメ
ソッドをコンパイルするときに、クラス、またはメソッ
ドを予めリンクすることもできる。しかしながら、リン
クのいずれかが失敗すると、直ちに失敗に終わるのでは
なく、ＪＩＴは、別の状況であれば、要求駆動型ロード
が例外処理を行ったであろうポイントにおいて、適切な
例外処理を可能にするコードを生成しなければならな
い。（可能ではあるが、実際には、リンク・タイム・テ
ストを必要とはしない）。別の例では、独占リンク中に
無効のクラス参照によって、静的なコンパイラが失敗す
ることがある。それにもかかわらず、コンパイラが完全
にリンクできなくとも、コードをコンパイルすることが
選択されれば、そのコードがＪＩＴによってコンパイル
されたであろう同じポイントにおいて、そのコードを実
行すると、必然的に失敗する。最後の例では、クラスを
動的にロードする（たとえば、クラス・ローダを通じ
て）と、実装プログラムによって、全体的に、または部
分的にそのクラスを予めリンクされることができる。し
かしながら、なんらかの失敗があれば、そのコードは、
再び、無効な参照ポイントまで実行することができなけ
ればならない。

【００７７】モジュールごとのベリファイ処理本発明の別の態様では、参照モジュールがロードされて
も、参照モジュールのベリファイ処理を実行しない。１
回１モジュール・ベリファイ処理とも呼ばれる、そのモ
ジュールごとのベリファイ処理が望ましいが、それには
多くの理由がある。実行前に、ベリファイ処理を行う
と、結果的に有利である。時間面およびスペース面での
ベリファイ処理の実行時のコストを減少させる、または
除去できる。余分な、または、実行時ごとのベリファイ
処理を取り止めることができる。ＪＡＶＡ（登録商標）
実行環境は、より小規模であり、より簡単であるのは、
その実行環境が含むベリファイ処理を実行するコードの
量を減少できるからである。クラスごとのベリファイ処
理と同じように、ＪＡＶＡ（登録商標）プラットホーム
の延長部として実行される、その１回１モジュール・ベ
リファイ処理は、従来のＪＶＭ仕様によっても、上記に
提案された完全要求駆動型ロードによってでも自動的に
は行われない。前者の場合では、ロードする以外に選択
の余地がない場合、ベリファイアは、自動的に参照クラ
スをロードする。後者の場合では、参照クラスがロード
されて、ベリファイ処理を行わなければならない状況
で、ベリファイ処理を実行するのであれば、参照クラス
のベリファイ処理が行われる。したがって、クラスごと
のベリファイ処理には、２つの実施形態が予想される。
１つは、従来のＪＶＭ設計の場合に使用でき、１つは、
新しい完全要求駆動型ロードの場合に使用することがで
きる。

【００７８】本発明の１つの実施形態によれば、通常、
ベリファイ処理中に実行されるチェック処理は、実行時
の前に実行することができる。実行時の前のチェック
は、技術的には、リンクの一部ではなく、またその結
果、リンクのベリファイ処理段階の一部ではないので、
それらのチェックは、本明細書では、ベリファイ前処理
と呼ばれ、実行前の妥当性チェックを指す。

【００７９】本実施形態では、コンパイラがバイナリ・
クラスを生成した後なら、いつでも、プログラマは、バ
イナリ・クラスによってベリファイ前処理を実行するこ
とができ、そのクラスにおいて参照されるであろう他の
いかなるクラスからも独立している。その結果、参照ク
ラス、または参照モジュールへアクセスする必要はな
い。本発明によるクラスごとのベリファイ前処理が図７
Ａに示されている。たとえば、そのメソッドは、記憶
媒体から、クラスＢＡＲをメモリにロードするステップ
７１０から始まる。次に、従来は、ベリファイ処理中に
行われていた、タイプ・チェックや、オペランド・スタ
ック・オーバーフロー／アンダーフロー・チェックなど
の妥当性チェックを、ステップ７１２において実行す
る。そのようなチェック処理中は、クラスＢＡＲから参
照されているクラスＡとクラスＢとの間のサブ・タイプ
関係などの他のモジュールを参照する命令のベリファイ
処理に必要とした相互モジュール情報は、いずれも楽観
的には、命令が有効であるよう想定される。しかしなが
ら、想定された情報、または関係によって、仮想マシン
が記憶すべき参照モジュールに制約が課せられる。その
ような参照モジュールを最終的にロードするならば、そ
のような制約をチェックしなければならない。それらの
想定にもかかわらず、クラスＢＡＲなどのモジュール
が、実行されるチェックに合格しなければ、ステップ７
１３において、エラー・メッセージが発せられる。その
ようなエラーは、必ずしも実行時エラーではないので、
エラー・メッセージは、実行時にハンドラに発せられる
ことがないことがあり得る。その代わりに、そのような
エラーは、たとえば、プリンタや表示装置のスクリーン
などの出力装置に表示されるエラー・メッセージを使用
して、プログラマに伝えられなければならないであろ
う。モジュールがすべてのチェックに合格すると、次
に、ステップ７１６において、再び呼び出されるべきベ
リファイ前処理制約すべてが、実行時の後々の使用のた
めに書き込まれる。続いて、ベリファイ前処理が終了す
ると、ステップ７１９においてプロセスが終了する。そ
して、別のクラス、またはモジュールのベリファイ前処
理を、図７Ａに示されるステップに従って、実行でき
る。モジュール内のすべての命令をベリファイ前処理し
なければならないというわけではない。ベリファイ前処
理しなければならないのは、モジュールの特定の用途に
必要である命令のみである。たとえば、メソッドＦＯＯ
内の命令のベリファイ処理は必要であるが、クラスＢＡ
Ｒ内の他のメソッド内の命令のベリファイ処理は必要で
はない。

【００８０】場合によっては、ファイルにベリファイ前
処理制約を書き込むことができる、または、書き込まな
い場合、実行時の後々のチェックのためにそのモジュー
ルと関連づけられる。ＪＶＭとともに使用するとすれ
ば、記憶媒体の上でバイナリ・クラス形式でクラスと関
連づけられるデータとしてそれらの制約を記録すること
ができるであろう。クラスがメモリにロードされると、
必要になったとき、たとえば、参照クラスＢをロードし
た後、ＪＶＭがチェックのために、それらの制約を内蔵
させることができるであろう。

【００８１】しかしながら、本発明によれば、別の選択
肢として、ベリファイ前処理制約が、記憶されていて
も、またはモジュール自体であっても、または、両者で
あっても、該制約に、デジタル署名などの信号を添付す
ることができる。そのような信号は、モジュール、また
は制約のソースを確実に特定し、サイン済みのものから
改ざんされてしまっているかいないかを示すのに使用で
きる。

【００８２】このように、従来ベリファイ処理の間に行
われた内部モジュール・ベリファイ妥当性チェックと等
価であって、クラスＡ、およびクラスＢなどの参照モジ
ュールに関する相互モジュール情報を必要としない相互
モジュール・ベリファイ妥当性チェックを実行前に実施
することができる。すなわち、内部モジュール・チェッ
クのために、実質的に完全なモジュールごとのベリファ
イ前処理を実行することができる。相互モジュール・チ
ェックをベリファイ前処理制約に変える。

【００８３】図７Ｂは、例としている図７Ａのステップ
７１６の詳細を示す。プロセスは、ステップ７３２にお
ける、ロードされたクラスＢＡＲのメソッドのベリファ
イ前処理から始まる。次に、ステップ７５５において、
命令の妥当性チェックのために、メソッドにおける次の
命令が情報を必要とするかどうかを、参照クラスＢから
決定する。次に、必要としないのであれば、ステップ７
３７において、必要とされる内部クラスの妥当性チェッ
クすべてをその命令に関して行う。その命令が、その相
互クラス・チェックに合格しなければ、エラー・メッセ
ージを出力装置に書き込む。そして、プログラマは、上
記問題を処理できる。他方では、その命令を完全にベリ
ファイ処理するために、参照クラスをロードしなければ
ならない。ステップ７５０において、後々の再呼び出し
のために、ベリファイ前処理制約を書き込むか、また
は、書き込まないのであれば、記録する。そして、命令
が要求するサブ・タイプ関係が、有効であると想定す
る。また、命令は、内部クラス・チェックを要求できる
ので、ステップ７３７に進んで、それらの内部チェック
を実行する。命令が内部クラス・チェックを必要としな
いならば、ステップ７３７において、その命令は、それ
らの内部クラス・チェックに自動的に「合格」する。相
互クラス・チェックの後、その命令が見つかると、およ
び／または、ベリファイ前処理制約を書き込んだ後、そ
の命令が有効であると仮定されると、フロー制御は、ロ
ードされたクラスＢＡＲのメソッドＦＯＯ内に命令がな
くなり、メソッドＦＯＯのベリファイ前処理を終了する
まで、ステップ７５５にループ処理するステップ７８２
に移動する。参照クラスをロードしているかどうかを決
定しない、つまり、内部モジュール・チェックがなされ
ることも、ベリファイ前処理制約が書き込まれることも
ないことに注意されたい。既にロードされているモジュ
ールについて、相互モジュール・チェックを行うことは
ない。

【００８４】実行前に、１回１モジュール・ベリファイ
処理されたモジュールが、たとえば、クラスＢＡＲが、
実行時のリンク中に行われるベリファイ処理によってど
のように扱われるかを図７Ｃに示す。従来のＪＶＭによ
るステップ５３０ａ、または完全要求駆動型ロードのた
めの変更されたステップ５３０ｂのいずれかに代わっ
て、従来のＪＶＭによる概要求駆動型ロードに従い、ク
ラスごとのベリファイ前処理を組み込む代替のステップ
５３０ｃが図７Ｃに示されている。ステップ７９２にお
いて、クラスＢＡＲのメソッドＦＯＯなどのモジュール
の命令をベリファイ処理するステップを開始した後、そ
のモジュールが、ステップ７８０において、ベリファイ
前処理に合格したかどうかを決定する。合格していなけ
れば、図５Ｂのステップ５５５で開始される従来のＪＶ
Ｍの流れに従う。さもなければ、場合によっては、ベリ
ファイ前処理されたモジュールが、ステップ７８３にお
いて、信頼性があるとすべきかどうかをチェックした
後、以下でさらに記載するが、ステップ７８４に進む。
ファイルが、信頼性があるとされているかどうかをテス
トする方法が多くあることは、当業者に知られている。
たとえばデジタル署名を使用する方法がある。ベリファ
イ前処理されたモジュールの信頼性に関心がなければ、
ステップ７８３をスキップすることができる。ステップ
７８４では、メソッド内の各命令に従っていく代わり
に、実行ベリファイアは、ＢＡＲのクラスごとのベリフ
ァイ処理中に、記録された／書き込まれたベリファイ前
処理制約を読み込む。書き込まれたベリファイ前処理制
約がなければ、ＢＡＲ．ＦＯＯのベリファイ処理を終了
して、ステップ７７８に進み、そのプロセスを終了させ
る。

【００８５】ベリファイ前処理制約が、参照モジュー
ル、たとえば、クラスＡまたはクラスＢが書き込まれて
いれば、ステップ７８６において、実行ベリファイア
が、制約内の参照モジュールが既にロードされているか
どうか決定する。ロードされていれば、ステップ７８８
において、ベリファイ前処理制約が実施される。参照モ
ジュールが制約に合格しなければ、ステップ７６２にお
いて、エラー・ハンドラが、例外処理のためにエラー・
メッセージを発する。さもなければ、ステップ７７８に
移動して、処理の必要がなくなるまで、ベリファイ前処
理制約処理がループ処理される。ステップ７８６におい
て、参照クラスなどの参照モジュールがロードされてい
ないと決定すれば、ステップ７８９において、クラスな
どの参照モジュールがロードされて、ステップ７８８に
おいて、その制約処理が実施される。

【００８６】そのクラスがベリファイ前処理されている
（場合によっては、信頼性チェックに合格している）限
り、ベリファイ前処理制約が参照クラスに書き込まれて
いてもいなくとも、相互クラス・チェックを実行する必
要はない。理由は、それらの相互クラス・チェックは、
実行前の、クラスごとのベリファイ前処理の間に既に行
われてしまっているからである。本発明によれば、モジ
ュールが、１回１モジュール・ベリファイ前処理に合格
した後、実行ベリファイアは内部モジュール・チェック
を実行せず、相互モジュール制約を実施するだけであ
る。

【００８７】上記のように本例では、モジュールのコン
パイルが終了するとすぐに、他のモジュールをロードす
ることなく、ベリファイ前処理される。したがって、実
行前に、ベリファイ処理の多くを処理することが可能に
なって、毎回繰り返されなくて、モジュールをロード
し、リンクするたびに、ベリファイ処理を繰り返すこと
がなくなり、その結果、貴重な時間とスペースに関する
リソース（たとえば、仮想マシンを作動させるプロセッ
サの時間とスペース）が節約される。

【００８８】完全要求駆動型ロードを伴うモジュールご
とのベリファイ前処理図８は、実行時に完全要求駆動型ロード中にベリファイ
前処理の結果を組み込むフロー・チャートを示す。図８
が、実行前に１回１モジュール・ベリファイ処理を行っ
たモジュールが、本例のクラスＢＡＲのための完全要求
駆動型ロードをサポートするリンク中に実行されるベリ
ファイ処理によって、いかに扱われるかを示す。従来の
ＪＶＭによるステップ５３０ａ、または、完全要求駆動
型ロードのための変更されたステップ５３０ｂ、１回１
モジュール・ベリファイ処理を伴う概要求駆動型ロード
のためのベリファイ処理を行うステップ５３０ｃのいず
れかに代わって、図８は、ＪＶＭの新しい実施形態によ
る完全要求駆動型ロードに従う代替ステップ５３０ｄを
示し、クラスごとのベリファイ前処理を組み込む。図８
のステップ８９２、ステップ８８０、ステップ８８３、
ステップ８８４、ステップ８７８、ステップ８８６、お
よびステップ８６２は、それぞれ、図７Ｃの対応する７
００番台のステップ７９２、ステップ７８０、ステップ
７８３、ステップ７８４、ステップ７７８、ステップ７
８６、およびステップ７６２に類似している。ステップ
８９２において、クラスＢＡＲのメソッドＦＯＯなどの
モジュールの命令のためにベリファイ処理ステップを開
始した後、ステップ８８０において、そのモジュールが
ベリファイ前処理に合格したかどうかを決定する。合格
していなければ、図６Ａのステップ６５５で始まるＪＶ
Ｍによる完全要求駆動型ロードのフローに従う。場合に
よっては、ステップ８８３において、ベリファイ前処理
されたモジュールが上記したように、信頼性があるとす
べきかどうかをチェックした後、ステップ８８４に移動
する。ステップ８８４において、メソッド内の各命令に
従っていく代わりに、実行ベリファイアは、ＢＡＲのク
ラスごとのベリファイ処理中に、書込まれたベリファイ
前処理制約を読み込む。書き込みされたベリファイ前処
理制約がなければ、ＢＡＲ．ＦＯＯのベリファイ処理を
終了して、ステップ８７８に進み、プロセスを終了させ
る。

【００８９】たとえば、クラスＡ、または、クラスＢで
ある、参照モジュールのために、ベリファイ前処理制約
を読み込むと、ステップ８８６において、実行ベリファ
イアが、その制約内の参照モジュールが既にロードされ
ているかどうかを決定する。ロードされていれば、ステ
ップ８８８において、ベリファイ前処理制約処理が実施
される。参照モジュールがその制約に合格しなければ、
ステップ８６２において、エラー・ハンドラによる例外
処理のためにエラー・メッセージが発せられる。参照モ
ジュールが適格ではない制約に合格すると、処理をする
必要がなくなるまでベリファイ前処理制約処理をループ
処理するステップ８７８に進む。

【００９０】完全要求駆動型ロードのための図８に残っ
ているステップは、概要求駆動型ロードのための対応部
と実質的に異なっている。ステップ８８６において、参
照クラスなどの参照モジュールがロードされていないと
決定すれば、参照モジュールはロードされない。代わり
に、クラスなどのまだロードされていないモジュールが
ロードされることがあるとしたら、そのときのために、
ステップ８８９において、ベリファイ前処理制約は、メ
モリ、または記憶媒体にコピーされる、または、コピー
されるのでなければ、保持される。

【００９１】図８では、ステップ８８８は、３つの進む
先を持つことができる。条件なしで、合格する場合と、
合格しない場合のほかに、１つ、または複数の他のまだ
ロードされていないモジュールのコンテンツが既知であ
るときのみ、既にロードされている参照モジュールが合
格できる場合があり得る。上記結果は、いくつかの参照
モジュールに課せられるベリファイ前処理制約を、１つ
または複数のまだロードされていない参照モジュールに
課せられるベリファイ制約として、書き直すべきである
という「条件付き合格」と考えることができる。ステッ
プ８８５において、クラスなどのまだロードされていな
い参照モジュールにのみ課せられるベリファイ制約とし
て、ベリファイ前処理制約を書き直す。書き直した後
に、必要ならば、ステップ８７８に進む。

【００９２】信頼性のないクラスのモジュールごとのベ
リファイ処理上記のように、本発明によるべリファイ処理は、参照モ
ジュールが満足しなければならない制約を有するモジュ
ールをコンストラクト（ｃｏｎｓｔｒｕｃｔ）し、アノ
テート（ａｎｎｏｔａｔｅ）する能力による。不幸にし
て、その手順は、アタッカーが、そのようなアノテーシ
ョンをスプーフィングする−おそらく、悪性のクラスを
良性に見せかけることを必ずしも防止しない。したがっ
て、本発明の１つの実施形態によれば、選択自由の信頼
性チェックが、図７Ｃのステップ７８３と、図８のステ
ップ８８３に含まれている。それらのチェックがなくて
も、たとえば、クラスをベリファイ前処理して、実行前
に、信頼性のある（改ざんのない）データベースにロー
ドすることができる場合、信頼性のある状況でベリファ
イ前処理できる。

【００９３】しかしながら、信頼性のない状況では、よ
り多くの保護対策が必要である。本発明の１つの実施形
態によれば、図９に示されるように、キャッシュ９２０
は、信頼性のあるクラスおよび／または、ベリファイ前
処理制約、たとえば、９６５ａなどの信頼性のあるモジ
ュールを含むことができるであろう。信頼性のないソー
ス、たとえば、インターネット上のソースから仮想マシ
ンに入力されたモジュールおよび／制約を、キャッシ
ュ、たとえば９６５の外側に置くことができるであろ
う。信頼性のないソース、たとえば９６５からのクラス
に伴うベリファイ前処理制約はいかなるものも無視され
るであろう。代わりに、そのようなモジュールが初めて
ロードされたとき、図７Ａで示された方法によって、ベ
リファイ前処理ベリファイア９１０において非要求駆動
型ベリファイ前処理される。モジュールがベリファイ前
処理に合格しなければ、そのモジュールは直ちに拒絶さ
れるであろう。モジュールがベリファイ前処理に合格す
れば、必要に応じて、新しいベリファイ前処理制約が生
成され、そして、新しい制約とアノテート、または関連
付けられたモジュール、たとえば、９６５ａが、信頼性
のあるモジュール・キャッシュ９２０に記憶される。続
いて、信頼性のないソースからモジュールをロードしよ
うとすると、モジュール・キャッシュ９２０がサーチさ
れるであろう。キャッシュされ、ベリファイ前処理され
たモジュール９６５ａが見つかると、そのモジュール９
６５ａを、ベリファイ前処理されたものとして、安全に
使用できる。上記変形例では、図７Ｂに示されたよう
に、クラスごとのベリファイ前処理制約のチェックが正
しく行われるであろう。実際、図７Ｃのステップ７８０
では、モジュール・キャッシュをチェックすることによ
ってベリファイ前処理が実行されたかどうかという質問
に答えが与えられる。上記の変形例では、図７Ａのステ
ップ７１８のベリファイ前処理制約のデジタル・サイン
は必要とされない。同様に、上記変形例では、図７Ｃの
ステップ７８３と、図８のステップ８８３に示された、
ベリファイ前処理出力が信頼性のあるものかどうかにつ
いてのチェックは必要とされない。そして、ステップ７
８０、またはステップ８８０から、それぞれステップ７
８４、またはステップ８８４に直接進む。

【００９４】制約の形式図６Ａ、６Ｃ、７Ａ、７Ｂおよび８のフロー・チャート
で示した方法は、すべて、できるだけ遅く参照クラスを
チェックする要素を提供している。書き込まれた制約の
形式、および、それらの制約が続いてチェックされる方
法は、以下の通りである。制約は、たとえば、図６Ａの
ステップ６５０、図７Ｂのステップ７５０、および図８
のステップ８８５と、ステップ８８９において書き込む
ことができる。図６Ｃのステップ６７３、図７Ｃのステ
ップ７８８、および図８のステップ８８８において、制
約処理を実施することができる。

【００９５】制約の生成と制約のチェックを、例を使用
して、より詳細に記載する。図２を参照して、処理ステ
ートメントは、クラスＢの新しいインスタンスを、クラ
スタイプＡの変数ｖａｒに記憶すると宣言している。オ
ブジェクト指向言語では、上記の処理は、Ｂ＜＝Ａと表
現されるように、クラスＢがクラスＡのサブ・タイプで
あることを要求している。クラスＢがそのときロードさ
れていなければ、ＢＡＲのベリファイ処理の間、上記の
ことは既知ではない。また、クラスＢがロードされ、ク
ラスＢがクラスＡのサブ・クラスならば、Ａは、またロ
ードされていなければならない（Ｂをロードするため
に、Ａがロードされていなければならないので）。した
がって、その対置が真である、すなわち、クラスＢがロ
ードされていて、クラスＡがロードされていないなら
ば、クラスＢは、クラスＡのサブ・クラスではない。そ
の処理ステートメントによって、クラスＢＡＲがベリフ
ァイ処理に合格しなくなるサブ・タイプ・ミスマッチを
引き起こす。図３の非要求駆動型ロードのように、クラ
スＡとクラスＢの両方がロードされていれば、クラスＡ
が、ほぼクラスＢのスーパー・クラスであるかどうかを
調べるために、クラスＢのためのスーパー・クラスのイ
ンジケータをトレースできる。そうであれば、クラスＢ
は、クラスＡのサブ・クラスであって、上記処理は、ベ
リファイ処理に合格する。その階層上でスーパー・クラ
ス・インジケータを追跡しても、クラスＡが見つからな
ければ、クラスＢは、クラスＡのサブ・クラスではな
い。つまり、処理ステートメントによって、サブ・タイ
プ・ミスマッチが起こって、クラスＢＡＲがベリファイ
処理に合格しない。

【００９６】従来のＪＶＭ仕様を使用して、クラスＢが
まだロードされていなかったならば、ベリファイアは、
クラスＢをロードして、そのタイプ、より詳しくは、ク
ラスＢがクラスＡのサブ・タイプであるかどうかをチェ
ックする。

【００９７】本発明によれば、完全要求駆動型ロード、
または、クラスごとのベリファイ処理、または両者を実
現するために、クラスＢをロードしないことが望まれ
る。したがって、本発明の本実施形態によれば、クラス
Ｂはロードされない。代わりに、制約Ｂ＜＝Ａが書き込
まれる。制約を書き込むための上記のステップであれば
どのステップにおいても、上記の制約を書き込むことが
できる。（たとえば、ステップ６５０、ステップ７５
０、ステップ８８９、ステップ８８５）ＢＡＲ．ＦＯＯ
を実行した後、その処理ステートメントを有する上記の
ブランチが実行されず、そして、クラスＢが、必ずしも
同様に、実行されるいかなる他の命令からも参照されな
いならば、クラスＢは決してロードされない。しかし、
上記処理ステートメントを含むブランチが実行され、ク
ラスＢがまだロードされないならば、そのときには、ク
ラスＢはロードされる。そして、そのとき、クラスＢが
ロードされた後、クラスＢが制約Ｂ＜＝Ａを満足させる
かどうかのチェックが行われるであろう。上記のチェッ
クを、たとえば、制約をチェックするための上記ステッ
プ（たとえば、６７３、７８８、８８８）において実行
することができる。上記の実行が簡単なのは、もし、ク
ラスＢが本当にクラスＡのサブ・クラスであり、クラス
Ａからその属性を引き継いでいれば、クラスＡは、既に
ロードされていなければならなかっただろうからであ
る。したがって、上記のタイプの制約は、完全要求駆動
型ロード、または、クラスごとのベリファイ前処理、ま
たは両者を可能にする。

【００９８】クラスごとのベリファイ前処理では、本発
明による完全要求駆動型ロード実行時の取り扱い方法と
は異なる方法で取り扱うことのできる、ノン・ローカル
・クラスのクラス・タイプには、別のチェックが課せら
れる。上記は、プロテクテッドメンバーのためのレシー
バ・アクセス・チェックである。

【００９９】ＪＡＶＡ（登録商標）の仮想マシンでは、
プロテクテッドメンバーＲに、１つのクラス、またはイ
ンタフェースＤによってアクセスできるのは、下記の条
件、または下記の条件のときのみである。１．Ｄが、ＲＯＲＢＯＴＨであると宣言したクラ
スＣと同じ実行パッケージの中にある。２．Ｄが、Ｃのサブ・クラスであって、Ｒ，ＡＮＤで
あると宣言したクラスである。３．Ｒがインスタンス・メンバーであれば、アクセス
されるインスタンスＲのスタチック・タイプであるＴ
は、Ｄのサブ・タイプである。条件３は、レシーバ・チ
ェックとして知られている。

【０１００】従来のＪＡＶＡ（登録商標）仮想マシンで
は、最初の２つの条件は、ＤからＲへの参照が、Ｄのリ
ンク中に分割されるときチェックされる。３番目の条件
は、Ｄのベリファイ処理の間にチェックされる。ベリフ
ァイ処理の間、Ｒを宣言するクラスＣのロードは、まだ
終了していないであろう。上記の場合、ＣがＤのスーパ
ー・クラスではないことは明らかである。（そうでなけ
れば、クラスをロードすることは、そのすべてのスーパ
ー・クラスをロードすることを意味するから、Ｃは強制
的にロードされていただろう。）その場合、ＣとＤが同
じ実行パッケージの中にあるときのみ、そのアクセスは
適格である。ベリファイアは、上記条件が成立すると、
楽観的に仮定することができる。参照が分割されている
とき、その条件がチェックされるだろう。したがって、
Ｃが既にロードされていれば、ベリファイアは、プロテ
クテッドレシーバ・チェックを実行する必要があるだけ
である。上記状況において、Ｒがいったいプロテクテッ
ドメンバーであるかどうかを決定することができる。Ｒ
がプロテクトされていないならば、いかなるプロテクテ
ッドレシーバ・チェックも必要ない。Ｒがプロテクトさ
れているならば、ベリファイアは、Ｄが、Ｃと同じ実行
パッケージ内にあるかどうかを調べるテストを行うこと
ができる。上記が事実ならば、そのアクセスは適格であ
って、再び、いかなるプロテクテッドレシーバ・チェッ
クも必要ない。ＤとＣが同じ実行パッケージの中にない
ならば、ベリファイアは、ＤがＣのサブ・クラスである
かどうかと、Ｔが、アクセスされているインスタンスの
スタチック・タイプであって、Ｄのサブ・タイプである
かどうかをチェックすることができる。もし、否定され
れば、エラー・メッセージが発せられる。Ｔがまだロー
ドされていなければ、チェックＴ＜＝Ｄが、Ｔのロード
を要求することができることに注意されたい。

【０１０１】完全要求駆動型ロードを伴うベリファイ処
理では、Ｄをベリファイ処理するとき、Ｄのスーパー・
クラスが、ロードされていたと仮定される。１つの例外
処理を除いて、非要求駆動型の場合と同じように処理さ
れる。Ｔ＜＝Ｄかどうかのチェックが必要とされて、Ｔ
がロードされていないことが決定されれば、ロードする
ことを避けなければならない。代わりに、制約Ｔ＜＝Ｄ
がＴに課せられる。

【０１０２】クラスごとのベリファイ処理では、状況は
異なる。Ｄのスーパー・クラスも、Ｒを宣言したクラス
Ｃもいずれもロードされていない。したがって、プロテ
クテッドレシーバ・チェックを実行することはできな
い。ＣがＤのスーパー・クラスならば、Ｃがロードされ
ているに違いないと仮定することはできない。したがっ
て、Ｒの宣言を調べることはできない。Ｒがプロテクト
されているかどうかを決定することさえできないという
ことになる。代わりに、後でプログラムが実行されると
きに、チェックされるであろう適切な制約を生成しなけ
ればならない。上記の問題は、下記の条件付きの制約を
生成させることによって解決することができる。ｉｎｖｏｋｅｏ，Ｘ．ｍの形式の全命令に対して、Ｉｆ（Ｄ＜＝Ｘ）ｔｈｅｎ｛ｉｆ（Ｘ．ｍｐｒｏｔｅ
ｃｔｅｄ）ｔｈｅｎ｛Ｔ＜＝Ｄ｝ｅｌｓｅ｛ｔ
ｒｕｅ｝｝ｅｌｓｅ｛ｔｒｕｅ｝ここで、ｏのタイプは、Ｔである。同様の戦略がフィー
ルド参照に適用される。上記の制約は、Ｄの初期化の前
に調べられる。そのポイントでは、Ｄ＜＝Ｘを決定でき
る。（Ｄとそのすべてのスーパー・クラスが既にロード
されているので）。Ｄ＜＝Ｘが真でなければ、さらなる
行動は必要ではない。ＤがＸのサブ・クラスでないなら
ば、おそらくＤは、Ｃのサブ・クラス、ｍを宣言したク
ラスではない。その理由は、Ｃが必ずＸのスーパー・ク
ラスでなければならないからである。ｍもプロテクトさ
れず、ＣがＤと同じ実行パッケージの中にあるならば、
Ｘ．ｍへの参照が適格であるにすぎないということにな
る。Ｘ．ｍへの参照が分割されるとき、上記がチェック
される。Ｄ＜＝Ｘが真ならば、Ｘ．ｍがプロテクトされ
ているかどうかをチェックすることができる。Ｘ．ｍが
プロテクトされないならば、プロテクテッド・レシーバ
・チェックを実行する必要はない。さもなければ、Ｔ＜
＝Ｄのテストを行うことができ、上記のように、Ｔがロ
ードされることになる。

【０１０３】完全要求駆動型ベリファイ処理と、クラス
ごとのベリファイ処理を組みあわせると、下記を除き、
クラスごとのベリファイ処理のための手順に従うことに
なる。以下の条件付きの制約を評価するとき、ｉｆ（Ｄ＜＝Ｘ）ｔｈｅｎ｛ｉｆ（Ｘ．ｍｐｒｏｔｅ
ｃｔｅｄ）ｔｈｅｎ｛Ｔ＜＝Ｄ｝ｅｌｓｅ｛ｔｒｕ
ｅ｝｝ｅｌｓｅ｛ｔｒｕｅ｝Ｔ＜＝Ｄを評価しなければならず、そして、Ｔがロード
されていないならば、要求駆動型の場合と同じように、
Ｔに、ロード制約Ｔ＜＝Ｄを課さなければならない。

【０１０４】ベリファイ処理によって、いくつかの前に
実行されたステートメントの後続ステートメントである
ステートメントの、すなわち２つ以上のブランチが一点
に集まるところで、オペランド・スタックの状態を調べ
るとき、別の制約も適切である。ここで、現在、ベリフ
ァイ処理は、オペランド・スタックのスナップショット
と、現在の命令が後続である、先行の命令からのローカ
ル変数とをマージさせるよう設計される。まだロードさ
れていないクラスにおいて定義されるタイプが参照され
るならば、クラスごとのベリファイ処理では常時事実で
あり、完全要求駆動型ロードでの場合事実であることが
あるが、そのタイプ格子は、利用可能ではなく、ＬＵＢ
は既知ではない。図６Ｂのステップ６３８において記載
されたＬＵＢの記号表示に従うと、「ＬＵＢ＜＝クラス
Ｔ」などの制約を、下記のように記号で表示されたリス
トにある制約に置き替えることができる。Ｘ₁＾Ｘ₂＾．．．Ｘ_n＜＝Ｔ上記は、以下のように、個々のクラスＸ₁の一連の制約
に分解できる。Ｘ₁＜＝Ｔ、Ｘ₂＜＝Ｔ、．．．Ｘ_n＜＝Ｔ

【０１０５】ロードされたクラスの現在のメソッドが実
行されて、クラスＸ２の分割を必要とするブランチに進
む場合、たとえば、クラスＸ₂は、ロードされて、その
とき、制約Ｘ₂＜＝Ｔをチェックすることができる。代
わりに、Ｘ₂がロードされているとき、Ｘ₂がそのチェッ
クに合格するならば、リストから、Ｘ₂を落として、リ
ストにおける制約を書き直すことができる。

【０１０６】上記のように、いくつかのステップの内の
いずれかのステップ（たとえば、ステップ６５０、ステ
ップ７５０、ステップ８８９、ステップ８８５）におい
て、その制約を書き込み、次に、いくつかのチェック・
ステップの内のいずれかのステップ（たとえば、ステッ
プ６７３、ステップ７８８、ステップ８８８）において
その制約をチェックする。

【０１０７】ＬＵＢの上記記号表示によって、収束する
実際の計算時間が長くなることがある。しかしながら、
ＪＶＭの固定プールのクラス・ファイルは有限なので、
上記プロセスは確実に収束する。したがって、１つのメ
ソッドは、直接的に、または間接的に、有限の数のタイ
プしか参照することはできない。その結果、ＬＵＢの記
号表示は、クラス名、Ｘ₁＾．．．＾Ｘ_nの有限系列でな
ければならない。また、上記によって、タイプ推論アル
ゴリズムによる繰り返しの数は、ＪＶＭに対して、有限
であることになる。その理由は、新しいタイプが、ＬＵ
Ｂに追加できるまで繰り返しが続くからである。

【０１０８】本発明は詳細に記載され、図示されたが、
説明と実施形態としてのみ行なわれたもので、何ら制限
を加えるためのものではなく、添付の請求項目によって
のみ本発明の趣旨と範囲が制限されることは明らかであ
る。

【図面の簡単な説明】

【図１Ａ】本発明の実行のための使用に適したコンピュ
ータ・システムの例を示す。

【図１Ｂ】図１Ａのコンピュータのハードウェア構成の
例を示すブロック構成図である。

【図１Ｃ】本発明による、プログラムとデータ情報を記
憶するするのに適した記憶媒体の例を示す図である。

【図１Ｄ】本発明による、データとプログラムを伝送す
るのに適したネットワーク・アーキテクチャのブロック
構成図である。

【図１Ｅ】本発明による構成をもつコンピュータのブロ
ック構成図である。

【図２】ＪＡＶＡ（登録商標）プログラミング言語に類
似の疑似言語で書かれたメソッドＦＯＯと参照クラスＡ
とＢを有するクラスＢＡＲの１つの例である。

【図３】図２の例のクラスＢＡＲの完全要求駆動型ロー
ドを示すフロー・チャートである。

【図４Ａ】図２の例のクラスＢＡＲの概要求駆動型ロー
ドを示すフロー・チャートである。

【図４Ｂ】図４Ａに示した概要求駆動型ロードのステッ
プ４７５のために最新版のＪＶＭに使用されているアク
セス−タイプのチェック法を示すフロー・チャートであ
る。

【図５Ａ】図２の例のクラスＢＡＲのための図４Ａのリ
ンク・ステップ４３５でのベリファイ処理を示すフロー
・チャートである。

【図５Ｂ】図２の例のクラスＢＡＲのために、図５Ａの
ステップ５３０の１つの実施形態におけるメソッドのベ
リファイ処理を示すフロー・チャートである。

【図５Ｃ】図５Ｂのベリファイ処理ステップ５３７にお
ける命令ベリファイ処理を示すフロー・チャートであ
る。

【図６Ａ】完全要求駆動型ロードが可能な図２の例のク
ラスＢＡＲのための図５Ａのステップ５３０における本
発明の実施形態によるメソッド・ベリファイ処理を示す
フロー・チャートである。

【図６Ｂ】本発明の実施形態による、図６Ａの命令ベリ
ファイ処理ステップ６３７における命令ベリファイ処理
を示すフロー・チャートである。

【図６Ｃ】本発明の実施形態による、図２の例のクラス
ＢＡＲのための図４Ａのステップ４７５におけるベリフ
ァイ制約チェックを示すフロー・チャートである。

【図７Ａ】例のクラス「ＢＡＲ」のために図２から一度
にクラスプレベリファイについて表現するフロー・チャ
ートである。

【図７Ｂ】図７Ａのステップ７１６におけるメソッドの
ベリファイ前処理を示すフロー・チャートである。

【図７Ｃ】本発明の１つの実施形態による図２の例のク
ラスＢＡＲの実行時のベリファイ処理中における図５Ａ
のステップ５３０のクラスごとのベリファイ前処理の利
用を示すフロー・チャートである。

【図８】図２の例のクラスＢＡＲのクラスごとのベリフ
ァイ前処理による完全要求駆動型ロードを可能にする、
本発明の別の実施形態による、図５Ａのステップ５３０
におけるクラスごとのベリファイ前処理の利用を示すフ
ロー・チャートである。

【図９】本発明の別の実施形態による、信頼性のあるク
ラスと、ベリファイ制約のために、キャッシュを有し
て、ベリファイ前処理を行うよう構成されたコンピュー
タのブロック構成図である。

【符号の説明】

１１０Ａ、１１０Ｂディスク・ドライブ装置１００中央演算処理装置１２０表示装置１２５表示装置インタフェース１３０キーボード１４０マウス１５０バス１５０、１５１、１６７仮想マシン（ＶＭ）１５５ＣＰＵ１６０読出し専用記憶装置１６２ソース・コード・ステートメント１６４コンパイラ１６５ランダム・アクセス・メモリ１６７仮想マシン（ＶＭ）１７０ディスク制御装置１７１ＣＤーＲＯＭドライブ装置、ＤＶＤドライブ
装置１７２ハード・ディスク・ドライブ装置１７３フロッピー・ディスク・ドライブ装置１２５表示装置インタフェース１７５通信ポート１９０ネットワーク３１０、３２０、３３５、４１０、４４０ステップＬ１、Ｌ２、Ｌ３クラス・ローダ

───────────────────────────────────────────────────── フロントページの続き (72)発明者ギラッドブラーチャアメリカ合衆国カリフォルニア州 94024，ロスアルトスファーンドンアベニュー 2042 (72)発明者シェンリャンアメリカ合衆国カリフォルニア州 94041，マウンテンビュー＃23，カルデロンアベニュー 210 (72)発明者ティモシージー．リンドルムアメリカ合衆国カリフォルニア州 94301，パロアルトミドルフィールドロード 623

Claims

【特許請求の範囲】

【請求項１】コンピュータ・プログラムのモジュール
内の命令を１回１モジュール・ベリファイ処理する方法
であって、最初のモジュール内の命令をチェックして、その最初の
モジュールとは異なる参照モジュール内の情報が要求さ
れるかどうかを決定するステップと、もしその情報が要求されれば、その参照モジュールにア
クセスすることを要求することなく、その参照モジュー
ルのための制約を書き込むステップと、を含む方法。
【請求項２】その命令に要求される内部モジュール・
チェックを実行するステップと、その最初のモジュール内の命令をチェックして、その参
照モジュール内の情報が要求されるかどうかの決定を、
その最初のモジュール内の必要とされる命令が前記決定
にかかるまで行うステップに戻るステップと、をさらに
含む、請求項１に記載の方法。
【請求項３】もし、その命令が内部モジュール・チェ
ックに合格できないとき、前記内部モジュール・チェッ
クの実行が、エラー・メッセージを送るステップをさら
に含む、請求項２に記載の方法。
【請求項４】リンク中に、コンピュータ・プログラム
のモジュールの命令をベリファイ処理する方法であっ
て、ロードされた最初のモジュールが１回１モジュール・ベ
リファイ前処理に合格したかどうかを決定するステップ
と、もし、その最初のモジュールがベリファイ前処理に合格
していれば、もしあれば、制約付きモジュールに課せら
れるベリファイ前処理制約を読み込むステップと、もし、ベリファイ前処理制約が読み込まれていれば、そ
の制約付きモジュールがロードされているかどうかを決
定するステップと、もし、その制約付きモジュールがロードされていれば、
そのベリファイ前処理制約を実施するステップと、を含
む方法。
【請求項５】もし、その制約付きモジュールがベリフ
ァイ前処理制約に合格できないとき、ベリファイ前処理
制約を実施する前記ステップが、エラー・メッセージを
送るステップをさらに含む、請求項４に記載の方法。
【請求項６】もし、その制約付きモジュールがロード
されていなければ、その制約付きモジュールをロードす
るステップと、その前記ベリファイ前処理制約を実施す
るステップをさらに含む、請求項４に記載の方法。
【請求項７】もし、その制約付きモジュールが、前記
実施中に、その前記ベリファイ前処理制約に合格すれ
ば、ベリファイ前処理制約すべてが読み込まれるまで
は、制約付きモジュールに課せられるベリファイ前処理
制約を読み込むステップに戻るステップをさらに含む、
請求項４に記載の方法。
【請求項８】もし、その制約付きモジュールが、前記
実施中に、その前記ベリファイ前処理制約に合格すれ
ば、ベリファイ前処理制約すべてが読み込まれるまで
は、制約付きモジュールに課せられるベリファイ前処理
制約を読み込むステップに戻るステップをさらに含み、
その結果、その最初のモジュールがベリファイ処理され
る、請求項６に記載の方法。
【請求項９】コンピュータ・プログラムのモジュール
内の命令を１回１モジュール・ベリファイ処理するコン
ピュータ・プログラム生成物であって、コンピュータが読み込みできる記憶媒体と、コンピュータが読み込みできる記憶媒体に記憶されたコ
ンピュータ制御コマンドであって、最初のモジュール内
の命令をチェックして、その最初のモジュールとは異な
る参照モジュール内の情報が要求されるどうかを決定
し、そして、もしその情報が要求されれば、その参照モ
ジュールにアクセスすることを要求することなく、その
参照モジュールのための制約を書き込むコンピュータ制
御コマンドと、を含むコンピュータ・プログラム生成
物。
【請求項１０】そのコンピュータが読み込みできる記
憶媒体に記憶されて、その命令に要求される内部チェッ
クを行い、その最初のモジュール内の命令をチェックし
て、その参照モジュール内の情報が要求されるかどうか
の決定を、その最初のモジュール内の必要とされる命令
が前記決定にかかるまで行うステップに戻る、コンピュ
ータ制御コマンドをさらに含む、請求項９に記載のコン
ピュータ・プログラム生成物。
【請求項１１】そのコンピュータが読み込みできる記
憶媒体に記憶されて、もし、その命令が内部モジュール
・チェックを満足することができなければ、エラー・メ
ッセージを送るコンピュータ制御コマンドをさらに含
む、請求項１０に記載のコンピュータ・プログラム生成
物。
【請求項１２】リンク中に、コンピュータ・プログラ
ムのモジュールの命令をベリファイ処理するコンピュー
タ・プログラム生成物であって、コンピュータが読み込みできる記憶媒体と、コンピュータが読み込みできる記憶媒体に記憶されて、
ロードされている最初のモジュールが１回１モジュール
・ベリファイ前処理に合格したかどうかを決定し、も
し、その最初のモジュールがベリファイ処理に合格して
いれば、もしあれば、制約付きのモジュールに課せられ
るベリファイ前処理制約を読み込み、ベリファイ前処理
制約が読み込まれていれば、その制約付きモジュールが
ロードされているかどうかを決定し、そして、その制約
付きモジュールがロードされていれば、そのベリファイ
前処理制約を実施するコンピュータ制御コマンドと、を
含むコンピュータ・プログラム生成物。
【請求項１３】コンピュータが読み込みできる記憶媒
体に記憶されて、そのベリファイ前処理制約を実施中
に、その制約付きモジュールがベリファイ前処理制約を
満足することができなければ、エラー・メッセージを送
るコンピュータ制御コマンドをさらに含む、請求項１２
に記載のコンピュータ・プログラム生成物。
【請求項１４】コンピュータが読み込みできる記憶媒
体に記憶されて、もし、その制約付きモジュールがロー
ドされていなければ、その制約付きモジュールをロード
して、そのベリファイ前処理制約を実施するコンピュー
タ制御コンドをさらに含む、請求項１２に記載のコンピ
ュータ・プログラム生成物。
【請求項１５】コンピュータが読み込みできるその記
憶媒体に記憶されて、もし、前記実施中に、制約付きモ
ジュールがベリファイ前処理制約に合格するなら、すべ
てのベリファイ前処理制約を読み込むまで、制約付きモ
ジュールに課せられるベリファイ前処理制約を読み込む
ステップに戻るコンピュータ制御コマンドをさらに含
む、請求項１２に記載のコンピュータ・プログラム生成
物。
【請求項１６】コンピュータが読み込みできるその記
憶媒体に記憶されて、もし、前記実施中に、制約付きモ
ジュールがベリファイ前処理制約に合格するなら、すべ
てのベリファイ前処理制約を読み込むまで、制約付きモ
ジュールに課せられるベリファイ前処理制約を読み込む
ステップに戻るコンピュータ制御コマンドをさらに含
み、その結果、その最初のモジュールをベリファイ処理
する、請求項１４に記載のコンピュータ・プログラム生
成物。
【請求項１７】モジュールを１回１モジュール・ベリ
ファイ処理するベリファイ前処理装置であって、コンピュータ・プログラムのモジュールと制約を記憶す
る、コンピュータが読み込みできる記憶媒体と、最初のモジュール内の命令をチェックして、その最初の
モジュールと異なる参照モジュール内の情報が必要とさ
れるかどうかを決定し、そして、もし、その情報が要求
されれば、その参照モジュールにアクセスすることを要
求することなく、その参照モジュールのための制約を書
き込むよう構成されたプロセッサと、を含む装置。
【請求項１８】プロセッサが、その命令に要求される
内部モジュール・チェックを実行し、その最初のモジュ
ール内にある命令をチェックして、その参照モジュール
内の情報が要求されるかどうかの決定を、その最初のモ
ジュール内の必要とされる命令が前記決定にかかるまで
行うステップに戻るようさらに構成されている、請求項
１７のベリファイ前処理装置。
【請求項１９】プロセッサは、命令が内部モジュール
・チェックを満足することができなければ、エラー・メ
ッセージを送るようさらに構成されている、請求項１８
のベリファイ前処理装置。
【請求項２０】リンク中に、モジュールをベリファイ
処理するベリファイ処理装置であって、コンピュータ・プログラムのモジュールを記憶するコン
ピュータが読み込みできる記憶媒体と、モジュールをロードするメモリと、ロードした最初のモジュールが１回１モジュールベリフ
ァイ前処理に合格したかどうかを決定し、もし、その最
初のモジュールがベリファイ処理に合格していれば、も
しあれば、制約付きのモジュールに課せられるベリファ
イ前処理制約を読み込み、もし、ベリファイ前処理規約
が読み込まれていれば、その制約付きモジュールがロー
ドされているかどうかを決定し、そして、その制約付き
モジュールがロードされていれば、ベリファイ前処理制
約を実施するよう構成されたプロセッサと、を含む装
置。
【請求項２１】プロセッサは、もし、その制約付きモ
ジュールが、前記実施中に、ベリファイ前処理を満足す
ることができなければ、エラー・メッセージを送るよう
さらに構成されている、請求項２０に記載のベリファイ
処理装置。
【請求項２２】プロセッサは、その制約付きモジュー
ルをロードし、もし、その制約付きモジュールがまだロ
ードされていなければ、そのベリファイ前処理制約を実
施するようさらに構成されている、請求項２０に記載の
ベリファイ処理装置。
【請求項２３】プロセッサが、もし、前記実施中に、
制約付きモジュールがベリファイ前処理制約に合格する
なら、すべてのベリファイ前処理制約を読み込むまで、
制約付きモジュールに課せられるベリファイ前処理制約
を読み込むステップに戻るようさらに構成されている、
請求項２０に記載のベリファイ処理装置。
【請求項２４】プロセッサは、もし、前記実施中に、
制約付きモジュールがベリファイ前処理制約に合格する
なら、すべてのベリファイ前処理制約を読み込むまで、
制約付きモジュールに課せられるベリファイ前処理制約
を読み込むステップに戻るようさらに構成され、その結
果、その最初のモジュールがベリファイ処理される、請
求項２２に記載のベリファイ処理装置。
【請求項２５】通信線路上の搬送波と、その搬送波を使用して伝送される、コンピュータ制御コ
マンドを示す信号であって、コンピュータ・プログラム
の最初のモジュール内の命令をチェックして、その最初
のモジュールとは異なる参照モジュール内の情報が要求
されているかどうかを決定し、そして、もし、その情報
が要求されていれば、その参照モジュールにアクセスす
ることを要求することなく、その参照モジュールのため
の制約を書き込む信号とを含む、信号伝送装置。
【請求項２６】その搬送波を使用して伝送されて、命
令に要求される内部モジュール・チェックを行なって、
その最初のモジュール内の命令をチェックして、その参
照モジュール内の情報が要求されているかどうかの決定
を、その最初のモジュール内の必要とされる命令が前記
決定にかかるまで行うステップに戻るコンピュータ制御
コマンドをさらに含む、請求項２５に記載の信号伝送装
置。
【請求項２７】その搬送波を使用して伝送されて、そ
の命令が内部モジュール・チェックを満足することがで
きなければ、エラー・メッセージを送るコンピュータ制
御コマンドをさらに含む、請求項２６に記載の信号伝送
装置。
【請求項２８】通信線路上の搬送波と、その搬送波を使用して伝送される、コンピュータ制御コ
マンドを示す信号であって、ロードされている最初のモ
ジュールが１回１モジュール・ベリファイ前処理に合格
したかどうかを決定し、もし、その最初のモジュールが
ベリファイ前処理に合格していれば、もしあれば、制約
付きモジュールに課せられるベリファイ前処理制約を読
み込み、もし、ベリファイ前処理制約が読み込まれてい
れば、その制約付きモジュールをロードするかどうかを
決定し、そして、その制約付きモジュールがロードされ
ていれば、そのベリファイ前処理制約を実施する信号
と、を含む信号伝送装置。
【請求項２９】その搬送波を使用して伝送されて、そ
のベリファイ前処理制約を実施中に、その制約付きモジ
ュールがそのベリファイ前処理制約を満足できなけれ
ば、エラー・メッセージを送るコンピュータ制御コマン
ドをさらに含む、請求項２８に記載の信号伝送装置。
【請求項３０】その搬送波を使用して伝送されて、そ
の制約付きモジュールをロードし、もし、その制約付き
モジュールがまだロードされていなければ、そのベリフ
ァイ前処理制約を実施するコンピュータ制御コマンドを
さらに含む、請求項２８に記載の信号伝送装置。
【請求項３１】その搬送波を使用して伝送されて、前
記実施中に、その制約付きモジュールがそのベリファイ
前処理制約に合格するならば、すべてのベリファイ前処
理制約を読み込むまで、制約付きモジュールに課せられ
るベリファイ前処理制約を読み込むステップに戻るコン
ピュータ制御コマンドをさらに含む、請求項２８に記載
の信号伝送装置。
【請求項３２】その搬送波を使用して伝送されて、前
記実施中に、その制約付きモジュールがそのベリファイ
前処理制約に合格すれば、すべてのベリファイ前処理制
約を読み込むまで、制約付きモジュールに課せられるベ
リファイ前処理制約を読み込むステップに戻るコンピュ
ータ制御コマンドをさらに含み、その結果、その最初の
モジュールがベリファイ処理される、請求項３０に記載
の信号伝送装置。
【請求項３３】ネットワークと、コンピュータ・プログラムのモジュールを記憶するため
の、ネットワークに接続されて、コンピュータが読み込
みできる記憶媒体と、モジュールをロードする、ネットワークに接続されたメ
モリと、最初のモジュール内の命令をチェックして、最初のモジ
ュールと異なる参照モジュール内の情報が必要となるか
どうかを決定し、そして、情報が要求されるならば、そ
の参照モジュールにアクセスすることを要求することな
く、その参照モジュールのための制約を書き込むよう構
成されて、その結果、１回１モジュール・ベリファイ前
処理が実行される、ネットワークに接続されたプロセッ
サと、そして、ロードされた最初のモジュールが、リンク前に１回１モ
ジュール・ベリファイ前処理に合格したかどうかをリン
ク中に決定し、その最初のモジュールがベリファイ前処
理に合格していれば、もしあるとすれば、制約付きモジ
ュールに課せられるベリファイ前処理制約を読み込み、
ベリファイ前処理制約が読み込まれていれば、制約付き
モジュールをロードするかどうか決定し、そして、制約
付きモジュールが既にロードされていれば、ベリファイ
処理制約を実施するよう構成される、ネットワークに接
続されたプロセッサと、を含み、その結果リンク前に１
回１モジュール・ベリファイ処理を実行し、リンク中は
ベリファイ処理を抑える、ベリファイ前処理システム。