As Ariya mentioned in one of his previous posts, we’ve been doing some work on using JavaScriptCore (JSC) as the QtScript back-end. The whole idea is that you’ll get the same QtScript API, but with JSC performance. There’s also the prospect of being able to use the QtScript API together with QtWebKit, giving a smooth integration (e.g. having a function similar to QWebFrame::evaluateJavaScript() that returns a QScriptValue rather than a QVariant, and being able to use QScriptValue::call() and QScriptValue::setProperty() and friends; in general, having such API will just make it much easier for the C++ side and JS side to communicate).
The main challenge we’re facing is keeping the QtScript API behave 100% as it does today; it’s not acceptable that the behavior changes just because us speed freaks decide to replace the back-end, of course. The main aid we have in this regard is the set of QtScript autotests; assuming the tests are all-encompassing (which, let’s face it, is hard to guarantee, but let’s pretend…), after completing the back-end swap, all the tests should still pass. Once this goal is reached, some brave soul would step forward, brown paper bag in hand, asserting that except for performance improvements, it’s not possible for the application developer to tell that the QtScript runtime was replaced. OK, so we’ll probably have to do some real-world testing as well.
Work on the back-end had been put on hold for some time due to various other projects, but now we’re slowly getting back in business again. And the best news is that the ongoing work is now out in the open (qtscript-jsc-backend branch)! Now before you start doing the Qt dance, just keep in mind that the branch is not currently in a state where it can be used to run new or existing apps against the back-end, because not all the API and/or behavior is implemented yet. Currently we’re working on bringing it up-to-date with the last few months of changes in WebKit trunk, then we can focus on remaining API. In case you’re interested in helping out hardcore hacker-style, though, there’s an easy recipe that we all follow: Run one of the qscript* autotests, look for failures or asserts that say “Implement me”, and hack on the implementation until the test passes. 
Test statement by test statement, the compatibility will get there. Happy hacking!
Possibly related posts:
13 comments
wow, never knew that it is possible to implement JSC as QtScript back-end.
one more thing, how is it called, the current QtScript back-end?
That’s awesome.
Yet again Kent, you deliver great (although this some, somewhat incomplete) features! Again, this is very important to me, and I’d been waiting for this for some time. I unfortunately will have to wait to test it, as it sounds like it’ll take more time than I can give it.
But thank you, and I look forward to using this with 4.6!
Rock. On.
I’m currently working on a project that uses both QtScript on the one hand and QWebView on the other, showing pages with (JSC-evaluated) script in them. Merging these worlds would be very good for us.
One question:
Will this also mean that the version of Javascript that QtScript supports will take a leap forward?
Is there any work going on to support V8? I know that it was considered tedious, but for platforms where it is supported, it could be a big boost. I can of course completely understand if SquirrelFish[Exterme] is the immediate target.
Very cool. Is the goal to make the backend configurable at compile/runtime or will JSC replace the old backend completely?
What’s the impact on size for the completed binaries? Webkit is pretty huge, but how does JSC compare to the old backend?
Great news!
Does it mean that QtWebkit will become a dependency when we use QtScript? Or JSC will be in another library?
@Scorp1us: If you did check what I wrote before with respect to this, you would know the answer (which is “No”). Here is one reason: “lack of a bytecode interpreter for non JIT-supported platforms”.
Scorp1us: Why V8? SquirrelFish Extreme is native to WebKit and performs at least as good as V8 (even better in some cases). And you have fallback to standard SquirrelFish on non-JIT platforms. V8 is IMHO obsolete, Google should switch to SquirrelFish Extreme.
@Benjamin: Probably the best would be to put the script either in one of the existing Qt-lib, or in it’s own. Then QtWebKit could use it. Hmmm, or why not have QtWebKit simply depend on QtScript ?
@mmmm: V8 has a few fancy features that make it still worth using — specifically, process separation. It’s designed to keep the browser from locking up when a script goes bonkers.
@Adam Higerd: Are you really sure about that? Per-process execution is a feature in Chromium (Google Chrome), not V8. And it is really needed anyway if one is using V8, because V8 is not thread safe.
Oh? I thought that was in the core, not the browser. My mistake. Still sounds like a useful trick, though.
Comments on this entry are closed.