[compiler-rt] [llvm] [ORC][MachO] Use a per-graph compact-unwind dso_base (PR #208931)

[Yaxing Cai via llvm-commits]

cyx-6 wrote:

Sure, happy to share our downstream usage and get official guidance from upstream.

We are building [tvm-ffi-orcjit](https://github.com/apache/tvm-ffi/tree/main/addons/tvm_ffi_orcjit): a small Python extension that loads compiled object files (`.o`) at runtime through ORC JIT v2. The objects are mostly GPU kernels behind the tvm-ffi ABI, e.g. via FlashInfer, CuTeDSL, and similar. `init/fini` matters because these objects run real static initializers — e.g. CUDA runtime setup happens in a constructor — so **`initialize()`/`deinitialize()` is a hard requirement** (that's what motivated #175981); we also need **compact-unwind** for C++ exceptions across JIT frames. **No ObjC/Swift, in-process only**. Modules are small — **well under ~100 MB, nowhere near 4 GB** — and it's **one JITDylib per module**, so a per-JITDylib slab far below 4 GB would suit us perfectly.

On the memory model, since that's the crux of your question: our `JITLinkMemoryManager` is a **pool per ExecutionSession, shared by all JITDylibs** — a growable pool of 64 MB slabs, not a fixed per-JITDylib reservation. It `mmap`s an additional slab whenever a graph doesn't fit, so **multiple independent `mmap`s** back a single JITDylib. (Linux only today; macOS is still on the default `InProcessMemoryManager`, which also `mmap`s each graph separately. Our goal is one shared slab manager across both, but we're not there yet.)

The consequence is that as soon as there's more than one `mmap`, their relative placement is up to the OS — a later graph can land **below the JITDylib header**, and the shared-header compact-unwind base **underflows its unsigned `uint32_t` delta**. So the risk is present **whenever a JITDylib spans more than one reservation**, purely from address randomness; it **isn't about distance** (it fires even a few KB below the header). The **per-graph base** removes that dependency — each object's base is the lowest address within its own graph, so deltas stay non-negative regardless of how the reservations land.

Hope this helps your planning — we'd welcome your guidance on the memory-allocation model you'd like clients to target, and we're happy to align with it.


https://github.com/llvm/llvm-project/pull/208931