JVMLS 2015 - Java Goes AOT

There have been AOT compilers from third party JVM vendors almost since the begining. Used mostly by companies that didn't want to expose their bytecode. However Sun decided to bet the farm on JIT and was against having AOT compilation on the reference JDK. Meaning anyone that wanted a AOT toolchain for Java had to go shopping. Now, it appears Oracle is of a different opinion. "Java Goes AOT" at JVM Language Summit 2015 [this video] Being used to memory safe languages with AOT compilation like Turbo Pascal, Modula-2, Modula-3, Oberon, Delphi, Ada among many others, I also would have prefer that Java and .NET had offered the same type of toolchain from the beginning. Now almost 20 years later, we need to teach young generations that their default implementations were just that, implementations. As they got used to the (wrong) idea that memory safe languages imply a VM.

Hi, What is the rationale for doing this, given that the Graal / JVM guys are already developing an AOT compiler which can compile Scala to native binaries? Is this motivated by performance? The desire to write C libraries in Scala? What? Given the high level, dynamic nature of Scala I am skeptical LLVM+Boehm GC will result in faster code. I expect it would result in slower code. EDIT: OK, I just saw the link to your talk below. I feel you should know a few things: 1) The Hotspot team are adding AOT compilation to the JVM. There is a talk on it here. This mostly eliminates warmup time: [this video] You can't eliminate warmup time entirely because profile guided on-the-fly optimisation is actually quite powerful and an AOT compiler that doesn't have profile data to work with can't generate code that's as good. But they support tiered AOT, where the AOT compiled code does basic profiling of itself, and then it can still trigger profile-guided JIT compilation if you want to. 2) Interop with native is being heavily worked on in project Panama: another JVM upgrade project. With the current prototype you can feed it arbitrary header files that are parsed with clang, and it generates Java interfacing files that are efficiently compiled (no overhead). There's a Pointer<T> type and so on. 3) Stack allocation isn't so easy to do unless you are willing to pretty wildly violate the safety of the language. It's also been found to not help much when very adventurous JVM implementors tried it an