3 ms·

I wouldn't call those policies "stupid", both from a security (a JIT compiler means you can't trust NX bits) and a battery-life/performance standpoint.

yorwba 9y ago
But Apple's JavaScript engine uses a JIT as well, doesn't it?
- pjmlp 9y ago
  Well, one can always advocate that they can validate and secure as much as possible their own JIT compiler, including special OS paths, whereas for 3rd party ones everything goes. Also Microsoft does exactly the same on store apps. Just Google doesn't, because they never bothered to ramp up Java AOT compilation at the store level, rather using everyone's batteries and since that went pretty bad, now they have a mix of interpreted/JIT/AOT.
modeless 9y ago
The security argument is bogus. The benefit over W^X is miniscule. The battery life argument is even more bogus, as JITs are likely to be faster for dynamic languages.
- eropple 9y ago
  The benefit over W^X is that they already have it in place and usable. A JIT, full-stop, is going to consume more battery in the general-purpose mobile case than compiled code will. Break-even points on performance certainly exist but mobile applications don't tend to run for that long. You might be okay with that tradeoff--and it is not an unreasonable one--but Apple does tend to prioritize battery life and performance over developer happiness on their mobile platform. And JIT and garbage collection are both red flags for iOS according to the people I know who've worked on the platform from a performance and a battery-life perspective. "But dynamic languages"--Apple doesn't seem to care about dynamic languages, do they? Aside from JavaScript, which uses their own, tested, internally blessed, JavaScript runtime. Developers might get frothy about that--but iOS is where the users who actually pay for things are.

3 ms·

I wouldn't call those policies "stupid", both from a security (a JIT compiler means you can't trust NX bits) and a battery-life/performance standpoint.

by eropple 9y ago

yorwba 9y ago
But Apple's JavaScript engine uses a JIT as well, doesn't it?
- pjmlp 9y ago
  Well, one can always advocate that they can validate and secure as much as possible their own JIT compiler, including special OS paths, whereas for 3rd party ones everything goes. Also Microsoft does exactly the same on store apps. Just Google doesn't, because they never bothered to ramp up Java AOT compilation at the store level, rather using everyone's batteries and since that went pretty bad, now they have a mix of interpreted/JIT/AOT.
modeless 9y ago
The security argument is bogus. The benefit over W^X is miniscule. The battery life argument is even more bogus, as JITs are likely to be faster for dynamic languages.
- eropple 9y ago
  The benefit over W^X is that they already have it in place and usable. A JIT, full-stop, is going to consume more battery in the general-purpose mobile case than compiled code will. Break-even points on performance certainly exist but mobile applications don't tend to run for that long. You might be okay with that tradeoff--and it is not an unreasonable one--but Apple does tend to prioritize battery life and performance over developer happiness on their mobile platform. And JIT and garbage collection are both red flags for iOS according to the people I know who've worked on the platform from a performance and a battery-life perspective. "But dynamic languages"--Apple doesn't seem to care about dynamic languages, do they? Aside from JavaScript, which uses their own, tested, internally blessed, JavaScript runtime. Developers might get frothy about that--but iOS is where the users who actually pay for things are.