3 ms·

As JVM gets closer to being the de-facto VM for running any language (Jython, jRuby, Scala, Java, etc), the possibility of higher performance by running the VM

by rykov 17y ago

As JVM gets closer to being the de-facto VM for running any language (Jython, jRuby, Scala, Java, etc), the possibility of higher performance by running the VM "closer to metal" is quite exciting. I commend Sun on pushing JVM beyond just Java.

spitfire 17y ago
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.
c00p3r 17y ago
As LLVM gets closer to being the de-facto VM...
- antonovka 17y ago
  Except that LLVM isn't actually a high-level VM. You have to bolt on quite a bit to even begin to run Python, Java, Scala, etc, and achieving interoperability between those has yet to even be approached. LLVM is the best thing since sliced bread -- and there's even work to provide an alternative to Java's c1/c2/interpreter backends using LLVM -- but it's not really a direct replacement for the JVM or any other high-level virtual machine. Something like this might be: http://vmkit.llvm.org/ http://vmkit.llvm.org/
  - gaius 17y ago
    Or http://flyingfrogblog.blogspot.com/2009/03/hlvm-has-been-released.html http://flyingfrogblog.blogspot.com/2009/03/hlvm-has-been-rel...
  - c00p3r 17y ago
    Future looks like this - http://code.google.com/p/unladen-swallow/ http://code.google.com/p/unladen-swallow/
    - antonovka 17y ago
      The future of general purpose VMs is a Python bytecode in an LLVM-backed branch of CPython? That doesn't make any sense. It's only a generic VM in the sense that it's turing complete. You're going to implement Ruby on top of this? Or is everyone just going to get their own incompatible re-implementation of the same VM services?
      - c00p3r 17y ago
        Define general purpose VM? Do not forget ARM and MIPS based platforms. May be not Ruby but Arc.

by rykov 17y ago

spitfire 17y ago

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.

c00p3r 17y ago

As LLVM gets closer to being the de-facto VM...

antonovka 17y ago
Except that LLVM isn't actually a high-level VM. You have to bolt on quite a bit to even begin to run Python, Java, Scala, etc, and achieving interoperability between those has yet to even be approached. LLVM is the best thing since sliced bread -- and there's even work to provide an alternative to Java's c1/c2/interpreter backends using LLVM -- but it's not really a direct replacement for the JVM or any other high-level virtual machine. Something like this might be: http://vmkit.llvm.org/ http://vmkit.llvm.org/
- gaius 17y ago
  Or http://flyingfrogblog.blogspot.com/2009/03/hlvm-has-been-released.html http://flyingfrogblog.blogspot.com/2009/03/hlvm-has-been-rel...
- c00p3r 17y ago
  Future looks like this - http://code.google.com/p/unladen-swallow/ http://code.google.com/p/unladen-swallow/
  - antonovka 17y ago
    The future of general purpose VMs is a Python bytecode in an LLVM-backed branch of CPython? That doesn't make any sense. It's only a generic VM in the sense that it's turing complete. You're going to implement Ruby on top of this? Or is everyone just going to get their own incompatible re-implementation of the same VM services?
    - c00p3r 17y ago
      Define general purpose VM? Do not forget ARM and MIPS based platforms. May be not Ruby but Arc.