
JEP 295: Ahead-of-Time Compilation - yarapavan
http://openjdk.java.net/jeps/295
======
valarauca1
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.

~~~
brianwawok
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
I'm surprised to hear anyone running Java in the trading industry. Isn't speed
a huge factor in that industry?

~~~
eternalban
> Isn't speed a huge factor in that industry?

Exactly. There are a lot of high performance system written in Java. For long
running systems, the startup cost is irrelevant. And for networked systems
(such as fintech) you are going to be IO bound. The main issue as far as Java
and high performance is the GC related pauses and that is a concern shared
with any GC'd runtime.

~~~
PeCaN
And for Java it's actually much less of an issue thanks to the crazy manhours
put into developing fast GC for Java. I suspect Azul Systems's pauseless GC is
probably quite popular in HFT.

~~~
brianwawok
They are trying to sell it for sure. They attend a lot of events.

I am not aware of any trading company using it. May be some.. but the high
perf people I know go other ways.

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

~~~
duck2

        functional, oop
    

Do these have any intersection except Scala?

~~~
Sharlin
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.

~~~
belovedeagle
If Rust is OO then the term is meaningless. No inheritance; dynamic dispatch
only via explicit indirection (Boxed traits); methods are (therefore) just
syntactic sugar for regular functions.

~~~
qznc
Lisp CLOS does not have inheritance for methods either, but is OO by
definition.

Imho, OO is about polymorphism [0] and Rust provides that.

[0]
[http://beza1e1.tuxen.de/articles/oop.html](http://beza1e1.tuxen.de/articles/oop.html)

~~~
belovedeagle
Rust fails many of the other tests mentioned. As for polymorphism, is Haskell
OO? If so, then I think my claim that the term is meaningless is justified.

~~~
qznc
This is the punch line. Once you have a definition of OO, which fits all
languages usually considered OO, the definition also fits Haskell. :)

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

~~~
mi100hael
> 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_logic
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?

~~~
valarauca1
Green Threading is M:N threading. Go-Routines are M:N threading. Q.E.D. M:N
threading isn't a new idea. Go just offers a backed (or compiled) in run-time
that does M:N threading by default for you.

While nearly every other Green Threaded language offered as an additional
library/option. This hurt adoption. While Go just forces you to use Green
Threading.

    
    
        With an AOT option for Java, this becomes even more of an option.
    

Not in the slightest.

    
    
         why can't Java implement the same idea and
         let all existing libraries benefit from it?
    

A laundry list of reason:

1\. Change what functions do and don't block can cause huge issues with down
stream libraries/people who depend on system libraries behaving the same thing
tomorrow as they did yesterday.

2\. Refactoring all code around system calls so they never block.

3\. Write a multi-core and multi-socket scheduler.

4\. Write a scheduler to balance multi-core and multi-socket thread load.

5\. Determine how you will do polling, and write a polling strategy to figure
out what green threads are/are not blocked, then figure out how to communicate
this information efficiently.

6\. Repeat the above 5 steps for EVERY platform Java runs on.

~~~
paulddraper
Well, it was a runtime option that was requested, and runtime options don't
have to be identical on every platform.

~~~
valarauca1
Actually they do. That is the entire point of Java.

~~~
paulddraper
No, the point was to make compile-once run-anywhere software. It's natural for
tuning runtime parameters to vary.

The hotspot JVM will accept both -d32 (32-bit data model) and -d64 (64-bit
data model) everywhere, but they will only work on certain platforms.

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

~~~
pjmlp
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
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](https://www.excelsiorjet.com/free)

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

~~~
wtetzner
> 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](https://github.com/java-
native-access/jna)

------
samfisher83
C# had this for a while with ngen.

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

~~~
FrancoDiaz
Right, Assembler only needs an assembler

~~~
valarauca1
Still needs a linker

~~~
lomnakkus
Pffft... you're using a libc, or something? Direct Syscalls[1] are where it's
at.

[1]
[https://en.wikibooks.org/wiki/X86_Assembly/Interfacing_with_...](https://en.wikibooks.org/wiki/X86_Assembly/Interfacing_with_Linux)

------
shuntress
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
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
Not necessarily. Java byte code can be run directly on a JPM (Java Physical
Machine).

~~~
jerven
Are there any that support the current class file format? ARM jazelle is no
longer being worked on. So I would be surprised if there is anything that can
do Java SE directly. JavaCard of course being quite different than standard
Java.

~~~
imtringued
Java bytecode is too highlevel for it to be suitable to run directly on
hardware. Each instruction can map to multiple machine instructions. A JIT or
AOT compiler can optimize the code on a lower level. A hardware implementation
cannot do inlining, loop unrolling, hoist array length checks out of a loop,
etc...

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

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

~~~
gleenn
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
>>There aren't any Java 8 features available to Android now

that is incorrect.
[https://developer.android.com/guide/platform/j8-jack.html](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.

~~~
pjmlp
Except it doesn't work and is full of bugs.

[https://www.reddit.com/r/androiddev/comments/59gcr9/who_is_u...](https://www.reddit.com/r/androiddev/comments/59gcr9/who_is_using_jack_how_is_it/)

