Jazelle


Jazelle DBX is an extension that allows some ARM processors to execute Java bytecode in hardware as a third execution state alongside the existing ARM and Thumb modes. Jazelle functionality was specified in the ARMv5TEJ architecture and the first processor with Jazelle technology was the ARM926EJ-S. Jazelle is denoted by a "J" appended to the CPU name, except for post-v5 cores where it is required for architecture conformance.
Jazelle RCT is a different technology and is based on ThumbEE mode and supports ahead-of-time and just-in-time compilation with Java and other execution environments.
The most prominent use of Jazelle DBX is by manufacturers of mobile phones to increase the execution speed of Java ME games and applications. A Jazelle-aware Java virtual machine will attempt to run Java bytecode in hardware, while returning to the software for more complicated, or lesser-used bytecode operations. ARM claims that approximately 95% of bytecode in typical program usage ends up being directly processed in the hardware.
The published specifications are very incomplete, being only sufficient for writing operating system code that can support a JVM that uses Jazelle. The declared intent is that only the JVM software needs to depend on the hardware interface details. This tight binding facilitates that the hardware and JVM can evolve together without affecting other software. In effect, this gives ARM Holdings considerable control over which JVMs are able to exploit Jazelle. It also prevents open source JVMs from using Jazelle. These issues do not apply to the ARMv7 ThumbEE environment, the nominal successor to Jazelle DBX.

Implementation

The Jazelle extension uses low-level binary translation, implemented as an extra stage between the fetch and decode stages in the processor instruction pipeline. Recognised bytecodes are converted into a string of one or more native ARM instructions.
The Jazelle mode moves JVM interpretation into hardware for the most common simple JVM instructions. This is intended to significantly reduce the cost of interpretation. Among other things, this reduces the need for Just-in-time compilation and other JVM accelerating techniques. JVM instructions that are not implemented in Jazelle hardware cause appropriate routines in the Jazelle-aware JVM implementation to be invoked. Details are not published, since all JVM innards are transparent if correctly interpreted.
Jazelle mode is entered via the BXJ instructions. A hardware implementation of Jazelle will only cover a subset of JVM bytecodes. For unhandled bytecodes—or if overridden by the operating system—the hardware will invoke the software JVM. The system is designed so that the software JVM does not need to know which bytecodes are implemented in hardware and a software fallback is provided by the software JVM for the full set of bytecodes.

Instruction set

The Jazelle instruction set is well documented as Java bytecode. However, ARM has not released details on the exact execution environment details; the documentation provided with Sun's HotSpot Java Virtual Machine goes as far as to state: "For the avoidance of doubt, distribution of products containing software code to exercise the BXJ instruction and enable the use of the ARM Jazelle architecture extension without agreement from ARM is expressly forbidden."
Employees of ARM have in the past published several white papers that do give some good pointers about the processor extension. Versions of the ARM Architecture Reference Manual available from 2008 have included pseudocode for the "BXJ" instruction, but with the finer details being shown as "SUB-ARCHITECTURE DEFINED" and documented elsewhere.

Application binary interface (ABI)

The Jazelle state relies on an agreed calling convention between the JVM and the Jazelle hardware state. This application binary interface is not published by ARM, rendering Jazelle an undocumented feature for most users and Free Software JVMs.
The entire VM state is held within normal ARM registers, allowing compatibility with existing operating systems and interrupt handlers unmodified. Restarting a bytecode will re-execute the complete sequence of related ARM instructions.
Specific registers are designated to hold the most important parts of the JVM state: registers R0–R3 hold an alias of the top of the Java stack, R4 holds Java local operand zero and R6 contains the Java stack pointer.
Jazelle reuses the existing program counter PC or its synonym register R15. A pointer to the next bytecode goes in R14, so the use of the PC is not generally user-visible except during debugging.

CPSR: Mode indication

Java bytecode is indicated as the current instruction set by a combination of two bits in the ARM CPSR. The "T"-bit must be cleared and the "J"-bit set.
Bytecodes are decoded by the hardware in two stages and switching between hardware and software decoding takes ~4 clock cycles.
For entry to Jazelle hardware state to succeed, the JE bit in the CP14:C0 register must be set; clearing of the JE bit by a operating system provides a high-level override to prevent application programs from using the hardware Jazelle acceleration. Additionally, the CV bit found in CP14:c0 must be set to show that there is a consistent Jazelle state setup for the hardware to use.

BXJ: Branch to Java

The BXJ instruction attempts to switch to Jazelle state, and if allowed and successful, sets the "J" bit in the CPSR; otherwise, it "falls through" and acts as a standard BX instruction. The only time when an operating system or debugger must be fully aware of the Jazelle mode is when decoding a faulted or trapped instruction. The Java program counter pointing to the next instructions must be placed in the Link Register before executing the BXJ branch request, as regardless of hardware or software processing, the system must know where to begin decoding.
Because the current state is held in the CPSR, the bytecode instruction set is automatically reselected after task-switching and processing of the current Java bytecode is restarted.
Following an entry into the Jazelle state mode, bytecodes can be processed in one of three ways: decoded and executed natively in hardware, handled in software, or treated as an invalid/illegal opcode. The third case will cause a branch to an ARM exception mode, as will a Java bytecode of 0xff, which is used for setting JVM breakpoints.
Execution will continue in hardware until an unhandled bytecode is encountered, or an exception occurs. Between 134 and 149 bytecodes are translated and executed directly in the hardware.

Low-level registers

Low-level configuration registers, for the hardware virtual machine, are held in the ARM Co-processor "CP14 register c0". The registers allow detecting, enabling or disabling the hardware accelerator.
A "trivial" hardware implementation of Jazelle is only required to support the BXJ opcode itself and to return RAZ for all of the CP14:c0 Jazelle-related registers.

Successor: ThumbEE

The ARMv7 architecture has de-emphasized Jazelle and Direct Bytecode Execution of JVM bytecodes. In implementation terms, only trivial hardware support for Jazelle is now required: support for entering and exiting Jazelle mode, but not for executing any Java bytecodes.
Instead, the Thumb Execution Environment was to be preferred, but has since also been deprecated. Support for ThumbEE was mandatory in ARMv7-A processors, and optional in ARMv7-R processors. ThumbEE targeted compiled environments, perhaps using JIT technologies. It was not at all specific to Java, and was fully documented; much broader adoption was anticipated than Jazelle was able to achieve.
ThumbEE was a variant of the Thumb2 16/32-bit instruction set. It integrated null pointer checking; defined some new fault mechanisms; and repurposed the 16-bit LDM and STM opcode space to support a few instructions such as range checking, a new handler invocation scheme, and more. Accordingly, compilers that produced Thumb or Thumb2 code could be modified to work with ThumbEE-based runtime environments.