Hey linker, can you spare a meg?

Tailscale’s iOS VPN runs as a Network Extension, which can use only about 15 MB of memory - far less than a regular iOS app. When the extension exceeds that limit, iOS may terminate it and interrupt VPN access. Its baseline use was already 10-12 MB, leaving little room for features or for users with large networks. The team first reduced allocations through profiling and code changes, then made Go’s garbage collector more aggressive. Running with GOMAXPROCS=1 also helped: it reduced thread costs and limited the allocator’s per-CPU memory slabs. Other allocator changes saved memory but seemed too fragile to adopt, and these runtime and code-level measures did not solve the problem.

The key insight came from examining the memory iOS actually counts, rather than relying only on application-level usage. A memory report showed a 13 MB footprint, with a large share attributed to VM_ALLOCATE and another substantial portion to DATA_CONST. That category contains data made read-only after the operating system applies relocations to support position-independent executables. Although constant afterward, relocated pages are marked dirty and count toward the process’s footprint. The investigation therefore shifted from shrinking Go’s runtime allocations to reducing the executable’s relocations. A script that modeled the binary’s relocations matched iOS’s memory accounting, giving the team a concrete way to study whether linker changes could reclaim some of the scarce memory.