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].
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 ?
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.
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).
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.
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.
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!
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/
> 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.