The problem is that the bytecodes aren't where the work is done, so speeding up the bytecode portion of the VM would get you negligible speedups. The interprete

The problem is that the bytecodes aren't where the work is done, so speeding up the bytecode portion of the VM would get you negligible speedups. The interpreter is a glorified dynamic dispatch mechanism to code that then has to figure out the type of the arguments and then call the relevant routine. Unless the bytecode VM is doing type tracing, the speedup from just a hardware inner loop will get you probably single digit percentage speedup. But I could see a hardware VM that was a combination of a regular CPU and some of the hot code paths in interpreter as well as operations on primitives of arrays being sped up. The Java processors had the advantage of static types.