Use ARM DBX hardware extensions to accelerate Java in space-constrained embedded appsThis "Product How-To" article focuses how to use a certain product in an embedded system and is written by a company representative.
Performance is an issue constantly raised about the Java platform. Java's portability is also a major disadvantage, as bytecode must always undergo some form of conversion to run on the native instruction set of the underlying architecture. The feature-rich demands of next-generation Java applications will quickly outstrip the capabilities of current massmarket Java handsets.
Hardware graphics accelerators, increasing processor clock speeds, and fast data transfer rates are all changing the application types that can run on mobile devices. If Java is to keep pace, Java platform performance must improve and a powerful Java Virtual Machine (JVM) must be used.
|Figure 1: To reduce die size and improve performance, Jazelle DBX is implemented in the ARM pipeline as a finite state machine rather than a traditional microcode engine.|
Traditional methods of improving Java execution speed include software solutions - such as optimized JVMs, just-in-time (JIT) or ahead-of-time (AOT) compilers - and hardware solutions - such as dedicated Java processors and Java co-processors.
Depending on the system, high speed levels can be achieved using these methods. However, delivering this performance on an embedded platform has typically involved power, memory or platform cost. JIT and AOT compilers compile code for immediate execution on the target device. An AOT compiler compiles all code after application download, some of which may not even run during execution.
A JIT compiler, meanwhile, compiles code "on sight" - i.e. just prior to execution. On an embedded device, JIT compilation causes a delay between an application's launch and its actual run. Research has likewise shown that dynamically compiled code expands four to six times. So, in addition to slow application startup with a JIT, extra memory is required for the code compiled by JIT and AOT solutions.
Using a hybrid software is one way to address issues with JIT compilers on embedded systems. This software solution is often referred to as dynamic adaptive compiler (DAC), which combines a JIT compiler and a bytecode interpreter.
Bytecodes are initially executed by interpretation, while the software profiles the code and determines key code sections to be compiled. Once compiled, these key code sections are run as native code.
Using a DAC may diminish JIT compiler problems, but the maximum speed achievable with a true JIT is compromised, and start-up time and code bloat may still be significant. Until code has been profiled, an application will run in a slow interpreter mode, then pause to generate compiled code.
When an application is launched, many methods are run only once, so they should not be compiled. This significantly impacts user experience, particularly at application start-up when a device appears un-responsive for a long period.
Because software interpretation is very slow, most DAC solutions do little profiling and compile almost all methods immediately, taking a gamble that a method is not to be executed for the last time, but many more times. This could be a costly risk - not only is time consumed compiling an overhead, but the compiled code is also using up memory for no gain.
Finally, when memory runs low, a DAC must discard previously compiled code and may recompile or compile a new one. This usually leads to efficiency problems as an application pauses while the DAC is compiling.
This can be seen as a user moves to a new scene in a game for example. Despite these drawbacks, solutions such as DAC and even partial AOT become attractive as embedded devices increase in capability, particularly the available RAM and ROM.
However, a parallel trend is for more system platforms to be written in Java, more downloaded applications to become Java applications, and multiple Java applications to be able to run concurrently. Thus, available memory for Java is constantly being pushed to the limit.