Live data from Hacker News

HolyJit: A New Hope

blog.mozilla.org

71–80 of 219 posts

Re: HolyJit: A New Hope

#71

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.

> 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...

Re: HolyJit: A New Hope

#72

First thought was: "Is this another Terry Davis language/framework?"[1] No, no it is not. I would suggest changing the name from HolyJit to anything else. [1] https://en.m.wikipedia.org/wiki/TempleOS

I don't know, I'm a fan of the name to be honest, I wouldn't change it just because of the possibility of accidental association.

What about just avoiding needless offence to people who happen to regard the 'holy' morpheme as indicative of ... well ... something holy and not to be trifled with.

I don't have religion, but given an essentially infinite number of alternatives to this not-very-funny one, why do this?

People also have a right to be idiots in other ways, such as poking hornets' nests because it's funny.

Re: HolyJit: A New Hope

#73
post #40

Earlier quoted context omitted.

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.

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.

Re: HolyJit: A New Hope

#74
post #70

How is this different from Pypy, other than the fact that ones uses RPython and the other uses Rust?

HolyJIT seems to be similar to RPython rather than Pypy: RPython is both the restricted language and the tooling around it, Pypy is a Python interpreter implemented using RPython.

Re: HolyJit: A New Hope

#75
post #53

"This means more time to implement JavaScript features" - yes, because JavaScript isn't getting enough features fast enough :-p Jokes aside, I love this kind of work from the Mozilla team. This and the bits going into Quantum are really amazing pieces of software engineering in my opinion.

> "This means more time to implement JavaScript features" - yes, because JavaScript isn't getting enough features fast enough :-p

AFAIK Mozilla does not drive the evolution of ECMAScript (not on their own anyway), so it would be a way to provide new features faster, providing better feedback during phase 3 (and possibly even phase 2) and providing time to implement features they could not so far (e.g. ES6 TCO)

Re: HolyJit: A New Hope

#76
post #73

Earlier quoted context omitted.

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).

Re: HolyJit: A New Hope

#77
post #28

Earlier quoted context omitted.

I am absolutely convinced that the god of Terry A. Davis. does not approve of JIT compilation.

I haven't looked closely at the architecture, but isn't JIT compilation pretty much how Holy C works?

I was making an uninformed joke. You are right, it's right there in the wikipedia article: "Code can be compiled JIT.".

Let me repeat: God approves of JIT compilation.

Re: HolyJit: A New Hope

#78
post #54
post #39

For what it's worth, the name is obviously a pun and a small wink to the Graal VM [1]. Not sure there's any intention to reference TempleOS's HolyC. [1] https://github.com/graalvm/

Last I heard Terry Davis got kicked out of his parent's house and is now living out of his car. Something about an upcoming court case he's involved in as well. He has a small following on Reddit and users post updates of his whereabouts from time to time. He still sporadically streams live video to the TempleOS site. Last broadcast was from an internet cafe.

Does Terry still post here? I just went to my settings to turn on dead posts.

Re: HolyJit: A New Hope

#79
post #46
post #25

Earlier quoted context omitted.

Yes, once you convince everyone to drop the thing we have that works and implement the thing we don't have that doesn't work. In short: you complain as though it were an easy change to make.

He/she is right though, just wait when WebAssembly gets more mature. I bet all those plugins will be back.

WebAssembly has a lot of potential. It would be nice to write web apps in a language other than JavaScript that can compile down to WebAssembly and run in the browser.

Will there be a day where we can make desktop class apps that can run in the browser and not have to wade through the insanity of what is out there now...Should I use ReactJS, VueJs, Flow, Svelte, AngularJS, EmberJs, nextJS, on and on and on.

Pick an approach and standardize? Or just let people ship large WebAssembly binarys with their own runtimes and UI frameworks.

Re: HolyJit: A New Hope

#80
post #40

Earlier quoted context omitted.

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.

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?

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.

Post reply on HN