Ahead-of-Time Compilation • Hacker News Board

Re: Ahead-of-Time Compilation

#11

Post by psuter » Sat, Oct 01, 2016, 4:32 AM UTC

avbor wrote: post #4

I'm not familiar enough with compilers, but why would an ahead of time compiler perform worse than a just in time compiler in a static language? I think I'd understand if it was a dynamic language, because you can't know the types for sure until you start running the program, but are similar issues present for Java?

One thing JIT compilers are good at is specializing methods for common (runtime) types; e.g. you have a method operating on Iterable but it turns out most of the time you get a List as input; you can generate code that bypasses the method lookups for .size etc. The question of whether this pays off is usually only answerable at runtime.

Re: Ahead-of-Time Compilation

#12

Post by jcdavis » Sat, Oct 01, 2016, 4:34 AM UTC

johnydepp wrote: post #3

That's great! Won't it make the compiled executable platform specific?

the generated .so file will be platform specific, but it seems like the class files will still be needed as usual

Re: Ahead-of-Time Compilation

#13

Post by copperx » Sat, Oct 01, 2016, 4:36 AM UTC

johnydepp wrote: post #3

That's great! Won't it make the compiled executable platform specific?

I believe that's the whole point.

From what I could gather, this is the process one would follow to get native code:

.java -> javac -> .class (still cross-platform bytecode) -> jaotc -> .so native code

Re: Ahead-of-Time Compilation

#14

Post by h4nkoslo » Sat, Oct 01, 2016, 4:36 AM UTC

avbor wrote: post #4

I'm not familiar enough with compilers, but why would an ahead of time compiler perform worse than a just in time compiler in a static language? I think I'd understand if it was a dynamic language, because you can't know the types for sure until you start running the program, but are similar issues present for Java?

Most of the JIT optimizations amount to "it's been called like this in the past; assume it'll always be & depotimize (at a penalty) if it isn't."

That potentially includes the fully resolved types of objects (ie devirtualization), branch prediction (stronger than the CPU can do; for instance, if a value is only used inside a branch that's never taken, don't bother mutating it), data sizes (this "array" is only ever size 2, store it in registers), dead code elimination (keeps the compiled code small), and a whole bunch more fun stuff.

Re: Ahead-of-Time Compilation

#15

Post by Sanddancer » Sat, Oct 01, 2016, 4:38 AM UTC

johnydepp wrote: post #3

That's great! Won't it make the compiled executable platform specific?

There are other JVMs that already do AOT compilation. This just brings an AOT compilation option to Java. It also looks like the contained file will include both the compiled version and the normal bytecode, so that the code can be recompiled if/when necessary.

Re: Ahead-of-Time Compilation

#16

Post by paukiatwee » Sat, Oct 01, 2016, 4:45 AM UTC

Cyph0n wrote: post #9

Assuming this comes in Java 9, and compilation of code other `java.base` is possible, will this make Java a more solid competitor to Go? I guess it partly depends on how much they optimize the compiled binary size. Go does a really good job at static compilation, so it will be tough to compete.

Java AOT is compile JVM bytecode to native code during startup of JVM, which is different from Go's compile source to native and distribute platform specific binaries. So in this case, Java binary size remain same as before, which is .jar or .war binaries.

For Go, .go -> native

For Java, .java -> .class -> package .jar -> AOT native

For Go part I might be wrong, not working on Go professionally.

Re: Ahead-of-Time Compilation

#17

Post by saynsedit » Sat, Oct 01, 2016, 4:48 AM UTC

not sure why this isn't a transparent feature implemented via caching.

Re: Ahead-of-Time Compilation

#18

Post by KMag » Sat, Oct 01, 2016, 4:55 AM UTC

This is great news, though it initially only supports Linux x86-64 and is decades late for Java desktop apps (and not having non-blocking I/O until Java 1.4 was shameful for a language explicitly targeted and a pervasively networked ecosystem.)

In their "tiered mode", they put sampling instrumentation into the native code, and if they detect a hotspot, regenerate fully instrumented native code from bytecode using the C1 (fast) JIT, which then allows the C2 JIT to do its full optimizations on the code as if AoT were not involved.

Since the invention of tracing JITs, I've often wondered why languages don't package together a compact serialized SSA form such as LLVM bitcode or SafeTSA along with storing functions as lists of pointers to space-optimized compilations of extended basic blocks (strait-line code), similar to how some Forth compilers generate threaded code. A threaded code dispatcher over these strait-line segments of native code would have minimal overhead, and when a simple SIGPROF lightweight sampler detected a hotspot, a tracing version of the dispatcher could collect a trace, and then generate native code from the visited traces using the stored SSA for the basic blocks.

In this way, they'd have a light-weight tracing JIT for re-optimizing native code.

Re: Ahead-of-Time Compilation

#19

Post by jcdavis » Sat, Oct 01, 2016, 4:57 AM UTC

saynsedit wrote: post #17

not sure why this isn't a transparent feature implemented via caching.

Hotspot's JIT compiled code tends to be pretty specialized based on runtime profiling information, which may not necessarily be similar between different runs even the class itself hasn't changed, or (in an extreme case) even if none of the code has.

Some other JVMs (at least Azul's Zing) try to solve this by cache profiling information to speed up code generation.

Re: Ahead-of-Time Compilation

#20

Post by bad_user » Sat, Oct 01, 2016, 5:03 AM UTC

psuter wrote: post #11

avbor wrote: post #4

I'm not familiar enough with compilers, but why would an ahead of time compiler perform worse than a just in time compiler in a static language? I think I'd understand if it was a dynamic language, because you can't know the types for sure until you start running the program, but are similar issues present for Java?

One thing JIT compilers are good at is specializing methods for common (runtime) types; e.g. you have a method operating on Iterable but it turns out most of the time you get a List as input; you can generate code that bypasses the method lookups for .size etc. The question of whether this pays off is usually only answerable at runtime.

Actually that's not a thing most JIT compilers are good at, as such runtimes are hard to build. For the mainstream ones, you only have Java and the major Javascript runtimes.