mold: A Massively Parallel Linker

Abstract: Linking is a critical step in the software build process that combines compiled object files into a single executable or shared library. Despite decades of engineering effort, link times remain a significant bottleneck in the edit-compile-debug cycle, particularly for large C++ programs. Existing linkers exploit limited parallelism, leaving most CPU cores idle during linking. We present mold, a Unix/Linux linker that applies data parallelism systematically across the entire linking pipeline. We first analyze the architectural constraints that prevent existing linkers from scaling, including entangled symbol resolution and archive processing, and then show how a clean-slate design that decouples them overcomes these limitations. On large real-world programs, mold links multi-gigabyte debug binaries in at most a few seconds, and often in under a second. It is 2.4-16.1x faster than the state-of-the-art lld linker, and up to 112x faster than the traditional GNU ld. An ablation study shows that no single optimization dominates; the speedup comes from the cumulative effect of parallelizing all passes.

• The paper presents the creation of mold—a high-performance Unix/Linux ELF linker designed using pervasive data parallelism—achieved through the restructuring of the linking pipeline to operate in parallel on large homogeneous arrays across multiple sections
• On nine large real-world workloads, mold is 2.4 to 16.1 times faster than lld with portable system-level optimizations and up to 112 times faster than GNU ld.
• A blown performance is systematic and comprehensive, not due to a single optimization; the parallel approach ensures all passes benefit from parallel computation without detailed inhibition by sequential dependencies

The paper presents mold, a Unix/Linux ELF linker designed around pervasive data parallelism. Its central claim is that linker performance is limited less by the intrinsic complexity of ELF linking than by architectural decisions inherited from sequential implementations. Existing linkers parallelize selected passes, but retain serial dependencies in symbol resolution, archive extraction, section processing, layout, and output generation. mold instead restructures the complete pipeline so that each major pass operates over large homogeneous arrays—symbols, sections, relocations, strings, or output blocks—with synchronization confined primarily to atomic updates and reduction steps. The paper’s empirical conclusion is correspondingly strong: across nine large real-world workloads, mold is 2.4–16.1 times faster than an lld configuration augmented with several portable system-level optimizations, and up to 112 times faster than GNU ld (2608.23228).

Problem formulation and architectural thesis

Linking is a particularly important build bottleneck for large C++ systems because a single invocation must process millions of symbols, sections, relocations, and debug-information records. The paper gives the example of a TensorFlow debug build containing 24 GiB of object files and producing a 9.9 GiB shared library. On a 64-core machine, lld requires 52 seconds for this link while leaving most cores idle. This workload exposes a mismatch between the data-parallel structure of the input and the predominantly sequential structure of conventional linker implementations.

The paper distinguishes data parallelism from task parallelism. gold attempted to overlap coarse-grained tasks through a dependency-driven work queue, but the dependencies between linker phases frequently serialize the resulting computation. mold instead executes conceptually distinct passes in sequence while parallelizing the work within each pass. This choice retains clear pass-level invariants while exposing parallelism across millions of independent records. The architecture is therefore not based on concurrent execution of arbitrary linker stages; it is based on making each stage amenable to parallel iteration.

The most consequential design decision is the separation of input parsing from symbol resolution. Conventional linkers often resolve symbols while processing each input file and archive, thereby coupling parsing order, archive extraction, and global symbol state. mold eagerly parses all input files and every archive member in parallel, interns symbol names, and only then performs global resolution. This decoupling changes the representation of the problem: symbol resolution becomes a parallel ownership computation over interned symbol objects rather than an order-sensitive side effect of a sequential input scan.

That decision also exposes a compatibility trade-off. ELF specifies object-file format details and some symbol precedence rules, but does not provide a complete normative specification for linker behavior. In particular, interactions involving archive members, shared libraries, duplicate definitions, and linker groups are partly defined by established implementation behavior. mold therefore uses heuristic precedence rules selected to minimize disagreement with traditional linkers rather than claiming formal semantic equivalence. This is an explicit departure from strict GNU ld compatibility, not merely an implementation detail.

Parallel symbol resolution and archive processing

mold represents each interned symbol with an owner field. Input files concurrently attempt to install themselves as the owner of the symbols they define using atomic compare-and-swap operations. A rank ordering determines which definition prevails: strong definitions take precedence over weak definitions, regular object-file definitions generally take precedence over definitions in archives or shared libraries, and common and undefined symbols occupy lower ranks. Ties are resolved according to command-line order.

This mechanism removes the central serialization point in traditional symbol resolution. Once ownership has been established, archive inclusion is determined by a subsequent liveness traversal. Non-archive inputs are initially live; when a live file references a symbol, the traversal follows that symbol’s owner pointer and marks the defining file live. Archive members no longer need to be extracted through a left-to-right, rescan-based process. Circular dependencies can be reached directly through the ownership graph, and --start-group/--end-group are accepted only for compatibility and have no operational effect.

The result is a significant simplification of archive handling, but it is not semantically neutral in every corner case. In the Gentoo compatibility experiment, 19,422 packages were tested. Seventy-four failed to build or pass their tests with mold when GNU ld succeeded; after excluding non-userland software, test suites that reject harmless ELF differences, and unrelated unsupported options, only two failures were attributed to mold’s alternative parallel symbol resolution. Thus, the practical compatibility cost was small in the reported workload, but the experiment also confirms that mold does not implement GNU ld’s behavior exactly.

COMDAT deduplication uses the same general structure. Group signatures are interned, and live files concurrently claim each group using atomic compare-and-swap. Losing copies are discarded. This is particularly important for C++ workloads, where template instantiation and header-defined functions can create millions of duplicate sections. The paper reports that Firefox’s debug build contains approximately 2.7 million COMDAT groups, of which 1.6 million are redundant.

Parallelization across the linking pipeline

The paper’s main technical contribution is not one isolated algorithm but the systematic reformulation of the entire linker pipeline.

Input parsing is parallelized over files. Symbol names are interned using hash bins and thread-local buffers, avoiding a shared concurrent map during the most allocation-intensive portion of parsing. Relocation records are located during parsing but deferred for processing until symbol resolution has completed.

Relocation scanning is a parallel traversal over input sections and their relocation arrays. Each relocation determines whether its referenced symbol requires a GOT or PLT entry. Since the relevant state is monotonic—a symbol transitions from “no entry required” to “entry required”—relaxed atomic bitwise operations suffice. The expensive scan is parallelized, while the much smaller construction of the GOT and PLT remains comparatively inexpensive.

Section garbage collection is expressed as graph reachability. Sections are vertices and relocations are edges; roots include entry points, exported symbols, and sections with special semantics. mold performs the mark traversal with a parallel feeder pattern. This avoids the single-threaded graph walk retained by lld and is especially consequential for fine-grained function and data sections.

Identical Code Folding is implemented as parallel bisimulation-style refinement. Sections are initially colored using their contents, flags, and relocation types. Each iteration hashes a section’s previous identity together with the previous identities of its relocation targets. The process monotonically refines equivalence classes until the number of distinct hashes stabilizes. This is a parallel form of one-dimensional Weisfeiler–Leman refinement, and its use avoids pairwise comparison among candidate sections. Cryptographic hashing makes accidental equivalence from collisions negligibly likely, although the correctness argument depends on the practical collision-resistance assumption rather than on a collision-free mathematical representation.

String merging uses a specialized concurrent hash table. The implementation avoids resizing by estimating the number of distinct strings with HyperLogLog and allocating a sufficiently large table in advance. This is motivated by workloads such as Firefox, where approximately 21 million mergeable strings are present and nearly three quarters are duplicates. The implementation experience is instructive: the general-purpose oneTBB concurrent hash map was inadequate for this workload, so mold uses a workload-specific data structure.

Layout computation is formulated as a hierarchical prefix scan. Sections are divided into groups of roughly 10,000 elements; group sizes and alignment effects are computed in parallel, group offsets are assigned through a much smaller serial scan, and offsets within groups are then computed in parallel. Only the final scan over the small number of output sections remains serial. This pattern removes the need to serialize a prefix computation over millions of sections while preserving alignment semantics.

Range extension thunks

Range extension thunks are one of the more technically distinctive parts of the design. On ARM and PowerPC targets, branch instructions may not encode the displacement to distant targets. A conventional linker lays out the code, inserts thunks for out-of-range calls, and repeatedly rescans relocations because each insertion changes subsequent addresses. This fixed-point procedure is both sequential and potentially repetitive.

mold integrates thunk creation into a linear layout scan. A leading cursor assigns addresses, while a trailing cursor scans relocations within a bounded distance behind it. The distance between the cursors is kept below the branch reach, with a margin for thunk insertion. Because previously scanned calls target addresses below the newly inserted thunk, later insertion cannot invalidate an earlier range decision. Relocations within a batch are scanned in parallel, and entries are deduplicated through atomic per-symbol flags.

The algorithm initially treats calls into other output sections pessimistically as out of range, making each section locally layout-independent. After global layout, mold rescans relocations and removes unnecessary thunk entries. This grow-then-shrink strategy is safe because removing thunks cannot increase branch displacement. The resulting output is close to lld’s despite using a different algorithm: for the ARM64 Firefox debug build, mold emits 19,080 thunk entries versus lld’s 18,896, a difference of roughly 2 KiB in a 282 MiB text segment.

The performance consequences are substantial. On the ARM64 Firefox workload, thunk creation adds 0.07 seconds to mold’s link but 1.01 seconds to lld’s, a 14-fold difference. Even with one thread, mold’s thunk algorithm costs 0.51 seconds versus lld’s 0.92 seconds, showing that the advantage is partly algorithmic. Parallel scanning accounts for the remainder: mold reduces its thunk overhead by approximately seven times at the default thread count, whereas lld’s overhead remains effectively serial.

Output generation, reproducibility, and system-level optimizations

Output generation is naturally parallelized because each input section maps to a disjoint output range. Threads copy section contents and apply relocations directly into a memory-mapped output file. mold also computes the build ID in parallel using a two-level Merkle construction: BLAKE3 hashes 4 MiB output blocks concurrently, after which the block hashes are combined into the final identifier. Hashing a 2.5 GiB Firefox debug output takes 23 milliseconds on the evaluation machine.

Parallel mutation introduces a reproducibility problem. Concurrent string insertion, for example, can yield schedule-dependent pool order and therefore different output offsets. mold addresses this by using commutative atomic operations where possible and canonicalizing results after nondeterministic steps when necessary. The stated guarantee is bit-identical output for fixed inputs, command-line options, and linker version.

Several system-level optimizations reinforce the architectural design. madvise(MADV_HUGEPAGE) reduces output-file page-fault overhead and makes the output-copy pass 3.1 times faster on the Firefox debug workload, reducing the complete mold link from 1.46 to 0.89 seconds. File preallocation with fallocate makes the copy pass 3.5 times faster, from 0.82 to 0.24 seconds. These optimizations are not intrinsically specific to mold, so the evaluation retrofits them into lld. Their end-to-end effects are nevertheless much smaller for lld: huge pages improve lld by 12%, and preallocation by 3.8%, compared with a 39% reduction reported for mold in the corresponding measurements. The implication is a direct application of Amdahl’s law: an optimization to a larger fraction of the remaining runtime has greater end-to-end value, and mold’s parallel architecture reduces the sequential remainder.

The choice of mimalloc improves mold’s Firefox link from 1.15 to 0.89 seconds relative to glibc malloc, a factor of approximately 1.3. jemalloc, tcmalloc, and tbbmalloc perform between these extremes. A custom non-freeing bump allocator is slower than mimalloc and increases peak memory consumption, suggesting that allocator replacement is unlikely to provide a large additional improvement for this workload.

mold also overwrites existing executable outputs in place when safe, avoiding inode replacement and the associated deletion of multi-gigabyte files. This saves approximately 0.3 seconds for the Chromium debug executable. A two-process architecture hides teardown latency from the build system: the parent process has minimal resources and can return promptly once the child closes the output, while the child’s resource reclamation proceeds after the observed link completion. This saves a further 10% in the reported Firefox example. These optimizations are useful in real build systems, but the primary benchmark disables output reuse and the fork-based latency hiding to ensure that linker comparisons measure a common task.

Evaluation and scalability

The evaluation uses nine large open-source programs, with release outputs from 0.15 to 1.21 GiB and debug outputs from 1.00 to 9.91 GiB. The primary machine is a 64-core AMD Threadripper with 384 GiB of memory. The comparison uses mold 2.42.0, lld 22.1.8 with four portable mold optimizations retrofitted, gold 2.46.1, and GNU ld 2.46.1.

On x86-64, mold outperforms retrofitted lld on every measured configuration. The strongest result is the TensorFlow debug build: 3.23 seconds for mold versus 52.16 seconds for lld, or 16.1 times faster. Approximately 30 seconds of lld’s runtime is spent matching two dozen version-script glob patterns against 2.5 million defined symbols sequentially; excluding that workload-specific effect still leaves an estimated sevenfold advantage. Chromium’s debug build takes 1.89 seconds with mold and 13.24 seconds with lld, a sevenfold speedup. Across the other workloads, mold’s improvement ranges from 2.4 to 5.7 times.

The comparison against GNU ld is constrained by compatibility: GNU ld cannot link seven of the eighteen release/debug workload configurations. Where it does link, mold is often tens of times faster, reaching 92.86 seconds versus 0.89 seconds on the Firefox debug build. The paper’s headline claim of up to 112 times faster than GNU ld is therefore supported by the broader reported workload results, but the non-linkable cases mean that the GNU comparison is not uniformly a timing comparison.

Peak RSS is broadly similar between mold and lld. For example, the TensorFlow debug link uses 37.35 GiB with mold and 40.60 GiB with lld. The shared mmap-based I/O model causes resident input and output pages to dominate memory use. mold’s eager parsing of archive members adds comparatively little because it reads symbol and section metadata rather than all member contents. GNU ld often uses less memory because it relies on explicit read and write operations, but this lower RSS accompanies much longer execution times.

The scalability experiment on Firefox is particularly revealing. mold takes 12.18 seconds with one thread, 1.94 seconds with eight threads, 1.19 seconds with sixteen, and 0.90 seconds with 32; it reaches 13.5 times speedup at 32 threads and does not improve at 64. lld falls from 11.44 seconds at one thread to 4.44 seconds at 16 threads, after which additional threads have negligible effect. At one thread, mold is slightly slower than lld, demonstrating that its advantage is not a universal single-thread constant factor. The speedup emerges from the ability to exploit additional cores.

The cost of this scalability is higher CPU consumption. At 32 threads, mold reduces wall-clock time by 13.5 times but uses 73% more cumulative CPU time than its one-thread execution. At 64 threads, CPU time rises from 21.1 to 38.2 seconds without improving the approximately 0.9-second wall-clock result. Hardware-counter analysis attributes this plateau to memory-system saturation: from 32 to 64 threads, mold retires only 9% more instructions but incurs 37% more demand loads served from DRAM. Average sampled memory latency rises from approximately 570 to 1,070 cycles, and IPC falls from 0.85 to 0.53. The default 32-thread cap is therefore not arbitrary; it reflects a memory-bound scaling limit for the evaluated processor and workload.

The ARM64 results establish that the approach is not tied to x86-64, although the relative gains are smaller on a 16-core Apple M1 Ultra. Mold is 1.7–12.6 times faster than lld on that system. The Firefox debug link takes 1.02 seconds with mold and 3.26 seconds with lld. The reduced advantage relative to the 64-core Threadripper demonstrates that the design benefits from abundant parallel hardware and that faster individual cores can narrow the gap against a sequential or partially parallel linker.

Ablation and causal attribution

The ablation study supports the paper’s principal architectural claim: no single optimization accounts for mold’s performance. On the Firefox debug workload, serializing output copy and relocation application increases total time by 542%, from 0.91 to 5.84 seconds. Serializing symbol resolution increases it by 125%, and serializing section garbage collection by 114%. Input parsing adds 52%, string merging 40%, relocation scanning 43%, and build-ID computation 62%.

These percentages must be interpreted alongside pass sizes. Build-ID computation scales by approximately 29 times when parallelized, but its absolute contribution is small. Output generation has a lower relative pass speedup than some other phases but dominates the end-to-end effect because it contains much more work. The evidence therefore favors cumulative pervasive parallelism over a bottleneck-specific optimization strategy.

The per-pass comparison with lld gives the same conclusion from the opposite direction. On Firefox, mold’s parsing and symbol-resolution work takes 0.17 seconds compared with lld’s 1.29 seconds; section garbage collection takes 0.06 versus 0.85 seconds; string merging takes 0.03 versus 0.31 seconds; and output copy takes 0.23 versus 0.50 seconds. Relocation scanning is a notable exception: both linkers take approximately 0.10 seconds. lld’s total is 4.43 seconds compared with mold’s 0.90 seconds, so the 4.9-fold gap is distributed across multiple passes rather than generated by one universal constant-factor advantage.

A particularly important implementation distinction concerns nested parallelism. lld parallelizes across output sections but processes the contents of an individual section serially when invoked inside another parallel loop. This leaves large sections such as .eh_frame_hdr as serial tails. mold’s runtime supports nested parallel-for loops, enabling parallelism both across and within output sections. The result illustrates that “parallelized” is not a binary property: granularity and composition of parallel loops determine whether a pass actually scales.

Limitations and open questions

mold does not implement the full GNU linker-script language. It lacks SECTIONS-based layout control and the MEMORY and OVERLAY commands, excluding important use cases such as Linux kernel development and many embedded systems. Its tested compatibility profile is consequently strongest for userland ELF programs, not for arbitrary linker-script-driven firmware or low-level system software.

The implementation supports ELF only, although the paper argues that its abstractions—sections, symbols, relocations, and archives—are shared by COFF and Mach-O. This portability claim is plausible but not established by the reported evaluation; an earlier Mach-O port was discontinued after Apple’s system linker became substantially faster. The paper also excludes LTO workloads because compiler-side IR processing dominates those links. Consequently, the measured advantage specifically characterizes full native-object linking, especially debug-oriented development builds, rather than end-to-end optimized builds with substantial LTO.

The most important semantic open question concerns the absence of a formal, normative specification for linker behavior. mold’s heuristic symbol-ranking scheme produced only two Gentoo failures attributable to resolution differences, but a repository-scale test cannot establish equivalence across all build systems, linker scripts, or unusual archive interactions. The result leaves open how much of the remaining GNU ld behavior can be formalized and whether a parallel resolution strategy can be made both scalable and specification-preserving.

Finally, scalability beyond 32 threads remains unresolved. The evaluation identifies DRAM latency and random-access pressure as the limiting factors on the Threadripper, while noting that additional memory channels on server processors could change the balance. The paper does not establish whether mold’s metadata layout, scheduling, or synchronization costs become the dominant constraints on such systems.

Conclusion

“mold: A Massively Parallel Linker” (2608.23228) argues that linker parallelism requires architectural separation rather than incremental threading of selected passes. Its decisive intervention is to decouple eager parsing from symbol resolution and to express subsequent computations as data-parallel operations over linker metadata. The evaluation shows that this design scales from one to roughly 32 threads, reduces large debug link times to approximately one second or a few seconds, and outperforms a carefully optimized lld by 2.4–16.1 times across the principal workload suite. The results also establish the cost of the approach: higher CPU consumption, substantial memory traffic, incomplete GNU linker-script compatibility, and a deliberately nonidentical treatment of some underspecified ELF semantics. Within its supported userland ELF domain, the paper demonstrates that comprehensive parallelization of the linking pipeline is both technically feasible and materially more effective than selectively parallelizing isolated phases.