[Development] V8 on iOS

[Ian]

Too many technical terms that I don't have (or want) intimate understanding of...
:/

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.macieira at intel.com> wrote:
(04/02/2012 15:25)

>On segunda-feira, 2 de abril de 2012 16.17.35, Ian wrote:
>> 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)...
>
>-- 
>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