5 ms·

FTL: WebKit’s LLVM-based JIT

127 points by dochtman 12y ago

AndrewDucker 12y ago
I'm intrigued that they keep pointing out that it's not using any asm.js optimisations, but still "performs well". "Performing well" in this case still means significantly slower than Firefox does on the same code: http://arewefastyet.com/#machine=12&view=breakdown&suite=asmjs-apps http://arewefastyet.com/#machine=12&view=breakdown&suite=asm... Which isn't to say that it's not a big improvement over where it was. But there's still a way to go on making it competitive, so far as I can see. Edit: Got name of the original engine wrong.
- CJefferson 12y ago
  Personally, I am more interested in improvements to asm.js like code. The limitations of asm.js, in particular the inability to allocate memory, greatly limits its usefulness for many applications.
  - mnemonik 12y ago
    A work around is to pass a foreign function into your asm.js module to do allocations for you, but then you have to either implement your own GC, do reference counting, or just come up with some hand rolled lifetime management. I'm also interested in how asm.js could be improved in this regard without moving away from its existing barebones model. Would love to hear ideas. I think the first thing we will see is shared array buffers between workers because games really need that.
  - sunfish 12y ago
    We're interested in that too; see the "Firefox (no asmjs)" line in those arewefastyet graphs. That shows Firefox with asm.js-specific optimization disabled.
- 9point6 12y ago
  Apple's WebKit used "Nitro"/"JavaScript Core", did it not? V8 was just for Chrome (Which isn't even WebKit anymore).
  - AndrewDucker 12y ago
    Thanks - fixed!
ksec 12y ago
It seems there were a lot of new "features" in LLVM to get this right. Where previously most of the Dynamic Script replying on LLVM hoping to speeds things up simply wasn't possible. ( Project Unladen Swallow. ) Dropbox's Pyston seems to have it this round. Will Rubinius get any more substantial improvement? It seems to be in maintenance mode rather then development mode.
andrewchambers 12y ago
Unfortunately I think the increased complexity in javascript engines is also a security risk. Fuzzing and other techniques may be able to cause all sorts of crashes and memory corruptions in the jit compilers code or in the generated code. This issue may have just been amplified by the extra complexity in the massive amount of LLVM C++ code added. This is less of an issue for llvm when used as a static compiler, but as a jit on untrusted code, I don't know. Time will tell, but I wonder if Rusts memory safety will make it a better candidate for implementing advanced JIT engines that process untrusted code than C++ like in LLVM.
- _pmf_ 12y ago
  > Fuzzing and other techniques may be able to cause all sorts of crashes and memory corruptions in the jit compilers code or in the generated code. This issue may have just been amplified by the extra complexity in the massive amount of LLVM C++ code added. But to be consistent with the web's development, such risks should not be considered in advance (this would spoil the fun, after all!), but bolted on in vendor specific ways as an afterthought (so that the vendors can be continued to be ridiculed for their incompetency, which makes "full-stack-engineers" feel warm and fuzzy).
- dbaupp 12y ago
  A JIT is inherently unsafe, since you're creating (nearly) arbitrary code, so, IMO, the largest benefit Rust can give to a JIT is possibly making it easier to write correct code, since memory safety of the code generator is somewhat orthogonal to memory safety of the generated code. (NB. it isn't necessarily the case that Rust makes writing correct code easier, but features like ADTs and pattern matching seem like they would be useful for such things.)
  - andrewchambers 12y ago
    I was partially referring to LLVM segfaulting sometimes on bad input, but its correct to say even without segfaults in the compiler itself, just generating incorrect code via any other bug could cause the same issues. LLVM is interesting in that it's far less mature as a JIT than as a static compiler. I think using llvm as a browser JIT specifically may raise the bar for how the LLVM people need to consider security in the code. Though that being said, compilers are already some of our most critical and trusted code.
ramigb 12y ago
Some of the google documnets were not shared probably, would you please share them? like the "FTL Performance" one it gives me: "Your current account (@gmail.com) does not have access to view this page. Click here to logout and change accounts."
- aaronharnly 12y ago
  They're just broken anchor links – intended to take you to the section headings further down the page, I think.
notastartup 12y ago
Not sure if I understand the technical jargon in the article, can someone tell me what the implication of this LLVM engine is? Will we finally see cross platform Javascript mobile apps that runs like native apps?

127 points by dochtman 12y ago

I'm intrigued that they keep pointing out that it's not using any asm.js optimisations, but still "performs well". "Performing well" in this case still means significantly slower than Firefox does on the same code: http://arewefastyet.com/#machine=12&view=breakdown&suite=asmjs-apps http://arewefastyet.com/#machine=12&view=breakdown&suite=asm... Which isn't to say that it's not a big improvement over where it was. But there's still a way to go on making it competitive, so far as I can see. Edit: Got name of the original engine wrong.

CJefferson 12y ago
Personally, I am more interested in improvements to asm.js like code. The limitations of asm.js, in particular the inability to allocate memory, greatly limits its usefulness for many applications.
- mnemonik 12y ago
  A work around is to pass a foreign function into your asm.js module to do allocations for you, but then you have to either implement your own GC, do reference counting, or just come up with some hand rolled lifetime management. I'm also interested in how asm.js could be improved in this regard without moving away from its existing barebones model. Would love to hear ideas. I think the first thing we will see is shared array buffers between workers because games really need that.
- sunfish 12y ago
  We're interested in that too; see the "Firefox (no asmjs)" line in those arewefastyet graphs. That shows Firefox with asm.js-specific optimization disabled.
9point6 12y ago
Apple's WebKit used "Nitro"/"JavaScript Core", did it not? V8 was just for Chrome (Which isn't even WebKit anymore).
- AndrewDucker 12y ago
  Thanks - fixed!

ksec 12y ago

It seems there were a lot of new "features" in LLVM to get this right. Where previously most of the Dynamic Script replying on LLVM hoping to speeds things up simply wasn't possible. ( Project Unladen Swallow. ) Dropbox's Pyston seems to have it this round. Will Rubinius get any more substantial improvement? It seems to be in maintenance mode rather then development mode.

andrewchambers 12y ago

Unfortunately I think the increased complexity in javascript engines is also a security risk. Fuzzing and other techniques may be able to cause all sorts of crashes and memory corruptions in the jit compilers code or in the generated code. This issue may have just been amplified by the extra complexity in the massive amount of LLVM C++ code added. This is less of an issue for llvm when used as a static compiler, but as a jit on untrusted code, I don't know. Time will tell, but I wonder if Rusts memory safety will make it a better candidate for implementing advanced JIT engines that process untrusted code than C++ like in LLVM.

_pmf_ 12y ago
> Fuzzing and other techniques may be able to cause all sorts of crashes and memory corruptions in the jit compilers code or in the generated code. This issue may have just been amplified by the extra complexity in the massive amount of LLVM C++ code added. But to be consistent with the web's development, such risks should not be considered in advance (this would spoil the fun, after all!), but bolted on in vendor specific ways as an afterthought (so that the vendors can be continued to be ridiculed for their incompetency, which makes "full-stack-engineers" feel warm and fuzzy).
dbaupp 12y ago
A JIT is inherently unsafe, since you're creating (nearly) arbitrary code, so, IMO, the largest benefit Rust can give to a JIT is possibly making it easier to write correct code, since memory safety of the code generator is somewhat orthogonal to memory safety of the generated code. (NB. it isn't necessarily the case that Rust makes writing correct code easier, but features like ADTs and pattern matching seem like they would be useful for such things.)
- andrewchambers 12y ago
  I was partially referring to LLVM segfaulting sometimes on bad input, but its correct to say even without segfaults in the compiler itself, just generating incorrect code via any other bug could cause the same issues. LLVM is interesting in that it's far less mature as a JIT than as a static compiler. I think using llvm as a browser JIT specifically may raise the bar for how the LLVM people need to consider security in the code. Though that being said, compilers are already some of our most critical and trusted code.

ramigb 12y ago

Some of the google documnets were not shared probably, would you please share them? like the "FTL Performance" one it gives me: "Your current account (@gmail.com) does not have access to view this page. Click here to logout and change accounts."

aaronharnly 12y ago
They're just broken anchor links – intended to take you to the section headings further down the page, I think.

notastartup 12y ago

Not sure if I understand the technical jargon in the article, can someone tell me what the implication of this LLVM engine is? Will we finally see cross platform Javascript mobile apps that runs like native apps?