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

JEP 544: Ahead-of-Time Code Compilation

openjdk.org

Post reply on HN
Print view View original

21–30 of 76 posts

Re: JEP 544: Ahead-of-Time Code Compilation

#21

Post by jasomill »

layer8 wrote: post #13
java-man wrote: post #2

I hope at some point we'll get AOT-only mode (or compile to native) and maybe even cross-compilation.

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…

It works pretty well for greenfield projects on .NET, so long as you can live without third-party libraries that don't support AOT.

Existing code bases can be a pain, though, especially applications that heavily rely on things like C++/CLI and COM Interop that basically need to be rewritten from scratch.

Which is not to say that it's intended to replace the traditional JIT runtime in applications where it isn't troublesome, because it's not.

Re: JEP 544: Ahead-of-Time Code Compilation

#22

Post by cogman10 »

Leyden has been relying pretty heavily on training runs which I get, but man is that a pretty hard burden to setup.

The tooling for doing these sorts of training runs doesn't really exist, you end up needing to do something more bespoke as part of your build pipeline if you want it there. That can be especially tricky with more complicated applications like the ones I maintain.

I like what these can deliver, but dislike the effort needed to get it going.

Re: JEP 544: Ahead-of-Time Code Compilation

#23

Post by layer8 »

jasomill wrote: post #21
layer8 wrote: post #13

Earlier 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…

It works pretty well for greenfield projects on .NET, so long as you can live without third-party libraries that don't support AOT. Existing code bases can be a pain, though, especially applications that heavily rely on things like C++/CLI and COM Interop that basically need to be rewritten from scratch. Which is not to say that it's intended to replace the traditional JIT runtime in applications where it isn't troub…

> so long as you can live without third-party libraries that don't support AOT.

Yes, and that’s a significant limitation in the Java library and framework ecosystem.

Re: JEP 544: Ahead-of-Time Code Compilation

#25

Post by jgon »

cogman10 wrote: post #22

Leyden has been relying pretty heavily on training runs which I get, but man is that a pretty hard burden to setup. The tooling for doing these sorts of training runs doesn't really exist, you end up needing to do something more bespoke as part of your build pipeline if you want it there. That can be especially tricky with more complicated applications like the ones I maintain. I like what these can deliver, but disl…

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 tools to correctly create it, you have the venerable jar file, but all in all the process of actually getting a java project ready to distribute in a way that doesn't presuppose a relevant pre-installed JRE on the user's side, and which takes advantage of the various facilities available to modern Java is still a pretty bespoke and painful process.

Compared to Go and Rust, and just throwing a static binary to someone or some server, Java kind of sucks. And that's unfortunate because the language, the runtime, and even the dependency situation all feels pretty competent, there's not some huge gulf that makes Java "old". Its really just the every about setting up a project and then distributing it, so the "start" and "end" of a project, that currently sucks, and I fear that so much of the great work the Java team is doing is going to go largely unused if they don't work to make it easier for the average developer to utilize it.

Re: JEP 544: Ahead-of-Time Code Compilation

#26

Post by bebop »

Twirrim wrote: post #19
nirvdrum wrote: post #7

Earlier quoted context omitted.

If you haven't checked it out yet, GraalVM's Native Image [1] already let's do AOT compilation suitable for distribution. You have to do some configuration to deal with reflection and dynamic class loading since there's no JVM in the produced build, but it comes with tooling to simplify that. And that restriction is being addressed by Project Crema [2]. [1] -- https://www.graalvm.org/latest/reference-manual/native-im…

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.

Re: JEP 544: Ahead-of-Time Code Compilation

#27

Post by tadfisher »

jgon wrote: post #25
cogman10 wrote: post #22

Leyden has been relying pretty heavily on training runs which I get, but man is that a pretty hard burden to setup. The tooling for doing these sorts of training runs doesn't really exist, you end up needing to do something more bespoke as part of your build pipeline if you want it there. That can be especially tricky with more complicated applications like the ones I maintain. I like what these can deliver, but disl…

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.

Re: JEP 544: Ahead-of-Time Code Compilation

#28

Post by DonHopkins »

cyberax wrote: post #4

Excelsior 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 only thing that could possibly save Java on the desktop would require Oracle not owning it.

Re: JEP 544: Ahead-of-Time Code Compilation

#29

Post by atgreen »

wahern wrote: post #10
cyberax wrote: post #4

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

Don't forget GCJ. It wasn't removed from GCC until about 2016, a nearly 20-year long run, though interest had waned many years prior. I don't remember if GCJ supported loading and running code dynamically with a built-in JIT or interpreter. I think it was just pure AOT, which caused some compatibility headaches.

I worked on this years ago. Gcj did support loading and interpreting bytecode alongside the AOT-compiled code. libffi's closures were originally implemented to support calling interpreted methods from AOT-compiled code, because a class's vtable could include a mix of AOT-compiled and interpreted methods. You could also compile jar files directly into .so files, which would get loaded and used at runtime if a classloader ever loaded the corresponding jar.

Re: JEP 544: Ahead-of-Time Code Compilation

#30

Post by Rohansi »

layer8 wrote: post #23
jasomill wrote: post #21

Earlier quoted context omitted.

It works pretty well for greenfield projects on .NET, so long as you can live without third-party libraries that don't support AOT. Existing code bases can be a pain, though, especially applications that heavily rely on things like C++/CLI and COM Interop that basically need to be rewritten from scratch. Which is not to say that it's intended to replace the traditional JIT runtime in applications where it isn't troub…

> so long as you can live without third-party libraries that don't support AOT. Yes, and that’s a significant limitation in the Java library and framework ecosystem.

But the possibility of AOT compilation is what drives libraries to support it. That's why .NET libraries are adapting over time to support AOT.
Post reply on HN