【０００１】
【発明の属する技術分野】
本出願は、２００２年８月２２日に出願された米国仮出願番号第６０／４０５，２６６号の利益を主張する。 上記の出願の開示は、本願明細書に引用したものとする。
【０００２】
本発明は、コード実行の速度を改善することに関し、特に、ＪＡＶＡ（登録商標）のようなオブジェクト指向環境において動作するバーチャルマシン内でのメソッド呼び出しメカニズムを加速することに関する。
【０００３】
【従来の技術】
オブジェクト指向言語は、継承および多義（ｐｏｌｙｍｏｒｐｈｉｓｍ）をサポートして、柔軟で再使用可能なソフトウェアの開発を可能にする。 典型的なオブジェクト指向プログラムは、一組のクラスを含む。 このようなクラスのそれぞれは、一組のデータメンバーを定義することができる。 更に、各クラスは、この組のデータメンバー上で動作する一組のメソッドを含むことができる。
【０００４】
継承は、クラスが、親クラスの機能を「継承する」、すなわち引き出すことを可能にする。 したがって、継承のために、与えられたメソッドは、親および子供クラスに共通でもよい。 このような共通のメソッドが呼び出されるときに、実行メカニズムは、呼び出されたメソッドが親または子供のいずれのクラスのオブジェクト上で動作しているかを判定しなければならない。 オブジェクト上で動作しているメソッドは、一般に、メソッド名、引数の数、型および順序（ｏｒｄｅｒ）、戻り型（ｒｅｔｕｒｎ ｔｙｐｅ）、およびオブジェクトの関連付けられたクラスから構成されるメソッドシグネチャを用いて識別される。
【０００５】
与えられたオブジェクトの型は、通常、実行時に判定される。 実行時にオブジェクトの型を判定する、このアプローチは、「動的結合」と呼ばれる。 この文脈において、実行される適当なメソッドの選択は、ルックアップメカニズムに基づき、それは、を意味する。 起動の後に実行される実際のメソッドは、メソッドのレシーバの型、クラス階層およびメソッド継承またはオーバーローディングスキーマ（ｏｖｅｒｌｏａｄｉｎｇ ｓｃｈｅｍａ）に基づいて、動的に判定される。 典型的なルックアップメカニズムを、次に述べる。
【０００６】
起動が起こるときに、ルックアップメカニズムは、実行される実際のメソッドを判定する。 クラスが呼ばれたものと同じシグネチャを有するメソッドを実装している場合、見つけられたメソッドが実行される。 さもなければ、検索されたメソッドが見つけられるまで、親クラスが繰り返しチェックされる。 メソッドが見つけられない場合、エラーであることが合図される（ＭｓｇＮｏｔＵｎｄｅｒｓｔｏｏｄ）。 この動作は、あまりにしばしば起こって、実行時間および他の資源に関して非常に不経済である。 したがって、ルックアップメカニズムの速度を上げる必要がある。
【０００７】
静的な技術は、ルックアップの一部を予め計算して、動的な技術は、以前のルックアップの結果のキャッシュを用いるので、他のルックアップを避けることができる。 主要な動的結合アルゴリズムは、ディスパッチテーブル検索（ＤｉｓｐａｔｃｈＴａｂｌｅ Ｓｅａｒｃｈ；ＤＴＳ）と呼ばれている。 ＤＴＳは、スペースコストに関しては良いメソッドであるが、ＤＴＳに関する検索の不利益は、メカニズムを、あまりにもゆっくりにする。 ＤＴＳに関するオーバーヘッドを減らす必要がある。 多くの技術が、ＤＴＳに関するオーバーヘッドを減らすために提案されてきた。 すなわち、ルックアップの一部を予め計算する静的な技術と、以前のルックアップの結果をキャッシュする動的な技術とによって、他のルックアップを避けることである。 上記で言及した技術を、次に述べる。
【０００８】
セレクタテーブルインデクシング（Ｓｅｌｅｃｔｏｒ Ｔａｂｌｅ Ｉｎｄｅｘｉｎｇ；ＳＴＩ）と呼ばれている技術は、ルックアップメカニズムを加速する静的な方法である。 ＳＴＩ技術を、次に簡単に述べる。 ＣクラスおよびＳセレクタのクラス階層が与えられると、Ｃ＊Ｓエントリ（ｅｎｔｒｉｅｓ）の二次元の配列が造られる。 クラスおよびセレクタは、各軸上の連続番号で与えられ、配列は、各クラスおよびセレクタのためにロックアップを予め計算することによって満たされる。 配列エントリ（ｅｎｔｒｙ）は、対応するメソッドまたはエラールーチンに対するリファレンスを含む。 これらのテーブルは、完全なシステムのために計算される。
【０００９】
ＳＴＩ技術は、高速かつ一定時間のルックアップをもたらす。 しかし、ＳＴＩの主な欠点は、スペース要求が、限られた計算資源しか持っていない典型的なシステム、例えば、組み込みシステムにとって、非常に大きいことである。 セレクタカラーリング（ｓｅｌｅｃｔｏｒ ｃｏｌｏｒｉｎｇ）、列置換等のような多くのディスパッチテーブル圧縮技術が、必要なスペースオーバーヘッドを減らすために提案されてきた。 しかし、このような技術を実装することは、組み込みシステムのような限られた計算資源環境に、望ましくない負担をかける。 この技術の更なる欠点は、コンパイルされたコードが、クラス階層の変化に非常に敏感であることである。 ＳＴＩによって造られる二次元の配列は、コンパイル時間で固定される。 しかし、Ｊａｖａ（登録商標）のような言語にとっては、クラスのセットは、動的に変わることができる。 ＳＴＩは、このような状況を取り扱うことができない。 なぜなら、それは、動的に配列を変えることができないからである。
【００１０】
同期化技術は、マルチスレッドアプリケーション（ｍｕｌｔｉ−ｔｈｒｅａｄｅｄ ａｐｐｌｉｃａｔｉｏｎｓ）を実行するために用いられるスレッディングモデル（ｔｈｒｅａｄｉｎｇ ｍｏｄｅｌｓ）の機能を改善する。 従来の組み込みＪＡＶＡ（登録商標）バーチャルマシン（特にキロバイトバーチャルマシンに基づくもの）において用いられる同期技術は、次の４つの状態のうちの１つのオブジェクトに関連する。 （１）ロックがかかってない、（２）単純ロックされた、（３）拡張ロックされた、または（４）モニターに関連する。 したがって、どの特定のロック状態とも関連しない同期技術が必要である。
【００１１】
【発明が解決しようとする課題】
したがって、計算資源プロセッサ／実行時間、メモリおよびメソッド検索すなわちルックアップに関して、小さいオーバーヘッドの要求しか持たない一組の技術が必要である。 このような技術は、レシーバオブジェクトがしばしば変わる状況であっても効果的でなければならない。 更に、組み込みシステムのような限られた資源の計算環境において動作するバーチャルマシン内でのコード実行を加速するメカニズムが必要である。
【００１２】
【課題を解決するための手段】
コンピュータベースのシステムは、メソッド呼び出しの速度を上げることによってコード実行を加速する。 バーチャルマシンは、ローダー、インタープリタ、スレッドマネージャ（ｔｈｒｅａｄ ｍａｎａｇｅｒ）および他のモジュールおよび／またはコンポーネント（ｃｏｍｐｏｎｅｎｔｓ）を備えている。 ローダーは、メソッドシグネチャ（ｍｅｔｈｏｄ ｓｉｇｎａｔｕｒｅｓ）を用いて、ハッシュテーブル（ｈａｓｈ−ｔａｂｌｅ）をつくる。 インタープリタは、つくられたハッシュテーブルを用いて、メソッドを検索するプロセスを加速する。 インタープリタは、レシーバに対するポインタを有するメソッド呼び出しキャッシュをつくり、かつ用いて、コード実行を加速する。 キャッシュは、修正されたガード条件を提供し、これは、より速いキャッシュ動作を可能にし、その結果、より良い実行速度がもたらされる。 スレッドマネージャは、深さレベルを用いてロック状態の移行を加速する。 深さレベルは、単純ロックおよび拡張ロック状態を示し、従って別々の単純ロック状態を不要にする。 ロック状態の数が少なければ、より速いロック状態の移行という結果になり、これは、より速いコード実行をもたらす。 本発明は、一般に、いかなるバーチャルマシン環境、例えば、ＪＡＶＡ（登録商標）バーチャルマシン（ＪＶＭ）およびキロバイトバーチャルマシン（ＫＶＭ）環境にも実装することができる。 特に、本発明は、比較的限られた計算資源しか持たない組み込みシステムにも実装することができる。
【００１３】
本発明の更なる応用範囲は、以下の詳細な説明から明らかになるであろう。 詳細な説明および具体的な例は、本発明の好適な実施形態を示しているが、単なる具体例に過ぎず、本発明の範囲を限定するものでないことは、理解されなければならない。
【００１４】
【発明の実施の形態】
本発明は、詳細な説明および添付の図面から、より充分に理解されるであろう。
【００１５】
以下の好適な実施形態の記載は、単なる例に過ぎず、決して本発明、その応用または使用を限定するものではない。
【００１６】
オブジェクト指向（“ＯＯ”）プログラムは、データメンバーをカプセル化するクラスと、このようなデータメンバー上で動作するメソッドとから成る。 したがって、ＯＯプログラム内のメソッドは、与えられたクラスの一部である。 あらかじめ宣言／定義されたクラスのオブジェクトは、インスタンス化されることができる。 与えられたクラス型の各個々のインスタンスオブジェクトは、与えられたクラス宣言／定義において宣言されたデータメンバーを保持する。 一般に、与えられたクラス型の一部であるメソッドは、インスタンス化されたオブジェクトのデータメンバー上で動作する。
【００１７】
例は、ＯＯプログラム内の典型的な装置を示す。 例としてのＯＯプログラムは、クラスＡおよびクラスＢと名付けられた２つのクラスを有することができ、クラスＢは、クラスＡを継承すなわちクラスＡに由来する。 クラスＡは、メソッドｍを定義することができ、かつ、継承のために、クラスＢもまた、その一部としてメソッドｍを持つ。 クラスＡ型のオブジェクトは、それらの一部としてメソッドｍを持ち、かつ、継承のために、クラスＢ型のオブジェクトも、そうする。 メソッドシグネチャは、次に記述するように、メソッドを識別するために用いられる。
【００１８】
ＯＯ環境は、一般にクラス名、メソッド名、パラメータおよび戻り型を用いて形成されたメソッドシグネチャを用いて、２つのよく似たメソッドを識別する。 実行エンジンが与えられたオブジェクト上のメソッドｍの起動に遭遇すると、それは、呼び出されたメソッドシグネチャを用いて、メソッドテーブル内のメソッドの定義の位置を捜し当てる。 メソッド定義のこの検索は、時間強い作業である。 本発明は、メソッドルックアップおよび実行のために必要な時間を最小にする一方で、与えられた環境の計算資源上での要求を最小にする。
【００１９】
ＯＯ言語（例えばＪＡＶＡ（登録商標））は、頻繁に動的ディスパッチメカニズムを用いて、呼び出されたメソッドの定義を検索する。 メソッドは、複数のクラスにおいて定義されることができる。 適当なメソッド定義の検索は、動的に実行される。 これは、著しい実行時間のオーバーヘッドを引き起こす。 一般に、既知の静的および動的な技術は、比較的厳しい資源制約の下で動作する組み込みＪＡＶＡ（登録商標）のような組み込みプラットホームに適していない。 特に、このような技術は、メモリをたくさん使うが、これは、限られたメモリ資源しか持っていない典型的な組み込みシステムにとって、望ましくない特性である。
【００２０】
本発明は、ＯＯ環境におけるメソッド呼び出しメカニズムを加速する動的、柔軟かつ効率的な技術を含む。 例証目的のために、メソッド呼び出し加速メカニズムが、組み込みシステムの応用におけるＪＡＶＡ（登録商標）ベースのバーチャルマシン環境の状況において論じられる。 当業者であれば、ＪＡＶＡ（登録商標）ベースの組み込みシステムが、単なる説明目的のための具体例として用いられ、かつ、同じものは、本発明を限定するものではないことを認めるであろう。 本発明は、いかなるオブジェクト指向環境においても使用でき、および／または適用できる。 本発明の加速技術は、メソッド呼び出しプロセスの複数の態様、例えば、ルックアップ、キャッシングおよび同期されたメソッドに及ぶ。 バーチャルマシンは、次に、本発明の実施形態における本発明の技術を適用するためのプラットホームとして論じられる。
【００２１】
図１は、本発明の実施形態におけるバーチャルマシン１０のブロック図である。 バーチャルマシン１０は、オペレーティングシステム１２と緊密に連係して動作する。 ローダー１４は、実行されるべきコードを、バーチャルマシン１０内にロードする。 ローダー１４は、ハッシュ管理モジュール、例えばハッシュビルダー１６およびハッシュルックアップ１８を備えている。 ベリファイヤ２０は、あらゆる起こりうるエラーのために、ロードされたクラスおよびコードをチェックする。 ローダー１４は、また、任意のルーチンおよび／またはクラスを、言語クラスライブラリ２２およびネイティブクラスライブラリ２４からロードする。
【００２２】
インタープリタ２６は、ローダー１４によってロードされたコードを解釈して、実行する。 キャッシュ２８およびキャッシュハンドラ３０は、インタープリタ２６の一部であって、メソッド呼び出しをキャッシュするために用いられる。 ヒープ管理およびガーベッジコレクタモジュール３２は、インタープリタ２６によって用いられて、ヒープ上でオブジェクトをつくり、かつ破壊する。 インタープリタ２６は、スレッドマネージャ３４を用いて、実行されているコードのスレッディング動作を制御する。 さまざまなスレッドが、オブジェクトにアクセスするために、コード実行の間、競合するので、スレッドマネージャ３４は、オブジェクト上でロックおよびアンロック動作を実行する。 更に、スレッドマネージャ３４は、スレッドの切り替えも管理する。
【００２３】
バーチャルマシン１０についての上記の説明は、一般的なバーチャルマシンに関する。 このような一般的なバーチャルマシン１０の具体例は、ＪＡＶＡ（登録商標）バーチャルマシン（ＪＶＭ）である。 更なる具体例として、ＫＶＭ（キロバイトバーチャルマシン）が引用される。 ＫＶＭは、一般に、小さい設置面積のＪＶＭを必要とする組み込みシステムのアプリケーションに用いられる。 ＫＶＭまたはＪＶＭのいずれにおいても、ローダー１４は、システムおよびユーザ定義のクラスをロードするクラスファイルローダーとして動作する。 更に、ローダー１４は、定数プール（ｃｏｎｓｔａｎｔ ｐｏｏｌ）およびクラスファイル構造（ｃｌａｓｓ ｆｉｌｅ ｓｔｒｕｃｔｕｒｅｓ）を造り、かつ、それは、クラスおよびコードベリファイヤ２０と連係し、この具体例においては、ロードされたバイトコードの型の安全を確認する。 インタープリタ２６は、ロードされたクラスファイルのバイトコードを解釈するために動作する。 スレッドマネージャ３４は、アプリケーションのスレッドを管理する。 当業者であれば、ＪＶＭおよびＫＶＭの上記の説明は、具体例として提供され、本発明の理解を助けることができ、かつ、同じものは、本発明を限定するものではないことを認めるであろう。 次に、メソッドのルックアップの加速について説明する。
【００２４】
図２Ａは、典型的なクラス階層３６を示す。 クラスＡ ３８は、メソッド'ｍ'を含む。 クラスＢ ４０は、親クラスＡ ３８の子供クラスである。 クラスＢ４０は、メソッドｍ、ｍ１およびｍ２を含む。 クラスＢ ４０は、クラスＡ ３８からメソッドｍを継承する。 次に、この典型的なクラス階層３６のためのハッシュテーブルベースのルックアップについて説明する。
【００２５】
図２Ｂは、ルックアップの加速のプロセスにおいて用いられるメソッドハッシュテーブル４２を示す。 バーチャルマシンのローダー１４（図１を見る）は、上述したクラス階層の各仮想メソッドテーブルのためにハッシュテーブル４２を造る。 メソッドテーブルのルックアップは、ハッシング（ｈａｓｈｉｎｇ）のようなダイレクトアクセス技術によって加速される。 これは、適当なハッシング技術および効率的なハッシング関数（ｆｕｎｃｔｉｏｎ）を用いることによって達成される。
【００２６】
メソッドシグネチャ（図示せず）は、複数の方法でつくることができる。 例えば、メソッドシグネチャは、メソッド名およびその公式の（ｆｏｒｍａｌ）パラメータの数および型を用いてつくることができる。 ハッシュテーブル４２の各インデックスは、ハッシュ関数をメソッドシグネチャに適用した結果に対応する。 ハッシュテーブル４２のサイズは、より効率的かつ柔軟なルックアップメカニズムを得るために、メソッドシグネチャ間の衝突を最小にする一方で、小さい設置面積持つように、慎重に選ばなければならない。 ハッシュベースのアクセスを通して提供されるメソッドテーブルに対するダイレクトアクセスによって、効率が達成される。 我々はスピードアップ対設置面積のための最良の比率を持つようにハッシュテーブル４２のサイズを調整することができるので、柔軟性が達成される。
【００２７】
クラスをロードするプロセスの間、ハッシュビルダー１６は、ハッシュメソッドテーブルを造る。 ハッシュは、メソッドシグネチャから計算される。 ハッシュテーブル４２内の各エントリは、２つのコンポーネントでできている。 第１のコンポーネントは、クラスが、このような定義を有するメソッドを含むかどうかを示すフラグである。 この例においては、第１のコンポーネント４４ _１ 〜４４ _５が示されている。 第１のコンポーネント４４ _１および４４ _４内でのフラグ'１'の存在は、メソッド定義に対するリンクが、このようなメソッドを利用できることを示す。 そのメソッドシグネチャは、第１のコンポーネント４４ _１および４４ _４のためにハッシュインデックスにハッシュする。
【００２８】
第２のコンポーネントは、メソッド定義に対するポインタである。 衝突の場合、この第２のコンポーネントは、メソッド定義のリストに対するポインタである。 ここでは、第２のコンポーネント４６ _１は、メソッドｍ２のための単一のメソッド定義である。 なぜなら、他のメソッドシグネチャは、第１のコンポーネント４４ _１のハッシュ位置に対してハッシュしないからである。 しかし、第１のコンポーネント４４ _４のハッシュ位置のための第２のコンポーネントは、衝突リストである。 なぜなら、メソッドｍおよびｍ１のそれぞれのための２つのメソッドシグネチャは、同じ第１の位置４４ _４上にハッシュするからである。 したがって、メソッドｍおよびｍ _１のメソッド定義のための衝突リストは、それぞれ第２のコンポーネント４６ _２および４６ _３として示される。
【００２９】
図３は、典型的なメソッドハッシュテーブル構築手順を示す。 ローダー１４（図１参照）は、ハッシュテーブル４２（図２Ｂ参照）をつくるために、内蔵のハッシュビルダー１６（図１参照）を持つこともできるし、または、ハッシュビルダー１６は、外部の呼び出し可能なルーチンであってもよい。 ハッシュ構築ルーチンの位置は、ローダー１４の内部であれ外部であれ、いかなる方法でも本発明を限定するものではないことは、当業者であれば理解するであろう。 ハッシュテーブル４２の構築およびハッシュビルダー１６の動作の詳細な説明は、以下の通りである。
【００３０】
ハッシュビルダー１６は、ローダー１４によってロードされたクラスを処理する。 与えられたロードされたクラス内の各メソッドのために、ハッシュビルダー１６は、メソッドのシグネチャからハッシュを計算する。 生成されたハッシュを用いて、ハッシュビルダー１６は、ハッシュテーブル４２内のハッシュインデックスで要素（ｅｌｅｍｅｎｔ）を得る。 メソッド定義が、そのハッシュインデックスにおけるフラグによって定まるような、アクセスされたハッシュ位置に、すでに存在する場合に、衝突エントリが、新しいメソッドのためにつくられる。 しかし、もし、そのハッシュインデックスにおけるフラグがオフで、メソッドエントリの不在が示されていれば、メソッドは、ハッシュテーブル４２内の計算されたハッシュインデックスに登録される。
【００３１】
図４は、ハッシュテーブル内でメソッドを検索するための典型的なハッシュルックアップ手順を示す。 ハッシュルックアップ１８（図１参照）は、ハッシュテーブル４２（図２Ｂ参照）内の対応するエントリ／インデックスにアクセスするために、ハッシュ関数をメソッドシグネチャに適用することから得られるハッシュ値を用いる。 ハッシュ値を用いて、ハッシュルックアップ１８は、アクセスされたハッシュインデックス／エントリで、フラグ値を判定する。 もし、このエントリに関するフラグが（図２Ｂにおける１として示されたように）オンであれば、それは、エントリの第２のコンポーネントによって、メソッド定義にアクセスする。 （図２Ｂにおける'０'として示されたような）フラグのオフ状態は、クラスがこのようなメソッドを実装しないで、検索がスーパークラスに指示されることを示す。
【００３２】
ハッシュベースのメソッド定義アクセスアプローチは、単純なテーブルベースの検索と比較して、より速い検索時間を提供する。 ルックアップメソッドの加速は、ハッシュテーブルサイズによって決まる。 より大きいハッシュテーブルサイズは、より大きいメモリ空間を必要とするが、衝突を最小限にする。 他方で、より大きいハッシュテーブルサイズは、メモリ管理（割当て、ガーベッジコレクション、圧縮等）に関して追加のコストを引き起こす可能性がある。
【００３３】
当業者であれば、本発明が複数の方法で実施することができることを認めるであろう。 例えば、１つの実施形態として、ハッシュベースのルックアップの必要な要素を含むバーチャルマシン１０をつくることができる。 その代わりに、従来のバーチャルマシンを修正して、次に述べるようにハッシュベースのルックアップを提供することもできる。
【００３４】
上述したルックアップの加速は、従来の組み込みＪａｖａ（登録商標）バーチャルマシン、例えば以下のＫＶＭ（キロバイトバーチャルマシン）内で実現することができる。 典型的なＫＶＭ内のメソッドルックアップメカニズムは線形である。 すなわち、それはシーケンシャルアクセスを用いる。 ハッシュベースのルックアップは、典型的なＫＶＭにおいて用いられる線形のメソッドルックアップをこえる、より良い性能を生む。 このようなメカニズムの実装は、バーチャルマシン１０（図１参照）の２つのコンポーネント、すなわちローダー１４およびインタープリタ２６に影響を及ぼす。 ローダーは、各々のロードされたクラスのためのハッシュテーブル４２をつくるために修正される。 インタープリタは、ハッシュテーブル４２を利用するために修正されて、速くかつダイレクトアクセスのルックアップを実行する。
【００３５】
動的な技術は、以前のルックアップの結果をキャッシュすることに本質がある。 キャッシュベースの技術は、巨大なディスパッチテーブルをつくることを不要にするので、メモリオーバーヘッドおよびテーブル作成時間は減少する。 グローバルなキャッシュ技術は、以前のルックアップ結果を格納する。 グローバルなキャッシュテーブルにおいて、各エントリは、三つ組み（レシーバクラス、セレクタおよびメソッドアドレス）から成る。 レシーバクラスおよびセレクタは、キャッシュ内のインデックスを計算するために用いられる。 現在のクラスおよびメソッド名が、計算されたインデックスで、キャッシュされたエントリ内のそれらと合致した場合に、メソッドアドレスにおけるコードが実行される。 したがって、メソッドルックアップは避けられる。 さもなければ、デフォルトのディスパッチ技術（通常はＤＴＳ）が用いられ、この検索の終わりに、新しい三つ組みが、キャッシュテーブルに加えられ、そして、制御は見つけられたメソッドへ移される。 このアルゴリズムが必要とする実行時メモリは小さく、通常はＤＴＳ技術のキャッシュおよびオーバーヘッドの固定された量である。 レシーバクラスの頻繁な変化は、実行を遅くする可能性がある。
【００３６】
図５は、メソッド呼び出しを格納するための既知のキャッシュレイアウトを示す。 キャッシュエントリ４８は、典型的な形式が示され、その内容を以下で説明する。 コンテンツリンク５０は、呼び出されたメソッドに対するポインタである。 ｃｏｄｅＬｏｃ５２は、メソッドを呼び出したインストラクションに対するポインタである。 オリジナルパラメータ５４は、メソッドが元々呼び出されたパラメータを表す。 オリジナルインストラクション５６は、メソッドを呼び出すために用いられたインストラクションを指し示す。 従来のインラインキャッシュ技術（例えばＫＶＭ内に実装されたもの）においては、メソッド定義に対するポインタのみが、キャッシュエントリ４８内に格納される。 次に、修正されたキャッシュエントリ構造およびキャッシュハンドリングメカニズムについて説明する。
【００３７】
図６は、レシーバに対するリンクを含むキャッシュエントリ５８を示す。 メソッドが呼び出されるオブジェクトは『レシーバ』と呼ばれている。 なぜなら、それは、いくつかの他のオブジェクトからメソッド起動要求を受け取るからである。 レシーバポインタ６０はレシーバを指し示す。 キャッシュエントリ５８の他のメンバーは、上述したキャッシュエントリ４８と同様である。 キャッシュエントリ５８は、詳細が述べられるメソッド起動のキャッシュを除けば、同様に、レシーバに対するリンクまたはポインタをキャッシュする。 メソッドが呼び出されると、レシーバのクラスは、呼び出されたメソッドのクラスと比較される。 これらの２つのクラスが等しければ、メソッド定義が、キャッシュエントリのために検索される。 等しくなければ、動的なルックアップが、クラス階層内のメソッド定義を検索するために実行される。 キャッシュレイアウトのこの修正は、次に述べるように、メソッドルックアッププロセスを加速する。
【００３８】
メソッド呼び出しは、キャッシングアプローチを用いて加速することができる。 インラインキャッシュ技術は、修正されたキャッシュレイアウトを用いることによって、プログラム実行の著しいスピードアップを達成することができる。 インラインキャッシュ技術は、各呼び出しサイトでコード自体の中に以前のルックアップ（メソッドアドレス）の結果をキャッシュすることに本質がある。 インラインキャッシュは、デフォルトメソッドルックアップによって見つけられたメソッドのダイレクト起動と共に、それを上書きすることによって、呼び出しインストラクションを変更する。 インラインキャッシュは、レシーバのクラスが、まれにしか変わらないと仮定しているが、そうではない場合には、インラインキャッシュ技術は、遅い実行時間をもたらす可能性がある。
【００３９】
インラインキャッシュ技術は、レシーバのクラスと呼び出されたメソッドのクラスとの間にミスマッチがあるときに、動的ルックアップの多くを避けることによって、著しく改善される。 このようなミスマッチの場合に、もし、キャッシュハンドラ３０が、レシーバが変わらなかったことを検出することができたら、我々は、メソッド定義をキャッシュから検索することができる。 これは、ポインタをキャッシュ構造内のレシーバに加え、かつキャッシュ検索をガードする条件を修正することによって、なされる。
【００４０】
キャッシュエントリ５８内でのレシーバポインタ６０の追加は、上述した通りである。 キャッシュのためのガード条件は、レシーバポインタ６０の存在の利点をとるために修正することができる。 メソッドが呼び出されると、キャッシュハンドラ３０は、次に述べるガード条件をチェックする。
【００４１】
第１のガード条件は、与えられたキャッシュエントリ５８内のレシーバのクラスが、呼び出されたメソッドのクラスに等しいどうかである。 第２の代替ガード条件は、現在のレシーバが、レシーバポインタ６０によって指し示されたキャッシュされたレシーバに等しいかどうか、すなわち、レシーバが変わらなかったかどうかである。 どちらのガード条件も満たされる場合、キャッシュハンドラ３０は、キャッシュエントリ５８を検索して、メソッドテーブルのルックアップすなわち検索を経ることなく、メソッド定義にアクセスする。 当業者であれば、レシーバが変わらなかったかどうかをチェックする代替ガード条件が、キャッシュ検索プロセスをより柔軟にすることを認めるであろう。 この代替ガード条件は、レシーバポインタ６０が、修正されたキャッシュエントリ５８内に設けられることを必要とする。
【００４２】
次に、本発明の実施形態におけるキャッシュ動作の具体例について説明する。 この具体例においては、クラスＸおよびＹ（図示せず）の典型的な一組について考察する。 クラスＹは、クラスＸから静的ではないメソッドｍを継承する。 クラスＸおよびＹを用いているＯＯＰプログラムコードの中に、頻繁に実行されるループが存在する。 このようなループの中で、メソッドｍは、オブジェクトｏ _Ｂ上に呼び出される。 ここで、ｏ _Ｂは、クラスＹのインスタンスである。 キャッシュハンドラ１８は、キャッシュエントリ５８内の他の起動に関するエントリとともに、メソッドｍの最初の起動の後に、オブジェクトｏ _Ｂを指し示しているレシーバポインタ６０を格納する。 メソッドｍの次の起動の際には、レシーバポインタ６０のクラス、すなわちクラスＹは、呼び出されたメソッドのクラスとは異なっていて、それは、クラスＸである。 第１のガード条件、すなわち、キャッシュエントリ５８内のレシーバのクラス（クラスＹ）が、呼び出されたメソッドのクラス（クラスＹ）と等しいかどうかは、満たされず、キャッシュ検索は行われない。 しかし、第２のガード条件、すなわち、現在のレシーバが、レシーバポインタによって指し示されたキャッシュされたレシーバと等しいかどうかは、満たされる。 なぜなら、両方が、同じオブジェクトｏ _Ｂを指し示すからである。 したがって、第２のガード条件は、キャッシュされたメソッド呼び出しのより速いルックアップを、キャッシュエントリ５８内のレシーバポインタを用いて促進する。
【００４３】
上述した状況におけるキャッシュ技術の比較は、本実施形態における修正されたキャッシュ技術が、優れたルックアップ性能をもたらすことを示している。 レシーバポインタ６０なしでのキャッシュ（図５参照）は、メソッドｍの各々の次の起動のために、動的なルックアップを実行して、著しいオーバーヘッドという結果になる。 このようなキャッシュは、レシーバポインタの不足により、レシーバポインタ６０によって指し示されたオブジェクトが現在のオブジェクトと比較される代替ガード条件の利点をとることができない。 他方で、キャッシュハンドラ３０は、現在のレシーバが、レシーバポインタ６０によって指し示されたものに等しいかどうかを簡単に検査する。 それゆえに、メソッド定義は、資源的に不経済なルックアップを必要とせずに、メソッドｍの全ての次の起動のために、キャッシュから検索される。 したがって、本発明のキャッシュ構造およびキャッシュハンドリングメカニズムは、著しいスピードアップという結果になる。
【００４４】
多義的インラインキャッシュは、インラインキャッシュ技術の拡張である。 コンパイラは、特別なスタブルーチンに対する呼び出しを生成する。 各呼び出しサイトは、特定のスタブ関数にジャンプする。 この関数は、最初は、メソッドルックアップに対する呼び出しである。 メソッドルックアップが呼び出されるたびに、スタブ関数は拡張される。 この技術は、最良のケースのテストおよびダイレクトなジャンプのコストを有している。 加えて、クラス階層が巨大で、レシーバクラスがしばしば変わるときに、実行可能なコードを劇的に拡張することができる。
【００４５】
もう一つの本発明の実施形態は、ルックアップの加速をもたらす同期したスレッディングモデルを実装している。 いかなる外部の資源も必要としない非同期の単一のスレッドプログラムは、並列に実行されるスレッドの状態または活動を管理する必要がなく、自由に動作することができる。 複数の同期したスレッドが、おそらく同じ資源にアクセスして、同時に動作している状況においては、さまざまなスレッドの衝突する要求を管理することが、避けられなくなる。 同期したメソッドを実行する前に、スレッドは、レシーバオブジェクトに関するロックを得なければならない。 ２つのスレッドが同じオブジェクト上のこのメソッドを実行しようとしている場合に、これは必要である。 オブジェクトをロックすることは、実行を遅くする。 複数のスレッドの衝突する要求を管理するために、オブジェクトロック機構を用いる典型的なスレッディングモデルについて、以下で述べる。
【００４６】
図７は、既知のスレッディングモデルを表す第１のオートメーション（ａｕｔｏｍａｔｉｏｎ）６２を示す。 第１のオートメーション６２は、円でオブジェクトロック状態を示し、状態移行は、オートメーション状態を接続している方向をもった線として示されている。 第１のオートメーション６２は、状態Ａ〜Ｅから成り、それは、与えられたオブジェクトのロック状態を示す。 状態Ａ ６４は、ロックがかかっていない状態を示し、状態Ｂ ６６は、単純ロック状態を示し、状態Ｃ ６８は、拡張状態を示し、状態Ｄ ７０は、モニター状態を示し、そして、状態Ｅ ７２は、例外状態を示す。 移行は、文字'ｕ'、'ｓ'、'ｅ'、'ｍ'および'ｘ'で識別される。 特に、これらの文字は、以下の動作を表す：ｕ−ｓｅｔ＿ｕｎｌｏｃｋｅｄ；ｓ−ｓｅｔ＿ｓｉｍｐｌｅ＿ｌｏｃｋ；ｅ−ｓｅｔ＿ｅｘｔｅｎｄｅｄ＿ｌｏｃｋ；ｍ−ｓｅｔ＿ｍｏｎｉｔｏｒ；そして、ｘ−ｒａｉｓｅ＿ｅｘｃｅｐｔｉｏｎ。
【００４７】
移行動作の相互作用は、与えられたオブジェクトの状況の中で述べる。 最初に、オブジェクトは、ロックがかかってない状態Ａ ６４にある。 スレッドが初めてオブジェクトをロックしようとするときには、オブジェクトのロック状態をとることは、単純ロック状態Ｂ ６６に変わり、ｓｅｔ＿ｓｉｍｐｌｅ＿ｌｏｃｋ（ｓ）動作が実行される。 更に、別のスレッドが、単純ロック状態Ｂ ６６にある同じオブジェクトをロックしようとすると、オブジェクトロック状態は、拡張ロック状態'Ｃ'６８に変えられる。 オブジェクトは、他のスレッドが更にそれをロックしようとするまで、拡張状態Ｃ ６８のままである。 第２のスレッドがオブジェクトをロックしようとする一方で、別のスレッドがロックを支配していたら、いかなる与えられた状態からも、モニター状態Ｄ ７０が生成されることができる。 いかなる状態からも、モニターＤ ７０状態へ移行することができる。 同期したメソッドから出ることは、モニター状態Ｄ ７０または拡張状態Ｃ ６８からの移行を引き起こす。
【００４８】
与えられた状態から他の状態への移行は、唯一、例外状態Ｅ ７２を除いて、可能である。 例外信号が発せられると、オブジェクトは例外状態Ｅ ７２になる。 移行インストラクションまたはコマンドをそれに送ることによって例外状態Ｅ７２を出ることは不可能である。 全ての他の状態、すなわちＡ〜Ｄにとっては、他の状態またはそれ自体への移行は、適当な移行インストラクションまたは信号を送ることによって可能である。
【００４９】
図８は、マルチスレッドアプリケーションを加速するための最適化されたオートメーションを示す。 それは、バーチャルマシン１０（図１参照）内で用いられる同期技術を改善する。 図７に示したオートメーションから単純ロック状態Ｂ ６６を取り除くことによって、スレッディングモデルは、単純ロック状態Ｂ ６６から、および、単純ロック状態Ｂ ６６への移行を避け、したがって、ロックがかかってない状態Ａ ６４から、直接、拡張ロック状態Ｃ ６８に行く。 次に述べるように、深さインジケータ（図示せず）は、ロックレベルを示すために用いられる。
【００５０】
オブジェクトは、スレッドが初めてそれをロックしようとするとき、ロックがかかってない状態Ａ ６４から単純ロック状態Ｂ ６６（図７参照）に移る。 この場合、深さ（オブジェクトがロックされた回数）は１にセットされる。 オブジェクトは、上述したように、単純ロック状態Ｂ ６６から拡張ロック状態Ｃ ６８に移る。 スレッドが２回目にオブジェクトをロックしようとすると、深さは２にインクリメントされ、拡張ロック状態Ｃ ６８への移行を示す。 拡張ロック状態Ｃ ６８は、深さレベルが１以上の状態と考えることができる。 従って、深さインジケータを用いて、単純ロック状態Ｂ ６６の必要性を除去することができる。
【００５１】
単純ロック状態の除去は、スレッド性能を改善する。 なぜなら、コードのいくつかの部分の実行を避けることができるからである。 更に、単純ロックから拡張ロックへの移行が避けられ、スレッディングモデルをより効率的にする。
【００５２】
図９は、継承されたメソッドの呼び出しの改良を示すために用いられた典型的なクラス階層７６である。 ここでは、ベースクラスはクラスＰ ７８である。 クラスＱ ８０はクラスＰ ７８を継承して拡張する。 クラスＱ ８０はクラスＰ７８の継承されたメソッドｍ（）を拡張する。 クラスＲ ８２はクラス０ ８０を拡張し、クラスＳ ８４は更にクラスＰ ８２を拡張する。 型Ｓ（）の新しいオブジェクト'ｏ'は、クラスＳ ８４のｍａｉｎ（）メソッドの中でインスタンス化される。 継承されたメソッド'ｍ'は、更なる説明において加速の結果を示すための例として用いられる。 当業者であれば、クラス階層７６の上記の説明が、典型的なクラス階層の例であり、同じものが、いかなる方法でも本発明を限定するものではないことを認めるであろう。 一般に、本発明において提示された技術は、およそ２７パーセントまでのＪＡＶＡ（登録商標）プログラムの実行速度における加速を提供することを示した。 上述したクラス階層は、以下の説明においてプロファイルが描かれ、本発明の原理を適用することによって得られた典型的な機能強化が示される。
【００５３】
図１０は、元のメソッド呼び出しと、本発明の実施形態における最適化されたメソッド呼び出しとの呼び出し時間を比較するための棒グラフ８６を示す。 元のメソッド呼び出し８８は、ＫＶＭの下で実行されたものとし、一方、最適化されたメソッド呼び出し９０は、本発明のバーチャルマシン１０（図１参照）を用いて実行された。 棒グラフ８６のＸ軸は、ハッシュテーブルサイズ４２（図２Ｂ参照）を表し、Ｙ軸は、実行時間を表している。 ハッシュテーブル４２のサイズは、Ｘ軸上に示したように、１１ユニットから２９ユニットまで変化させられる。 最適化されたメソッド呼び出し９０は、ハッシュテーブル４２の全ての範囲にわたる改良された性能を示す。 Ｙ軸上に示したように、最適化されたメソッド呼び出し９０は、およそ５００ミリ秒を必要とする一方で、元のメソッド呼び出し８８は、同じメソッド呼び出しのために、およそ８００ミリ秒を必要とする。 このように、本発明の最適化されたメソッド呼び出し９０は、ＫＶＭメソッド呼び出しと比べて、改良された実行時間をもたらす。 当業者であれば、メソッド呼び出し時間の上記の比較が、実例であり、かつ典型的な性質であり、同じものは、いかなる方法でも本発明を限定するものではないことを理解するであろう。
【００５４】
図１１は、本発明の実施形態における加速／スピードアップ率を示しているパイチャート９２を示す。 マーカー９４は、ハッシュテーブル４２（図２Ｂ参照）のサイズを示し、結果としての加速は、対応するパイスライス９６として示される。 パイチャート９２は、図９に示し、かつ上述したコードの部分的引用に対して、プロファイルを描く技術のアプリケーションを反映する。 パイチャート９２は、ハッシュテーブル４２のサイズが最適のときに、より優れた実行時間が可能であることを示している。 この例においては、ハッシュテーブルの最適なサイズは、およそ２９ユニットであり、これは、実行時間が２７．９１ユニットのものに対応する。 これは、ハッシュテーブル４２のサイズが１１であり、実行時間が３５．９７に増加したときの状況と比較することができる。 本発明の柔軟な技術を適用すると、最適なハッシュテーブル４２のサイズを選ぶことが可能であり、それは最小限の衝突という結果になり、そのうえ必要なメモリ設置面積を減らす。 次に、本発明の一般的な特性について説明する。
【００５５】
本発明は、大きいシステムと比べて計算資源が制限された組み込みシステム内に実装されるオブジェクト指向システムに適用されることが好ましい。 組み込みシステム内での機能強化は、システムが一般にリアルタイムであるので、望ましい。 これは、より優れた望ましい実行時間をもたらす。 更に、本発明は、柔軟な方法を提供して、性能を改良する技術の資源要求を最適化する。 これは、組み込みシステムにおける、もう一つの望ましい特性である。 なぜなら、それらは、限られたメモリおよび処理パワーしか持っていないからである。 当業者であれば、組み込みシステムという用語が、一般的に用いられ、同じものが、ある程度の資源の制約の下で動作する、いかなるシステムも含むことを認めるであろう。 例えば、計算資源が限られた性質のセルホン内のＪＶＭを走らせているシステムまたは腕時計ベースのアプリケーションも含む。
【００５６】
本発明の説明は、単なる具体例であり、したがって、本発明の要旨から逸脱しない変形は本発明の範囲内であるつもりである。 このような変形は、本発明の精神および範囲からの逸脱とみなされるべきではない。
【図面の簡単な説明】
【図１】本発明の実施形態におけるバーチャルマシンのブロック図である。
【図２Ａ】典型的なクラス階層を示す。
【図２Ｂ】ルックアップの加速のプロセスにおいて用いられるメソッドハッシュテーブルを示す。
【図３】典型的なメソッドハッシュテーブル構築手順を示す。
【図４】ハッシュテーブル内でメソッドを検索するための典型的なハッシュルックアップ手順を示す。
【図５】メソッド呼び出しを格納するための既知のキャッシュレイアウトを示す。
【図６】レシーバとのリンクを含むキャッシュエントリを示す。
【図７】既知のスレッディングモデルを表す第１のオートメーションを示す。
【図８】マルチスレッドアプリケーションを加速するための最適化されたオートメーションを示す。
【図９】継承されたメソッドの呼び出しにおける改良を示すために用いられた典型的なクラス階層７６である。
【図１０】本発明の実施形態におけるメソッド呼び出し時間を比較している棒グラフを示す。
【図１１】本発明の実施形態における加速／スピードアップ率を示しているパイチャートを示す。
【符号の説明】
１０ バーチャルマシン１２ オペレーティングシステム１４ ローダー１６ ハッシュビルダー１８ ハッシュルックアップ２０ ベリファイヤ２２ 言語クラスライブラリ２４ ネイティブクラスライブラリ２６ インタープリタ２８ キャッシュ３０ キャッシュハンドラ３２ ヒープ管理およびガーベッジコレクタモジュール３４ スレッドマネージャ４８、５８ キャッシュエントリ５０ コンテンツリンク５２ ｃｏｄｅＬｏｃ
５４ オリジナルパラメータ５６ オリジナルインストラクション６０ レシーバポインタ