Does it target pure JVM bytecode and runtime? This talks about GraalVM and how it's "optimized for many different languages", and they make the same claim on their page, specifically citing LLVM.
GraalVM is based on Graal, Java's future C2 JIT compiler implemented in Java, and already part of OpenJDK 11.
Sulong makes use of Graal and Truffle to create a LLVM AST interpreter (with native code JIT via Graal, thus allowing seamless integration between C and Java code on the same JVM.
When you say "reuses the JIT", does it reuse the JIT API that gets JVM bytecode as input, and native code as output? Or is it a lower layer, that JVM bytecode is implemented on top of, and that is not constrained by the Java object and memory model? Like, if it can do unbounded pointer arithmetic without emulating it with arrays (which is slow and inefficient), surely the JIT needs to have the corresponding low-level opcodes for that, like e.g. CLR does?
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.
Regardless 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?
