JP2002522844A - バーチャル・マシン環境でネイティブ・コードを変換し、実行する方法および装置 - Google Patents

Abstract

(57)【要約】 バーチャルマシン環境においてネイティブコードを変換し、実行する方法と装置。バーチャルマシン実施デバッキングは、ネイティブ・コードのバイナリ変換によって容易になる。プラットフォーム独立性を高め、スレッド管理とスケジューリングに対する制御が向上し、ネイティブコードにおけるメモリアクセス・エラーの識別を提供する。バーチャルマシン内でネイティブ・コードが実行されると、ネイティブ・コードは中間フォームに変換される。この中間フォームは処理され、メモリアクセスとブロッキングシステムコールが生じる箇所を決定する。メモリアクセスされたコールに妥当性チェックが挿入され、各コールによってアクセスされるメモリの部分が許可範囲にあるかどうかが決定される。ネイティブコードに関連したワイルドポインタとメモリアクセスエラーの他のソースが識別される。ブロッキングシステムコールが非ブロッキング変数に置き換えられ、かつイールドオペレーションがシステムコールとループとに挿入される。リバイズされたネイティブコードが組み込まれたメモリアクセス妥当性チェックと非ブロッキングシステムコールがバーチャルマシンによってコンパイルされ、インタプリートされ、ネイティブコードで定義されたルーチンが実行される。リバイズされたネイティブコードは他のスレッドをブロックしないので、スレッドスケジューリングが基礎となるオペレーティングシステムではなくバーチャルマシンによって管理され、かつ協調的なスケジューリングが実施される。

Description

【発明の詳細な説明】

【０００１】 （発明の背景） １．発明の分野 本発明は、コンピュータ・システムの分野に関するものであり、より詳細には
、バーチャル・マシン実行環境に関する。

【０００２】 Ｓｏｌａｒｉｓ、Ｓｕｎ、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ、Ｓｕｎロゴ、
Ｊａｖａ、およびＪａｖａベースの商標およびロゴは、米国および他国のＳｕｎ
Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．の商標または登録商標である。

【０００３】 ２．背景技術 Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ（登録商標）によって開発されたＪａｖａ ^TM プログラミング言語は、「ｗｒｉｔｅ ｏｎｃｅ，ｒｕｎ ａｎｙｗｈｅｒｅ
」^TM言語であるという、他のプログラミング言語に優る利点を有している。Ｊａ
ｖａプログラミング言語は、バイトコード・クラス・ファイルの形式で設計され
、配布され、実行される、実質的にアプリケーションのためのプラットフォーム
非依存な機構、つまり「アプレット」を用意している。Ｊａｖａバーチャル・マ
シンは、Ｊａｖａバーチャル・マシンを含んでいるすべてのコンピュータ・プラ
ットフォームが同じバイトコード・クラス・ファイルを実行することができるよ
うに、バイトコードを必要なプラットフォーム依存命令セットに還元する処理を
行う。Ｊａｖａプログラミング言語によってサポートされていない機能が必要な
とき、バーチャル・マシン内で実行中のＪａｖａアプリケーションは、リンクさ
れたライブラリ内で実装されるネイティブ・コード関数をコールすることができ
る。ネイティブ・コードは、Ｊａｖａプログラミングおよびその実行の制約を受
けず、したがって、それほど制御の良くない実行動作という代償を払って、より
プラットフォームに固有なプログラム可能性を提供する。Ｊａｖａアプリケーシ
ョンおよびＪａｖａアプレットのための処理環境、ならびにネイティブ・コード
の使用について、下記でより十分な説明を行う。

【０００４】 処理環境 Ｊａｖａプログラミング言語は、各プログラムが１つまたは複数のオブジェク
ト・クラスおよびインターフェースを含んでいるオブジェクト指向プログラミン
グ言語である。プログラムがマシン依存の実行可能プログラム・コードにコンパ
イルされる多くのプログラミング言語とは異なり、Ｊａｖａプログラミング言語
で書かれたクラスは、マシン非依存のバイトコード・クラス・ファイルにコンパ
イルされる。各クラスは、クラス・ファイル・フォーマットと呼ばれるプラット
フォーム非依存フォーマットのコードおよびデータを含む。実行ビークルとして
動作するコンピュータ・システムは、各クラス内のコードを実行することを担う
、バーチャル・マシンと呼ばれるプログラムを含む。

【０００５】 アプリケーションは、独立型Ｊａｖａアプリケーションとして、またはＨＴＭ
Ｌ（ハイパーテキスト・マークアップ言語）文書内のアプレット・タグによって
識別され、ブラウザ・アプリケーションによってロードされるＪａｖａ「アプレ
ット」として設計することができる。アプリケーションまたはアプレットに関連
付けられたクラス・ファイルは、ローカル・コンピュータ・システム上に、また
はネットワークを介してアクセス可能なサーバ上に記憶することができる。各ク
ラスは、必要に応じて、「クラス・ローダ」によってＪａｖａバーチャル・マシ
ンにロードされる。

【０００６】 ネットワーク上で、サーバからクラスに対するアクセスをクライアントに提供
するために、サーバ上でウェブ・サーバ・アプリケーションが実行されて、「ウ
ェブ・ページ」とも呼ばれるＨＴＭＬ文書に対する、ＵＲＬ（ユニフォーム・リ
ソース・ロケータ）を含んだＨＴＴＰ要求に応答する。クライアント・プラット
フォーム上で実行中のブラウザ・アプリケーションが、ＨＴＭＬ文書を受け取っ
たとき（例えば、ＵＲＬをウェブ・サーバに転送することによってＨＴＭＬ文書
を要求した結果として）、ブラウザ・アプリケーションは、そのＨＴＭＬを構文
解析して、そのＨＴＭＬ文書内でアプレット・タグに出会ったとき、指定のバイ
トコード・クラス・ファイルのダウンロードを自動的に開始する。

【０００７】 Ｊａｖａアプレットのクラスは、Ｊａｖａアプレットの実行中に最初に参照さ
れたとき、オンデマンドで、ネットワークから（サーバ上に記憶されている）、
またはローカル・ファイル・システムからロードされる。バーチャル・マシンは
、各クラス・ファイルを探し出して、ロードし、クラス・ファイルの構文解析を
行って、クラスの様々な構成要素にメモリを割振り、そのクラスを他の既にロー
ドされているクラスとリンクする。この処理は、クラス内のコードが、バーチャ
ル・マシンによって容易に実行可能なようにする。

【０００８】 ＪａｖａアプリケーションおよびＪａｖａアプレットはしばしば、クラス・ラ
イブラリを使用する。クラス・ライブラリ内のクラスは、「ネイティブ・メソッ
ド」と呼ばれるものを含む。アプリケーションおよびアプレットは、時として、
ネイティブ・メソッドを有しているクラスを含む。ネイティブ・メソッドは、「
ネイティブ」というキーワード、スレッドの名前、メソッドの戻り値の型、およ
びメソッドに渡されるすべてのパラメータを指定する。Ｊａｖａプログラミング
言語で書かれる「標準メソッド」（すなわち、非ネイティブ・メソッド）とは対
照的に、ネイティブ・メソッドには、それぞれのクラス内でのボディが存在しな
い。その代わりに、ネイティブ・メソッドのルーチンは、リンクされたライブラ
リをサポートする任意のプラットフォームに固有のリンク機能を使用して実行時
にバーチャル・マシン内の任意のクラスと動的にリンクされる、ネイティブ・コ
ード（例えば、ＣまたはＣ＋＋プログラミング言語で書かれ、バイナリ・フォー
ムにコンパイルされたコード）によって実行される。

【０００９】 例えば、Ｓｏｌａｒｉｓ^TMまたはＵＮＩＸ（登録商標）の環境では、バイナリ ・フォームのネイティブ・コードを含むリンクされたライブラリは、「ｓｏ．」 ファイルとして書かれた「共有オブジェクト」ライブラリとして実装することが できる。Ｗｉｎｄｏｗｓ（登録商標）の環境では、リンクされたライブラリは、 「．ｄｌｌ」ファイルとして書かれた動的にリンクされた（または動的にロード 可能な）ライブラリのフォームを取ることが可能である。ネイティブ・コードは 、そうでなければ、Ｊａｖａプログラミング言語によってサポートされない機能 、例えば、任意のプラットフォームの専用ハードウェア（例えば、表示ハードウ ェア）またはソフトウェア（例えば、データベース・ドライバ）とインターフェ ースをとることなどを実行するために使用することができる。ネイティブ・コー ドはまた、レンダリングなどの計算上インテンシブな機能をスピードアップする ために使用することもできる。

【００１０】 ネイティブ・メソッドを含むクラスはまた、それれぞれのリンクされたライブ
ラリをロードするコールも含む。 Ｓｙｓｔｅｍ．ＬｏａｄＬｉｂｒａｒｙ（“Ｓａｍｐｌｅ”） ここで、「Ｓａｍｐｌｅ」は、システムを動作させるホスト（例えば、ＵＮＩＸ
、Ｗｉｎｄｏｗｓ等）により、「ｌｉｂＳａｍｐｌｅ．ｓｏ」または「Ｓａｍｐ
ｌｅ．ｄｌｌ」という名前が付けられたファイルに通常、格納されている、リン
クされたライブラリの名前である。通常、リンクされたライブラリは、関連付け
られたクラスがバーチャル・マシン内でインスタンス化された時点でロードされ
る。

【００１１】 ネイティブ・コードのリンクされたライブラリは、リンクされたライブラリが
クラス内のネイティブ・メソッドのメソッド署名を認識できるようにするため、
関連付けられたクラスのスタブおよびヘッダ情報とともにコンパイルされる。次
に、ネイティブ・メソッドの実施が、リンクされたライブラリ内のネイティブ・
コード関数（Ｃ関数など）として行われる。実行時に、ネイティブ・メソッドに
対するコールが行われたとき、コールされたメソッドに対応するリンクされたラ
イブラリ内の機能に制御が渡される（例えば、ネイティブ・メソッド・スタック
上にネイティブ・メソッド・フレームを押し付けることを介して）。リンクされ
たライブラリ内のネイティブ・コードは、その機能を実行して、Ｊａｖａアプリ
ケーションまたはＪａｖａアプレットに制御を戻す。

【００１２】 図１は、処理システムのためのコンパイル環境および実行環境を図示している
。コンパイル環境で、ソフトウェア開発者が、データ構造、メソッド実装、およ
び他のクラスに対する参照を含んだ、プログラマ可読クラス定義を含むソース・
ファイル１００を作成する（例えば、Ｊａｖａプログラミング言語で）。ソース
・ファイル１００は、Ｊａｖａコンパイラ１０１に提供され、これがソース・フ
ァイル１００を、Ｊａｖａバーチャル・マシンによって実行可能なバイトコード
を含むコンパイルされた「クラス」ファイル１０２にコンパイルする。バイトコ
ード・クラス・ファイル１０２は、サーバ上に記憶され（例えば、一時記憶また
は永久記憶で）、ネットワークを介してダウンロードのために利用可能である。
別法では、バイトコード・クラス・ファイル１０２は、ローカルに、クライアン
ト・プラットフォーム上のディレクトリ内に格納することができる。

【００１３】 Ｊａｖａ実行環境は、バイトコード・クラス・ファイルを実行することができ
、また実行中に必要なとき、オペレーティング・システム１０９に対してネイテ
ィブ・オペレーティング・システム（「Ｏ／Ｓ」）コールを実行することができ
る、Ｊａｖａバーチャル・マシン（ＪＶＭ）１０５を含む。Ｊａｖａバーチャル
・マシン１０５は、バイトコード・クラスのマシン非依存性と基礎となっている
コンピュータ・ハードウェアのマシン依存命令セットならびにオペレーティング
・システム１０９のプラットフォーム依存コールとの間で抽象化のレベルを提供
している。

【００１４】 クラス・ローダおよびバイトコード検証器（「クラス・ローダ」）１０３は、
必要に応じてＪａｖａバーチャル・マシンに、バイトコード・クラス・ファイル
１０２をロードすること、ならびにクラス・ライブラリ１０４をサポートするこ
とを担う。クラス・ローダ１０３はまた、各クラスのバイトコードを検証して、
セキュリティ規則の適切な実行および実施を維持する。実行時システム１０８の
コンテキスト内では、バイトコードが、ハードウェア１１０内のプロセッサ（ま
たは複数のプロセッサ）によって実行され得るように、インタープリタ１０６が
バイトコードを直接に実行するか、または「ジャスト・イン・タイム」（ＪＩＴ
）コンパイラ１０７がバイトコードをマシン・コードに変換するかのいずれかで
ある。例えば、リンクされたライブラリ１１１という形式のネイティブ・コード
は、関連付けられたネイティブ・メソッドを含むクラス（例えば、クラス・ライ
ブラリ１０４からの）がバーチャル・マシン内でインスタンス化されたときにロ
ードされる。

【００１５】 バーチャル・マシン１０５の実行時システム１０８は、汎用スタック・アーキ
テクチャをサポートする。この汎用スタック・アーキテクチャが基礎となるハー
ドウェア１１０によってサポートされる方法は、バーチャル・マシンの特定の実
装によって決定され、バイトコードが解釈されるスレッド、またはＪＩＴコンパ
イルされるスレッドに反映される。実行時システムの他のエレメントは、スレッ
ド管理（例えば、スケジューリング）機構およびごみ収集機構を含む。

【００１６】 図２は、実行時システム１０８内のスタック・アーキテクチャをサポートする
実行時データ・エリアを図示している。図２で、実行時データ・エリア２００は
、１つまたは複数のスレッド・ベースのデータ・エリア２０７を含む。スレッド
・ベースの各データ・エリア２０７は、プログラム・カウンタ・レジスタ（ＰＣ
ＲＥＧ）２０８、ローカル変数ポインタレジスタ（ＶＡＲＳ ＲＥＧ）２０９
、フレーム・レジスタ（ＦＲＡＭＥ ＲＥＧ）２１０、オペランド・スタック・
ポインタ・レジスタ（ＯＰＴＯＰ ＲＥＧ）２１１、スタック２１２（例えば、
標準メソッドの場合）、およびオプションとして、ネイティブ・メソッド・スタ
ック２１６を含む。スタック２１２は、オペランド・スタック２１４およびロー
カル変数２１５を含んだ１つまたは複数のフレーム２１３を含む。ネイティブ・
メソッド・スタック２１６は、１つまたは複数のネイティブ・メソッド・フレー
ム２１７を含む。

【００１７】 実行時データ・エリア２００はさらに、共有ヒープ２０１を含む。ヒープ２０
１は、そこからすべてのクラスのインスタンスおよび配列に対するメモリが割振
られる実行時データ・エリアである。共有ヒープ２０１は、すべてのスレッドの
間で有されるメソッド・エリア２０２を含む。メソッド・エリア２０２は、ロー
ドされた各クラス・ファイルから抽出された情報を記憶するための１つまたは複
数のクラス・ベースのデータ・エリア２０３を含む。例えば、クラス・ベースの
データ・エリア２０３は、コンスタント・プール２０４、フィールドおよびメソ
ッド・データ２０５、ならびにメソッドのためのコードおよびコンストラクタ２
０６を含み得る。

【００１８】 バーチャル・マシンは、一度に多くの実行のスレッドをサポートすることがで
きる。各スレッドは、それ自体のスレッド・ベースのデータ・エリア２０７を有
する。どの時点でも、各スレッドは、そのスレッドに対する「現行メソッド」で
ある、単一のスレッドのコードを実行している。「現行メソッド」がネイティブ
・メソッドではない場合、プログラム・カウンタ・レジスタ２０８は、現在、実
行されているバーチャル・マシン命令のアドレスを含む。「現行メソッド」がネ
イティブ・メソッドである場合、プログラム・カウンタ・レジスタ２０８の値は
、未定義となる。フレーム・レジスタ２１０が、メソッド・エリア２０２内の現
行メソッドのロケーションにポイントする。

【００１９】 各スレッドは、そのスレッドと同時に作成されたプライベート・スタック２１
２を有する。スタック２１２は、スレッドによって呼び出された標準メソッドに
関連付けられた１つまたは複数のフレーム２１３を格納する。フレーム２１３は
、データおよび部分的結果を格納するため、ならびにダイナミック・リンキング
、方法への戻り値、およびディスパッチ例外を実行するために使用される。標準
・メソッドが呼び出される度に新規フレームが作成され、スタックに押し上げら
れる。既存フレームは、そのメソッドが完了するとスタックから外され、破壊さ
れる。スレッドによって作成されるフレームはそのスレッドにとって局所的であ
り、通常、他のどのスレッドからも直接参照することはできない。

【００２０】 現在実行中のメソッドのためのフレームである１つのフレームだけが、制御の
所与のスレッドのいずれかのポイントで活動中である。このフレームは、「現行
フレーム」と呼ばれ、そのメソッドは「現行メソッド」として知られている。フ
レームは、そのメソッドが別のメソッドを呼び出したり、そのメソッドが完了し
た場合は、現行でなくなる。メソッドが呼び出されると、新規フレームが作成さ
れ、制御がその新規フレームに移るとそれが現行となる。メソッドが戻ると、現
行フレームはそのメソッドの呼び出しの結果がいかなるものであれ、それを前フ
レームに返す。次いで、前フレームが現行フレームになると、現行フレームは破
棄される。

【００２１】 各フレーム２１３は、一組の固有のローカル変数２１５と固有のオペランド・
スタック２１４とを有する。ローカル変数ポインタ・レジスタ２０９は、現行フ
レームのローカル変数２１５を含むワードの配列の基数を指すポインタを含む。
オペランド・スタック・ポインタ・レジスタ２１１は、現行フレームのオペラン
ド・スタック２１４のトップを指す。大部分のバーチャル・マシン命令は、現行
フレームのオペランド・スタックから値を取り、その上で動作し、同じオペラン
ド・スタックに結果を戻す。オペランド・スタック２１４は、メソッドに引数を
引き渡し、メソッドの結果を受け取ることにも使用される。

【００２２】 ネイティブ・メソッド・スタック２１６は、ネイティブ・メソッドをサポート
してネイティブ・メソッド・フレーム２１７を格納する。各ネイティブ・メソッ
ド・フレームは、スレッド実行制御、メソッド引き数およびリンクされたライブ
ラリでネイティブ・コード関数として実行される標準メソッドとネイティブ・メ
ソッドとの間でやり取りされるメソッドの結果のための機構を提供する。

【００２３】 ネイティブ・メソッドは、クラスの標準メソッドとしてではなくリンクされた
ライブラリ内のネイティブ・コードによって実行されるので、ネイティブ・メソ
ッドはＪａｖａプログラム言語およびバイトコード検証器によって課される制限
を受けることがない。すなわち、コンパイルされたＪａｖａアプリケーションお
よびアプレット用バイトコードと異なり、リンクされたライブラリにあるネイテ
ィブ・コードは、実行時にチェックなしで進行する、望まない、不正行為の対象
となりやすくなる場合がある。例えば、「ワイルド」ポインタ（例えば、８エレ
メント配列で９エレメントを指すポインタなど、禁止された範囲を値が超えたポ
インタ）の発生や不適切な（制限された、すなわち範囲外の）メモリ位置をアド
レス指定する可能性のあるメモリ・アクセス機構の使用により、メモリ・アクセ
ス・エラーが起こることがある。したがって、ネイティブ・メソッドの使用によ
り、大部分はポインタの使用に基づいて、特定バーチャル・マシンのデバッグの
実行をより困難にするプログラム・バグの分類が可能になる。

【００２４】 さらに、ネイティブ・コードは、ブロッキング・システム・コール（すなわち
、未指定の期間、外部イベントの発生を待つことのできるコール）を含むことが
できる。バーチャル・マシンがその固有のスレッド管理とスケジューリングとを
実行するならば、リンクされたライブラリ内のネイティブ・コード関数に制御が
渡された時に発生するブロッキング・システム・コールは、バーチャル・マシン
全体の実行をブロックすることができる。

【００２５】 大部分のバーチャル・マシンを実行すると、「ネイティブ・スレッディング」
を使用することによってネイティブ・コードに関連付けられたブロッキング問題
が回避される。すなわち、バーチャル・マシンの複数のスレッドと、バーチャル
・マシンが実行中の１つまたは複数のプログラム（例えば、アプリケーションお
よび／またはアプレット）が、基礎となるプラットフォームのスレッド、例えば
ＵＮＩＸスレッドとして実行される。このメソッドでは、バーチャル・マシンの
スレッドを同時に実行することができる。ただし、ネイティブ・スレッディング
が使用されると、バーチャル・マシンは、計画中のスレッドに優先して基礎とな
るオペレーティング・システムに制御を引き渡さなければならない。したがって
、ネイティブ・スレッディングを使用すると、スレッドの挙動はオペレーティン
グ・システム依存およびハードウェア依存になる。バーチャル・マシン実行中の
並行性に関係したバグの効果的なデバッグは不確かなものとなる。それは、ネイ
ティブ・スレッディングを使用した、スレッドを実行する相対的なタイミングが
、異なるオペレーティング・システムおよびハードウェアのプラットフォームを
通して変化することがあるからである。

【００２６】 図３Ａおよび３Ｂは、実行環境下におけるスレッドの使用を示すブロック図で
ある。図３Ａは、ネイティブ・スレッディングを使用しないバーチャル・マシン
を含む。図３Ｂは、ネイティブ・スレッディングを使用するバーチャル・マシン
を含む。

【００２７】 図３Ａで、オペレーティング・システム１０９はハードウェア１１０の上で実
行されており、バーチャル・マシン１０５はオペレーティング・システム１０９
の上で実行されている。バーチャル・マシン１０５では、アプレット１（３００
）およびアプレット２（３０１）のような複数のアプリケーションおよび／また
はアプレットが実行されている。アプレット１およびアプレット２は、それぞれ
に１つまたは複数のバイトコード・クラス・ファイルを含むことができる。リン
クされたライブラリ（ＬＩＢ）は、ネイティブ・メソッドをサポートするために
アプレット２に関連付けられている。ライブラリ３０２は、関連付けられたネイ
ティブ・メソッドを含むアプレット２のクラスがバーチャル・マシン１０５内に
インスタンス化される時にロードおよびリンクされる。ライブラリ３０２のネイ
ティブ・コードは、ライブラリ・リンキング機能をサポートするオペレーティン
グ・システム１０９およびハードウェア１１０の上で直接に実行される。

【００２８】 実行の複数スレッドは、バーチャル・マシン１０５内で処理される。例えば、
アプレット１は２つのスレッドＴ１およびＴ２を有することができ、アプレット
２は２つのスレッドＴ５およびＴ６を有することができ、バーチャル・マシン自
体は、ごみ収集などのバーチャル・マシンのプロセスを実行する２つのスレッド
Ｔ３およびＴ４を有することができる。スレッドＴ１ないしＴ６は、バーチャル
・マシン１０５内のＶＭスレッド・スケジューラ３０３によって管理およびスケ
ジューリングされる。ＶＭスレッド・スケジューラ３０３は、例えば優先順位お
よびタイム・スライシング方法に基づいて、オペレーティング・システム・レベ
ルで、グループＴ１ないしＴ６のどのスレッドが現在実行中のバーチャル・マシ
ンのスレッド、ＴＶＭであるかを選択する。

【００２９】 Ｊａｖａバーチャル・マシンは、通常、実行中のスレッドが処理中のリソース
を特定の間隔で他のスレッドに譲渡する「協調スケジューリング」をサポートす
るが、さもなければ現行スレッドの実行に関連付けられた遅延が起こる可能性が
ある。例えば、優先順位の高いスレッドは、譲渡操作を利用して現行スレッドに
取って代わることができる。プロセッサ・リソースの譲渡は、標準メソッドにお
いて明示的にプログラムされる必要はない。バーチャル・マシンは、協調してス
ケジューリングするために、解釈のプロセスやコンパイルされたコードの、メソ
ッドが呼び出した時やループの途中（例えば、逆方向ブランチ）のような実行に
適した時点で譲渡を挿入することができる。

【００３０】 オペレーティング・システム１０９は、選択されたバーチャル・マシン・スレ
ッドＴＶＭを含む多くのスレッドに対していつでも同時に働くことができる。例
えば、オペレーティング・システム１０９は、オペレーティング・システムの他
のアプリケーションまたは処理をサポートするスレッドＴＡ−ＴＺを含むことが
出来る。ＯＳスレッド・スケジューラ３０４は、グループＴＡ−ＴＺのどのスレ
ッドおよびＴＶＭが、所与の時間に基礎となるハードウェア１１０によって実行
されるかを決定する。ハードウェア１１０が複数のプロセッサをサポートしてい
るならば、複数のスレッドを異なるプロセッサで同時に実行するようにＯＳスレ
ッド・スケジューラ３０４によってスケジュールすることができる。

【００３１】 図３Ａの実施において、バーチャル・マシン・スレッド（例えば、Ｔ１−Ｔ６
）は、例えば、図に示すように、スレッドＴ６はライブラリ３０２のネイティブ
・コードによってサポートされているアプレット１のネイティブ・メソッドを呼
び出すように、ネイティブ・メソッドのための機能を実行するために実行制御を
リンクされたライブラリ（例えば、ＬＩＢ３０２）に移すことができる。スレッ
ドＴ６は、スレッドＴ６が現行でバーチャル・マシン・スレッドＴＶＭとしてオ
ペレーティング・システム１０９に渡されているので、制御をライブラリ３０２
に移すことができる。バーチャル・マシンの他のスレッドは、協調スケジューリ
ングに従ってスレッドＴ６がイールド(yield)するのを待たなければならない。

【００３２】 ただし、ライブラリ３０２の制御の移動は、バーチャル・マシン実行の問題を
増加させることになる。バーチャル・マシンで実行中のクラスは、通常、他のク
ラスのメソッドのみを呼び出し、一般的にシステムを直接呼び出すことはしない
。ネイティブ・コードは、しかし、その機能依存であり、ブロッキング・システ
ム・コールを頻繁に行うことができる。ネイティブ・コードはリンクされたライ
ブラリでコンパイルされたコードとして独立に実行されるので、バーチャル・マ
シンのインタープリタおよびコンパイラはバイパスされ、制御が標準メソッドに
戻されるまで協調スケジューリングを強行することはできない。バーチャル・マ
シンは、したがって、ネイティブ・コードに明示的なyield()コールを与えるネ
イティブ・コード・プログラマーに依存する。

【００３３】 ネイティブ・コード・ライブラリ３０２が、ファイルをダウンロードするため
のＩ／Ｏコールのようなシステムコールをブロックしたら、バーチャル・マシン
内のスレッドＴ６と、したがってオペレーティング・システム・レベルのスレッ
ドＴＶＭは、システム・コールが完了するまで、例えばダウンロードが終了する
までブロックする。バーチャル・マシン全体の実行は、ライブラリ３０２のネイ
ティブ・コードによって実行制御が維持されているので、システムコールの期間
中もブロックされる。ブロッキング・システムコールが完了するのに比較的長時
間掛かるので、バーチャル・マシン１０９のすべてのスレッドを同様にブロック
されるのは好ましくない。アプレット１およびアプレット２ならびにバーチャル
・マシン１０５のパフォーマンスは、ライブラリ３０２のブロッキング・システ
ムコールによって低下する。このため、多くのバーチャル・マシンの実行におい
て、図３Ｂに示すようにネイティブ・スレッディングが使用される。

【００３４】 図３Ｂでは、ＶＭスレッド・スケジューラ３０３は、バーチャル・マシンの複
数のスレッドをオペレーティング・システム・レベルのスレッドとして実行する
。このスレッドは、スレッドＴＶＭ１ないしＴＶＭｎとしてラベリングされる。
ＶＭスレッド・スケジューラ３０３は、どのバーチャル・マシン・スレッド（Ｔ
１−Ｔ６）がＯＳスレッドＴＶＭ１ないしＴＶｎとして所与の時間にオペレーテ
ィング・システム１０９に渡されるのかを決定する。バーチャル・マシン１０５
の各スレッドが基礎となるオペレーティング・システム１０９の個別スレッドと
して実行されるような極端な場合には、バーチャル・マシン１０５はＶＭスレッ
ド・スケジューラ３０３の実行に先立つことができ、またスレッドのスケジュー
リングについてＯＳスレッド・スケジューラ３０４に完全に依存することができ
る。

【００３５】 図３Ｂを実行すると、複数のスレッドがバーチャル・マシン１０５において同
時にアクティブになることができる。すなわち、ライブラリ３０２のネイティブ
・コードによるブロッキング・システム・コールは、バーチャル・マシン１０５
を完全にブロックすることができないということである。むしろ、グループＴＶ
Ｍ１ないしＴＶＭｎの１つのスレッド、すなわちライブラリ３０２に制御を渡し
たスレッド（すなわち、バーチャル・マシンのスレッドＴ６に対応するオペレー
ティング・システムのスレッド）は、ブロックされるが、残りのスレッドＴＶＭ
１ないしＴＶＭｎは実行することができる。

【００３６】 しかし、バーチャル・マシンの複数のスレッドをＯＳスレッドまたはネイティ
ブ・スレッドとして実行することによって、バーチャル・マシン１０５は、バー
チャル・マシンにおけるスレッドのスケジューリングを、ＶＭスレッド・スケジ
ューラ３０３からスレッド・スケジューラ３０４に効果的に制御を譲渡する。Ｖ
Ｍスレッド・スケジューラ３０３に制御が比較的欠けているので、バーチャル・
マシンのスレッド間で同期エラーが発生することがある。複雑な問題については
、ネイティブ・スレッディングがＯＳスレッド・スケジューラ３０４に依存して
いるため、バーチャル・マシン１０５およびアプレット１およびアプレット２が
、異なるタイミング・パラメータおよびスケジューリング・プロセスを有する異
なるオペレーティング・システム１０９および／または異なるハードウェア１１
０上で実行される場合には、同期エラーは起こる可能性がないか、または別の形
式で起こることがある。したがって、エラーは容易に反復することはできず、シ
ステムのデバッグはより複雑化する。

【００３７】 オブジェクト指向プログラミング 下記で参照のためにオブジェクト指向プログラミングの一般的な説明を行う。
オブジェクト指向プログラミングは、ある種の基本的ビルディング・ブロックを
組み合わせ、そのビルディング・ブロック間に関係を築くことによりコンピュー
タ・プログラムを作る方法である。オブジェクト指向プログラミング・システム
におけるビルディング・ブロックは「オブジェクト」と呼ばれる。１つのオブジ
ェクトは、データ構造（１つまたはそれ以上のインスタンス変数）およびそのデ
ータを使用しまたはそのデータに影響を及ぼすオペレーション（メソッド）をグ
ループ化するプログラミング単位である。したがってオブジェクトは、データお
よびそのデータ上で実行される１つまたはそれ以上のオペレーションまたは手続
きから成る。データとオペレーションを単一のビルディング・ブロックに結合す
ることを「カプセル化」と呼ぶ。

【００３８】 オブジェクトは「メッセージ」を受け取るとそのメソッドのうち１つを実行す
るように命令することができる。メッセージはあるメソッドを実行するためにオ
ブジェクトに送信されるコマンドまたは命令である。メッセージは、メソッド選
択（例えばメソッド名）およびゼロまたはそれ以上の引数からなる。メッセージ
は受信先のオブジェクトに、どのオペレーションを実行するのかを伝える。

【００３９】 オブジェクト指向プログラミングの一利点はメソッドを呼び出すメソッドであ
る。メッセージがオブジェクトに送信される際、メッセージはオブジェクトに対
してあるメソッドをどのように実行するかを命令する必要がない。必要なのはオ
ブジェクトがメソッドを実行するよう要求することだけである。これによりプロ
グラム開発が非常に簡易になる。

【００４０】 オブジェクト指向プログラミングの言語は主に「クラス」体系に基づく。クラ
スに基づくオブジェクト指向プログラミング体系の一例は、一般にアディソン・
ウェスレー出版社から１９８９年に出版されたアデル・ゴールドバーグおよびデ
ビッド・ロブソン著「Ｓｍａｌｌｔａｌｋ−８０：Ｔｈｅ Ｌａｎｇｕａｇｅ」
で説明される。

【００４１】 クラスは通常、クラスについてのフィールド（例えば変数）およびメソッドの
両方を含むオブジェクトのタイプを定義する。オブジェクト・クラスを使用して
オブジェクトの特定のインスタンスを生成することができる。オブジェクト・ク
ラスのインスタンスは、その変数およびクラスについて定義されたメソッドを含
む。同一クラスの複数のインスタンスは、オブジェクトクラスから生成すること
ができる。オブジェクト・クラスから生成された各インスタンスは、同一のタイ
プまたはクラスであるということになる。

【００４２】 例として説明すると、従業員オブジェクト・クラスは「ｎａｍｅ」および「ｓ
ａｌａｒｙ」インスタンス変数と「ｓｅｔ＿ｓａｌａｒｙ」メソッドを含むこと
ができる。従業員オブジェクト・クラスのインスタンスは、組織内の各従業員に
ついて生成すなわちインスタンス化することができる。各オブジェクト・インス
タンスは「ｅｍｐｌｏｙｅｅ」タイプであるということになる。各従業員オブジ
ェクト・インスタンスは、「ｎａｍｅ」および「ｓａｌａｒｙ」インスタンス変
数と「ｓｅｔ＿ｓａｌａｒｙ」メソッドを含む。各従業員オブジェクト・インス
タンス内で「ｎａｍｅ」および「ｓａｌａｒｙ」の変数と関連付けられた値は、
組織内の従業員の氏名および給料を含む。メッセージがある従業員の従業員オブ
ジェクト・インスタンスに送信されると、「ｓｅｔ＿ｓａｌａｒｙ」メソッドを
呼び出して、従業員の給料（すなわち、従業員の従業員オブジェクト内の「給料
」変数と関連付けられた値）を変更させることができる。

【００４３】 クラスの階層は、オブジェクト・クラス定義が１つまたはそれ以上のサブクラ
スを持つように定義することができる。サブクラスはその親（およびそのまた親
などの）定義を継承する。階層中の各サブクラスは、その親のクラスが指定する
振る舞いを追加または変更することがある。オブジェクト指向プログラミング言
語の中には、サブクラスが１つ以上の親クラスからクラス定義を継承する多重継
承を支持するものもある。Ｊａｖａプログラミング言語など他のプログラミング
言語は単一継承だけを支持し、その場合サブクラスは１つだけの親クラスのクラ
ス定義を継承するように制限される。Ｊａｖａプログラミング言語は、定数およ
び抽象メソッド宣言のセットを含む「インターフェース」として知られるメカニ
ズムをも用意している。オブジェクト・クラスは、インターフェース内で定義さ
れた抽象メソッドを実施することができる。単一継承および多重継承はどちらも
インターフェースに使用することができる。すなわちインターフェースは、１つ
以上の親インターフェースからインターフェース定義を継承することができる。

【００４４】 オブジェクトは、オブジェクト指向プログラミング環境において関連するコー
ドおよび変数を含むモジュールを指すのに使用される一般的な用語である。ソフ
トウェア・アプリケーションにはオブジェクト指向プログラミング言語を使用し
て書き込みをすることができ、その場合プログラムの機能性はオブジェクトを使
用して実施される。

【００４５】 発明の概要 バーチャル・マシン環境においてネイティブ・コードを変換および実行するメ
ソッドおよび装置が提供され、ポインタ・チェッキング、スレッド制御、他の有
用な特性が可能になる。バーチャル・マシン実施のデバッグは、ネイティブ・コ
ードのバイナリ変換によって容易になる。バイナリ変換はプラットフォームの独
立性を高め、スレッド管理およびスケジューリングをより制御することができる
ようになり、ネイティブ・コード内のメモリ・アクセス・エラー識別に対する予
防手段をとる。バーチャル・マシン環境でネイティブ・コードが実行されると、
ネイティブ・コードは中間フォームに変換される。この中間フォームは処理され
、どこでメモリ・アクセスおよびブロッキング・システム・コールが発生してい
るのかを判断する。妥当性チェックがメモリ・アクセス・コールに挿入され、各
コールがアクセスすべき各メモリの一部が許容範囲内にあるかを判断する。すな
わちワイルド・ポインタおよびネイティブ・コードに関連するメモリ・アクセス
・エラーの他のソースが識別される。ブロッキング・システム・コールは非ブロ
ッキングの変形と入れ換えられ、「イールド（ｙｉｅｌｄ）」オペレーションが
システム・コールおよびループに挿入される。

【００４６】 メモリ・アクセス妥当性チェックおよび非ブロッキング・システム・コールを
組み込む修正されたネイティブ・コードはバーチャル・マシンによりコンパイル
およびインタープリートされ、ネイティブ・コードが定義するルーチンを実行す
る。修正されたネイティブ・コードは他のスレッドをブロックしないので、スレ
ッドのスケジューリングは基本となるオペレーティング・システムではなくバー
チャル・マシンにより管理され、連携スケジューリングが実行される。

【００４７】 発明の詳細な説明 本発明は、バーチャル・マシン環境でネイティブ・コードを変換し、実行する
メソッドと装置である。以下の説明では、本発明の実施形態をより完全に説明す
るために多くの特定の詳細が述べられる。しかしながら、当業者にはそれらの特
定の詳細なしでも本発明を実施できることは明らかである。他の例では良く知ら
れた要素は本発明を曖昧にしないようにその詳細については述べない。

【００４８】 Ｊａｖａプログラミング・ランゲージ及びＪａｖａバーチャル・マシンに関し
て述べるが、本発明はネイティブ・メソッド又は関数を含むいかなるバーチャル
・マシンでも実施することができる。

【００４９】 コンピュータ実行環境（ハードウエア）の実施形態 本発明実施形態は、図４に示されたコンピュータ４００のような一般目的のコ
ンピュータで実行されるコンピュータ可読コードの形のコンピュータ・ソフトウ
エアとして実装することができ、またはそのようなコンピュータで走るＪａｖａ
実行環境で実行可能なバイトコード・クラス・ファイルの形のコンピュータ・ソ
フトウエアとして実装することができる。キーボード４１０とマウス４１１が双
方向システムバス４１８に接続されている。キーボードとマウスはユーザ入力を
コンピュータ・システムへ送り、そのユーザ入力をプロセッサ４１３へ送るため
のものである。他の適切な入力デバイスがマウス４１１やキーボード４１０に追
加し又はそれらに代えて用いることも可能である。双方向システムバス４１８に
接続されたＩ／Ｏ（入出力）ユニット４１９はプリンタ、Ａ／Ｖ（オーディオ／
ビデオ）Ｉ／ＯなどのＩ／Ｏ要素を代表している。

【００５０】 コンピュータ４００はビデオ・メモリ４１４、メイン・メモリ４１５及び大容
量記憶装置４１０を含む。それらはすべてキーボード４１０，マウス４１１及び
プロセッサ４１３とともに双方向システムバス４１８に接続されている。大容量
記憶装置は、磁気的、光学的又は光磁気的記憶システムまたはその他のいかなる
利用可能な大容量技術のような固定及び着脱自在なメディア双方を含む。バス４
１８は、例えば、ビデオメモリ４１４やメインメモリ４１５をアドレスするアド
レス・ラインを含む。同様に、システムバス４１８は、例えば、プロセッサ４１
３、メインメモリ４１５，ビデオメモリ４１４及び大容量記憶装置４１２のよう
な部材の間でデータを転送するデータバスをも含む。データとアドレス用の個々
のラインの代わりに多重化データ／アドレス・ラインを用いても良い。

【００５１】 本発明の１実施形態では、プロセッサ４１３は、６８０Ｘ０プロセッサのよう
なモトローラによって製造されたマイクロプロセッサ、８０Ｘ８６又はペンティ
アム（登録商標）・プロセッサのようなインテルによって製造されたマイクロプ ロセッサ、又はサン・マイクロシステムズ・インコーポレーテッドからのＳＰＡ ＲＣマイクロプロセッサである。しかしながら、他の適切なマイクロプロセッサ 又はマイクロ・コンピューを使用可能である。メインメモリ４１５は、ランダム ・アクセス・メモリ（ＤＲＡＭ）を含む。ビデオ・メモリ４１４は、二重ポート ・ビデオ・ランダム・アクセス・メモリである。ビデオ・メモリ４１４の一つの ポートはビデオ増幅器４１６に接続されている。ビデオ増幅器４１６は陰極線管 （ＣＲＴ）ラスタ・モニタ４１７を駆動するために使用される。ビデオ増幅器４ １６は従来良く知られており、任意の適切な装置によって実現できる。この回路 はビデオ・メモリ４１４に記憶されたピクセル・データをモニタ４１７によって 使用するのに適したにラスタ信号に変換する。代わりに、ビデオ・メモリはフラ ット・パネル又は液晶ディスプレイ（ＬＣＤ）又はその他のデータを適切に表示 するデバイスを駆動するために用いられる。

【００５２】 コンピュータ４００はバス４１８へ接続された通信インターフェース４２０を
含む。通信インターフェース４２０は、ネットワーク４２１を介してローカル・
ネットワーク４２２へ接続し、２方向データ通信を行っている。例えば、通信イ
ンターフェース４２０が統合サービス・デジタル・ネットワーク（ＩＳＤＮ）カ
ード又はモデムである場合、通信インターフェース４２０は、ネットワーク・リ
ンク４２１の一部となっている、電話線の対応するタイプのデータ通信接続を構
成している。もし、通信インターフェース４２０がローカル・エリア・ネットワ
ーク（ＬＡＮ）カードである場合、通信インターフェース４２０はネットワーク
・リンク４２１を介して適合するＬＡＮとデータ通信接続を行う。通信インター
フェースは、ケーブル・モデム又はワイヤレス・インターフェースでも良い。ど
のような実施形態においても、通信インターフェース４２０は、情報の多くのタ
イプを現しているデジタル・データ・ストリームを運ぶ電子的、電磁的又は光学
的信号を送りかつ受け取る。

【００５３】 ネットワーク・リンク４２１は一つ又はより多くのネットワークを通して他の
データ・デバイスにデータを通信する。例えば、ネットワーク・リンク４２１は
、ローカル・ネットワーク４２２を通して、ローカル・サーバ・コンピュータ４
２３へ又はインターネット・サービス・プロバイダ（ＩＳＰ）４２４によって動
作させられるデータ装置へ接続されている。ＩＳＰ４２４は、今一般に「インタ
ーネット」４２５といわれているワールド・ワイド・パケット・データ通信サー
ビスを通してデータ通信サービスを実施する。ローカル・ネットワーク４２２と
インターネット４２５の双方はデジタル・データ・ストリームを運ぶ電子的、電
磁的又は光学的信号を利用する。コンピュータへ及びコンピュータからデジタル
・データを運ぶ、多くのネットワークを通る信号やネットワーク・リンク４２１
上にあり通信インターフェースを通る信号は、典型的には情報を運ぶ搬送波の形
である。

【００５４】 コンピュータ４００は、ネットワーク、ネットワーク・リンク４２１及び通信イ
ンターフェース４２０を通してプログラム・コードを含むメッセージを送り、か
つデータを受け取る。例えば、インターネットでは、リモート・サーバ・コンピ
ュータ４２６が、インターネット４２５、ＩＳＰ４２４、ローカルネットワーク
４２２及び通信インタフェース４２０を通してアプリケーション・プログラムに
対して要求されたコードを送る。

【００５５】 受け取られたコードはプロセッサ４１３によって受け取ったときに実行されて
もよいが、後に実行するために大容量記憶装置４１２または他の不揮発性記憶装
置に記憶しても良い。また、実行して記憶しても良い。このようにして、コンピ
ュータ４００はアプリケーション・コードを搬送波の形で獲得する。本発明の実
施形態においては、そのようなダウンロードされたアプリケーションの例には、
バーチャル・マシン、クラス・ローダ、クラス・バイトコード・ファイル、クラ
ス・ライブラリおよびここに述べられるネイティブ・コードを変換し、実行する
装置のような、実行環境の一つ以上の要素を含んでいる。

【００５６】 アプリケーション・コードはコンピュータ・プログラム製品のいかなる形態に
も組み込むことができる。コンピュータ・プログラム製品は、コンピュータ可読
コード又はデータを記憶し、転送するように構成された、あるいはコンピュータ
可読コード又はデータメディアが組み込まれたメディアを含む。コンピュータ・
プログラム製品の例としては、ＣＤ−ＲＯＭディスク、ＲＯＭカード、フロッピ
ー（登録商標）・ディスク、磁気テープ、コンピュータ・ハードディスク、ネッ トワーク上のサーバ及び搬送波などである。

【００５７】 上述したコンピュータ・システムは例示の目的だけである。本発明の実施形態
は、バーチャル・マシンをサポートする、組み込まれたデバイス（例えばウエブ
・ホーンなど）や「ｔｈｉｎ」クライアント処理環境（例えばネットワーク・コ
ンピュータ（ＮＣ）その他）を含むコンピュータ・システム又はプログラミング
環境、処理環境のいずれのタイプでも実施できる。

【００５８】 ネイティブ・コードのバイナリ変換 先に述べたように、バーチャル・マシン内で実行されるクラスはリンクされた
ライブラリ内のネイティブ・コード関数によって実施されるネイティブ・メソッ
ドを含む。本発明の実施形態によれば、リンクされたライブラリのネイティブ・
コードはバーチャル・マシンのコンポーネントによって処理され、実行され、従
来技術のネイティブ・メソッド実行プロセスに対して共通スケジューリングが可
能で、強化したデバッキング能力を与える。ネイティブ・コードの処理は、バイ
ナリ変換手順の一部として、「ワイルド」ポインタによって引き起こされるよう
なメモリ・アクセス・バグに関するチェックを挿入すること、及びネイティブ・
スレッディングの必要なしに、ブロッキング・システム・コールをバーチャル・
マシンにおける共通スケジューリングを可能とする非ブロッキング・バリアント
で置き換えることを含む。

【００５９】 バイナリ変換は典型的にはデバッキングオペレーションの間にバーチャル・マ
シンで可能で、通常の動作の間は不可能である。例えば、可能なとき、「System
.loadLibrary()」コールが、バーチャル・マシン内でインタプリートされた又は
コンパイルされた実行に関する指定されたライブラリのバイナリ変換となる。不
可能なとき、指定されたライブラリは標準のメソッドでロードされ、かつリンク
されれる。いくつかの実施形態では、デバッキング処理の間のみに実行できるの
ではなく、バイナリ変換がいつでも実行できる。

【００６０】 図５は本発明実施形態によるバイナリ変換を実施するためのメソッドのフロー
図である。ステップ５００で、リンクされたライブラリからそれぞれのネイティ
ブ・コードを獲得する。このステップは、例えば、それぞれのクラスがバーチャ
ル・マシン内でインスタンス化されるときリンクされたライブラリのソース・フ
ァイルを決定し、かつそのフォース・ファイルからネイティブ・コード（すなわ
ちマシン・コード）のバイナリ・フォームを読みとることを含む。バイナリ変換
はバーチャル・マシンにおける実行に先立って実施される。

【００６１】 ステップ５０１では、ネイティブ・コードのバイナリ・フォームがバーチャル
・マシンのバイナリ変換コンポーネントによって、バイトコード、アブストラク
ト・シンタックス・ツリー又は制御フロー・グラフのような中間フォームに変換
される。バイトコードは、例えば、Ｊａｖａコンパイラ（図１の要素１０１）に
よって生成された標準バイトコードと同じように実施される。アブストラクト・
シンタックス・ツリーや制御フロー・グラフは、ツリーやグラフのノードとして
の実行オペレーションを特定するプログラム実行を現している。典型的には、中
間フォーム（ここでは変換されたフォームともいう）はメモリ・アクセス・ポイ
ント及び／又はコール及びブランチ・オペレーションの識別を単純化するフォー
ムである。

【００６２】 ステップ５０２では、メモリ・アクセス・コールの位置が決定され、かつ制限
されたまたは制限区域外のメモリの部分にアクセスしようとしているならば、メ
モリ・アクセス・コールが実行している間に信号にチェックが挿入される。信号
は、例えばエラー・メッセージを表示する（例えば、ダイアログボックスに）、
ログファイルにエラーをログする、例外をスローすることを含み、またはそれら
のアクションのいくつかの組み合わせを含む。実行中に、ワイルド・ポインタと
ネイティブ・コードに関連する他のメモリ・アクセス・バグのデバッキングが、
不法な各メモリ・アクセス・イベントが起こったときにそれを報告することによ
って決定される。メモリ・アクセス・チェックの一部として、ネイティブ・コー
ドの要素によって正規にアクセスできるメモリの部分がポインタ値と比較するた
めに追跡される。

【００６３】 ステップ５０３で、ブロッキング・システム・コールが中間フォームで識別さ
れ、可能ならば、システム・コールの非ブロッキング・バリアントが挿入される
。ステップ５０４で、「yield()」関数がコールとループに挿入される。ループ
に対するイールド・ポイント（yield()関数が挿入されるポイント）が、例えば
、バックワード・ブランチ・オペレーションに基づいて決定される。ステップ５
０３と５０４の効果は、可能な限り、バーチャル・マシン及びいかなる実行して
いるアプリケーション及び／又はアプレットの実行をネイティブ・コードのアク
ティビティに関する依存から自由にする。バーチャル・マシンの他のスレッドは
ネイティブ・コードのシステム・コールによってブロックされず、かつコールで
かつループ内で他の待機中のスレッドに処理リソースをイールドするためにイー
ルド・ポイントが確立される。バーチャル・マシンがすべての関連するスレッド
の共通スケジューリングを実行できる。この共通スケジューリングによって、同
期又は同時に関連しているバグを信頼性を持って識別し、かつ基礎となるオペレ
ーティング・システムやハードウエアと独立に修正する。

【００６４】 ステップ５０５で、中間のすなわち変換されたフォームにおけるリバイズされ
たネイティブ・コードがバーチャル・マシンでコンパイルされ、インタプリート
され、関数をそこで実行する。いくつかの実施形態では、さらなる変換ステップ
が実施され、中間フォームを標準インタープリタ及びＪＩＴコンパイラでインタ
プリートしたりコンパイルするのに適切なバイトコードに変換する。ネイティブ
・コード関数の実行に関連するスレッドのスケジューリングがバーチャル・マシ
ンの他のあらゆるインタプリートされた又はコンパイルされたプロセスのように
、ＭＶスレッド・スケジューリング・プロセスによって制御される。メモリ・ア
クセス・チェックが実施されると、違反がログされる。必要な分離された非同期
スレッドが生成され、バーチャル・マシンにおいて他のスレッドと独立に他の処
理が起こることができるようになる。

【００６５】 場合により、ネイティブ・コードはステップ５０１において完全にはパース（
構文解析）を行えない。ルーチンの始め又は見込まれたブランチ(computed bran
ch) のようなコードのある部分（ないし側面）は、変換されたコードがステップ
５０５において実行される（例えば、ルーチンが現実にコールされた時）までは
知り得ないことがある。このために、変換プロセスは、ステップ５０５からステ
ップ５０１へと、フィードバックの矢印５０６で示されるように戻ることができ
る。このフィードバックは、それまではパース（構文解析）をされていないネイ
ティブ・コードをパース（構文解析）および変換（又は、既にパースをされたネ
イティブ・コードの再パース）を、実行過程で決定された新たな情報に基づいて
行う目的のものである。

【００６６】 バイナリ変換を受けるネイティブ・メソッドの一般的な中間フォームが図６Ａ
および図６Ｂに示されている。図６Ａは、一例としての実行ブロックの一般化し
たコントロール・フローを示す図であって、本発明の実施形態に従ってネイティ
ブ・コードのブロックを中間フォームへと変換することが例示されている。図６
Ｂは、図６Ａの一般化したコントロール・フローに本発明の実施形態に従って変
形を付加したものを示す。この実施形態では、ループ内でのイールド点の表示は
バックワード・ブランチ・オペレーションの発生に基づいている。

【００６７】 例示したオペレーション（動作）の表示のために、図６Ａおよび図６Ｂでは、
次の略号が用いられている。 ＲＤ ＝メモリ・リード・オペレーション ＷＲ ＝メモリ・ライト・オペレーション ＢＲ ＝ブランチ・オペレーション（例：if） ＭＣ ＝メソッド（関数）コール ＢＳＣ＝ブロッキング・システム・コール ＯＰ ＝他の一般的・オペレーション（その他） ＣＨＫ＝ポインタ・チェック・オペレーション ＹＬＤ＝イールド・オペレーション ＮＢＳＣ＝非ブロッキング・システム・コール ＦＬＡＧ＝信号処理アクセス違反

【００６８】 図６Ａにおいて、実行ブロックは、一般的オペレーション６００から始まり、
続いてリード・オペレーション６０３が行われ、さらに、一般的オペレーション
６０５，６０６，６０７が順に続く。一般的オペレーション６０７の後で、ライ
ト・オペレーション６１０が遂行され、続けて、一般的オペレーション６１２，
６１３、そして、ブランチ・オペレーション６１４が行われる。このブランチ・
オペレーションでは、一般的オペレーション６１６へと進むか、一般的オペレー
ション６０６へと分岐して戻るかされる。一般的オペレーション６１６から、メ
ソッド・コール６１８が行われ、それに、一般的オペレーション６１９，ブロッ
キング・システム・コール６２１Ａ，一般的オペレーション６２２が続く。

【００６９】 バイナリ変換にとって興味あるオペレーションは、リード・オペレーション６
０３，ライト・オペレーション６１０，ブランチ・オペレーション６１４，メソ
ッド・コール６１８，ブロッキング・システム・コール６２１Ａであり、それら
は図中で強調されている。メモリ・アクセスに関するリード・オペレーション６
０３およびライト・オペレーション６１０は、ポインタ・チェックの挿入のため
のセットである。ブランチ・オペレーション６１４およびメソッド・コール６１
８は、yield() コールの挿入のためのセットである。ブロッキング・システム・
コール６２１Ａは、非ブロッキング・システム・コール・バリアントで置換する
ためのセットである。

【００７０】 図６Ｂには、図６Ａの実行ブロックの中間フォームに対する変形が示されてい
る。リード・オペレーション６０３は、ポインタ・チェック・オペレーション６
０１，ブランチ・オペレーション６０２，リード・オペレーション６０３および
フラッグ・オペレーション６０４で置換されている。チェック・オペレーション
６０１は、ポインタ値がリーガル（適法な）レンジ内か否かを決定し、それにブ
ランチ・オペレーション６０２が続く。ブランチ・オペレーション６０２は、ポ
インタが有効であればリード・オペレーション６０３を行い、さもなければ、ポ
インタ・チェックで無効なポインタが示されていることを知らせるフラグ・オペ
レーション６０４を遂行する。オペレーション６０３，６０４は何れもオペレー
ション６０５へ進む。

【００７１】 ライト・オペレーション６１０は、リード・オペレーション６０３のために行
われた上述した挿入に類似のチェックおよびフラッグの挿入を受ける。ライト・
オペレーション６１０は、ポインタ・チェック・オペレーション６０８，ブラン
チ・オペレーション６０９，ライト・オペレーション６１０およびフラッグ・オ
ペレーション６１１で置換される。ポインタ・チェック・オペレーション６０８
は、ポインタ値がリーガル・レンジ内にあるか否かを決定するものであり、それ
にブランチ・オペレーション６０９が続く。ブランチ・オペレーション６０９は
、ポインタが有効であればライト・オペレーション６１０を実行し、さもなけれ
ば、ポインタ・チェックにより無効ポインタと示されたことを知らせるフラグ・
オペレーションを遂行する。オペレーション６１０，６１１は何れもオペレーシ
ョン６１２へ進む。

【００７２】 バックワード・ブランチ・オペレーション６１４には、オペレーション６０６
へのリターン・ループ内に挿入されたイールド・オペレーション６１５が伴って
いる。挿入されたイールド・オペレーション６１５によって、他のスレッドには
、ブランチ・オペレーション６１４により形成されるループが今一度開始される
前にプロセッサ・リソースを得る機会が許される。これにより、長いループの再
帰プロセスのために、他のスレッドからプロセッサ・リソースが奪われることが
防止される。同様に、イールド・オペレーション６１７がメソッド・コール６１
８の前に挿入され、他のスレッドは、もし必要であれば、カレント・スレッドに
よる新たなメソッドの開始前に実行を許される。

【００７３】 ブロッキング・システム・コール６２１Ａは、図６Ｂにおいて、非ブロッキン
グ・システム・コール６２１Ｂで置換されている。イールド・オペレーション（
６２０）を、任意的に、システム・コールの前に挿入してもよい。必要であれば
、非ブロッキング・システム・コール６２１Ｂは、新たな非同期スレッドを生成
して変換された関数の動作を独立的に実行されるスレッドとして遂行し得る。

【００７４】 バーチャル・マシンによりインタープリートまたはコンパイルをされると、リ
バイズされた実行ブロック（図６Ｂ）は、従来技術でのネイティブ・メソッドの
実行に比べて、意味のあるデバッギングおよびスケジューリングの利点を提供す
る。

【００７５】 図７は、本発明の実施形態に従ってバイナリ変換を実現する実行環境を示すブ
ロック図を示す。図７において、オペレーティング・システム１０９はハードウ
エア１１０でランし、バーチャル・マシン１０５はオペレーティング・システム
１０９上でランする。オペレーティング・システム１０９はハードウエア１１０
によってサポートされる。図３Ａおよび図３Ｂに示されるように、バーチャル・
マシン１０５およびオペレーティング・システム１０９は、スレッド実行の管理
のために、ＶＭスレッド・スケジューラ３０３およびＯＳスレッド・スケジュー
ラ３０４をそれぞれ有する。また、バーチャル・マシン１０５は、バイナリ変換
・プロセス７０１を有する。

【００７６】 バーチャル・マシン１０５内で実行されるのは、アプレット１（３００）およ
びアプレット２（３０１）のような複数のアプリケーション及び／又はアプレッ
トである。アプレット１およびアプレット２それぞれは、１以上のバイトコード
のクラス・ファイルを含むことができる。リンクされたライブラリ（ＬＩＢ）３
０２は、アプレット２に付随させられてネイティブ・メソッドをサポートする。
ライブラリ・ファイル３０２のネイティブ・コードは、バーチャル・マシン１０
５のバイナリ変換・プロセス７０１によってパース（構文解析）および変換（ト
ランスレーション）されて、変換されたライブラリ７００が発生される。

【００７７】 変換されたライブラリ７００は、ネイティブ・コードの中間フォーム（メモリ
・アクセス・チェック，イールド，非ブロッキング・システム・コール・バリア
ントを含んでいる）から成っている。アプレット２のネイティブ・メソッドがス
レッドＴ６によってコールされると、変換されたライブラリ７００はバーチャル
・マシン１０５内でインタープリートまたはコンパイルをされて所望の関数が実
行される。変換されたライブラリ７００の中間フォームに依存して、変換された
ライブラリを得るためのインタープリートまたはコンパイルのプロセスは、アプ
レット１およびアプレット２のクラスに適用されるインタープリートまたはコン
パイルのプロセスと異なることも、異ならないこともある。しかし、バーチャル
・マシン１０５によって、変換されたライブラリ７００に対して行われる一般的
オペレーションや実行される管理は、アプレット１およびアプレット２のための
ものと一致している。実施形態によっては、変換されたライブラリ７００は、ス
レッドＴ６において、ネイティブ・メソッド・スタック２１６を介するのではな
く、スタック２１２のフレームを介して、処理され得る。変換されたライブラリ
７００は、あたかも、不変更のネイティブ・コード中の欠点を持たない追加のス
タンダード・メソッドを提供しているかのように、実行できる。

【００７８】 リンクされたライブラリの変換されたネイティブ・コード関数は、オペレーテ
ィング・システム１０９で遂行される、リンクされたライブラリの独立したプロ
セスではなくして、バーチャル・マシン１０５を通して実行される故に、そして
、変換されたライブラリ７００内にブロッキング・コールが存在しない故に、Ｖ
Ｍスレッド・スケジューラ３０３によって、共通スケジューリングを実行できる
。従って、図３Ｂで実現されるようなネイティブ・スレッディングは不要となる
。バーチャル・マシン１０５内でのスレッド・イベントの同期は、基礎にあるオ
ペレーティング・システムおよびハードウエアから独立しており、デバッギング
はオペレーティング・システムをベースとする同時発生事項の考慮なしに遂行可
能となる。

【００７９】 以上にバーチャル・マシン環境においてネイティブ・コードの変換と実行を行
うメソッドおよび装置を、１またはそれ以上の実施の形態とともに、記載した。
本発明は、請求の範囲およびそれに均等な範囲によって定められるものである。

【図面の簡単な説明】

【図１】 コンパイルおよびランタイム環境のブロック図である。

【図２】 バーチャル・マシンの実施形態のランタイム・データ・アクセスのブロック図
である。

【図３Ａ】 リンクされたライブラリを介して実装された多重アプレットおよびネイティブ
・コードをサポートするバーチャル・マシンを有するランタイム環境のブロック
図である。

【図３Ｂ】 ネイティブ・メソッド操作を使用するバーチャル・マシンを有するランタイム
環境のブロック図である。

【図４】 本発明の実施形態のために適切な実行環境を提供することができるコンピュー
タ・システムの実施形態のブロック図である。

【図５】 本発明の実施形態に従ったバイナリ変換プロセスの流れ図である。

【図６Ａ】 本発明の実施形態に従ったネイティブ・コードのブロックの中間フォームへの
バイナリ変換を図示する例示的実行ブロックの汎用的な制御フロー図である。

【図６Ｂ】 本発明の実施形態に従って実行される変更を加えた図６Ａの汎用的な制御フロ
ー図である。

【図７】 本発明の実施形態に従ってネイティブ・コードのバイナリ変換を実施するバー
チャル・マシンを有するコンピュータ・システムのブロック図である。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＵＧ，ＺＷ)，Ｅ Ａ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＲ， ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ，ＥＥ，ＥＳ，ＦＩ，Ｇ Ｂ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ， ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，Ｍ Ｇ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ， ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，Ｙ Ｕ，ＺＡ，ＺＷ (71)出願人 2550 Ｇａｒｃｉａ Ａｖｅｎｕｅ，ＭＳ ＰＡＬ１−521，Ｍｏｕｎｔａｉｎ Ｖ ｉｅｗ，Ｃａｌｉｆｏｒｎｉａ 94043− 1100，Ｕｎｉｔｅｄ Ｓｔａｔｅｓ ｏｆ Ａｍｅｒｉｃａ Ｆターム(参考） 5B081 DD00 5B098 HH00 【要約の続き】 ムコールがバーチャルマシンによってコンパイルされ、 インタプリートされ、ネイティブコードで定義されたル ーチンが実行される。リバイズされたネイティブコード は他のスレッドをブロックしないので、スレッドスケジ ューリングが基礎となるオペレーティングシステムでは なくバーチャルマシンによって管理され、かつ協調的な スケジューリングが実施される。

Claims (24)

【特許請求の範囲】
1. 【請求項１】 コンピュータにおいて、 ライブラリのネイティブ・コードを取得するステップと、 このネイティブ・コードを変換されたフォームに変換するステップと、 前記ネイティブ・コードの前記変換されたフォームを実行するステップと を有する方法。
2. 【請求項２】 前記ネイティブ・コードの前記変換されたフォームを実行す
   るステップは、バーチャル・マシンにおいて実施される請求項１記載の方法。
3. 【請求項３】 前記変換されたフォーム内のブロッキング・システム・コー
   ルを識別するステップと、 前記ブロッキング・システム・コールを非ブロッキング・システム・コールで
   置き換えるステップとをさらに有する請求項１記載の方法。
4. 【請求項４】 前記変換されたフォーム内のメモリ・アクセス・オペレーシ
   ョンを識別するステップと、 このメモリ・アクセス・オペレーションにメモリ・アクセス違反のチェックを
   追加するステップとをさらに有する請求項１記載の方法。
5. 【請求項５】 前記変換されたフォーム内のイールド・ポイントを識別する
   ステップと、 このイールド・ポイントにイールドを挿入するステップとをさらに有する請求
   項１記載の方法。
6. 【請求項６】 前記変換されたフォーム内のイールド・ポイントを識別する
   ステップは、メソッド・コールを識別する請求項５記載の方法。
7. 【請求項７】 前記変換されたフォーム内のイールド・ポイントを識別する
   ステップは、ループを識別する請求項５記載の方法。
8. 【請求項８】 前記ループを識別するステップは、バックワード・ブランチ
   を識別することからなる請求項７記載の方法。
9. 【請求項９】 コンピュータ読み取り可能なコードが記録されたコンピュー
   タで使用可能な媒体からなるコンピュータ・プログラム製品であって、 前記コンピュータ・プログラム製品は、 コンピュータにライブラリのネイティブ・コードを取得させるように構成され
   たコンピュータ読み取り可能なコードと、 コンピュータに前記ネイティブ・コードを変換されたフォームに変換させるよ
   うに構成されたコンピュータ読み取り可能なコードと、 コンピュータに前記ネイティブ・コードの前記変換されたフォームを実行させ
   るように構成されたコンピュータ読み取り可能なコードと を有するコンピュータ・プログラム製品。
10. 【請求項１０】 前記コンピュータ・プログラム製品は搬送波である請求項
    ９記載のコンピュータ・プログラム製品。
11. 【請求項１１】 コンピュータに前記ネイティブ・コードの前記変換された
    フォームを実行させるように構成された前記コンピュータ読み取り可能なコード
    は、 バーチャル・マシンに前記変換されたフォームを実行させるように構成されて
    いる請求項９記載のコンピュータ・プログラム製品。
12. 【請求項１２】 コンピュータに前記変換されたフォーム内のブロッキング
    ・システム・コールを識別させるように構成されたコンピュータ読み取り可能な
    コードと、 コンピュータに前記ブロッキング・システム・コールを非ブロッキング・シス
    テム・コールで置き換えさせるように構成されたコンピュータ読み取り可能なコ
    ードと をさらに備える請求項９記載のコンピュータ・プログラム製品。
13. 【請求項１３】 コンピュータに前記変換されたフォーム内のメモリ・アク
    セス・オペレーションを識別させるように構成されたコンピュータ読み取り可能
    なコードと、 コンピュータに前記メモリ・アクセス・オペレーションにメモリ・アクセス違
    反のチェックを追加させるように構成されたコンピュータ読み取り可能なコード
    と をさらに備える請求項９記載のコンピュータ・プログラム製品。
14. 【請求項１４】 コンピュータに前記変換されたフォーム内のイールド・ポ
    イントを識別させるように構成されたコンピュータ読み取り可能なコードと コンピュータに前記イールド・ポイントにイールドを挿入させるように構成さ
    れたコンピュータ読み取り可能なコードと をさらに備える請求項９記載のコンピュータ・プログラム製品。
15. 【請求項１５】 コンピュータに前記変換されたフォーム内のイールド・ポ
    イントを識別させるように構成された前記コンピュータ読み取り可能なコードは
    、 コンピュータにメソッド・コールを識別させるように構成されたコンピュータ
    読み取り可能なコードからなる請求項１４記載のコンピュータ・プログラム製品
    。
16. 【請求項１６】 コンピュータに前記変換されたフォーム内のイールド・ポ
    イントを識別させるように構成された前記コンピュータ読み取り可能なコードは
    、 コンピュータにループを識別させるように構成されたコンピュータ読み取り可
    能なコードからなる請求項１４記載のコンピュータ・プログラム製品。
17. 【請求項１７】 コンピュータにループを識別させるように構成された前記
    コンピュータ読み取り可能なコードは、 コンピュータにバックワード・ブランチを識別させるように構成されたコンピ
    ュータ読み取り可能なコードからなる請求項１６記載のコンピュータ・プログラ
    ム製品。
18. 【請求項１８】 ネイティブ・メソッドからなるクラスと、 このクラスを処理するバーチャル・マシンとからなる装置であって、 前記ネイティブ・メソッドは、ライブラリのネイティブ・コードによってサポ
    ートされており、 前記バーチャル・マシンは、 前記ネイティブ・コードを変換されたフォームで実行するように構成されてお
    り、 共同スケジューリングをインプリメントするスレッド・スケジューラと、 前記ネイティブ・コードを前記変換されたフォームに変換するように構成され
    た変換プロセスと を備える装置。
19. 【請求項１９】 前記変換プロセスは、さらに、 前記変換されたフォーム内のブロッキング・システム・コールを非ブロッキン
    グ・システム・コールで置き換えるように構成されている請求項１８記載の装置
    。
20. 【請求項２０】 前記変換プロセスは、さらに、 前記変換されたフォーム内のメモリ・アクセス・オペレーションにメモリ・ア
    クセス・チェックを挿入するように構成されている請求項１８記載の装置。
21. 【請求項２１】 前記変換プロセスは、さらに、 前記変換されたフォーム内のイールド・ポイントにイールド・オペレーション
    を挿入するように構成されている請求項１８記載の装置。
22. 【請求項２２】 前記イールド・ポイントは、コールと関連付けられる請求
    項２１記載の装置。
23. 【請求項２３】 前記イールド・ポイントは、ループと関連付けられる請求
    項２１記載の装置。
24. 【請求項２４】 前記イールド・ポイントは、前記ループのバックワード・
    ブランチと関連付けられる請求項２３記載の装置。