5 ms·

AFAIK they will never allow JIT. It isn't so much banning JIT as it is the kernel providing no way for applications to mark memory pages executable. Marking mem

AFAIK they will never allow JIT. It isn't so much banning JIT as it is the kernel providing no way for applications to mark memory pages executable. Marking memory executable is how JIT compilers function, but it also prevents other uses.

phoboslab 13y ago
I still have hopes that Apple cares enough and finds a way to whitelist the JSC lib somehow. Not sure exactly how that would work, because permissions to allocate executable memory is given per process on iOS. But I guess they could inspect the call stack to see if the allocating call indeed comes from the built-in JSC lib?
- apaprocki 13y ago
  Can't predict the future -- but I do not think they will ever do it after talking to @radian at JSConf.EU.
- dunham 13y ago
  They might be able to support JIT by moving webkit out of process. I believe they do this now with the Mail UI. For more info see: http://oleb.net/blog/2012/10/remote-view-controllers-in-ios-6/
- mistercow 13y ago
  They could potentially do it with IPC, running the JS engine (or even the entire web view) in a separate process. The question then is whether the communication overhead can be minimized so that it doesn't cancel out the performance benefits of the JIT.
  - eonil 13y ago
    They're doing that for Quartz. But I doubt what will drive Apple to improve JS performance. Because making people to use Objective-C is a lot beneficial to Apple.
    - mistercow 13y ago
      Interesting. If they're doing it for Quartz, then that pretty much answers the overhead question. I suspect you are right that Apple feels very little motivation to improve support for languages and environments that don't lock you into their system. Or at least, they wouldn't have under Jobs. But I don't think it is true that this strategy is actually more beneficial to Apple. Developers want to support multiple platforms, and the least expensive way to do that is often HTML5. That's why PhoneGap is popular, despite the poor JS performance. The extra cost of doing separate apps is ultimately paid not only by third party developers, but by Apple as well. To make a long story short, encouraging a cross platform environment would allow good developers to make higher quality apps. Much as I dislike Apple these days, the difference between iOS and Android is such that I have trouble maintaining a straight face when I hear them compared. They don't need to compete on app availability.
antimagic 13y ago
More exactly, the kernel does provide a way for applications to mark memory pages as executable (which is exactly what Safari does, after all), but you need to have the right permissions to use the API, and App Store apps don't have those permissions...
- edvinbesic 13y ago
  Even more exactly, there are ways but if you use them there is no way to publish on the App Store, because private API. There is no reason not to have JIT or WebGL in a WebView other then apple not wanting you to, even though this was the original vision of the platform.

phoboslab 13y ago

I still have hopes that Apple cares enough and finds a way to whitelist the JSC lib somehow. Not sure exactly how that would work, because permissions to allocate executable memory is given per process on iOS. But I guess they could inspect the call stack to see if the allocating call indeed comes from the built-in JSC lib?

apaprocki 13y ago
Can't predict the future -- but I do not think they will ever do it after talking to @radian at JSConf.EU.
dunham 13y ago
They might be able to support JIT by moving webkit out of process. I believe they do this now with the Mail UI. For more info see: http://oleb.net/blog/2012/10/remote-view-controllers-in-ios-6/
mistercow 13y ago
They could potentially do it with IPC, running the JS engine (or even the entire web view) in a separate process. The question then is whether the communication overhead can be minimized so that it doesn't cancel out the performance benefits of the JIT.
- eonil 13y ago
  They're doing that for Quartz. But I doubt what will drive Apple to improve JS performance. Because making people to use Objective-C is a lot beneficial to Apple.
  - mistercow 13y ago
    Interesting. If they're doing it for Quartz, then that pretty much answers the overhead question. I suspect you are right that Apple feels very little motivation to improve support for languages and environments that don't lock you into their system. Or at least, they wouldn't have under Jobs. But I don't think it is true that this strategy is actually more beneficial to Apple. Developers want to support multiple platforms, and the least expensive way to do that is often HTML5. That's why PhoneGap is popular, despite the poor JS performance. The extra cost of doing separate apps is ultimately paid not only by third party developers, but by Apple as well. To make a long story short, encouraging a cross platform environment would allow good developers to make higher quality apps. Much as I dislike Apple these days, the difference between iOS and Android is such that I have trouble maintaining a straight face when I hear them compared. They don't need to compete on app availability.

antimagic 13y ago

More exactly, the kernel does provide a way for applications to mark memory pages as executable (which is exactly what Safari does, after all), but you need to have the right permissions to use the API, and App Store apps don't have those permissions...

edvinbesic 13y ago
Even more exactly, there are ways but if you use them there is no way to publish on the App Store, because private API. There is no reason not to have JIT or WebGL in a WebView other then apple not wanting you to, even though this was the original vision of the platform.