Caveat: I also haven't been using Native Images yet, though. So I can't comment on if it'll be dramatically different for that build target.
GraalVM is first and foremost a JIT compiler written in Java that can be plugged into OpenJDK. Due to it being written in a higher level language than the original Hotspot compilers (written in C++) they are easier to write/maintain/experiment with. This mode of operation is used extensively by Twitter for example, because on their workloads it provides better performance than Hotspot, but the two trades blows in general. But this uses the standard javac compiler so it is basically just a slightly different JVM implementation.
Since a JIT compiler outputs machine code it can be “easily” modified to do so in an offline setting as well — this is Graal’s AOT/native compilation mode. This will take a long time compared to some other compilers (I don’t exactly know the reason for that, probably Java’s dynamic nature requiring more wide-reaching analysis?), but will have lower memory usage and faster startup speed compared to the traditional execution mode (but rarely better performance).
There is also Truffle, which turns “naive” language interpreters into efficient JIT compiled runtimes and allowing polyglot execution, which is a whole other dimension.
Thanks a lot @kaba0, big-O would be smart put your comment as part of the GraalVM site FAQ for "What is GraalVM".
Cheers.
EDIT: One request for a small clarification
> But this uses the standard javac compiler so it is basically just a slightly different JVM implementation.
What is "this"? Are you referring to TFA?
That’s not true. For the majority of applications the JIT compiler will be much faster (either Graal’s JIT compiler or Hotspot). Startup time, and memory reduction is true though for AOT.
There are a lot of non-biased benchmarks you can find online, most of them showing that Graal (both CE/EE, though particularly EE) are more performant than OpenJDK.
You then also have the option to compile to native, or to embed/run code in other languages baked in.
It's a no-lose scenario IMO.
Also, not every GC is available, or only in the enterprise version.
There are multiple benchmarks that show marginal gains using GraalVM CE for big data workloads; it might make sense if you're still stuck on Java 8 or 11. The enterprise edition shows more significant gains.
The community version has only serial or nothing, which are ok for small heaps or short lived processes.
GraalVM is regular OpenJDK with the compiler switched out, AFAIK.
Do you have a source for this? Or how do you know?
> Updated the OpenJDK release on which GraalVM Community Edition is built ...
and
> Updated the Oracle JDK release on which GraalVM Enterprise Edition is built ...