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

Oracle is planning to finally add it to the standard JDK around Java 10 timeframe, but it might be a premium feature similar to the mission control licensing. [VIDEO]

Afaik IBM's JVM supports class data sharing, which effectively provides AOT behavior once they have been JITed. For oracle's VM they're working on a commercial feature [VIDEO] There also are things like nailgun which simply prestart a JVM and then delegate to the loaded JVM when you invoke some command. It may be a bit of a workaround, but if your use-case is to frequently start extremely shortlived programs that might be worth it.

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: [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

There was a talk about it last year: [VIDEO] The project seems to have gone slower than I expected, perhaps because Chris Thalinger moved to Twitter.

It's explained in the talk "Java goes AOT": [VIDEO] Basically they thought it'd de-opt too much. I'm not totally sure it's the case but they'd be the experts on that.

> Compiles to binary which could bring benefits depending on your needs (compared to JS, Java, Scala..) While its not there _yet_, JEP 295: Ahead-of-Time Compilation ( [LINK] ) is active, it was just updated last week, is targeted and a priority 1 item. I have reasonable confidence that it will get there in the near future. See also: JVMLS 2015 - Java Goes AOT [VIDEO]