JP2000347871A - スタブ／アダプタ自動生成器 - Google Patents

Abstract

(57)【要約】 【課題】 ランタイム環境においてアダプタもしくはス
タブを自動的に与えるシステムおよび方法が開示され
る。 【解決手段】 アダプタ生成器には入力パラメータが与
えられ、次に入力パラメータは処理されてコンパイラ60
2に入力される。次に、コンパイラ602は、生成されたア
ダプタを保存するために使用されるアダプタ・ライブラ
リ614に連結される。次に、アダプタ・ライブラリ614
は、一つのもしくは一連のバイトコード604を実行する
ときに、ランタイム・システムに対して要求に応じてア
ダプタを与える。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、コンピュータ・シ
ステムに関するものである。より詳細には、マルチ・プ
ラットフォーム環境においてスタブを自動的に生成する
方法および装置が開示される。

【０００２】

【従来の技術】Java(登録商標)プログラミング言語は、
Sun Microsystems社により開発されるとともに小型のパ
ーソナルコンピュータからスーパーコンピュータまで多
岐に亙り実施されるほど移植性の高い設計の、オブジェ
クト指向でハイレベルなプログラミング言語である。Ja
va(および他の言語)で記述されたコンピュータ・プログ
ラムは仮想マシン用命令にコンパイルされてJava仮想マ
シンにより実行され得る。一般的には、Java仮想マシン
は仮想マシン用命令を解読して実行するインタプリタで
ある。

【０００３】Java仮想マシンに対する仮想マシン用命令
はバイトコードであり、それらは一つ以上のバイを含む
ことを意味する。しかしながら、バイトコードは一つの
クラスの様々な方法に対するバイトコードを含む「クラ
ス・ファイル」と称される特定ファイル・フォーマット
で保存される。一つのクラスの様々な方法に対するバイ
トコードに加え、クラス・ファイルはシンボル・テーブ
ルならびに他の補助的な情報を含んでいる。

【０００４】一つ以上のクラス・ファイルにおいてJava
バイトコードとして実現されたコンピュータ・プログラ
ムは、プラットフォーム独立型である。そのコンピュー
タ・プログラムは、Java仮想マシンの実行を作動させ得
る任意のコンピュータ上では、修正されることなく実行
され得る。Java仮想マシンは、「汎用」コンピュータの
ソフトウェア・エミュレータであり、このことが、Java
仮想マシンに対するコンピュータ・プログラムをプラッ
トフォーム独立型にしている主な要因である。

【０００５】Java仮想マシンは一般的に、ソフトウェア
・インタプリタとして実行される。従来のインタプリタ
は、実行の間に一回に一命令ずつ、解釈済プログラムの
仮想マシン用命令を解読して実行する。一方、実行に先
立ちコンパイラはソース・コードを固有マシン命令へと
解読することから、実行の間に解読は実施されない。従
来のインタプリタは命令に遭遇する毎に命令が実行され
る前に反復的に命令を解読することから、解釈されたプ
ログラムの実行はコンパイル済プログラムによりも相当
に低速なのが典型的である、と言うのも、コンパイル済
プログラムの固有マシン命令は解読無しで固有マシンも
しくはコンピュータ・システム上で実行され得るからで
ある。従って、パフォーマンスが重要な要因であるとき
は常に、インタプリタの代わりにコンパイラを使用して
ソース・コードを解読することが望ましい。しかしなが
ら、これを実現するためには、アダプタと称されるもの
が、プラットフォーム依存型インタプリタにより使用さ
れる実行スタックを、プラットフォーム依存型コンパイ
ラが期待する形態と一致した形態へと翻訳する。残念な
がら、プラットフォーム依存型コンパイラにより生成さ
れるコードはインタプリタと異なる様式で情報を保存か
つ通信することから、プラットフォーム特有アダプタは
仮想マシンが動作するプラットフォーム毎に構築されね
ばならない。この結果としてユーザは典型的に、たとえ
ばアセンブラ言語もしくはC++コードを使用してプラッ
トフォームに対してアダプタを生成することが必要とな
る。仮想マシンが動作するプラットフォーム毎にアダプ
タをコーディングすると、時間がかかるとともにエラー
が起こり易い。

【０００６】典型的には、Java仮想マシンはJavaプログ
ラミング言語以外のプログラミング言語(たとえば、C++
プログラミング言語)により記述される。従って、Java
プログラムを実行するには、複数のプログラミング言語
で記述された関数の実行を含むこともある。その上、バ
イトコード自体が、Javaプログラミング言語で記述され
たものでない固有関数(たとえば、入出力に対するシス
テム特有関数)を呼び出すこともある。従って、実行さ
れているJavaプログラムが複数のプログラミング言語で
記述された関数の実行を伴うのが一般的である。ところ
でRPC(リモート・プロシージャ・コール)は、ネットワ
ークにおける他のコンピュータに配置されたプログラム
からのサービスを要求するために、一つのプログラムが
ネットワークの詳細を知ることを要さずに使用し得るプ
ロトコルである。しかしながら、プロシージャ呼出し
は、関数呼出しもしくはサブルーチン呼出しと呼ばれる
こともある。クライアント／サーバ・モデルを例に取る
と、要求を行うプログラムはクライアントであり、サー
ビスを与えるプログラムはサーバである。通常のもしく
は局所的なプロシージャ呼出しにおけるのと同様に、RP
Cは、リモート・プロシージャの結果が戻されるまで中
断されるべきプログラム要求を要する同期オペレーショ
ンである。但し、同一のアドレススペースを共有する軽
量のプロセスもしくはスレッドを使用すると、複数のRP
Cが同時に実施され得る。

【０００７】RPCを使用したプログラム・ステートメン
トが実行可能プログラムへとコンパイルされたとき、コ
ンパイル済コードにはリモート・プロシージャ・コード
として機能するスタブがコンパイル済コード内に含まれ
る。スタブとは、長いプログラムに置き換わるととも
に、おそらく後でロードされるか遠隔的に配置される短
いプログラム・ルーチンである。たとえば、複数のリモ
ート・プロシージャ・コール(RPC)を使用するプログラ
ムは、要求された手順を与えるプログラムに置き換わる
複数のスタブを以てコンパイルされる。そのスタブは要
求を受信するとそれを(別のプログラムを介して)リモー
ト・プロシージャへと送る。そのプロシージャはサービ
スを完了したときに、結果もしくは他のステータスをス
タブへと戻し、スタブはそれを、要求を行ったプログラ
ムへと渡す。

【０００８】アダプタと同様に、従来の仮想マシンにお
いては、仮想マシンが動作する全てのプラットフォーム
に対して手動でコーディングされたスタブ・ライブラリ
が必要とされる。仮想マシンが動作するプラットフォー
ムの全てのRPCに対してスタブをコーディングすると、
時間がかかるとともにエラーが起こり易い。

【０００９】従って、プラットフォーム依存型アダプタ
のライブラリを自動生成する技術の必要性が存在する。
さらに、仮想マシンが動作するプラットフォームに対し
てプラットフォーム依存型スタブのライブラリを自動的
に与える技術の必要性が存在する。

【００１０】

【課題を解決するための手段】一般的には本発明の実施
形態は、仮想マシンで使用されるプラットフォーム依存
アダプタとスタブとのライブラリを自動的に生成する革
新的なシステムおよび方法をもたらすものである。

【００１１】ランタイム・システムにおいてバイトコー
ドを実行するとともにアダプタもしくはスタブを自動的
に与える装置が開示される。装置は、インタプリタ・ユ
ニットに連結されたバイトコード・ソースを含む。イン
タプリタは、バイトコードを解釈するために使用され
る。インタプリタは次に、解釈済バイトコードを実行す
るランタイム・システムに連結される。バイトコード
は、バイトコードをコンパイルするために使用されるコ
ンパイラにも連結される。コンパイラは、コンパイル済
バイトコードを実行するランタイム・システムに連結さ
れる。装置はまた、必要なときにランタイム・システム
に対してアダプタもしくはスタブを要求に応じて与え
る、コンパイラに連結されたアダプタ／スタブ生成器ユ
ニットも含んでいる。

【００１２】好適な実施形態においては、ランタイム・
システムに連結されたライブラリはアダプタおよびスタ
ブを保存するために使用され、アダプタおよびスタブは
必要に応じてランタイム・システムにより取出される。

【００１３】別の実施形態においては、ランタイム・シ
ステムにおいてバイトコードを処理するコンピュータ・
プログラム製品が開示される。プログラム製品はコンピ
ュータ・コードを含むが、コンピュータ・コードは、受
信したバイトコードを解釈するとともに、解釈済バイト
コードを実行のためにランタイム・システムへと渡す。
コンピュータ・コードはまた、受信したバイトコードを
コンパイルするとともにコンパイル済バイトコードを実
行のためにランタイム・システムへと渡す。コンピュー
タ・コードはまた、バイトコードを実行するためにラン
タイム・システムにより要求されたときにアダプタも生
成する。

【００１４】別の実施形態においては、ランタイム環境
にてバイトコードを処理するための、コンピュータによ
り実行される方法が開示される。もしバイトコードを処
理するためにアダプタが必要とされれば、必要アダプタ
がアダプタ・ライブラリ内にあるかどうかに関する決定
が行われる。もし必要アダプタがアダプタ・ライブラリ
内に無ければ、アダプタ生成器はそのアダプタを構築し
てそれをライブラリ内に保存し、ライブラリは次にアダ
プタをランタイム・システムに与えるとランタイム・シ
ステムはバイトコードを実行する。

【００１５】本発明の他の特徴および利点は、添付図面
に関連した以下の詳細な説明を検討すれば容易に明らか
となろう。

【００１６】

【発明の実施の形態】定義 関数[function]−(サブルーチン、プロシージャ、メン
バ関数および方法とも称される)ソフトウェア・ルーチ
ン。

【００１７】フレーム(もしくは起動フレームもしくは
起動レコード)−関数がその関数の実行のための情報を
保存するための、実行スタックに保存されるレコードで
あり、そのような情報としては状態変数、ローカル変
数、オペランド・スタックが挙げられる。

【００１８】実行スタック−プログラム実行の間に活用
され、関数に対するフレームをそれらの連続的呼出し順
に保存するスタック。関数(「呼出対象」)が呼出された
とき、その関数に対するフレームは実行スタック上に押
し出される。その後、その関数が終了したとき、そのフ
レームはスタックからはじき出されるとともに、実行ス
タックの先頭となるフレームに対する関数(「呼出対
象」)の実行が再開される。

【００１９】オペランド・スタック−実行の間にマシン
命令により使用されるオペランドを保存するために活用
されるスタック。

【００２０】外部コード−特定のプログラミング言語
(たとえばJavaプログラミング言語)以外のプログラミン
グ言語で記述されたコンピュータ・コード。たとえば、
Java仮想マシンはC++プログラミング言語で記述され得
るとともにJava仮想マシンは、解釈されつつあるプログ
ラムのJavaコードに関しては外部コードと見做され得る
(外部コードは固有の方法を含む)。

【００２１】固有の方法−Javaプログラミング言語以外
のプログラミング言語で記述された関数。固有の方法は
Javaプログラムにより呼出され、ダイナミックにロード
および実行され得る。その上、固有の方法はJavaプログ
ラミング言語で記述された関数を呼出し得る。

【００２２】以下の説明においては、Javaプログラム
(たとえばバイトコード)を実行するJava仮想マシンに対
する実行スタックを実行する好適実施形態に関して本発
明を説明する。特に、Java仮想マシンがC++プログラミ
ング言語で記述された例を説明する。しかしながら、本
発明は何らかの特定の言語、コンピュータ・アーキテク
チャ、特定の実行に限定されるものでない。従って、以
下における実施形態の説明は例示的なものであり、限定
的なものではない。

【００２３】図１は、本発明の実施形態のソフトウェア
を実行するために使用され得るコンピュータ・システム
の一例を示している。図１は、ディスプレイ3、画面5、
キャビネット7、キーボード9およびマウス11を含むコン
ピュータ・システム1を示している。マウス11は、グラ
フィカル・ユーザ・インタフェースと相互作用を行う一
つ以上のボタンを有し得る。キャビネット7はCD-ROMド
ライブ13、システム・メモリ、ハードディスク・ドライ
ブ(図２参照)を収納するが、これらは、本発明を実現す
るコンピュータ・コードを取り入れたソフトウェア・プ
ログラム、本発明で使用されるデータなどの保存および
読出しに使用され得る。CD-ROMドライブ15は典型的なコ
ンピュータ可読保存媒体として示されているが、フロッ
ピー・ディスク、テープ、フラッシュ・メモリ、システ
ム・メモリ、ハードディスク・ドライブなどの他のコン
ピュータ可読保存媒体も活用され得る。さらに、(たと
えばインターネットなどのネットワークにおける)搬送
波で具体化されたデータ信号はコンピュータ可読保存媒
体とされ得る。

【００２４】図２は、本発明の実施形態のソフトウェア
を実行するために使用され得るコンピュータ・システム
1のシステム・ブロック図である。図１に示された如
く、コンピュータ・システム1はディスプレイ3、キーボ
ード9およびマウス11を含んでいる。コンピュータ・シ
ステム1はさらに、中央プロセッサ51、システム・メモ
リ53、固定記憶装置55(たとえばハードディスク・ドラ
イブ)、着脱式記憶装置57(たとえばCD-ROMドライブ)、
ディスプレイ・アダプタ59、サウンド・カード61、スピ
ーカ63、ネットワーク・インタフェース65などのサブシ
ステムを含んでいる。本発明とともに使用されるのに適
した他のコンピュータ・システムは、さらに別のサブシ
ステムを含むこともあれば、これほどサブシステムを含
まないこともある。たとえば、別のコンピュータ・シス
テムは二つ以上のプロセッサ51(即ちマルチ・プロセッ
サ・システム)もしくはキャッシュ・メモリを含むこと
がある。

【００２５】コンピュータ・システム1のシステム・バ
ス・アーキテクチャは、矢印67で表される。但し、これ
らの矢印はサブシステムをリンクする何らかの相互接続
機構の実例である。たとえば、中央プロセッサをシステ
ム・メモリおよびディスプレイ・アダプタに接続するた
めにローカル・バスが活用され得る。但し、図２に示さ
れたコンピュータ・システム1は、本発明で使用される
に適したコンピュータ・システムの一例に過ぎない。異
なる構成のサブシステムを有する他のコンピュータ・ア
ーキテクチャも活用され得る。

【００２６】典型的には、Javaプログラミング言語で記
述されたコンピュータ・プログラムはバイトコードすな
わちJava仮想マシン命令へとコンパイルされ、次にJava
仮想マシンにより実行される。バイトコードは解釈のた
めにJava仮想マシンへと入力されるクラス・ファイル内
に保存される。図３は、Java仮想マシンにおけるインタ
プリタによる実行を通じた、単一のJavaソース・コード
の進行を示している。

【００２７】Javaソース・コード101は、Javaで記述さ
れた古典的Hello Worldプログラムを含む。ソース・コ
ードは次に、ソース・コードをバイトコードへとコンパ
イルするバイトコード・コンパイラ103へと入力され
る。バイトコードは仮想マシン用命令である、と言うの
も、それらはソフトウェアによりエミュレートされたコ
ンピュータにより実行されるからである。典型的には、
仮想マシン用命令は汎用的である(即ち、何らかの特定
のマイクロプロセッサもしくはコンピュータ・アーキテ
クチャ向けには設計されていない)が、これは必須では
ない。バイトコード・コンパイラは、Javaプログラムに
対するバイトコードを含むJavaクラス・ファイル105を
出力する。

【００２８】Javaクラス・ファイルは、Java仮想マシン
107へと入力される。Java仮想マシンは、Javaクラス・
ファイルにおけるバイトコードを解読して実行するイン
タプリタである。Java仮想マシンはインタプリタである
が一般的に仮想マシンと称される、と言うのも、それは
ソフトウェアによりマイクロプロセッサもしくはコンピ
ュータ・アーキテクチャ(たとえば、ハードウェア内に
は存在していないマイクロプロセッサもしくはコンピュ
ータ・アーキテクチャ)をエミュレートするからであ
る。

【００２９】図４は、Javaランタイム・システムの実行
を示している。Java仮想マシンの実行は、Javaランタイ
ム・システムとして知られている。Javaランタイム・シ
ステム201はJavaプログラムを実行するために、Javaク
ラス・ファイル203、標準的組み込みJavaクラス205およ
び固有の方法207の入力を受信し得る。標準的組み込みJ
avaクラスは、スレッド、ストリングなどのオブジェク
トに対するクラスでよい。固有の方法は、Javaプログラ
ミング言語以外のプログラミング言語で記述され得る。
固有の方法は典型的には、ダイナミック・リンク・ライ
ブラリ(DLL)もしくは共用ライブラリ内に保存される。

【００３０】Javaランタイム・システムはまた、オペレ
ーティング・システム209とインタフェースし得る。た
とえば、Javaクラス・ファイル203、標準的組み込みJav
aクラス205、固有の方法207をJavaランタイム・システ
ムに与えるなどのI/O機能は、オペレーティング・シス
テムにより取り扱われ得る。

【００３１】ダイナミック・クラス・ローダ／ベリファ
イヤ211はオペレーティング・システム209を介してJava
クラス・ファイル203および標準的組み込みJavaクラス2
05をメモリ213内にロードする。その上、ダイナミック
・クラス・ローダ／ベリファイヤは、Javaクラス・ファ
イルにおけるバイトコードの正確さを検証し、検出され
た一切のエラーを報告する。

【００３２】固有の方法・リンカ215はオペレーティン
グ・システム209を介して固有の方法207をJavaランタイ
ム・システムにリンクするとともに、固有の方法をメモ
リ213に保存する。示された如く、メモリ213はJavaクラ
スに対するクラス／方法の領域と、固有の方法に対する
固有の方法の領域とを含み得る。メモリ213内のクラス
／方法の領域は、ガーベジ収集ヒープ内に保存され得
る。新たなオブジェクトが生成されると、それらはガー
ベジ収集ヒープに保存される。スペースがもはや活用さ
れていないときは、アプリケーションではなくJavaラン
タイム・システムがガーベジ収集ヒープ内のメモリを再
生使用する責任を有する。

【００３３】図４においてJavaランタイム・システムの
中心には、実行エンジン217が示される。この実行エン
ジンはメモリ213に保存された命令を実行するととも
に、ソフトウェア、ハードウェアもしくは両者の組合せ
により実現され得る。この実行エンジンはまたオブジェ
クト指向アプリケーションをサポートするとともに、概
念的には、Javaスレッドのそれぞれに一つずつとなるよ
うに複数の実行エンジンが同時に実行される。実行エン
ジン217はサポート・コード221も活用し得る。このサポ
ート・コードは、例外、スレッド、セキュリティなどに
関する機能性を与え得る。

【００３４】Javaプログラムが実行されるとき、スレッ
ド内ではそれぞれの関数が連続的に呼出される。スレッ
ドに対しては、実行を未だ完了していない関数のそれぞ
れに対するフレームを保存する実行スタックがある。フ
レームは関数を実行するための情報を保存するが、その
ような情報は状態変数、ローカル変数、オペランド・ス
タックを含み得る。関数が呼出されると、その関数に対
するフレームが実行スタック上に押し出される。その関
数が終了したとき、その関数のフレームは実行スタック
からはじき出される。従って、実行スタックの先頭のフ
レームに対応する関数のみが現用となっており、実行ス
タックの先頭より下位のフレームに対応する関数の実行
は、それらが呼出した関数が戻る(即ち、終了する)まで
中断される。

【００３５】図５は、実行スタック上に保存された、関
数に対するフレームを示す図である。実行スタック301
は、実行スタックの先頭のフレーム303と、それぞれフ
レーム303の下位に保存されたフレーム305および307と
を有している。スタック・ポインタSPは実行スタックの
先頭を指し示す一方、フレーム・ポインタFPは実行スタ
ック301の先頭におけるフレームのフレーム・ポインタ
を指し示す。

【００３６】各フレームは、そのフレームに対応する関
数に対する状態変数、ローカル変数、オペランド・スタ
ックを含むものとして示される。その上、フレームに保
存された最後のアイテムはフレーム・ポインタである
が、フレーム・ポインタは矢印309および311で示された
如く実行スタック上で現在のフレームの下位となるフレ
ームのフレーム・ポインタを指し示している。

【００３７】或る関数が別の関数を呼出すと、システム
は先ず現在の関数に対するリターン・アドレスを実行ス
タック301上に押し出し、次に、間近に呼出された関数
に対する新たなフレームを押し出す。このようにして、
新たな関数が戻したとき、システムは実行スタックの先
頭にフレームを動かし、次に、実行スタックからリター
ン・アドレスをはじき出すとともにプログラム・カウン
タをこのリターン・アドレスに等しく設定し得ることか
ら、呼出しを行った関数の実行が再開され得る。従っ
て、これが、フレーム305および307はリターン・アドレ
スを含むが現用となっているフレーム303はリターン・
アドレスを含まない理由である。但し、フレーム303に
対応する関数が別の関数を呼出したときは、その新たな
関数に対するフレームが実行スタック301上に押し出さ
れる前に実行スタック301上にリターン・アドレスが押
し出される。

【００３８】フレーム・ポインタによれば、システムは
実行スタック上で正確にフレームを移動し得る。たとえ
ば、スタック・ポインタSPおよびフレーム・ポインタFP
は実行スタックの先頭におけるフレームを記述する。さ
らに、フレーム303におけるフレーム・ポインタは実行
スタック上における次のフレームを指定する。フレーム
303におけるフレーム・ポインタのすぐ下のアドレスは
実行スタック上における次のフレームの開始であり、且
つ、フレーム303のフレーム・ポインタの内容は、実行
スタック上のフレーム305である次のフレームにおける
最後のアイテムを指定する。同様に、フレーム305にお
けるフレーム・ポインタは実行スタック上における次の
フレームの位置を指定する。従って、フレーム・ポイン
タの連鎖により、システムは(たとえばフレームが実行
スタックからはじき出されるときに)実行スタック上で
フレームを移動し得る。

【００３９】図５は実行スタックの実行を示している
が、本発明は図示された実行に限定されるものでない。
たとえば、実行スタックはメモリ内で上方に増加して示
されるが、スタックはメモリ内で下方に増加し得ること
を理解すべきである。さらに、フレーム内に保存された
情報は実行に依存して変化し得る。

【００４０】最近になって、オブジェクト指向言語であ
るJavaプログラミング言語は、Java仮想マシン(即ちバ
イトコード・インタプリタ)が与えられる任意のコンピ
ュータ・システム・プラットフォームで動作し得る(バ
イトコードと称された)コンパイル出力の可能性を導い
た。Java仮想マシンは、実際のハードウェア・プロセッ
サにより実行され得る命令へとバイトコードを変換する
ように設計される。この仮想マシンを使用すると、一回
に一命令分ずつ解釈されるのではなく、バイトコードは
特定システム・プラットフォームにおいて一定の場合に
はジャストインタイム(JIT)コンパイラにより再コンパ
イルされ得る。

【００４１】図６は、本発明の実施形態に係るJava仮想
マシン(JVM)600を含む装置を示している。Javaプログラ
ミング言語および環境においてジャストインタイム(JI
T)コンパイラは、プロセッサへと直接的に送られ得る命
令へとJavaバイトコードを変換するプログラムである。
Javaプログラムが記述された後でJavaソース言語ステー
トメントはJavaコンパイラにより、特定のハードウェア
・プラットフォームのプロセッサ(たとえば、Intel Pen
tiumマイクロプロセッサもしくはIBMシステム／390プロ
セッサ)に対応する命令を含むコードよりは、Javaバイ
トコードへとコンパイルされる。Javaバイトコードは、
任意のプラットフォームへと送られてそのプラットフォ
ーム上で動作し得るプラットフォーム独立型コードであ
る。

【００４２】より詳細には、コンパイラ602により与え
られたJITコンパイラに対してバイトコードが与えられ
るとき、バイトコード604内に含まれた方法のコンパイ
ルは、方法が実行されようとするまで遅延される。バイ
トコード604がインタプリタ606に対して与えられると
き、バイトコード604はインタプリタ606内に一回に一バ
イトコード分ずつインタプリタ606に読み込まれる。そ
れから、インタプリタ606は、バイトコードにより定義
されたオペレーションに対応するパラメータを実行スタ
ック500へとロードする。ロードされたなら、インタプ
リタ606はバイトコード604により定義されたオペレーシ
ョンを実施する。即ちインタプリタ606は、その技術に
熟練した者であれば理解されるように、バイトコード60
4を「解釈」する。一般的には、インタプリタ606はバイ
トコード604を処理するとともにバイトコード604に関連
するオペレーションをほとんど連続的に実施する。

【００４３】或る方法が別の方法により呼び出されたと
き、または、その方法が解釈される場合には、ランタイ
ム・システム608は、インタプリタ606により直接的に実
行され得る一連のバイトコード604の形態でその方法を
取得する。他方、もし呼び出された方法が未だコンパイ
ルされていないコンパイル方法であれば、ランタイム・
システム608は一連のバイトコード604の形態でその方法
を取得してから、コンパイラ602により与えられるプラ
ットフォーム特有コンパイラを起動し続け得る。コンパ
イラ602はそれから、バイトコード604からマシン命令を
生成するとともに、結果として得られるマシン語命令は
目的のプラットフォームのオペレーティング・システム
610により直接的に実行され得る。一般的には、マシン
語命令は仮想マシン600が終了するときに廃棄される。

【００４４】しかしながら、コンパイラ602において一
つのもしくは一連のバイトコードをコンパイルするため
には、限られたコンパイル時間の量が必要とされる。コ
ンパイラはソース・コードを実行する前に固有マシン命
令へと解読することから、解読は実行の間には実施され
ない。従来のインタプリタは反復的に命令に遭遇する毎
にソース・コード命令を実行前に解読することから、解
釈されたプログラムの実行はコンパイルされたプログラ
ムよりも相当に低速なのが典型的である、と言うのも、
コンパイルされたプログラムの固有マシン命令はソース
・コードの解読を要さずに固有マシンもしくはコンピュ
ータ・システム上で実行され得るからである。従って、
パフォーマンスが重要な要因であるときは常に、インタ
プリタの代わりにコンパイラを使用してソース・コード
を解読するのが望ましい。従って、一つのもしくは一連
のバイトコードを仮想マシン600が受信したとき、その
一つのもしくは一連のバイトコードがインタプリタによ
り解釈されるべきかコンパイラによりコンパイルされる
べきかに関する決定が行われる。たとえば、付与された
一つのもしくは一連のバイトコードがコンパイルされた
コードを実行することにより処理されるべきであるとと
もに、前の一つのもしくは一連のバイトコードがインタ
プリタにより処理されていた場合、プラットフォーム特
有アダプタが与えられねばならない。コンパイル済コー
ド(I/C)アダプタに対するプラットフォーム特有のイン
タプリタは、インタプリタにより使用された実行スタッ
ク500をコンパイル済コードにより使用され得る実行ス
タックへと翻訳するために使用される。その上、アダプ
タはシステム内の他の構成要素の状態を更新し得る。

【００４５】あるいはまた、前の一つのもしくは一連の
バイトコードがおそらくはコンパイラ602により生成さ
れたコンパイル済コードを実行することにより処理され
ており、且つ、現在の一つのもしくは一連のバイトコー
ドを解釈することがさらに実行上効率的であると決定さ
れた場合、実行スタック500をインタプリタにより使用
され得る実行スタックへと適切に翻訳するために、コン
パイル済コード対インタプリタ(C/I)のアダプタが与え
られねばならない。その上、そのアダプタはシステム内
における他の構成要素の状態を更新し得る。

【００４６】I/CアダプタもしくはC/Iアダプタのいずれ
かが生成されたとき、それはコンパイラ602およびラン
タイム・システム608に連結されたライブラリ614へと保
存される。このようにして、特定アダプタが必要なこと
が決定されるときは常にライブラリ614に問い合わせが
行われ、その特定アダプタが存在しなければそのアダプ
タが生成される。特定プラットフォーム専用アダプタを
生成するためには、様々なプラットフォーム依存型の入
力が必要とされる。一実施形態においては、これらの入
力としてはたとえば、既知の種類の呼出元、既知の種類
の呼出対象、呼出対象の既知のパラメータの数および種
類、呼出規約などが挙げられる。

【００４７】図７は、本発明の実施形態に従い一つのも
しくは一連のバイトコードを処理するプロセス700の詳
細を示すフローチャートである。プロセス700は、一つ
のもしくは一連のバイトコードを受信したときに702に
て開始する。704では、一つのもしくは一連のバイトコ
ードが、解釈されるのか、または、コンパイル済コード
を実行することにより処理されるのかに関する決定が行
われる。もし一つのもしくは一連のバイトコードがコン
パイル済コードを実行することにより処理されるべきで
あれば、708ではI/Cアダプタが必要かどうかに関する決
定が行われる。もしアダプタが必要でなければ、一つの
もしくは一連のバイトコードは710においてコンパイル
済コードを実行することにより処理され、その結果が71
1にて戻される。しかし、もしアダプタが必要であれ
ば、712では必要なアダプタがライブラリ内に保存され
ているかどうかに関する決定が行われる。必要なアダプ
タがもしライブラリ内に保存されていなければ、必要な
アダプタは714にて生成されるか、さもなければ、必要
なアダプタは716にてライブラリから取出される。いず
れの場合にも、アダプタは718にてコンパイルされ、そ
の後にアダプタは720にてライブラリに保存されて、722
ではコンパイル済コードを実行する準備が行われる。準
備が完了したなら、一つのもしくは一連のバイトコード
は、コンパイルされたバイトコードを710にて実行する
ことで処理される。

【００４８】コンパイル済みのバイトコードの実行の結
果が711にて戻された後、724ではより多くのバイトコー
ドが使用可能かどうかに関する決定が行われる。もしよ
り多くのバイトコードが使用可能であれば、制御は704
に渡されてバイトコードを受信するが、その他の場合に
はプロセス700は停止する。

【００４９】704に戻ると、受信した一つのもしくは一
連のバイトコードが解釈されるべきことが決定されれ
ば、726ではC/Iアダプタが必要かどうかに関する決定が
行われる。もしアダプタが必要でなければ、一つのもし
くは一連のバイトコードは728にて解釈され、その結果
は730にて戻される。但し、もしアダプタが必要なら
ば、必要なアダプタがライブラリに保存されているかど
うかに関する決定が732にて行われる。もし必要なアダ
プタがライブラリ内に保存されていなければ、必要なア
ダプタは734にて生成され、さもなければ、必要なアダ
プタは736にてライブラリから取出される。いずれの場
合にも、アダプタは738にてコンパイルされ、その後に
アダプタは740にてライブラリ内に保存される。742では
バイトコードを解釈する準備が行われ、その後にバイト
コードは728にて解釈され、その結果は730にて戻され
る。

【００５０】解釈されたバイトコードの結果が730にて
戻された後、724ではより多くのバイトコードが使用可
能かどうかに関する決定が行われる。もしより多くのバ
イトコードが使用可能であれば、制御は704に渡されて
バイトコードを受信するが、その他の場合にはプロセス
700は停止する。

【００５１】図８は、本発明の実施形態に従いアダプタ
／スタブを生成する一つのもしくは一連のバイトコード
を処理するプロセス700の詳細を示すフローチャートで
ある。プロセス800は802にて、コンパイル済コードへの
呼出しに対するパラメータと、関連するマシン状態とを
識別することにより開始する。次に、入力されたパラメ
ータおよびマシン状態は804にて、コンパイル済コード
呼出しの入力へとマッピングされる。806にて、マシン
状態および戻り値は「インタプリタ対コンパイル済コー
ドのアダプタの戻りポイントへとマッピングされる。80
8では、オブジェクト・コードのコンパイルおよび生成
のためにアダプタ／スタブの表示がコンパイラに対して
与えられる。

【００５２】上述した内容は、本発明の好適実施形態を
完全に説明したものであるが、代替案および変更が存在
するとともに、本発明と同等の発明が使用され得る。本
発明は、上述された実施形態に対する適切な変更を行う
ことによって、等しく適用可能であることは明らかであ
る。たとえば、説明された実施形態はJavaフレームを含
む実行スタックに関していたが、本発明の原理は他のシ
ステムおよび言語に対して容易に適用され得る。従っ
て、上述の説明は、上述の請求項の全体および限度によ
って定義された本発明の範囲、さらにそうした請求項の
全体及び限度によって定義された本発明と同等の発明の
全範囲を制限するものと解釈すべきではない。

【図面の簡単な説明】

【図１】本発明の実施形態のソフトウェアを実行するた
めに活用され得るコンピュータ・システムの一例を示す
図である。

【図２】図１のコンピュータ・システムのシステム・ブ
ロック図である。

【図３】Javaソース・コードが実行される方法を示す図
である。

【図４】Javaランタイム・システムの実行の構成要素を
示す図である。

【図５】実行スタック上に保存された、関数に対するフ
レームを示す図である。

【図６】Java仮想マシンにおける本発明の実施形態を示
す図である。

【図７】Java仮想マシンにおけるアダプタ／スタブの使
用法のフローチャートである。

【図８】アダプタ／スタブを生成するフローチャートで
ある。

フロントページの続き (72)発明者 クリフォード エヌ． クリック， ジュ ニア アメリカ合衆国， カリフォルニア州， サン ノゼ， ウォーレイス ドライヴ 955 (72)発明者 クリストファー エー． ヴィック アメリカ合衆国， カリフォルニア州， サン ノゼ， リオ グランデ ドライヴ 5290 (72)発明者 マイケル エイチ． パレッツィニィ アメリカ合衆国， カリフォルニア州， サニーヴェイル， アリバ ドライヴ 241 ナンバー 10

Claims (7)

【特許請求の範囲】
1. 【請求項１】 ランタイム・システムでバイトコードを
   実行する装置であって、 バイトコード・ソースと、 バイトコード・ソースに連結されてバイトコードを解釈
   するために使用されるインタプリタと、 バイトコード・ソースに連結されてバイトコードをコン
   パイルするために使用されるコンパイラと、 インタプリタに連結されるとともにコンパイラに連結さ
   れたランタイム・システムであって、バイトコードがイ
   ンタプリタにより解釈されたものであるときには解釈済
   バイトコードを実行するために配置されるとともに、バ
   イトコードがコンパイラによりコンパイルされたもので
   あるときにはコンパイル済バイトコードを実行するため
   に配置されたランタイム・システムと、 コンパイラに対して要求に応じてアダプタ・ソース・コ
   ードもしくはスタブ・ソース・コードを与えるために配
   置されたコンパイラに連結されたアダプタ／スタブ生成
   器ユニットと、 コンパイラによりコンパイルされたアダプタおよびスタ
   ブを保存するために配置されたコンパイラおよびランタ
   イム・システムに連結されたライブラリであって、必要
   なときにはランタイム・システムがアダプタを取出す、
   ライブラリとを含む、装置。
2. 【請求項２】 バイトコードが、一連のバイトコードの
   一つである、請求項１に記載の装置。
3. 【請求項３】 アダプタ生成器が、必要なアダプタを生
   成するために使用されるアダプタ入力パラメータを供え
   る、請求項１に記載の装置。
4. 【請求項４】 バイトコードを処理する装置を実行する
   コンピュータ・プログラム製品であって、 受信したバイトコードを解釈するコンピュータ・コード
   と、 受信したバイトコードをコンパイルするコンピュータ・
   コードと、 コンパイラにより要求されたときにアダプタを生成する
   コンピュータ・コードと、 アダプタを保存するとともに、コンパイル済バイトコー
   ドもしくは解釈済バイトコードを実行するときにランタ
   イム・システムにアダプタを与えるコンピュータ・コー
   ドと、 コンピュータ・コードを保存するコンピュータ可読媒体
   とを含む、コンピュータ・プログラム製品。
5. 【請求項５】 ランタイム環境にてバイトコードを処理
   する、コンピュータ・システムにおける方法であって、 バイトコードを処理するためにアダプタが必要かどうか
   を決定する工程と、 アダプタが必要とされたときにそのアダプタがアダプタ
   ・ライブラリ内に配置されているかどうかを決定する工
   程と、 必要なアダプタがライブラリ内に無いことが決定された
   ならばそのアダプタを生成する工程と、 生成されたアダプタをライブラリ内に保存する工程と、
   アダプタをランタイム環境に与える工程と、 バイトコードを実行する工程とを含む、コンピュータ・
   システムにおける方法。
6. 【請求項６】 ランタイム環境でバイトコードを処理す
   るコンピュータ・プログラム製品であって、 バイトコードを与えるコンピュータ・コードと、 バイトコードを実行するためにアダプタが必要かどうか
   を決定し、且つ、必要なアダプタがアダプタ・ライブラ
   リ内に存在しないときにその必要なアダプタを生成して
   必要アダプタを要求に応じてランタイム・システムに与
   えるコンピュータ・コードと、 コンピュータ・コードを保存するコンピュータ可読媒体
   とを含む、コンピュータ・プログラム製品。
7. 【請求項７】 コンピュータ可読媒体が、CD-ROM、フロ
   ッピー（登録商標）・ディスク、テープ、フラッシュ・
   メモリ、システム・メモリ、ハードディスク・ドライ
   ブ、搬送波上で具体化されたデータ信号からなる群から
   選ばれた１種である、請求項６に記載のコンピュータ・
   プログラム製品。