GraalVM Blog

I am just following its development, here is an article about it, https://medium.com/graalvm/improving-performance-of-graalvm-native-ima…

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-161527df3d76… 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.

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-su… - 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?)

> 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-ima…

> 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-… [2] https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md

The goal posts started at "the multicore + GPU party." For example: "Optimizing Machine Learning Performance at Netsuite with GraalVM and NVIDIA GPUs" https://medium.com/graalvm/optimizing-machine-learning-performance-at-…

The truffle compiler extensions in Graal will be part of Galahad. For example the partial evaluator. The truffle framework and all the languages are consumed from a maven repo as a regular java library these days. Some background on the recent changes there: https://medium.com/graalvm/truffle-unchained-13887b77b62c

Don't forget TruffleRuby's other tricks: parallel code [0] and polyglot language interplay [1] [2]. [0] https://www.graalvm.org/latest/reference-manual/ruby/#aim [1] https://www.graalvm.org/latest/reference-manual/ruby/Polyglot/ [2] https://medium.com/graalvm/graalvm-ten-things-12d9111f307d

Client apps are most of the time not long running processes where JIT could reach steady state performance and startup time is important. So in practical terms, AOT is faster than JIT majority of time in this use case. Also, look at this benchmark where native image PGO is now outperforming JIT in peak throughput: https://medium.com/graalvm/graalvm-for-jdk-21-is-here-ee01177dd12d

Startup time is very important Some apps get poorly reviewed due to slow startup time Also 3sec on your dev machine = 10sec on regular machines Don't be like Microsoft, don't pretend 9 seconds is fast startup time :) https://www.youtube.com/watch?v=CT7nnXej2K4 "10MinuteMail shared how they used GraalVM and Spring Boot 3 to reduce their startup time from ~30 s down to about 3 ms, and memory usage from 6.6 GB down to 1 GB, with the same throughput and CPU utilization." https://medium.com/graalvm/graalvm-for-jdk-21-is-here-ee01177dd12d

The linked sibling post on "New Truffle and GraalVM Languages release" feels rather exciting too https://medium.com/graalvm/new-truffle-and-graalvm-languages-release-1… Specifically: > GraalVM language runtimes (for JavaScript, Python, Ruby, Java on Truffle, WebAssembly, and LLVM) can now be [...] installed as Maven/Gradle dependencies [...] which will work for GraalVM JDK and any other compatible JDK Polyglot experimentation just got a whole lot easier! Kudos to everyone involved in pushing the JVM ecosystem forwards.

Do you know Truffle for GraalVM? Support various types of languages, even very different from each other. https://medium.com/graalvm/java-on-truffle-going-fully-metacircular-21… https://www.graalvm.org/22.0/graalvm-as-a-platform/language-implementa…

You don't have to chase your dependencies. You just need an adequate suite of tests and then run them with the Graal Tracing Agent enabled [1]. [1] - https://medium.com/graalvm/introducing-the-tracing-agent-simplifying-g…

ZipPy, the initial implementation of Python on Truffle, was an intern project developed by Wei Zhang [1] while doing his PhD at UC Irvine, and continued by other students for a while. It was later re-implemented from scratch by an Oracle Labs team. I think that the main reason for a clean re-implementation was that the Truffle framework had evolved enough where it was easier to start from scratch than to rebase. Also, ZipPy was reusing the Jython parser, whereas GraalPython is using ANTLR [2]. [1] http://thezhangwei.com [2] https://medium.com/graalvm/how-to-contribute-to-graalpython-7fd304fe8b…

Ironically, GraalVM might end up being one of the better WASM VM: https://medium.com/graalvm/announcing-graalwasm-a-webassembly-engine-i…

The announcement blog post: https://medium.com/graalvm/announcing-graalvm-19-4590cf354df8 The HN thread didn't get upvoted much: https://news.ycombinator.com/item?id=19873081

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… Really nice features that will never make it into the GPL version, and it reminds me - there is always a price for Oracle.

Will be interesting once Graal is released. I've found it be at least 30% faster than the existing JDKs around for Scala development. Others have found similar results: https://medium.com/graalvm/compiling-scala-faster-with-graalvm-86c5c08…

Here's a couple of early studies of using it: https://aardvark179.github.io/blog/fibers.html/ https://medium.com/graalvm/bringing-fibers-to-truffleruby-1b5d2e258953

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-… 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.

My understanding is that Graal is doing whole-application compilation, so the dependent jars will be compiled. Reflection is an issue that they have a work around for. There's a good article illustrating various issues [1] in the case of netty written by one of the graal team. (There you'll see an example of a reflection configuration file) [1] https://medium.com/graalvm/instant-netty-startup-using-graalvm-native-…