Re: Free the VM two!
Actually the opposite may be true.
The Grand daddy of them was maybe the UCSD p-Code. It can be argued that there is no speed penalty for the majority of a Program running on a P-Code VM. The P-Code will be more compact and load faster than many native codes and is more portable. The VM can manage APIs of the OS and also the different CPU architectures. Easier to port a good PM once and have portable programs.
Davik & Android is another flavour.
In theory too biggest issues are reliability and security. Easier with a P-Code VM to ensure the application doesn't scribble all over the OS or have privileges or pinch stuff it shouldn't.
One can envisage a P-Machine that identifies and caches loops or functions/procedures best optimised as native code. So those portions are compiled at run time. No need to native code almost 98% of the program typically.
Also your SoC or CPU designer can create HW execution for some common P-Code constructs (does ARM Neon do this?). Western Digital implemented a HW UCSD p-code machine with their Bit Slice processor chip set. But that idea fails badly unless you have a 2nd CPU to run a decent OS kernel.
Java/C# may be fine for Applications, but OS Kernel and low level drivers probably better in C++ or even Modula-2 or related languages.