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

31–40 of 76 posts

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

#31

Post by jgon »

tadfisher wrote: post #27
jgon wrote: post #25

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

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 something similar this is very convenient but anything else and jpackage isn’t ideal. Not to mention that I don’t know what the integration is currently with jpackage and the aot cache that Leyden produces but I’m guessing it isn’t super straight forward.

I’m sure that all of this stuff can be strung together after spending a suitable amount of time trolling through the documentation of the individual tools, but it’s far cry from go build and cargo build, and I think it would be great if Java could narrow the gap in this aspect.

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

#34

Post by elric »

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…

The complexity of training depends heavily on your goals. If your goal is to improve startup time, it's actually pretty simple.

If your goal is peak performance across the board and you can't wait for runtime optimizations to kick in, you're going to have a harder time. But in many of the things I've worked on, startup time has been a bigger issue than JIT->peak.

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

#36

Post by pjmlp »

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…

Yes, OpenJ9 and ART do it much more easily, the JIT cache is updatable across executions, so there isn't an explicit training run required.

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

#37

Post by pjmlp »

DonHopkins wrote: post #28
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.

Had it not been for Oracle, Java would have died in version 6.

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

#39

Post by pjmlp »

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…

Depends on how much effort, like on C and C++, you are willing to put into PGO metadata for the compiler and linker.

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

#40

Post by xxs »

ledo9915 wrote: post #11

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

if that's any help: (guessing) you have tons of dependencies in multiple jars, if you bundle them all in a single jar (i'd not even compress it), the startup time would massively decrease. Stuff like dependency injection, makes the issues worse.

Lots of the strautup time is class resolution/loading. With that being said - some time last year I ended up optimizing on the main application servers developers run with startup time being over 90s (and often times close to 3min), down to 11seconds (still tons of access of database configurations, secrets, discoveries, and what not). One of the main optimizations was runtime build up of a single jar with the classes being loaded, and then concurrently verifying the classes/resources have not changed.

Post reply on HN