0

Java Card（Classicから2.1.1までに興味があります）では、アプレットに必要な一時（RAM）は、通常、インストール時にによって割り当てられますmakeTransientByteArray()。そのメソッドはパラメータCLEAR_ON_RESETまたはを受け入れますCLEAR_ON_DESELECT。後者には次のような警告が表示されます

CLEAR_ON_DESELECT一時オブジェクトにアクセスできるのは、オブジェクトを作成したアプレットが現在選択されているアプレットと同じコンテキストにある場合のみです。

CLEAR_ON_DESELECT現在選択されているアプレットがオブジェクトを作成したアプレットと同じコンテキストにないときに一時オブジェクトにアクセスすると、JavaCardランタイム環境はSecurityExceptionをスローします。

私の読書では、同時に選択されていCLEAR_ON_DESELECTないCLEAR_ON_RESET限り、ランタイムは2つのアプレット間でトランジェント（上記のようにインストール時に割り当てられます）をオーバーレイできるため、m jバイトを割り当てる複数のアプレットは約max（m j ）sum（ m j ）ではなく一時バイト。

更新：少なくとも一部のランタイム環境では、異なるパッケージから割り当てられたトランジェントに対して選択的にオーバーレイが発生するという調子で何かを言われました。しかし、私はそのような規則/メカニズムの参照または正確な説明を見つけることができません。

質問：このオーバーレイメカニズムは、ランタイムに実装されることがありますか？はいの場合、それはいつ発生しますか？そして、それを実装していないランタイムを持つカードはありますか？はいの場合、実験以外の方法で、おそらく宣伝されているJava Cardのバージョンから判断する方法はありますか？

その他の質問：引用された制限で「コンテキスト」は正確に何を意味しますか？特に、一時的なアプレットは、ここCLEAR_ON_DESELECTに示すメカニズムによって割り当てられたインスタンスと共有して、アプレットの別のインスタンスで使用できますか？注：ランタイムによるオーバーレイの不足の可能性を回避するために、トランジェントのコンテンツを共有することには興味がありません。2つの割り当てを回避することだけに関心があります。

更新：私はここで同じ質問をし、興味深い答えを得ました。

4

1 に答える 1

1

CLEAR_ON_DESELECTOracleが を使用して異なるアプレット インスタンス間でメモリを共有できると指定する直接的な理由はありませんが、それが許可されない場合、非常に奇妙な実装になります。

どこかに指定されている場合、それはおそらく Oracle が Java Card を実装する企業に提供するテスト ツールにあります。実際、実際の基礎となるメモリモデルはOracleによってまったく指定されていません。たとえば、データを整列させたい場合は、実装次第です。Java Card バイトコードと CAP ファイル形式をサポートする必要がありますが、基本的な実装に関してはそれだけです。

コンテキストに関しては、VM 仕様から:

アプレットが定義されているコンテキストとパッケージの間には、1 対 1 のマッピングがあります。Java パッケージはコンパイル時の構成要素であり、実行時に直接的な表現を持たないため、コンテキストは実行時にパッケージに相当するものと考えるのが簡単です。結果として、同じパッケージのすべてのアプレット インスタンスは同じコンテキストを共有します。

CLEAR_ON_DESELECTこれは、アプレットが何らかの方法で選択解除された場合に配列がクリアされないという意味ではないことに注意してください。これはアクセス条件に関するものです。調べる必要がありますが、同じコンテキストの別のアプレットが配列を使用している場合、ゼロ化されたバイトしか表示できないと思います。

しかし、この部分CLEAR_ON_DESELECTとコンテキストは、私が仕様をどのように読んだかにすぎません。

于 2013-01-18T01:58:34.983 に答える