Does Android castrate the ARM's Jazelle technology?

Question

The justification that I've seen for shall we say "Bastardizing" the Java bytecodes in Android was performance. (I suspect there is another reason.) However by changing the byte codes haven't they made hardware acceleration technologies such as Jazelle moot, and thus actually degraded the performance available for a Mobile Java platform?

It appears counter intuitive to me knowing that the target platform is a ARM based mobile platform. While it MIGHT give you better performance on other CPU architectures it seems to spit in the face of ARM and Jazelle.

What sort of quantitative effect does it have on Java performance?

Does it actually improve performance, and if so how?

What's the effect on other platforms? (i.e. x86,mips,yadda,yadda,yadda...)

Globular

+1. I don't see how this is not programming related. – Uncaredfor

Jazelle has mostly of gone away. Some cores just implement entry/exit/undefined-instruction-trap, and rely on a library to implement the whole thing, which is slower than just doing it in software. – Protuberate

Answer 1

Yes Dalvik makes Jazelle useless. The only question is was Jazelle useful to begin with or is it 90% marketing hype? A good JIT or AOT(ahead of Time) compiler tends to give much better performance than trying to use specialized instructions. The register based approach of Dalvik might be faster than a traditional java bytecode interpreter but if the difference in minor between that of an interpreter and that of a JIT. Hopefully one of the next versions of Android has a JIT.

It takes ~5-10 years to write a good virtual machine with state of the art garbage collectors and optimizers. Sun (and Microsoft) have spent those years. Google hasn't. Hopefully they will keep investing in it so that one day Android Java code isn't a 90% slower than it should be.

Scanlon

I don't know the Jazelle instruction set that well, but the concept when applied to Bytecodes seems logical. Because bytecodes are just a machine code for a "Mythical" processor. Are there performance problems with Jazelle? I can buy the ahead of Time compilation being efficient, because that's no different then saying bytescode is intermediate representation. That's the exact same concept as a normal compiler. And while the same applies for JIT, it requires using extra cycles to do it while you are running the code. – Globular

My intent isn't to dispute your answer, just to get more information. – Globular

Jazelle performs well (2-4x versus normal bytecode) but it still 2-4x+ slower than a JIT. If you read the Sun HotSpot papers you can see the optimizations (inlining functions, eliminating virtual call overhead, removing the need for synchronizations, avoiding object allocations,..) that a modern JIT can do by doing code flow analysis. Jazelle can not do any of them. Jazelles not bad but if you have the choice between a 386, 486 and core 2, I want the core 2. – Scanlon

I haven't seen alot of good Benchmarks that compare Jazelle. I guess the lack of information says more than the benchmarks would if I could find them. So is the jist of this that the Java virtual machine doesn't port as well to hardware as it does to software? – Globular

I am not sure what you mean by port. Jazelle makes executing some byte codes faster. But not faster than executing the same byte codes translated to native arm code. If you can pay the memory (and initial compile time penalty), native code gives you better results. If you just need small speed boost, Jazelle can get you there without the memory hit. – Scanlon

So Jazelle is best used on the lower end ARM platforms? Is that a fair statement? – Globular

If you are memory constrained Jazelle is better than a JIT. If you are CPU bound, JITs (in general. There are exceptions) give you more performance. And if your really low end embedded skip using a java virtual machine and compile your java straight to asm. – Scanlon

Answer 2

Wikipedia: Dalvik virtual machine:

Unlike most virtual machines and true Java VMs which are stack machines, the Dalvik VM is a register-based architecture.

Being optimized for low memory requirements, Dalvik has some specific characteristics that differentiate it from other standard VMs:

• The VM was slimmed down to use less space.
• Dalvik has no just-in-time compiler.
• The constant pool has been modified to use only 32-bit indexes to simplify the interpreter.
• It uses its own bytecode, not Java bytecode.

Moreover, Dalvik has been designed so that a device can run multiple instances of the VM efficiently.

Edit: See Wikipedia: Open Handset Alliance. The founding member includes Intel, Motorola, Qualcomm, and Texas Instruments. ARM joined an year later in December, 2008. So, I guess it didn't make sense for these companies to rely on a proprietary technology by then non-member, when the goal was to create opensource iPhone/Blackberry competitor.

Uncaredfor

I get that for a pure software implementation, but Jazelle adds another variable to the equation which makes performance less cut and dry on that platform. – Globular

Answer 3

I was actually under the impression that Dalvik was intended more for space efficiency than execution efficiency. Also from Wikipedia:

An uncompressed .dex file is typically a few percent smaller in size than a compressed .jar (Java Archive) derived from the same .class files.

While the current phones may use an ARM with Jazelle support, that's not necessarily true going forward.

Also from Wikipedia (warning: hearsay):

The published specifications are very incomplete, being only sufficient for writing operating system code that can support a JVM that uses Jazelle. The declared intent is that only the JVM software needs to (or is allowed to) depend on the hardware interface details. This tight binding facilitates that the hardware and JVM can evolve together without affecting other software. In effect, this gives ARM Holdings considerable control over which JVMs are able to exploit Jazelle. It also prevents open source JVMs from using Jazelle.

Once they add a JITter to Dalvik, it will all be a moot point.

Ileneileo

The hype is that a register based model is suppose to improve performance. Check eed3si9n's post. I've read that Jazelle gives you better performance than JIT alone, I would expect the same is true of JITter. Practically, I'm not sure, but I know that ARM has a whole suite of Java related technology aimed at improving performance including Mixed JIT/Jazelle operation, but that may just be marketing BS. – Globular