(57)【特許請求の範囲】
【請求項１】
クラスベースのオブジェクト指向プログラミング言語の処理系を実現する装置であって、
前記オブジェクト指向プログラミング言語における既存のクラスである第１のクラスと、当該第１のクラスのクラス外からアクセス可能なメンバを含むクラスであって、特定の用途に特化したクラスである第２のクラスとを記憶する記憶部と、
前記処理系を実現するソフトウェアにおける所定の命令に応じて、前記第２のクラスを用いた処理を行い、前記処理系で実行されるユーザプログラムにおける、前記第２のクラスのアイデンティティを調べる命令に応じて、前記第１のクラスを用いた処理を行う処理部と
を含む、装置。
【請求項２】
前記処理部は、
前記処理系を実現するソフトウェアにおける所定の命令に応じて、前記第２のクラスを用いた処理を行う第１の処理部と、
前記処理系で実行されるユーザプログラムにおける、前記第２のクラスのアイデンティティを調べる命令に応じて、前記第１のクラスを用いた処理を行う第２の処理部と
を含む、請求項１の装置。
【請求項３】
前記第２のクラスは、自身に含まれるクラス変数が前記第１のクラスにも含まれていれば、自身に含まれるクラス変数として、当該第１のクラスに含まれるクラス変数を参照する、請求項１の装置。
【請求項４】
前記第２のクラスは、クラス外からアクセス可能なインスタンス変数として、自身におけるメモリ上の相対的な配置位置が前記第１のクラスにおける同じインスタンス変数のメモリ上の相対的な配置位置と同じであるインスタンス変数を含む、請求項１の装置。
【請求項５】
前記第２のクラスは、クラス外からアクセス可能なインスタンスメソッドとして、自身のメソッドテーブルにおけるインデックスが前記第１のクラスのメソッドテーブルにおけるインデックスと同じであるインスタンスメソッドを含む、請求項１の装置。
【請求項６】
前記所定の命令は、前記第１のクラス及び前記第２のクラスからなるクラス群のインスタンスを生成する命令であり、
前記第１の処理部は、前記クラス群に格納される値から前記第２のクラスが適切であると判断できる場合は、当該第２のクラスのインスタンスを生成し、前記クラス群に格納される値から前記第２のクラスが適切であると判断できない場合は、前記第１のクラスのインスタンスを生成する、請求項２の装置。
【請求項７】
前記所定の命令は、前記第１のクラスのインスタンスを記憶するメモリのガベージコレクションを行う命令であり、
前記第１の処理部は、前記第１のクラスに格納された値から前記第２のクラスが適切であると判断できる場合は、当該第１のクラスのインスタンスを当該第２のクラスのインスタンスに変換する、請求項２の装置。
【請求項８】
Ｊａｖａ（登録商標）の処理系を実現する装置であって、
Ｊａｖａ（登録商標）における既存のクラスである第１のクラスと、当該第１のクラスのｐｒｉｖａｔｅ属性を持たないメンバを含むクラスであって、当該第１のクラスのフィールドのサイズを当該第１のクラスに格納される値に応じて削減したクラスである第２のクラスとを記憶する記憶部と、
前記処理系を実現するソフトウェアにおける所定の命令を、前記第２のクラスを用いて処理し、前記処理系で実行されるユーザプログラムにおける、前記第２のクラスのインスタンスを引数としたｉｎｓｔａｎｃｅｏｆバイトコード及びｃｈｅｃｋｃａｓｔバイトコード、並びに、前記第２のクラスを引数としたＣｌａｓｓ．ｇｅｔＮａｍｅ（）メソッドの何れかに応じて、前記第１のクラスが保持する情報を返す処理を行う処理部と
を含む、装置。
【請求項９】
クラスベースのオブジェクト指向プログラミング言語の処理系を実現するためにコンピュータにより実行される方法であって、
前記オブジェクト指向プログラミング言語における既存のクラスである第１のクラスと、当該第１のクラスのクラス外からアクセス可能なメンバを含むクラスであって、特定の用途に特化したクラスである第２のクラスとを用意するステップと、
前記処理系を実現するソフトウェアにおける所定の命令に応じて、前記第２のクラスを用いた処理を行うステップと、
前記処理系で実行されるユーザプログラムにおける、前記第２のクラスのアイデンティティを調べる命令に応じて、前記第１のクラスを用いた処理を行うステップと
を含む、方法。
【請求項１０】
クラスベースのオブジェクト指向プログラミング言語の処理系を実現する装置として、コンピュータを機能させるプログラムであって、
前記コンピュータを、
前記オブジェクト指向プログラミング言語における既存のクラスである第１のクラスと、当該第１のクラスのクラス外からアクセス可能なメンバを含むクラスであって、特定の用途に特化したクラスである第２のクラスとを記憶する記憶部と、
前記処理系を実現するソフトウェアにおける所定の命令に応じて、前記第２のクラスを用いた処理を行い、前記処理系で実行されるユーザプログラムにおける、前記第２のクラスのアイデンティティを調べる命令に応じて、前記第１のクラスを用いた処理を行う処理部と
して機能させる、プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プログラミング言語の処理系を実現する装置及び方法に関する。特に、本発明は、クラスベースのオブジェクト指向プログラミング言語の処理系を実現する装置及び方法に関する。
【背景技術】
【０００２】
クラスベースのオブジェクト指向プログラミング言語において、オブジェクトの実装はそのオブジェクトのクラス定義によって決まる。
【０００３】
ここで、クラスベースのオブジェクト指向プログラミング言語におけるクラスに関連する技術は、公報記載の技術として知られている（例えば、特許文献１〜５参照）。
【０００４】
特許文献１は、はじめにサブクラス作成部は選択した複数のオブジェクトに共通する属性、メソッドを含むスーパークラスを作成し、次にサブクラスに指定したオブジェクトの共通なドメインをドメインキーワードデータベースを検索し、ドメインネームのリストを作成し、次にサブクラス作成部は非共通部分から選択したオブジェクトより、スーパークラスに用いた属性、メソッドを削除したサブクラスを作成し、この作成したサブクラスをスーパークラスに結合し、選択したオブジェクトを非共通部分から削除し、次にサブクラスモデル登録部は、サブクラス作成部で作成したサブクラス構造(スーパークラスとサブクラスの結合モデル)をスーパークラスの名前を付けたドメインモデルとしてドメインモデルデータベースに登録し、次にサブクラス化結合図生成部において、サブクラス作成部で作成したサブクラス構造のオブジェクト群と、サブクラス化を行わなかった非共通部分のオブジェクト群を、それぞれの関連データに基づいて同類部分抽出部で抽出した共通部分に結合し、サブクラス化構造を有する包含オブジェクト図を作成することを開示する。
【０００５】
特許文献２は、ＩＢＭシステム・オブジェクト・モデル製品SOMobjectsは、オブジェクト指向フレームワークであり、このフレームワークは、クラスと、そのクラスに属するオブジェクトとから構成され、SOMobjectsでは、クラスはそれ自体がオブジェクトであり、オブジェクトのすべての特徴を有し、クラスは、そのクラス中の各オブジェクトが応答するメソッドまたは挙動（振舞い）に関する情報を含むという追加の特徴を有し、オブジェクトは、それがあるメソッド名用のプロセス・コードを含む場合に、そのメソッドに応答するものとみなされ、クラスは、そのクラス中のオブジェクトがあるメソッドに応答するとき、そのメソッドをサポートするとみなされ、あるクラスによってサポートされるメソッドとは、そのクラスのために明示的に定義されたもの、およびそのクラスの親クラスであるクラスから継承されたものであり、オブジェクトは、そのクラスによってサポートされるメソッドだけに応答することを開示する。
【０００６】
特許文献３は、オブジェクト指向プログラミング言語を拡張して、親クラスからの実施の継承を示さずにサブクラス化することによって、クラスの親クラスからのインタフェースの継承を示す修飾子をクラスごとに設けることを開示する。
【０００７】
特許文献４は、アプリケーションに関連付けられたクラスをロードするように適合されたクラスローダを開示する。
【０００８】
特許文献５は、入力デバイスによって入力されたユーザの指示を入力解釈部で解釈し、命令を表示部に送り、表示部を通じてオブジェクトモデル格納部に格納されるモデル情報を参照しながらグラフ構造でディスプレイに表示するに当たり、クラス節表示部でクラスを節として表示させ、関連枝表示部で関連を枝として表示させ、メンバ表示部でクラスが持つメンバを表示させ、汎化クラス節表示部により汎化／特化の関係にあるクラス、例えば親クラスと子クラスのそれぞれに対応する節を、親クラスが子クラスの節内になるように、表示させるオブジェクトモデル表示装置を開示する。
【０００９】
また、プログラムを特殊化することにより最適化する技術も、公報記載の技術として知られている（例えば、特許文献６、７参照）。
【００１０】
特許文献６は、コンパイルの対象であるプログラムにおける所定の命令のパラメータを特定の状態に固定することによりこのプログラムの実行速度をどれだけ向上させることができるかを解析する影響度解析部と、このプログラムを実行した場合に、この影響度解析部にて解析された命令のパラメータが取り得る状態ごとの出現頻度の統計を取り、得られた統計情報に基づいてこの命令のパラメータをどの状態に固定するかを決定する特殊化データ選択部と、この影響度解析部及び特殊化データ選択部による処理結果に基づいて、このプログラム中に、所定の命令のパラメータを特定の状態に固定した特殊化されたパスを生成する特殊化コンパイル処理部とを備えるコンパイラを開示する。
【００１１】
特許文献７は、最適化の対象プログラムにおいて、変数又は変数により指定される記憶領域の内容を更新する更新命令を検出する更新命令検出部と、対象プログラムにおいて、他の命令列に制御を移す制御移行命令により制御が移行されて、変数又は記憶領域の内容に応じて異なる処理を行う命令列を検出する命令列検出部と、検出した当該命令列を、変数又は記憶領域の内容が予め定められた特定の内容である場合の処理に最適化してコンパイルする命令列コンパイル部と、対象プログラムにおける、更新命令から制御移行命令までの間に、変数の内容又は記憶領域の内容が特定の内容である場合に実行され、制御移行命令の移行先アドレスを、命令列コンパイル部により最適化された命令列のアドレスに設定する設定命令を生成する設定命令生成部とを備える最適化コンパイラを開示する。
【先行技術文献】
【特許文献】
【００１２】
【特許文献１】特開平１１−８５４９２号公報
【特許文献２】特開平７−１３７６６号公報
【特許文献３】特開平６−１０３０７５号公報
【特許文献４】特開２０１１−２３３１７１号公報
【特許文献５】特開平６−２５１１６３号公報
【特許文献６】特開２００２−２５９１３５号公報
【特許文献７】特開２００５−２１５８３０号公報
【発明の概要】
【発明が解決しようとする課題】
【００１３】
上述したように、クラスベースのオブジェクト指向プログラミング言語において、オブジェクトの実装はそのオブジェクトのクラス定義によって決まる。
【００１４】
例えば、オブジェクトのメモリ上のレイアウトもそのオブジェクトのクラス定義によって決まる。従って、オブジェクトの変数を記憶する領域はクラス定義によって決まったメモリ上の位置に確保されることになる。しかしながら、オブジェクトの一部の変数はその値によっては使われない場合もあり、その場合は、その変数を記憶する領域をメモリ上に確保しないようにすれば、メモリ使用量を削減することができる。
【００１５】
このように１つのクラスに対して複数のオブジェクトレイアウトを持ちたい場合、例えばＪａｖａ（登録商標）では、インターフェースが使用される。しかしながら、Ｊａｖａ（登録商標）システムクラスのような、既に多くのソフトウェアで使用されているクラスの実装を変更すると、既存のソフトウェアが動作しなくなる。また、Ｊａｖａ（登録商標）システムクラスに対して外部仕様が変わる変更を行うと、Ｊａｖａ（登録商標）としての互換性を保てなくなってしまう。尚、Ｒｕｂｙの特異クラス、ＪａｖａＳｃｒｉｐｔ（登録商標）等のテンプレートベースの言語実装等、オブジェクトごとに独自のクラスを持つことができる言語はあるが、プログラマが明示的に使い分ける必要があり、既存のコードを最適化するためには使えない。
【００１６】
以上述べた通り、従来から、既存ソフトウェアと互換性を保ったまま、オブジェクトのメモリ上のレイアウトを最適化したい、という要求があった。
【００１７】
即ち、より一般化して言えば、従来から、既存ソフトウェアとの互換性を保ったまま、オブジェクトの実装をより適切なものとしたい、という要求があった。しかしながら、これまで、このような要求に十分に応えられていないという課題があった。
【００１８】
尚、特許文献１〜５の技術は、クラスベースのオブジェクト指向プログラミング言語におけるクラスに関連する技術であるが、このような課題を解決するための手段を提示するものではない。また、特許文献６、７の技術は、プログラムを最適化するものであるが、これらの技術も同様に上記課題を解決できない。
【００１９】
本発明の目的は、既存ソフトウェアとの互換性を保ったまま、オブジェクトの実装をより適切なものとすることにある。
【課題を解決するための手段】
【００２０】
かかる目的のもと、本発明は、クラスベースのオブジェクト指向プログラミング言語の処理系を実現する装置であって、オブジェクト指向プログラミング言語における既存のクラスである第１のクラスと、第１のクラスのクラス外からアクセス可能なメンバを含むクラスであって、特定の用途に特化したクラスである第２のクラスとを記憶する記憶部と、処理系を実現するソフトウェアにおける所定の命令に応じて、第２のクラスを用いた処理を行い、処理系で実行されるユーザプログラムにおける、第２のクラスのアイデンティティを調べる命令に応じて、第１のクラスを用いた処理を行う処理部とを含む、装置を提供する。処理部は、処理系を実現するソフトウェアにおける所定の命令に応じて、第２のクラスを用いた処理を行う第１の処理部と、処理系で実行されるユーザプログラムにおける、第２のクラスのアイデンティティを調べる命令に応じて、第１のクラスを用いた処理を行う第２の処理部とを含む、ものであってよい。
【００２１】
ここで、この装置において、第２のクラスは、自身に含まれるクラス変数が第１のクラスにも含まれていれば、自身に含まれるクラス変数として、第１のクラスに含まれるクラス変数を参照する、ものであってよい。
【００２２】
また、第２のクラスは、クラス外からアクセス可能なインスタンス変数として、自身における相対的な配置位置が第１のクラスにおける相対的な配置位置と同じであるインスタンス変数を含む、ものであってよい。
【００２３】
更に、第２のクラスは、クラス外からアクセス可能なインスタンスメソッドとして、自身のメソッドテーブルにおけるインデックスが第１のクラスのメソッドテーブルにおけるインデックスと同じであるインスタンスメソッドを含む、ものであってよい。
【００２４】
また、この装置において、所定の命令は、第１のクラス及び第２のクラスからなるクラス群のインスタンスを生成する命令であり、第１の処理部は、クラス群に格納される値から第２のクラスが適切であると判断できる場合は、第２のクラスのインスタンスを生成し、クラス群に格納される値から第２のクラスが適切であると判断できない場合は、第１のクラスのインスタンスを生成する、ものであってもよい。
【００２５】
更に、所定の命令は、第１のクラスのインスタンスを記憶するメモリのガベージコレクションを行う命令であり、第１の処理部は、第１のクラスに格納された値から第２のクラスが適切であると判断できる場合は、第１のクラスのインスタンスを第２のクラスのインスタンスに変換する、ものであってよい。
【００２６】
また、本発明は、Ｊａｖａ（登録商標）の処理系を実現する装置であって、Ｊａｖａ（登録商標）における既存のクラスである第１のクラスと、第１のクラスのｐｒｉｖａｔｅ属性を持たないメンバを含むクラスであって、第１のクラスのフィールドのサイズを第１のクラスに格納される値に応じて削減したクラスである第２のクラスとを記憶する記憶部と、処理系を実現するソフトウェアにおける所定の命令を、第２のクラスを用いて処理し、処理系で実行されるユーザプログラムにおける、第２のクラスのインスタンスを引数としたｉｎｓｔａｎｃｅｏｆバイトコード及びｃｈｅｃｋｃａｓｔバイトコード、並びに、第２のクラスを引数としたＣｌａｓｓ．ｇｅｔＮａｍｅ（）メソッドの何れかに応じて、第１のクラスが保持する情報を返す処理を行う処理部とを含む、装置も提供する。
【００２７】
更に、本発明は、クラスベースのオブジェクト指向プログラミング言語の処理系を実現するためにコンピュータにより実行される方法であって、オブジェクト指向プログラミング言語における既存のクラスである第１のクラスと、第１のクラスのクラス外からアクセス可能なメンバを含むクラスであって、特定の用途に特化したクラスである第２のクラスとを用意するステップと、処理系を実現するソフトウェアにおける所定の命令に応じて、第２のクラスを用いた処理を行うステップと、処理系で実行されるユーザプログラムにおける、第２のクラスのアイデンティティを調べる命令に応じて、第１のクラスを用いた処理を行うステップとを含む、方法も提供する。
【００２８】
更にまた、本発明は、クラスベースのオブジェクト指向プログラミング言語の処理系を実現する装置として、コンピュータを機能させるプログラムであって、コンピュータを、オブジェクト指向プログラミング言語における既存のクラスである第１のクラスと、第１のクラスのクラス外からアクセス可能なメンバを含むクラスであって、特定の用途に特化したクラスである第２のクラスとを記憶する記憶部と、処理系を実現するソフトウェアにおける所定の命令に応じて、第２のクラスを用いた処理を行い、処理系で実行されるユーザプログラムにおける、第２のクラスのアイデンティティを調べる命令に応じて、第１のクラスを用いた処理を行う処理部として機能させる、プログラムも提供する。
【発明の効果】
【００２９】
本発明によれば、既存ソフトウェアとの互換性を保ったまま、オブジェクトの実装をより適切なものとすることができる。
【図面の簡単な説明】
【００３０】
【図１】本発明の実施の形態におけるコンピュータのハードウェア構成例を示した図である。
【図２】本発明の実施の形態におけるコンピュータの機能構成例を示したブロック図である。
【図３】（ａ）〜（ｇ）は、代表クラス及び特殊クラスの第１の例を示した図である。
【図４】（ａ）〜（ｄ）は、代表クラス及び特殊クラスの第２の例を示した図である。
【図５】（ａ）〜（ｃ）は、代表クラス及び特殊クラスの第３の例を示した図である。
【図６】本発明の実施の形態におけるＪＶＭのオブジェクト生成時の動作例を示したフローチャートである。
【図７】本実施の形態におけるＪＶＭのＧＣ（ガベージコレクション）時の動作例を示したフローチャートである。
【図８】本実施の形態におけるＪＶＭのクラスメタ情報提供時の動作例を示したフローチャートである。
【図９】本発明の実施の形態の効果を示した図である。
【発明を実施するための形態】
【００３１】
以下、添付図面を参照して、本発明の実施の形態について詳細に説明する。
【００３２】
［コンピュータのハードウェア構成］
図１は、本実施の形態におけるコンピュータ１０のハードウェア構成例を示した図である。図示するように、コンピュータ１０は、ＣＰＵ１１と、ＲＡＭ（Random Access Memory）１２と、ＨＤＤ（Hard Disk Drive）１３と、キーボード１４と、マウス１５と、ディスプレイ１６と、通信インターフェース１７とが、システムバス１８に接続されることにより、構成されている。
【００３３】
ＣＰＵ１１は、これには限定されないが、好適には、３２ビット又は６４ビットのアーキテクチャに基づくものである。例えば、ＩＢＭ社のＰＯＷＥＲ８（商標）、ＰＯＷＥＲ７（商標）、インテル社のＣｏｒｅ（商標）ｉ３、Ｃｏｒｅ（商標）ｉ５、Ｃｏｒｅ（商標）ｉ７、Ｘｅｏｎ（登録商標）、ＡＭＤ社のＡｔｈｌｏｎ（商標）、Ｐｈｅｎｏｍ（商標）、Ｓｅｍｐｒｏｎ（商標）等を用いるとよい。
【００３４】
ＲＡＭ１２は、これには限定されないが、好適には、８ＧＢ以上の容量、より好ましくは、１６ＧＢ以上の容量を持つメモリである。
【００３５】
ＨＤＤ１３は、ＯＳ（Operating System）を格納する。ここで、ＯＳは、ＣＰＵ１１に適合する任意のものでよい。例えば、Ｌｉｎｕｘ（登録商標）、ＩＢＭ社のＡＩＸ（登録商標）、マイクロソフト社のＷｉｎｄｏｗｓ（登録商標）７、Ｗｉｎｄｏｗｓ（登録商標）８、Ｗｉｎｄｏｗｓ（登録商標）２００３サーバ、アップルコンピュータ社のＭａｃ  ＯＳ（登録商標）等を用いるとよい。
【００３６】
ＨＤＤ１３はまた、ＩＢＭ社のＷｅｂＳｐｈｅｒｅ（登録商標）アプリケーションサーバ等の、コンピュータ１０をウェブサーバとして動作させるためのプログラムを格納する。そして、このプログラムは、コンピュータ１０の起動時に、ＲＡＭ１２にロードされる。
【００３７】
キーボード１４及びマウス１５は、ＯＳが提供するグラフィックユーザインターフェースに従い、ディスプレイ１６に表示されたアイコン、タスクバー、テキストボックス等のグラフィックオブジェクトを操作するために用いられる。
【００３８】
ディスプレイ１６は、これには限定されないが、好適には、１０２４×７６８以上の解像度を持ち、３２ビットトゥルーカラーのＬＣＤモニタである。ディスプレイ１６は、各種プログラムによる動作の結果を表示するために用いられる。
【００３９】
通信インターフェース１７は、これには限定されないが、好適には、イーサネット（登録商標）プロトコルにより、ネットワークと接続されている。通信インターフェース１７は、クライアントコンピュータ（図示せず）からＷｅｂＳｐｈｅｒｅ（登録商標）アプリケーションサーバ等が提供する機能により、ＴＣＰ／ＩＰ等の通信プロトコルに従い、処理リクエストを受け取り、或いは処理結果をクライアントコンピュータ（図示せず）に返す。
【００４０】
［本実施の形態の概要］
図１に示したコンピュータ１０が、クラスベースのオブジェクト指向プログラミング言語で記述されたプログラムを実行する場合を考える。その場合に、本実施の形態では、ユーザプログラムからは同一のクラスとして扱われるが、独立した実装を持つクラス群を導入する。即ち、既存のクラスに対して、コンピュータ１０が提供する複数の実装を持つクラス群を用意する。本明細書では、この既存のクラスを、外部インターフェースを定義する「代表クラス」と呼ぶ。また、それ以外の実装を持つクラスを「特殊クラス」と呼ぶ。
【００４１】
ここで、代表クラスとこれに対する特殊クラスとの間には、以下の関係があるものとする。
【００４２】
第１の関係は、特殊クラスのサブクラスを作成することはできないが、代表クラスのサブクラスに対して新たに特殊クラスを作成することはできる、というものである。
【００４３】
第２の関係は、代表クラス及び特殊クラス群は互いに全メンバにアクセスすることができる、というものである。具体的には、代表クラスは特殊クラスの全メンバにアクセス可能であり、特殊クラスは代表クラスの全メンバにアクセス可能であり、代表クラスに対する特殊クラスはその代表クラスに対する他の特殊クラス（兄弟の特殊クラス）の全メンバにアクセス可能である。また、第２の関係は、特殊クラスは代表クラス及び特殊クラス群以外のクラスからは不可視である、という関係も含む。
【００４４】
また、特殊クラスの変数及びメソッドの定義は、代表クラスとこれに対する特殊クラスとの間で不整合が生じないように、以下の制約を満たすものとする。
【００４５】
第１の制約は、代表クラスに存在するクラス変数を特殊クラスで参照する際は、常に代表クラスのクラス変数を参照する、というものである。即ち、クラス変数を記憶するメモリ領域は、代表クラスと全ての特殊クラスとで共有される。
【００４６】
第２の制約は、ｐｒｉｖａｔｅでないインスタンス変数は、代表クラス及び特殊クラス群全体で同じレイアウトに配置する、というものである。即ち、ｐｒｉｖａｔｅなインスタンス変数以外のインスタンス変数のメモリ配置を、代表クラスと全ての特殊クラスとで同一とする。
【００４７】
従って、第１の制約と第２の制約とから、ｐｒｉｖａｔｅなインスタンス変数以外の変数は代表クラスと特殊クラスとで同じである、と言うことができる。
【００４８】
第３の制約は、ｐｒｉｖａｔｅでないインスタンスメソッドは、代表クラス及び特殊クラス群全体で同一のメソッドテーブル内インデックスを持つ、というものである。
【００４９】
第４の制約は、代表クラスに存在する変数又はメソッドを特殊クラスで削除できるのは、その変数又はメソッドがｐｒｉｖａｔｅの場合のみである、という制約である。即ち、代表クラスに存在するｐｒｉｖａｔｅでない変数を削除することや、代表クラスに存在するｐｒｉｖａｔｅでないメソッドを削除することはできない。
【００５０】
尚、特殊クラスで変数又はメソッドを追加することは可能である。
【００５１】
そして、本実施の形態では、クラスのオブジェクトを生成する際に、初期値から代表クラス又は何れかの特殊クラスを選択する。即ち、初期値から適切な実装が判断できる場合は、その実装に対する特殊クラスのインスタンスを生成する。一方、初期値から適切な実装が判断できない場合は、代表クラスのインスタンスを生成する。
【００５２】
或いは、ＧＣ（ガベージコレクション）を行う際に、代表クラスのインスタンスを適切な特殊クラスのインスタンスに変更したり、特殊クラスのインスタンスをより適切な特殊クラスのインスタンスに変更したりしてもよい。例えば、ＧＣがコピーイング方式であれば、オブジェクトをコピーする際に、そのようなインスタンスの変更を行う。また、ＧＣがマークアンドスイープ方式であれば、コンパクションを行う際に、そのようなインスタンスの変更を行う。
【００５３】
また、本実施の形態において、実行時システムは、ユーザプログラムがクラスメタ情報（例えば、クラスのアイデンティティの情報）を参照する場合に、常に代表クラスのクラスメタ情報を返す。具体的には、ｉｎｓｔａｎｃｅｏｆバイトコード、ｃｈｅｃｋｃａｓｔバイトコード、及び、Ｃｌａｓｓ．ｇｅｔＮａｍｅ（）メソッド等の命令に対し、引数として特殊クラスが渡された場合でも代表クラスが渡されたものとして動作することで、常に代表クラスのクラスメタ情報を返す。これにより、ユーザプログラムから特殊クラスの存在を隠す。
【００５４】
以下では、実行時システムとしてＪａｖａ（登録商標）仮想マシン（以下、「ＪＶＭ」という）を例にとり、説明する。
【００５５】
［本実施の形態におけるコンピュータの機能構成］
図２は、図１に示したコンピュータ１０のこのような動作を行うための機能構成例を示した図である。図示するように、コンピュータ１０は、クラスファイル記憶部２０と、ＪＶＭ３０とを含む。
【００５６】
クラスファイル記憶部２０は、ＪＶＭ３０上で実行可能なＪａｖａ（登録商標）バイトコードを含む、拡張子「．ｃｌａｓｓ」が付いたファイルであるクラスファイルを記憶する。ここでは、代表クラスのクラスファイル（以下、「代表クラスファイル」という）４１と、特殊クラスのクラスファイル（以下、「特殊クラスファイル」という）４２とを記憶している。この場合、代表クラスファイル４１のファイル名は「Ｃ．ｃｌａｓｓ」とし、特殊クラスファイル４２のファイル名は「Ｃｘ．ｃｌａｓｓ」としている。ここで、クラスファイル記憶部２０は、例えばＨＤＤ１３（図１参照）によって実現される。
【００５７】
ＪＶＭ３０は、Ｊａｖａ（登録商標）バイトコードをこれが移植されたプラットフォームのネイティブコードに変換して実行するソフトウェアである。このようにＪＶＭ３０はソフトウェアであるが、ここでは、便宜上、このソフトウェアが動作する装置をＪＶＭ３０として示している。本実施の形態では、オブジェクト指向プログラミング言語の処理系を実現する装置の一例として、ＪＶＭ３０を設けている。
【００５８】
また、ＪＶＭ３０は、クラスデータ領域３１と、ヒープ領域３２とを含む。また、インタプリタ３３と、ＪＩＴ（Just-In-Time）コンパイラ３４と、マシン命令３５と、クラスローダ３６と、オブジェクトアロケータ３７と、ガベージコレクタ３８とを含む。
【００５９】
クラスデータ領域３１は、クラスファイル記憶部２０に記憶されたクラスファイルからロードしたクラスを記憶する。ここでは、まず、インタプリタ３３による実行又はＪＩＴコンパイラ３４によるコンパイルの対象であるメソッドを含むクラスをクラス５０としている。尚、このようなメソッドを、以下では「ユーザプログラム」とも称する。また、インタプリタ３３がこのメソッドを実行する際、又は、ＪＩＴコンパイラ３４がこのメソッドをコンパイルして得られるマシン命令３５が実行される際に呼び出されるクラスを代表クラス５１及び特殊クラス５２としている。この場合、代表クラスファイル４１のファイル名が「Ｃ．ｃｌａｓｓ」であり、特殊クラスファイル４２のファイル名が「Ｃｘ．ｃｌａｓｓ」であるので、代表クラス５１はクラスＣとし、特殊クラス５２はクラスＣｘとしている。本実施の形態では、既存のクラスである第１のクラスの一例として、代表クラス５１を用いており、特定の用途に特化したクラスである第２のクラスの一例として、特殊クラス５２を用いている。また、第１のクラスと第２のクラスとを記憶する記憶部の一例として、クラスデータ領域３１を設けている。
【００６０】
各クラスは、メタデータとクラス変数とメソッドとを含む。ここで、メタデータは、そのクラスのクラス名、そのクラスのインスタンス変数に関する情報（例えばインスタンス変数のオフセット）、そのクラスのインスタンスメソッドを呼び出すためのメソッドテーブル等を含む。また、前述の通り、代表クラスに存在するクラス変数を特殊クラスで参照する際は、常に代表クラスのクラス変数を参照する、という第１の制約がある。従って、代表クラス５１に存在するクラス変数は特殊クラス５２には存在していない。図では、このことを特殊クラス５２内のクラス変数をグレーアウトとすることにより示している。更に、前述の通り、ｐｒｉｖａｔｅでないインスタンスメソッドは、代表クラス及び特殊クラス群全体で同一のメソッドテーブル内インデックスを持つ、という第３の制約がある。代表クラス５１に存在するクラスメソッドを特殊クラス５２で参照する際は代表クラス５１のクラスメソッドを参照するので、代表クラス５１に存在するクラスメソッドは特殊クラス５２に存在しない。一方で、インスタンスメソッドは代表クラス５１及び特殊クラス５２の両方に存在する場合もある。従って、図では、特殊クラス５２内のメソッドをグレーアウトとしていない。
【００６１】
ヒープ領域３２は、クラスデータ領域３１に記憶されたクラスのオブジェクトを記憶する。ここでは、代表クラス５１に基づいてオブジェクトアロケータ３７により生成された代表クラスのオブジェクト（以下、「代表クラスオブジェクト」という）６１と、特殊クラス５２に基づいてオブジェクトアロケータ３７により生成された特殊クラスのオブジェクト（以下、「特殊クラスオブジェクト」という）６２とを記憶している。
【００６２】
各クラスのオブジェクトは、クラスを特定する情報と、インスタンス変数の情報とを含む。ここで、前述の通り、代表クラスに存在する変数又はメソッドを特殊クラスで削除できるのは、その変数又はメソッドがｐｒｉｖａｔｅの場合のみである、という第４の制約がある。従って、代表クラスオブジェクト６１に存在するｐｒｉｖａｔｅでないインスタンス変数である「ｐｕｂｌｉｃ＿ｆｉｅｌｄ１」は特殊クラスオブジェクト６２に存在するが、代表クラスオブジェクト６１に存在するｐｒｉｖａｔｅなインスタンス変数である「ｐｒｉｖａｔｅ＿ｆｉｅｌｄ２」は特殊クラスオブジェクト６２に存在していない。また、前述の通り、ｐｒｉｖａｔｅでないインスタンス変数は、代表クラス及び特殊クラス群全体で同じレイアウトに配置する、という第２の制約がある。従って、ｐｒｉｖａｔｅでないインスタンス変数である「ｐｕｂｌｉｃ＿ｆｉｅｌｄ１」は代表クラスオブジェクト６１及び特殊クラスオブジェクト６２の両方において１つ目に配置されている。尚、前述の通り、特殊クラスで変数を追加することは可能であるので、代表クラスオブジェクト６１に存在しないｐｒｉｖａｔｅなインスタンス変数である「ｐｒｉｖａｔｅ＿ｆｉｅｌｄＸ」が特殊クラスオブジェクト６２に存在している。
【００６３】
インタプリタ３３は、クラスデータ領域３１に記憶されたクラスのメソッドを逐次解釈しながら実行するプログラムである。ここでは、クラス５０のメソッドを実行することにより、クラスローダ３６に代表クラス５１又は特殊クラス５２のロードを要求し、オブジェクトアロケータ３７に代表クラスオブジェクト６１又は特殊クラスオブジェクト６２の生成を要求することを示している。また、クラス５０のメソッドを実行することにより、代表クラス５１又は特殊クラス５２のアイデンティティを調べる命令を検出すると、クラスローダ３６にその調査を要求して調査結果を受け取ることも示している。
【００６４】
ＪＩＴコンパイラ３４は、クラスデータ領域３１に記憶されたクラスのメソッドを実行直前にまとめてマシン命令３５に変換するプログラムである。ここでは、クラス５０のメソッドを変換することを示している。
【００６５】
マシン命令３５は、ＪＩＴコンパイラ３４がメソッドを変換することにより生成された、ＣＰＵ１１（図１参照）が直接実行する一連の命令である。ここでは、マシン命令３５が実行されることにより、クラスローダ３６に代表クラス５１又は特殊クラス５２のロードが要求され、オブジェクトアロケータ３７に代表クラスオブジェクト６１又は特殊クラスオブジェクト６２の生成が要求されることを示している。また、マシン命令３５が実行されることにより、代表クラス５１又は特殊クラス５２のアイデンティティを調べる命令が検出されると、クラスローダ３６にその調査が要求されて調査結果が受け取られることも示している。
【００６６】
クラスローダ３６は、インタプリタ３３又はマシン命令３５からクラスのロードを要求されると、そのクラスが既にＪＶＭ３０にロードされているかどうか調べる。そして、まだＪＶＭ３０にロードされていなければ、クラスファイル記憶部２０に記憶されたクラスファイルからそのクラスをＪＶＭ３０にロードする。尚、ここでロードされるクラスには、代表クラス５１と特殊クラス５２とがある。また、クラスローダ３６は、インタプリタ３３又はマシン命令３５から代表クラス５１又は特殊クラス５２のアイデンティティの調査が要求されると、その調査を行う。そして、インタプリタ３３又はマシン命令３５に調査結果を返す。尚、その際、特殊クラス５２のアイデンティティの調査が要求されたとしても、クラスローダ３６は、代表クラス５１の情報をインタプリタ３３又はマシン命令３５に返す。本実施の形態では、オブジェクト指向プログラミング言語の処理系で実行されるユーザプログラムにおけるクラスのアイデンティティを調べる命令に応じて処理を行う第２の処理部の一例として、クラスローダ３６を設けている。
【００６７】
オブジェクトアロケータ３７は、インタプリタ３３又はマシン命令３５からクラスのオブジェクトの生成が要求されると、クラスデータ領域３１に記憶されたクラスに基づいて、そのクラスのオブジェクトを生成する。その際、オブジェクトアロケータ３７は、代表クラス５１及び特殊クラス５２のうちインタプリタ３３又はマシン命令３５で決定されたクラスに基づいて、そのクラスのオブジェクトを生成する。そして、オブジェクトアロケータ３７は、生成したオブジェクトをヒープ領域３２に記憶する。本実施の形態では、オブジェクト指向プログラミング言語の処理系を実現するソフトウェアにおける所定の命令に応じて処理を行う第１の処理部の一例として、オブジェクトアロケータ３７を設けている。
【００６８】
ガベージコレクタ３８は、ヒープ領域３２のうち、不要になったオブジェクトが記憶された領域を解放するガベージコレクションを行う。その際、代表クラスオブジェクト６１を特殊クラスのオブジェクトに変換したり、特殊クラスオブジェクト６２を別の特殊クラスのオブジェクトに変換したりする。本実施の形態では、オブジェクト指向プログラミング言語の処理系を実現するソフトウェアにおける所定の命令に応じて処理を行う第１の処理部の一例として、ガベージコレクタ３８を設けている。
【００６９】
ここで、本実施の形態における、クラスローダ３６が変数の名前解決を行う際の実装上の工夫について詳しく述べる。
【００７０】
まず、クラス変数の名前解決について説明する。クラスローダ３６は、代表クラス５１に存在するクラス変数を特殊クラス５２で参照する際は、常に代表クラス５１のクラス変数のアドレスを取得する。また、クラスローダ３６は、特殊クラス５２で追加したｐｒｉｖａｔｅなクラス変数を参照する際は、特殊クラス５２独自のそのクラス変数のアドレスを取得する。
【００７１】
次に、インスタンス変数の名前解決について説明する。クラスローダ３６は、代表クラス５１に存在するｐｒｉｖａｔｅでないインスタンス変数のオフセットが、特殊クラス５２におけるそのインスタンス変数のオフセットと同じになるようにする。つまり、代表クラス５１及び特殊クラス５２のメタデータに同じオフセットの情報を格納する。これにより、オブジェクトアロケータ３７がオブジェクトをヒープ領域３２に記憶する際に、インスタンス変数は代表クラス５１及び特殊クラス５２において同じオフセットでオブジェクトの先頭に集めて配置される。また、クラスローダ３６は、代表クラス５１に存在するｐｒｉｖａｔｅなインスタンス変数を特殊クラス５２で参照する際は、特殊クラス５２のメタデータに独自に決めたオフセットの情報を格納する。更に、クラスローダ３６は、特殊クラス５２で追加したｐｒｉｖａｔｅな変数を参照する際も、特殊クラス５２のメタデータに独自に決めたオフセットの情報を格納する。
【００７２】
また、本実施の形態におけるクラスローダ３６がメソッドの名前解決を行う際の実装上の工夫について詳しく述べる。
【００７３】
まず、クラスメソッドの名前解決について説明する。クラスローダ３６は、代表クラス５１に存在するクラスメソッドを特殊クラス５２で参照する際は、特殊クラス５２独自のクラスメソッドのアドレスを取得する。但し、特殊クラス５２が代表クラス５１のクラスメソッドを共有する場合は、代表クラス５１のメソッドのアドレスを取得する。
【００７４】
次に、インスタンスメソッドのうちｖｉｒｔｕａｌメソッドの名前解決について説明する。クラスローダ３６は、代表クラス５１に存在するｖｉｒｔｕａｌメソッドを呼び出すためのメソッドテーブルのインデックスと、特殊クラス５２におけるそのｖｉｒｔｕａｌメソッドを呼び出すためのメソッドテーブルのインデックスとが同じになるようにする。つまり、代表クラス５１及び特殊クラス５２のメタデータ内のメソッドテーブルの同じインデックスにメソッドのアドレスを格納する。また、クラスローダ３６は、特殊クラス５２で追加したメソッドを参照する際は、特殊クラス５２のメタデータ内のメソッドテーブルにおいて、代表クラス５１に存在するメソッドのアドレスの後に、この追加したメソッドのアドレスを格納する。
【００７５】
次いで、インスタンスメソッドのうちｆｉｎａｌメソッドの名前解決について説明する。クラスローダ３６は、ＪＶＭ本来の実装では、アドレスを取得するが、本実施の形態では、ｖｉｒｔｕａｌメソッドの名前解決と同様の動作を行う。ＪＶＭ本来の実装では、ｆｉｎａｌメソッドがシステムに１つしかないのに対し、本実施の形態では、ｆｉｎａｌメソッドが代表クラス５１及び特殊クラス５２で異なる実装を取り得るからである。
【００７６】
即ち、インタプリタ３３又はＪＩＴコンパイラ３４の最適化を制限して、クラスメソッド及びｆｉｎａｌメソッドの実装が、ＪＶＭ３０上に複数存在することを許容する。
【００７７】
更に、本実施の形態における、クラスのアドレスを調整して効率を向上するための実装上の工夫について詳しく述べる。
【００７８】
まず、クラスローダ３６によるクラスのロードについて説明する。クラスローダ３６は、特殊クラス５２を、通常のクラスとは異なるアドレス範囲にロードする。その際、クラスローダ３６は、ビット演算を活用できるように、クラスをロードするアドレスを調整する。具体的には、代表クラス５１をロードするアドレスの上位Ｎビットと、特殊クラス５２をロードする全てのアドレスの上位Ｎビットとを、同じにする。そして、これに続く下位のＭビットにより、特殊クラス５２を識別できるようにする。尚、このとき、代表クラス５１をロードするアドレスの下位のＭビットは全て０とすればよい。また、上位Ｎビット及びこれに続く下位のＭビットよりも更に下位のビットは全て０とする。こうすることにより、ｉｎｓｔａｎｃｅｏｆバイトコード、ｃｈｅｃｋｃａｓｔバイトコード、Ｃｌａｓｓ．ｇｅｔＮａｍｅ（）メソッド等の命令に対しては、クラスがロードされたアドレスの上位Ｎビットのみを使って、代表クラス５１のクラスメタ情報を返すことが可能となる。また、クラス変数へのアクセス要求に対しては、クラスがロードされたアドレスの上位Ｎビットのみを取り出し、そこからのインデックスを使ってメモリを参照すれば、常に代表クラス５１のクラス変数にアクセスすることになる。
【００７９】
次に、ＪＩＴコンパイラ３４によるマシン命令３５の記憶について説明する。ＪＩＴコンパイラ３４は、マシン命令３５を記憶する領域として、固定長領域を特殊クラス５２の数だけつなげた領域を確保する。その際、特殊クラス５２のアドレスのＭビットの部分から、その特殊クラス５２に対する固定長領域のオフセットを計算する。より詳細には、各メソッドについて、全ての特殊クラス５２の数だけつなげた領域を確保する。ＪＶＭ３０は、特殊クラス５２の数は予め分かっているので、連続領域を確保することは可能である。特殊クラス５２のメソッドのコードは、代表クラス５１のメソッドテーブルから取得したアドレスに、特殊クラス５２のアドレスのＭビットの部分を適宜シフトした値を加えれば、算出できる。従って、アドレスのロードが必要な仮想呼び出し（virtual call）より速くメソッドを呼び出すことができる。尚、固定長領域に収まらなかったコードは、別の領域に適宜ジャンプすればよい。
【００８０】
［代表クラス及び特殊クラスの具体例］
図３（ａ）〜（ｇ）は、代表クラス５１及び特殊クラス５２の第１の例を示した図である。この第１の例は、既存のｊａｖａ．ｌａｎｇ．Ｓｔｒｉｎｇクラスを代表クラス５１とし、この代表クラス５１に対して、７つの特殊クラス５２を導入した例である。
【００８１】
図３（ａ）に、既存のｊａｖａ．ｌａｎｇ．Ｓｔｒｉｎｇクラスの実装を示す。この実装では、「ｖａｌｕｅ」フィールドがｃｈａｒ型の配列を指しており、この配列には任意の長さの１６ビット文字の列が格納される。しかしながら、これだと、文字の列が長くない場合には、配列に無駄が生じてしまうし、配列を用意することによりサイズ等の情報を記憶しなければならないという無駄もある。また、既存のｊａｖａ．ｌａｎｇ．Ｓｔｒｉｎｇクラスは、配列に格納される１６ビット文字の列から一部を切り出し易いように「ｏｆｆｓｅｔ」フィールドを持つが、このフィールドは使われないことも多いので、このフィールドを持たせておくことが無駄な場合もある。
【００８２】
例えば、８ビット文字の列であって文字の列の長さが７以下である「ａｂｃｄ」を格納する場合を考える。この場合は、図３（ｂ）のＶａｒｉａｎｔ＃１の実装に示すように、３２ビット×２の大きさのフィールドを用意し、このフィールドに「ｌｅｎｇｔｈ」（図では「Ｌｅｎ」と表記）、「ａ」、「ｂ」、「ｃ」、「ｄ」を格納すればよい。
【００８３】
また、８ビット文字の列であって文字の列の長さが１５以下である「ａｂｃｄｅｆｇｈｉ」を格納する場合を考える。この場合は、図３（ｃ）のＶａｒｉａｎｔ＃２の実装に示すように、３２ビット×４の大きさのフィールドを用意し、このフィールドに「ｌｅｎｇｔｈ」（図では「Ｌｅｎ」と表記）、「ａ」、「ｂ」、「ｃ」、「ｄ」、「ｅ」、「ｆ」、「ｇ」、「ｈ」、「ｉ」を格納すればよい。
【００８４】
更に、８ビット文字の列であって文字の列の長さが２３以下である「ａｂｃｄｅｆｇｈｉｊｋｌｍｎｏｐ」を格納する場合を考える。この場合は、図３（ｄ）のＶａｒｉａｎｔ＃３の実装に示すように、３２ビット×６の大きさのフィールドを用意し、このフィールドに「ｌｅｎｇｔｈ」（図では「Ｌｅｎ」と表記）、「ａ」、「ｂ」、「ｃ」、「ｄ」、「ｅ」、「ｆ」、「ｇ」、「ｈ」、「ｉ」、「ｊ」、「ｋ」、「ｌ」、「ｍ」、「ｎ」、「ｏ」、「ｐ」を格納すればよい。
【００８５】
一方、１７６ビットまでのＢＡＳＥ６４でエンコードされた文字列又は１６進文字列を格納する場合を考える。この場合は、図３（ｅ）のＶａｒｉａｎｔ＃４の実装に示すように、３２ビット×６の大きさのフィールドを用意する。そして、１つ目のフィールドの前半１６ビットに「ｌｅｎｇｔｈ」（図では「Ｌｅｎ」と表記）、ビット数（ｂｉｔｓ）を格納し、１つ目のフィールドの後半１６ビットから６つ目のフィールドに文字列に対応するバイナリデータを格納すればよい。
【００８６】
また、１４桁までのパック１０進数の文字の列及びこれと共に使われる普通の記号からなる「−１２３４５６．７８」を格納する場合を考える。この場合は、図３（ｆ）のＶａｒｉａｎｔ＃５の実装に示すように、３２ビット×２の大きさのフィールドを用意し、このフィールドに「ｌｅｎｇｔｈ」（図では「Ｌｅｎ」と表記）、「−１」、「２３」、「４５」、「６．」、「７８」を格納すればよい。
【００８７】
更に、３０桁までのパック１０進数の文字の列及びこれと共に使われる普通の記号からなる「＋８１−３−１２３４−５６７８」を格納する場合を考える。この場合は、図３（ｇ）のＶａｒｉａｎｔ＃６の実装に示すように、３２ビット×４の大きさのフィールドを用意し、このフィールドに「ｌｅｎｇｔｈ」（図では「Ｌｅｎ」と表記）、「＋８」、「１−」、「３−」、「１２」、「３４」、「−５」、「６７」、「８」を格納すればよい。
【００８８】
図４（ａ）〜（ｄ）は、代表クラス５１及び特殊クラス５２の第２の例を示した図である。この第２の例は、既存のｊａｖａ．ｍａｔｈ．ＢｉｇＩｎｔｅｇｅｒクラスを代表クラス５１とし、この代表クラス５１に対して、３つの特殊クラス５２を導入した例である。
【００８９】
図４（ａ）に、既存のｊａｖａ．ｍａｔｈ．ＢｉｇＩｎｔｅｇｅｒクラスの実装を示す。この実装では、「ｄｉｇｉｔｓ」フィールドがｉｎｔ型の配列を指しており、この配列には任意の長さのビット列が格納される。しかしながら、これだと、ビット列が長くない場合には、配列に無駄が生じてしまうし、配列を用意することによりサイズ等の情報を記憶しなければならないという無駄もある。また、既存のｊａｖａ．ｍａｔｈ．ＢｉｇＩｎｔｅｇｅｒクラスは、ビット長を示す「ｎｕｍＬｅｎｇｔｈ」フィールド及び初めて０以外のビットが現れるまでの長さを示す「１ｓｔＮｏｎｚｅｒｏＤｉｇｉｔ」フィールドを持つが、ビット列が長くない場合には、これらのフィールドにも無駄が生じてしまう。
【００９０】
例えば、ビット長が２１５より短いビット列を格納する場合を考える。この場合は、図４（ｂ）のＶａｒｉａｎｔ＃１の実装に示すように、３２ビットの大きさのフィールドに「ｎｕｍＬｅｎｇｔｈ」（図では「ｎｕｍＬｅｎ」と表記）及び「１ｓｔＮｏｎｚｅｒｏＤｉｇｉｔ」（図では「Ｎｏｎ０Ｄｉｇｉｔ」と表記）を含めればよい。
【００９１】
また、ビット長が６４より短いビット列を格納する場合を考える。この場合は、図４（ｃ）のＶａｒｉａｎｔ＃２の実装に示すように、３２ビットの大きさのフィールドを２つ用意し、１つ目のフィールドに６３ビット目から３２ビット目までを格納し、２つ目のフィールドに３１ビット目から０ビット目までを格納すればよい。加えて、３２ビットの大きさのフィールドに「ｎｕｍＬｅｎｇｔｈ」（図では「ｎｕｍＬｅｎ」と表記）及び「１ｓｔＮｏｎｚｅｒｏＤｉｇｉｔ」（図では「Ｎｏｎ０Ｄｉｇｉｔ」と表記）を含めればよい。
【００９２】
更に、ビット長が１２８より短いビット列を格納する場合を考える。この場合は、図４（ｄ）のＶａｒｉａｎｔ＃３の実装に示すように、３２ビットの大きさのフィールドを４つ用意し、１つ目のフィールドに１２７ビット目から９６ビット目までを格納し、２つ目のフィールドに９５ビット目から６４ビット目までを格納し、３つ目のフィールドに６３ビット目から３２ビット目までを格納し、４つ目のフィールドに３１ビット目から０ビット目までを格納すればよい。加えて、３２ビットの大きさのフィールドに「ｎｕｍＬｅｎｇｔｈ」（図では「ｎｕｍＬｅｎ」と表記）及び「１ｓｔＮｏｎｚｅｒｏＤｉｇｉｔ」（図では「Ｎｏｎ０Ｄｉｇｉｔ」と表記）を含めればよい。
【００９３】
図５（ａ）〜（ｃ）は、代表クラス５１及び特殊クラス５２の第３の例を示した図である。この第３の例は、既存のｊａｖａ．ｍａｔｈ．ＢｉｇＤｅｃｉｍａｌクラスを代表クラス５１とし、この代表クラス５１に対して、２つの特殊クラス５２を導入した例である。
【００９４】
図５（ａ）に、既存のｊａｖａ．ｍａｔｈ．ＢｉｇＤｅｃｉｍａｌクラスの実装を示す。この実装では、ｌｏｎｇ型で表現できないビット列を示す「ｉｎｔＶａｌ」フィールドが図４（ａ）の既存のｊａｖａ．ｍａｔｈ．ＢｉｇＩｎｔｅｇｅｒクラスの実装を指しており、ｌｏｎｇ型で表現できるビット列を示す「ｓｍａｌｌＶａｌｕｅ」フィールドも設けている。しかしながら、これだと、数値がｌｏｎｇ型で表現できる場合には、配列に無駄が生じてしまうし、配列を用意することによりサイズ等の情報を記憶しなければならないという無駄もある。
【００９５】
例えば、ビット長が３２以上であるビット列を格納する場合を考える。この場合は、図５（ｂ）のＶａｒｉａｎｔ＃１の実装に示すように、「ｓｍａｌｌＶａｌｕｅ」フィールドを設けなければよい。尚、ここでは、図５（ａ）の「ｉｎｔＶａｌ」は「ｂｉｇＩｎｔ」としている。
【００９６】
また、ビット長が３２より短いビット列を格納する場合を考える。この場合は、図５（ｃ）のＶａｒｉａｎｔ＃２の実装に示すように、「ｉｎｔＶａｌ」フィールドを設けなければよい。尚、ここでは、図５（ａ）の「ｓｍａｌｌＶａｌｕｅ」は「ｓｍａｌｌＶａｌｕｅＩｎｔ」としている。
【００９７】
［本実施の形態におけるＪＶＭの動作］
図６は、本実施の形態におけるＪＶＭ３０のオブジェクト生成時の動作例を示したフローチャートである。尚、この動作例は、インタプリタ３３又はマシン命令３５が、ユーザプログラム（例えば、クラス５０のメソッド）から、代表クラス５１及び特殊クラス５２からなるクラス群のオブジェクトを生成する命令を検出することにより、開始する。このように、本実施の形態では、インタプリタ３３又はマシン命令３５が命令を検出することにより動作を開始するが、以下では、インタプリタ３３が命令を検出することにより動作を開始するものとして説明する。
【００９８】
動作を開始すると、ＪＶＭ３０では、まず、インタプリタ３３が、生成するオブジェクト（生成オブジェクト）の初期値が分かるかどうかを判定する（ステップ３０１）。このような判定は、例えば、ユーザプログラムのオブジェクトを生成する命令の前後を解析することにより行えばよい。
【００９９】
生成オブジェクトの初期値が分かると判定した場合、インタプリタ３３は、生成オブジェクトのクラスが特殊クラス５２を持つかどうかを判定する（ステップ３０２）。このような判定は、例えば、代表クラス５１のアドレスの上位Ｎビットと同じ上位Ｎビットを有する他のアドレスに特殊クラス５２が記憶されているかどうかを調べることにより行えばよい。
【０１００】
生成オブジェクトのクラスが特殊クラス５２を持つと判定した場合、インタプリタ３３は、ステップ３０１で分かると判定した初期値に基づいて、生成オブジェクトの特殊クラス５２を検索する（ステップ３０３）。そして、適切な特殊クラス５２があるかどうかを判定する（ステップ３０４）。例えば、図３（ｂ）に示すように、初期値が「ａｂｃｄ」であることが分かっている場合、インタプリタ３３は、ｊａｖａ．ｌａｎｇ．ＳｔｒｉｎｇクラスのＶａｒｉａｎｔ＃１の特殊クラス５２を適切な特殊クラス５２とする。
【０１０１】
その結果、適切な特殊クラス５２があると判定した場合、インタプリタ３３は、その特殊クラス５２を、生成オブジェクトのクラスに設定する（ステップ３０５）。
【０１０２】
一方、ステップ３０１で生成オブジェクトの初期値が分かると判定しなかった場合、ステップ３０２で生成オブジェクトのクラスが特殊クラス５２を持つと判定しなかった場合、又は、ステップ３０４で適切な特殊クラス５２があると判定しなかった場合、インタプリタ３３は、ユーザプログラムが指定したクラスを、生成オブジェクトのクラスに設定する（ステップ３０６）。
【０１０３】
次に、ＪＶＭ３０では、クラスローダ３６が、ユーザプログラムが指定したクラスが既にクラスデータ領域３１にロードされているかどうかを判定する（ステップ３０７）。ユーザプログラムが指定したクラスが既にクラスデータ領域３１にロードされていると判定した場合、処理はそのままステップ３０９へ進む。一方、ユーザプログラムが指定したクラスが既にクラスデータ領域３１にロードされていると判定しなかった場合、クラスローダ３６は、そのクラスをクラスデータ領域３１にロードする（ステップ３０８）。
【０１０４】
次いで、クラスローダ３６は、ステップ３０５で特殊クラス５２が設定されているが、その特殊クラス５２がまだクラスデータ領域３１にロードされていないかどうかを判定する（ステップ３０９）。クラスローダ３６がステップ３０９において、ステップ３０５で特殊クラス５２が設定されていないと判定した場合、又は、ステップ３０５で設定された特殊クラス５２が既にクラスデータ領域３１にロードされていると判定した場合、処理はそのままステップ３１１へ進む。一方、ステップ３０５で特殊クラス５２が設定されているが、その特殊クラス５２がまだクラスデータ領域３１にロードされていないと判定した場合、クラスローダ３６は、その特殊クラス５２をクラスデータ領域３１にロードする（ステップ３１０）。
【０１０５】
その後、ＪＶＭ３０では、オブジェクトアロケータ３７が、ステップ３０５又はステップ３０６で設定されたクラスのオブジェクトを記憶するメモリ領域を確保する（ステップ３１１）。そして、オブジェクトアロケータ３７は、コンストラクタを呼び出す（ステップ３１２）。つまり、オブジェクトを生成し、オブジェクトの初期化処理を行う。
【０１０６】
尚、この動作例では、複数の特殊クラス５２が存在することを前提とし、ステップ３０４では、複数の特殊クラス５２の中で最も適切な特殊クラス５２を適切な特殊クラス５２とした。しかしながら、１つの特殊クラス５２のみが存在することを前提とし、ステップ３０４では、代表クラス５１よりもその特殊クラス５２が適切であれば、その特殊クラス５２を適切な特殊クラス５２としてもよい。
【０１０７】
図７は、本実施の形態におけるＪＶＭ３０のＧＣ時の動作例を示したフローチャートである。尚、この動作例は、ガベージコレクタ３８がオブジェクトをＧＣの対象とした時にそのオブジェクトに対して実行される。また、ここでは、ＧＣの対象となっているオブジェクトのクラスは配列を参照するものとし、特殊クラス５２は配列を参照する場合と配列を参照しない場合とがあるものとする。
【０１０８】
動作を開始すると、ＪＶＭ３０では、まず、ガベージコレクタ３８が、そのオブジェクトの値に対してより適切な特殊クラス５２があるかどうかを判定する（ステップ３２１）。このような判定は、例えば、代表クラス５１のアドレスの上位Ｎビットと同じ上位Ｎビットを有する他のアドレスに特殊クラス５２が記憶されており、そのオブジェクトの値がその特殊クラス５２を用いるための条件を満たすかどうかを調べることにより行えばよい。
【０１０９】
そのオブジェクトの値に対してより適切な特殊クラス５２がないと判定した場合、ガベージコレクタ３８は、そのオブジェクトを記憶するメモリ領域をヒープ領域３２内の移動先に確保し、オブジェクトの内容をそのメモリ領域にコピーする（ステップ３２２）。また、そのオブジェクトが参照する配列を記憶するメモリ領域をヒープ領域３２内の移動先に確保し、配列の内容をそのメモリ領域にコピーする（ステップ３２３）。そして、移動先にあるオブジェクトが移動先にある配列を参照するように、ポインタを修正する（ステップ３２４）。
【０１１０】
一方、そのオブジェクトの値に対してより適切な特殊クラス５２があると判定した場合、ガベージコレクタ３８は、適切な特殊クラス５２を選択する（ステップ３２５）。そして、その特殊クラス５２のオブジェクトを記憶するメモリ領域をヒープ領域３２内の移動先に確保し、オブジェクトの内容をそのメモリ領域にコピーする（ステップ３２６）。
【０１１１】
また、この場合、ガベージコレクタ３８は、選択した特殊クラス５２が、データを保持するために配列を用いるかどうかを判定する（ステップ３２７）。
【０１１２】
選択した特殊クラス５２がデータを保持するために配列を用いると判定した場合、ガベージコレクタ３８は、選択した特殊クラス５２のオブジェクトが参照する配列を記憶するメモリ領域をヒープ領域３２内の移動先に確保し、配列の内容をそのメモリ領域にコピーする（ステップ３２３）。そして、移動先にある選択した特殊クラス５２のオブジェクトが移動先にある配列を参照するように、ポインタを修正する（ステップ３２４）。
【０１１３】
一方、選択した特殊クラス５２が、データを保持するために配列を用いると判定しなかった場合、ガベージコレクタ３８は、移動元のオブジェクトが参照する配列の内容を、移動先の特殊クラス５２のオブジェクトにコピーする（ステップ３２８）。
【０１１４】
尚、この動作例では、ＧＣの対象となっているオブジェクトのクラス以外に複数の特殊クラス５２が存在することを前提とし、ステップ３２１では、複数の特殊クラス５２の中で最も適切な特殊クラス５２を適切な特殊クラス５２とした。しかしながら、ＧＣの対象となっているオブジェクトのクラス以外に１つの特殊クラス５２のみが存在することを前提とし、ステップ３２１では、ＧＣの対象となっているオブジェクトのクラスよりもその特殊クラス５２が適切であれば、その特殊クラス５２を適切な特殊クラス５２としてもよい。
【０１１５】
また、図６及び図７の動作例のように、本実施の形態では、ＪＶＭ３０におけるオブジェクトを生成する命令又はＧＣを行う命令に応じて、より適切な特殊クラス５２を用いた処理が行われるものとした。しかしながら、これをより一般化して、ＪＶＭ３０における所定の命令に応じて、より適切な特殊クラス５２を用いた処理が行われるものとしてもよい。
【０１１６】
図８は、本実施の形態におけるＪＶＭ３０のクラスメタ情報提供時の動作例を示したフローチャートである。
【０１１７】
動作を開始すると、ＪＶＭ３０では、まず、クラスローダ３６が、ユーザプログラムにより特殊クラス５２のクラスメタ情報の参照が要求されているかどうかを判定する（ステップ３４１）。インタプリタ３３又はマシン命令３５は、ユーザプログラム（例えば、クラス５０のメソッド）から代表クラス５１又は特殊クラス５２のクラスメタ情報の参照を要求する命令を検出すると、クラスローダ３６にその旨の情報を伝えてくるので、このような判定は、この伝えられた情報に基づいて行えばよい。
【０１１８】
その結果、ユーザプログラムにより特殊クラス５２のクラスメタ情報の参照が要求されていると判定されなかった場合、処理はそのままステップ３４３へ進む。
【０１１９】
一方、ユーザプログラムにより特殊クラス５２のクラスメタ情報の参照が要求されていると判定された場合、クラスローダ３６は、参照するクラスを、特殊クラス５２に対する代表クラス５１に変更する（ステップ３４２）。
【０１２０】
次に、クラスローダ３６は、ユーザプログラムが指定した代表クラス５１又はステップ３４２での変更後の代表クラス５１から、クラスメタ情報を保持するデータ構造（図２のメタデータ）を取得する（ステップ３４３）。そして、取得したデータ構造から、参照が要求されたクラスメタ情報を取り出し、インタプリタ３３又はマシン命令３５にこのクラスメタ情報を返す（ステップ３４４）。
【０１２１】
［本実施の形態の効果］
図９は、本実施の形態の効果を示した図である。ここでは、図３（ａ）のｊａｖａ．ｌａｎｇ．Ｓｔｒｉｎｇクラスを代表クラス５１として、図３（ｂ）〜（ｄ）の３種類の特殊クラス５２を導入した場合について示している。
【０１２２】
図中、「DayTrader (after 90min run)」という見出しの列に、ＤａｙＴｒａｄｅｒを９０分間実行した後にＪａｖａ（登録商標）ヒープダンプを解析した結果を示す。図示するように、使用中のオブジェクト（ライブオブジェクト）を抽出すると、そのサイズは５６２ＭＢであった。これに対し、３種類の特殊クラス５２を導入したことによるメモリ削減量の見積もりは約６０ＭＢであった。
【０１２３】
また、「SPECjEnterprise (after 90min run)」という見出しの列に、ＳＰＥＣｊＥｎｔｅｒｐｒｉｓｅを９０分間実行した後のＪａｖａ（登録商標）ヒープダンプからの見積もりを示す。この見積もりでは、３７３ＭＢのライブヒープのうち、約３１ＭＢを削減可能だった。
【０１２４】
このように、本実施の形態によれば、ライブヒープのサイズを約１０％削減することが可能となる。
【０１２５】
以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態には限定されない。本発明の精神及び範囲から逸脱することなく様々に変更したり代替態様を採用したりすることが可能なことは、当業者に明らかである。
【符号の説明】
【０１２６】
１０…コンピュータ、２０…クラスファイル記憶部、３０…ＪＶＭ、３１…クラスデータ領域、３２…ヒープ領域、３３…インタプリタ、３４…ＪＩＴコンパイラ、３５…マシン命令、３６…クラスローダ、３７…オブジェクトアロケータ、３８…ガベージコレクタ
【図１】
0005950288.tif 000002
【図２】
0005950288.tif 000003
【図３】
0005950288.tif 000004
【図４】
0005950288.tif 000005
【図５】
0005950288.tif 000006
【図６】
0005950288.tif 000007
【図７】
0005950288.tif 000008
【図８】
0005950288.tif 000009
【図９】
0005950288.tif 000010