GraalVM Blog

> It seems like a revisiting of the experience of the Self team between the second and third generation of Self VMs, though the underlying hardware might be just a little faster :) Do you think this tradeoff of peak performance vs interactivity is inherent in Truffle's approach? Or can Truffle realistically aim for the best of both worlds?

> One interesting aspect of the Self VM is that it can save the JIT generated native machine code together with the Self code in the image/snapshot, so that you can load a pre-warmed set of objects. Is that possible within the Truffle framework?

I completely agree. Mario Wolczko, who worked on the Self VM at that time, is part of the extended GraalVM team. So the knowledge and experience is there, it only has to be implemented. The GraalVM team is thinking about ways to support snapshotting and a couple of other things. Their profile-guided optimizations [1] is probably the closest to that and definitely a way into the right direction. So I'd say it is possible to make performance of GraalVM languages much more predictable, maybe to the extent that it doesn't matter anymore for interactivity.

[1] https://medium.com/graalvm/improving-performance-of-graalvm-native-images-with-profile-guided-optimizations-9c431a834edb

GraalVM is truly great stuff.

GraalVM native compilation helps Java in the data center to avoid being a cost sink and to reduce start-up latency. Oracle needs Java to sell enterprise software.

Oracle contributing to OpenJDK may be required for Amazon cooperation (since Amazon is pushing its own JDK build) and probably helps the library ecosystem work towards native compatibility.

Native support for reflection (used in many libraries) requires "reachability metadata", maps of reflective API usage, at build time. Anyone can do it, but enterprise requires authoritative sources. Until authoritative reachability metadata covers the transitive graph of library+version dependencies in enterprise software, GraalVM native AOT builds are a PITA.

- https://github.com/oracle/graalvm-reachability-metadata

- latest release: https://medium.com/graalvm/graalvm-22-3-is-here-jdk-19-builds-jlink-support-new-monitoring-features-and-more-f6e2b2eeff95

- graalvm "community" roadmap: https://github.com/orgs/oracle/projects/6

(As a side note: Mark Reinhold has run the JDK team since 1997: is there any comparable example of such stellar leadership for broadly-adopted software across multiple technical and organizational eras?)

Ironically this is solved already by the latest release of Graal, one of WASM's competitors:

https://medium.com/graalvm/whats-new-in-graalvm-languages-161527df3d76With

You can now distribute Python applications or libraries as standalone binaries or JAR files without any external dependencies. The Truffle framework on which GraalPy is built, and the Sulong LLVM runtime that GraalPy leverages for managed execution of Python’s native extensions, enable virtualization of all filesystem access of Python applications, including those to the standard library and installed packages.

So now you can build a standalone executable as follows:

graalpy -m standalone binary - module my_script.py - output my_binary

or a JAR file that runs on GraalVM and includes GraalPy as follows:

graalpy -m standalone java - output-directory MyJavaApplication - module my_script.py

The first form creates a fast starting native binary. The second is a portable bytecode standalone file. So this WASM dream is delivered already, just by a different group of people.

Now, GraalPy is a different implementation to CPython so not all Python apps run on it yet. But obviously any WASMPy would have the same issue.

> What do I need to have a simple "hello world" CLI Java app which starts within 25ms and doesn't eat more than 10MB of RAM? Is GrallVM enough?

Yup. Here is another tutorial [1]. There are limitations, though:

* It's AOT, which means you don't get the JVM peak performance that come from JITting to your wordload profile. (but maybe in the future we can have startup in AOT then transition to JIT?)

* You're getting an embedded generational garbage collector. Not the sweet stuff like G1/ZGC/Shenandoah.

* You can't do dynamic class loading, or you have to declare (and know) beforehand which classes are reachable. A fair amount of frameworks use this and will not work with native-image. I suspect these will provide mechanisms to help in this regard in the future (for JSPs: generating the code of all classes-pages that are reachable at compile-time).

* There are other limitations [2].

All in all, great for CLIs and cloud lambdas.

[1] https://medium.com/graalvm/instant-netty-startup-using-graalvm-native-image-generation-ed6f14ff7692

[2] https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md

Totally agreed that java fails hard for use cases involving small, lightweight binaries that are low memory and fast to start. This is an area where golang shines on the other.

People are starting to experiment with AOT compilation via graal to make headroom in this space, but the techonology being used feels young, nascent, and experimental or immature:

https://medium.com/graalvm/instant-netty-startup-using-graalvm-native-image-generation-ed6f14ff7692

https://www.innoq.com/en/blog/native-clojure-and-graalvm/

Interestingly most high-level runtimes also have slow startup, including python, ruby, and node.js, but java's feels worse because people seem to want to use heavyweight frameworks like spring or aspectj that absolutely murder startup time, that for instance generate bytecode on startup or use classpath scanning to discover dependencies.

I really like the idea of being able to compile java down to native targets.

Having a GPL compiler capable of that seems like a significant step forward - coming from a background of writing the deployment software for a much larger and heavyweight application, it would've been very nice to be able to break the JVM compatibility requirement and go native on arbitrary versions.

Then I see things like this: https://medium.com/graalvm/safe-and-sandboxed-execution-of-native-code-f6096b35c360.

Really nice features that will never make it into the GPL version, and it reminds me - there is always a price for Oracle.