3 ms·

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 alloc

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.

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.