Java bytecode constraints

# Bytecode constraints

From the point of view of a piece of code written in the Java programming language or targeted in the same way to `.class` files, the Dalvik VM aims to behave in a way that is fully consistent with the language's definition. That is, the code running in Dalvik will behave the same as it would have running in any other virtual machine. This includes verification failures. The Dx/Dalvik system will check roughly the same constraints that any other VM would, except as noted in the file verifier.html. The following table briefly lists all Dx/Dalvik verification constraints together their analogs from the book The JavaTM Language Specification, second edition. In the numbering scheme, the first three elements refer to the specification chapter, the fourth one to the bullet inside that chapter. The failure mode specifies whether the constraint will fail during the Dx conversion or during verification in the VM itself.

## Static constraints

Static constraints are constraints on individual elements of the bytecode. They usually can be checked without employing control or data-flow analysis techniques.

Identifier | Description | Spec equivalent | Failure mode
--- | --- | --- | ---
A1 | The `code` array must not be empty. | 4.8.1.1 | DX
A2 | The `code` array must not be larger than 65535 bytes. | 4.8.1.2 | DX
A3 | The first opcode in `code` array must have index `0`. | 4.8.1.3 | DX
A4 | The `code` array must only contain valid opcodes. | 4.8.1.4 | DX
A5 | The index of instruction `n+1` must equal the index of instruction `n` plus the length of instruction `n`, taking into account a possible `wide` instruction. Opcodes modified by a `wide` instruction must not be directly reachable. | 4.8.1.5 | DX
A6 | The last instruction in `code` array must end at index `code_length-1`. | 4.8.1.6 | DX
A7 | All jump and branch targets must be opcodes within the same method. Opcodes modified by a `wide` instruction must not be directly reachable via a jump or branch instruction. | 4.8.1.7 | DX
A8 | All targets of a `tableswitch` instruction must be opcodes within the same method. Upper and lower bounds must be consistent. Opcodes modified by a `wide` instruction must not be directly reachable via a `tableswitch` instruction. | 4.8.1.8 | DX
A9 | All targets of a `lookupswitch` instruction must be opcodes within the same method. Its table must be consistent and sorted low-to-high. Opcodes modified by a `wide` instruction must not be directly reachable via a `lookupswitch` instruction. | 4.8.1.9 | DX
A10 | The operands of `ldc` and `ldc_w` instructions must be valid indices into the constant pool. The respective entries must be of type `CONSTANT_Integer`, `CONSTANT_Float`, or `CONSTANT_String`. | 4.8.1.10 | DX
A11 | The operands of `ldc2_w` instructions must be valid indices into the constant pool. The respective entries must be of type `CONSTANT_Long` or `CONSTANT_Double`. The subsequent constant pool entry must be valid and remain unused. | 4.8.1.11 | DX
A12 | The Operands of `get<kind>` and `put<kind>` instructions must be valid indices into constant pool. The respective entries must be of type `CONSTANT_Fieldref`. | 4.8.1.12 | DX
A13 | The first two operands of `invokevirtual`, `invokespecial`, and `invokestatic` must form a valid 16-bit index into the constant pool. The respective entries must be of type `CONSTANT_Methodref`. | 4.8.1.13 | DX
A14 | Methods whose names start with '<' must only be invoked implicitly by the VM, not by class file code. The only exception is the instance initializer, which may be invoked by `invokespecial`. | 4.8.1.14 | DX
A15 | The first two operands of `invokeinterface` must form a valid 16-bit index into the constant pool. The entry must be of type `CONSTANT_Interface_Methodref`. The third operand must specify number of local variables and the fourth operand must always be zero. | 4.8.1.15 | DX
A16 | The operands of `instanceof`, `checkcast`, `new`, and `anewarray` instructions must be a valid index into the constant pool. The first two operands of `multianewarray` instruction must form a valid 16-bit index into the constant pool. All respective entries must be of type `CONSTANT_Class`. | 4.8.1.16 | DX
A17 | The dimensions of an array created by `anewarray` instructions must be less than `256`. | 4.8.1.17 | DX
A18 | The `new` instruction must not reference array classes, interfaces, or abstract classes. | 4.8.1.18 | DX
A19 | The type referenced by a `multinewarray` instruction must have at least as many dimensions as specified in the instruction. The dimensions operand must not be `0` | 4.8.1.19 | DX
A20 | The type referenced by a `newarray` instruction must be a valid, non-reference type. | 4.8.1.20 | DX
A21 | The index operand of instructions explicitly referencing single-width local variables must be non-negative and smaller than `max_locals`. | 4.8.1.21 | DX
A22 | The index operand of instructions implicitly referencing single-width local variables must be non-negative and smaller than `max_locals`. | 4.8.1.22 | DX
A23 | The index operand of instructions explicitly referencing double-width local variables must be non-negative and smaller than `max_locals-1`. | 4.8.1.23 | DX
A24 | The index operand of instructions implicitly referencing double-width local variables must be non-negative and smaller than `max_locals-1`. | 4.8.1.24 | DX
A25 | The index operand of `wide` instructions explicitly referencing single-width local variables must be non-negative and smaller than `max_locals`. | 4.8.1.25 | DX
A26 | The index operand of `wide` instructions explicitly referencing double-width local variables must be non-negative and smaller than `max_locals-1`. | 4.8.1.25 | DX

## Structural constraints

Structural constraints are constraints on relationships between several elements of the bytecode. They usually can't be checked without employing control or data-flow analysis techniques.

Identifier | Description | Spec equivalent | Failure mode
--- | --- | --- | ---
B1 | The number and types of arguments (operands and local variables) must always match the instruction. | 4.8.2.1 | DX
B2 | The operand stack must have the same depth for all executions paths leading to an instruction. | 4.8.2.2 | DX
B3 | Local variable pairs must never be broken up. | 4.8.2.3 | DX
B4 | A local variable (or pair) has to be assigned first before it can be read. | 4.8.2.4 | DX
B5 | The operand stack must never grow beyond `max_stack`. | 4.8.2.5 | DX
B6 | The operand stack must never underflow. | 4.8.2.6 | DX
B7 | An `invokespecial` instruction must only invoke an instance initializer or a method in the current class or one of its superclasses. | 4.8.2.7 | VM
B8 | An instance initializer must only be invoked on an uninitialized instance residing on the operand stack. | 4.8.2.8 | VM
B9 | Instance methods may only be invoked on and instance fields may only be accessed on already initialized instances. | 4.8.2.9 | VM
B10 | The must be no backwards branches with uninitialized instances on the operand stack or in local variables. There must be no code protected by an exception handler that contains local variables with uninitialized instances. | 4.8.2.10 | DX
B11 | An instance initializer must call another instance initializer (same class or superclass) before any instance members can be accessed. Exceptions are non-inherited instance fields, which can be assigned before calling another initializer, and the `Object` class in general. | 4.8.2.11 | VM
B12 | All actual method arguments must be assignment-compatible with formal arguments. | 4.8.2.12 | VM
B13 | For each instance method invocation, the actual instance must be assignment-compatible with the class or interface specified in the instruction. | 4.8.2.13 | VM
B14 | A returns instruction must match its method's return type. | 4.8.2.14 | VM
B15 | When accessing protected members of a superclass, the actual type of the instance being accessed must be either the current class or one of its subclasses. | 4.8.2.15 | VM
B16 | The type of a value stored into a static field must be assignment-compatible with or convertible to the field's type. | 4.8.2.16 | VM
B17 | The type of a value stored into a field must be assignment-compatible with or convertible to the field's type. | 4.8.2.17 | VM
B18 | The type of every value stored into an array must be assignment-compatible with the array's component type. | 4.8.2.18 | VM
B19 | The operand of an `athrow` instruction must be assignment-compatible with `java.lang.Throwable`. | 4.8.2.19 | VM
B20 | The last reachable instruction of a method must either be a backwards jump or branch, a return, or an `athrow` instruction. It must not be possible to leave the `code` array at the bottom. | 4.8.2.20 | VM
B21 | Local variable values must not be used as return addresses. | 4.8.2.21 | VM
B22 | There must be a single, uniquely determined return instruction per subroutine call. | 4.8.2.22 | VM
B23 | Subroutine calls must not be directly or indirectly self-recursive. | 4.8.2.23 | DX
B24 | `ReturnAddress` instances must not be reused. If a subroutine returns to a `ReturnAddress` further up the stack than where its original call instruction is located, then all `ReturnAddress` instances further down the stack must never be used. | 4.8.2.24 | DX