Mojo IPC: Why Chromium Replaced Its Legacy System

This article provides a comprehensive overview of the Mojo inter-process communication (IPC) system used in the Chromium web browser and explains the technical reasons why it replaced the older legacy IPC architecture. It covers the fundamental mechanics of Mojo, the severe limitations of the previous C++ macro-based system, and how transitioning to Mojo significantly improved browser performance, security, and cross-language compatibility.

What is the Mojo IPC System?

Chromium uses a multi-process architecture to keep the browser secure and stable. Tabs, extensions, the GPU, and the main browser interface all run in separate isolated processes. Because these processes cannot directly share memory, they need an Inter-Process Communication (IPC) system to talk to one another.

Mojo is Chromium’s modern IPC system. It is a collection of runtime libraries and bindings generators that facilitate message passing across different processes. Instead of just being a way to send raw data, Mojo provides a platform-agnostic way to create communication channels, share memory buffers, and wrap platform-specific handles (like file descriptors on Linux or handles on Windows).

At the heart of Mojo is two main components:

  • Message Pipes: A bidirectional communication channel. Two endpoints are created as a pair, and what is written into one endpoint can be read from the other, regardless of whether those endpoints are in the same process or different processes.
  • Mojom IDL: An Interface Definition Language (IDL) used to define the structure of messages. Developers write a .mojom file, and the Mojo compiler automatically generates the necessary communication code in C++, Java, and JavaScript/TypeScript.

The Flaws of Chromium’s Legacy IPC

Before Mojo, Chromium used a custom system simply referred to as "Legacy IPC." As the browser grew more complex, Legacy IPC became a major bottleneck for several reasons:

  • Reliance on C++ Macros: Legacy IPC used complex C++ preprocessor macros to define messages. These macros were notoriously difficult to read, hard to debug, and significantly slowed down compile times.
  • C++ Lock-in: Because the system was built on C++ macros, it only worked in C++. On Android, where the UI is written in Java, or in Chrome's settings pages, which are written in JavaScript, developers had to write tedious "glue code" to translate C++ IPC messages into other languages.
  • Hub-and-Spoke Bottleneck: Legacy IPC only allowed point-to-point communication between a child process (like a web page renderer) and the main browser process. If a renderer needed to talk to the GPU process, it often had to route messages through the main browser process first, creating unnecessary delays.
  • Rigid Process Model: Legacy IPC assumed a fixed architecture where certain features always lived in the main browser process. It did not allow components to easily move between processes.

Why Mojo Replaced Legacy IPC

Chromium engineers developed Mojo to solve the exact limitations of the legacy system, fundamentally changing how the browser operates internally.

1. Dynamic Routing and Pipe Passing

The most powerful feature of Mojo is that you can send a message pipe over another message pipe. The main browser process can create a new pipe, send one end to a renderer process, and send the other end to the network process. Those two processes can now communicate directly with zero involvement from the main browser process. This eliminated the hub-and-spoke bottleneck and dramatically increased performance.

2. Multi-Language Support

Because Mojom IDL automatically generates bindings for C++, Java, and JavaScript, developers no longer need to write manual translation layers. A WebUI page written in TypeScript or an Android feature written in Java can communicate directly with a C++ backend process using the exact same Mojo interface.

3. The "Servicification" of Chromium

Mojo enabled Chromium to transition into a service-oriented architecture. Massive systems like networking, audio, and storage were broken out of the main browser process into isolated "services." Because Mojo message pipes work the exact same way whether the endpoints are in the same process or different processes, Chromium can dynamically adjust how it runs. On a powerful desktop, the Audio Service can run in its own isolated process for stability. On a low-memory Android phone, the exact same Audio Service can run inside the main browser process to save RAM, without changing a single line of communication code.

4. Improved Security Auditing

In a browser, IPC boundaries are the primary line of defense against hackers trying to escape the sandbox. Legacy IPC macros made it difficult for security teams to track where data was coming from and how it was validated. Mojom files provide a clear, strongly-typed contract of every message that can cross a process boundary. Mojo also forces developers to use specific data validation traits, ensuring untrusted data from a compromised web page is sanitized before the browser process ever touches it.