Hacker News Comments on
Project Sulong: an LLVM bitcode interpreter on the Graal VM with Matthias Grimmer @grimmer_m
Java
·
Youtube
·
2
HN points
·
1
HN comments
- This course is unranked · view top recommended courses
Hacker News Stories and Comments
All the comments and stories posted to Hacker News that reference this video.Graal only knows about JVM bytecodes, and there isn't any emulation of pointer arithmetic.You need first to understand the role of Truffle in this.
It is a framework to generate AST interpreters, that plugs into Graal.
So an interpreter for LLVM gets written in Truffle, which while running a specific LLVM application, generates an interpreter for that specific code, so after awhile the JIT comes into the picture optimizing the generated interpreter that is processing that LLVM code.
This goes a few rounds until it becomes almost indistinguishable from generating the code straight from LLVM.
It is the same principle behind using PyPY and RPython to add new languages into PyPy.
JRuby is one of the projects making use of this infrastructure to run C extensions.
Naturally due to the slow startup until everything is finally converted into native code, this approach is only usable for long lived server based applications.
You can get more information about it in some of these links, mostly outdated though.
https://llvm.org/devmtg/2016-01/slides/Sulong.pdf
"Using LLVM and Sulong for Language C Extensions - LLVM Cauldron 2016"
https://www.youtube.com/watch?v=bJzMfYX6n9A
"Project Sulong: an LLVM bitcode interpreter on the Graal VM"
⬐ int_19hRegardless of how it gets there in the end - from an interpreter or otherwise - if it produces pure JVM bytecode, that means that the memory model is also JVM. How does that accommodate the C memory model? Emulating heap with giant arrays?⬐ pjmlpMost likely yes, which doesn't matter, because Graal will eventually optimize bounds check away anyway, as it does for regular Java code.The links that I provided go into detail about all of this.