Ahead-of-Time Compilation • Hacker News Board

Re: Ahead-of-Time Compilation

#41

Post by the8472 » Sat, Oct 01, 2016, 6:39 AM UTC

haberman wrote: post #10

How does this interact with classloading? My general impression is that the design of classloaders is pretty actively hostile to making JVM startup fast.

AOT only applies to clases that have been AOT-compiled and are not transformed at runtime. Everything else will either still be need JITing or could potentially throw errors if pure AOT is desired.

AOT and JIT are not mutually exclusive. From the proposal itself:

> AOT libraries can be compiled in two modes:

> Non-tiered AOT compiled code behaves similarly to statically compiled C++ code in that no profiling information is collected and no JIT recompilations will happen.

> Tiered AOT compiled code does collect profiling information. The profiling done is the same as the simple profiling done by C1 methods compiled at Tier 2. If AOT methods hit the AOT invocation thresholds these methods are being recompiled by C1 at Tier 3 first in order to gather full profiling information. This is required for C2 JIT recompilations to be able to produce optimal code and reach peak application performance.

Re: Ahead-of-Time Compilation

#42

Post by alblue » Sat, Oct 01, 2016, 7:01 AM UTC

CalChris wrote: post #28

Scarbutt wrote: post #6

Earlier quoted context omitted.

A JIT can use information from runtime for optimizations, you pay a cost in startup time. Being worse or better depends on the workloads and implementations.

AOT can as well. PGO.

There are a set of optimisations that you can only do at runtime that you can't do with AOT. Anything that depends on data is something that you can't reliably do, such as eliding null checks if you can prove this cannot happen based on the data passed in. There are also cases where you can have multiple subclasses of a type such as a normal and a debug subclass, or multiple drivers for different back ends such as MongoDB or Cassandra, only one of which is used at runtime but you cannot know ahead of time which is selected (for example, it's based on an environment variable or system property).

The point is that while AOT can do a set of optimisations, including whole module analysis, there are a set which are only available at runtime.

Re: Ahead-of-Time Compilation

#43

Post by singularity2001 » Sat, Oct 01, 2016, 7:03 AM UTC

resurrect me when it's there https://github.com/search?p=3&q=jaotc&type=Code

Re: Ahead-of-Time Compilation

#44

Post by alblue » Sat, Oct 01, 2016, 7:03 AM UTC

jcdavis wrote: post #19

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.

I believe the ReadyNow technology used by Zing records what methods are compiled at which level, then trigger a compilation of those methods at start up. So you effectively use profiling information from the previous run to inform the next run of what the final target state is, allowing the warm up times to be dramatically reduced.

Re: Ahead-of-Time Compilation

#45

Post by alblue » Sat, Oct 01, 2016, 7:06 AM UTC

Slightly off topic but if you are interested in how HotSpot compiles to native code I gave a presentation at JavaOne:

http://alblue.bandlem.com/2016/09/javaone-hotspot.html

The presentation wasn't recorded but there is a video recorded from a DocklandsLJC event which is on InfoQ:

https://www.infoq.com/presentations/hotspot-memory-data-stru...

Re: Ahead-of-Time Compilation

#46

Post by alblue » Sat, Oct 01, 2016, 7:11 AM UTC

KMag wrote: post #18

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…

LLVM bitcode is still architecture specific - for example, whether the code is 64 bit or 32 bit will result in different bitcode paths.

You may be interested to look further into Eclipse OMR, which is a generic VM used by IBM for many of their runtimes (including J9). The Testarossa JIT support landed last week, and although it doesn't support bitcode form directly there are optimisations that can be used to transform the static parts of the class from the dynamic parts, to facilitate loading. There is an IL for the JIT and interpreter use.

https://developer.ibm.com/open/omr/

Re: Ahead-of-Time Compilation

#47

Post by CJefferson » Sat, Oct 01, 2016, 7:20 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.

In benchmarks I've seen, Java already smokes Go on any benchmark except the second or so it takes the JVM to start up.

I'm not aiming this just at you, but I think many people (node.js users in particular come to mind) don't realise just how good the JVM is, performance-wise. I'm not a great fan of Java the language, but the JVM is top class.

Re: Ahead-of-Time Compilation

#48

Post by [deleted] » Sat, Oct 01, 2016, 7:21 AM UTC

pjmlp wrote: post #34

KMag wrote: post #18

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…

> decades late for Java desktop apps Commercial JDKs always offered AOT compilation, the problem is that people nowadays apparently don't buy compilers anymore unless forced to do so (e.g. embedded, consoles...).

[deleted]

Re: Ahead-of-Time Compilation

#49

Post by bitmapbrother » Sat, Oct 01, 2016, 7:22 AM UTC

paukiatwee wrote: post #16

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.

No it's not. Compilers such as the one in IBM's J9 have a switch setting to use AOT.

Re: Ahead-of-Time Compilation

#50

Post by vidarh » Sat, Oct 01, 2016, 7:25 AM UTC

KMag wrote: post #18

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…

You might be interested in looking at Semantic Dictionary Encoding [1]. It was professor Michael Franz' PhD thesis work. Franz' was Andreas Gals advisor on his thesis on trace trees.

SDE didn't propose starting with SSA, but could easily work with an SSA representation. SDE basically functions as a compression mechanism for an semantic IR that builds a dictionary on compression/decompression reminiscent of LZW. So instead of storing straight byte code, you store a compact higher level representation, that could very well be SSA, that is structure for you to generate code while "decompressing" it, and reuse generated code fragments as "templates" for later fragments.

An implementation was built in Oberon, compact tree representation (you could do a DAG with some adjustments) that mirrors your code generation orderand e.g. used to support PPC and M68k from the same "binares" in MacOberon. The way it was structured makes retaining arbitrary higher level structure of the programs very straight forward.

I keep wanting to do something with SDE, but life keeps intervening... I see it as a huge shame that more work didn't go into exploring that alternative to straight up bytecode, but it basically had way too little head start on Java, and I believe Franz' moved to Java for his subsequent research on code generation.

[1] https://en.wikipedia.org/wiki/Semantic_dictionary_encoding