>> - 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.

Emscripten is an amazing project. I cannot express the amount of fun I've been having the last few months.

A few things I've been working on:

A N64 emulator that already runs a few demos quite fast. The Super Mario 64 rom loads, but it doesn't work yet. I suspect it to be a TLB issue.

A dosbox port, which I'll later try to use to run Windows 95 on top. I know, this is a monumental attack on Microsoft's copyright. I won't release this.

A port of the dillo browser. A browser inside another browser. I've looked into webkit but I'm sure it is too big to fit in a browser.

A port of PHP's cli interpreter.

If all of this is not fun, then I don't know what fun is! All thanks to LLVM and emscripten.

Don't assume that VMKit is faster than OpenJDK; LLVM is powerful but it's not magic awesome sauce (see Unladen Swallow). Also see GCJ.

And here's a plug for ruby-llvm!

https://github.com/jvoorhis/ruby-llvm

Since the LLVM type system was rewritten, I have a lot of work to do to target 3.0.

> A faster Java that doesn't require a virtual machine?

I don't know about 'faster', but gcj has been compiling Java to machine code for a while now.

From the homepage:

> GCJ is a portable, optimizing, ahead-of-time compiler for the Java Programming Language. It can compile Java source code to Java bytecode (class files) or directly to native machine code, and Java bytecode to native machine code.

http://gcc.gnu.org/java/

LLVM actually still is a virtual machine, since it contains mechanisms for executing code written in LLVM IR. There are two execution paths - an interpreter and a JIT compiler. I guess this makes it a VM after all, although the acronym is no longer descriptive because the VM part is a tiny fraction of what LLVM includes and can do. As you said, its super-tool for creating compilers, especially compiler back-ends.

"if the name is an acronym, you should spell out the acronym"

(I did not downvote you BTW)

Someone else replied that the project is now just referred to as LLVM. That's fine, but people expect acronyms to stand for something, and the definition or lack of should be way at the top of any project. Lots of people come to a project for the first time and aren't in the know.

They probably should have it in their FAQ, though, if they don't.

The problem with "Low-Level Virtual Machine" is that it gives a very wrong view of what LLVM actually is (because a "virtual machine" is associated with JVM and similar tools). That full name is not even used a whole lot any more, people refer to LLVM as LLVM which means the umbrella project under which a lot of subprojects exist.