PRODUCT HOW-TO: Use ARM DBX hardware extensions to accelerate Java in space-constrained embedded apps
By Chris Porthouse, ARM Ltd.
(10/14/07, 03:40:00 PM EDT) -- Embedded.com
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.
Software solutions
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.
(10/14/07, 03:40:00 PM EDT) -- Embedded.com
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.
Software solutions
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.
To read the full article, click here
Related Semiconductor IP
- TSMC 7nm 0V75 / 0V9 ESD Local Clamp – Low Cap
- TSMC 65nm 3V3 ESD Local Clamp – Rad Hard
- TSMC 5nm 1V8, 1.2V and 0.9V ESD Local Protection – Low Cap
- TSMC 3nm 3V3 ESD Local Clamp
- TSMC 3nm 1V2 ESD Local Clamp – Low Capacitance
Related Articles
- How to use snakes to speed up software without slowing down the time-to-market?
- How to accelerate memory bandwidth by 50% with ZeroPoint technology
- How to manage changing IP in an evolving SoC design
- How Low Can You Go? Pushing the Limits of Transistors - Deep Low Voltage Enablement of Embedded Memories and Logic Libraries to Achieve Extreme Low Power
Latest Articles
- LACE: Large Language Model Aided Multi-Agent Framework for Agile RISC-V Instruction Extension
- A Process-Aware Hybrid Si/IGO Monolithic-3D 6T SRAM with BEOL Pass-Gates for the 2nm Node
- Automated Estimation of MBIST Area and Test Time in Heterogeneous Memory IPs via Stacked Ensemble Framework
- VIPER: Architecture-Aware Performance Modeling for Processing-in-Memory Design-Space Exploration
- CTTE: An Open Dual-Protocol RISC-V Trace Encoder for N-Trace and E-Trace