Live data from Hacker News

HolyJit: A New Hope

blog.mozilla.org

61–70 of 219 posts

Re: HolyJit: A New Hope

#61
post #57
post #46

Earlier quoted context omitted.

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

WebAssembly has no good story for the DOM.

i feel like that's on purpose...we can engineer all these crazy things, but getting good DOM access? naw not possible

Re: HolyJit: A New Hope

#62
post #58
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/

It could also be a play on the phrase "Holy shit!"

“Could” if that’s not intentional then this browser will fail lol

Re: HolyJit: A New Hope

#64
post #57

Earlier quoted context omitted.

WebAssembly has no good story for the DOM.

i feel like that's on purpose...we can engineer all these crazy things, but getting good DOM access? naw not possible

wasm is an MVP, they fully intend to add DOM support: http://webassembly.org/docs/future-features

Its just that implementing the DOM requires a lot of other (complex) things 1. Stable JS object ABI 2. Integration with the GC garbage collector 3. Better integration with modules

Personally, I'm hoping that we actually get a lower-level subset of the DOM apis that doesn't rely on as many OO features so we can bind to it easier, and avoid more DOM manipulation overhead (though I have no idea what this would look like).

Re: HolyJit: A New Hope

#65
post #40

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.

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?

Re: HolyJit: A New Hope

#66
So Mozilla continues the tradition of terrible names in software engineering - HolySh*t is just wonderful. At least if they were as autistic as Terry and were inspired by HolyC...

Re: HolyJit: A New Hope

#68

No offense, but the blog post is seriously missing a better (or any?) explanation of what's the new JIT all about. At first I even thought my browser loaded only half the page...

It does link to https://github.com/nbp/holyjit which explains pretty much everything there is to explain so far...

Re: HolyJit: A New Hope

#69
post #24

Why does the Cargo.toml[1] file in the source repo for HolyJit have the word "brainfuck"[2] in it? Does that have some significance to Rust or Mozilla? Or is this a case of copy pasta? [1]: https://github.com/nbp/holyjit/blob/master/Cargo.toml [2]: Permanent link to line: https://github.com/nbp/holyjit/blob/1f20eb41de2dae14179815c7...

>the source repo for HolyJit have the word "brainfuck"[2] in it?

It is a reference to the best programming language ever created.

Post reply on HN