StackMap ------ The different attribute between j2se and j2me.

        CLDC requires that a Java VM be able to identify and reject invalid classfiles. However, since the standard classfile verification approach defined by J2SE is too memory-consuming for small devices, CLDC defines an alternative mechanism for classfile verification.In this alternative, each method in a downloaded Java classfile contains a “stackmap” attribute. This attribute is newly-defined in CLDC and is not defined by The Java Virtual Machine Specification. Typically, this attribute is added to standard classfiles by a “pre-verification” tool that analyzes each method in the classfile. Pre-verification is typically performed on a server or desktop system before the classfile is downloaded to the device (see Figure 3-1). The stack map attribute increases the size of a classfile by approximately 5%.

 

        The presence of this attribute enables a CLDC-compliant Java VM to verify Java classfiles much more quickly and with substantially less VM code and dynamic RAM consumption than the standard Java VM verification step, but with the same level of security. Note that since stack maps have been implemented by utilizing the extensible attribute mechanism built in Java classfiles, classfiles containing stack maps will run unmodified in larger Java environments such as J2SE or J2EE. (PS by sodino: But classfiles without stack maps will NOT run normally in KVM and a java/lang/VerifyError will be thrown)

from:J2ME Building Blocks for Mobile Devices -- White Paper on KVM and the Connected, Limited Device Configuration (CLDC)

 

 

 

The type checker requires a list of stack frame maps for each method with a Code attribute. The type checker reads the stack frame maps for each such method and uses these maps to generate a proof of the type safety of the instructions in the Code attribute. The list of stack frame maps is given by the stack map attribute. This section specifies the format of the stack map attribute. If the stack map attribute does not conform to the format specified in this section, the Java virtual machine must throw a java.lang.ClassFormatError.

 The intent is that a stack frame map must appear at the beginning of each basic block in a method. The stack frame map specifies the verification type of each operand stack entry and of each local variable at the start of each basic block.


The stack map attribute is an optional variable-length attribute in the attributes table of a Code attribute. The name of the attribute is StackMap. A stack map attribute consists of zero or more stack map frames. Each stack map frame specifies an offset, an array of verification types for the local variables, and an array of verification types for the operand stack.
If a method’s Code attribute does not have a StackMap attribute, it has an implicit stack map attribute. This implicit stack map attribute is equivalent to a StackMap attribute with number_of_entries equal to zero. A method’s Code attribute may have at most one StackMap attribute, otherwise a java.lang.ClassFormatError is thrown.
The format of the stack map in the class file is given below. In the following, if the length of the method’s byte code1 is 65535 or less, then uoffset represents the type u2; otherwise uoffset represents the type u4. If the maximum number of local variables for the method is 65535 or less, then ulocalvar represents the type u2; otherwise ulocalvar represents the type u4. If the maximum size of the operand stack is 65535 or less, then ustack represents the type u2; otherwise ustack represents the type u42.

stack_map { // attribute StackMap
    u2 attribute_name_index;
    u4 attribute_length
    uoffset number_of_entries;
    stack_map_frame entries[number_of_entries];
}

Each stack map frame has the following format:
stack_map_frame {
    uoffset offset;
    ulocalvar number_of_locals;
    verification_type_info locals[number_of_locals];
    ustack number_of_stack_items;
    verification_type_info stack[number_of_stack_items];
}
The 0th entry in locals represents the type of local variable 0. If locals[M] represents local variable N, then
locals[M+1] represents local variable N+1 if locals[M] is one of Top_variable_info,
Integer_variable_info, Float_variable_info, Null_variable_info,
UninitializedThis_variable_info, Object_variable_info, or Uninitialized_variable_info, otherwise locals[M+1] represents local variable N+2. It is an error if,
for any index i, locals[i] represents a local variable whose index is greater than the maximum number of local
variables for the method.
The 0th entry in stack represents the type of the bottom of the stack, and subsequent entries represent types of stack
elements closer to the top of the operand stack. We shall refer to the bottom element of the stack as stack element 0,
and to subsequent elements as stack element 1, 2 etc. If stack[M] represents stack element N, then stack[M+1]
represents stack element N+1 if stack[M] is one of Top_variable_info, Integer_variable_info,
Float_variable_info, Null_variable_info, UninitializedThis_variable_info,
Object_variable_info, or Uninitialized_variable_info, otherwise stack[M+1] represents
stack element N+2. It is an error if, for any index i, stack[i] represents a stack entry whose index is greater than
the maximum operand stack size for the method.
We say that an instruction in the byte code has a corresponding stack map frame if the offset in the offset field of the
stack map frame is the same as the offset of the instruction in the byte codes.
The verification_type_info structure consists of a one-byte tag followed by zero or more bytes, giving
more information about the tag. Each verification_type_info structure specifies the verification type of one
or two locations.
union verification_type_info {
Top_variable_info;
Integer_variable_info;
Float_variable_info;
Long_variable_info;
Double_variable_info;
Null_variable_info;
UninitializedThis_variable_info;
Object_variable_info;
Uninitialized_variable_info;
}
The Top_variable_info indicates that the local variable has the verification type top (.)
Top_variable_info {
u1 tag = ITEM_Top; /* 0 */
}
The Integer_variable_info type indicates that the location contains the verification type int.
Integer_variable_info {
u1 tag = ITEM_Integer; /* 1 */
}
The Float_variable_info type indicates that the location contains the verification type float.
Float_variable_info {
u1 tag = ITEM_Float; /* 2 */
}
The Long_variable_info type indicates that the location contains the verification type long. If the location is
a local variable, then:
• It must not be the local variable with the highest index.
• The next higher numbered local variable contains the verification type  .
If the location is an operand stack entry, then:
• The current location must not be the topmost location of the operand stack.
• the next location closer to the top of the operand stack contains the verification type  .
This structure gives the contents of two locations in the stack[] or local[] array.
Long_variable_info {
u1 tag = ITEM_Long; /* 4 */
}
The Double_variable_info type indicates that the location contains the verification type double. If the
location is a local variable, then:
• It must not be the local variable with the highest index.
• The next higher numbered local variable contains the verification type  .
If the location is an operand stack entry, then:
• The current location must not be the topmost location of the operand stack.
• the next location closer to the top of the operand stack contains the verification type  .
This structure gives the contents of two locations in the stack[] or local[] array.
Double_variable_info {
u1 tag = ITEM_Double; /* 3 */
}
The Null_variable_info type indicates that location contains the type checker type null.
Null_variable_info {
u1 tag = ITEM_Null; /* 5 */
}
The UninitializedThis_variable_info type indicates that the location contains the verification type
uninitializedThis.
UninitializedThis_variable_info {
u1 tag = ITEM_UninitializedThis; /* 6 */
}
The Object_variable_info type indicates that the location contains the class referenced by the constant pool
entry.
Object_variable_info {
u1 tag = ITEM_Object; /* 7 */
u2 cpool_index;
}
The Uninitialized_variable_info indicates that the location contains the verification type
uninitialized(offset). The offset item indicates the offset of the new instruction that created the object being
stored in the location.
Uninitialized_variable_info {
u1 tag = ITEM_Uninitialized /* 8 */
uoffset offset;
}

 

from:Appendix1-verifier  CLDC Byte Code Typechecker Specification