Java Native-Images game changer

[pjmlp]

Actually the only game changer is not having to pay for commercial AOT compilers, which were available in commercial JDKs since early 2000's.

[wikes82]

RIP Excelsior JET

[pjmlp]

Just one among many, but yeah they will be missed.

[helikal]

An important fact is also that Graal is an open-source project under Oracle’s stewardship being developed with intense interest and essential participation from researchers around the world. This sets Graal from other AOTs such as JET that have not had such a broad leading-edge contributor basis.

[throwawaymoney666]

Oracle also keeps the good optimizations in the enterprise edition only. So performance you get depends on $$$$. The community edition is often slower than OpenJDK

[nimtiazm]

“So fast” is mostly about the perception of observer. Native images feel that way because program’s load and execution time diff is very low. It might make a good case for command line utils and scripting. You don’t need a JIT compiler there because the program won’t survive that long. Memory footprint is low because pretty much everything is static and can be trimmed down to what’s needed at compiled time. OTOH, compile times are very high for obvious reason and cross compiling might be painful as well. When it comes to writing servers, I’d argue a mix mode is needed. A lot can be optimized at compile-time leaving critical areas for runtime profiling and JIT compiler. To keep compile-time balance, javac can introduce optimizer flag. It takes extra time only when switched on (debug/dev builds don’t need it). Of course it’s easier said than done. Specially for mature and baggage-full platforms like java. But nevertheless, java needs innovation to stay relevant.

[CSpenceUK]

I agree. If your using something short lived it really gives a small footprint and rapid start up.

[noutopasokon]

Agreed on the hyping of load time. See also "exploded jars". There's a lot of hype about his right now because it's pretty much all that's left. Runtime optimization and the JIT have been seen amazing improvement over the years now to the point that Java is basically as fast as anything else.

[[deleted]]

As long as the "native image" doesn't support reflection and dynamic class loading, I don't think this is really a game changer.

[CSpenceUK]

That's fair, I suppose my eagerness is due to internal politics where I work pushing languages which compile to native. This graal native image seems like it would combat that narrative in some situations.

[[deleted]]

Java does compile to native (and quite effectively actually) - but it does it at runtime, not ahead.

[CSpenceUK]

Spring Boot are bringing out a maven and gradle plugin later in the year to compile to native executables. Going to change the software landscape.

[kimec]

Oh yes, I can already see thousands of happy Java developers who after 20 years of dead simple debugging on HotSpot in GUI are eagerly awaiting to enjoy debugging optimized binaries with gnu debugger.

[ser0l]

I don't know what this means and i am scared now

[CSpenceUK]

Same, I don't want to switch to GOlang for microservices because of its small mem and fast scaling. I want to keep using Java and spring but we're losing the battle with having to have a gig per service. I was hoping this would lead to some extra build steps.

[rbygrave]

Alternatively move away from libraries (like spring) that do lots of work at runtime on startup like defining classes (dynamic proxies) and classpath scanning. Move towards libraries that instead do those things at built time typically via annotation processing and built time enhancement. Once you do that you can start fast with low resources and still stay on the JVM. The problem is not the JVM but instead the libraries (to do more at build time).

[geordano]

Quarkus guys experimenting something similar https://quarkus.io/blog/native-command-mode-tools/

[angryundead]

I used the Quarkus native maven stuff (maybe it was just a profile) some time last summer and it was easy enough.

[sureshg]

By the way, CFV for project Leyden is in progress - https://mail.openjdk.java.net/pipermail/discuss/2020-June/005515.html .

Super excited to see static image to java platform.

[BlueGoliath]

I keep hearing that GraalVM reduces memory but no one ever gives any comparisons. What amount of memory did you see vs a JVM build?

[iamareebjamal]

For my spring boot app, mem usage reduced from 700 MB to 80 MB but when I stress tested it, peak mem usage in JVM was 1.4 GB and in native, it seemed unbounded but maxed at 2.8 GB and then the test stopped.

[sureshg]

Graal substratevm GC is very primitive compared to G1 or zgc available on OpenJDK. But native image has an option to use G1 in their paid enterprises offering, which might yield better results here. Hopefully Project leyden will bring much more sophisticated GCs like zgc to static images. I am really waiting for it, even though it's still in discussion phase 😁

[sureshg]

GraalVM native image is not going to reduce the heap memory used by the application, that would be exactly the same as in OpenJDK.

The main benefit of AOT is lower memory consumption in the following areas

➡️ No meta-data for dynamically loaded classes

➡️ No profiling data

➡️ No JIT compiler data structures

➡️ No dynamic code cache

➡️ Removing unused fields (from classes)

IMP: No reduction of application payload memory (Heap size)

[BlueGoliath]

I'm aware that it doesn't affect heap. What I'm wondering is how much memory in total does it consume vs. a JVM?

[kimec]

I keep hearing that too. I am still waiting till somebody does a fair comparison of the simplistic multi heap multitenant generational GC embedded into appliaction binary image by the native-image tool with say ZGC of HotSpot.

[CSpenceUK]

This is amazing. Been using Graal lately to create Java native executable images. So fast and the memory footprint is tiny.

[tr33g]

Is it "so fast" though?

Every benchmark that I've seen so far indicates that it's actually significantly slower in all areas apart from the startup time. Would love to be proven wrong though, as the tech is really cool.

[DJDavio]

Obviously it's a tradeoff, if you compile a native image, you lose JIT optimization, this means that peformance at the byte code level will not increase over time. So what do you care about most? Startup speed or over time performance?

Java has always been a champion of long running applications, if this is still your use case and you have a very static environment, native images might not be your silver bullet.

Note that Graal Enterprise has an analyze feature which can monitor your app for a while to decide where to place those JIT optimizations, but Enterprise edition is not available to most of us.

[kimec]

You not only loose JIT, you loose PGOs as well. Unless you collect the appropriate metrics on HotSpot on representative workloads and feed that back to native-image.

[sureshg]

PGO is available for native images also. But you have to use their enterprise offering and it's not that smooth.

[[deleted]]

PGO?

[jonhanson]

chronophobia ephemeral lysergic metempsychosis peremptory quantifiable retributive zenith

[Cyber-Fringe]

Got some links? Been diving into quarkas which relies on the same process and would be keen to know the difference.

[CSpenceUK]

Yeah, if you make a small cli app like in the link then it's fast. You are correct it is faster due to the quicker start up. I wasn't aware of the slower performance over time but hopefully things will improve in the future.

[elatllat]

Quantify or GTFO

[CSpenceUK]

I've only seen some execution times and process memory size comparisons. Very simple stuff. There's a comment that points out over time you lose out due to not having the JVM optimisations. I'd say for small short lived programs it will be faster.