What are the architectural differences between this and Android's ahead-of-time runtime?
This JEP is essentially about caching the JIT's generated code for later runs. The JIT is still free to discard the cache if it deems it worthwhile.
JEP 544: Ahead-of-Time Code Compilation
41–50 of 76 posts
Re: JEP 544: Ahead-of-Time Code Compilation
#42Excelsior JET did that 25 years ago: https://en.wikipedia.org/wiki/Excelsior_JET It's a shame that Sun/Oracle never partnered with them to bring native apps. This could have saved Java on the desktop.
The JRockit JVM had it already 20 years ago, and the company was even bought by Oracle shortly afterwards.
Re: JEP 544: Ahead-of-Time Code Compilation
#43Earlier quoted context omitted.
The slight drawback is that AOT compiled Java code's performance isn't as good as the JIT compiled form running on the JVM. There's a reason why folks keep coming back to JIT compilation. It's hard to beat the value that can be gained from actually gathering data on how the code is actually used, which leads to a whole set of potential optimisations (which is the problem Profile Guided Optimisation attempts to solve…
Full agreement with everything you said. Just one detail to add on serverless (and potentially in a scheduled environment like k8s), startup time can be an order of magnitude or more faster in a native build. For instance, I have some quarkus applications that can take 10 seconds to ready running via the jre that take 10ms or less to start as a graalvm built binary.
I wish JVM could at least recover the memory after some time and drop at runtime what quarkus / AOT drops at build time.
Re: JEP 544: Ahead-of-Time Code Compilation
#44Earlier quoted context omitted.
Are you describing jpackage? I'm not sure how you would make it less bespoke, given you are essentially creating a Java runtime for your program. Maybe the Java folks could tree-shake the runtime for you so you wouldn't have to care about their weird module system, but it's not the worst thing to learn.
jpackage is heavily oriented around installable artifacts, it creates a .deb or .rpm for Linux for example. So if I wanted to throw someone a cli utility I can literally just send them the binary if I’m working in Go, whereas Java they need to use dpkg to install the deb. This somewhat complicates building a docker image as well. It’s the same story for windows and Mac as well. If I’m creating a Swing app or somethin…
One could also just use jlink and extract the zip file that it produces.
Re: JEP 544: Ahead-of-Time Code Compilation
#45Excelsior JET did that 25 years ago: https://en.wikipedia.org/wiki/Excelsior_JET It's a shame that Sun/Oracle never partnered with them to bring native apps. This could have saved Java on the desktop.
IBM's J9 had AOT for a long time too. I wonder how JEP 544 compares.
IMHO the most interesting feature of OpenJ9 is the compile server. One node decides to optimize, sends over the traces, and the compile server sends optimized native code to all nodes. Or a new node joins and could be brought up to speed within a very short time.
Re: JEP 544: Ahead-of-Time Code Compilation
#46I hope at some point we'll get AOT-only mode (or compile to native) and maybe even cross-compilation.
That won't be necessary when 544 lands. The only thing you'd gain is not having to ship the JIT compilers in a jlink build. Also, I'm fairly certain that the JIT compilers can be turned off with some combination of runtime flags to ensure only the AOT generated code is executed.
Re: JEP 544: Ahead-of-Time Code Compilation
#47Earlier quoted context omitted.
That would place significant limitations on the applications that can be compiled. As the JEP explains: “Features such as dynamic class loading, dynamic linkage, dynamic dispatch, and dynamic reflection bring vast expressive power, and have been fundamental to the platform's success. HotSpot handles these features naturally, while static compilers struggle with them. Even heroic amounts of static analysis cannot make…
we are not talking about fully supporting dynamic loading, because it's not needed in all the cases, and in some cases, the list of allowed classes in the application can (or must) be limited. i guess what i am saying is that AOT-only case is not "standard java", but something that will make a (more) useful replacement for things like c/c++.
> i guess what i am saying is that AOT-only case is not "standard java", but something that will make a (more) useful replacement for things like c/c++.
What is the objective here? Startup latency or throughput? Both will be vastly improved by JEP 544.
Re: JEP 544: Ahead-of-Time Code Compilation
#48Earlier quoted context omitted.
Full agreement with everything you said. Just one detail to add on serverless (and potentially in a scheduled environment like k8s), startup time can be an order of magnitude or more faster in a native build. For instance, I have some quarkus applications that can take 10 seconds to ready running via the jre that take 10ms or less to start as a graalvm built binary.
I wish JVM could at least recover the memory after some time and drop at runtime what quarkus / AOT drops at build time.
It can and already does. It mostly depends on the GC. Or do you mean non-heap memory that the runtime uses?
Re: JEP 544: Ahead-of-Time Code Compilation
#49Data point from a small side project: I run user code in a Piston sandbox for a coding challenge site. A trivial Java program costs 2.5-3 s wall clock on a 4 vCPU box, almost all of it javac plus JVM startup. Go takes about 1.7 s for build plus run, and Swift running through the interpreter is at 0.4 s. Java is the reason I had to put a global rate limit on compiled languages at all. If AOT gets the JVM side down to…
How much of these 3s is javac? JEP 544 will only help reduce javac's overhead, not that of the compiled program.
Re: JEP 544: Ahead-of-Time Code Compilation
#50Earlier quoted context omitted.
I completely agree. I know that there has been some work on command line ergonomics for this stuff, but my hope is that after the bulk of the Leyden work is done, another project starts up aimed at unifying all of the various disparate tools that modern Java now has. You have training runs to generate bytecode/compiled code, you have jlink to create a distributable JRE for your app, leaning on jdeps and various other…
Are you describing jpackage? I'm not sure how you would make it less bespoke, given you are essentially creating a Java runtime for your program. Maybe the Java folks could tree-shake the runtime for you so you wouldn't have to care about their weird module system, but it's not the worst thing to learn.
It would be nice if jpackage could bundle the generated AOT configuration data along with a custom action in the MSI package to run the machine-dependent AOT compilation step at install time.