Hacker News Reader

Comment by mmebane | Hacker News Reader

Sadly, Apple removed the JIT support in 14.4, so not even sideloaded apps can use it any more.

https://twitter.com/altstoreio/status/1354096048650809349

Unfortunate but I was surprised Apple looked like they where changing it at all since it would lessen security allowing some common attack vectors.

I haven't followed it for some time however, it does look like V8 supports a JITless mode now which allows it to possibly be used on iOS and other platforms with NX set, albeit with significant performance loss:

https://v8.dev/blog/jitless

Looks like JavaScriptCore still disables JIT when run in a non entitled app. Always thought they might figure out a way to at least let their own JS engine JIT since its trusted in Safari on the open web, but I believe its an all or nothing thing for the process/app and not per module thing.

JavaScriptCore could use a daemon process with elevated privileges that does the JIT-ting and then shares back the executable memory pages with the sandboxed process. It's simply a matter of Apple wanting to curb React Native because it threatens their control over app development.

You can run JavaScript out of process with the JIT through WKWebView.

Which is fine if you're doing an HTML UI (PhoneGap) since the DOM and JS engine share the same process. If you're doing a native UI with JS then it must marshal cross process to affect the UI then you have to decide which is worse, no JIT or cross process overhead.

Yep, that's pretty much what I've described, and it is the reason why I'm certain that there's no technical limitation at play here. Apple just chose to not allow this for political/strategic reasons.

Out of process mean a loss in performance itself due to marshaling cross process calls and data. When your dealing with UI orchestration its probably better / faster to run an interpreter with no cross process overhead than a JIT with the overhead. Think Web Workers which have similar issues, you have to keep your communication with worker chunky for good performance.

You're misunderstanding what I've described. Only the JITting would occur in a separate process. The sandboxed app would give the JS code to the JITter daemon, then the JITted code would be mapped to the address space of the sandboxed app, where it would run just as if it was part of the native app binary. There's no marshalling other than sending JS code to the JIT daemon.

Yes I did misunderstand and that may work to get around the NX restriction being per process it would probably be a significant change to the JIT architecture in order for it to work out of process. This also would probably have security implications since it looks like old MS Edge did this for mitigation and Google found possible exploits: https://googleprojectzero.blogspot.com/2018/05/bypassing-mit...

Reply on news.ycombinator.com