Question

In Java Card (I’m interested in Classic downto 2.1.1), transient (RAM) needed by an applet is typically allocated on install by makeTransientByteArray(). That method accepts a parameter CLEAR_ON_RESET or CLEAR_ON_DESELECT. The later comes with warning that

CLEAR_ON_DESELECT transient objects can be accessed only when the applet which created the object is in the same context as the currently selected applet.

The Java Card runtime environment will throw a SecurityException if a CLEAR_ON_DESELECT transient object is accessed when the currently selected applet is not in the same context as the applet which created the object.

My reading is that CLEAR_ON_DESELECT (but not CLEAR_ON_RESET) would allow the runtime to overlay the transients (allocated on install as stated above) between two applets, as long as they are not simultaneously selected, so that several applets allocating m_j bytes would consume about max(m_j) transient bytes, rather than sum(m_j).

Update: I’m told something on the tune that on at least some runtime environments, the overlay occurs selectively for transients allocated from different packages. But I fail to find a reference, or a precise description of such rule/mechanism.

Question: Is this overlay mechanism sometime implemented in the runtime? If yes, when does it occurs? And are there cards with a runtime not implementing it? If yes, is there a way to tell other than by experiment, maybe from the version of Java Card advertised?

Other question: Precisely what does “context” mean in the quoted restriction? In particular, is a CLEAR_ON_DESELECT transient usable by another instance of the applet, sharing it with the instance that allocated by the mechanism shown here? Note: I’m not interested in sharing the content of the transient, only in avoiding two allocations, to workaround a possible lack of overlay by the runtime.

Update: I asked the same question here and got an interesting answer.

Answer 1

There is no direct reason for Oracle to specify that CLEAR_ON_DESELECT can be used to share memory between different applet instances, but it would be a very weird implementation if it didn’t allow that to happen.

If it is specified anywhere, it is probably in the testing tools that Oracle makes available to companies implementing Java Card. Actually, the actual underlying memory model is not specified by Oracle at all, it’s up to the implementation if they want to e.g. align data. Java Card byte code & CAP file format must be supported, but that’s about it regarding the underlying implementation.

As for the context, from the VM specs:

There is a one-to-one mapping between contexts and packages in which
applets are defined. An easy way to think of a context is as the
runtime equivalent of a package, since Java packages are compile-time
constructs and have no direct representation at runtime. As a
consequence, all applet instances from the same package will share the
same context.

Note that this does not mean that a CLEAR_ON_DESELECT array won’t be cleared if the applet is deselected in any way. This is just about access conditions. I will have to find out, but I guess if another applet in the same context uses the array, it will only be able to see zero’ed out bytes.

But this part about CLEAR_ON_DESELECT and context is just how I read the specs.