[webkit-dev] Cleaning House
oliver at apple.com
Thu Apr 4 10:21:03 PDT 2013
Supporting V8 places a considerable burden on webkit, there are a number of
large, cumbersome and expensive abstractions required for to support multiple
JS engines (see the original discussions on the topic from many years ago).
Additionally we will only be supporting JSC in WebKit2, so I don't think anything could
convince me at least that maintaining support for multiple JS engines is good for
When thinking about which JS engines you want to se please consider that
JSC is webkit's main JS engine, that has a fast purely C backend that supports every
architecture under the sun, and even faster assembly support for at _least_ i386, x86-64,
ARMv5, Thumb2, MIPS, and SH4. It has JITs for all of those CPUs as well, and
the DFG optimizing JIT support i386, x86-64, and Thumb2 (unsure about the other CPUs
in that list).
Adding support for more architectures is relatively simple courtesy of our well
designed cpu abstractions ;)
JSC also has an ABI stable pure C API, supports an essentially unlimited number
of independent VMs running concurrently in a single process, and execution on
any given VM can be interleaved across multiple threads.
Given these many great and wondrous features, the support (at some level) for
_all_ architectures, the substantial cost of maintaining support for V8 bindings
does not seem worth it, at least to me.
If there are features that you do want that V8 provides, but JSC does not, you are
welcome to file bugs, or even contribute implementations :D
On Apr 4, 2013, at 3:56 AM, Mario Sanchez Prada <mario.prada at samsung.com> wrote:
>> On Apr 4, 2013, at 1:39 AM, Allan Sandfeld Jensen <kde at carewolf.com>
>> #if USE(V8)
>> #if !USE(JSC)
> Here at Samsung we are using WebKitGTK+ and V8, and I bet we are not the
> only ones doing it, so it would be great to keep those guards there.
>> Geoff posted the list in part because we'd like to know if any of the
>> above are used by other ports. We're not planning to remove things still
> in use.
> Cool, thanks.
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
More information about the webkit-dev