Hacker News Reader

Comment by bananicorn | Hacker News Reader

I'm not sure as to what is fundamentally different about this JIT-compiler (except for the awesome name of course)

Is it basically just a Rust rewrite which also tries to reduce the complexity of their current just-in-time compiler?

Edit: By calling it "just" a Rust rewrite, I'm not implying that's a simple undertaking, even moreso considering the complexity of modern JS engines.

View on HN

Basically, instead of manually writing assembly fragments, they want to reuse annotated interpreter code, thus ensuring both correctness and safety for JIT-generated code, while reducing the redundancy. The rustc compiler is used to generate assembly fragments for the JIT, directly out of the interpreter code. It seems like a worthwhile endeavor.

Your explanation is much better than what I can read in the blog post.

Thank you, jchw! Impressively concise and helpful summary!

doesnt rustc rely on LLVM to generate its assembly. i watch the webrender repo and there have been several issues about poor codegen that LLVM could not properly handle. some were also related to absent optimizations at the MIR level.

also would that mean that the asm snippets could change as llvm changes and possibly cause security bugs if not carefully hand-audited/tweaked anyhow?

The blog post doesn't explain it very well, but I believe the tool code-generates the assembly at runtime, and not at compile time, so LLVM is not involved in code generation for the JIT.

Since it sounds very similar to RPython it probably does both: it generates a regular (native) interpreter, and generates and merges a JIT inside that interpreter (with all that implies of e.g. tracing and runtime code generation).

Rustc does, but it doesn't appear to me that holyjit does, that is https://github.com/nbp/holyjit/blob/master/lib/src/compile.r... and https://github.com/nbp/holyjit/blob/master/lib/src/lib.rs#L1...

Basically, it seems (and I haven't fully digested the code yet) that it uses https://crates.io/crates/dynasmrt for codegen.

Looks like dynasmrt was written for use in holyjit.

Quite possibly! It's the first I'm hearing of it. It's very interesting...

I believe the fundamental difference is that instead of hand-writing snippets of assembly which their JIT can append, they are having the Rust compiler generate the assembly snippets from Rust code. This lets them be much more confident that they wrote the snippets correctly, and lets them spend much less time writing the snippets so they can focus on optimizations.

... and the snippets are used for the interpreter, which gives you more confidence that interpreted and JITed code behave the same (if I understood it correctly).

I believe you’re correct. Unless there is a compiler bug, the JIT and interpreted code will have the same semantics.

…but (barring a sufficiently advanced compiler) that also means the JITted code can’t use data structures that are wildly different from those used in the interpreter. For example, if integers are boxed in the interpreter, the JITted code would use boxed integers, too.

> Is it basically just a Rust rewrite which also tries to reduce the complexity of their current just-in-time compiler?

My understanding is it's rather more similar to RPython: the developer does not write the JIT, the developer writes the interpreter and the meta-jit generates a JIT from that. The developer can further add various annotations to guide JIT generation for improved performances.

See Laurence Tratt's Fast Enough VMs in Fast Enough Time on rewriting their Converge VM in RPython: http://tratt.net/laurie/blog/entries/fast_enough_vms_in_fast...

Name reminds me of TempleOs's HolyC language...

Me too.

I wonder why they don't mention it.

s/J/Sh/

Because it is obscure enough (outside HN) that they might even not have heard of it?

He hadn't. I just explained the Terry/HolyC thing to nbp (the author) this evening over coffee. He had never heard of it before.

Inb4 HolyOS, HolyBrowser, HolyKernel

Reply on news.ycombinator.com