| Virtual Machine Specification, Java Card Platform, v2.2.2 |    
|
| Virtual Machine Specification, Java Card Platform, v2.2.2 |
|
| C H A P T E R 3 |
|
Structure of the Java Card Virtual Machine |
The specification of the Java Card virtual machine is in many ways quite similar to that of the Java virtual machine. This similarity is of course intentional, as the design of the Java Card virtual machine was based on that of the Java virtual machine. Rather than reiterate all the details of this specification which are shared with that of the Java virtual machine, this chapter will mainly refer to its counterpart in The Java Virtual Machine Specification, 2nd Edition, providing new information only where the Java Card virtual machine differs.
The Java Card virtual machine supports the same two kinds of data types as the Java virtual machine: primitive types and reference types. Likewise, the same two kinds of values are used: primitive values and reference values.
The primitive data types supported by the Java Card virtual machine are the numeric types, the boolean type, and the returnAddress type. The numeric types consist only of these types:
Some Java Card virtual machine implementations may also support an additional integral type:
Support for the boolean type is identical to that in the Java virtual machine. The value 1 is used to represent true and the value of 0 is used to represent false.
Support for reference types is identical to that in the Java virtual machine.
The Java Card virtual machine is defined in terms of an abstract storage unit called a word. This specification does not mandate the actual size in bits of a word on a specific platform. A word is large enough to hold a value of type byte, short, reference or returnAddress. Two words are large enough to hold a value of type int.
The actual storage used for values in an implementation is platform-specific. There is enough information present in the descriptor component of a CAP file to allow an implementation to optimize the storage used for values in variables and on the stack.
The Java Card virtual machine can support only a single thread of execution. Any runtime data area in the Java virtual machine which is duplicated on a per-thread basis will have only one global copy in the Java Card virtual machine.
The Java Card virtual machine's heap is not required to be garbage collected. Objects allocated from the heap will not necessarily be reclaimed.
This specification does not include support for native methods, so there are no native method stacks.
Otherwise, the runtime data areas are as documented for the Java virtual machine.
Each applet running on a Java Card virtual machine is associated with an execution context. The Java Card virtual machine uses the context of the current frame to enforce security policies for inter-applet operations.
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.
The Java Card Runtime Environment also has its own context. Framework objects execute in this Java Card RE context.
The context of the currently executing method is known as the current context. Every object in a Java Card virtual machine is owned by a particular context. The owning context is the context that was current when the object was created.
When a method in one context successfully invokes a method on an object in another context, the Java Card virtual machine performs a context switch. Afterwards the invoked method's context becomes the current context. When the invoked method returns, the current context is switched back to the previous context.
Java Card virtual machine frames are very similar to those defined for the Java virtual machine. Each frame has a set of local variables and an operand stack. Frames also contain a reference to a constant pool, but since all constant pools for all classes in a package are merged, the reference is to the constant pool for the current class' package.
Each frame also includes a reference to the context in which the current method is executing.
The Java Card virtual machine does not mandate a particular internal structure for objects or a particular layout of their contents. However, the core components in a CAP file are defined assuming a default structure for certain runtime structures (such as descriptions of classes), and a default layout for the contents of dynamically allocated objects. Information from the descriptor component of the CAP file can be used to format objects in whatever way an implementation requires.
The Java Card virtual machine supports instance initialization methods exactly as does the Java virtual machine.
The Java Card virtual machine includes only limited support for class or interface initialization methods. There is no general mechanism for executing <clinit> methods on a Java Card virtual machine. Instead, a CAP file includes information for initializing class data as defined in Section 2.2.4.6, Class Initialization.
Exception support in the Java Card virtual machine is identical to support for exceptions in the Java virtual machine.
This specification defines two binary file formats which enable platform-independent development, distribution and execution of Java Card programs.
The CAP file format describes files that contain executable code and can be downloaded and installed onto a Java Card technology-enabled device. A CAP file is produced by a Java Card platform Converter tool, and contains a converted form of an entire package of Java classes. This file format's relationship to the Java Card virtual machine is analogous to the relationship of the class file format to the Java virtual machine.
The export file format describes files that contain the public linking information of Java Card API packages. A package's export file is used when converting client packages of that package.
The Java Card virtual machine instruction set is quite similar to the Java virtual machine instruction set. Individual instructions consist of a one-byte opcode and zero or more operands. The pseudo-code for the Java Card virtual machine's instruction fetch-decode-execute loop is the same. Multi-byte operand data is also encoded in big-endian order.
There are a number of ways in which the Java Card virtual machine instruction set diverges from that of the Java virtual machine. Most of the differences are due to the Java Card virtual machine's more limited support for data types. Another source of divergence is that the Java Card virtual machine is intended to run on 8-bit and 16-bit architectures, whereas the Java virtual machine was designed for a 32-bit architecture. The rest of the differences are all oriented in one way or another toward optimizing the size or performance of either the Java Card virtual machine or Java Card programs. These changes include inlining constant pool data directly in instruction opcodes or operands, adding multiple versions of a particular instruction to deal with different datatypes, and creating composite instructions for operations on the current object.
The Java Card virtual machine supports only a subset of the types supported by the Java virtual machine. This subset is described in Chapter 2. Type support is reflected in the instruction set, as instructions encode the data types on which they operate.
Given that the Java Card virtual machine supports fewer types than the Java virtual machine, there is an opportunity for better support for smaller data types. Lack of support for large numeric data types frees up space in the instruction set. This extra instruction space has been used to directly support arithmetic operations on the short data type.
Some of the extra instruction space has also been used to optimize common operations. Type information is directly encoded in field access instructions, rather than being obtained from an entry in the constant pool.
TABLE 3-1 summarizes the type support in the instruction set of the Java Card virtual machine. Only instructions that exist for multiple types are listed. Wide and composite forms of instructions are not listed either. A specific instruction, with type information, is built by replacing the T in the instruction template in the opcode column by the letter representing the type in the type column. If the type column for some instruction is blank, then no instruction exists supporting that operation on that type. For instance, there is a load instruction for type short, sload, but there is no load instruction for type byte.
The mapping between Java storage types and Java Card virtual machine computational types is summarized in TABLE 3-2.
Chapter 7 describes the Java Card virtual machine instruction set in detail.
| Virtual Machine Specification, Java Card Platform, v2.2.2 | 3-11-06 |
|
Copyright © 2005, Sun Microsystems, Inc. All Rights Reserved.