[Development] V8 on iOS

christopher.adams at nokia.com christopher.adams at nokia.com
Mon Apr 2 02:19:55 CEST 2012


Hi,

>> 	At this point, I'm either looking for an alternative to V8 
> 
> This is more of an follow-up question for the list than a reply:
> 
> QtDeclarative includes the V4 javascript interpreter that (as far as I know) can
> handle simple javascript expressions. How far can you get with V4 only?
> Could using V4 only be a good way of bootstrapping a V8-challenged
> platform?

Currently, v4 is quite limited in the sort of expressions that it can evaluate.
It would be possible to improve v4 to handle a greater range of expressions (eg, perhaps being able to handle JS function calls, so long as the function being called is itself v4-able) which would be beneficial for everyone.  However it is simply not possible to improve v4 to handle all expressions, and thus some form of naïve JS interpreter (which doesn't do JIT compilation or any form of on-stack code generation) would be required in order to evaluate complex bindings, complex signal handlers, and so on, if iOS does indeed require noexec stack etc.

In summary: not very far, with v4 only.

So the question is: could the dependence on v8 within QtDeclarative be changed, so that a naive JS implementation could be used instead, if v8 is not available on that platform?  Theoretically: yes.  Practically: no.  We gain a lot of advantages from tight integration with v8 (and indeed, we want to increase the tightness of that integration in order to improve performance further, eg, caching C++-side property resolution etc) and the performance of a naïve interpreter would probably be a showstopper anyway (even if v4 was improved to handle more cases than it does currently).

Also, it's a huge amount of work to #ifdef out all of the v8 integration within QtQml and QtQuick currently (and even more work to use hypothetical JS-backend-abstracting APIs provided by QtJsBackend as a true JS abstraction, which would also have massive performance implications).

Cheers,
Chris.





More information about the Development mailing list