Instant Netty Startup using GraalVM Native Image Generation
1–10 of 12 posts
Re: Instant Netty Startup using GraalVM Native Image Generation
#2Maybe it's easier to just disable unsafe usage in netty. It can run without it. All the magic hoops you have to jump through to 'unlock' Unsafe are silly - libraries just do the incantations and the JVM developers still end up with loads of libraries using internal APIs.
They should have just standardised raw pointers in the Java language and libraries. Then Netty and SubstrateVM wouldn't require these hacks. Of course it's typical for all modern languages, Java is hardly alone in struggling to integrate well with C in high performance ways.
Re: Instant Netty Startup using GraalVM Native Image Generation
#3Wondering, what is the price of using GraalVM Enterprise Edition?
Re: Instant Netty Startup using GraalVM Native Image Generation
#4(Slightly off-topic) My understanding was that HotSpot and other JITs are able to to profile-guided optimizations and the like (such as a polymorphic inline cache) to produce the best possible assembly. How does the assembly produced by these AOT compilers compare? Fast startup time and reduced memory footprint is great, but how will performance compare on compute-intensive workloads?
Re: Instant Netty Startup using GraalVM Native Image Generation
#5[deleted]
Re: Instant Netty Startup using GraalVM Native Image Generation
#6(Slightly off-topic) My understanding was that HotSpot and other JITs are able to to profile-guided optimizations and the like (such as a polymorphic inline cache) to produce the best possible assembly. How does the assembly produced by these AOT compilers compare? Fast startup time and reduced memory footprint is great, but how will performance compare on compute-intensive workloads?
you can use profile guided optimisations when building a native image with GraalVM. You'll need to run your code in a special way under the desired load to gather the profile information, then it can be used when building the native image. YMMV, but the results can be quite interesting, here for example someone compiled http4s: https://twitter.com/lukasz_bialy/status/989091065033625606
Re: Instant Netty Startup using GraalVM Native Image Generation
#7That's a good read for library developers. Ideally libraries should be a little bit adapted for Graal. I think it's an important project and compatibility is good, most developers won't be able to overcome those problems and just won't use Graal at all if popular libraries are incompatible out of the box.
Re: Instant Netty Startup using GraalVM Native Image Generation
#8Wondering, what is the price of using GraalVM Enterprise Edition?
It's oracle, so that depends: how much money do you have?
Re: Instant Netty Startup using GraalVM Native Image Generation
#9Wondering, what is the price of using GraalVM Enterprise Edition?
Cheaper than the other commercial AOT compilers that exist since the early days of Java.
Re: Instant Netty Startup using GraalVM Native Image Generation
#10(Slightly off-topic) My understanding was that HotSpot and other JITs are able to to profile-guided optimizations and the like (such as a polymorphic inline cache) to produce the best possible assembly. How does the assembly produced by these AOT compilers compare? Fast startup time and reduced memory footprint is great, but how will performance compare on compute-intensive workloads?
You can use Graal for both JIT and AOT workloads. The JIT version works just like hotspot, but it's better with memory allocation and collection due to better optimizations. I have yet to see an application where it has performed worse than hotspot, although they may exist.
Ive read that the EE version can do PGO (you profile the app in a profiling mode, outputting a profile file which is used in a subsequent AOT compile), but I personally have no desire to talk to an oracle salesman ever again, so I'll just stick to JIT.