One rationale I've seen somewhere is that they were intentionally trying to not commit to a stable instruction set they'd need to support going forward, i.e. intentionally make support very closely coupled to a specific JVM and OS implementation.

Of course it might just also have been a cooperation with a specific JVM vendor (that could then promote their JVM as the fastest on a given set of CPUs).

> "alternate" execution mode that exists solely to emulate x86

Is this something different from TSO?

It so much that JITs became feasible, it's that bigger CPUs were less suitable for Jazelle's approach because of the behaviour of the in-order CPU pipeline.

Because Jazelle converted Java bytecodes into ARM instructions in sequence, there is no opportunity for any instruction scheduling. So a bytecode sequence like:

  // public static int get_x(int x, T a, T b) { return a.x+b.x; }
  aload_1
  getfield #N
  aload_2
  getfield #N
  iadd

would go down the pipeline as something like:

    LDR r1, [r0, #4]   // a_load1
  * LDR r1, [r1]       // getfield
    LDR r2, [r0, #8]   // aload_2
  * LDR r2, [r2]       // getfield
  * ADD r1, r1, r2     // iadd

There would be a pipeline stall before each instruction marked with a *.

On the first ARM 9 CPUs with Jazelle, the pipeline is fairly similar to the standard 5 stage RISC pipeline (Fetch-Decode-Execute-MemoryAccess-Writeback) so this stall would be 1 cycle. That wasn't too bad - you could just accept that loads took usally 2 cycles, and it would still be pretty fast.

However, on later CPUs with a longer pipeline the load-use delay was increased. By ARM11, it was 2 cycles - so now the CPU is spending more time waiting for pipeline stalls that it spends actually executing instructions.

In contrast, even a basic JIT can implement instruction scheduling and find some independent instructions to do between a load and the use of the result, which makes the JIT much more performant than Jazelle could be.

It was more about Memory usage than anything else.

It was designed for a market with feature phones running J2ME apps in about 4-8MB of RAM. The CPU was probably fast enough to do decent JIT compilation, but a JIT compiler would take a few hundred KB of code, and then suck up a large chunk of RAM for the code cache.

As far as I'm aware, it's is not as fast as a JIT would be on the same hardware (due to the stack machine), but Jazelle has the advantage of being significantly faster than an interpreter, while using about the same RAM (if not less).

A bit fuzzy. I mostly work on M-class so idk what the sig would be, but a cursory glance says there's a dedicated "go to Jazelle" instruction that maybe it deals with differently? That way if any bytecodes overlap with arm/thumb it'll still know. Thinking about it, I'm more certain that's what it is. Maybe there's a bytecode that's a valid non-Java encoding that's a valid instruction, so they focus on the Jazelle mode entry

Philosophical question: What does "useful" mean in the context of a game console?

In my view, it's people having fun with it and maybe learning a new thing or two, so I'd say this is as useful as it gets.