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