GraalVM does a lot of things, and I think it's important to separate these terms.
GraalVM - most often this is used to refer to a project that was originally designed to be a implementation of the JVM in Java. So when people ask "does X run on GrallVM" the question is really "does X run in the JVM". Clojure runs on the JVM therefore it runs on GraalVM. I've done this, and it's not that hard to setup. Truffle - is an AST interpreter framework that allows for highly dynamic languages to run efficiently on GraalVM. Truffle is valid Java code, so you can run Truffle on a stock JVM, but it's much faster on GraalVM (or on JVM of version >= 9). Notice my use of "highly dynamic" earlier. Surprisingly, Clojure is mostly static, so there's no clear win here to translating Clojure to Truffle. The exception to this is primitive math, and situations that use lots of HOF where Truffle could perhaps offer more localized optimizations that fit into the Clojure programming model. However, you pay for all this with some rather massive startup time penalties. Most examples I've seen show Truffle adding seconds on to the startup time of a language. SubstrateVM - (aka native-image), SubstrateVM attempts to improve the performance of a Truffle based language by doing image freezing. This method has been used in other languages, and has existed in the PyPy toolchain (RPython) for well over a decade. The idea is that you write an interpreter, then hand SVM a pointer to the start of your interpreter (the main() function). The framework then analyzes the data needed by that function and all the functions it calls. All data required by those functions are also recorded. Then the call graph required to run all these functions is written out (normally to C or C++) and compiled. The side-effect is that all the startup time is removed since the interpreter is "frozen" in a started state. In the terms of Clojure this means that metadata would be serialized as-is, instead of running the code to create that metadata on every startup. Polyglot VM - so in truffle you can have multiple type systems, and multiple languages all running on Truffle. The framework then allows cheap interop between these languages. So when GraalVM docs talk about "zero overhead interop" what they mean is that it's possible to inline a Truffle based function inside any other truffle based function. Since Truffle implementations exist for Ruby, Python, LLVM bytecode (think C/C++), JavaScript, etc. It's easy to see how its possible to have all of these languages efficiently calling each other on the same VM. It's not all awesome though. By using SubstrateVM you give up Java reflection/interop, or have to find a way to embed a full JVM as a Truffle language (this is being worked on), but every language you add into your SVM image comes at a cost of startup times, memory usage etc. So most of the time SVM images stick to a few languages. TruffleRuby for example only uses Ruby and LLVM (for c interop). To finish, I think Clojure on Truffle is possible, but it would take a TON of work. Basically most of clojure.lang.RT would need to be rewritten from scratch, and I'm not sure how much more in clojure.lang.* would also need to be rewritten. So the tradeoff is: A. Current state - Good enough performance - Fast enough startup (Clojure starts quickly, it's the deps/tooling that are slow) - Requires type hinting to avoid reflection B. Clojure on Truffle - More-or-less the same performance - Faster un-type-hinted math - (Possibly) Faster transducers/HOF over primitive collections - No need for type hints - Massive rewrite - Huge startup time penalty - Requires a modern/uncommon JVM (JVM9+ or GraalVM) Comparing these side-by-side, it looks to me to be a wash. And because of that I doubt we'll see a TruffleClojure any time soon. Timothy On Thu, Apr 19, 2018 at 4:00 AM, Khalid Jebbari <khalid.jebb...@gmail.com> wrote: > Hello, > > Oracle has just announced GraalVM 1.0 release candidate: > https://blogs.oracle.com/developers/announcing-graalvm > > It mentions a few JVM-based language but not Clojure (maybe just because > of popularity). > - Does it mean Clojure is not "compatible" with GraalVM ? > - Does it mean Clojure needs to be reimplemented in terms of GraalVM's > Truffle framework ? > - Does it mean Clojure can be run as a native binary with fast startup > time and minimized memory footprint ? > > If someone with some knowledge could explain to me the relationships > between Clojure and GraalVM ? Bonus points if Alex Miller answers and share > the plans, if any, about their integration/interaction. > > Thanks a lot in advance. really curious to understand more. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
