[stephth]

As an avid reader of HN I'm surprised it's the first time I hear of many of these many (LLVM backed) projects. Some that stood out to me:

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

- LanguageKit is a framework for implementing dynamic languages sharing an object model with Objective-C.

- Eero is a fully header-and-binary-compatible dialect of Objective-C 2.0

Has anyone tried Eero? It looks interesting (and seems to be compatible with Objective-C code): http://eerolanguage.org/from-objective-c-to-eero. One thing I didn't get from the documentation is does Eero still require header files?

[exDM69]

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

[Hrundi]

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.

[iso8859-1]

Links? If you're not going to release that Dosbox port, could you at least leak it? You can do it anonymously.

[wmf]

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.

[stephth]

Precompilation: by compiling ahead of time a small subset of Java's core library, the startup performance have been highly optimized to the point that running a 'Hello World' program takes less than 30 milliseconds.

Sounds faster than the Java I know.

[mikedouglas]

... on startup. That doesn't mean it outcompetes Hotspot over the lifetime of the application.

[Hemospectrum]

That startup time is probably the biggest turnoff for people seeking to write lightweight scripts in JVM languages. If your script's runtime is 100ms after a 5 second startup, it doesn't particularly matter if the machine code version runs at half speed.

[lemming]

Of course, precompilation is usually a big turnoff for those same people.

[lukesandberg]

but it is precompilation of the core library, not the whole app, so presumably it could be done only once for the system and cached somewhere. (maybe like .Nets global assembly cache, which caches jitted dlls)

[kev009]

Right, a naive implementation of anything going up a finely tuned one will generally behave accordingly even if the naive one is using fundamentally better CS :). I would naturally assume that J3 on VMKit is more a proof of concept of VMKit, at least until a lot of people start hacking on it. The other use of LLVM in OpenJDK Shark is about portability rather than pure speed.

The Sun JVM is pretty well tuned. A lot of people have a lot of money riding on top of it performing well. There is room for improvement (see Azul) but I would be surprised if a FOSS project would break much ground without major commercial backing.

Static compilation would have a lot of benefits for short lived programs. I know IBM's i OS (OS/400) used to use statically compiled Java and was quite a bit faster than that era JRE, but it's somewhat cloudy as the whole machine was quasi-VM with the MI level. Not sure if they retained this but it would be interesting to compare now days to i.e. HotSpot in Java 7.

[jvoorhis]

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.

[derleth]

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

[noselasd]

Every single thing I have measured(which, granted, does not cover that much), openjdk comes out way ahead of gcj in terms of speed.

Similarly, running eclipse under gcj is not something you want to do, it becomes slow.

[mraleph]

You should try Excelsior JET compiled Eclipse then.

(see: http://www.excelsior-usa.com/)

[disclaimer: I've worked for Excelsior LLC back then when initial support for AOT compilation of Eclipse was implemented]

[leoh]

Yes, it's also ridiculously difficult to get working. I'm not entirely convinced it's possible to get it to work anymore without some serious hacking; and OS X doesn't include it in their dev package.

[derleth]

See, in Ubuntu, I do 'sudo apt-get install gcj', hit enter twice (to bring in all the dependencies), and a little while later I have gcj up and running on my system.

I don't doubt it needs hacking to get running; I probably wouldn't want to install the latest release from source. However, when you have the package maintainers of two distros (Debian and Ubuntu) on your side, things get a bit easier.