(57)【特許請求の範囲】
【請求項１】
プロセッサと、
前記プロセッサに接続され、前記プロセッサに仮想マシンを実現させるためのコンピュータプログラムを格納するメモリと、
を有するコンピュータシステムであって、
前記仮想マシンは、
ロード対象のクラスを受信すると、前記メモリに格納されている前記受信したクラスと該クラスのスーパークラスとに関連するクラス情報の所定のフィールドを設定することによって、前記受信したクラスと該クラスのスーパークラスとをマーク付けするステップと、
前記マーク付けされたクラス情報を参照して、各コンパイル済みのメソッドに関連する従属性情報であって、前記コンパイル済みのメソッドの最適化された全仮想関数コールのクラス、関数名及びタイプシグネチャのリストから構成される前記従属性情報の前記クラスが前記マーク付けされたクラスを含むか判断するステップと、
前記従属性情報の前記クラスが前記マーク付けされたクラスを含むことに応答して、前記従属性情報の関数名及びタイプシグネチャと前記マーク付けされたクラスの仮想関数及びタイプシグネチャとの一致があるか判断するステップと、
前記関数名と前記タイプシグネチャとの一致があることに応答して、前記コンパイル済みのメソッドを逆最適化してインタプリット済み状態に戻すステップと、
を実行するコンピュータシステム。
【請求項２】
前記クラスに関連するクラス情報は、前記クラス、前記クラスのメソッド、前記メソッドのタイプシグネチャの名前を格納するコンスタントプールを有する、請求項１記載のコンピュータシステム。
【請求項３】
前記仮想マシンは、前記仮想関数コールを実行時に動的に導出する、請求項１記載のコンピュータシステム。
【請求項４】
前記逆最適化は、前記コンパイル済みのメソッドを逆コンパイルすることからなる、請求項１記載のコンピュータシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ソフトウェアの実行時コンパイレーションに関する。より詳細には、本発明は、動的リンキング及び動的ローディングの存在下において動的にディスパッチされたコールの静的結合を実行する技術に関する。
【０００２】
【従来の技術】
オブジェクト指向言語の背景にある基本的な概念は、データを操作してオブジェクトと呼ばれる単一単位に変換する、データ及びメソッド（すなわち、関数）双方の組み合わせである。オブジェクトの関数は、一般的に、オブジェクトによってカプセル化されているデータにアクセスするための唯一の手段を提供する。データは、メッセージによって特定されたメソッドを呼び出すためにオブジェクトに命令するオブジェクトに対してメッセージを送ることによってアクセスされる。
【０００３】
効率の良いメッセージのディスパッチは、オブジェクト指向言語における最も重要な事項の１つである。その理由は、オブジェクト指向プログラムにおいて、メッセージのディスパッチは、非常に高頻度の動作であると共に、実行時に実行される動作だからである。したがって、できる限り高速に実行されるべきである。実行時前に関数のアドレスを決定可能な手続型プログラム言語（例えば、Ｃプログラム言語）とは異なり、オブジェクト指向言語は、受取側オブジェクトに対してディスパッチ済みであるメッセージを取り扱うメソッドを、実行時に動的に決定しなければならず、また、拡張サーチを伴い得る。
【０００４】
複雑なメッセージのディスパッチの理解をより良いものとするために、クラス階層の例について以下に説明する。図１は、各クラスのメソッドを含むクラス階層を図示する。クラス階層１は、そのルートに２個の仮想関数foo()及びbar()を定義する親クラスＡ３を含む。仮想関数は、親クラスにおいて定義され得ると共に、関連子クラスにおいて再定義され得る関数である。クラスＢ５及びクラスＣ７は、本質的に、親クラスＡ３のデータ及びメソッドを含んでいる。図示されるように、クラスＢ５は、仮想関数foo()及びbar()のいずれについても再定義していない。しかしながら、クラスＣ７は仮想関数foo()を再定義している。メソッドfoo()を呼び出すためにクラスＣ７のオブジェクトが要求されるとき、呼び出されたメソッドは、親クラスＡ７でなく、クラスＣ７によって定義されたメソッドである。クラスＤ９及びＥ１１もまた、メソッドfoo()を再定義する。
【０００５】
【発明が解決しようとする課題】
一般的に、オブジェクトのクラスを静的に決定することは不可能なので、オブジェクトに関連付けられている正確なメソッドのサーチは、実行時実行中、すなわち、より詳細には、メッセージのディスパッチ中に実行される。例えば、以下のようなメソッドがあるとする。
test()
{
...
x.foo();
...
}
全クラスＡ−Ｅが実行時の実行に際してロードされる場合、どの関数foo()をコールするかの決定は、クラスｘがインスタンスであるか否かに依存する。
【０００６】
さらに、性能を上げるために、test関数は実行時にコンパイルされる。実行時コンパイレーションに際しては、クラスＡ３及びＢ５だけがロードされ得る。したがって、メッセージx.foo()がＡ::foo()だけを呼び出すであろうことは、ロード済クラスの査閲から当業者にとって明らかである。当然のことながら、実行時の実行に際してクラスＣ７がロードされる場合には、この仮定は誤りであることが証明される。
【０００７】
【課題を解決するための手段】
一般的に、本発明に係る発明の実施の形態は、動的リンキング及び動的ローディングの存在下において動的にディスパッチされたコールの静的結合を実行するための革新的な技術を提供する。本発明の１つの局面によれば、実行時における関数の実行性能を増大させるための方法は、インタプリットされた、あるいは、以前にコンパイルされた関数をコンパイルすること、及び処理過程に対する関数内でコールを識別することを備えている。この方法はまた、従属情報を関数に対して付加することを備える。従属性情報は、関数のステータスを表示すると共に、処理過程に関するクラス、名前、及びシグネチャに関する情報を含む。
【０００８】
本発明の他の局面によれば、実行時中にシステムのクラス階層に関連する第１のクラスを解析するための、コンピュータ上で実行される方法は、第１のクラスをマークすること、及び２つのクラス間の関係を表示するために第１のクラスのスーパークラスである第２のクラスをマークすることを備える。そして、システムに関連するコンパイル済関数が査閲される。コンパイル済関数は、コンパイル済関数の最適化ステータスと共にコンパイル済関数の有効性ステータスを表示する従属性情報を含む。コンパイル済関数の査閲は、第１のクラス及び第２のクラスの少なくとも一方が従属性情報中にて識別される時期の決定を含む。第１のクラス、または、第１のクラス及び第２のクラスの双方が従属性情報中にて識別されたと決定されたとき、コンパイル済関数が無効であるか否かに関する決定が下される。ある実施形態では、メソッドは、コンパイル済関数が無効であると決定されるときコンパイル済関数を逆コンパイルすることを含み得る。コンパイル済関数の逆コンパイルは、関数をインタプリット済状態に戻す。
【０００９】
本発明の他の特徴、並びに利点は、添付図面と共に以下の詳細な説明を考察することにより容易に理解されるであろう。
【００１０】
【発明の実施の形態】
定義
マシン命令（すなわち、命令）とは、オペレーションコード（ＯＰコード）及び任意の１つ以上のオペランドにより特定されるオペレーションを実行するために計算機装置に指示する命令を意味する。
仮想マシン命令とは、ソフトウェアエミュレート済マイクロプロセッサ又はコンピュータアーキテクチャのための命令（仮想コードとも呼ばれる）を意味する。
ネイティブマシン命令とは、特定のマイクロプロセッサ又はコンピュータのために設計された命令（ネイティブコードとも呼ばれる）を意味する。
【００１１】
メソッドは、ソフトウェアルーチン（関数、サブルーチン、プロシージャ、及びメンバ関数とも呼ばれる）を意味する。
実行時コンパイレーションとは、実行時に実行されるコードのコンパイレーションを意味する。
実行時実行とは、実行時に実行されるコードの実行を意味する。
【００１２】
詳細な説明
以下の説明では、本発明は、Java仮想マシン命令（すなわち、バイトコード）において動的にディスパッチされたコールを静的に結合する好適な実施の形態について説明される。特に、コンパイル済Java仮想マシン命令のための実行時クラスローディング及び初期化チェックを実行するために、ＩＢＭパーソナルコンピュータ、若しくは、その互換機のために生成され得る、実ネイティブマシン命令を示す例示が記載されている。しかしながら、本発明は、いかなる特定の言語、コンピュータアーキテクチャ、あるいは、特定のインプリメンテーションにも限定されるものではない。したがって、以下の発明の実施の形態の記載は、説明のためのものであって、限定を目的とするものではない。
【００１３】
Java（商標）プログラム言語は、サンマイクロシステムズ社により開発された、小規模デバイス（例えば、ポケットベル、携帯電話及びスマートカード）からスーパーコンピュータに至るまで幅広い範囲のコンピュータ上で実行されるために十分に高移植性であるように設計された、オブジェクト指向の高レベルプログラム言語である。Java（及び他の言語）で記述されたコンピュータプログラムは、Java仮想マシンによる実行のために、仮想マシン命令にコンパイルされ得る。一般的に、Java仮想マシンは、仮想マシン命令をデコードし、実行するインタプリタである。
【００１４】
Java仮想マシン用仮想マシン命令は、１以上のバイトを含む、バイトコードである。バイトコードは、クラスのメソッドのためのバイトコードを含む「クラスファイル」と呼ばれる特定のファイル形式中に格納される。クラスのメソッドのためのバイトコードに加え、クラスファイルは、他の付属情報と共にシンボルテーブルを含んでいる。
【００１５】
Javaバイトコードとして１つ以上のクラスファイル中に具象化されたコンピュータプログラムは、プラットフォームに依存しない。コンピュータプログラムは、Java仮想マシンのインプリメンテーションを実行可能な任意のコンピュータ上で、修飾されることなく実行され得る。Java仮想マシンは、Java仮想マシン用のコンピュータプログラムが、プラットフォームに依存しないことを許容することを重要な要素とする、「汎用」コンピュータのソフトウェアエミュレータである。
【００１６】
Java仮想マシンは、ソフトウェアインタプリタとしても実現され得る。
実行時にデコーディングが実行されないように、実行に先立ってソースコードをネイティブマシン命令にデコードするコンパイラに対して、従来のインタプリタは、実行時に、インタプリット済プログラムの１つのプログラムの仮想マシン命令をデコードすると共に実行する。Java仮想マシンは、実行時コンパイレーションのために、インタプリタ及びコンパイラの双方を含み得る。一般的に、Java仮想マシンは、Javaプログラム言語以外のプログラム言語（例えば、Ｃ＋＋プログラム言語）で記述される。
【００１７】
図２は、本発明に係る発明の実施の形態のソフトウェアを実行するために用いられ得るコンピュータシステムを例示する。図２は、ディスプレイ３０３、スクリーン３０５、キャビネット３０７、キーボード３０９及びマウス３１１を含むコンピュータシステム３０１を図示する。マウス３１１は、グラフィカルユーザインターフェースと対話するための１個以上のボタンを有し得る。キャビネット３０７は、本発明を実行するコンピュータコードを組み込むソフトウェアプログラム、本発明と共に用いるデータ等を格納すると共に引き出すために用いられ得る、ＣＤ−ＲＯＭドライブ３１３、システムメモリ、及びハードドライブ（図２参照）を収容する。ＣＤ−ＲＯＭ３１５がコンピュータ読み取り可能媒体の例示として図示されているが、フレキシブルディスク、テープ、フラッシュメモリ、システムメモリ、及びハードドライブを含む、他のコンピュータ読み取り可能媒体も用いられ得る。
【００１８】
図３は、本発明に係る発明の実施の形態の１つにおけるソフトウェアを実行するために用いられる、コンピュータシステム３０１のシステムブロック図を示す。図２のように、コンピュータシステム３０１は、モニタ３０３、キーボード３０９及びマウス３１１を有している。コンピュータシステム３０１はさらに、中央処理装置３５１、システムメモリ３５３、固定記憶装置３５５（例えば、ハードディスク）、リムーバブル記憶装置３５７（例えば、ＣＤ−ＲＯＭドライブ）、ディスプレイアダプタ３５９、サウンドカード３６１、スピーカ３６３、及びネットワークインターフェース３６５といったサブシステムを備えている。本発明と共に用いることが好適な他のコンピュータは、より多くの、あるいは、より少ないサブシステムを備え得る。例えば、他のコンピュータシステムは、１個以上のプロセッサ３５１を備えたり（すなわち、マルチプロセッサシステム）、キャッシュメモリを備え得る。
【００１９】
コンピュータシステム３０１のシステムバスアーキテクチャは、矢印３６７で示されている。しかしながら、これらの矢印は、サブシステムとリンクするために機能する、任意の相互接続スキームの例示にすぎない。例えば、ローカルバスは、中央処理装置とシステムメモリ及びディスプレイアダプタとを接続するために用いられ得る。図３に図示されるコンピュータシステム３０１は、本発明と共に用いることが好適なコンピュータシステムの例示にすぎない。サブシステムの異なる構成を備える他のコンピュータアーキテクチャも用いられ得る。
【００２０】
一般的に、Javaプログラム言語で記述されているコンピュータプログラムは、後にJava仮想マシンによって実行される、バイトコード、又は、Java仮想マシン命令にコンパイルされる。バイトコードは、インタプリテーションのためにJava仮想マシンに入力されるクラスファイルに格納される。仮想マシンは、図２及び図３を参照して先に説明したコンピュータシステムのような、コンピュータシステム上で稼働し得る。図４は、本発明の実行に好適であると共に、図２及び図３のコンピュータシステム３０１によってサポートされる仮想マシンの代表図である。コンピュータプログラム、例えば、Java（商標）プログラム言語で記述されたコンピュータプログラムが実行されると、ソースコード４１０がコンパイル時環境４０５内のコンパイラ４２０に対して供給される。コンパイラ４２０は、ソースコード４１０をバイトコード４３０に翻訳する。一般的に、ソースコード４１０は、ソフトウェア開発者によってソースコード４１０が作成されたとき、バイトコード４３０に翻訳される。
【００２１】
バイトコード４３０は、一般的に、複製され、ダウンロードされ、あるいは、例えば、図３のネットワークインターフェース３６５のようなネットワークを通じて分散され、または、図３の主記憶装置３５５のような記憶装置上に格納され得る。本発明の実施の形態では、バイトコード４３０はプラットフォームに依存しない。すなわち、バイトコード４３０は、実質的に、好適な仮想マシン４４０を稼働させる任意のコンピュータシステム上で実行され得る。
【００２２】
バイトコード４３０は、仮想マシン４４０を含む実行時環境４３５に供給される。１つの実施形態では、仮想マシンはJava（商標）仮想マシンたり得る。実行時環境４３５は、一般的に、図３のＣＰＵ３５１のような１つのプロセッサ又は複数のプロセッサを使用して実行され得る。仮想マシン４４０は、コンパイラ４４２、インタプリタ４４４、及び実行時システム４４６を含んでいる。バイトコード４３０は、コンパイラ４４２、あるいは、インタプリタ４４４のいずれかに提供され得る。
【００２３】
バイトコード４３０がコンパイラ４４２に供給されると、バイトコード４３０内に含まれているメソッドがマシン命令にコンパイルされる。１つの実施形態では、コンパイラ４４２は、バイトコード４３０内に含まれているメソッドのコンパイレーションを、メソッドがまさに実行されるときまで遅延するジャストインコンパイラである。バイトコード４３０がインタプリタ４４４に供給されると、バイトコード４３０は１バイトコード毎にインタプリタ中に読み込まれる。そして、インタプリタ４４４は、各バイトコードがインタプリタ４４４中に読み込まれるのに従って、各バイトコードによって定義された演算を実行する。すなわち、インタプリタ４４４は、当業者に知られているように、バイトコード４３０を「インタプリット」する。一般的に、インタプリタ４４４はバイトコード４３０を処理すると共に、バイトコード４３０に関連する演算を実質的に連続して実行する。
【００２４】
メソッドが他のメソッドによって呼び出されるとき、あるいは、実行時環境４３５から呼び出されるとき、メソッドがインタプリットされる場合には、実行時システム４４６は、インタプリタ４４４によって直接実行され得るバイトコード４３０のシーケンスの形式で実行時環境４３５からメソッドを取得し得る。これに対して、呼び出されたメソッドが未だコンパイルされていないコンパイルメソッドである場合には、実行時システム４４６は、バイトコード４３０列の形式でメソッドを実行時環境４３５から取得し、そして、コンパイラ４４２を起動する。コンパイラ４４２は、バイトコード４３０からマシン命令を生成し、得られたマシン語命令は、図３のＣＰＵ３５１によって直接実行され得る。一般的に、マシン語命令は、仮想マシン４４０が終了すると、破棄される。
【００２５】
Javaクラス（及びインターフェース）は、動的にロード、リンク及び初期化される。ローディングは、システムが、クラスのバイナリフォーム（例えば、クラスファイル）を見つけだし、そして、クラスを表すためにバイナリコードからClassオブジェクトを構成するプロセスである。Classクラスは、クラスの構成を格納し、又は、表すためのクラスである。リンキングは、クラスのバイナリフォームを獲得し、そして、実行され得るようにシステムの実行時状態と結びつけるプロセスである。クラスの初期化は、クラスのスタティックイニシャライザ、及び、クラス内で宣言されたスタティックフィールドのイニシャライザの実行を含む。
【００２６】
各Javaクラスは、自身に関連するコンスタントプールを有する。コンスタントプールは、Javaクラスファイル内に格納され、そして、シンボルテーブルに似た関数として機能する。一般的に、コンスタントプール内の各エントリは、１から始まりコンスタントプール内のエントリ数まで増加する番号で指標付けされる。クラスのメソッドは、指標を用いてコンスタントプール内のエントリにアクセスし、あるクラスのメソッドは、他のクラスのコンスタントプールにアクセスし得ない。
【００２７】
リテラル定数を格納するコンスタントプールに加えて、コンスタントプールはクラス、メソッド、フィールド、及びインターフェースを概念的に格納する。これらのエントリを概念的に格納するということは、エントリを識別する名前は格納されるが、物理アドレスは格納されないことを意味する。すなわち、クラスＡがフィールドＦを有する場合には、（Ｆのタイプシグネチャと共に）双方の名前Ａ及びＦがコンスタントプール内に格納され得る。アドレスでなく名前を格納することにより、Java実行システムは、実行時にシンボリックレファレンスを物理アドレスに動的に導出する。
【００２８】
図５は、本発明に係る発明の実施の形態における、実行時にメソッドをコンパイルするフローチャートを図示する。ステップ５０１にて、システムは、メソッドのコンパイルは有益であると決定する。一般的に、メソッドのコンパイルは、メソッドの実行性能を増大する。しかしながら、メソッドがコンパイルされないインスタンスは多数存在する。例として、コンパイル済メソッドは、コンパイルされていないメソッドよりも多くの記憶スペースを要求し得る。少なくとも、一旦、特定のメソッドがコンパイルされるべきであると決定されると、そのメソッドはステップ５０３にてコンパイルされる。
【００２９】
ステップ５０５では、システムは、コンパイルされたメソッド中の仮想関数に対するコールを識別する。上述のように、仮想関数コールの導出は、実行時に動的に実行される。Java仮想マシン命令において、コールは呼び出し仮想命令である。
【００３０】
システムは、ステップ５０７にて、実行時コンパイレーション時のクラス階層を解析する。クラス階層は、一般に、仮想関数コールの受手側であるロード済クラスの１関数だけを表示し得る。ロード済クラスの１関数だけが仮想関数コールの受手側である場合には、システムは、コンパイル済メソッド内に、その関数に対する直接コールを配置する。さらに、システムは、全関数をコンパイル済メソッド中にインラインする。全関数のインラインは、コンパイル済メソッドのためにより多くの記憶スペースを要求するが、より高速な性能を結果としてもたらす。
【００３１】
場合によっては、仮想関数コールの受手側であり得る、１つ以上のロード済関数が存在し得る。このような場合には、システムは、関数、及び／又は、インライン関数に対する直接コールを含む、判断ツリー、または、ハッシュテーブルをインラインし得る。すなわち、ステップ５０５を参照して説明したように、仮想関数に対するコールは、ステップ５０９にて最適化され得る。
【００３２】
ステップ５１１では、システムは、コンパイル済メソッドに対して従属性情報を付加する。従属性情報は、ステップ５０９にて最適化済みである各仮想関数のクラス、関数名、及びシグネチャ（すなわち、パラメータタイプ）を含み得る。この方法では、実行時実行に際してクラスがロードされると、コンパイル済メソッドが依然として有効であるか、逆最適化されるべきか、あるいは、再最適化されるべきかを決定するために、コンパイル済メソッドについて従属性情報がチェックされ得る。この処理過程は、図７を参照して以下に詳述する。
【００３３】
図６は、従属性情報を備えるコンパイル済メソッドの実施例を図示する。コンパイル済メソッド６０９は、ヘッダ６０３及びコンパイル済コード６０５を備えている。ヘッダ６０３は、特に、従属性情報６０７を含んでいる。本実施例中では、従属性情報は、コンパイル済メソッド６０９中で最適化された全仮想関数コールのクラス、名前、及びシグネチャのリストである。この情報は、シンプルリストとして格納され得るが、他の種々の格納技術も用いられ得る。
【００３４】
図７は、実行時実行中におけるクラスローディングのフローチャートを図示する。ステップ７０１にて、システムは、実行時にロードされるべきクラスを受け取る。そして、システムは、ステップ７０３にて、クラス、及びそのクラスの全スーパークラスをマークする。クラスは、クラス階層構造（図８参照）におけるブーリアンフィールドを設定することによってマークされ得る。
【００３５】
ステップ７０５にて、システムは、コンパイル済メソッドが、その従属性情報中に任意のマーク済クラスを含んでいるかを決定するために、全てのコンパイル済メソッドを査閲する。上述のように、従属性情報は、コンパイル済メソッドのヘッダ内に格納され得る。任意のマーク済クラスがコンパイル済メソッドの従属性情報に含まれている場合には、システムは、ステップ７０７にて、関数名及びシグネチャの一致があるか否か決定する。
【００３６】
関数名及びシグネチャの一致があるか否かを決定することにより、システムは、クラスのローディングが、任意のコンパイル済メソッドを効率的に無効にするか否かを確認する。すなわち、関数名及びシグネチャの一致が存在するか否かの決定は、クラスのローディングが最適化済みの仮想関数コールのための新規且つ前回未解釈な受け手を生成するか否かを決定することである。
【００３７】
例えば、再度、図１を参照すると、クラスＡ３及びクラスＡ５だけが実行時コンパイレーションに際してロードされる場合、仮想関数コールの受け手であり得る関数は１つしか存在しないので、システムは、Ａ::foo()に対する直接コールを、コンパイル済メソッド内に配置し得る（あるいは、全関数をインラインすることすら可能である）。しかしながら、実行時実行中に、クラスＣ７がロードされる場合には、仮想関数コール（すなわち、Ｃ::foo()）のための他の受け手が存在し得る。したがって、コンパイルメソッドは、逆最適化されるべきか、あるいは、再最適化されるべきである。
【００３８】
ステップ７０７にて、コンパイル済メソッドについて一致が存在する場合には、コンパイル済メソッドは、ステップ７０９にて逆最適化される。コンパイル済メソッドの逆最適化は、メソッドを自身のインタプリット済フォームに逆戻りさせること、あるいは、「逆コンパイル」することを含み得る。さらに、システムは、新規にロードされたクラスを考慮するために、コンパイル済メソッドを再最適化し得る。
【００３９】
図８は、メモリ中におけるクラス階層の代表例を図示する。クラス８０１は、その下方のクラスに対してスーパークラスであることを示すルートに図示されている。図示されているように、クラス８０３、８０５は、クラス８０１のサブクラスである。各クラスのクラス情報は、図７のステップ７０３におけるのと同様に、クラスをマークするために用いられるブーリアンフィールドを含み得る。
【００４０】
さらに、各クラスのクラス情報は、サブクラスポインタ、及びシビリングポインタを含み得る。サブクラスポインタは、本例中ではクラス８０３が相当する第１サブクラスを指している。シビリングポインタは、シビリングであるクラスのリンクリストを形成する。図示されているように、クラス８０３のシビリングポインタは、クラス８０５を指している。サブクラスポインタ及びシビリングポインタを使用することにより、本発明に係る発明の実施の形態におけるシステムは、クラス階層を容易にトラバースすることができる。
【００４１】
結論
以上が本発明に係る好適な発明の実施の形態の説明であるが、種々の変形例、改良例、及び等価例が用いられ得る。本発明は、上述の発明の実施の形態に対して適当な改良を施すことによっても、同様に利用可能であることは明らかである。例えば、既述の発明の実施の形態は、Java仮想マシンによって実行されるアプリケーションに関するが、本発明の原理は、他のシステム及び言語に対して容易に適用され得る。したがって、上記記述は、その最大の均等の範囲及びその特許請求の範囲の境界及び範囲によって定義される本発明の範囲を制限するものでない。
【図面の簡単な説明】
【図１】オブジェクト指向環境において仮想関数を含むクラスのクラス階層を示す説明図。
【図２】本発明に係る発明の実施の形態のソフトウェアを実行するために用いられ得るコンピュータシステムを例示する説明図。
【図３】図１のコンピュータシステムのシステムブロック図。
【図４】本発明に係る発明の実施の形態に従う仮想マシンのブロック図。
【図５】本発明に係る発明の実施の形態に従う、実行時にメソッドをコンパイルするフローチャート。
【図６】従属性情報を含むコンパイル済メソッドの１つに実施形態を図示する説明図。
【図７】本発明に係る発明の実施の形態に従う、実行時実行中におけるクラスのローディングの処理過程を示すフローチャート。
【図８】本発明に係る発明の実施の形態に従う、メモリ中におけるクラス階層の代表例を示す説明図。
【図１】
0005129904.tif 000002
【図２】
0005129904.tif 000003
【図３】
0005129904.tif 000004
【図４】
0005129904.tif 000005
【図５】
0005129904.tif 000006
【図６】
0005129904.tif 000007
【図７】
0005129904.tif 000008
【図８】
0005129904.tif 000009