* 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.
> 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.
"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.
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.
Since we have significantly more RAM to spare than a few years ago and caching, almost by definition, is nothing but trading memory for cpu cycles. You want less memory? No problem, just remove the cache and recompute everything all the time, but don't cry if it takes time.
If 24-48MB is trivial completely depends on what is stored in this space, i.e. is there a more efficient representation for your stated goals? Context is king. Even 5MB could be non-trivial, depending on context.
$ java -version
openjdk version "1.8.0_91"
OpenJDK Runtime Environment (build 1.8.0_91-8u91-b14-0ubuntu4~14.04-b14)
OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode)
$ java -Xmx999k
Error occurred during initialization of VM
Too small initial heap
Rather since we have multi-gig RAM on consumer machines.
On embedded systems it might not be trivial, but on my laptop with its 4gigs of RAM and even more so on my desktop with 16gigs, 50mbs is definitely trivial.
> 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).
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...
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.
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.
You're assuming Java is slow. Evidence suggests otherwise. Eg. LMAX Exchange uses a lock-free ringbuffer they call Disruptor [1] which enables 6M tps on a single thread [2]
I seem to recall a prior discussion where a dev working on HFT stuff said that speed is a huge factor, but so is the ability to rapidly change functionality. They settled on Java because it was fast enough (HFT would have to be IO bound, right?) while still being flexible enough to allow them to adapt to daily changes in requirements.
Besides what the others already replied, the use in the trade industry is one of the reasons of Java having to adopt AOT, value types, JNI replacement and better integration with GPGPUs.
I have done this so can confirm, but every time I did I wished I didn't need to. I had a running nightmare where yesterday's trading data made us trade today.
Might not even be that. At some point you need to cut out the output from going to the real exchange.
If you had an IF somewhere random in your code.. you will then JIT code that is wrongly optimized.
If you try to put some kind of network device to capture the traffic and respond with fake responses to make the code happy.. you are one bitflip away from sending bad stuff to prod.
Except at the exchange, where you can't do this. Or you accidentally bitflip something and take yesterdays data, inject into todays books, and cause millions of dollars in mistakes.
Sorry, if you are reading it as "no big accomplishment", yeah, not right.
My question is really "why will it succeed this time?" Did GCJ and similar technologies not take off because Sun didn't support them? Or because it is a really neat technical challenge that solves a problem people don't actually care about?
So, yes, this is cool. But, I'm currently giving it a likelihood of success really low, since I have priors that failed. What other evidence are people seeing that make this something to be excited about, as opposed to just impressed. (Or, are we just impressed and I can go back to my corner?)
Almost all commercial JDKs support AOT to native code.
Sun was religious against it.
Regarding the GCJ, it failed because it is a hard problem where people didn't work for free and most of them stopped working on it when the OpenJDK was released.
Unfortunately no, I am aware of them, because as language geek I like to research these subjects.
While others read newspapers on the train, I read papers. :)
In any case, these provide AOT.
JamaicaVM, PTC Perc (former Atego and Aonix), IBM J9, Oracle Embedded Java, OS/400 Java (uses the same bytecode deployment as the other OS/400 languages), Excelsior JET, and probably a few others in embedded market that I am not aware of.
Awesome, thanks for responding. I have the same hobby of reading up on this sort of stuff, so I knew of quite a few of those. Just don't know of much for a use case of them.
I think the big distinguishing feature is that this is first-class support built into the platform, so it will likely have many more users than previous efforts. I don't anticipate it being generally useful until at least JDK11, though.
* 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.