Java 12

GraalVM is... complicated. There are a few parts to it:

1) An advanced JIT compiler, written in Java, and distributed as ordinary maven/jar packages, etc. You can use it yourself if you want. Interestingly, this compiler package ("graal") can be used for the JVM itself, and it will be used to compile the Java code that is run by the JVM. The "JVMCI" feature allows you to plug third party compilers into the JVM and replace HotSpot, and Graal (the library) is such a replacement. You can use this compiler on ordinary OpenJDK 10+ with a special startup invocation.

2) Truffle, which is another library for writing programming language interpreters. It does a lot of magic to make them fast. It uses the graal JIT compiler to do this, so it depends on the previous library.

3) A bunch of programming language implementations under umbrella: Python, JS, etc. These are implemented using Truffle. By using Truffle, these language implementations magically share an object model (so they can interoperate), and they get a JIT compiler, based on Graal, for "free". This means the languages can interoperate and JIT together cleanly (the compiler can inline JavaScript into Ruby!)

4) If you use Graal as the JVMCI compiler (i.e. for your host Java code), and you use Truffle-based languages -- Graal can extend benefit #3 to the host Java code itself. This effectively means the JIT compiler can inline and optimize code across every language boundary.

5) SubstrateVM, which is is a tool to turn Java programs into native exe binaries. The intent is you use SVM on the programming language interpreters, to produce interpreter binaries that look "normal" to the user. These binaries are run on custom, non-JDK/HotSpot runtime. The Java code is not JITed, but interpreted code -- Ruby, Python, JS, etc -- is. (This means you have benefit #3, but not #4). SubstrateVM uses a custom generational garbage collector (written in Java!)

6) The "GraalVM distribution", from graalvm.org. This is a combination of all the above pieces together as a sanctioned package. This package uses JDK8 as the base virtual machine.

7) The GraalVM distribution comes in both a "community" and "commercial" edition, which do have technical/feature differences.

Here's the thing: you can use everything from 1-4 with an "ordinary" OpenJDK today if you know what you're doing, and you don't need a special JDK build. SubstrateVM might also be workable, but I don't know.

Points 6-7 actually mean that there is generally a difference between "GraalVM the platform" and "Graal the compiler". Notably, while OpenJDK no longer has feature gaps vs the commercial OracleJDK, GraalVM does, which I find a very weird choice on Oracle's behalf and unfortunate, but maybe it will change one day.

If you want to use one of the new low-latency garbage collectors (ZGC/Shenandoah) with Graal, I don't think that's possible as of right now: garbage collectors need to interface with the JIT compiler, but ZGC does not support the JVMCI interface (it will explode on startup), and Shenandoah doesn't either, I believe (but maybe this changed). This will almost certainly be fixed in the future, of course.

Java basically copied (and cleaned up a bit) C++ OOP of the time. Don't blame Java for any bad direction, it was following rather than leading.

...what is this nonsense? User has 5GB of RAM left and program reads 3GB. The program finishes with it and loads the next 3GB, but triggers a GC pause. He comes to you and tells you the GC paused for a long time, but instead of coming clean and admitting the pause claim was a lie, you run out of the room crying that the user "didn't run the program with enough headroom"?

Why is it so hard for GC folks to admit pauses aren't unavoidable when even their GC's documentation says as much? Why is it always a user problem if the user lied to and sees reality is different?

> We found out, on the other hand, that people care for mixing that style of programming with OO, imperative, reactive, and other styles.

Which is why you forgot to mention Scala, which shows us how great such a promise land can be when we try to please everyone.

> JS, Java, C#, Rust, etc (even C++) give us.

Out of the languages you mentioned, only certain circles of Javascript (React) and Rust are arguably functional as I mentioned above. Javascript has been a real exception to the rule in how its lack of real class support left a vacuum for some FP. C++, C#, Java, and the majority of Javascript are object oriented and always will be.

> Shenandoah implicitly relies on collecting faster than application allocates

That's what the documentation tells you that you need in order to deploy Shenandoah. If you can't meet that then you don't get the claimed performance characteristics.

If you can meet that requirement then GC pause times are dependent on root set sizes, not heap sizes.