It's interesting to watch the swings and roundabouts in the VM engineering space. I remember many years ago being in a Google engineering all hands where Android was first announced (to the firm) and the technical architecture was explained. I and quite a few others were very surprised to hear that they planned to take slow, limited mobile devices and run a Java bytecode interpreter on them. The stated rationale was also quite surprising: it was done to save memory. I remember being very dubious about the idea of running a GCd interpreted language on a mobile phone (I had J2ME experience!).

In the years since I've seen Android go from interpreter, to interpreter+JIT, to AOT, to JIT+AOT, to interpreted + JIT then AOT at night. V8 has gone from only JIT (compile on first use) to multiple JITs to now, interpreter+single JIT. MS CLR still doesn't have any interpreter and is fully AOT or JIT depending on mode. HotSpot started interpreted, then gained a parallel fast JIT, then gained a parallel optimising JIT, then went to a tiered mechanism where code can be interpreted, compiled and recompiled multiple times before the system stabilises at peak performance.

Looking back, it's apparent that Android's and indeed Java's initial design was really quite insightful. A tight bytecode interpreter isn't quite as awful as it sounds, especially given how far CPU core execution speed has raced ahead of memory and cache availability. If you can fit an interpreter almost entirely in icache, and pack a ton of logic into dense bytecode, and if you can use spare cores that would otherwise be idle (in desktop/mobile scenarios) to do profile guided optimisation, you can end up utilising machine resources more effectively than it might otherwise appear.