JP2010170585A - ディスパッチテーブル構造のための方法と装置 - Google Patents

Abstract

【課題】ディスパッチテーブルを構造化するための装置及びコンピュータプログラムプロダクト。
【解決手段】本発明の一実施の形態では、新規ディスパッチテーブルを割り当てるための判断はクラスのアクセス可能性に左右される。ディスパッチテーブル及びディスパッチテーブル構造プロセスは、Vtableのためのエントリが、アクセス可能性とクラス階層との間の競合を回避するように判定される、と説明されている。特に、ディスパッチテーブル及びディスパッチテーブル構造プロセスは、メソッドのアクセス可能性とパッケージ状態を、適切にオーバーライドしている意味規定とテーブル構築技術の判定において考慮する、と説明されている。ディスパッチテーブルはメソッドのための複数の明確なエントリを有していてもよい。
【選択図】図４

Description

本発明は一般に、コンピュータソフトウェア及びソフトウェア移植性の分野に関する。特に、構造ディスパッチテーブルに関する。

以下の説明を容易にするため、従来のオブジェクト指向のコンピューティング環境の簡単な概略を述べる。オブジェクト指向のコンピューティング環境では、オブジェクトは変数及び関連メソッドのソフトウェアバンドルを参照する。オブジェクトは、その状態（即ちオブジェクトが知っているもの）を変数内に維持しており、その振るまい（即ちオブジェクトが行うことができるもの）をメソッド内に実装している。メッセージは、ソフトウェアオブジェクトが互いに影響し合い、交信する手段である。集合的に、変数とメソッドは、メンバと称してもよい。また、オブジェクト用の変数とメソッドは、インスタンス変数とインスタンスメソッドと称する。

普通、クラス変数とクラスメソッドは、クラスに属するものとして定義されるそれらの変数とメソッドである。クラスは、特定種類のすべてのオブジェクトに共通な変数とメソッドを定義する再使用可能な青写真と説明することもできる。インスタンスは、クラスに属するオブジェクトであって、メモリがクラス内のインスタンス変数に割り当てられるオブジェクトである。

クラスは、クラス階層内、又は継承ツリー内に編成されてもよく、より下の階層にクラスが現れるのであれば、それはより一層特化されたものである。図１は、特定のクラス階層１００を表すブロック図である。クラス階層１００は、変数１０４とメソッド１０６を含むクラスＡ１０２を含む。図示した実施例では、クラスＡは、メソッドＭを含む複数の関連メソッドを有している。クラス階層は更に、クラスＡからの継承であるクラスＢ１１０と、全てクラスＢ１１０からの継承であるクラスＣ、Ｄ及びＥ（それぞれ１１２、１１４及び１１６）を含む。各サブクラスも、変数１０４とメソッド１０６を含む。

スーパークラスは、クラスの直系の祖先と同様にその先祖のクラスのすべてを参照する。「直系の」スーパークラスは、直属の親スーパークラスとクラス階層内の代替先祖スーパークラスを区別する。サブクラスは、スーパークラスによって提供された共有エレメントの基盤から離れて、特化された振るまいを提供する。これを行うために、各サブクラスは、スーパークラスから変数とメソッドを継承する。加えて、サブクラスは、それらがスーパークラスから継承するものに変数とメソッドを加えることができる。例えば、クラスＢ１１０は、メソッドＭ１０８を含むそのスーパークラス（クラスＡ１０２）内で定義されるアクセス可能なメソッドを継承する。クラスＢはまた、図示実施の形態において１０９の、メソッドＮを含むそれ自身の新規メソッドを定義してもよい。サブクラスはまた、その継承されたメソッドの一つ以上をオーバーライドし、それらメソッドのために特化した実装を備えることができる点に注意することが重要である。

言語が、クラスに単一のスーパークラスからの継承を許容する場合、それは、単一継承を有すると言われている。それに対し、言語が、クラスに複数のスーパークラスからの継承を許容する場合、それは、多重継承を有すると言われている。図１に示すクラス階層では、各サブクラスがただ一つの直系スーパークラスから継承するので、単一継承がある。

幾つかの言語では、スーパークラスは、継承の実施を介して繰り返し用いられてもよい。一般に、サブクラスは、サブクラスが明示的にメソッドをオーバーライドしない限り、サブクラスにアクセス可能なスーパークラスからのメソッドのすべてをそのまま継承する。アクセス可能性は、スーパークラスメンバのアクセス可能性宣言とサブクラスメンバのアクセス可能性宣言の組み合わせによって判定される。

アクセス可能性は、ソースコードの無制限の共有から機密の特定形式まで変動範囲を促進するよう区別される。２つの従来のタイプのアクセス可能性レベルは、パブリックとプライベートである。パブリックメンバは、他の何れのクラスによっても見られるか、又はアクセスされ得る。プライベートメンバは、それ自身のクラスによってのみアクセスされ得る。特定の言語は、追加のアクセス可能性の型を用いるであろう。例えば、Ｃ＋＋は、プロテクテッドメンバが一般にそのサブクラスによってのみアクセスされ得るプロテクテッドアクセス可能性を用いる。加えて、Ｊａｖａは、パッケージプライベートメンバが特定パッケージ内のクラスによってのみアクセスされ得るパッケージプライベートアクセス可能性を用いる。パッケージは、パッケージのすべてのエレメントに対するアクセス保護及びネームスペース管理を提供する関連クラスのコレクション及びインターフェースである。クラスは、パッケージへとグループ化されて、クラスの検索と使用を容易にし、名前の競合を回避し、アクセスを制御するようにしてもよい。

一般に、メッセージのアクセス可能性は、メンバ宣言によって特定される。何のアクセス可能性も最初に提供されない場合、デフォルトのアクセス可能性が用いられるであろう。例えば、Ｊａｖａパッケージの内部では、アクセス可能性が初期に特定されていないメンバのためのデフォルトのアクセス可能性は、プライベートのパッケージになる。

図２は、クラス階層を説明するブロック図であり、ここで、階層内の各クラスは、ローカル的にメソッド「foo」を定義している。特に、クラスＡ２０２は、パッケージＰ１に属し、未特定のアクセス可能性を有するメソッド「Ａ．ｆｏｏ」２０４を含んでいる。この場合、メソッドＡ．ｆｏｏ２０４は、パッケージＰ１に関してパッケージプライベートアクセス可能性にデフォルト設定される。同様に、クラスＢ２０６は、パッケージＰ２に属し、パブリックなアクセス可能性を有するメソッド「Ｂ．ｆｏｏ」２０８を含む。クラスＣ２１０は、パッケージＰ１に属し、パブリックアクセス可能性を有するメソッド「Ｃ．ｆｏｏ」２１２を含んでいる。メソッド２０４、２０８及び２１２全ては、メソッド「ｆｏｏ」を実装するが、３つの間で異なるのは、それらそれぞれのクラス、パッケージ、ソースコード及びアクセス可能性である。この差はメソッドの振るまいに悪影響を及ぼすかもしれず、例えば、メソッドが、printステートメントのためのソースコードを呼び出して、メソッドのクラスを公表する場合、３つのメソッドは、図示の通り異なった出力を有する。

従来は、すべてのクラス及びインターフェースは、それがローカルに定義するすべてのメソッドを含むメソッドテーブルを有している。加えて、すべてのクラスは、継承メソッドを含むクラスによって呼び出され得るすべての外部アクセス可能なメソッドのためのエントリを有するディスパッチテーブル、即ちVtableを有する。普通プライベートメソッドは、Vtable内に含まれる注記である。従来のVtable構造では、すべての外部アクセス可能なメソッドは、メソッドに対応するコードの１セクションを指す単一のVtableエントリと関連する。従って、すべてのVtableエントリは、それが対応するメソッドにおいて、ローカルであるのか、継承されるのかを、指し返す。

図３は、図２のクラスＢ２０６に対応するVtable３００の従来のフォーマットを示すブロック図である。Vtable３００は、直系のスーパークラス（クラスＡ２０２）から継承されるメソッドに対応するすべてのエントリを含むスーパークラス部３０２と、クラスＢ２０６においてローカルに定義されるメソッドに対応するエントリを含むクラス部３０４とを含む。クラス部３０４内で見出されるローカル定義のメソッドは、クラスＢ２０６にとって新規なものである。例えば、クラスＡ２０２からのメソッドに対応するエントリを上書きしなかった新規エントリ３０６はクラス部３０４内に加えられ、従って、Vtable３００のサイズが増加する。あるいは、対応するスーパークラスのメソッドをオーバーライドするローカル定義のメソッドは、スーパークラス部３０２内の既存のVtableエントリを上書きする。例えば、Ｂ．ｆｏｏのためのコードを指すVtable３００のエントリ３０８は、Vtable３００のスーパークラス部内の対応するエントリを上書きして、ローカル定義メソッドＣ．ｆｏｏのためのコードを指す。

Ｊａｖａプログラミング言語は、単一継承の使用を考慮している。Ｊａｖａでは、サブクラスは、そのスーパークラスと祖先のアクセス可能なメンバのすべてを継承するよう定義されており、これらメンバのそのまま使用、それらの隠蔽、又はそれらのオーバーライド可能である。サブクラスは、パブリック又はプロテクテッドとして宣言されるそれらのスーパークラスメンバを継承する。加えて、サブクラスは、サブクラスがスーパークラスと同じパッケージ内にある（即ち、それらの両方とも、プライベートのパッケージにデフォルト設定されている）限り、アクセス指定されないで宣言されているスーパークラスのメンバを継承する。従って、Ｊａｖａは、無制限のソースコードの共有から制御可能なレベルの機密まで、アクセス可能性の変動範囲を柔軟に提供する。継承に対する正反対の体系に基づく従来のVtable構造は、このアクセス可能性の変動範囲を許可しない。

上記を鑑みて、改良されたディスパッチテーブル構造技法が望ましいということは明白となろう。

本発明によれば、方法、装置及びコンピュータプログラムプロダクトが、ディスパッチテーブルを構成するために開示される。本発明の実施の形態では、新規ディスパッチテーブルエントリを割り当てる判定はアクセス可能性に左右される。別の実施の形態では、Vtableは、Vtable内のメソッドが複数のエントリを持って提供される。

本発明は、一実施の形態に従って、単一のスーパークラスから継承するクラス内のメソッドのためのディスパッチテーブルの構築プロセスに関する。プロセスは、スーパークラス用のディスパッチテーブルのコピーを含む。プロセスはまた、クラスにおいて選択されるメソッドがクラスの先祖スーパークラス内にも存在するかどうかの判定を含む。更に、プロセスは、第１のクラスが継承する先祖スーパークラスにおいても選択メソッドが存在するのかが判定される際に、選択されるメソッドの選択されるスーパークラスバージョンがアクセス可能であるかどうかを判定することを含む。プロセスは加えて、選択メソッドの選択スーパークラスバージョンがアクセス可能でないと判定されるときに、第１のクラスにおける選択メソッドのためのディスパッチテーブル内に新規エントリを作成することを含む。プロセスはまた、第１のクラスにおける選択メソッドがアクセス可能である判定されるときに、エントリを上書きすることを含む。メソッドのスーパークラスバージョンが存在しない場合には、メソッドのための新規エントリが作成される。

別の実施の形態では、本発明は、先祖階層内の直系スーパークラスから継承するクラス内のメソッドのためのディスパッチテーブルを構築するプロセスに関する。プロセスは、ディスパッチテーブルをスーパークラスからコピーすることを含む。プロセスはまた、クラスにおける選択メソッド及びアクセス可能性が、先祖階層のスーパークラス内に存在するかどうかを判定することを含む。プロセスは更に、インデックスをディスパッチテーブルのエントリに割り当てることを含む。

更に別の実施の形態では、本発明は、少なくとも一つのスーパークラスから継承するクラス用のディスパッチテーブルに関し、ディスパッチテーブルが、特定メソッドのための複数のエントリを含む。

本発明は、添付図面に関連して行われる以下の説明を参照することによってより良く理解されるであろう、

クラス階層の代表的な形式を説明するブロック図である。 各それぞれのクラスにおいて別々に定義される特定メソッドfooを含むクラス階層を説明するブロック図である。 図２のクラスＢに対応するVtableの従来のフォーマットを示す。 本発明の一実施の形態に従う図２のクラスに対応する簡略化されたVtableのセットである。 本発明の他の実施の形態に従う図２のクラスＣに対応する簡略化されたVtableである。 本発明の他の実施の形態に従う図４のクラスＣから継承するクラスＤのための簡略化されたVtableである。 （ａ）は、Ｊａｖａソースコードを含むＪａｖａ（登録商標）プログラムの特定のプラットホーム又はコンピュータ上で実行されるネイティブコードへの変換を示すブロック／プロセス図であり、（ｂ）は、下で説明する図１８のコンピュータシステムによってサポートされる仮想マシンの線図である。 本発明の一実施の形態に従うディスパッチテーブル構造プロセスを示す。 図８のステップ８０４で参照されるようなパブリック／プロテクテッドプロトコルに従って、メソッドＭを編成するためのプロセスを説明するブロック図を示す。 エントリ内のメソッドのためのソースコードへ適切なポインタを挿入するためのプロセスを説明するブロック図を示す。 図８のステップ８０８で参照されるようなパッケージプライベートプロトコルに従って、メソッドＭを編成するためのプロセスを説明するブロック図を示す。 図８のステップ８１０で参照されるようなプライベートプロトコル（８１０）に従って、メソッドＭを編成するためのプロセスを説明するブロック図を示す。 図８のステップ８１４で参照されるようなミランダメソッドプロトコルに従って、ディスパッチテーブル内にエントリを割り当てるためのプロセスを説明するブロック図を示す。 本発明の好ましい実施の形態に従って、ルックアップ量を低減させる好ましいディスパッチテーブル構造プロセスを説明するブロック図を示す。 図１４のステップ１４０４で参照されるような、ルックアップが先祖階層を通して行われる際に、アクセス可能性インデックスを割り当て、テーブルサイズを増加させるためのプロセスを説明するブロック図を示す。 先祖階層を通したルックアップの後、Vtable内にインデックスを作成するためのプロセスを説明するブロック図を示す。 本発明の一実施の形態に従うVtableを示す。 本発明の実施の形態の実装に適切な代表的なコンピュータシステムのブロック図である。

本発明の特定実施の形態を詳細に参照する。本実施形態の実施例を添付図面に示す。本発明を特定実施の形態に関連して説明する一方で、それが本発明を一実施の形態に制限することを目的としないことは理解されたい。逆に、それは、添付請求項に記載の本発明の精神及び適用範囲に含まれるであろうような、代替、変更及び同等物をカバーすることを目的とする。

ディスパッチテーブル及びディスパッチテーブル構造プロセスは、Vtable用のエントリが、アクセス可能性とクラス階層との間の競合が回避されるように判定される、と説明される。特に、ディスパッチテーブル及びディスパッチテーブル構造プロセスは、メソッドのアクセス可能性を、適切にオーバーライドしている意味規定とテーブル構造とを判定することにおいて考慮する、と説明される。ディスパッチテーブルは、メソッドのための複数の明確なエントリを有していてもよい。メソッドの不適当な処理を回避するために、オーバーライドするエントリを、判定しなければならない。場合によっては、たとえメソッドがスーパークラスメソッドをオーバーライドするとしても、新規のVtableエントリは生成されなければならない。

記載のＪａｖａ実施の形態では、４つの明確なアクセス可能性の指定が提供されている。これに応じて、スーパークラス階層の少なくとも一部への多重検索は各指定に対して実行されてもよい。すべてのアクセス可能性がスーパークラス内で見つかると、先祖階層への検索は終了する。また、クラスがスーパーインターフェースから継承するであろう際に、クラス階層とアクセス可能性との間で直面する意味的インタラクションは、インターフェース階層内で生じる。

加えて、Vtable内の特定メソッドのための各多重エントリは、クラス内の特定メソッドのための優先度を割り当てられてもよい。普通、メソッドのアクセス可能性と同じアクセス可能性指定を含むエントリは、一次エントリとして割り当てられる。一次エントリは普通、特定メソッドが宣言されるときに呼び出される。加えて、二次及び三次エントリもまた、異なるアクセス可能性指定に対応する特定メソッドのためのVtable内に存在していてもよい。

一般に、新規Vtableエントリを割り当てる判定は、メソッドのアクセス可能性に左右される。それはまた、オーバーライドされるメソッドのアクセス可能性に依存してもよい。例えば、パブリック又はプロテクテッドメソッドは、何れのパブリックかプロテクテッドメソッドがオーバーライドされない場合にのみ新規Vtableエントリを必要とする。そうでなければ、オーバーライドされるパブリック／プロテクテッドメソッドのVtableインデックスが用いられる。同様に、同じパッケージからのパッケージプライベートメソッドが何れもオーバーライドされない場合にのみ、パッケージプライベートメソッドは新規Vtableエントリを必要とする。プライベートエントリは、常に新規Vtableエントリを必要とする。従って、新規で且つオーバーライドされたメソッドのためのVtableエントリの更新プロセスは、すべてが適切に設定されなければならない３つのVtableエントリをメソッドが用いてもよいという点で、ケース依存性である。

本発明の一実施の形態に従うVtable構造のための規則を、それぞれ図２のクラスＡ２０２、クラスＢ２０６及びクラスＣ２１０のための簡略化されたVtable４０２、４０４及び４０６を図示する図４を参照して説明する。普通、各Vtableは、各Vtable内の部分４０８、４１０及び４１２のそれぞれによって表される多くの継承エントリを含む。図２に示すように、この図の目的上、クラスＡ、Ｂ及びＣがそれぞれローカルにメソッド「ｆｏｏ」を定義すると仮定する。クラスＡはパッケージＰ１に属し、メソッドＡ．ｆｏｏはプライベートのパッケージとして定義される。クラスＢはパッケージＰ２に属し、メソッドＢ．ｆｏｏはパブリックである。クラスＣは（クラスＡと同様に）パッケージＰ１に属し、メソッドＣ．ｆｏｏはパブリックである。

クラスＡ、Ｂ及びＣに対応するVtableの構造では、ローカルに定義された「ｆｏｏ」メソッドが新規Vtableエントリを必要とするかどうか、又は、それがVtableのスーパークラス部において一つ以上の対応エントリを上書きすることを必要とするかどうかを判定しなければならない。この判定は、メソッド「ｆｏｏ」のスーパークラスバージョンがクラスに対してアクセス可能かどうかに基づいて、簡単に行われる。アクセス可能であるメソッドのバージョンに対応する何れのVtableエントリも上書きされる。メソッド「ｆｏｏ」に対応するスーパークラスエントリの何れもクラスに対してアクセス可能であるメソッドに対応しない場合、新規Vtableエントリが作成される。

例として、クラスＢのためのVtableの構造を熟考する。第１に、そのスーパークラス（この場合では、クラスＡ）のVtableがコピーされる。クラスＢは、ローカルにメソッドＢ．ｆｏｏを定義しているので、判定はＡ．ｆｏｏ用のVtableエントリに上書きするべきであるか又はVtableに新規エントリを行うべきかどうかに関しては行われなければならない。上で指摘したように、クラスＡ２０２のメソッド２０４はパッケージＰ１に関してプライベートのパッケージであり、従って、クラスＢ２０６のメソッド２０８はアクセスできず、何故なら、クラスＢは、（パッケージＰ１とは対照的に）パッケージＰ２内にあるためである。従って、クラスＢ２０６のメソッド２０８に対応する新規エントリ４１４は、クラスＢ４０４のためのVtable内に備えられる。従って、クラスＢのためのVtableは、ここで、「ｆｏｏ」メソッドに対応する２つのエントリを有する。第１のエントリは、メソッドＡ．ｆｏｏに対応するオリジナルエントリ４１６である。第２のエントリは、Ｂ．ｆｏｏに対応する新規エントリ４１４である。即ち、Ｂ．ｆｏｏに対応する新規エントリ４１４はVtable４０４に加えられる。この編成を用いて、メソッド「ｆｏｏ」がクラスＢのインスタンスに呼び出される時、クラスＢ４０４のインスタンスのためのVtableは、クラスＢ２０６のための適切なメソッド２０８に対応するＢ．ｆｏｏエントリ４１４を返す。

次に、クラスＣのためのVtableの構造を熟考する。前記のように、クラスＣ２１０は、その直系のスーパークラス、即ちクラスＢ２０６のすべてのメソッドを継承する。従って、クラスＣのためのVtableは、前もって判定されたエントリ４１４及び４１６を含むその直系のスーパークラス（この場合では、クラスＢ４０４）のVtableからのすべてのエントリを含む。図示のサンプルでは、クラスＣは、パッケージＰ１の一部であり（クラスＡと同様ではあるが、クラスＢと同様ではない）、また、ローカルに「ｆｏｏ」メソッド（本明細書中では、Ｃ．ｆｏｏと称する）を定義する。先に言及したように、クラスＣがアクセス可能なメソッド「ｆｏｏ」のいかなる既存のバージョンもオーバーライドされ、アクセスできないメソッド「ｆｏｏ」のいかなる既存のバージョンもオーバーライドされ得ない。この場合では、クラスＢ２０６のメソッド２０８はパブリックであり、クラスＣ２１０のメソッド２１２からアクセスできる。従って、クラスＣのためのVtable４０６では、クラスＢ２０６のメソッド２０８に対応するエントリ４２０はＣ．ｆｏｏを参照するよう上書きされる。加えて、クラスＡ２０２のメソッド２０４はパッケージＰ１に関してプライベートのパッケージであり、また両クラスＡ及びＣが同じパッケージ（パッケージＰ１）内部にあるので、クラスＣ２１０からアクセス可能である。従って、クラスＣのためのVtable４０６では、クラスＡ２０２のメソッド２０４に対応するエントリ４１８はＣ．ｆｏｏを参照するように上書きされる。従って、Ｃ．ｆｏｏは同じVtableにおいて二度参照される。この編成を用いて、メソッド「ｆｏｏ」がクラスＣのインスタンスに呼び出される時、インスタンスのためのVtableはＣ．ｆｏｏエントリを返す。

次いで、図５を参照して第２の実施例を説明する。この実施例では、クラスＣが（図４の実施例におけるようなパッケージＰ１よりはむしろ）第３のパッケージであるパッケージＰ３の一部として定義される点を除いて、図２のクラス階層及びメソッドアクセス可能性はそのまま維持される。このクラスＣに対応するVtableの構造では、クラスＢ２１０のメソッド２０８はクラスＣがアクセス可能なまま保たれる。従って、メソッドＢ．ｆｏｏに対応するVtableエントリは、（前の場合と同様に）Ｃ．ｆｏｏに対応するエントリ５０４によって上書きされる。しかし、メソッドＡ．ｆｏｏはパッケージＰ１に関してプライベートのパッケージであり、パッケージＰ３の一部であるクラスＣはアクセスできない。従って、エントリ５０２はクラスＣのためのVtable５００において上書きされない。

オブジェクト指向型言語内で共通に見出される注目すべき別の規則は、公開度を設定した後でメソッドの公開度を下げることができない、すなわち、アクセス可能性を下げることができないということである。このように、サブクラスはそのスーパークラスが求められる箇所で常に用いることができる。すなわち、継承されたパブリックのメソッドはプライベートメソッドに変換することができない。

図６は、プライベートであって、パッケージＰ１に属するクラスＣ２１０のサブクラス、Ｄ、のためのVtable６００の構築の実施例を示す図である。クラスＤのためのVtable６００は、その直系のスーパークラス、即ち図２のクラスＣ２１０のすべてのメソッドを継承する。従って、それは、その直系のスーパークラスのすべてのエントリを含み、この場合では、図４のクラスＣ２１０のためのVtable４０６である。クラスＤのためのVtable６００の構築は、前述したVtableの構築と同様に行われる。クラスＣのメソッド２１２はパブリックであり、クラスＤはアクセス可能である。従って、エントリ６０６は、それがメソッドＤ．ｆｏｏを参照するように上書きされる。更に、クラスＡ２０２のメソッド２０４はパッケージＰ１に関してプライベートのパッケージであり、パッケージＰ１に属するクラスＤのメソッドはアクセス可能である。このメソッドは、エントリ６０４内に存在して、同様にオーバーライドされる。最終的に、インスタンスＤ内でローカルに定義されるメソッド「ｆｏｏ」（即ちＤ．ｆｏｏ）はプライベートであり、新規エントリ６０８はそのエントリを反映するよう作成される。従って、３個のエントリはこのとき同一メソッド「ｆｏｏ」のためのVtable６００内に存在する。改良されたVtable６００を作成するためのプロセスを、図８から図１３のそれぞれについて以下にある程度詳細に説明する。

クラス及びスーパークラス階層と同様に、独立インターフェース階層もまた存在する。一般に、インターフェースは、おそらく無関係なオブジェクトが互いに相互作用するために用いるメカニズムである。オブジェクト指向型言語においてこれを行うために、インターフェースは１セットのメソッドシグニチャを含んでいる。普通、メソッドシグニチャと関連するコードは存在しない。インターフェースを実装するクラスは、インターフェースにおいて定義されるメソッドのすべてを実装することを承認し、これにより特定の振るまいを承認する。

抽象クラスは一般的な振るまいを定義し、部分的にこれらのメソッドを実装できるが、そのクラスの多くは定義及び実装されない。この不満足の指定によって、単独実装は特化サブクラスのための詳細（即ち、コード）を完全にすることができる。抽象クラスは、コンパイラが認識するその状態を特定する宣言を含んでいてもよい。インターフェースが実装され、クラスが抽象である場合、コンパイラはインターフェースからの未特定メソッドの継承を許容する。しかし、クラスが抽象クラスでない場合、コンパイラは未特定メソッドで満たされていることを示す。クラス又はそのスーパークラスの何れかにおけるそれらの定義において完全ではないスーパーインターフェースから継承されるこれらのメソッドは、「ミランダメソッド」と称される。

これらのミランダメソッドもまた、まるでそれらがクラス内で宣言されたかのように、エントリを必要とする。クラスがスーパーインターフェースから幾分同様に継承できるように、クラス階層とアクセス可能性との間に直面する意味的インタラクションもまた、インターフェース階層内部に生じるであろう。インターフェース階層の場合に注目すべき差は、インターフェースメソッドが一般に常にパブリックであるという点である。しかし、クラスが単一継承階層内の一つのスーパークラスだけを有する一方で、それは、相当システムの複雑さを増す多重スーパーインターフェースを有するであろう。

呼び出された場合、対応コードを持たないメソッドを呼び出すためのエラーメッセージを発行しなければならない抽象メソッドを処理するために、スタブポインタは、メソッドコードに対するポインタの代わりに用いられる。このスタブは、例外を引き起こすコードを指す。スタブポインタは、抽象メソッドが共通であるため適所になければならず、独立したデザイナが抽象クラスに関してコード設計できるようにし、従って、対応サブクラスの間の共通の振るまいを管理する。

特定の実施の形態では、ミランダメソッドはクラスのVtableにおいて定義されるが、いかなるクラスのメソッドテーブルにおいても出現しない。Vtableの構築のために、ミランダメソッドはクラスによって宣言されないので、それらは別々に処理されなければならない。本発明の実施の形態では、別々のVtableエントリはミランダメソッドを備える。

アクセス可能性構造及びソースコードの継承を用いるいかなるソフトウェア言語も、本発明を実装することができる。本発明の特定の実施形態では、ディスパッチテーブル構造におけるＪＡＶＡの意味規定により本発明が実装される。

図７（ａ）は、本発明の一実施の形態に従う、Ｊａｖａソースコードからネイティブ命令を作成することに関わる入力／出力及び実行ソフトウェア／システムを示すブロック図である。他の実施の形態では、本発明は、他言語用の仮想マシンを用いて、又はＪａｖａクラスファイル以外のクラスファイルを用いて実装できる。線図の左側から開始すると、第１の入力は、カリフォルニア州マウンテンビューのサンマイクロシステムズによって開発されたＪａｖａ（商標）プログラミング言語で書かれたＪａｖａソースコード７０１である。Ｊａｖａソースコード７０１は、バイトコードコンパイラ７０３に対する入力である。バイトコードコンパイラ７０３は本質的に、ソースコード７０１をバイトコードにコンパイルするプログラムである。バイトコードは、一つ以上のＪａｖａクラスファイル７０５に含まれている。Ｊａｖａクラスファイル７０５は、Ｊａｖａ仮想マシン（ＪＶＭ）を有するいかなるコンピュータ上でも実行可能という点で、ポータブルである。仮想マシンの構成要素を図７（ｂ）で更に詳細に示す。Ｊａｖａクラスファイル７０５は、ＪＶＭ７０７に対する入力である。ＪＶＭ７０７はいかなるコンピュータ上にもあることができ、従って、バイトコードコンパイラ７０３を有する同一のコンピュータ上にある必要はない。ＪＶＭ７０７は、インタプリタ又はコンパイラ等、幾つかの役割のうちの一つで動作できる。それがコンパイラとして動作する場合、それは更に、"just in time"（ＪＩＴ）コンパイラとして、即ち適応コンパイラとして動作できる。インタプリタの働きをする時、ＪＶＭ７０７はＪａｖａクラスファイル７０５に含まれる各バイトコード命令を解釈する。

図７（ｂ）は、下で説明する図１８のコンピュータシステム１８００によってサポートされ得るＪＶＭ７０７等の仮想マシン７１１の線図である。前記のように、コンピュータプログラム、例えばＪａｖａ（商標）プログラミング言語で書かれたプログラムが、ソースからバイトコードへ変換される場合、ソースコード７０１は、コンパイル時環境７０９内部でバイトコードコンパイラ７０３に提供される。バイトコードコンパイラ７０３は、ソースコード７０１をバイトコード７０５に変換する。一般に、ソースコード７０１は、ソースコード７０１がソフトウェア開発者によって作成された後で、バイトコード７０５に変換される。

バイトコード７０５は一般に、複製されてダウンロードされるか、そうでなければ、ネットワークを介して、例えば図１８のネットワークインターフェース１８２４を介して配布されるか、又は図１８の一次記憶装置１８０４等の記憶装置に格納することができる。記載の実施の形態では、バイトコード７０３はプラットホームに依存しない。即ち、バイトコード７０３は適切な仮想マシン７１１を実行している実質的にいかなるコンピュータシステム上でも実行されるであろう。バイトコードのコンパイルによって形成されるネイティブ命令はＪＶＭによるその後の使用のために保持されてもよい。このような方法で、変換コストは、多重実行上で清算されて、解釈されたコード上のネイティブコードに対し有利な速度を提供する。例えば、Ｊａｖａ（登録商標）環境ではバイトコード７０５はＪＶＭを実行しているコンピュータシステム上で実行され得る。

バイトコード７０５は、仮想マシン７１１を含む実行時環境７１３に提供される。実行時環境７１３は一般に、図１８のＣＰＵ１００２等のプロセッサを用いて実行され得る。仮想マシン７１１は、コンパイラ７１５、インタプリタ７１７、及び実行時システム７１９を含む。バイトコード７０５は一般に、コンパイラ７１５又はインタプリタ７１７の何れかに対して提供され得る。

バイトコード７０５がコンパイラ７１５に提供される時、バイトコード７０５に含まれているメソッドはネイティブ機械命令（図示せず）にコンパイルされる。一方で、バイトコード７０５がインタプリタ７１７に提供される時、バイトコード７０５は一度に一つのバイトコードずつインタプリタ７１７に読み込まれる。次いで、インタプリタ７１７は、各バイトコードがインタプリタ７１７に読み込まれる際に、各バイトコードによって定義される操作を実行する。一般に、インタプリタ７１７はバイトコード７０５を処理し、実質的に連続してバイトコード７０５と関連する操作を実行する。

メソッドがオペレーティングシステム７２１から呼び出される時、そのメソッドが解釈されたメソッドとして呼び出されるものであると判定されると、実行時システム７１９はインタプリタ７１７からメソッドを得ることができる。一方で、メソッドがコンパイルされたメソッドとして呼び出されるものであると判定されると、実行時システム７１９はコンパイラ７１５を起動させる。次いで、コンパイラ７１５はバイトコード７０５からのネイティブ機械命令を生成し機械語命令を実行する。一般に、機械語命令は仮想マシン７１１が終了する際に破棄される。仮想マシンの操作、すなわち、より詳しくはＪａｖａ（商標）仮想マシンの操作は、Tim Lindholm及びFrank Yellin著のThe Java ^TM VirtualMachine Specification、第２版(ISBN 0-201-43294-3)により詳細に記載されており、本明細書ではそのすべてを引用して組み込む。

図８から図１３は、本発明の一実施の形態に従うディスパッチテーブル構造プロセス８００を示す。ディスパッチテーブルは直系のスーパークラスＳを有するパッケージＰ内のクラスＣのために構築される。ディスパッチテーブル構造プロセス８００はまた、Vtableのサイズを計算し、不揮発性メモリの最適サイズに設定した部分にそのVtableを割り当てて書き込む。

ディスパッチテーブル構造プロセス８００は、クラスＣ（図８）内のローカル定義のメソッドのすべてを通して繰り返すことから始める。それに応じて、現行の反復のメソッドはメソッドＭと呼ばれる。ディスパッチテーブルを構築するためのアクセス可能性を区別するために、判定されるアクセス可能性の３つのグループは、パブリック／プロテクテッド、プライベート、及びプライベートパッケージである。パブリック及びプロテクテッドは、ディスパッチテーブルの構築におけるそれらの振るまいが実質的に類似しているため、図８の場合では共にグループ化される。

ディスパッチテーブル構造プロセス８００は、メソッドＭがパブリックかプロテクテッドかの判定（８０２）から始める。それがパブリックかプロテクテッドであれば、プロセスは、パブリック／プロテクテッドプロトコルに従うメソッドＭを編成する手続きを行い（８０４）、これを図９に関して以下に詳細に記載する。そうでなければ、プロセスは、メソッドＭがプライベートパッケージであるかどうかを判定する（８０６）。それが、プライベートパッケージであれば、プロセスは、パッケージプライベートプロトコルに従うメソッドＭを編成する手続きを行い（８０８）、これを図１１に関して以下に詳細に記載する。そうでなければ、メソッドＭは、プライベートのアクセス可能性にデフォルト設定され、プライベートプロトコルに従って編成されるが（８１０）、これについては図１２を用いて以下に詳細に記載する。上記の場合の何れでも、メソッドＭが適切な方法に従って編成される時、プロセスは次いで、何れか未処理のメソッドが存在するのかを判定し（８１２）、次のメソッドのために開始まで戻る。すべてのメソッドが処理された後で、追加ステップは、何れかのミランダメソッドの処理が必要であれば取られるが（８１４）、これについては図１３を用いて以下に詳細に記載する。

図９は、パブリック／プロテクテッドプロトコル（８０４）に従うディスパッチテーブルにおいてメソッドＭを編成するためのプロセスを示す。それは、直系のスーパークラスＳ、又は、スーパークラスＳのスーパークラス又はスーパーインターフェースの何れかにおいて宣言されたメソッドＭのパブリック又はプロテクテッドバージョンが存在するかどうかを判定することから開始する（９０２）。言い換えると、プロセスは、メソッドＭのバージョンが先祖階層内のどこかに存在するかどうかを判定する。メソッドＭのパブリック又はプロテクテッドバージョンが先祖階層内に存在しなければ、新規エントリがディスパッチテーブルに追加される（９０４）。それに応じて、プロセスは、メソッドＭに対する適切なポインタ（１０００）を新規に形成されるエントリに挿入し（９０６）、これを図１０に関して以下に詳細に記載する。メソッドＭのパブリック又はプロテクテッドバージョンがスーパークラス内に存在すれば、識別されたスーパークラスエントリは、クラスＣのディスパッチテーブルのための識別されたスーパークラスエントリに適切なポインタ（１０００）を挿入することによってオーバーライドされる（９０８）。

プロセス８０４はまた、先祖階層内にメソッドＭの（メソッドＭが対応するパッケージＰに対して）プライベートなアクセス可能なパッケージのバージョンがあるかどうかを判定する（９１０）。もし存在するならば、識別されたスーパークラスエントリは、アクセス可能なパッケージプライベートメソッドに対する適切なポインタ（１０００）を識別されたスーパークラスエントリに挿入することによってオーバーライドされる（９１２）。

図１０は、エントリ内のメソッドのためのソースコードへ適切なポインタを挿入するためのプロセスを説明するブロック図を示す（１０００）。メソッドＭが抽象メソッドであるかどうかを判定することから開始する（１００２）。メソッドが抽象メソッドでなければ、メソッドコードへのポインタは、ディスパッチテーブルの適切なエントリに挿入される（１００６）。これに対して、メソッドが抽象メソッドであれば、スタブポインタがディスパッチテーブルの適切なエントリに挿入される（１００６）。この時点での標準又はスタブのポインタの挿入は既存のエントリポインタから独立している、即ち、スタブポインタはメソッドコードへのポインタを上書きする能力があるということに注意することが重要である。

図１１は、図８に関して上記で検討されたパッケージプライベートプロトコル（８０８）に従ってメソッドＭを編成するためのプロセスを示す。それは、直系のスーパークラスＳ、又は、スーパークラスＳのスーパークラス又はスーパーインターフェースの何れかにおいて宣言されたメソッドＭのアクセス可能なパッケージプライベートバージョンが存在するかどうかを判定することから開始する（１１０２）。適切なパッケージのプライベート状態（この場合ではパッケージＰ）を有するメソッドＭが先祖階層内に存在しなければ、新規エントリはディスパッチテーブルに追加される（１１０４）。それに応じて、プロセスは、メソッドＭのパッケージプライベートバージョンに対する適切なポインタ（１０００）を新規に形成されるエントリに挿入する（１１０６）。メソッドＭのパッケージプライベートバージョンが先祖階層内に存在すれば、識別されたスーパークラスエントリは、適切なポインタ（１０００）を識別されたスーパークラスエントリに挿入することによってオーバーライドされる（１１０８）。

プロセス８０８はまた、直系のスーパークラスＳ、又は、スーパークラスＳのスーパークラス又はスーパーインターフェースの何れかにおけるメソッドＭのパブリック又はプロテクテッドバージョンが存在するかどうかを判定する（１１１０）。もし存在するならば、識別されたスーパークラスエントリは、メソッドＭの識別されたパブリック又はプロテクテッドバージョンに対する適切なポインタ（１０００）を識別されたスーパークラスエントリに挿入することによってオーバーライドされる（１１１２）。

図１２は、図８に関して上記で検討されたプライベートプロトコル（８１０）に従ってメソッドＭを編成するためのプロセスを示す。それは、プライベートエントリが普通は新規Vtableエントリを必要とするので、新規エントリをディスパッチテーブル（１２０２）に追加することを開始する。それに応じて、プロセスは、メソッドＭのプライベートバージョンに対する適切なポインタを新規に形成されるエントリに挿入する（１２０４）。この場合には、プライベートメソッドＭは抽象され得るので、抽象クラスのチェックは必要でない。

プロセス８１０はまた、直系のスーパークラスＳ、又は、スーパークラスＳのスーパークラス又はスーパーインターフェースの何れかにおけるメソッドＭのパブリック又はプロテクテッドバージョンが存在するかどうかを判定する（１２０６）。もし存在するならば、識別されたスーパークラスエントリは、適切なポインタ（１０００）を識別されたスーパークラスエントリに挿入することによってオーバーライドされる（１２０８）。

プロセス８１０はまた、直系のスーパークラスＳ、又は、スーパークラスＳのスーパークラスの何れかにおけるメソッドＭのパッケージプライベートバージョンが存在するかどうかを判定する（１２１０）。もし存在するならば、識別されたスーパークラスエントリは、適切なポインタ（１０００）を識別されたスーパークラスエントリに挿入することによってオーバーライドされる（１２１２）。

クラスＣ内のすべてのローカル定義メソッドがディスパッチテーブル構造プロセス８００において編成された後で、何れのミランダメソッドも処理されなければならない。図１３は、図８に関して上記で検討されたミランダメソッドプロトコル（８１４）に従うディスパッチテーブルにおいてエントリを割り当てるためのプロセスを示す図である。

ミランダメソッドプロトコル（８１４）は、クラスＣの何れか未処理のスーパーインターフェースが存在するかどうかを判定することから開始する（１３０２）。何れのクラスＣの未処理のスーパーインターフェースも存在していなければ、プロセス８１４は終了する。未処理のスーパーインターフェースが存在する場合、次のインターフェースＩが選択される（１３０４）。このインターフェースＩのため、プロセス８１４はインターフェースＩの各メソッドを通して繰り返される。何れのインターフェースＩの未処理のメソッドも存在していなければ、プロセスは、何れかのクラスＣの未処理のスーパーインターフェースが存在するかの判定まで戻る（１３０２）。そうでなければ、インターフェースＩの次のメソッドが検索され、チェックが実行されて、インターフェースＩの同一メソッドの同一バージョンが既にクラスＣのためのディスパッチテーブル内に存在しているかを判定する（１３１０）。インターフェースＩの同一メソッドのバージョンがディスパッチテーブル内に存在する場合、プロセスは、インターフェースＩの残りのメソッドを通して繰り返すよう続けられる（１３０６）。クラスＣのメソッドの同一バージョンが存在しない場合、新規エントリはクラスＣのためのディスパッチテーブルに作成される（１３１２）。ポインタは、ディスパッチテーブルの新規エントリに挿入され（１３１４）、プロセスは、インターフェースＩの残りのメソッドを通して繰り返すよう続けられる（１３０６）。

ディスパッチテーブルを構築するため、様々な手続きが実装されてもよい。例えば、従来のディスパッチテーブル構築プロセスは各ステップに対して僅かな変更を行って用いられてもよい。この従来のプロセスでは、ディスパッチテーブル内のスーパークラスのサイズは最初に判定される。この継承されたサイズから、クラスＣ内の各ローカル定義のメソッドには新規エントリが提供される。新規エントリは累積的に計数され、継承されたスーパークラスディスパッチテーブルのサイズに追加される。最終的に、いかなるミランダメソッドも、ディスパッチテーブルの完全な構造に処理されてもよい。

本発明が多重アクセス可能性指定を許可するように、スーパークラス及びスーパーインターフェース階層の少なくとも一部への別々の検索は各アクセス可能性に対して実行されてもよい。特定のアクセス可能性に対する先祖階層への検索は、それがスーパークラス内に見つかったときに中止するのが好ましい。

加えて、特定メソッドのための各多重エントリには優先度を割り当てられてもよい。普通、メソッドのアクセス可能性と同じアクセス可能性を有するエントリは一次エントリである。この一次優先度に対応するアクセス可能性がメソッド及びパッケージに基づいて変化しても良いように、優先度インデックスは、一次メソッドがパッケージに関係なく設定されることを可能にする。二次及び三次エントリは、他のアクセス可能性に対応する先祖階層内に見出される場合、追加として存在することができ、それに応じて、エントリに割り当てられてもよい。

実際には、メソッドが呼び出される時、一次インデックスだけが用いられる。従って、二次及び三次エントリに対応するインデックスは、ディスパッチテーブル内に割り当てられるたり恒久的に保持される必要はなく、実装によって定まる際に割り当てられるか又は恒久的に保持されてもよい。

単一メソッドに対する複数のエントリの間で相対的な優先度を設定するための正当性は、一次メソッドがリンクされる時、呼び出されたメソッドがエントリの構造において設定されたため、アクセスビリティから呼び出されたメソッドのアクセス可能性状態に関して曖昧性がまったくない。

優先度は、同一アクセス可能性を指定したエントリがクラスのために用いられることを可能にする一方で、他のアクセス可能性指定エントリを保持するためのニーズに左右される。従って、クラスのために呼び出される一次インデックスでなくてもよい新規ローカル定義エントリは、残りの階層に関するクラス内で適切に更新されてもよい。ローカル定義のプライベートメソッドは一般に、常に、そのメソッドのための一次エントリとして指定されてもよいVtable内の新規エントリを必要とする。しかし、スーパークラスから継承される他のアクセス可能なメソッド（即ち、パブリック）は、同一メソッドを持つ２つのエントリの曖昧性を回避するようオーバーライドされ、正しくインデックス付けされてもよい。

上記のプロセスは、明確なアクセス可能性レベルに関するメソッドのための多重エントリを割り当てるために適切である。しかし、ディスパッチテーブル構造プロセス８００は、各アクセス可能性のために先祖各自の階層を通しての冗長なルックアップを必要とする。

図１４から図１６は、本発明の他の実施の形態に従い、ルックアップ量を低減させる代替ディスパッチテーブル構造プロセス１４００を示す図である。それはまた同時に、ディスパッチテーブルのサイズを判定し、何のインデックスがVtable内の各メソッドと関連するかを判定する。一旦これが実行されると、プロセスは、Vtableを割り当て、適切なエントリを書き込む。再び、ディスパッチテーブルは、直系のスーパークラスＳを有するパッケージＰ内のクラスＣのために構築される。ディスパッチテーブル構造プロセス１４００は、Vtableのサイズを判定しながら、クラス及びインターフェース階層の一横断においてメソッドＭの各アクセス可能性のためのインデックスを判定するので、先の実施例とは異なる。

ディスパッチテーブル構造プロセス１４００（図１４）は、第１の近似では、スーパークラスのVtableのサイズであるVtableの初期サイズを推定することから開始する（１４０２）。ディスパッチテーブル構造プロセス１４００はまた、特定のアクセス可能性が先祖階層において見出されたかどうかの判定に用いられる少なくとも一つのインデックスを初期化する。

メソッドＭが先祖階層において見出されたどうかの判定に、一つのインデックスが用いられた前の場合とは対照的に、ディスパッチテーブル構造プロセス１４００は多重インデックスを用いる。例えば、メソッドに対するパブリックアクセス可能性と特に関連するアクセス可能性インデックスは、先祖階層をスキャンする間、パッケージプライベートアクセス可能性と特に関連するアクセス可能性インデックスから独立して維持されてもよい。加えて、いかなるアクセス可能性インデックスも、特定のメソッドが先祖階層において見出されなかったことを示すデフォルト値（例えば負の数）で開始してもよい。インデックスは次いで、対応するメソッドの位置を示す第２の値（正の数）に変更してもよい。

ルックアップが先祖階層を通して行われる際のアクセス可能性インデックスの割り当て（１４０４）とテーブルサイズの増加とを、図１４に関して上で検討したように図１５内に示す。プロセスはクラスＣ内の各ローカル定義メソッドＭのために繰り返される（１５０２）。すべてのローカル定義メソッドが処理されると、メソッドは好ましいディスパッチテーブル構造プロセス１４００へ戻る（１４０８）。次の未処理メソッドＭのため、対応メソッドＭを検索する先祖階層上への横断が実行される。これは、直系のスーパークラス５が存在するかどうかを判定することから開始する（１５０４）。

直系のスーパークラス５が存在する場合、ディスパッチテーブル構造プロセス１４００は、アクセス可能性インデックスの状態をチェックして、メソッドＭのすべての関連アクセス可能性が見出されたかを判定する。例えば、メソッドのパブリック／プロテクテッド及びパッケージプライベートバージョンに対応するアクセス可能性インデックスのすべてが先祖階層内のメソッドの存在を示すと（１５１２）、プロセスは検索された情報の割り当て（１５０６）へ進んでもよい。メソッドのパブリック、プライベート及びパッケージプライベートバージョンに対応するアクセス可能性インデックスのすべてが見つからなければ、好ましいプロセス１４００は階層を遡り続ける（１５０４）。

ディスパッチテーブル構造プロセス１４００は次いで、現在のスーパークラスＳがメソッドＭによってオーバーライドされるメソッドを含むかどうかを判定する（１５１４−１５２０）。もし、このようなメソッドが存在するならば、プロセス１４００は現在のスーパークラスＳで終了し、階層内に他のスーパークラスが存在するかの判定まで戻る（１５０４）。もしそれがメソッドＭによってオーバーライドされたメソッドを含むのであれば、メソッドのアクセス可能性を判定する必要がある。オーバーライドされたメソッドがパブリックかプロテクテッドであれば（１５１６）、メソッドに対する一次Vtableインデックスはパブリック／プロテクテッドインデックスに割り当てられる（１５１８）。これに対して、オーバーライドされたメソッドがプライベートであれば（１５２０）、メソッドに対する一次Vtableインデックスはパッケージプライベートインデックスに割り当てられる（１５２２）。何れにせよ、プロセス１４００は階層を遡り続ける（１５０４）。

すべてのメソッドＭのアクセス可能性のタイプが見出された場合、又は先祖階層を通してのルックアップが終了した場合、情報はVtableに割り当てられる（１５０６）。先祖階層を通してのルックアップ後のVtable１７００内へのインデックスの作成を図１６及び図１７に示す。Vtable１７００のためのインデックスの作成はメソッドＭのアクセス可能性に左右される。それに応じて、メソッドＭに対するインデックスを割り当てるプロセスは、最初にメソッドＭのアクセス可能性を判定する。

本実施の形態では、メソッドＭがパブリックかプロテクテッドかは最初に判定される（１６０２）。メソッドＭがパブリックかプロテクテッドである場合、アクセス可能性インデックスはチェックされて、メソッドＭのパブリックバージョンが先祖階層内で見出されたのかを判定する（１６０４）。パブリック又はプロテクテッドメソッドＭが先祖階層内で見出されたとすると、メソッドＭに割り当てられる一次Vtableインデックスは、スーパークラス内で見出されるパブリック／プロテクテッドアクセス可能性インデックス１７０２である（１６０６）。パブリック又はプロテクテッドメソッドＭが先祖階層内で見出されなければ、新規エントリ１７０４はVtable１７００内に作成され、メソッドＭに対する一次インデックスは新規エントリ１７０４に割り当てられ（１６０８）、現在のVtableサイズはVtableポインタ１７０６用いて増加させられる（１６１０）。従って、メソッドＭが先祖階層内に見出されたかどうかに関係なく、一次VtableインデックスはVtable１７００内に割り当てられる。

Vtableポインタ１７０６は次いで、Vtable１７００内の次のエントリ１７１０を指す。Vtableポインタ１７０６は、スーパークラスＳの継承メソッドに対応する推定サイズ及び位置で開始した。各新規エントリがクラスＣのローカル定義メソッドのために追加されるように、Vtableポインタ１７０６は、Vtable１７００のサイズを増加し保持する。

次いで、パッケージプライベートアクセス可能性インデックスが記録された場合、それは二次インデックスに割り当てられなければならない。割り当てられたインデックスは、Vtable１７００のスーパークラス部内の適切なエントリを上書きするために後で用いられる。

メソッドＭがプライベートパッケージである場合（１６１６）、アクセス可能性インデックスはチェックされて、メソッドＭが先祖階層内で見出されたかを判定する（１６１８）。パッケージプライベートメソッドＭが先祖階層内で見出されたとすると、メソッドＭに割り当てられる一次Vtableインデックスは、スーパークラス内で見出されるパッケージプライベートアクセス可能性インデックス１７０８である（１６２０）。パッケージプライベートメソッドＭが先祖階層内で見出されなければ、新規エントリ１７０４は依然としてVtable１７００内に作成され、メソッドＭに対する一次インデックスは新規エントリ１７０４に割り当てられ（１６２２）、現在のVtableサイズはVtableポインタ１７０６を用いて増加させられる。

また、パブリック／プロテクテッドインデックスが記録された場合、それは二次インデックスに割り当てられなければならない。割り当てられたインデックスは、Vtable１７００のスーパークラス部内の適切なエントリを上書きするために後で用いられる。

最終的に、好ましいプロセス１４００のために、メソッドＭがパブリック、プロテクテッド、又はプライベートパッケージでない場合、それはプライベートとしなければならない（１６１６）。ローカル定義メソッドが常に新規エントリを必要とするように、メソッドＭに対する新規エントリ１７０４はVtable１７００内に作成され、メソッドＭに対する一次インデックスは新規エントリ１７０４に割り当てられ（１６２２）、現在のVtableサイズはVtableポインタ１７０６用いて増加させられる。

次いで、パブリック／プロテクテッドアクセス可能性インデックスが記録された場合、それは二次インデックスに割り当てられなければならない。割り当てられたインデックスは次いで、Vtable１７００のスーパークラス部内の適切なエントリを上書きするために用いられる。同様に、パッケージプライベートインデックスが記録された場合、それは、三次インデックスに割り当てられなければならない。割り当てられたインデックスは次いで、Vtable１７００のスーパークラス部内の適切なエントリを上書きするために用いられる。

ローカル定義メソッドのすべてに対するインデックスの割当てが完了し、テーブルのサイズが決定された後（１４０４）、好ましいプロセス１４００は次いで、必要であれば、何れのミランダメソッドも処理する（１４０６）。Vtable１７００は次いで、メモリの適切な部分に割り当てられる（１４０８）。Vtable１７００は、最初にスーパークラスＳの内容によって満たされ（１４１０）、次いで各ローカル定義メソッドによって満たされる（１４１２）。

各ローカル定義メソッドＭのために、好ましいプロセス１４００は、ポインタを一次インデックスにおいて対応するメソッドソースコードに割り当てる（１４１４）。二次インデックスが割り当てられると（１４１６）、二次インデックスにおけるソースコードに対するポインタが割り当てられる（１４１８）。同様に、三次インデックスが割り当てられると（１４２０）、三次インデックスにおけるソースコードに対するポインタが割り当てられる（１４２２）。

サブクラスがミランダメソッドを実装する時、対応するVtableエントリは更新されなければならない。従って、何れかのミランダメソッドが上書きされたかは別々に判定されなければならない。これは、スーパークラスのVtableを通して検索することによって実行される。より詳細には、Vtableは低部から走査されて、現在のメソッドの名前とディスクリプタと一致するミランダメソッドを探す。ミランダメソッドに対応するエントリ１７１２はVtable１７００内に示される。

エントリを新規ミランダメソッドに割り当てるための手続きは図１３と同様である。しかしこの場合には、新規エントリをディスパッチテーブル内に割り当て（１３０２）、スタブポインタを新規エントリに挿入する（１３１４）ことの代わりに、新規スタブメソッドは、ローカル定義のミランダメソッドのセットに追加される。一次インデックスはこのメソッドのために割り当てられ、Vtableサイズは増加させられる。

特定の実施の形態では、上記Vtable構築メソッドは、サンマイクロシステムズのホットスポットの内部クラス表現のクラス表現において実装される。この場合には、すべてのクラス及びインターフェースは、それがローカルに定義するすべてのメソッドを含むメソッドテーブルを有している。加えて、すべてのクラスは、（継承メソッドを含む）クラスのインスタンスにおいて呼び出され得るすべてのメソッドのためのエントリを有するディスパッチテーブルを有する。

本発明は、コンピュータシステム内に格納される情報に関わる様々なコンピュータ実装オペレーションを用いてもよい。これらのオペレーションは、それらの必要とする物理量の物理的な操作を含むが、これに限定されるものではない。必ずしもそうではないが、通常、これらの量は、格納され、転送され、組み合わされ、比較され、一方で処理されることが可能な電気又は磁気信号の形をとる。本発明の一部を形成する本明細書中に記載のオペレーションは、有用な機械操作である。実行される操作は、多くの場合、作成、識別、実行、判定、比較、履行、ダウンロード、又は検出等の用語で引用される。時には、便宜的に、主に一般的な用法の理由で、これら電気又は磁気信号を、ビット、数値、エレメント、変数、文字等と称する。しかしながら、これら全ての、及び同様の用語は、適切な物理量と関連するものであり、これらの量に適用される単に便宜上の呼び名であることを留意されたい。

本発明はまた、前記のオペレーションを実行するためのデバイス、システム又は装置に関する。システムは、必要な目的のために特別に構成されてもよく、又は、コンピュータ内に格納されるコンピュータプログラムによって選択的に起動させられるか、又は設定される汎用コンピュータであってもよい。上で示されるプロセスは本質的に、いかなる特定のコンピュータ又は他のコンピューティング装置とも関係しない。特に、様々な汎用コンピュータは、本明細書中の教示に従って書かれるプログラムとともに用いられてもよく、又は、代替として、必要なオペレーションを実行するため、より特化したコンピュータシステムを構成することが、便利であろう。

図１８は、本発明の一実施の形態に従う処理の実行に適した汎用コンピュータシステム１８００のブロック図である。例えば、ＪＶＭ７０７、仮想マシン７１１、又はバイトコードコンパイラ７０３は、汎用コンピュータシステム１８００上で実行できる。図１８は、汎用コンピュータシステムの一実施の形態を示す。他のコンピュータシステムアーキテクチャ及び構成は、本発明の処理の実行に用いることができる。以下に記載する様々なサブシステムで構成されているコンピュータシステム１８００は、少なくとも一つのマイクロプロセッササブシステム（また、中央処理装置、即ちＣＰＵと称する）１８０２を含む。即ち、ＣＰＵ１８０２は、シングルチッププロセッサによって、又はマルチプロセッサによって実装され得る。ＣＰＵ１８０２は、コンピュータシステム１８００のオペレーションを制御する汎用デジタルプロセッサである。メモリから取り出される命令を用いることによって、ＣＰＵ１８０２は、入力情報の受信及び操作、及び出力装置上への情報の表示及び出力を制御する。

ＣＰＵ１８０２は、第１の一次記憶装置１８０４、普通はランダムアクセスメモリ（ＲＡＭ）と双方向に、そして、メモリーバス１８０８を介して第２の一次記憶領域１８０６、普通は読み出し専用メモリ（ＲＯＭ）と単方向に接続される。当該技術においてよく知られるように、一次記憶装置１８０４は、汎用記憶領域として、及び、スクラッチパッドメモリとして用いることができ、また、入力データ及び処理済データの格納に用いることができる。それはまた、プログラム命令及びデータを、ＣＰＵ１８０２上で動作するプロセス用の他のデータ及び命令に加えて格納でき、普通、メモリーバス１８０８上での双方向の素早いデータ及び命令の転送に用いられる。また、当該技術においてよく知られるように、一次記憶装置１８０６は普通、ＣＰＵ１８０２によって用いられて、その機能を実行する基本動作命令、プログラムコード、データ及びオブジェクトを含む。一次記憶デバイス１８０４及び１８０６は、例えば、データアクセスが、双方向又は単方向である必要があるかどうか等によって、以下に記載の、あらゆる適切なコンピュータ可読記憶媒体を含んでいてもよい。ＣＰＵ１８０２はまた、頻繁に必要とされるデータをキャッシュメモリ１８１０内に直接及び非常に素早く取り出し、格納することができる。

リムーバブル大容量記憶装置１８１２は、コンピュータシステム１８００用の追加データ記憶容量を提供し、周辺バス１８１４を介して双方向又は単方向でＣＰＵ１８０２に接続される。例えば、ＣＤ―ＲＯＭとして一般に公知されている特定のリムーバブル大容量記憶装置は普通、単方向でデータをＣＰＵ１８０２に渡すのに対して、フロッピー（登録商標）ディスクは、双方向でデータをＣＰＵ１８０２に渡すことができる。記憶装置１８１２はまた、磁気テープ、フラッシュメモリ、搬送波内に包含される信号、スマートカード、ポータブル大容量記憶装置及び他の記憶装置等のコンピュータ可読媒体を含んでいてもよい。固定大容量記憶装置１８１６はまた、追加データ記憶容量を提供し、周辺バス１８１４を介して双方向でＣＰＵ１８０２に接続される。一般に、これらの媒体へのアクセスは、一次記憶装置１８０４及び１８０６へのアクセスより遅い。大容量記憶装置１８１２及び１８１６は一般に、普通ＣＰＵ１８０２によってアクティブに使用されない追加のプログラム命令、データその他を格納する。大容量記憶装置１８１２及び１８１６内部で保持される情報は、必要であれば、仮想メモリとしての一次記憶装置１８０４（例えばＲＡＭ）の一部として標準形態で組み込まれてもよいことは認められよう。

記憶サブシステムに対するＣＰＵ１８０２のアクセスを提供することに加え、周辺バス１８１４は、他のサブシステム及びデバイスにも同様にアクセスを提供するために用いられる。記載の実施の形態では、これらは、表示モニタ１８１８及びアダプタ１８２０、プリンタ装置１８２２、ネットワークインターフェース１８２４、補助入出力装置インターフェース１８２６、サウンドカード１８２８及びスピーカ１８３０、及び必要に応じて他のサブシステムを含んでいる。

ネットワークインターフェース１８２４は、ＣＰＵ１８０２が他のコンピュータ、コンピュータネットワーク、又は参照されるようなネットワーク接続を用いる遠距離通信ネットワークに接続されることを許容する。ネットワークインターフェース１８２４を介して、ＣＰＵ１８０２が、例えば、他のネットワーク内のコンピュータからのオブジェクト、プログラム命令、又はバイトコード命令の情報を受信するかもしれず、又は、上記メソッドのステップの実行の間に他のネットワーク内のコンピュータに情報を出力するかもしれないことは、考慮される。多くの場合ＣＰＵ上で実行される連続命令として表される情報は、例えば、搬送波内に包含されるコンピュータデータ信号の形で、他のネットワークから受信され、出力されてもよい。インターフェースカード又は同様のデバイス、及びＣＰＵ１８０２によって実装される適切なソフトウェアは、コンピュータシステム１８００を外部ネットワークに接続し、標準プロトコルに従ってデータを転送するために使用される。即ち、本発明のメソッドの実施の形態は、単にＣＰＵ１８０２上だけで実行してもよく、又は、処理の一部を共有する遠隔ＣＰＵと連動する、インターネット、イントラネットネットワーク、又はローカルエリアネットワーク等のネットワークにわたって実行されてもよい。追加の大容量記憶装置（図示せず）はまた、ネットワークインターフェース１８２４を介してＣＰＵ１８０２に接続されてもよい。

補助Ｉ／Ｏ装置インターフェース１８２６は、ＣＰＵ１８０２が、他のデバイスからデータを送信し、より一般的には、受信することができる汎用及びカスタマイズされたインターフェースを意味する。また、ＣＰＵ１８０２に接続されるのは、キーボード１８３６又はポインタデバイス１８３８からの入力を受信し、キーボード１８３６又はポインタデバイス１８３８からの復号化シンボルをＣＰＵ１８０２へ送信するためのローカルバス１８３４を介するキーボードコントローラ１８３２である。ポインタデバイスは、マウス、スタイラス、トラックボール又はタブレットであってもよく、グラフィカルユーザーインターフェースとの相互作用に役立つ。

加えて、本発明の実施の形態は更に、様々なコンピュータ実装オペレーションを実行するためのプログラムコードを含むコンピュータ可読媒体を持つコンピュータ記憶装置製品に関する。コンピュータ可読媒体は、その後でコンピュータシステムによって読取り可能なデータを格納することができるすべてのデータ記憶装置である。コンピュータ可読媒体の実施例は、ハードディスク、フロッピーディスク、及び特定用途向け集積回路（ＡＳＩＣ）又はプログラマブルロジックデバイス（ＰＬＤ）等の特別に構成されたハードウェアデバイスを含む上記すべての媒体を含むが、これに限定されるものではない。コンピュータ可読媒体はまた、コンピュータ可読コードが、配布形態で格納され、実行されるよう、搬送波に包含されるデータ信号として接続したコンピュータシステムのネットワーク上で配布することができる。

上記のハードウェア及びソフトウェアエレメントは、標準の設計と構成のものであることは、当該技術に精通する者によって認められるであろう。本発明の用途に適切な他のコンピュータシステムは、追加の、又はより少ないサブシステムを含んでいてもよい。加えて、メモリーバス１００８、周辺バス１８１４、及びローカルバス１８３４は、サブシステムの連結に役立つすべての相互接続体系を例証する。例えば、ローカルバスは、ＣＰＵを固定大容量記憶装置１８１６及びディスプレイアダプタ１８２０に接続するために用いられてもよい。図１８において参照されるコンピュータシステムは、本発明の用途に適切なコンピュータシステムのほんの一実施例である。異なるサブシステム構成を有する他のコンピュータアーキテクチャもまた、利用されてもよい。

前記発明は、明確な理解のために幾つか詳細に記載したが、特定の変更及び修正は、添付請求の範囲の適用範囲において実践されるであろうことは、明白である。例えば、発明は、クラスのためのディスパッチテーブルの構築に関して検討されてきたが、ディスパッチテーブルは、インターフェースのために開示された手続きを用いて同様に構築されてもよい。他の実施例では、Vtableに関してそれらを区別するstaticメソッド及びプロセスは、拡張されなかったが、本発明は、それらを区分することも同様に適用可能である。加えて、最適化として、Vtableエントリを最終メソッドに割り当てることは、それがスーパークラス又はスーパーインターフェースにおいてメソッドをオーバーライドする限り、回避され得る。更に、本発明は、４つのアクセス可能性のみを示したが、より多くは、本発明に対し明らかに可能で、適用可能である点に留意されたい。更に、本発明が柔軟に適応可能なディスパッチテーブル構造の競合及びアドレス指定されない解像度の代替形式がある点に留意されたい。従って、本実施例は、例証であり、制限するものでないことを考慮すべきであり、本発明は、本明細書中で与えられる詳細に限定されないが、添付請求の範囲の適用範囲及び同等物の範囲において修正されても良い。

Claims (18)

1. コンピュータにより実行される、直属の親スーパークラスから継承する第１のクラス内のメソッドのためのディスパッチテーブルの構築方法であって、
   前記コンピュータが、クラス内のメソッドへのポインタを格納するエントリを有する構造体であるディスパッチテーブルを前記直属の親スーパークラスからコピーするステップであって、該メソッドには他のクラスからアクセスできるか否かを示すアクセス可能性の情報が関連付けられている、該ステップと、
   前記コンピュータが、前記第１のクラス内のメソッドがクラス階層内の前記第１のクラスの先祖スーパークラス内にも存在するかどうかを判定するステップと、
   前記メソッドが前記先祖スーパークラス内にも存在することが判定された場合に、前記コンピュータが、前記ディスパッチテーブルに含まれているポインタで示される前記メソッドの前記先祖スーパークラスバージョンに対応する前記アクセス可能性の情報に基づいて、前記第１のクラスから該メソッドの該先祖スーパークラスバージョンへのアクセスが可能かどうかを判定するステップと、
   前記メソッドの前記先祖スーパークラスバージョンへアクセスできないと判定された場合に、前記コンピュータが、前記第１のクラス内の前記メソッドへのポインタを格納する新規エントリを前記ディスパッチテーブル内に作成するステップと、
   前記メソッドの前記先祖スーパークラスバージョンへアクセスできると判定された場合に、前記コンピュータが、前記ディスパッチテーブル内にある、該メソッドの該先祖スーパークラスバージョンへのポインタを格納しているエントリに、前記第１のクラス内のメソッドへのポインタを格納することで、該エントリを上書きするステップと、
   を含むディスパッチテーブルの構築方法。
2. 前記第１のクラスが少なくとも一つのスーパーインターフェースからメソッドを継承する、
   請求項１に記載の方法。
3. 前記メソッドがミランダ（miranda）メソッドである、
   請求項２に記載の方法。
4. 前記ディスパッチテーブルを構築する前記方法がオブジェクト指向型言語によって実装される、
   請求項１〜３のいずれか一項に記載の方法。
5. 前記オブジェクト指向型言語がＪＡＶＡ（登録商標）である、
   請求項４に記載の方法。
6. 前記エントリ又は前記新規エントリの位置がインデックスにより示される、
   請求項１〜５のいずれか一項に記載の方法。
7. 前記クラスがパッケージに属する、
   請求項１〜６のいずれか一項に記載の方法。
8. 前記アクセス可能性には、パブリック（public）アクセス可能性、プライベート（private）アクセス可能性、プロテクテッド(protected)アクセス可能性、及びパッケージプライベートアクセス可能性のうちの一つが含まれる、
   請求項１〜７のいずれか一項に記載の方法。
9. コンピュータにより実行される、先祖階層内の直属の親スーパークラスから継承する第１のクラス内のメソッドのためのディスパッチテーブルの構築方法であって、
   前記コンピュータが、クラス内のメソッドへのポインタを格納するエントリを有する構造体であるディスパッチテーブルを前記直属の親スーパークラスからコピーするステップであって、該メソッドには他のクラスからアクセスできるか否かを示すアクセス可能性の情報が関連付けられており、前記エントリの位置がインデックスにより示される、該ステップと、
   前記コンピュータが、前記第１のクラス内のメソッド、及び該メソッドに対応するアクセス可能性の情報が前記先祖階層のスーパークラス内に存在するかどうかを判定するステップと、
   前記コンピュータが、前記メソッド及び前記アクセス可能性の情報が前記先祖階層のスーパークラス内にも存在することが判定された場合に、該スーパークラスに対応するディスパッチテーブルのインデックスを前記メソッド及び前記アクセス可能性の情報に割り当てることを、メソッドに関連付けられたアクセス可能性毎に行うステップと、
   前記コンピュータが、前記メソッド及び前記アクセス可能性の情報が前記先祖階層のスーパークラス内に存在しないと判定された場合に、前記ディスパッチテーブルのインデックスを作成して該インデックスを前記メソッド及び前記アクセス可能性の情報に割り当てることを、メソッドに関連付けられたアクセス可能性毎に行うステップと、
   前記コンピュータが、前記メソッドへのポインタを格納する前記ディスパッチテーブル内のエントリを前記メソッドが割り当てられたインデックスに割り当てることを、各インデックスについて行うステップと、
   を含むディスパッチテーブルの構築方法。
10. 前記コンピュータが、前記アクセス可能性に基づいて決定された優先度を、前記メソッド及び前記アクセス可能性に対応するエントリに割り当てるステップを更に含む、
    請求項９に記載の方法。
11. 前記優先度を前記エントリに割り当てるステップが、前記メソッドと、前記第１のクラスのアクセス可能性に対応するアクセス可能性とに関連付けられた前記エントリに一次優先度を割り当てるステップを含む、
    請求項１０に記載の方法。
12. 前記メソッドのすべての前記アクセス可能性の情報にインデックスが割り当てられた場合に、前記コンピュータが、前記第１のクラス内の前記メソッド及び前記アクセス可能性が前記先祖階層のスーパークラス内にも存在するかどうかの判定を中止するステップを更に含む、
    請求項９〜１１のいずれか一項に記載の方法。
13. 前記アクセス可能性がパブリックアクセス可能性、プライベートアクセス可能性、プロテクテッドアクセス可能性、又はパッケージプライベートアクセス可能性である、
    請求項９〜１２のいずれか一項に記載の方法。
14. 前記第１のクラス内の前記メソッド及び前記アクセス可能性の情報が前記先祖階層のスーパークラス内にも存在するかどうかの判定は、前記メソッド及びアクセス可能性の情報が見出されなかった場合の第１の状態から、前記メソッド及びアクセス可能性の情報が見出された場合の第２の状態へ変化することを示すインデックスを用いて実行される、
    請求項９に記載の方法。
15. 前記コンピュータが、前記ディスパッチテーブルをメモリに割り当てるために該ディスパッチテーブルのサイズを判定するステップを更に含む、
    請求項９〜１４のいずれか一項に記載の方法。
16. 前記コンピュータが、割り当てられた各エントリに対応する前記ディスパッチテーブルの少なくとも一つのエントリを割り当てるステップを更に含む、
    請求項１５に記載の方法。
17. 前記コンピュータが前記ディスパッチテーブルを前記メモリに書き込むステップを更に含む、
    請求項１５又は１６に記載の方法。
18. スーパークラスから継承する第１のクラス内のメソッドのためのディスパッチテーブルの構築方法をコンピュータに実行させるためのプログラムを記録したコンピュータ可読記憶媒体であって、
    前記構築方法が
    クラス内のメソッドへのポインタを格納するエントリを有する構造体であるディスパッチテーブルを前記第１のクラスの直属の親スーパークラスからコピーするステップであって、該メソッドには他のクラスからアクセスできるか否かを示すアクセス可能性の情報が関連付けられている、該ステップと、
    前記第１のクラス内のメソッドがクラス階層内の前記第１のクラスの先祖スーパークラス内にも存在するかどうかを判定するステップと、
    前記メソッドが前記先祖スーパークラス内にも存在することが判定された場合に、前記ディスパッチテーブルに含まれているポインタで示される前記メソッドの前記先祖スーパークラスバージョンに対応する前記アクセス可能性の情報に基づいて、前記第１のクラスから該メソッドの該先祖スーパークラスバージョンへのアクセスが可能かどうかを判定するステップと、
    前記メソッドの前記先祖スーパークラスバージョンへアクセスできないと判定された場合に、前記第１のクラス内の前記メソッドへのポインタを格納する新規エントリを前記ディスパッチテーブル内に作成するステップと、
    前記メソッドの前記先祖スーパークラスバージョンへアクセスできると判定された場合に、前記ディスパッチテーブル内にある、該メソッドの該先祖スーパークラスバージョンへのポインタを格納しているエントリに、前記第１のクラス内のメソッドへのポインタを格納することで、該エントリを上書きするステップと、を含む、
    コンピュータ可読記憶媒体。
    

Images