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.
On Thu, Apr 19, 2018 at 2:55 PM, Timothy Baldridge <tbaldri...@gmail.com> wrote: > 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. > -- - sent from my mobile -- 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.
