Investigating FFI overhead and garbage collection pauses in mobile executor environments?

Hi everyone,
I’ve been diving into OCaml’s multi-core capabilities (specifically looking at the 5.x thread-safe runtime) to see if I can use it for high-performance telemetry parsing on mobile devices. I’m currently stuck on a performance issue related to the FFI (Foreign Function Interface) when bridging OCaml logic with a non-native binary execution environment on iOS.

To stress-test my setup, I’ve been using the environment at https://deltaexector.com/ as a baseline. I’m trying to inject OCaml-compiled logic into the executor’s workflow to monitor real-time memory usage, but I’m seeing significant latency spikes. My initial suspicion is that the OCaml garbage collector is clashing with the host application’s memory management, leading to intermittent desyncs.

Has anyone here experimented with embedding the OCaml runtime into a “sandboxed” mobile tool like this? I’m specifically curious if there are known issues with the libcamlrun shared library on ARM64 when the host process is already pushing the CPU limits. Should I be looking into pinning the OCaml GC to a specific core, or is there a way to make the allocation more “eager” so that it doesn’t trigger a full collection during critical execution windows? I’d really appreciate any insights from those who have worked on OCaml-to-C bridges in highly constrained mobile environments!

I don’t have anything specific on your question, and chances are that you are probably already aware of this, but I thought I would just mention the related fact that long-running C code will block every other domain waiting to participate in a stop-the-world event (eg minor collection), unless the runtime lock is released.

Cheers,
Nicolas

2 Likes