Understanding GraalVM and Clojure
1,921 views
Skip to first unread message
Khalid Jebbari
Apr 19, 2018, 6:00:14 AM4/19/18
to Clojure
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.
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.
Timothy Baldridge
Apr 19, 2018, 1:55:25 PM4/19/18
to clo...@googlegroups.com
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
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
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+unsubscribe@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+unsubscribe@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)
(Robert Firth)
Nathan Fisher
Apr 19, 2018, 6:48:44 PM4/19/18
to clo...@googlegroups.com
I was thinking it would be interesting to “remove” the use of Java interop in core instead replacing it with a reserved namespace that maps to whatever the underlying runtime/reader wants to. I suppose you can do the same with the exisiting RT stuff but naively feels like it would be cleaner/provide easier porting if it were one namespace which could have Clojure docs generated for it.
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+u...@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 clo...@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
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+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
- sent from my mobile
Jason Kapp
Apr 19, 2018, 10:34:32 PM4/19/18
to Clojure
Thank you for this detailed explanation.
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+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Khalid Jebbari
Apr 20, 2018, 2:38:11 AM4/20/18
to clo...@googlegroups.com
Yes thanks a lot, it clarifies lots of points not obvious to me by simply skimming the graalvm website.
You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/iBY6hwqqp5c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.
Khalid Jebbari
Apr 20, 2018, 2:43:09 AM4/20/18
to Clojure
Oh a question Timothy. You said you managed to get Clojure running in GraalVM. What was the outcome ? 100% compatibility? Faster/slower ? Memory footprint? Curious about how it worked.
Didier
Apr 20, 2018, 3:17:07 PM4/20/18
to Clojure
https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md has some details of the limitations around native-image.
Native-image is probably the more interesting part for Clojure, but I'm not sure it will fully work given those current limitations.
Native-image is probably the more interesting part for Clojure, but I'm not sure it will fully work given those current limitations.
Jacob Goodson
Apr 22, 2018, 11:48:41 AM4/22/18
to Clojure
What about multimethod style programming, would that not see a large benefit?
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+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Khalid Jebbari
Apr 28, 2018, 9:01:20 AM4/28/18
to clo...@googlegroups.com
Thank you for the link.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+u...@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 a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/iBY6hwqqp5c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.
Nathan Fisher
Apr 28, 2018, 5:14:24 PM4/28/18
to clo...@googlegroups.com
Another interesting post on Clojure and Graal
https://www.innoq.com/en/blog/native-clojure-and-graalvm/
https://www.innoq.com/en/blog/native-clojure-and-graalvm/
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+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Khalid Jebbari
Apr 29, 2018, 6:16:15 AM4/29/18
to clo...@googlegroups.com
I've read it, it's really interesting. Alex Miller mentioned on Twitter that they'll work on removing some limitations over time. @Alex, can you confirm and expand a bit more ?
Nathan Fisher
May 1, 2018, 12:33:23 AM5/1/18
to clo...@googlegroups.com
Is there a runnable language test suite that is used to verify CLJ, CLJS, and CLR compatibility? Thinking something similar to RubySpec that could be used to validate the completeness/gaps in a particular implementation (eg GraalVM).
Khalid Jebbari
May 1, 2018, 3:22:41 AM5/1/18
to clo...@googlegroups.com
The ClojureScript unit tests pass in the JavaScript engine that comes with GraalVM 1.0.0-rc1
https://t.co/WiNHWhv04v (via @Mike Fikes on Twitter)
Daniel Carleton
May 8, 2018, 8:15:29 PM5/8/18
to Clojure
I was interested to see if a native-image binary could be run on AWS Lambda, and a superficial example does at least:
Reply all
Reply to author
Forward
0 new messages