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.
This definitely makes a difference in serverless environments because I remember writing code to preemptively hit AWS lambda functions to keep them hot because it took 5 seconds to boot some of them. Outside of smaller binaries and faster startup times, I don't think I'd go out of my way to use this for long running Java apps.
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.
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.
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
![Blox Fruits Dragon Rework Update [Full Stream]](http://i.ytimg.com/vi/EqDAp8udhm0/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.
This is going to be a game changer !
12:05 that performance differential is unreal...
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
This definitely makes a difference in serverless environments because I remember writing code to preemptively hit AWS lambda functions to keep them hot because it took 5 seconds to boot some of them. Outside of smaller binaries and faster startup times, I don't think I'd go out of my way to use this for long running Java apps.
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. 😢
Very informative. Thanks a lot!
Where's the WASM target?
Great présentation. Is it available at a repository...
Good stuff!
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.
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