WebKit spools up FTL, seeks to make JavaScript even faster

WebKit spools up FTL, seeks to make JavaScript even faster

WebKit, the open source rendering engine that powers Apple's Safari and is the basis of most mobile browsers today, is looking to once again escalate its level of JavaScript performance. Dubbed FTL — not "faster than light" but "fourth tier LLVM" — it's now spooled up and ready jump onto OS X and iOS. Filip Pizlo expounds in glorious, deeply nerdy fashion on the Surfing Safari blog:

As we worked to improve WebKit's optimizing compiler, we found that we were increasingly duplicating logic that would already be found in traditional ahead-of-time (AOT) compilers. Rather than continue replicating decades of compiler know-how, we instead investigated unifying WebKit's compiler infrastructure with LLVM – an existing low-level compiler infrastructure. As of r167958, this project is no longer an investigation. I'm happy to report that our LLVM-based just-in-time (JIT) compiler, dubbed the FTL – short for Fourth Tier LLVM – has been enabled by default on the Mac and iOS ports.

This post summarizes the FTL engineering that was undertaken over the past year. It first reviews how WebKit's JIT compilers worked prior to the FTL. Then it describes the FTL architecture along with how we solved some of the fundamental challenges of using LLVM as a dynamic language JIT. Finally, this post shows how the FTL enables a couple of JavaScript-specific optimizations.

If into high order browser bits, check out the full post and the WebKit nightly builds. If you're not, just know that once again JavaScript heavy sites — think social networks like Facebook, web apps like iWork, etc. — will eventually be hitting light-speed.

And if you're a total web geek let me know — what do you think of FTL?

Have something to say about this story? Leave a comment! Need help with something else? Ask in our forums!

Rene Ritchie

EiC of iMore, EP of Mobile Nations, Apple analyst, co-host of Debug, Iterate, Vector, Review, and MacBreak Weekly podcasts. Cook, grappler, photon wrangler. Follow him on Twitter and Google+.

More Posts



← Previously

Fund This: Kittyo lets you feed, talk to, and play with your cat while away from home

Next up →

Deal of the Day: Versio Mobile Skin Case for iPhone 5/5S

Reader comments

WebKit spools up FTL, seeks to make JavaScript even faster


Not-a-total-geek-just-a-wanna-be-geek here, but more cowbell.....I mean, more speed is always a good thing....right?!

I think they need to start moving some of these JS improvements over to the rest of the iOS space. It's ridiculous that apps should still be second citizen to the built-in browser for JS performance.

Oh I'm very aware of their quoted reason. It's just simply not an acceptable one. No other platform has this problem that I'm aware of. Javascript is becoming extremely prevalent, even in native apps. Forcing the old slow engine on those apps impacts performance, and also battery life. This security issue is one that CAN be solved, it's simply one Apple doesn't WANT to solve. It's never going to be a problem for Apple since their apps have exemptions. Honestly, I can understand why iOS developers have grown increasingly frustrated with Apple as of late.

Safari and UIWebView both execute interpreted code (javascript) from remote sources that the application cannot control, but through an engine that Apple purely controls.

If anything, Safari is a *more* open space than an App Store-funneled app, as Safari does not go through the same review process as a normal app, and it also has a profile and privileges within iOS that normal apps lack. Assuming JIT itself poses risks, then JIT within Safari should be considered more of a threat, not less.