GraalVM for JDK 21(medium.com) |
GraalVM for JDK 21(medium.com) |
Compiling with GraalVM is still a pain and will not work out-of-the-box without modifications for any non-trivial project. This is mostly, I believe, not GraalVM's fault, because it can only do so much within the confines of the existing ecosystem.
If only AoT compilation to native code would have been taken seriously from the start, if only gcj would have gotten more attention, we could have ended up with an ecosystem that is somewhat amenable to what GraalVM tries to do.
As much as I like GraalVM and wish it success, my prediction is that in a few years it will be in the same state gcj has been quite some years now.
Native image is quite different. With this new release the compiled images can not only be faster than JIT compiled Java (wow) but also use way less memory and start instantly. At a stroke this is resolving one of the biggest complaints people have always had against JVM languages.
And as a consequence you're seeing adoption by the wider community. All the modern Java web frameworks support it now, and there's a metadata repository where it's collected for projects that haven't accepted it upstream yet [1].
You make it sound like GraalVM is just for ahead-of-time compiling like gcj, but there's more to it than native image. It's possible GraalVM will be openjdk's jit compiler, for example.
I'll take that bet.
GraalVM has only gotten more and more popular.
There are a lot of situations (large server applications) that don't benefit much from AOT.
But others do. Android is (partially) AOT.
I think in today's ecosystem of microservices and serverless etc, AOT will be taken pretty seriously.
Also Android uses a mix of AOT and JIT since version 5.
How are we people practically putting this polyglot stuff into action?
Distributing a nonmodularized Java Swing app in 2023 is far more difficult than it should be.
It’s great.
ISOLATED and UNTRUSTED require GFTC
CONSTRAINED is also available under open-source licenses.
Only for JavaScript right now. We are working hard on supporting all the other languages!
Developer here. So, if you have more questions, let me know!
I was doing stuff in Clojure. Clojure is a great language but it tends to have very slow startup times, even by JVM standards (it's not weird for a large Clojure program to take 5-6 seconds to start. Even a "hello world" can take upwards of a second or two). Graal mostly Just Worked with the standalone uberjar produced by Leiningen and created an executable that started in about 3 milliseconds. It was amazing.
While the lack of proper reflection support was a little annoying, it actually wasn't as horrible with Clojure as you might think; most problems were fixed with basic type hinting, and all but one Clojure library I used (http-kit) worked flawlessly.
By reordering things to be loaded smartly or lazily, startup speed can be improved a lot.
Another reason for a slow startup is that Clojure must load its own runtime every time. The current compiler is not a tree shaker, nor can it rewrite complex expressions in compile-time, although many clojure.core functions were rewritten over time to accommodate JVM optimizers. However, Graal is here precisely to do at the bytecode level, as long as you take care of all type hint warnings and avoid things Graal can't see during compilation (e.g. deferring evaluation of some expressions for runtime).
Things that broke include: JSON (de)serialization using Jackson, validations using hibernate, validator, AWS SDK, and even simpler libs like picocli...
It could be quite useful for a set of simpler apps though
https://gist.github.com/chrisseaton/535e0e80ea19803d5529c623...
Specifically:
> GraalVM language runtimes (for JavaScript, Python, Ruby, Java on Truffle, WebAssembly, and LLVM) can now be [...] installed as Maven/Gradle dependencies [...] which will work for GraalVM JDK and any other compatible JDK
Polyglot experimentation just got a whole lot easier! Kudos to everyone involved in pushing the JVM ecosystem forwards.
Wouldn’t this provide massive gains for the Rails ecosystem once delivered?
(And with the GraalVM licenses changes to be more favorable/permission, I have to imagine there would be significant adoption)
TruffleRuby runs Rails and is compatible with many gems, including C extensions. TruffleRuby is not 100% compatible with MRI 3.2 yet. Please report any compatibility issues you might find. TruffleRuby passes around 97% of ruby/spec, more than any other alternative Ruby implementation.
My question is, how viable is TruffleRuby vs JRuby?
https://openjdk.org/jeps/8313278
It is "Ahead of Time Compilation for the Java Virtual Machine". The proposal details of using AOT code at startup and then JIT taking over. So you get best of both worlds with fast application launch and then throughput once things are warmed up.
Graal is cool, but it will not be as throughput performant compared to JIT. Only for fast startup, serverless or low memory environments.
Also, there was a proposal (not yet JEP though) on condensers and that model could also make great use of GraalVM.
This means you can take full advantage of ARM cloud services like AWS Graviton (sp?) services for lower cost.
Also, looks like the Java Vector API (JEP338) has been optimized.
So, same code on your Raspberry Pi and AWS Graviton, cool.
It can't do native images from those though.
[0]: https://github.com/remkop/picocli/blob/main/picocli-codegen/...
It's really unfortunate how Java and C# are perceived as slow because of their painful startup time.
If you use a framework like Spring Boot then you don't even need that. Just upgrade to 3+ and Jackson, Hibernate (and maybe these other APIs) should pretty much work out of the box.
> Exception in thread "main" Polyglot sandbox limits can only be used with runtimes that support enterprise extensions. The runtime 'GraalVM CE' does not support sandbox extensions.
That alone I think can muddy the waters and can even hurt adoption. I wish they had clear and meaningful names for the specific distinct pieces of tech (even if there is some shared underpinnings).
Not sure I have questions, just generally interested in making it easier/lighter weight/built-in to constrain ambient authority (for example, to mitigate supply chain risks), thus have it be done more.
The Polyglot sandfox feels very loosely analogous to Deno per process (and thus subprocess) permissions, though it looks like ISOLATED and UNTRUSTED can limit a bunch of things not possible with Deno.
The advantage of the native-image-isolate-based isolation is that it is much more lightweight. For example, calls from and to the host application are much faster. There is no copying or expensive synchronization necessary. The disadvantage is that we need to do our own protections against attacks, as the OS protections between processes don't apply to such isolates. By default, we deploy software/compiler-based protections but are also very close to supporting hardware like Intel MPK.
If you have more questions, you can also drop by on Slack; we are a friendly bunch: https://www.graalvm.org/slack-invitation/
I hope Oracle will let it drip it down to the CE, but it's their project, their monetization strategy.
Otherwise, it trades blows with hotspot.
Does this mean that once Project Valhalla lands, Java via Graal will be a viable competitor to C++ for tasks requiring extremely high performance?
One interesting experiment that'd be worth trying is generating value types that wrap memory segments, as that's the new manual memory allocation API. You can do pretty sophisticated manual allocation with arenas and stuff, but you can't allocate Java objects into those segments. What you can do though, is create a "struct" using VarHandles that you can cast the segment to which then reads/writes through to the segment. This leads to the question of whether you can make a nice wrapper around such value types that yield C++ style manual memory allocation.
- The new value type don't garanty flat memory representation, so might have some corner cases which are not properly optimized
- The monomorphization or java vs C++ is still a big advantage for c++
- The compiler optimization of LLVM/GCC are still quite a bit better (in term of generated code) vs jvm/graal
Valhalla supports flattening, that's the whole point of it. To get that you need to have a type declared as a value type, and then put it into a non-null variable, field or parameter. At least that's how the current prototype works. If you do that then the compiler will fully inline the allocation into arrays, containing objects/structs, or the stack.
Valhalla started with monomorphization prototypes, although that went silent years ago. I don't know if it'll be delivered in the first version. But, it's an intended goal of the project to deliver.
As for the final point, could you evidence that? It's very hard to do direct comparisons here because they're usually compiling very different languages and Graal hasn't been optimized for C++. For example, Graal can compile many languages LLVM just doesn't even try to. Also, you'd really need to compare against the Oracle GraalVM (née GraalVM Enterprise) to see the best of what it can do. I'm curious what comparison you're thinking of when you say that, as Graal is an extremely advanced compiler by any measure.
Java like C and C++, enjoys multiple implementations.
Regarding monomorphization, it is still open how much Valhala will go into that front.
Even if Java will never be as good as C++ in generics, there are several other issues that usually tend to have Java chosen for instead of C++, even if C++ wins in the microbenchmark games.
Likewise most options for running Java on the GPU aren't as feature rich as C++, and that is certainly an area where C++ will be dominating in decades to come.
Source ?