[akerro]

>Performance can vary quite a lot from task to task, also compile times suffer a lot and you lose some dynamic features.

That's actually really bad in Graal. I compiled a few classes project in Java, JS and Ruby. Compilation time was measured in minutes and memory usage most of the time was >8GB.

[aseipp]

To be clear (for anyone reading), it's SubstrateVM's whole-program compiler (and corresponding analysis') that does this, not Graal itself -- Graal can be used as an ordinary JVMCI compiler in an ordinary JDK, like HotSpot C2. Graal is really just a very fancy compiler-backend-as-an-API that can emit native code from a CFG (like LLVM, sort of), just written in Java. SubstrateVM uses Graal to emit binary object code from the JVM class files you specify at compile time, when you use the 'native-image' tool -- but it otherwise has a different compilation pipeline entirely (AFAIU.) So Graal can both be used for a JIT or AOT compiler...

SubstrateVM was designed more to make Graal/Truffle based interpreters like TruffleRuby and FastR have fast startup time with small binaries, which is a large and complex project, more than it was meant to compile small, random one-off Java/JVM applications for CLI usage. From what I remember in my few random experiments the compile time isn't quite linear in size at least (e.g. compiling a 10 line Java class file takes 2 minutes, but compiling a 100 line one takes only marginally longer, comparatively.)

(Using SubstrateVM also means that there is no JIT for the JVM class files you compile to native code, so you're dealing with a purely ahead-of-time compilation scheme. Graal's online JIT still kicks in for SubstrateVM-based interpreters like TruffleRuby, however. This is an important distinction to understand.)

Hopefully they can improve the compile time requirements a bit for cases like this, since it's surely more popular and common case that people are looking for, as opposed to writing Truffle-based interpreters.