You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#224 bounds the iOS JIT metadata leak by relaunching the host app on memory pressure. That is the only portable reclaim today, but it costs a full-screen flash and @State loss. This issue tracks reclaiming the leak in-process so no relaunch is needed.
Why the leak exists
Each structural edit JIT-links a fresh generation whose __swift5_proto/__swift5_types (and ObjC class) metadata is registered with the runtime. The Swift runtime appends those records to an append-only global scan list with no unregister API at any visibility (confirmed via nm on iOS 26.2 libswiftCore), and the records point into that generation's __TEXT/__const. So the code pages can never be freed safely. Proven: ExecutionSession::removeJITDylib frees the memory but crashes in _objc_map_images on the next link (dangling runtime pointers). Measured growth ~1.4 MB per structural edit.
Candidate avenues (none free; ordered by practicality)
Reduce/strip per-generation metadata. Use swiftc reflection levers (-disable-reflection-metadata, -reflection-metadata-level none) and/or skip registering __swift5_types for the thunk. If nothing in the runtime holds a pointer into a generation's code, removeJITDylib becomes a safe in-process reclaim. Load-bearing unknown: SwiftUI likely needs the View protocol conformance registered, and that conformance record re-pins the code. Gating measurement (skipped in iOS JIT: relaunch host on memory pressure to reclaim leaked metadata (#221) #224's Phase 0): metadata-vs-code attribution per generation. Bounded experiment: strip, measure per-edit growth, confirm the preview still renders and stays interactive.
Ship a patched Swift runtime with an unregister function. Most thorough, least portable (ABI/version/loading across user toolchains and sim runtimes).
Surgically mutate the runtime's private conformance/type scan lists from our process. Research-grade, fragile, version-specific.
If avenue 1 works, the host relaunch from #224 can be retired (or kept only as a backstop).
Follow-up to #221 / #224.
#224 bounds the iOS JIT metadata leak by relaunching the host app on memory pressure. That is the only portable reclaim today, but it costs a full-screen flash and
@Stateloss. This issue tracks reclaiming the leak in-process so no relaunch is needed.Why the leak exists
Each structural edit JIT-links a fresh generation whose
__swift5_proto/__swift5_types(and ObjC class) metadata is registered with the runtime. The Swift runtime appends those records to an append-only global scan list with no unregister API at any visibility (confirmed vianmon iOS 26.2libswiftCore), and the records point into that generation's__TEXT/__const. So the code pages can never be freed safely. Proven:ExecutionSession::removeJITDylibfrees the memory but crashes in_objc_map_imageson the next link (dangling runtime pointers). Measured growth ~1.4 MB per structural edit.Candidate avenues (none free; ordered by practicality)
swiftcreflection levers (-disable-reflection-metadata,-reflection-metadata-level none) and/or skip registering__swift5_typesfor the thunk. If nothing in the runtime holds a pointer into a generation's code,removeJITDylibbecomes a safe in-process reclaim. Load-bearing unknown: SwiftUI likely needs theViewprotocol conformance registered, and that conformance record re-pins the code. Gating measurement (skipped in iOS JIT: relaunch host on memory pressure to reclaim leaked metadata (#221) #224's Phase 0): metadata-vs-code attribution per generation. Bounded experiment: strip, measure per-edit growth, confirm the preview still renders and stays interactive.If avenue 1 works, the host relaunch from #224 can be retired (or kept only as a backstop).