Google Chrome for Linux: Why V8 Bests WebKit's JavaScript Engine

In general, Google does not suffer from NIH syndrome. It is therefore curious, at first, that they (Google) would develop their own JavaScript engine when a number of potential options exist. Most notable in this regard is the existence of a JavaScript engine in WebKit. WebKit is the Web browser engine that has already been adopted for use by the Chromium Project in Google Chrome for Linux. After providing a brief overview of the WebKit JavaScript engine, the Chromium Project's decision to use The V8 JavaScript engine can be understood quite clearly.

Even though WebKit has experienced significant adoption, there is considerable effort underway to improve it. And in this regard of continuous improvement, the WebKit JavaScript engine JavaScriptCore is no exception. Although additional details are summarized elsewhere, under consideration for improving the WebKit JavaScript engine is:

• The introduction of a bytecode interpreter. JavaScriptCore currently executes a syntax tree.
• The introduction of a generational garbage collector. Garbage collection is a process that reclaims memory from objects that are dereferenced (i.e., in essence, no longer needed). A generational approach incrementally collects garbage - selectively a few objects at-a-time, as opposed to brute force all-at-once. This improves overall efficiency as the necessary process of garbage collection impacts less upon code execution. Introduction of this approach will also simplify how JavaScriptCore manages pointers.
• Improved test suite compatibility. The current implementation of JavaScriptCore does not cleanly pass tests in the Mozilla JavaScript Test Suite. In addition to improved run-time compliance, efficiencies are anticipated to result from compatibility improvements in this area.
• Incorporation of extensions to JavaScript. Ecma International's Standard ECMA-357 (aka. E4X) specifies extensions to ECMAScript to include native support for XML. The WebKit Project intends to consider implementing this support in a future version of their JavaScriptCore engine. Provider extensions (e.g., from the Mozilla Project) to JavaScript, as well as the WebKit Project's own extensions, are also under consideration.
• The introduction of a C language binding. JavaScriptCore currently provides a C++ binding. The introduction of a C-based binding is anticipated to improve maintainability and interoperability.

Armed with a sense as to the current status of the WebKit JavaScript engine, it is now possible to compare and contrast it with V8.

V8 has been considered previously in this series. That being the case, attention here focuses on comparing and contrasting V8 with WebKit's JavaScriptCore.

JavaScriptCore and V8 differ significantly in their execution models. JavaScriptCore will execute JavaScript bytecode - today it executes a syntax tree. V8 takes a radically different approach on two fronts. First, it introduces an efficient method for accessing properties associated with an object. Second, JavaScript bytecode is compiled into architecture-specific machine code. Because JavaScript is a dynamic language, the new paradigm for property access is fully integrated with execution of machine code through a patching mechanism that accounts for object-property dynamics in real time. Not only are JavaScriptCore and V8 approaching the model of execution differently from a technical standpoint, they are also exhibiting philosophical differences - to incur or not to incur the penalty of interpretation.

JavaScriptCore and V8 are completely aligned on garbage collection, as both engines are (or will) use a generational approach. Of course, the specifics of the algorithms employed and their implementation remain different.

WebKit's JavaScript engine places emphasis on the need to support various extensions to JavaScript. I have not (yet) run across such considerations in the case of V8.

Like JavaScriptCore, V8 provides C++ bindings. I have not (yet) run across anything suggesting that V8 intends to support bindings through another language.

In summary then, it is fairly clear why the Chromium Project adopted V8 over JavaScriptCore. V8 delivers today an efficient run-time platform based on a novel execution model and leading-edge garbage collection. As V8 continues to evolve, however, JavaScript extensions are highly likely to warrant consideration.