New MacBook Pros are here! Get the lowest prices anywhere: Apple Price Guides updated July 31st (exclusive coupons)
 


Thursday, March 01, 2012, 04:29 pm PT (07:29 pm ET)

New low level JavaScript interpreter to boost WebKit performance more than 200%

Apple's WebKit JavaScriptCore is now a "triple tier virtual machine," offering the potential for 2-2.5 times faster JavaScript performance in Safari.

Recent changes in Apple's WebKit open source project (used by Safari on OS X and iOS, and to power a wide variety of other browsers) include the incorporation of the efficient new LLInt (Low Level Interpreter), which is now used by JavaScriptCore (JSC) to attempt executing code before passing it to the standard interpreters, either the bytecode virtual machine or the JIT (Just In Time complier) which builds native machine code on the fly.

"JSC will now will start by executing code in LLInt and will only tier up to the old JIT after the code is proven hot," a change report on the new interpreter describes.

"LLInt is written in a modified form of our macro assembly. This new macro assembly is compiled by an offline assembler (see offlineasm), which implements many modern conveniences such as a Turing-complete CPS-based macro language and direct access to relevant C++ type information (basically offsets of fields and sizes of structs/classes)."

The new interpreter "is 2-2.5x faster than our old interpreter on SunSpider, V8, and Kraken [benchmarks]," the report states. "With triple-tiering turned on [to allow the LLInt to interpret code], we're neutral on SunSpider, V8, and Kraken, but appear to get a double-digit improvement on real-world websites due to a huge reduction in the amount of JIT'ing."

JavaScript performance in web browsers is a primary focus for optimization, as the faster and more efficiently code can be executed, the more fluid animations can run and the more sophisticated and responsive cross platform web applications can be.

The LLInt enhancements to JavaScriptCore appear to have been contributed by Filip Pizlo, who joined WebKit as a reviewer in December after acting as a "major contributor" to improvements to the JavaScriptCore JIT and Garbage Collector. Pizlo filed a bug report in January noting that "JSC should be a triple-tier VM," and subsequently solved the issue by the end of February.

The new changes to JavaScriptCore will take some time to make it into the mainstream version of Safari, following similar WebKit enhancements of previous years. Enhancements in Apple's next release of Safari 5.2 have been profiled in reports describing its new user interface and sharing enhancements and new privacy settings and website alert features.



Improvements to Nitro in JavaScriptCore

In 2008, WebKit announced a rewriting of JavaScriptCore as a direct-dispatch register based, high-level bytecode virtual machine originally named SquirrelFish. It compiled JavaScript into native machine code. The project was later enhanced to gain the codename SquirrelFish Extreme.

SquirrelFish Extreme


In 2009, Apple applied the enhancements to Safari 4 under the brand "Nitro," noting that the new implementation could run JavaScript up to 4.5 times faster.

The next year, it subsequently released new SquirrelFish Extreme enhancements in Safari 5, boosting JavaScript performance on the Mac another 30 percent over the previous Safari 4.

Last year, the company added Nitro to mobile Safari in iOS 4.3, boosting JavaScript performance by 200 percent on Apple's mobile devices. However, a minor controversy ensued after it was found that iOS only used Nitro to accelerate web apps running in Safari; this resulted in a significant speed penalty when full screen web apps were saved to the home screen.

In iOS 5, Apple solved the security issues that prevented earlier releases from running full screen web apps using Nitro, although security measures still prevent apps that use UIWebView to present a web view from invoking Nitro.

Google's JavaScript competitors

Other WebKit browsers don't necessarily use JavaScript Core. Google's Chrome uses its own competing V8 JavaScript engine, for example.

V8 seeks to enhance performance by compiling JavaScript to native code before executing it. It was developed by a team led by Lars Bak, the programmer who developed Sun's Java ME virtual machine. After Oracle acquired Sun, it filed suit against Google for infringing patents related to virtual machines, including a patent filed by Bak while working for Sun.

JavaScript, which is related to Java in name only, was originally developed at Netscape as a way to add programatic interactivity to web pages (it was previously named LiveScript). JavaScript has since become a widely established open standard, sometimes referred to as ECMAScript, after the standards body that now manages it as a specification. Microsoft formerly supported its own vbscript, but has since backed interoperability on the web through the common use of JavaScript.

Google has recently sought to replace JavaScript with its own new web programming language named Dart (originally Dash), which was codeveloped by Bak. Apple, Mozilla and Microsoft have all opposed Google's plans to replace JavaScript with its own new language, preferring instead to continually improve upon JavaScript.

Mozilla's Brendan Eich, who developed the original JavaScript at Netscape, recently wrote, "I guarantee you that Apple and Microsoft (and Opera and Mozilla, but the first two are enough) will never embed the Dart VM," adding, "Google's approach with Dart is thus pretty much all wrong and doomed to leave Dart in excellent yet non-standardized and non-interoperable implementation status," and musing, "could Google, unlike Microsoft ten or so years ago, prevail? Only by becoming the new monopoly power on the web. We know how that story ends."

In a discussion about Dart in December, Apple's Oliver Hunt wrote, "Adding direct and exposed support for a non-standard language is hostile to the open-web by skipping any form "consensus" driven language development that might happen, and foisting whatever language we want on the web instead. This implicitly puts any browser that supports additional proprietary extensions in the same position as a browser supporting something like vbscript, and has the same effect: breaking the open web by making content that only works effectively in a single product."

Google's efforts to leverage Chrome to push its own preferred technologies rather than open standards has also occured with its own WebM video codec (as opposed to H.264) and a prioritization of Adobe's Flash (over HTML5) for delivering video and interactivity, particularly as a differentiating feature of its Android mobile platform.