back
22 comments
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.

Surely complexity always creates risk. The question is whether the tradeoff is acceptable.

Everyone is optimizing the hell out of their Javascript engines right now -- the question is whether some jit that's cobbled together independently of any other codebase is going to be intrinsically superior to a compiler that's being used for lots of other things (obviously there are arguments in both directions, right?). Is it better to simultaneously support Javascript via V8 (which has tiered optimizations of its own), Dart both via compilation to Javascript and its own independently optimized runtime, and NaCl? Is it better to have Javascript and asm.js?

Your trusty Apple II will be immune to modern malware thanks to the simplicity of not being able to connect to the internet, run 32-bit software, or have more than 48kB of memory. Of course the Apple II did have at least one virus.

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

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.

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

This is why some browsers don't trust any code running in the webpage and sandbox everything in it
And Apple is forcing all other browsers to use its JS engine on iOS - so when Safara/its JS engine falls, they all fall.
Half untrue -- Apple allows you to use third-party JS engines on iOS. I've seen SpiderMonkey and Jurrasic (C#) used on iOS.

What they don't allow third parties to do is JIT compile. The "execute writeable pages" entitlement is only allowed to Safari and in iOS 8 WKWebViews.

So your bigger point stands -- third party browsers all need to use a single JS implementation if they want to have the speed of a JIT.

I think I prefer a single trusted implementation by Apple to N implementations by whoever wants to give it a shot.

With that logic applied to Windows, V8 would never have seen the light of day.
But that misses the other side of the argument, a fix for them is a fix for everyone and improvements to core are free improvements for everyone.
By that logic we should all be happy that Flash isn't a spec implemented in 4 different browsers, but rather on monolithic monster from one company, in all of them.
Which also emphasizes the point that Apple wouldn't ship this sort of code on iOS if it wasn't properly secured.
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=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.

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

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.
Apple's WebKit used "Nitro"/"JavaScript Core", did it not? V8 was just for Chrome (Which isn't even WebKit anymore).
Thanks - fixed!
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.

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

They're just broken anchor links – intended to take you to the section headings further down the page, I think.
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?