> Using a memory-safe language for these components and removing JIT compilers could work, but would significantly reduce the engine's performance (ranging, depending on the type of workload, from 1.5–10× or more for computationally intensive tasks)
I don't get it, why the dichotomy between "no JIT" and "sandboxed JIT"? Isn't the not also the option of producing JITted code with safety guarantees, similarly to how the Rust compiler generates code with safety guarantees?
Wish they'd go into more detail about these Futamura projections and how the partial evaluation is implemented. I get it at a conceptual level but I'm still not confident enough to implement one myself.
I don't think this is actually memory-safe. It sounds like the JavaScript-specific parts of the VM are untrusted, i.e. bugs in it won't violate memory safety. But the core GraalVM compiler and its optimizations would still have to be trusted (or if not, the post doesn't explain why not).
I think the _copy-and-patch_ approach [0] is probably the best compromise here.
You get many of the guarantees of compiled code (strong correctness, reduced mismatch between interpreter vs JIT semantics, etc.), while still being very close to native performance.
In fact, Python is already moving in that direction: the new bytecode-based copy-and-patch JIT in Python 3.13 shows correct results even before heavy performance tuning.
So to me this seems like a very promising road: I wonder how practical this is if the base language is not C/C++ but Rust (or any kind of memory safe language).
> Although being written in Java does improve memory safety, we just saw that rewriting V8 in a safe language wouldn’t help with the types of bugs V8 is trying to solve and so we would intuitively expect that GraalJS must suffer from the same classes of bugs. Yet, it doesn’t.
Essentially it exchanges the bugs of a V8 engine for the bugs of the GraalVM, right?
I love the work being done by GraalVM team, and the ones that predated it like MaximeVM and JikesRVM, proving that it is possible to use safer languages for all layers of compiler development, instead of the usual cargo cult of what is supposed to work.
9 comments
[ 4.2 ms ] story [ 29.5 ms ] thread> Using a memory-safe language for these components and removing JIT compilers could work, but would significantly reduce the engine's performance (ranging, depending on the type of workload, from 1.5–10× or more for computationally intensive tasks)
I don't get it, why the dichotomy between "no JIT" and "sandboxed JIT"? Isn't the not also the option of producing JITted code with safety guarantees, similarly to how the Rust compiler generates code with safety guarantees?
You get many of the guarantees of compiled code (strong correctness, reduced mismatch between interpreter vs JIT semantics, etc.), while still being very close to native performance.
In fact, Python is already moving in that direction: the new bytecode-based copy-and-patch JIT in Python 3.13 shows correct results even before heavy performance tuning.
So to me this seems like a very promising road: I wonder how practical this is if the base language is not C/C++ but Rust (or any kind of memory safe language).
[0] https://arxiv.org/abs/2011.13127
Essentially it exchanges the bugs of a V8 engine for the bugs of the GraalVM, right?