Chromium's Transition from Goma to RBE and Siso

This article provides an overview of the Chromium project's migration from its legacy distributed compiler service, Goma, to Google's modern Remote Build Execution (RBE) platform and the Siso build system. It covers the architectural limitations that led to Goma's deprecation, the intermediate step of pairing the Ninja build system with Reclient, and the final deployment of Siso to achieve faster, more scalable builds.

The Limitations of Goma

For years, compiling the massive Chromium codebase relied on GN (Generate Ninja) to create build files, Ninja to orchestrate the build, and Goma to distribute the compilation steps. Goma acted as a compiler proxy, intercepting local C++ compilation commands and sending them to remote servers.

While effective for its time, Goma eventually became a bottleneck for several reasons:

  • Non-Standard Architecture: Goma used a custom, Chromium-specific protocol rather than the standardized Remote Execution API (REAPI) used by modern tools like Bazel.
  • Limited Scope: Goma was primarily designed to accelerate C/C++ and Objective-C compilation. It could not easily distribute other heavy build steps, such as Rust compilation, Java compilation, or complex Python actions.
  • High Maintenance: Maintaining a bespoke backend infrastructure exclusively for Goma was costly and redundant, given that Google had already developed a unified Remote Build Execution (RBE) backend for its internal and cloud ecosystems.

Phase 1: RBE and Reclient

To move off Goma's aging infrastructure without rewriting Chromium’s entire GN-based build configuration, the Chromium team adopted a phased approach. The first step was migrating the backend from Goma to RBE while keeping Ninja as the local build orchestrator.

Because Ninja does not natively speak the Remote Execution API, Google developed a bridge tool called Reclient. Reclient replaced the Goma client on developers' machines and continuous integration (CI) bots.

When Ninja triggered a build step, it called a Reclient wrapper (rewrapper). Reclient analyzed the local files, determined the necessary header dependencies, packaged them, and sent the request to the RBE backend. By late 2023, the Chromium project successfully migrated its bots and developers from Goma to Ninja paired with Reclient, allowing the Goma service to be officially shut down.

The Ninja + Reclient Bottleneck

While Reclient solved the backend infrastructure problem, pairing it with Ninja introduced new local performance bottlenecks:

  • Process Overhead: Ninja had to spawn a separate rewrapper process for every single build action. In a full Chromium build consisting of tens of thousands of actions, this created massive Inter-Process Communication (IPC) overhead.
  • Redundant Dependency Scanning: Because each rewrapper instance ran in isolation, dependency scanning lacked unified state awareness, leading to duplicated effort on the host machine.
  • Local I/O Thrashing: Ninja requires all intermediate build artifacts (like .o object files) to be downloaded to the local disk, even if they are only needed for a subsequent remote step. This saturated local disk I/O and network bandwidth.

Phase 2: Replacing Ninja with Siso

To eliminate the overhead of the Ninja and Reclient combination, the Chromium build team developed Siso (Simple Software), a new build system written in Go that serves as a drop-in replacement for Ninja.

Siso reads the exact same .ninja build files generated by GN, requiring no immediate changes to how Chromium developers write build configurations. However, Siso fundamentally changes how the build is executed:

  • Native RBE Integration: Siso communicates directly with the RBE backend. For many actions, it bypasses the need to spawn external Reclient processes, eliminating IPC overhead and centralizing dependency scanning in memory.
  • Cloud-to-Cloud Execution: Siso minimizes local disk I/O by keeping intermediate files in the RBE cloud cache. If an object file is compiled remotely, Siso does not download it to the developer's machine unless it is explicitly needed for a local step.
  • Broader Action Distribution: Unlike Goma, Siso easily offloads non-C++ tasks—such as TypeScript, Rust, and Android resource processing—to RBE workers, massively parallelizing the build graph.
  • Starlark Configuration: Siso uses Starlark scripts to define how specific build steps are handled remotely, making it easy for build engineers to optimize and fine-tune remote execution rules.

The Result of the Transition

By moving from Goma to RBE, and subsequently replacing Ninja with Siso, the Chromium project unified its build infrastructure with modern cloud standards. The transition removed the maintenance burden of Goma, drastically reduced local CPU and memory consumption during builds, and significantly shortened compile times for both CI bots and individual contributors.