0

在 Java Card（我对 Classic 一直到 2.1.1 感兴趣）中，applet 所需的瞬态（RAM）通常在安装时由makeTransientByteArray(). 该方法接受一个参数CLEAR_ON_RESET或CLEAR_ON_DESELECT。后者带有警告

CLEAR_ON_DESELECT仅当创建对象的小程序与当前选定的小程序处于同一上下文中时，才能访问瞬态对象。

CLEAR_ON_DESELECT如果在当前选定的小程序与创建对象的小程序不在同一上下文中时访问瞬态对象，Java Card 运行时环境将抛出 SecurityException 。

我的阅读是CLEAR_ON_DESELECT（但不是CLEAR_ON_RESET）将允许运行时覆盖两个小程序之间的瞬态（如上所述在安装时分配），只要它们没有同时被选中，这样分配m j字节的几个小程序将消耗大约 max( m j ) 瞬态字节，而不是 sum( m j )。

更新：有人告诉我，至少在某些运行时环境中，覆盖选择性地发生在从不同包分配的瞬态中。但我找不到参考，或对此类规则/机制的精确描述。

问题：这种覆盖机制有时会在运行时实现吗？如果是，什么时候发生？是否有运行时没有实现它的卡？如果是的话，除了实验之外，有没有其他方法可以判断，可能是从广告中的 Java Card 版本？

其他问题：引用的限制中的“上下文”到底是什么意思？特别是，一个小程序的另一个实例是否可以使用瞬态，并与此处CLEAR_ON_DESELECT显示的机制分配的实例共享它？注意：我对共享瞬态的内容不感兴趣，只是为了避免两次分配，以解决运行时可能缺少覆盖的问题。

更新：我在这里问了同样的问题，得到了一个有趣的答案。

4

1 回答 1

1

Oracle 没有直接的理由指定CLEAR_ON_DESELECT可用于在不同的小程序实例之间共享内存，但如果它不允许这种情况发生，那将是一个非常奇怪的实现。

如果它在任何地方指定，它可能在 Oracle 为实施 Java Card 的公司提供的测试工具中。实际上，Oracle 根本没有指定实际的底层内存模型，如果他们想要对齐数据，则取决于实现。必须支持 Java Card 字节码和 CAP 文件格式，但关于底层实现仅此而已。

至于上下文，来自 VM 规范：

在定义小程序的上下文和包之间存在一对一的映射。将上下文视为包的运行时等价物的一种简单方法是，因为 Java 包是编译时构造，并且在运行时没有直接表示。因此，来自同一个包的所有小程序实例将共享相同的上下文。

请注意，这并不意味着CLEAR_ON_DESELECT如果以任何方式取消选择小程序，则不会清除数组。这只是关于访问条件。我将不得不找出答案，但我猜如果同一上下文中的另一个小程序使用该数组，它将只能看到清零字节。

但这部分关于CLEAR_ON_DESELECT和上下文就是我阅读规范的方式。

于 2013-01-18T01:58:34.983 回答