<story><title>FTL: WebKit’s LLVM-based JIT</title><url>http://blog.llvm.org/2014/07/ftl-webkits-llvm-based-jit.html</url></story><parent_chain></parent_chain><comment><author>andrewchambers</author><text>Unfortunately I think the increased complexity in javascript engines is also a security risk.&lt;p&gt;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.&lt;p&gt;This is less of an issue for llvm when used as a static compiler, but as a jit on untrusted code, I don&amp;#x27;t know.&lt;p&gt;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.</text></comment>
<story><title>FTL: WebKit’s LLVM-based JIT</title><url>http://blog.llvm.org/2014/07/ftl-webkits-llvm-based-jit.html</url></story><parent_chain></parent_chain><comment><author>AndrewDucker</author><text>I&amp;#x27;m intrigued that they keep pointing out that it&amp;#x27;s not using any asm.js optimisations, but still &amp;quot;performs well&amp;quot;.&lt;p&gt;&amp;quot;Performing well&amp;quot; in this case still means significantly slower than Firefox does on the same code:&lt;p&gt;&lt;a href=&quot;http://arewefastyet.com/#machine=12&amp;amp;view=breakdown&amp;amp;suite=asmjs-apps&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;arewefastyet.com&amp;#x2F;#machine=12&amp;amp;view=breakdown&amp;amp;suite=asm...&lt;/a&gt;&lt;p&gt;Which isn&amp;#x27;t to say that it&amp;#x27;s not a big improvement over where it was.  But there&amp;#x27;s still a way to go on making it competitive, so far as I can see.&lt;p&gt;Edit: Got name of the original engine wrong.</text></comment>