[Development] V8 on iOS
Ian
The first tentative steps for getting iOS support into Qt5 have been made (
really it's only a few small patches to get the build working - there's nothing
it could be used for yet). There's a possible issue with running any Javascript
interpreter on iOS (IIRC one of the App Store rules is that any Javascript must
run through their engine - which is only available as part of their browser
implementation), but let's ignore that for now and just concentrate on the
technical issues... There's also not much value in pursuing "jail break"
solutions, so let's ignore any solution which would be "jail break" only.
The iOS platform (as shipped to end-users) has a high level of security, with
applications needing to be signed, provisioned etc. before the shell will even
load them. Once loaded, the app runs at a reduced priviledge level (as the user
'mobile' IIRC). One of the priviledges which the app is not granted is the
ability to execute memory that has been marked as 'data', nor is it able to
allocate memory for 'code'. There is an iOS function 'mprotect' which can be
used to change execution priviledges for 'data' memory. Unfortunately, the
default provisioning for the app does not give it rights to call 'mprotect'. It
is possible to hack the provisioning (when packaging the app) to allow
'mprotect' to be called, but it's very unlikely that Apple would allow such an
application into the App Store (as mprotect is considered to be a private API,
and the hacked provisioning would be suspicious to them too).
There is another (possibly even bigger) issue in the ARM BI used by Apple on iOS.
It's not EABI (which AFAIK V8 on ARM is written for), and it's not even
documented AFAIK, so even though it's similar to EABI (from what I've seen so
far), it's not the same, which means that it may not even be feasible to port
V8 to iOS anyway (even without the priviledge issues).
As this is a bit of a show-stopper as far as I'm concerned (as a widget-only
version of Qt5 doesn't add any value over a widget and QML version of Qt4.8),
I'm not seeing any point in doing a Qt5 port to iOS if V8 is a hard requirement
(unless the above issues can be resolved somehow).
So I guess the question is: Is there any plan in place for platforms that are
not (for whatever reason) able to use V8 (which AFAIK would rule out QML2 and SG)?
Or maybe some way to use the interpreter from Qt4.8?
Please excuse any mistakes in terminology etc., I haven't been looking into
porting V8 to iOS that much yet (although I've done the preliminary steps which
enable it to build, it would probably crash and burn if run due to the memory
protection and ARM BI issues).
There's no platform plugin yet either, so no way to even test V8 on iOS AFAIK.
If anyone knows a way to test V8 without GUI, Declarative or OpenGL, then that
may be a starting point at least, because IMHO there's no point in starting a
platform plugin until this issue is resolved.
Thanks for your input,
Ian
_______________________________________________
Development mailing list
Devel...@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Holger Hans Peter Freyther
> There is another (possibly even bigger) issue in the ARM BI used by Apple on iOS.
> It's not EABI (which AFAIK V8 on ARM is written for), and it's not even
> documented AFAIK, so even though it's similar to EABI (from what I've seen so
> far), it's not the same, which means that it may not even be feasible to port
> V8 to iOS anyway (even without the priviledge issues).
This[1] is not the ABI that is used?
Ian
>This[1] is not the ABI that is used?
>
>[1]
>http://developer.apple.com/library/ios/documentation/Xcode/Conceptual/iPhoneOSABIReference/iPhoneOSABIReference.pdf
I have enough information about the ABI to know that it's similar to (but not
the same as) EABI (IIRC IOSABI uses an additional register which may or may not
be overwritten by V8, I haven't gotten that far yet).
Anyway, even if the ABI turns out to be a non-issue, there are still priviledge
and provisioning issues which can't be easily solved.
At this point, I'm either looking for an alternative to V8 or some way to test
V8 without a platform plugin, but thanks for the link (I must have looked at it,
and then forgotten about it, last year when I was into porting V8 to iOS - I
had to write ARM versions of some of the Mach system stuff).
morten...@nokia.com
At this point, I'm either looking for an alternative to V8
christop...@nokia.com
>> 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.
Ian
Thanks for your answer. So, the low-down is that it's not (practically)
possible to use QML without V8, and even if V8 did have a interpreter backend,
it would be too slow to be useable? If so, I guess I'm going to have to find a
way to get V8 working on iOS...
<christop...@nokia.com> wrote:
(04/02/2012 01:19)
>
>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).
>
_______________________________________________
aaron....@nokia.com
On 02/04/2012, at 2:21 PM, ext Ian wrote:
> Chris,
>
> Thanks for your answer. So, the low-down is that it's not (practically)
> possible to use QML without V8, and even if V8 did have a interpreter backend,
> it would be too slow to be useable? If so, I guess I'm going to have to find a
> way to get V8 working on iOS…
V8 with an interpreter backend would probably be fine. However, V8 doesn't have such a backend and writing one would be an enormous effort - akin to one of their architecture ports.
The key to getting V8 running on iOS will be executing writable pages. Unless you can solve that - and in a way that keeps Apple happy if you ever want to deploy such apps - everything else will be in vein.
Cheers,
Aaron
Thiago Macieira
> Hi,
>
> On 02/04/2012, at 2:21 PM, ext Ian wrote:
> > Chris,
> >
> > Thanks for your answer. So, the low-down is that it's not (practically)
> > possible to use QML without V8, and even if V8 did have a interpreter
> > backend, it would be too slow to be useable? If so, I guess I'm going to
> > have to find a way to get V8 working on iOS…
>
> V8 with an interpreter backend would probably be fine. However, V8 doesn't
> have such a backend and writing one would be an enormous effort - akin to
> one of their architecture ports.
I estimated a 40k contribution to do that.
> The key to getting V8 running on iOS will be executing writable pages.
> Unless you can solve that - and in a way that keeps Apple happy if you ever
> want to deploy such apps - everything else will be in vein.
I don't think Apple will ever allow that. I don't think Apple will allow
executing any code that isn't loaded strictly from disk.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
marius.st...@nokia.com
> On segunda-feira, 2 de abril de 2012 13.02.08,
> aaron....@nokia.com wrote:
>> On 02/04/2012, at 2:21 PM, ext Ian wrote:
>>> Chris, Thanks for your answer. So, the low-down is that it's not
>>> (practically) possible to use QML without V8, and even if V8 did
>>> have a interpreter backend, it would be too slow to be useable?
>>> If so, I guess I'm going to have to find a way to get V8 working
>>> on iOS…
>>
>> V8 with an interpreter backend would probably be fine. However, V8
>> doesn't have such a backend and writing one would be an enormous
>> effort - akin to one of their architecture ports.
>
> I estimated a 40k contribution to do that.
>
>> The key to getting V8 running on iOS will be executing writable
>> pages. Unless you can solve that - and in a way that keeps Apple
>> happy if you ever want to deploy such apps - everything else will
>> be in vein.
>
> I don't think Apple will ever allow that. I don't think Apple will
> allow executing any code that isn't loaded strictly from disk.
What do they use themselves for their own webkit JS engine?
--
.marius
Ian
point (for platforms like MIPS for example), but that work hasn't begun in any
way other than "maybe some time in the future", and even if it was decided to
implement that, it's quite some time off.
AFAIK Apple blocks what they find out about, and lets the rest pass until
someone complains or something bad happens. The big problems here are using
private APIs (they do static analysis, so there are ways around that), and
altering the application's provision (if they notice they will probably block
on that regardless of how it's been changed). They don't appear to analyse the
app at runtime, so I'm not sure how they would know about a 3rd party JIT (
apart from the provisioning). I'm not sure which actual JIT they use for their
own stuff, but I'm pretty sure it's not available outside of their webkit
implementation.
Guess the next step will be getting V8 to run at all on iOS (and finding a way
of testing it without a platform plugin)...
Thanks for the input!
Thiago Macieira <thiago....@intel.com> wrote:
(04/02/2012 14:06)
>On segunda-feira, 2 de abril de 2012 13.02.08, aaron....@nokia.com wrote:
>> Hi,
>>
>> On 02/04/2012, at 2:21 PM, ext Ian wrote:
>> > Chris,
>> >
>> > Thanks for your answer. So, the low-down is that it's not (practically)
>> > possible to use QML without V8, and even if V8 did have a interpreter
>> > backend, it would be too slow to be useable? If so, I guess I'm going to
>> > have to find a way to get V8 working on iOS?
>>
>> V8 with an interpreter backend would probably be fine. However, V8 doesn't
>> have such a backend and writing one would be an enormous effort - akin to
>> one of their architecture ports.
>
>I estimated a 40k contribution to do that.
>
>> The key to getting V8 running on iOS will be executing writable pages..
>> Unless you can solve that - and in a way that keeps Apple happy if you ever
>> want to deploy such apps - everything else will be in vein.
>
>I don't think Apple will ever allow that. I don't think Apple will allow
>executing any code that isn't loaded strictly from disk.
>
>--
>Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
> Intel Sweden AB - Registration Number: 556189-6027
> Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
_______________________________________________
Thiago Macieira
wrote:
> > I don't think Apple will ever allow that. I don't think Apple will
> > allow executing any code that isn't loaded strictly from disk.
>
> What do they use themselves for their own webkit JS engine?
Probably JavaScriptCore + SquirrelFish Extreme, which does JIT.
But that's not relevant. Apple isn't bound by Apple rules. You can't apply the
store rules for the base OS.
Thiago Macieira
> Hmmm, so from what I understand, there may be a bytecode backend for V8 at
> some point (for platforms like MIPS for example), but that work hasn't
MIPS has opted instead to write an assembler backend.
The effort would have to be for yet other platforms, like SPARC or PowerPC.
Or, if someone finally decides that writing assembly directly is a bad idea
since you have nothing to compare against.
> begun in any way other than "maybe some time in the future", and even if it
> was decided to implement that, it's quite some time off.
>
> AFAIK Apple blocks what they find out about, and lets the rest pass until
> someone complains or something bad happens. The big problems here are using
> private APIs (they do static analysis, so there are ways around that), and
> altering the application's provision (if they notice they will probably
> block on that regardless of how it's been changed). They don't appear to
> analyse the app at runtime, so I'm not sure how they would know about a 3rd
> party JIT ( apart from the provisioning). I'm not sure which actual JIT
> they use for their own stuff, but I'm pretty sure it's not available
> outside of their webkit implementation.
If a JIT works on bytecode, that's ok. The bytecode doesn't need to be
interpreted.
A JIT producing machine instructions would either need to be emulated (which
V8 can do), or make the memory writable and use mprotect for that.
> Guess the next step will be getting V8 to run at all on iOS (and finding a
> way of testing it without a platform plugin)...
--
Ian
:/
What I'm going to take away from this discussion is that it is expensive and
complex to implement anything other than what there is right now, and if any
work would be done on that in the forseeable future, it would take a commercial
sponsor to make that happen. Obviously noone here (including me) wants to take
on making alternatives unless they're going to be paid (lots of money) to do
that (or have some other pressing motivation)....
I'll try (if the ABI issues do not make it completely unfeasible) to get V8
working on iOS by methods that are not restricted by Apple's App Store rules.
Anyone wanting to use it, will then either need to take the risk that Apple
will reject their app (either immediately, or some time down the line after it
has been accepted), and provide their own solution to that issue if it's a
problem. Of course if the ABI issues or something else blocks my efforts, then
someone will have to sponsor a solution that both works for the platform (
technically) and for the App Store rules... IIRC the actual Apple restriction
regards Java interpreters/compilers is that they are not used to run code that
is downloaded from the web, so the issue at hand here really is being able to
run self-modifying code in such a way that doesn't violate the App Store rules
(or get noticed by the people enforcing them).
I'm hoping (I haven't looked at it much yet), that it would be fairly obvious
as to where the memory protection stuff would need to go in V8?
Thiago Macieira <thiago....@intel.com> wrote:
(04/02/2012 15:25)
_______________________________________________
aaron....@nokia.com
On 02/04/2012, at 3:04 PM, ext marius.st...@nokia.com wrote:
> On 02/04/2012 08:06, ext Thiago Macieira wrote:
>> On segunda-feira, 2 de abril de 2012 13.02.08,
>> aaron....@nokia.com wrote:
>>> On 02/04/2012, at 2:21 PM, ext Ian wrote:
>>>> Chris, Thanks for your answer. So, the low-down is that it's not
>>>> (practically) possible to use QML without V8, and even if V8 did
>>>> have a interpreter backend, it would be too slow to be useable?
>>>> If so, I guess I'm going to have to find a way to get V8 working
>>>> on iOS…
>>>
>>> V8 with an interpreter backend would probably be fine. However, V8
>>> doesn't have such a backend and writing one would be an enormous
>>> effort - akin to one of their architecture ports.
>>
>> I estimated a 40k contribution to do that.
>>
>>> The key to getting V8 running on iOS will be executing writable
>>> pages. Unless you can solve that - and in a way that keeps Apple
>>> happy if you ever want to deploy such apps - everything else will
>>> be in vein.
>>
>> I don't think Apple will ever allow that. I don't think Apple will
>> allow executing any code that isn't loaded strictly from disk.
>
> What do they use themselves for their own webkit JS engine?
My understanding is that they have a special exception for the web browser application to run the "Nitro" javascript engine (a fancy marketing name for JavaScript Core with JIT turned on), but they continue to use JSC with the byte code backend for everything else. I believe this is what led to the somewhat embarrassing iOS 4.3 situation where "web apps" ran significantly faster in a browser (using JIT), than they did when they were added to the home screen (where they didn't use JIT). I think that was fixed in 5.0.
Perhaps an iOS guru could provide more details.
Cheers,
Aaron