[alexambarch]

> Also, oh, man, Jazelle. I'd forgotten about that. Hardware support for Java bytecode... that did not pan out well.

As someone who was too young to be paying any attention during this time, what were some of the reasons this didn’t pan out? Java seems so dominant looking back that I’m surprised something like this wouldn’t have been a success.

[bitwize]

The Lisp machine failed because Lisp compiler technology got better and better at targeting generic 32-bit CPU hardware, which was becoming increasingly cheap and plentiful. So the benefits of having all this custom hardware to specially execute Lisp code were nullified -- leaving only the costs.

The same thing happened to Java in hardware. It seemed like a good idea at the time because it allowed developers to target a language they were already familiar with, and present an alternative to Wintel -- especially when you realize that Java was all the rage as a sort of universal programming environment, and in particular J2ME was a big deal for proto-"smart" phones before the iPhone came along. But embedded Java didn't really pan out, memory and CPU time got cheaper, and compiler and JIT tech improved to the point where there was just no benefit to adding the hardware it took to decode Java instructions. So Jazelle was deprecated and replaced with something called ThumbEE, which was a more generic framework based on ARM's Thumb instruction set for running code for an abstract machine, providing features like automatic null-pointer checking and that. Like you could set up a ThumbEE environment for running Python or .NET code in addition to Java. Nowadays even ThumbEE is deprecated. Neither feature appears in ARMv8 processors, for instance.

[vanderZwan]

I have also wondered this for years, and always was told "because JITs work better", but that felt a bit handwavy. Luckily for both of us David Chisnall just published an article on ACM about designing ISAs that properly explains the reasoning behind Jazelle and why it did not work in the long run:

> Small code is also important [for a simple single-issue in-order core]. A small microcontroller core may be as small as 10KB of SRAM (static random access memory). A small decrease in encoding efficiency can dwarf everything when considering the total area cost: If you need 20 percent more SRAM for your code, then that can be equivalent to doubling the core area. Unfortunately, this constraint almost directly contradicts the previous one [about decoder complexity]. This is why Thumb-2 and RISC-V focused on a variable length encoding that is simple to decode: They save code size without significantly increasing decoder complexity.

> This is a complex tradeoff that is made even more complicated when considering multiple languages. For example, Arm briefly supported Jazelle DBX (direct bytecode execution) on some of its mobile cores. This involved decoding Java bytecode directly, with Java VM (virtual machine) state mapped into specific registers. A Java add instruction, implemented in a software interpreter, requires at least one load to read the instruction, a conditional branch to find the right handler, and then another to perform the add. With Jazelle, the load happens via instruction fetch, and the add would add the two registers that represented the top of the Java stack. This was far more efficient than an interpreter but did not perform as well as a JIT (just-in-time) compiler, which could do a bit more analysis between Java bytecodes.

> Jazelle DBX is an interesting case study because it made sense only in the context of a specific set of source languages and microarchitectures. It provided no benefits for languages that didn't run in a Java VM. By the time devices had more than about 4MB of RAM, Jazelle was outperformed by a JIT. Within that envelope, however, it was a good design choice.

> Jazelle DBX should serve as a reminder that optimizations for one size of core can be incredibly bad choices for other cores

So: a decent JIT works better if you can afford the overhead of the JIT. Jazelle was only a good idea in a very brief period of time when this wasn't true, and even then only if you insist on running a Java VM.

[0] https://queue.acm.org/detail.cfm?id=3639445

[dmitrygr]

Because it be behind an NDA and a paywall and the cost of getting the info was not worth the speedup.