4 ms·

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 al

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.

minxomat 9y ago
Name reminds me of TempleOs's HolyC language...
- mabynogy 9y ago
  Me too. I wonder why they don't mention it.
  - romanows 9y ago
    s/J/Sh/
  - coldtea 9y ago
    Because it is obscure enough (outside HN) that they might even not have heard of it?
    - deleted 9y ago
      [deleted]
    - kannanvijayan 9y ago
      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.
- flamedoge 9y ago
  Inb4 HolyOS, HolyBrowser, HolyKernel
noahl 9y ago
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.
- qznc 9y ago
  ... 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).
  - wyager 9y ago
    I believe you’re correct. Unless there is a compiler bug, the JIT and interpreted code will have the same semantics.
  - Someone 9y ago
    …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.
jchw 9y ago
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.
- alex_duf 9y ago
  Your explanation is much better than what I can read in the blog post.
- chrisweekly 9y ago
  Thank you, jchw! Impressively concise and helpful summary!
- leeoniya 9y ago
  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?
  - Confiks 9y ago
    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.
    - masklinn 9y ago
      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).
  - steveklabnik 9y ago
masklinn 9y ago
> 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_enough_time.html http://tratt.net/laurie/blog/entries/fast_enough_vms_in_fast...

minxomat 9y ago

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

mabynogy 9y ago
Me too. I wonder why they don't mention it.
- romanows 9y ago
  s/J/Sh/
- coldtea 9y ago
  Because it is obscure enough (outside HN) that they might even not have heard of it?
  - deleted 9y ago
    [deleted]
  - kannanvijayan 9y ago
    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.
flamedoge 9y ago
Inb4 HolyOS, HolyBrowser, HolyKernel

noahl 9y ago

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.

qznc 9y ago
... 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).
- wyager 9y ago
  I believe you’re correct. Unless there is a compiler bug, the JIT and interpreted code will have the same semantics.
- Someone 9y ago
  …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.

jchw 9y ago

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.

alex_duf 9y ago
Your explanation is much better than what I can read in the blog post.
chrisweekly 9y ago
Thank you, jchw! Impressively concise and helpful summary!
leeoniya 9y ago
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?
- Confiks 9y ago
  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.
  - masklinn 9y ago
    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).
- steveklabnik 9y ago

masklinn 9y ago

> 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_enough_time.html http://tratt.net/laurie/blog/entries/fast_enough_vms_in_fast...