[Development] QML engine changes

Chris Adams chris.adams at qinetic.com.au
Mon Jun 24 13:18:41 CEST 2013


Hi,

This is really exciting news!  Good stuff!

> Hi,
> >
> > Does that include to get rid of v8 as an JS engine option for QML2?
>
> Yes, that's exactly the proposed change.
>
> > I have not tested it yet, but it would be interesting to know if the new
> > engine also uses just in time compilation, as we had quite some work done
> > to get v8 running on WinCE due to wrong ARM abis for Windows CE among
> other
> > things.
>
> Yes it does just-in-time compilation and will require most probably some
> changes to work under Windows CE. (but it should be less than the changes
> require for V8, if my memory of the v8 changes serves me right)
>

Is there an "interpreter only (no JIT)" compile-time option?  Presumably
that's required for iOS adoption, for example?
I wonder how much performance delta there is between JIT and pure
interpretted, with a tight enough interpreter loop, if you make some
simplifying assumptions (eg, types can't change at runtime / enforce no
property deletion or dynamic property addition to objects or prototypes /
disallow eval()).  Of course, some of those limitations would no doubt
break existing client code, but I personally think that weak typing is the
major negative of JavaScript :-/

> > Hi,
> > >
> > > As you may have heard (or read), Lars, Erik and I have been working on
> > > some
> > > bigger changes for qtdeclarative for a while. In a nutshell we've
> replaced
> > > the V8 JavaScript engine with a new engine that we wrote (based on
> work by
> > > Roberto and Aaron). We've progressed rather well and in our wip/v4
> branch
> > > in qtdeclarative we're now passing all auto tests (as well as the
> > > ECMAScript 262 test suite). So that's why we'd like to propose merging
> > > this
> > > work into qtdeclarative mainline (dev branch), in the coming
> days/week(s)
> > > -
> > > in time for Qt 5.2 though.
>

This confuses me a bit.  Why isn't the implementation tuned specifically
for QML, instead of being a fully-compliant ecmascript implementation?
There are currently some problems with using 3rd party JS libraries in QML
applications, simply because the environment doesn't have the stuff usually
supplied by the browser (and the difficulties in injecting properties in
the context at import time), so I don't know how many people actually use
"eval()" in their QML code, for example.  And I think some extremely
impressive performance improvements could be gained by integrating more
tightly with the QML engine.

Something Aaron mentioned to me a little while ago, is the possibility of
doing a two-stage binding generation (it's not too clean, but it's
extremely impressive): build pre-optimized binaries; run the application on
device; application emits the IR for the bindings during first time
evaluation, back to QtCreator; collect the IR and do a reverse transform
into C++ code; generate optimized binaries.  All of the type information is
generated/known at the time the IR is generated, so there shouldn't be any
problems compiling the resultant reverse transform; you end up with
super-fast bindings implementation, and no JIT required in the final
binaries.  If any bindings change at runtime, just use an interpreter to
evaluate the expression.

Of course there are issues (dynamically load QML resources from the web,
for example, might result in different bindings at runtime) and I may have
misunderstood some vital elements of the concept when Aaron explained it to
me, but it seems like a really interesting area of research.

In general, I think there's a lot of scope for improving the tooling around
QML, but I guess that's no surprise to anyone.


> > >
> > > We think that this work brings in many advantages, among others much
> > > improved maintenance (we know how this thing works, which isn't
> something
> > > we can confidently say about V8 as much as we'd like to), a unified
> code
> > > path in QML [1], much less code overall  and great opportunities for
> > > optimizations (way beyond what's possible with V8's API layer - you'd
> be
> > > surprised how often even in today's QML usage the V8 code path is not
> > > actually taken because it's slower that the built-in interpreter).
> > >
> > >
> > > So this is a heads-up and of course a last call for objections :)
> > >
> > >
> > >
> > > Simon
> > >
> > >
> > > [1] Did you know what when you read a URL property in QML binding
> > > expressions, sometimes it's a string and sometimes it's an opaque
> variant?
> > > That's because the builtin interpreter in qtdeclarative and V8 behave
> > > different. We're fixing that :)
>

Hehe.  At one stage there were three separate jsValueToMetatype()
conversion functions in the codebase o_O.

Anyway, I'm really excited about this change.  Congrats and thanks to Erik,
Lars and yourself for your impressive work!

Cheers,
Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130624/b9944409/attachment.html>


More information about the Development mailing list