Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ahead-of-Time Compilation

bugs.openjdk.java.net

Post reply on HN
Print view View original

21–30 of 95 posts

Re: Ahead-of-Time Compilation

#21

Post by BuckRogers »

Why was Java ever JIT'd rather than natively compiled anyway? I hate to stick my neck out and even ask this but I never understood why you'd want to JIT or interpret when you can just natively compile to a binary. It seems like Go has gone "back" to the future on this one and in general their toolchain approach to me looked like the way.

I always got the sense the world is waiting for a statically typed Python that compiles to native code with Go's CPU performance. I suppose Nim might fit that bill but a shame it doesn't have compatibility with Python's or even the extent of a language like Go's libraries. And if possible, an imperative language that interfaces with OTP.

And that said, I can see why Erlang/Elixir wouldn't make as much sense or even work with native code AOT compilation due to it's feature set (thinking stuff like hot code reloading). But I've never grasped why Java or Python were better off with JIT or interpreters than AOT comp. Seems like a type system such as Go's is simple enough and allows for good gains in both CPU performance and memory usage. Add in the fact you don't need to install anything and less to think about in deploying and it seems to be a no brainer. Please feel free to fill me in on this or where I went wrong..

Re: Ahead-of-Time Compilation

#22

Post by nwmcsween »

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…

This could be taken even further, if the IR can hold about effects and purity, etc you could potentially optimize across libraries and binaries.

Re: Ahead-of-Time Compilation

#23

Post by jcheng »

BuckRogers wrote: post #21

Why was Java ever JIT'd rather than natively compiled anyway? I hate to stick my neck out and even ask this but I never understood why you'd want to JIT or interpret when you can just natively compile to a binary. It seems like Go has gone "back" to the future on this one and in general their toolchain approach to me looked like the way. I always got the sense the world is waiting for a statically typed Python that c…

For several of Java's early use cases, being able to deploy a single file that could be run on any Java-supported platform was very important.

https://en.wikipedia.org/wiki/Write_once,_run_anywhere

Re: Ahead-of-Time Compilation

#24

Post by sandGorgon »

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.

that is an incorrect assumption. AOT step will include deadcode elimination. In that way - the Java way is a more sophisticated way combining platform independent bytecode and platform-specific machine code.

Re: Ahead-of-Time Compilation

#25

Post by Scarbutt »

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.

My understanding is that JVM bytecode is compiled to native before startup of the JVM, that is why it is called AOT ;)

Re: Ahead-of-Time Compilation

#26

Post by dantiberian »

taspeotis wrote: post #2

I can't see anywhere in the linked issue that indicates AOT compilation is coming to Java 9, or even coming at all. The issue demonstrates nothing more than an intent to bring it to OpenJDK, and the issue seems to be very nascent? It was only created a fortnight ago. Lest the title is changed: AOT compilation is coming to Java 9 (java.net) 18 points by hittaruki 37 minutes ago

> The extra step of recompiling code at Tier 3 is necessary since the overhead of full profiling is too high to be used for all methods, especially for a module such as java.base. For user applications it might make sense to allow AOT compilations with Tier 3-equivalent profiling, but this will not be supported for JDK 9.

This implies it will be in Java 9 (in a limited fashion).

Re: Ahead-of-Time Compilation

#27

Post by pvg »

BuckRogers wrote: post #21

Why was Java ever JIT'd rather than natively compiled anyway? I hate to stick my neck out and even ask this but I never understood why you'd want to JIT or interpret when you can just natively compile to a binary. It seems like Go has gone "back" to the future on this one and in general their toolchain approach to me looked like the way. I always got the sense the world is waiting for a statically typed Python that c…

Deployment (and fever dreams of 'mobile code'). It's also worth remembering that Java was designed and implemented at a time when the landscape was significantly less x86-centric and Sun was one of the companies on the not-x86 side.

Re: Ahead-of-Time Compilation

#28

Post by CalChris »

Scarbutt wrote: post #6
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?

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.

Re: Ahead-of-Time Compilation

#29

Post by qznc »

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.

Yes it is. On the other hand, gcj still did it years ago. I guess some features like dynamic class loading are just not supported.

Re: Ahead-of-Time Compilation

#30

Post by qznc »

jcheng wrote: post #23
BuckRogers wrote: post #21

Why was Java ever JIT'd rather than natively compiled anyway? I hate to stick my neck out and even ask this but I never understood why you'd want to JIT or interpret when you can just natively compile to a binary. It seems like Go has gone "back" to the future on this one and in general their toolchain approach to me looked like the way. I always got the sense the world is waiting for a statically typed Python that c…

For several of Java's early use cases, being able to deploy a single file that could be run on any Java-supported platform was very important. https://en.wikipedia.org/wiki/Write_once,_run_anywhere

Also, a small file and stack based bytecode is often the most compact representation.
Post reply on HN