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.
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.
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?
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.
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
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 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.
This is going to be a game changer !
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.
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
12:05 that performance differential is unreal...
Very informative. Thanks a lot!
Great talk Shaun! :)
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. 😢
Where's the WASM target?
Good stuff!
Great présentation. Is it available at a repository...
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
The "Game of Life" test on my mac is completely opposite ！！！
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.