Last weeks discussion about the Java Optimized Processor somehow turned into a discussion of Azul Systems' mammoth 800 core, 600GB powerhouse. I got in touch with the highly respected Cliff Click and asked if he could comment intelligently about some of the discussion that arose from this posting, which he kindly did on his latest blog entry.
Here's a peek at what he had to say:
Java bytecode is NOT suited to be run on real hardware. It's stack-based, so pipelining goes out of the window. In theory, one can do on-the-fly translation from stack-based to register-based machine, but it'll require A LOT of transistors. So in reality, it's ALWAYS more effective to JIT-compile Java bytecode and then run it on a common CPU.
Azul's CPUs are classic 3-address RISCs, with very few special-for-Java features. Our addressing math matches 64-bit Java math exactly (and pretty much nobody does; saves 1 op per array address math). We allow meta-data in the pointers which the LD/ST unit strips off. We have read & write barriers in hardware (these last are really for GC and not Java). We have a fast-inline-cache instruction. We have a fast-not-contended-CAS for all those not-contended Java locks.
We do NOT have special hardware to parse or execute Java bytecodes in any way. Like the speaker pointed out, it's plain faster and simpler to JIT.
Of course, hardware can still provide few features to speed up JVMs. Like hardware-assisted forwarding pointers which allow to create fast real-time compacting pauseless GC (I assume Azul hardware has this support).
No, our hardware assist is a read-barrier op. The hardware detects when a GC invariant is being blown on a freshly loaded pointer - and traps to a software routine. 1 clk if nothing is wrong (by far, vastly far, the common case) and 4 clks to enter the trap routine if there's an issue. Software does all the fixup, including relocating objects or adjusting pointers or marking or whatever. Generally fixup is done in <100 clks (but not always, rarely an object-copy is required).
If you dig around Cliff Click's blog, you'll find a posting named "I've Been Slashdot'd." In there you'll find the slides he used during the talk he gave at the JVM Language Summit. The discussion he has in there about the challenges facing processor capacity and performance is a required read for anyone in the IT industry. "Memory is the new disk." Say it isn't so, Cliff, say it isn't so...