JP3632598B2 - 変更定数プールを備えたＪａｖａランタイム・システム - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、ＪａｖａＣａｒｄなどの資源制約Ｊａｖａランタイム環境におけるダイナミック・コード・ダウン・ロードおよびリンキングに関する。
【０００２】
【従来の技術】
従来のＪａｖａ・システムにおいては、クラス構造（内部および外部）への参照は、いわゆる定数プールを介する間接名前ルックアップを使って解決される。このような手法は、処理能力および内部資源の点で十分な資源を提供するシステムでしか使用できない。
【０００３】
資源制約ランタイム・システム（例えば、ＪａｖａＣａｒｄ）においては、この手法は、有望ではない。その代わりに、解決されたクラス構造への参照を使用して、間接指示（ｉｎｄｉｒｅｃｔｉｏｎ）を回避し、定数プールの維持を避けることができる。
【０００４】
【発明が解決しようとする課題】
参照（リンキング）を解決することが、本発明の主題である。
【０００５】
本発明の一目的は、資源制約Ｊａｖａランタイム環境において効率的リンキングを実現することである。
【０００６】
本発明の一目的は、資源制約Ｊａｖａランタイム環境においてスペースおよびランタイムの効率的リンキングを実現することである。
【０００７】
【課題を解決するための手段】
本発明では上記課題を解決するために、バイトコードとクラス構造を含むプログラムを実行するスタック・ベースのインタープリタを備え、さらにリンク時にのみ使用される内部情報とレイト・コード・バインディングのために予約された外部情報とを含む変更定数プールを備え、前記内部情報がリンク後に前記変更定数プールから除去されるＪａｖａランタイム・システムを実現する。
【０００８】
【発明の実施の形態】
以下に本発明の概要を示し、実施の諸態様を取り上げる。Ｊａｖａは、米国９４０４３−１１００カリフォルニア州マウンテン・ビュー、ガルシア・アベニュー２５５０のサン・マイクロシステムズ社が開発したプログラミング言語および環境である。用語「Ｊａｖａ」は、同社の商標である。
【０００９】
この説明では実施の詳細も扱うので、当技術分野の技術者は、Ｊａｖａ仮想計算機およびその実施の基本的機構に精通しているものと想定する。Ｊａｖａ言語の包括的な提示とＪＶＭの実施は、Ｊ．ゴスリン（Ｇｏｓｌｉｎ）、Ｂ．ジョイ（Ｊｏｙ）およびＧ．テル（Ｔｅｌｅ）の「Ｔｈｅ Ｊａｖａ Ｌａｎｇｕａｇｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ」、ならびにＴ．リンドホルム（Ｌｉｎｄｈｏｌｍ）およびＦ．エリン（Ｙｅｌｌｉｎ）の「Ｔｈｅ Ｊａｖａ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ」、共にＡｄｄｉｓｏｎ−Ｗｅｓｌｅｙ Ｐｕｂｌｉｓｈｉｎｇ Ｃｏ．、１９９６年刊、に開示されている。しかし、本明細書でＪａｖａＣａｒｄＶＭと呼ぶＪａｖａＣａｒｄ仮想計算機は、サブセットと追加バイトコードだけが使用されるため、いくつかの面で異なっている。
【００１０】
１．０ ＪａｖａＳｏｆｔ ＣＡＰファイル・フォーマットの提案
ＪａｖａＳｏｆｔが提案するＣＡＰファイル・フォーマットでは、キャップ・ファイルをいくつかのセクションに分ける。キャップ・ファイルは基本的に、テキスト・セクションとデータ・セクションを含んでいる。テキスト・セクションは、クラス構造、メソッド構造およびバイトコード命令を含んでいる。データ・セクションは、カードレットの静的フィールドを含んでいる。
【００１１】
テキスト・セクションは、リンク時以前にはその実際のアドレスが知られていない全ての記号（クラス、メソッドなど）を、定数プールへのオフセットを介して参照する。あらゆるこのような記号について、定数プールは、ターゲット・パッケージのＡＩＤ、およびターゲット・パッケージ（すなわち、リンクされる対象となるパッケージ）中でのその記号のオフセットを含んでいる。定数プールは、インポートされた全ての記号（他のパッケージ中で定義される記号）、およびエキスポートされた全ての記号（ロードされるカードレット内で定義されアクセスされる記号）に対するこうしたオフセットを提供する。
【００１２】
テキスト・セクション、データ・セクションおよび定数プールの編成は、カードレットを実行するのに十分な情報を提供する。カードレットのロード後、リンカは、定数プール中をステッピングし、ターゲット・パッケージへの記号のオフセットをその実アドレスで置き換える。リンカは、所与のＡＩＤによって特定のパッケージをルックアップし、その開始アドレスを記号のオフセットに加え、この情報を定数プールに戻して記憶するだけでよい。そうすると、ＪａｖａＣａｒｄＶＭは、解釈のため定数プールにおけるこれらのアドレスを使用することができる。しかし、定数プール自体は、ランタイムには必要でない。実際、解釈中に記号のアドレスを見つけるには、追加の不必要な１つの間接指示が必要となる。さらに、定数プールは、不必要にカードのスペースを占める。したがって、ＪａｖａＳｏｆｔキャップ・ファイル・フォーマットでは、リンク後に、定数プールの必要をなくすため、個々のセクション用のフィックスアップ・テーブルを使用する。フィックスアップ・テーブルは、再配置を行うべきテキスト・セクション中の全ての位置を含んでいる。リンカは、フィックスアップ・テーブル中を移動し、その位置における定数プールへのオフセットを取る。次いで、その記号のアドレスを解決し、それをテキスト・セクションの元の位置に格納する。そうすると、インタープリタは、ランタイムにこれらのアドレスを直接使用することができ、したがって、定数プールはリンク・プロセス後に除去することができる。リンク・プロセス後にカード上に残るセクションは、テキスト・セクションとデータ・セクションだけである。
【００１３】
カードレットを、ターゲット・パッケージへの予め計算されハードコードされたオフセットとリンクすると、コンパクトなシステムが可能になる。しかし、システム・クラスの異なる実施および異なるカード上での指定された拡張を可能とするのに十分なフレキシビリティは得られない。例えば、ＩＢＭのシステム・クラスおよびＪａｖａＳｏｆｔの拡張に対して変換されたカードレットは、ＪａｖａＳｏｆｔからのシステム・カードレットおよびＩＢＭからの拡張カードレットを備えるカード上では稼動しないと思われる。その主な理由は、個々のクラス、メソッドのオフセットとインスタンスのフィールド・オフセットが実施ごとに異なっているからである。
【００１４】
本発明は、現在のＪａｖａＳｏｆｔのアイデアを拡張し、追加の軽くてフレキシブルな記号リンク機構によってその機能を強化するものである。
【００１５】
２．０ 本発明のＣＡＰファイル・フォーマット
本発明によるキャップ・ファイル・フォーマットでも、キャップ・ファイルを異なるセクションに分ける。テキスト・セクションは、クラス構造、メソッド構造、およびバイトコード命令を含んでおり、データ・セクションはやはり、静的フィールドを含んでいる。キャップ・ファイルはまた、必要な再配置情報をフィックスアップ・テーブルに維持する。カードレットがリンクされるあらゆるパッケージ（すなわち、ターゲット・パッケージ）に対して１つのフィックスアップ・テーブルがある。
【００１６】
フィックスアップ・テーブルはやはり、テキスト・セクションまたはデータ・セクション中の再配置を行うべき位置を含んでいる。簡単なケースでは、これらの場所も、信頼されるよく知られたターゲット・パッケージへの予め計算されたオフセットによって再配置される。この場合、リンカは、所与のターゲットＡＩＤによってパッケージの開始アドレスをルックアップし、ターゲット・パッケージへのオフセットを加え、テキスト・セクションの元の位置にその値を格納する。ターゲット・パッケージへのオフセットは、フィックスアップ・テーブルに保持することができ、またフィックスアップ・テーブルを小さくしておくためにテキスト・セクションの再配置アドレスに保持することもできる。オフセットによる再配置は、ロードされたカードレット自体内の大部分の参照に対して常に使用することができる。コンバータは、互換性を壊すことなく、これらのオフセットを予め計算することができる。
【００１７】
システムの保全性の理由から、他の外部パッケージへの参照は、予め計算されたオフセットによってリンクすべきではない。その代わりに、名前または識別子を、リンク・プロセス中に、他のパッケージへの参照に使用すべきである。これらの名前とそれに関連する値だけを、複数のアプレットの間で共用されるパッケージのカードに格納しなければならない。名前／値の対のこれらのテーブルはできるだけ小さくなければならないため、このキャップ・ファイル・フォーマットでは、クラス・ファイル要素の命名には制限があるが、それでも様々な仕様をベンダ特有に実施する可能性が与えられる。
【００１８】
・ 公用クラス：命名しなければならず、エキスポート可能でなければならない。
【００１９】
・ 公用静的メソッドおよびコンストラクタ：同上。
【００２０】
・ 公用静的フィールド：同上。
【００２１】
・ 仮想メソッド：
インタープリタは、仮想メソッド・テーブルへのインデックスにより、仮想メソッドを見つけ出す。これらのインデックスと仮想メソッド・テーブルは、ＪａｖａＣａｒｄ環境が仮想メソッドの標準Ｊａｖａレイト・コード・バインディングをサポートしようとする場合、カード上で解決する必要がある。メソッド・テーブルの構築中に、リンカは、あるメソッドが、メソッド・テーブル中の他のメソッドを継承するかどうかを判断しなければならない。これらのメソッドは異なるカードレット中で定義されている可能性があるため、２つのメソッドが同じタイプを有しているかどうかを判断するのに、メソッドに対する大域命名方式を導入しなければならない。仮想メソッド・コールに対するレイト（ｌａｔｅ）・コード・バインディング（ダイナミック・リンキングとも言う）では、仮想メソッドを解決し命名するために、大域命名方式、およびカード上の追加資源を必要とするが、本発明のキャップ・ファイル・フォーマットは、これをサポートしない。しかし、この制限があっても、コア・パッケージおよび拡張のベンダ特有の実施のための十分な余地が残る。プログラマは自由に、私用または静的メソッドおよびクラスを追加することができる。非私用インスタンス・メソッドが継承されず、最終的なものと宣言されていない場合、プログラマは、非私用インスタンス・メソッドも追加することができる。コンバータは次いで、これらのメソッドに対するコールを直接呼出しで置き換えることができる。
【００２２】
・ インスタンス・フィールド：
あるクラスにおけるインスタンス・フィールドの数およびタイプは通常、仕様で定義されず、異なるベンダの実施ごとに変わるものである。したがって、フィールド・オフセットのバインドは、ＣＡＰファイル・フォーマットの提案で対処しなければならない。リンク・プロセスに関するフィールドの使用法は、以下の３つのカテゴリに分けられる。
【００２３】
・ 予め計算されたフィールド・オフセット
ゲット／プット・フィールド命令は、そのクラスと全てのスーパークラスが、格納用（ｃｏｎｔａｉｎｉｎｇ）カードレット内で定義されているフィールドを参照付け（ｒｅｆｅｒｅｎｃｅ）する。そうすると、このフィールドのオフセットは、コンバータによって予め計算でき、ロード・プロセス中にリンクする必要はない。オブジェクト・クラスが何らフィールド宣言を含んでいないという取り決めがある場合、多くのフィールド・アクセスが、このカテゴリに属する。
【００２４】
・ 何らかのカードレット外部のスーパークラスによるカードレット内部のクラスのフィールドに対するアクセス
別々のパッケージ内で定義されるクラスのサブクラス分けを可能にするために、このケースを、キャップ・ファイル・フォーマットでサポートしなければならない。コンバータは、カードレット外部のスーパークラスのインスタンス・サイズに対するフィールドのオフセットを計算し、この値をキャップ・ファイルに格納することができる。リンク・プロセス中に、フィールドの実際のオフセットを、ベース・クラスのサイズに基づいて再計算しなければならない。カードレット内部クラスのインスタンス・サイズの要素についても同じことを行うことができる。
【００２５】
・ カードレット外部のスーパークラスまたは何らかの外部クラスにおけるフィールドに対するアクセス
インスタンス・フィールドが公用であると宣言されることはほとんどないが、保護されていると宣言されることはしばしばある。保護されたフィールドへのアクセスは常に、保護されたセット／ゲット・フィールト・メソッドを指定することによって許可されるが、提案されるキャップ・ファイル・フォーマットでもこのような保護された、または公用と宣言されたフィールドへの直接アクセスが可能である。保護されたまたは公用のインスタンス・フィールドをエキスポートするパッケージは、記号リンクを可能にするために、このようなフィールドに対する名前とオフセットを含んでいなければならない。
【００２６】
クラス、メソッドまたはフィールドをエキスポートするパッケージは、その項目がその記号のタイプ（クラスなど）、名前および値を含んでいる定数プールを含んでいる。キャップ・ファイル・フォーマットが大域命名方式をサポートする必要がないので、関連する記号の名前は簡単に指定できる。記号は、０からｎまでの番号を付け、アプリケーション・プログラミング・インターフェース（ＡＰＩ）の仕様と共に配布することができる。このような仕様の実施者は、ｎ＋１で始まる新しい名前を選ぶことにより、なお追加のクラスなどをエキスポートすることができる。
【００２７】
図３は、ターゲット・パッケージに対するアプレットの記号バインドを示す。フィックスアップ・テーブルの項目は、再配置のタイプ（下記参照）、再配置先のテキスト・セクションへのオフセット、および記号の名前（スペースの効率のため、再配置される位置に格納することもできる）を含んでいる。この提案された命名方式を用いると、名前をターゲット・パッケージの定数プールへのインデックスとして使用することができる。定数プールの項目は、項目のタイプ、名前および関連する値を含んでいる。リンカは、項目のタイプに応じてフィックスアップ・テーブルの項目を再配置する。
【００２８】
・ メソッドを再配置しなければならない：
所与の名前をもつターゲット・パッケージの定数プールの項は、メソッド・タイプでなければならない。その値は、そのメソッドが定義されているターゲット・パッケージへのオフセットでなければならない。リンカはメソッドのアドレスを計算し、テキスト・セクションを所与のオフセットに固定（ｆｉｘ）する。
【００２９】
・ クラスを再配置しなければならない：
記号インデックスと名前を含む定数プールの項がクラス・タイプでなければならない点を除き、上記と同じである。
【００３０】
・ 静的フィールドを再配置しなければならない：
記号インデックスと名前を含む定数プールの項が静的フィールド・タイプでなければならず、その値がパッケージのデータ・セクションへのオフセットである点を除き、上記と同じである。
【００３１】
・ 相対インスタンス・フィールドのオフセットまたは相対クラス・インスタンス・サイズ値を再配置しなければならない：
所与の名前をもつターゲット・パッケージの定数プールの項は、クラス・タイプでなければならない。リンカはターゲット・クラスのアドレスを計算し、そのクラスのインスタンス・サイズを取得する（後者はクラス構造の要素である）。リンカはインスタンス・サイズをテキスト・セクションのオフセットで与えられる値に加え、後者をその合計で置き換える。
【００３２】
・ 未定義のクラスに対する絶対フィールド・アクセス：
所与の名前をもつターゲット・パッケージの定数プールの項は、インスタンス・フィールド・タイプでなければならない。この項の値は、そのクラスのインスタンスにおけるそのフィールドの絶対オフセットである。
【００３３】
ロードされたカードレットが共用パッケージであり、保護されたまたは公用のフィールドをエキスポートする場合、リンカは定数プールにおけるその項目も再配置する。その実際のオフセットは、相対インスタンス・フィールドのオフセットと同様に再配置される。
【００３４】
リンク・プロセスが完了した後、フィックスアップ・テーブルを除去することができる。アプレットは、定数プールを必要とせず、複数のアプレットの間で共有できるパッケージだけが、将来使用するために定数プールを必要とする。定数プールのサイズは、エキスポートされる項の数および項のサイズによって決まる。現在のＪａｖａＣａｒｄシステム・クラス用の定数プールは、現在約１６０項を占める。定数プールの項は、タイプ・フィールドと名前と値を含み、４バイトで格納することができる（提案された命名方式を用いると、これは３バイトにまで減らすことができる）。この結果、全てのシステム・クラスに対しての定数プールのサイズは７２０バイトになる。
【００３５】
ＪａｖａＳｏｆｔの提案との違い：
・ ＪａｖａＳｏｆｔの定数プールでは現在、内部で定義された項と外部で定義された項を区別しない。このため、内部で定義される項をカバーする定数プールの項を除去するのが難しい。
【００３６】
・ ゲット／プット・フィールド命令におけるフィールド・オフセット、およびクラス構造におけるインスタンス・サイズ・フィールドは８ビット幅に過ぎない。このため、リンク・プロセス中にフィールドのオフセットをバインドするための情報が格納できる、定数プールへのインデックスとしてこの値を使用することは現在不可能である。
【００３７】
これら２つの制限により、現在のＪａｖａＳｏｆｔの提案では、必要とされる（本明細書で提案するような）軽い命名方式を可能とするために、強化機能が必要である。
【００３８】
３．０ 付録
３．１ 微小な拡張
ある種の環境においては、カード上にどんな記号情報も全く必要でなく、またそのためのスペースもない、たとえばリンク・プロセス中に予め計算されたオフセットだけを使用するだけで十分である。本発明によるキャップ・ファイル・フォーマットは、この方向に安全に拡張することができる。
【００３９】
・ パッケージまたはアプレットは、バージョン番号だけでなく、ベンダｉｄ（または、実施ｉｄ）も含んでいる。
【００４０】
・ 定数プールの項を参照付けするフィックスアップ・テーブルの項目は、変換時にコンバータが計算できるオフセットをも含んでいる。
【００４１】
・ ダウンロード・プロセスの開始時に、ローダは、アプレットが必要とするパッケージがカードに現在インストールされているものと同じベンダからのもの（すなわち、同じ実施）かどうかをチェックする。そうである場合、ローダは、リンク・プロセス中にアプレットのキャップ・ファイルにおけるオフセットを使用する。そうでない場合、ダウンロード・プロセスは、失敗する。
【００４２】
３．２ 参照されたキャップ・ファイル・フォーマット項に関する指定
この詳細な説明の目的は、キャップ・ファイルの内容を厳密に指定することではない。その代わりに、ＪａｖａＳｏｆｔの提案から始めて、キャップ・ファイルがどういうものであるべきか、どうでなければならないかについて詳細な議論を行う。とはいえ、この説明で言及したキャップ・ファイル・フォーマットの項のより正式な仕様を、Ｃ言語様の宣言として示す。これはわかりやすいようにここに指定したもので、最適な形ではない。

【図面の簡単な説明】
【図１】ＪａｖａＳｏｆｔ提案のキャップ・ファイル・フォーマットを備えたリンキングを示す図である。
【図２】本明細書で提案するファイル・フォーマットを備えた、オフセットによるリンキングを示す図である。
【図３】本明細書で提案するファイル・フォーマットを備えた、名前によるリンキングを示す図である。

Claims (6)

1. クラス構造を反映するバイトコードを含むプログラムを実行するスタック・ベースのインタープリタを備え、さらにリンク時にのみ使用される内部情報とレイト・コード・バインディングのための外部情報とを含む変更定数プールを備え、前記内部情報がリンク後に前記変更定数プールから除去されるJavaランタイム・システム。
2. 前記Javaランタイム・システムが、JavaCardである請求項１に記載のJavaランタイム・システム。
3. クラス構造を反映するバイトコードを含むパッケージを実行するためのスタック・ベースのインタープリタを備えるJavaランタイム・システムに新しいコードを導入する方法であって、
   前記システムが、前記システム内に存在する前記パッケージに前記新しいコードをリンク（内部リンク）し、それにより前記新しいコードのそれ自体に対するオフセットをリンク時にのみ使用される参照で置き換え、
   前記システムが、それにより前記パッケージの定数プールに含まれる記号情報（名前）を使用して外部リンクを解決し、
   前記システムが、少なくともリンク時にのみ使用される前記参照による置換えのために使用される情報を、前記定数プールから除去する方法。
4. 外部パッケージにリンクするために使用される情報も、前記定数プールから除去される請求項３に記載の方法。
5. 前記定数プール中の情報のうち前記除去によって除去されなかった残りの情報により、後でダウンロードされる他のパッケージおよびアプレットが、前記新しいコードにアクセスできるようになる（レイト・コード・バインディング）請求項３に記載の方法。
6. 前記Javaランタイム・システムが、JavaCardである請求項３に記載の方法。

Images