Skip to content

feat(runtime): V8 JIT on Mac Catalyst, with a Catalyst CI lane - #533

Draft
edusperoni wants to merge 5 commits into
mainfrom
feat/catalyst-jit
Draft

edusperoni wants to merge 5 commits into
mainfrom
feat/catalyst-jit

Conversation

@edusperoni

@edusperoni edusperoni commented Oct 30, 2026 •

Copy link
Copy Markdown
Collaborator

Depends on NativeScript/v8-buildscripts#10. This stays a draft until that PR is merged and tagged, and V8_RELEASE here is bumped to the new release.

What

  • Runtime (Catalyst only): before V8::Initialize, the runtime tries one small mmap(MAP_JIT) allocation. If it fails, the runtime passes --jitless. "ios": { "jit": false } in the app's package.json forces the interpreter. iOS is unchanged: its V8 is lite mode, which implies --jitless.
  • Catalyst test lane: TestRunner and its dependencies build for Mac Catalyst (arm64), ad-hoc signed with hardened runtime and allow-jit, like a shipped app. ./run_tests.sh --catalyst runs the suite on the host Mac, and a new test-catalyst CI job does the same on macos-15. CatalystJitTests asserts that V8 holds executable memory, which it only maps with the JIT on.
  • Fixed along the way:
    • The arm64 Catalyst slice was linking Apple's /usr/lib/libffi.dylib. build_libffi.sh had no arm64-maccatalyst slice, so -lffi fell back to the SDK's libffi.tbd, while the runtime compiled against our fork's headers; the published 9.1.0 framework shows this with otool -L. The slice is now built and committed.
    • The metadata generator produced 0-byte metadata in Catalyst builds without failing them. Xcode doesn't export IPHONEOS_DEPLOYMENT_TARGET to Catalyst script phases, so the fix(metadata-generator): emit UIKit metadata for Mac Catalyst #433 fallback raised KeyError. It now falls back to LLVM_TARGET_TRIPLE_OS_VERSION. User Catalyst apps run the same script.

Why the runtime check is needed

V8 doesn't fall back to the interpreter on its own. In a hardened-runtime process without allow-jit (or allow-unsigned-executable-memory), the JIT build dies at its first code allocation; I saw a SIGTRAP at startup in a probe. With the entitlement, or without hardened runtime, the JIT runs.

The app template now grants allow-jit instead of allow-unsigned-executable-memory. Only V8's JIT needs an exception, and libffi closures come from signed trampoline pages: a Catalyst probe calling a closure works under the hardened runtime with no entitlement. Existing apps keep the old entitlement, which also allows MAP_JIT, so they start using the JIT once they pick up this runtime.

Verification

  • Patched V8 Catalyst build (local), in a macabi probe: hot JS runs in 11 ms with JIT vs 385 ms with --jitless, and --trace-opt reports optimizations under ad-hoc, hardened + allow-jit, and hardened + allow-unsigned-executable-memory.
  • iOS simulator suite (./run_tests.sh --temp-sim): 1835 specs, 0 failures, 11 skipped.
  • Catalyst suite: not run locally yet. The macOS UI-test runner needs Automation Mode without authentication (sudo automationmodetool enable-automationmode-without-authentication). GitHub's macOS images ship with it enabled. The Catalyst framework did build and link with the JIT archives (Maglev and TurboFan symbols present).
  • CI: until V8_RELEASE is bumped, the Catalyst job downloads the lite -7 release, so CatalystJitTests is expected to fail there. Everything else in that lane should pass.

Notes

  • TestRunner's Catalyst entitlements include disable-library-validation. Ad-hoc signatures carry no Team ID, so hardened-runtime library validation would refuse the embedded frameworks. This is test-only.
  • --catalyst runs are serialized per Mac with a lock, because XCUIApplication kills any running app with the same bundle ID.
  • The ios.jit key isn't in the @nativescript/core config typings yet.

build_libffi.sh had no arm64-maccatalyst slice, so the Catalyst framework's
-lffi found no archive and the linker fell back to the macOS SDK's
libffi.tbd: the shipped Catalyst slice links Apple's /usr/lib/libffi.dylib
while the runtime compiles against our fork's headers (vector types and the
fork's closure layout included). arm64 macabi has no deployment target
below 14.0, so the slice gets its own minimum.
…ilds

Xcode does not export IPHONEOS_DEPLOYMENT_TARGET to Mac Catalyst script
phases, so the fallback raised KeyError and, since the phase does not fail
the build, left a 0-byte metadata file. Fall back to
LLVM_TARGET_TRIPLE_OS_VERSION, which Catalyst builds always carry.
…JIT memory

Catalyst V8 now ships with Sparkplug, Maglev and TurboFan. A hardened
runtime process may only map JIT memory with
com.apple.security.cs.allow-jit (or allow-unsigned-executable-memory), and
V8 does not fall back on its own, so before V8::Initialize the runtime
probes an mmap(MAP_JIT) allocation and passes --jitless when it fails.
`"ios": { "jit": false }` in the app's package.json forces the
interpreter. iOS is unchanged: its V8 is lite mode, which implies
--jitless.
TestRunner and its dependencies now build for Mac Catalyst (arm64), ad-hoc
signed with hardened runtime and allow-jit like a shipped app, and
`./run_tests.sh --catalyst` runs the suite on the host Mac. A CI job does
the same on macos-15. CatalystJitTests asserts that V8 holds executable
memory there, which it maps only with its JIT on.

The UI-testing runner needs macOS Automation Mode without authentication
(preconfigured on GitHub's macOS images); run_tests.sh checks for it.
@coderabbitai

coderabbitai Bot commented Oct 30, 2026 •

Copy link
Copy Markdown

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

  • Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

…cutable memory

Only V8's JIT needs an executable-memory exception, and allow-jit covers it
(MAP_JIT under the hardened runtime). allow-unsigned-executable-memory is a
broader exception nothing else uses: libffi closures come from signed
trampoline pages and work under the hardened runtime with no entitlement.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant