[webkit-qt] webkit2, v8, diplomacy

[Simon Hausmann]

On Tuesday, June 05, 2012 08:12:01 AM ext Coda Highland wrote:
> On Tue, Jun 5, 2012 at 7:53 AM, Balazs Kelemen <kbalazs at webkit.org> wrote:
> >     Hi all!
> > 
> > I think it's time to decide how important is the v8 integration for us.
> > I'm
> > not saying it's hyper-super important, I'm just curious about your
> > opinion.
> > In fact we have a qt5 release blocker bug for that:
> > https://bugs.webkit.org/show_bug.cgi?id=76778 (although at the time when
> > it
> > has been filed we did not expect that much community resistance) and it's
> > also quite clear that this could save a lot of memory (1 js engine instead
> > of 2). It's evident that we don't want to go against the community, but
> > still I think they should be more open to this. It's really just some
> > lines
> > of boilerplate glue code to webkit2, and we choose a solution that
> > provides
> > source compatibility with WebKitTestRunner. Btw, there are the bugs:
> >     - https://bugs.webkit.org/show_bug.cgi?id=76778 (meta)
> >     - https://bugs.webkit.org/show_bug.cgi?id=87872 shim for wtr
> >     - https://bugs.webkit.org/show_bug.cgi?id=84457 wk2+v8
> > 
> > If the case is that we want to go for this, I would definitely need your
> > help to get community acceptance since I'm not a reviewer and honestly I
> > am
> > not very good in diplomacy :)
> > 
> > Anyway, I would not like to make the false illusion that pushing these
> > patches will solve every problem and just save memory. In fact, in order
> > to
> > get the desired benefit we have to solve other issues:
> >     - using the same copy of v8 (fork) in declarative and webkit. this is
> > tricky because webkit needs the most up-to-date v8 version
> >     - using v8 in qtscript, or detaching qtscrpit from qtdeclarative (I
> > heard qtscript is a dependency)
> > 
> > 
> > Cheers,
> > -kbalazs
> 
> I don't understand why the push for V8 in the first place. JSC and V8
> are in an arms race for performance, so you can't categorically say V8
> is faster because that's not always true. JSC also has broader support
> (see Konstantin's post). Furthermore, my understanding is that V8
> doesn't expose the necessary APIs to be able to provide the full scope
> of the QtScript API. (Has this changed since the original plans to
> move to V8 were announced?)
> 
> Is there some specific feature that makes V8 qualitatively superior to
> JSC for Qt's use cases? So far I've not seen anything that really
> sells me on the idea.

Two key points drove us to choose V8 over JSC for QML:

    1) V8 provides an API that is much more stable (subject to less source 
incompatible changes).

    2) Performance. The way the V8 API allows binding with C++ code as well as 
the QML compiliation mode patch allowed for a much faster QML binding 
evaluation as well as faster C++ bindings inside the engine.


There was also the slightly less technical point that the V8 engine is moving 
forward with great momentum over a long period of time.



Over time the QML folks have learned a few things though, so in the meantime 
QML also includes a lightweight bindings evaluator (called V4) that avoids 
entering the v8 JIT for simple bindings. (I'm aware that "simple" is not a 
technically accurate term, but it keeps this email shorter :)



Now on the topic of V8 for QtWebKit we're looking at different arguments:

In the light of the WebKit1 in-process design we really wanted to share the 
underlying engine at run-time with QML. It just doesn't feel right to imagine 
a QML application using WebKit where QML is using one JS engine (V8) and 
within the same process a second JS engine (JSC) would be running as soon as 
you embed WebKit. It doesn't feel right to run two GCs on two different heaps 
and using the same engine opens up for interesting possibilities for hybrid 
applications. Do you agree here or would you like me to elaborate a bit more?

That vision however was born  long time ago and things have changed since 
then, especially with the decision to use WebKit2 as the way of embedding 
WebKit into QtQuick2. With WebKit using JSC and QML using V8 we still end up 
with two engines, but they live in separate processes. Less of a deal I would 
say, and for any exchange of "objects" between those two engines for hybrid 
application use-cases we should probably settle for JSON as data exchange 
format (and it probably starts with the use of SerializedScriptValue in WK2).

I hope this clears it up a bit for you. I'll continue with the QtWebKit 
relevant V8 bits in a reply to Balazs' email.



Simon