Google Chrome, Mozilla Firefox, In-Depth Software Architecture

 

---

Google Chrome: In-Depth Software Architecture

---

1. Overall Design Philosophy

• Focus on security, stability, and performance.

• Uses a multi-process architecture to isolate different components for robustness.

• Modular components with clearly defined responsibilities.

• Heavy use of sandboxing and OS-level protections.

---

2. Multi-Process Architecture

• Browser Process:

  • Runs the UI, tab management, history, bookmarks.

  • Manages the lifecycle of all other processes.

  • Responsible for security enforcement, such as sandboxing and permission management.

  • Manages user profiles and persistent storage (cookies, cache).

  • Implements the UI thread and IO thread for responsiveness.

• Renderer Processes:

  • Each tab gets its own renderer process (or shared if site isolation is disabled).

  • Runs Blink rendering engine and V8 JavaScript engine.

  • Executes all page scripts and layout computations.

  • Sandboxed to limit access to the OS and file system.

  • Maintains its own DOM, CSSOM, and JS heap in-process.

• GPU Process:

  • Handles all GPU-accelerated rendering, compositing, video decoding.

  • Isolated to prevent GPU driver crashes affecting the browser.

  • Manages hardware-accelerated graphics pipelines like OpenGL, DirectX, Vulkan.

• Network Process:

  • Handles HTTP/HTTPS requests, TCP/UDP sockets.

  • Implements caching, cookie management, and proxying.

  • Enforces network security policies and privacy features (e.g., Do Not Track, Tracking Prevention).

  • Decouples network IO from UI and rendering for performance.

• Utility Processes:

  • Audio, extension hosts, PDF renderer, and plugin processes.

  • Sandboxed and separated for security and fault tolerance.

---

3. Rendering Engine: Blink

• Forked from WebKit, Blink is the core layout and rendering engine.

• Parses HTML, CSS, SVG, and builds the DOM tree and render tree.

• Implements:

  • Style system: CSS cascade, inheritance, computed styles.

  • Layout system: Calculates box sizes, positioning, and flow.

  • Painting system: Converts render tree to visual pixels.

  • Compositing: Uses layers to manage overlapping elements, accelerated by GPU.

• Supports complex features:

  • Web Animations, CSS Grid/Flexbox, WebRTC, WebGL.

  • CSS Paint API and Custom Properties.

---

4. JavaScript Engine: V8

• A high-performance JavaScript engine with:

  • Interpreter for initial bytecode execution.

  • Baseline JIT compiler for optimized bytecode.

  • TurboFan optimizing compiler for machine code generation.

• Implements advanced memory management:

  • Generational garbage collection.

  • Precise heap snapshots and profiling.

• Integrates with Blink for DOM manipulation and event handling.

---

5. Inter-Process Communication (IPC)

• Uses Mojo IPC, a message-passing framework built on Platform Channels.

• Supports asynchronous communication between:

  • Browser process ↔ Renderer process.

  • Renderer process ↔ GPU process.

  • Browser process ↔ Network process.

• IPC ensures strict separation while allowing coordination (e.g., input events forwarded to renderer, resource requests, compositor updates).

---

6. Security Model and Sandboxing

• Sandboxes renderer and utility processes at OS level:

  • On Windows, uses Job Objects, Restricted Tokens, and AppContainer.

  • On Linux, uses setuid sandbox, namespace isolation, and seccomp-bpf filters.

  • On macOS, uses sandbox profiles enforced by the OS.

• Limits renderer’s file system, network, and system call capabilities.

• Uses Site Isolation to ensure each site runs in a separate process.

• Extension processes run with least privilege and with permission constraints.

---

7. Storage Systems

• Uses LevelDB for indexed storage and caching.

• HTTP cache stores responses on disk in a format optimized for quick lookup.

• Cookies are managed with strict partitioning per profile.

• Implements Quota Management API for controlling local storage, IndexedDB, and Cache API.

---

8. Process Lifecycle and Resource Management

• Browser process monitors child processes and can terminate/restart if they crash.

• Implements OOM (Out-of-memory) handling by killing least important processes.

• Uses tab discard and freezing to conserve memory.

---

Mozilla Firefox: In-Depth Software Architecture

---

1. Design Philosophy

• Focus on flexibility, open standards, and user control.

• Uses multi-process architecture (Electrolysis/e10s) but more conservative than Chrome.

• Emphasizes modularity and extensibility.

• Uses Rust language components to improve safety and performance.

---

2. Process Model

• Parent (Main) Process:

  • Handles UI, window management, session restore.

  • Coordinates all content processes.

  • Manages history, bookmarks, extensions, and preferences.

  • Responsible for network requests (also uses separate network threads).

• Content Processes:

  • Multiple content processes for tabs, but fewer than Chrome (configurable via dom.ipc.processCount).

  • Each process runs Gecko rendering engine, SpiderMonkey JavaScript engine.

  • Sandboxed to isolate web content from main process.

• GPU Process:

  • Dedicated process for compositing and GPU acceleration.

• Extension Process:

  • Runs extensions separately with restricted access.

---

3. Rendering Engine: Gecko

• Gecko is a monolithic engine that handles parsing, layout, rendering, and compositing.

• Major components:

  • Parser for HTML, XML, CSS, SVG.

  • Styling system: CSS cascade, inheritance.

  • Layout engine: Calculates box models, flow, positioning.

  • Rendering: Paints the content into layers.

  • Compositing: Uses layers for GPU acceleration.

• Supports complex layout models, accessibility features, and internationalization.

---

4. JavaScript Engine: SpiderMonkey

• Includes:

  • Baseline interpreter.

  • IonMonkey JIT compiler for highly optimized machine code.

  • Garbage collector with incremental and generational collection.

• Provides debugging APIs and embeds in various Mozilla projects.

---

5. IPC: IPDL (IPC Description Language)

• Firefox uses IPDL, a custom IPC framework designed specifically for Firefox.

• Supports asynchronous, bi-directional message passing between processes.

• Facilitates communication between parent and content processes for resource loading, DOM updates, event dispatch.

---

6. Security and Sandboxing

• Uses OS-level sandboxing:

  • Windows: Uses AppContainer, restricted tokens.

  • Linux: Uses seccomp, namespaces.

  • macOS: Uses sandbox profiles.

• Sandbox restricts filesystem, network, and system access of content processes.

• Implements Site Isolation (Project Fission) incrementally to isolate cross-site iframes.

• Extensions run with limited privileges using WebExtensions APIs.

---

7. Storage

• Uses SQLite for cookies, history, and bookmarks.

• IndexedDB and Cache API backed by LevelDB.

• Strict quota and storage policies enforced.

• Supports offline web storage, service workers.

---

8. Process and Memory Management

• Parent process tracks health of content processes.

• Uses OOM killer to reclaim resources.

• Implements tab suspension and freezing techniques.

• Uses Rust components (e.g., Servo's style system) to improve memory safety.

---

Comparative Summary

Feature	Google Chrome	Mozilla Firefox
Rendering Engine	Blink (fork of WebKit)	Gecko
JavaScript Engine	V8	SpiderMonkey
Multi-process Model	Aggressive: one process per tab/site	Moderate: fewer content processes
IPC	Mojo IPC	IPDL (custom)
Sandboxing	OS-level sandboxing + site isolation	OS sandbox + ongoing site isolation (Fission)
Storage Backend	LevelDB (cache, IndexedDB), custom SQLite for history	SQLite + LevelDB
GPU Handling	Separate GPU process	Separate GPU process
Extensions	Sandboxed, permission-based	Sandboxed, WebExtensions API
Security Focus	Strict site isolation and sandboxing	User control and evolving site isolation
Performance	Optimized for speed, low latency	Balanced speed with modularity and safety

---

-X-

---

1. Deep Explanation of Blink’s Rendering Pipeline Internals

• Parsing: Blink starts by parsing HTML and CSS to build the DOM tree and CSSOM tree respectively.

• Style Computation: Combines DOM and CSSOM to calculate computed styles for each element.

• Layout: Calculates geometry and positions elements in the viewport, generating a render tree.

• Painting: Converts the render tree into paint commands, which are organized into layers.

• Compositing: Layers are composited using GPU acceleration, allowing efficient rendering and animations.

• The pipeline is incremental and optimized for reflows and repaints to minimize work.

• Uses layers and raster threads to offload work from the main thread and improve responsiveness.

---

2. SpiderMonkey’s JIT Compilation Strategies

• Interpreter: Executes JavaScript bytecode initially.

• Baseline JIT: Quickly compiles frequently executed code into machine code with minimal optimization.

• IonMonkey Optimizing Compiler: Uses advanced static and dynamic analysis to generate highly optimized machine code.

• Employs type inference, inline caching, and speculative optimization.

• Includes garbage collection integrated with the JIT to manage memory efficiently.

• Uses deoptimization to fallback to interpreter if assumptions fail.

---

3. Detailed Security Architecture for Sandboxing

• Uses OS-level sandboxing to isolate renderer/content processes with restricted privileges.

• On Windows: Uses AppContainer, Restricted Tokens, Job Objects.

• On Linux: Uses namespaces, seccomp-bpf filters, and user IDs.

• On macOS: Enforced through sandbox profiles.

• Sandboxing limits file system, network access, system calls, and inter-process communication.

• Implements Site Isolation to ensure different websites run in separate processes to prevent cross-site data leakage.

• Extensions and plugins run in separate, tightly controlled processes with minimal permissions.

---

4. Internal Storage Mechanisms and Data Structures

• Uses LevelDB (a fast key-value store) for browser cache, IndexedDB, and service worker storage.

• SQLite databases manage cookies, history, bookmarks, and settings.

• Storage is partitioned by profile and site, with strict quota enforcement.

• Implements efficient LRU caches to manage in-memory data and disk persistence.

• Storage APIs abstract the physical storage backend and provide transactional semantics to web apps.

---

-X-

---

1. Deep Explanation of Blink’s Rendering Pipeline Internals

Parsing Phase

• HTML Parser:

  • Tokenizes the HTML input stream into tags, text, comments.

  • Builds the DOM tree incrementally.

  • Handles scripts synchronously: pauses parsing for script execution, which can modify DOM.

• CSS Parser:

  • Parses CSS stylesheets into the CSSOM tree (CSS Object Model).

  • Resolves @import rules and inline styles.

• Both DOM and CSSOM are maintained separately for flexibility.

Style Computation

• Combines DOM nodes with CSS rules to compute computed styles.

• Applies cascading, specificity, inheritance, and default values.

• Generates style contexts that attach to DOM nodes.

Layout Phase

• Takes the styled DOM tree and calculates the geometry:

  • Box sizes (width, height).

  • Positioning (static, relative, absolute, fixed).

  • Flow layout (block, inline).

• Creates the Render Tree, a tree of visual elements used for painting.

• Handles reflow when content or styles change, using incremental layout to limit recalculation.

Painting Phase

• The render tree is traversed to generate paint commands.

• These commands describe drawing operations (fill, stroke, images, text).

• Paint commands are grouped into layers.

Compositing Phase

• Layers are composited in GPU using the compositor thread.

• Enables optimizations like layer caching, hardware acceleration, and smooth animations.

• Supports partial repainting and GPU rasterization for performance.

Optimizations

• Lazy layout: layout only when necessary.

• Paint invalidation: only repaint affected regions.

• Layer promotion: promotes complex elements (like fixed or animated elements) to their own layers.

---

2. SpiderMonkey’s JIT Compilation Strategies

Interpreter

• Executes JavaScript bytecode directly.

• Used for initial execution and fallback cases.

Baseline JIT

• Quickly compiles frequently executed bytecode into machine code.

• Minimal optimization for fast startup and reasonable performance.

• Tracks type information and records type feedback for later optimization.

IonMonkey Optimizing Compiler

• Uses an SSA (Static Single Assignment) intermediate representation.

• Performs aggressive optimizations:

  • Inlining: replaces function calls with function body.

  • Type specialization: generates type-specific machine code.

  • Constant folding, dead code elimination, loop unrolling.

• Uses speculative optimization:

  • Compiles optimized code based on runtime assumptions (e.g., variable types).

  • If assumptions fail, triggers deoptimization to interpreter or baseline JIT.

Garbage Collection Integration

• Implements generational GC: separates young and old objects to reduce pause times.

• Supports incremental and concurrent GC to minimize impact on responsiveness.

• Works closely with JIT to track live references and avoid premature deallocation.

---

3. Detailed Security Architecture for Sandboxing

OS-Level Isolation

• Windows:

  • AppContainer sandbox: restricts process capabilities (file, registry, network).

  • Uses Restricted Tokens to drop unnecessary privileges.

  • Controls process job objects to limit CPU/memory usage.

• Linux:

  • Uses seccomp-bpf filters to whitelist allowed syscalls.

  • Employs namespaces (PID, network, mount) to isolate processes.

  • Drops privileges using setuid to a low-privilege user.

• macOS:

  • Uses Seatbelt profiles to specify fine-grained access control.

Site Isolation

• Runs renderer processes per site or origin.

• Ensures same-origin policy enforced at process boundaries.

• Prevents cross-site scripting or data leakage via process isolation.

Extension Sandboxing

• Extensions run with limited APIs.

• Permissions are explicitly requested and verified.

• Runs extensions in separate processes or isolated threads to reduce attack surface.

Additional Security Layers

• Content Security Policy (CSP): limits resources loaded by websites.

• Safe Browsing: blocks malicious URLs.

• Process privileges: renderer processes lack direct access to filesystem or OS APIs.

---

4. Internal Storage Mechanisms and Data Structures

LevelDB Usage

• Key-value storage optimized for fast read/write.

• Used for:

  • HTTP cache (stores response bodies, headers).

  • IndexedDB and Cache API backend for web applications.

  • Service worker storage.

• Organizes data in sorted string tables (SSTables) and uses write-ahead logging for durability.

SQLite Usage

• Manages structured relational data:

  • Cookies.

  • Browsing history.

  • Bookmarks and session data.

• Supports ACID transactions.

• Uses WAL (Write-Ahead Logging) mode for concurrency and crash recovery.

Storage Partitioning and Quotas

• Storage is partitioned by user profile and origin to prevent cross-site data leaks.

• Quota managers enforce limits per origin for IndexedDB, localStorage, and Cache.

• Implements LRU eviction strategies for cache pruning.

In-Memory Caches

• Uses RAM-backed caches for fast access to frequently used data.

• Employs cache invalidation and synchronization with persistent storage.

Data Structures

• B-Trees in SQLite for indexing.

• Hash maps and tries in LevelDB for fast lookups.

• Transaction logs and checkpoints for crash consistency.

---