JEP 295: Ahead-of-Time Compilation

http://openjdk.java.net/jeps/295

by yarapavan • 10 years ago

220 142 10 years ago

openjdk.java.net

adamnemecek2• 10 years ago

The great language convergence is happening! It seems like everyone is moving to expressive statically typed, compiled, functional, oop languages. Not that I'm complaining.

This means that we might actually get a language that becomes the new c in terms of popularity.

iyn2• 10 years ago

I look at this as cyclic trends (I'm not sure if 'trend' is the right word here, but it's a good enough approximation) - as you've said, we're entering the cycle of 'expressive statically typed, compiled, functional' (not sure about oop), but soon the cycle will go back to the dynamic languages, because they are "faster when iterating on product" etc. But who knows, maybe we'll stay in current cycle forever? ;)

adamnemecek2• 10 years ago

Yeah it's an extinction event in the evolutionary cycle of computing. Im not sure when was the last one.

I think that excessive dynamism is getting less attractive when you account for all the costs it brings with it and that the vast majority of the benefits can be achieved with static metaprogramming, in a more readable and safer manner.

galdosdi• 10 years ago

I don't think so, well, at least not entirely. :-)

Dynamic languages were attractive as an alternative to being forced to specify types all the time, even when it's "obvious." Nobody would have complained if type errors were pointed out for "free."

But type inference is getting popular (eg scala), which is showing people that you can have your cake and eat most of it too.

There's also a lot of little things like REPLs, runtime metaprogramming, blah blah, that used to be solely the domain of dynamic languages, but popular interpreters/VMs have gotten way better in the last decade or two (thanks, JVM) and shown that you actually _can_ have it all. There's no longer a big strong line between interpreted and compiled.

If you can make a statically typed language expressive and fast-to-iterate enough, which I think you can and we (mostly) have, then that kind of yanks the ground right out from under the feet of the dynamic languages, leaving them with no real reason to exist in the long run.

That said, there's something attractive to the unexperienced about being able to code in the laziest possible way, and I don't think platforms that deliver a tiny bit of value in the short run in exchange for massive payback in the long run will ever lose popularity, among new engineers who have not yet learned what it's like to maintain a large program. There will always be PHPs as long as there are students. And that's OK. You learn to do thing well by doing things poorly. But hopefully over time such tools will mainly be used for trivial and learning projects, not big mission critical things

greendragon• 10 years ago

I don't really see the cycle. I just see it as languages getting closer and closer to Lisp, as per usual. Turns out the static languages had a lot more growing up to do than the dynamic languages, so you're seeing 'big' changes like Java 7 through 9, C++0x through C++1y, new languages like Go, Rust, Nim, Scala... Meanwhile the only recent dynamic languages worth talking about are Clojure, and maybe Julia and Elixir. Across the field of dynamic languages though you see a little more movement to optional typing (and more powerful typing semantics like schema or protocol conformance or other things you can do with dependent types) and maybe some concurrency or JIT or AOT trinkets from other implementations that all boil down to performance improvements of some sort. The language design on the dynamic end has changed much less because they have less to change.

rudolf0• 10 years ago

So, everything is slowly converging on Scala? (Though of course none will reach the asymptote that is Scala's feature count.)

paulddraper7• 10 years ago

Or, hopefully, the asymptote that is Scala's compile times.

duck2• 10 years ago

    functional, oop

Do these have any intersection except Scala?

brianwawok11• 10 years ago

Sharlin• 10 years ago

Depends on how exactly how functional you want to go, but latest versions of C++, Java, JavaScript, and C# definitely qualify. Rust, too, though it's not strictly OO. And Python, Ruby, Swift.

agumonkey2• 10 years ago

Does OCaml counts ? the OO layer is actually pretty interesting.

stass• 10 years ago

And don't forget Erlang as well.

jahewson• 10 years ago

OCaml, which is now 20 years old. The "O" was originally for "Objective".

erl• 10 years ago

Important restriction:

for the initial release, the only supported module is java.base

I.e, we will not be able to compile our own code ahead of time just yet.

Alupis• 10 years ago

I.e, we will not be able to compile our own code ahead of time just yet.

That's not really true. From the same doc:

AOT compilation of any other JDK module, or of user code, is experimental.

So it's "experimental", but possible to do.

alistproducer2• 10 years ago

This is very exciting! Question for the experts out there, do you think this has the potential to do away with using the JNI in new projects for the speed boost?

teraflop• 10 years ago

This change has nothing to do with JNI whatsoever.

The JVM has always (well, not always, but for 15+ years) run Java code by first compiling it to native code. The only difference is that the JVM will now allow you to optionally do the compilation ahead of time, in order to decrease an application's startup overhead. This actually hurts performance of the compiled methods, since runtime profiling is not available to the AOT compiler (but the document also describes a "tiered" mode, where AOT-compiled code can be dynamically replaced with a better JIT-compiled version at runtime).

If you want to link your Java code with native code written in a non-Java language, that's a totally different requirement, and JNI will continue to be the way to accomplish it.

pjmlp14• 10 years ago

JNI will continue to be the way to accomplish it.

Not on Java 10 hopefully.

wtetzner2• 10 years ago

and JNI will continue to be the way to accomplish it.

Although if you don't like JNI, you can use JNA [1] (which I believe uses JNI to link to libffi, and libffi for the rest).

[1] https://github.com/java-native-access/jna

the84722• 10 years ago

There already are alternatives for JNI. You can use JNR[0] and JNA[1] which allow you to access native libraries by writing java.

In some future version panama[2] will offer similar functionality to JNR.

[0] https://github.com/jnr/jnr-ffi [1] https://github.com/java-native-access/jna [2]http://openjdk.java.net/projects/panama/

samfisher832• 10 years ago

C# had this for a while with ngen.

buster• 10 years ago

C++ had this for even longer. Assembler doesn't even need a compiler..

FrancoDiaz• 10 years ago

Right, Assembler only needs an assembler

samfisher832• 10 years ago

C# and Java are very similar. That is the only reason I mentioned it.

shuntress• 10 years ago

Isn't java already compiled ahead-of-time?

You give the JVM a .class file, not a .java file.

Though this is a technicality.

Java 9 will be able to compile java source code to java byte code then compile that java byte code to native machine code, correct?

mason55• 10 years ago

It is compiled to intermediate byte code but not machine code. You still need the JVM to JIT the byte code to something the CPU can deal with.

jsprogrammer• 10 years ago

Not necessarily. Java byte code can be run directly on a JPM (Java Physical Machine).

jdc0589• 10 years ago

compile means "native code" here, not jvm bytecode.

brianwawok11• 10 years ago

Look at class file sometime. It is basically bad C code in appearance. It is nowhere close to assembly type code, which is what the final output of the JIT is.

joe-user• 10 years ago

Maybe I'm crazy, but the bytecode dumped from a class file definitely looks more like assembly than "bad C" to me, personally: https://gist.github.com/anonymous/e824444ea158beb7b72b26fbf1...

aaron987• 10 years ago

What, if any, effect might this have on Android, given that its all Java?

loeg• 10 years ago

None — Android doesn't use Hotspot; they've had their own AOT compilation project for their platform (ART) for some time.

gleenn• 10 years ago

Android and Oracle's Java have been diverged for quite a while. There aren't any Java 8 features available to Android now, so you sadly shouldn't hold your breath for any Java 9 features either, it will probably be a long, long time.

ChemicalWarfare• 10 years ago

>There aren't any Java 8 features available to Android now

that is incorrect. https://developer.android.com/guide/platform/j8-jack.html

Just plopped this into my activity to make sure: someList.stream().map(String::toUpperCase).forEach(System.out::println);

As long as minSdkVersion is 24 or higher you should be good.

vanrysss• 10 years ago

Probably none. Android runs on a different implementation of the JVM called Android Runtime (ART), previously Dalvik.

spbaar• 10 years ago

This probably does not affect android. In 5.0, android switched to AOT with a new VM, ART instead of Dalvik, which was a huge win for performance. Jitter in many, many apps went away completely, especially when scrolling. This did cause install times to increase, however. In 7.0 (or 7.1?) there is a mix of JIT with AOT for code that is deemed hot by a profiler, hopefully bringing the benefits of AOT without the lengthy install times.

wvenable• 10 years ago

Android is not JVM so it won't have much affect on it.

valarauca15• 10 years ago

Seeing as nobody is reading the fine text

* Only 64bit Linux on AMD64 is supported, so no ARM or Android support currently.

* Files must be ran on computers they were compiled on, or identical hardware

* Still needs GC, only G1 and Parallel GC are supported

* No dynamic byte code (Lambda Expressions, Dynamic Classes, etc.)

* The only supported module is java.base

* No decrease to JVM start up times

* Still need the JVM

* Some decrease to spin up as there will be less JIT passes that require stopping the world.

Effectively this just lets you pre-load .class files into the codecache directly rather then running the ~10k initial byte-code passes before they'd receive a JIT pass and that would happen.

Lastly .so is just used as a container so I doubt we can expect to dynamically link against AOT compiled Java in C/C++/Rust land.

brianwawok11• 10 years ago

This is clearly still great for a few places. For example in the trading industry, you would have a few seconds of being very slow when starting up for the week - or anytime you crashed and needed to reboot midweek.

Also risk of "hot pathing" the wrong paths if the server comes up during say a market closed time...

OldSchoolJohnny• 10 years ago

I'm surprised to hear anyone running Java in the trading industry. Isn't speed a huge factor in that industry?

WatchDog3• 10 years ago

A lot of firms will run some training data through their application after startup, so that the hot paths get optimised.

plandis• 10 years ago

Those savings might still be beneficial. For instance this might be a decent speed up for GC Functions / AWS Lambda

agentgt• 10 years ago

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

My question is how much memory can be saved by not having the JIT. Sure you still have a GC with a heap (VM) but one of the big pigs in memory can be the JIT.

valarauca15• 10 years ago

This is an interesting question. The JVM CodeCache is normally rather small 24MB-48MB. But the JIT and all of its IR/Branch tracking? I Imagine non-trivial.

taeric5• 10 years ago

This sounds like it is just a modern gcj, then. Am I reading it wrong?

oldmanjay2• 10 years ago

The "just" part doesn't make a lot of sense but otherwise it's a fair characterization

the84722• 10 years ago

No dynamic byte code (Lambda Expressions, Dynamic Classes, etc.)

That just means it won't be AOT compiled. The JVM can still JIT them.

No decrease to JVM start up times

The JVM itself starts quite fast. Most of the time spent in startup comes from the applications themselves. Spend a lot of time in the interpreter running their startup code and burning CPU cycles on the lower compiler tiers.

The only supported module is java.base

Supported in the sense of oracle offering support. You can still compile other modules. It's just experimental.

bluejekyll2• 10 years ago

The JVM itself starts quite fast. Most of the time spent in startup comes from the applications themselves.

Jar unpacking can contribute quite a bit to startup times. It would be neat if this also did a pre-linked library as well.

duaneb2• 10 years ago

Can you statically compile executables? That's a huge win right there.

0xFFC• 10 years ago

Only 64bit Linux on AMD64 is supported, so no ARM or Android support currently.

Do you know what you are talking about ? Android is totally different thing than JVM and Java Ecosystem ! It is totally different technology ! They use one step to turn your bytecode to their own dex file, after that it is completely separated from Java ecosystem (Java as ecosystem which comes from Oracle).

I am fascinated on HN, how comment uneducated like this, haven't got down voted.

They use kind of hybrid AOT/JIT right now. (It was interpreter until 2.2, they switched to JIT, in android 5 they switched to complete AOT, now they are going kinda hybrid approach).

bit_logic4• 10 years ago

For the JVM experts here: how realistic is it for OpenJDK developers to add a command line "-useGreenThreads" option? In Golang, you can create thousands and thousands of threads and there's no issue. If I tried that in the JVM, it would quickly crash. But if there was a "-useGreenThreads" option, I could create Java Executor threadpool of size 50000, use existing http client libraries, and get full concurrency.

brianwawok11• 10 years ago

Why do you need a JVM flag for this? There are libraries that do it.

http://docs.paralleluniverse.co/quasar/

bit_logic4• 10 years ago

Because that's at the library level. It would require rewriting code to use it which loses one of the big advantages of the JVM (a huge existing ecosystem).

If it's at the JVM level (with a command line option to change how threading is done such as -useGreenThreads") then it's transparent to all existing code. I can just use anything (such as existing JDBC library), increase threadpool to levels that would be considered "ridiculous" with current JVM threading system, and it would all work fine. No code changes necessary for existing libraries.

mi100hael• 10 years ago

I could create Java Executor threadpool of size 50000, use existing http client libraries, and get full concurrency.

No, you'd get a slow illusion of full concurrency. The JDK ditched green threads ages ago because native threads were far more robust.

bit_logic4• 10 years ago

I probably shouldn't have used the term "green threads" since that has history in the JVM. I meant whatever Golang is doing which is similar (M:N threading). With an AOT option for Java, this becomes even more of an option. Golang has shown this works, why can't Java implement the same idea and let all existing libraries benefit from it?

duaneb2• 10 years ago

Robust, sure, but they offer an interface far too heavyweight for simple tasks.

pjmlp14• 10 years ago

The first wave of JVMs had it, but they eventually dropped because it wasn't worthwhile for the type of Java workloads.

The language specification doesn't state anything about how threads should be scheduled.

There are actually a few embedded JVMs that might still offer it.

bit_logic4• 10 years ago

Thanks for the replies, I think I understand better now why this isn't as possible as I hoped.

Not sure why I'm getting downvotes for just asking a question, I thought this place was about discussion of ideas.

logn2• 10 years ago

Quasar might be the closest in the meantime. One problem is that blocking IO blocks all the green threads (fibers). It might be possible for Oracle or someone to fix that by wrapping NIO with green threads to implement the IO APIs. Most people will just use async NIO wrapped in fibers so it appears synchronous. Also with Quasar any calls to Thread sleep, wait, or synchronization block all the threads. It would not be an easy feature for Oracle to add but Quasar has been attempting to get merged into the JRE. For Java 9 they said they got some features added that improves the situation but Quasar instrumentation will still be required.

The Quasar instrumentation in my opinion is a pain. Out of the box you either get AoT instrumentation or you use Java agent command line option. Both were problematic for me in context of build processes, IDE support, etc. It's possible to do runtime instrumentation with no special command line option using the Quasar URL classloader and Ant task which scans classes to instrument.

aardvark179• 10 years ago

There are problems with separating JVM and OS threads, mostly in assumptions that native library authors may have made about that mapping being 1:1. That isn't to say the situation can't be improved in specialised environments (see the JVM at Google talk at http://www.oracle.com/technetwork/java/javase/community/jlss...) but fixing it in general is a hard problem. It is being thought about though - see John Rose's talk at this year's JVMLS.

StevePerkins• 10 years ago

This is very exciting, but still a long way from what people probably think it is at first glance.

This isn't "compile your application to an EXE", like Go or Rust. This is "compile some or all of your application to a DLL, and then have the Java runtime use that DLL".

In other words, you still need a JRE available. The use case for this is simply optimizing hotspots in some very specialized situations.

duskwuff• 10 years ago

Not even compile to a DLL, really. The file format happens to be an ELF shared object, but its contents are unusable to anything other than Java, so it's effectively just a blob.

pjmlp14• 10 years ago

Anyone willing to pay for them, can buy a commercial AOT compiler for Java today, there are quite a few available.

This is significant for those that want to AOT Java without paying for it.

dleskov• 10 years ago

Some info for those that want to AOT Java without paying for it:

The entry-level edition of Excelsior JET is free (as in beer) since the end of August 2016. Licenses for the more senior editions have been available for non-commercial use at no cost for many years.

https://www.excelsiorjet.com/free

WatchDog3• 10 years ago

Hotspots aren't really going to be any faster with this change. The jvm already does a pretty good job of optimising hot code, which is why the vm is literally called hotspot.

AOT compilation is mostly intended to address startup time, Java has a big std library and much of it needs to be interpreted and compiled each time it runs. Between jigsaw modules and this, we should see some nice improvements in startup time.

jjnoakes4• 10 years ago

I don't think this is right, is it? I think this change is more about consistent performance than startup performance.

For me the JVM starts really quickly; the only performance issues I've seen there are related to large bloated frameworks doing too much at load time. I don't recall the std library being a factor at all (and why do you think it is recompiled every invocation?)

JEP 295: Ahead-of-Time Compilation

Related Stories