4 ms·
How does a VM (JVM, GraalVM) compare to something like LLVM's IR? From your description as a ``universal, _interoperable_ VM`` it seems like they have some simi
by toomanyducks 6y ago
How does a VM (JVM, GraalVM) compare to something like LLVM's IR? From your description as a ``universal, _interoperable_ VM`` it seems like they have some similar goals --- what are the reasons to write a compiler to a VM instead of with LLVM/IR?
- AlphaSite 6y agoI don’t think LLVM IR is really interoperable, is it?
- The_rationalist 6y agoGood question: GraalVM support taking LLVM IR as an input https://github.com/oracle/graal/tree/master/sulong https://github.com/oracle/graal/tree/master/sulong Which means that graalVM can support any llvm language almost out of the box (in theory) Llvm IR however has not been designed with inter language interoperability in mind or at least not enough. E.g rust has no transparant, complete, seamless and efficient interop with swift, go, c++, etc But in theory llvm is just an AOT and both AOT and JIT can enable true interoperability which is why graalvm support both a jit mode and an AOT mode. However JITs enable better performance at least for any high level, GCed language than would an AOT. Moreover, GraalVM through the truffle framework enable unprecedented language designer productivity. Through high level constructs the designers can be much more productive than in standard VM/AOT, which explains how with a few engineers Oracle has managed to reimplement Java, ruby, python, js and R in parallel in only a few years...
- kaba0 6y agoI’m not super knowledgeable on LLVM, but as far as I know while it did have at some point a VM runner, it is rather meant to abstract hardware for native compilation. The Java bytecode is much less specific. Also, LLVM IR is not really backward compatible, while Java bytecode is. (By the way Graal has sulong which actually runs LLVM IR on top of the JVM)