GraalVM Native Image - Faster, Smarter, Leaner
Вставка
- Опубліковано 12 чер 2024
- With support from all the leading microservice frameworks, compatible SDKs from all of the top cloud platforms, and ease of containerization, GraalVM Native Image is a great choice for cloud native application development. Join this session for an update on the latest GraalVM Native Image developments including JDK 20 support, Spring Boot 3 and Micronaut 4 integration, improved monitoring and debugging (perf, JFR, vmstat, and native debug), record breaking peak throughput, and more.
An Oracle DevLive Level Up - Java Developer Day session.
Presented by Shaun Smith - Senior Director, Product Management
More info ➱ www.graalvm.org/
More Level Up videos ➱ • Oracle DevLive Level U...
Tags: #Java #GraalVM - Наука та технологія
![COMPUTER SCIENCE - Roshan Thomas [Official Music Video] (Prod. by Harsh Muneshwar)](http://i.ytimg.com/vi/esmm4WHgS3U/mqdefault.jpg)
Props to the presenter, that was a great talk
Holy shit, as straight to the point as it gets. I guess there is no way around it. At some point you have to get into compiler programming to get better at programming.
12:05 that performance differential is unreal...
Very informative. Thanks a lot!
Great talk Shaun! :)
Good stuff!
Thanks for being transparent about the throughput. So the main benefits are image size, startup time, memory and CPU footprint. These are all not important to us as we don't deploy to the cloud. The CPU is bored anyway and memory is cheap.
Still, fascinating stuff.
The faster startup time of native images is also very noticeable for CLI apps, Desktop GUIs, and applications running on small targets like a Raspberry PI. I don't work with web services at all, but I still use native images whenever possible.
it matters a lot for lambda or cloudrun, even for kubernetes no need to pay for extra memory
Awesome talk - wasn't aware what nativeimage was doing when building those executables OR the benefit of building the native package. Awesome benefits. Does it impact instrumentation though since JFR and other VM capabilities aren't there?
@@Mig440 You rock, appreciate the link!
You can add JFR instrumentation to the generated executable for runtime monitoring of your app. This isn't the same as the performance guided optimization instrumentation I had done and is independent. Once I had the PGO data from the instrumented version, I recompiled to get a more optimized version. I could have enabled JFR in the final version that I would deploy. FYI, as I think I mentioned in the session, not all JFR events are supported yet but coverage is expanding release-to-release.
@@rkallalink’s gone now. 😢
Great présentation. Is it available at a repository...
The "Game of Life" test on my mac is completely opposite ！！！
That's too sad that PGO (Profile-Guided Optimizations) IS NOT part of Community Edition.
Considering, that GraalVM is slightly worse than Standard Java app with JIT (around 12%).
It seams to me that GraalVM won't be used for Non-lambda Apps, since for most of the cases when CI/CD is used - startup time is not that important than final perfomance.
So I guess, almost nobody will start using GraalVm for production, since It requires lots of changes for existing infrustructure, unless It will be obvious that it is "WIN-WIN" situation,
but, unfortunately, that can be achived only with PGO
as u said, lambda with graalvm is a major boost. in addition when you have an "on-prem" solution with limited cpu/ram graal also is a major boost. for generic "cloud" applications using k8 its probably less a "win" as the compile time and all of the configurations and back and forth getting things to work not worth it
Tried to AOT compiled one of our swing app with GraalVM, it threw bunch of errors. It's not as seamless and easy as the discontinued Excelsior JET
Gluon did some nice work to support JavaFX with native image. They even managed to use it to deploy to iOS and Android. Migrating complex apps is still a bit of a pain, but it's doable.
same experience
Same here - imho not production ready, and often not needed anyway. There is a narrow area of application anyway: serverless, microservices. CI/CD and deployment setup is a pain still. But this like CRaC is very interesting stuff and _can_ be very usable in the future.