Red Hat Devs Working On ARM64 OpenJDK Port 63
hypnosec writes "Developers over at Red Hat are busy porting OpenJDK to ARM's latest 64-bit architecture — the ARMv8, also known as the AArch64. The current OpenJDK ARM situation is rather unsatisfactory: for the current 32-bit ARM processors, there are two versions of the HotSpot JVM for OpenJDK — Oracle's proprietary JIT, and a less sophisticated free JIT that performs poorly in comparison. To avoid a similar situation for the 64-bit platform, the developers are working on an entirely Free Software port of HotSpot to 64-bit ARM."
Re:Secret ARM opcodes can execute JVM bytecode (Score:2, Informative)
Jezelle is slow and is not intended for performance. It was intended for low power execution.
The HotSpot JVM is and adaptive compiler. Java Byte codes are converted into native instructions during executions. Over time, critical paths will become fully optimized. "Hot spots" in the execution will be further dynamically executed.
You see, running native is fast. There's no difference between what the JVM can compile to native and, say, a c compiler. In light of being able to simply parse and convert byte code directly to the underlying assembly, something like Jazelle really doesn't offer much. It's not like it has magic instructions that will somehow be faster then the execution units in the CPU.
Of course, the compiling costs time and therefore power. Something less good, perhaps, on mobile. (Though caching the binaries from a first run isn't that hard.) On an ARM server you wouldn't care about the compile time spent, because execution time is better in native.
It's also important to point out that most ARM implementations only support Jazelle at the ISA level. That is, they don't map directly to any kind of Java-execution hardware. Instead, microcode simply maps it to regular arm to get simple instructions. This is quite a bit slower than what the JVM would produce, since it does no dynamic optimizations based on the run time profile. (additional loop unrolling, method inlining where appropriate, etc)