How does having a "native" compiler reduce the startup overhead of the JVM? That doesn't make any sense.
It may reduce compile times, but ultimately the reason startup sucks is because the JVM is huge and has to load everything and the kitchen sink in order to function for even the smallest programs.
Because when you compile to native code ahead of time:
1 - There is no JVM
2 - All the code that is not used is not part of the binary, if you do a static build
2.1 - There are native compilers for Java where you can give exclusion lists to allow certain code to be kept even in static builds to allow reflection use
OK, we are not talking about the same thing. I was thinking along the lines of a compiler written in a native (non-jvm) language ala jikes but you are referring to a compiler that compiles to a native executable ala gcj.
I've experimented with gcj in the past. It still suffered from excessive overhead, still had it's own runtime requirements (although obviously not the same as the JVM) and had a lot of serious compatibility issues. Not something I would have based a serious production deployment off of personally. Maybe the state of the art has changed since then.
It may reduce compile times, but ultimately the reason startup sucks is because the JVM is huge and has to load everything and the kitchen sink in order to function for even the smallest programs.