Jazelle DBX: Allow ARM processors to execute Java bytecode in hardware
1–10 of 77 posts
Re: Jazelle DBX: Allow ARM processors to execute Java bytecode in hardware
#2Jazelle and its replacement, ThumbEE, have been deprecated and removed in later architectures.
On modern Cortex-A systems, there are enough resources to make JIT feasible. On smaller systems, AOT is a reasonable alternative.
Re: Jazelle DBX: Allow ARM processors to execute Java bytecode in hardware
#3My brainfog claims some blurry memories of this ... for one, documentation is lacking so much that an opensource JVM using Jazelle never happened; you wanted to develop a JVM on top of it, you'd pay ARM for docs, professional services, and unit licenses. And second, that once things got to the ARM11 series cores, software JITs beat the cr* out of Jazelle. I don't remember any early Android device ever used it.
ARM is quite capable in vapourware generation. 64bit ARM was press-released (https://www.zdnet.com/article/arm-to-unleash-64-bit-jaguar-f...) a decade before ARMv8 / aarch64 became a thing.
(I'd love to learn more)
Re: Jazelle DBX: Allow ARM processors to execute Java bytecode in hardware
#4My brainfog claims some blurry memories of this ... for one, documentation is lacking so much that an opensource JVM using Jazelle never happened; you wanted to develop a JVM on top of it, you'd pay ARM for docs, professional services, and unit licenses. And second, that once things got to the ARM11 series cores, software JITs beat the cr* out of Jazelle. I don't remember any early Android device ever used it. ARM is…
> I don't remember any early Android device ever used it.
It couldn't have, as Dalvik VM is distinct from JVM.
Re: Jazelle DBX: Allow ARM processors to execute Java bytecode in hardware
#5I remember reading about Jazelle many years ago - before the release of the iPhone and suchlike. This was the age when people were coming up with things like 'Java Card' - smartcards programmed directly in Java.
I never heard of anyone actually using Jazelle, though - I assume JIT ended up working better.
Re: Jazelle DBX: Allow ARM processors to execute Java bytecode in hardware
#6My brainfog claims some blurry memories of this ... for one, documentation is lacking so much that an opensource JVM using Jazelle never happened; you wanted to develop a JVM on top of it, you'd pay ARM for docs, professional services, and unit licenses. And second, that once things got to the ARM11 series cores, software JITs beat the cr* out of Jazelle. I don't remember any early Android device ever used it. ARM is…
> I don't remember any early Android device ever used it. It couldn't have, as Dalvik VM is distinct from JVM.
It executes Java Bytecode. Whether Dalvik VM was/is a "Java" VM is hardly relevant there (not the least because "Java" is so much more than Java Bytecode, and Jazelle does nothing to help with anything on top of the latter).
Re: Jazelle DBX: Allow ARM processors to execute Java bytecode in hardware
#7Earlier quoted context omitted.
> I don't remember any early Android device ever used it. It couldn't have, as Dalvik VM is distinct from JVM.
It executes Java Bytecode. Whether Dalvik VM was/is a "Java" VM is hardly relevant there (not the least because "Java" is so much more than Java Bytecode, and Jazelle does nothing to help with anything on top of the latter).
Apparently it's not even Java bytecode. Would make sense, after all Dalvik is register-based. https://stackoverflow.com/a/36335740
Re: Jazelle DBX: Allow ARM processors to execute Java bytecode in hardware
#8The gains seem to not have been high enough to sustain that project. Nowadays CPUs plan, fuse and reorder so much of micro-code that lower-level languages can sort of be considered virtual as well.
But Java and similar languages extract more freedom-of-operation from the programmer to the runtime: no memory address shenanigans, richer types, and to some extent immutability and sealed chunks of code. All these could be picked up and turned into more performance by the hardware; with some help from the compiler. Sort of like SQL being a 4th-gen language, letting the runtime collect statistics and chose the best course of execution (if you squint at it in the dark with colored glasses)
More recent work about this is to be found on the RISC-V J extension [1], still to be formalized and picked up by the industry. Three features could help dynamic languages:
* Pointer masking: you can fit a lot in the unused higher bits of an address. Some GCs use them to annotate memory (refered-to/visited/unvisited/etc.), but you have to mask them. A hardware assisted mask could help a lot.
* Memory tagging: Helps with security, helps with bounds-checking
* More control over instruction caches
It is sort of stale at the moment, and if you track down the people working on it they've been reassigned to the AI-accelerator craze. But it's going to come back, as Moore's law continues to end and Java's TCO will again be at the top of the bean-counter's stack.
Re: Jazelle DBX: Allow ARM processors to execute Java bytecode in hardware
#9Fun fact, both the Wii's seconday ARM chip used for security tasks and the iPhone 2G's processors had Jazelle but never used them.
Re: Jazelle DBX: Allow ARM processors to execute Java bytecode in hardware
#10My brainfog claims some blurry memories of this ... for one, documentation is lacking so much that an opensource JVM using Jazelle never happened; you wanted to develop a JVM on top of it, you'd pay ARM for docs, professional services, and unit licenses. And second, that once things got to the ARM11 series cores, software JITs beat the cr* out of Jazelle. I don't remember any early Android device ever used it. ARM is…
There is a bit of info including example code on https://hackspire.org/index.php/Jazelle