3 ms·

We already have a bare metal VM though. It's called X86. Call me a luddite but I have never seen the point of Java and the JVM at all.

mbreese 17y ago
I can think of two main benefits you can get from a VM that you can't get from bare metal: 1) (and this is also true for most if not all dynamic languages) that you can distribute your app to anyone on any machine and have it run. This does limit your access to the full capabilities if the hardware, but write once run anywhere was pretty close to being true (at least at the JVM level). 2) you can perform optimizations at runtime that you may not have known about at compile time. As I see it, those are the main theoretical benefits.
- dkersten 17y ago
  Theres no reason you cannot get #2 in hardware.. now that'd be an interesting direction for processor manufacturers to go - architectures and instruction sets designed like that of a VM, with built in garbage collection and runtime optimisation and dynamic dispatch features. As for #1, write once run anywhere still doesn't seem to be quite there, imho.
  - rykov 17y ago
    I thought the outcome of CISC vs RISC battle has shown that best performance comes from simpler/faster CPUs with smarter software, not vice versa.
    - dkersten 17y ago
      RISC core and microcoded CISC instructions then? Still, what I meant was that the processor contains logic for some virtual machine style operations, eg keeping track of objects on the heap on-chip (or in a dedicated segment of ram/virtual address space) and having a hardware garbage collector. The main instruction set would still be RISC, but it would contain a small number of CISC instructions for allocating memory which the garbage collector then manages. As for dynamic dispatch, I guess thats not really needed, since it can be constructed from simpler instructions, but having a Python-style method dictionary lookup for member functions be performed in hardware could be interesting. Finally, if a processor had reflection and introspection features.. eg data is annotated in memory so that the structure and state of a program can be determined melodramatically at runtime (and modified). Actually, while writing this, I realise that this probably doesn't really make much sense... :-/
- rbanffy 17y ago
  3) You can have execution checkpoints on transactional memory architectures.
michaelneale 17y ago
I think even the "bare metal" runtimes/languages are going VM-like with LLVM due to the benefits others mention.
rbanffy 17y ago
The x86 ISA is a truly lousy standard. It lacks registers, it's asymmetrical and confusing. It's a Core Whatever wrapped around a Pentium 4 wrapped around a Pentium III wrapped around a Pentium II wrapped around a Pentium Pro wrapped around a Pentium wrapped around a 486 wrapped around a 386 wrapped around a 286 wrapped around a 8086, which is a hastily developed substitute for the failed ia432 built over the 8085, which was an upgrade over the 8080, which was an 8-bit version of a 4004. It's a monster.

mbreese 17y ago

I can think of two main benefits you can get from a VM that you can't get from bare metal: 1) (and this is also true for most if not all dynamic languages) that you can distribute your app to anyone on any machine and have it run. This does limit your access to the full capabilities if the hardware, but write once run anywhere was pretty close to being true (at least at the JVM level). 2) you can perform optimizations at runtime that you may not have known about at compile time. As I see it, those are the main theoretical benefits.

dkersten 17y ago
Theres no reason you cannot get #2 in hardware.. now that'd be an interesting direction for processor manufacturers to go - architectures and instruction sets designed like that of a VM, with built in garbage collection and runtime optimisation and dynamic dispatch features. As for #1, write once run anywhere still doesn't seem to be quite there, imho.
- rykov 17y ago
  I thought the outcome of CISC vs RISC battle has shown that best performance comes from simpler/faster CPUs with smarter software, not vice versa.
  - dkersten 17y ago
    RISC core and microcoded CISC instructions then? Still, what I meant was that the processor contains logic for some virtual machine style operations, eg keeping track of objects on the heap on-chip (or in a dedicated segment of ram/virtual address space) and having a hardware garbage collector. The main instruction set would still be RISC, but it would contain a small number of CISC instructions for allocating memory which the garbage collector then manages. As for dynamic dispatch, I guess thats not really needed, since it can be constructed from simpler instructions, but having a Python-style method dictionary lookup for member functions be performed in hardware could be interesting. Finally, if a processor had reflection and introspection features.. eg data is annotated in memory so that the structure and state of a program can be determined melodramatically at runtime (and modified). Actually, while writing this, I realise that this probably doesn't really make much sense... :-/
rbanffy 17y ago
3) You can have execution checkpoints on transactional memory architectures.

michaelneale 17y ago

I think even the "bare metal" runtimes/languages are going VM-like with LLVM due to the benefits others mention.

rbanffy 17y ago

The x86 ISA is a truly lousy standard. It lacks registers, it's asymmetrical and confusing. It's a Core Whatever wrapped around a Pentium 4 wrapped around a Pentium III wrapped around a Pentium II wrapped around a Pentium Pro wrapped around a Pentium wrapped around a 486 wrapped around a 386 wrapped around a 286 wrapped around a 8086, which is a hastily developed substitute for the failed ia432 built over the 8085, which was an upgrade over the 8080, which was an 8-bit version of a 4004. It's a monster.