The most prominent use of Jazelle DBX is by manufacturers of mobile phones to increase the execution speed of Java ME games and applications.
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.
"[6] Employees of ARM have in the past published several white papers that do give some good pointers about the processor extension.
[citation needed] Versions of the ARM Architecture reference Manual available from 2008 have included pseudocode for the "BXJ" (Branch and eXchange to Java) instruction, but with the finer details being shown as "SUB-ARCHITECTURE DEFINED" and documented elsewhere.
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 (such as following a return from interrupt) will re-execute the complete sequence of related ARM instructions.
[3] 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 (PC) pointing to the next instructions must be placed in the Link Register (R14) before executing the BXJ branch request, as regardless of hardware or software processing, the system must know where to begin decoding.
[7] 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 (with optimised ARM/ThumbEE JVM code), or treated as an invalid/illegal opcode.