>> - The VMKit project is an implementation of a Java Virtual Machine (Java VM or JVM) that uses LLVM for static and just-in-time compilation.
>> Am I reading this right? A faster Java that doesn't require a virtual machine? Does this mean faster Java, Scala, Clojure, or even Ruby, and deployed anywhere that LLVM can build for (which means pretty much everywhere)? Sounds too good to be true.
You are reading it wrong. Every word in the sentence "A faster Java that doesn't require a virtual machine" is somewhat incorrect or inaccurate. Let me explain.
First of all, there are no guarantees that VMKit -powered Java is faster than any other Java implementation out there. The LLVM native code generators are powerful, but they were not initially designed for JIT compilation, so the compilation is said to be a little slower than many other JIT's. I'm not saying that VMKit will be slower, either. It's probably a case by case situation, where one JVM is faster in one case and another one in a different case.
Second, VMKit is a framework for building virtual machines, so the part about "without a virtual machine" doesn't make sense. A VMKit based virtual machine will interpret and JIT compile the Java bytecode pretty much like any other VM out there. In contrast, the GNU Java Compiler (gcj) compiles Java code into native code and works without a bytecode interpreter. I think GCJ is often used to pre-build the Java class libraries into machine code in some setups.
>> Does this mean faster Java, Scala, Clojure, or even Ruby, and deployed anywhere that LLVM can build for (which means pretty much everywhere)?
No, it does not. As said before, the virtual machine is there as usual and the virtual machine has to be ported to the target platform. This may prove to be problematic on e.g. Android, because it ships with a limited userland and you need for example full C++ standard libraries to get LLVM working, which you need for VMKit. (This does not apply to non-JIT'ed language, where LLVM is used ahead of time and not on the target arch).
The real issue of portability across platform is not the target architecture's instruction set architecture (ISA) and it never was (despite what Java marketing wanted you to believe in 1999). With a modern compiler like LLVM it is trivial to produce machine code to multiple architectures like x86, OpenRISC, ARM, MIPS or an AVR microcontroller.
The real issue of portability is the frameworks and libraries needed. It starts from the operating system and standard libraries. Then comes all the libs that are built on top of those.
So even if it were possible to get e.g. Ruby up and running on a previously unsupported platform, the problem would be that Ruby on Rails would probably not work as easily.
I hope this clarifies a few of the misconceptions you had about LLVM and projects that use it. Even though it does not quite fulfill your expectations, remember that LLVM kicks ass.
>> Am I reading this right? A faster Java that doesn't require a virtual machine? Does this mean faster Java, Scala, Clojure, or even Ruby, and deployed anywhere that LLVM can build for (which means pretty much everywhere)? Sounds too good to be true.
You are reading it wrong. Every word in the sentence "A faster Java that doesn't require a virtual machine" is somewhat incorrect or inaccurate. Let me explain.
First of all, there are no guarantees that VMKit -powered Java is faster than any other Java implementation out there. The LLVM native code generators are powerful, but they were not initially designed for JIT compilation, so the compilation is said to be a little slower than many other JIT's. I'm not saying that VMKit will be slower, either. It's probably a case by case situation, where one JVM is faster in one case and another one in a different case.
Second, VMKit is a framework for building virtual machines, so the part about "without a virtual machine" doesn't make sense. A VMKit based virtual machine will interpret and JIT compile the Java bytecode pretty much like any other VM out there. In contrast, the GNU Java Compiler (gcj) compiles Java code into native code and works without a bytecode interpreter. I think GCJ is often used to pre-build the Java class libraries into machine code in some setups.
>> Does this mean faster Java, Scala, Clojure, or even Ruby, and deployed anywhere that LLVM can build for (which means pretty much everywhere)?
No, it does not. As said before, the virtual machine is there as usual and the virtual machine has to be ported to the target platform. This may prove to be problematic on e.g. Android, because it ships with a limited userland and you need for example full C++ standard libraries to get LLVM working, which you need for VMKit. (This does not apply to non-JIT'ed language, where LLVM is used ahead of time and not on the target arch).
The real issue of portability across platform is not the target architecture's instruction set architecture (ISA) and it never was (despite what Java marketing wanted you to believe in 1999). With a modern compiler like LLVM it is trivial to produce machine code to multiple architectures like x86, OpenRISC, ARM, MIPS or an AVR microcontroller.
The real issue of portability is the frameworks and libraries needed. It starts from the operating system and standard libraries. Then comes all the libs that are built on top of those.
So even if it were possible to get e.g. Ruby up and running on a previously unsupported platform, the problem would be that Ruby on Rails would probably not work as easily.
I hope this clarifies a few of the misconceptions you had about LLVM and projects that use it. Even though it does not quite fulfill your expectations, remember that LLVM kicks ass.