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