WebAssembly Runtime Architecture: Loading, Parsing, Execution, Memory Management and GC

1. Introduction

WebAssembly (Wasm) is a portable, compact binary format standardized by the W3C. Beyond the narrow definition of a binary format, the broader WebAssembly ecosystem includes the runtime, compilation toolchains, and high‑level languages that target Wasm.

2. WebAssembly Runtime Architecture

The runtime consists of a module loader ( WasmLoader ) that loads, decodes, validates, and links Wasm binaries, a set of runtime data areas (global space, function space, table space, and linear memory), and an execution engine that interprets or JIT‑compiles bytecode.

3. WebAssembly Parser

3.1 Module Loading and Decoding

Wasm modules are encoded as a sequence of sections, each representing a component such as types, functions, or code. The loader parses the binary according to the formal grammar, populating the runtime data areas.

3.2 Module Validation

After loading, the validator checks that the module conforms to the type system. The Validation Algorithm walks the opcode stream once, ensuring each instruction respects its type constraints.

3.3 Instantiation

During instantiation, the runtime creates concrete objects for functions, globals, tables, and memory, resolves imports (e.g., "env.print" ), and links them into the module's address space.

4. Execution Engine

4.1 Stack Interpreter

Wasm uses a zero‑address, stack‑based instruction set. Most instructions pop operands from the stack, compute a result, and push it back, enabling simple verification and fast execution.

void foo() {
    int a = 1;
    int b = 2;
    int c = (a + b) * 5;
    return c;
}

The corresponding Wasm text format is:

(module
  (type (;0;) (func (result i32)))
  (func (;0;) (export "foo") (type 0) (result i32)
    (local i32 i32 i32)
    i32.const 1
    local.set 0
    i32.const 2
    local.set 1
    local.get 0
    local.get 1
    i32.add
    i32.const 5
    i32.mul
    local.tee 2
    return))

4.2 Linear Memory Management

Wasm provides a contiguous, byte‑addressable linear memory. The default page size is 64 KB. Memory can be grown with the memory.grow instruction, and is sandboxed from the host process.

LLVM’s wasm‑ld linker lays out the linear memory into four regions: static data, BSS, stack, and heap. The layout can be altered with the --stack-first option.

// Fix the memory layout of the output binary.
void Writer::layoutMemory() {
  uint32_t memoryPtr = 0;
  auto placeStack = [&]() {
    memoryPtr += config->zStackSize;
    auto *sp = cast<DefinedGlobal>(WasmSym::stackPointer);
    sp->global->global.InitExpr.Value.Int32 = memoryPtr;
  };
  if (config->stackFirst) {
    placeStack();
  } else {
    memoryPtr = config->globalBase;
  }
  // ... (omitted for brevity)
}

4.3 Garbage Collection (GC)

Current Wasm lacks built‑in GC, relying on manual allocation (e.g., malloc / free ) or external allocators. The GC proposal adds reference types, struct / array primitives, and instructions such as struct.new , enabling automatic memory management and safer inter‑language interoperability.

5. WebAssembly System Interface (WASI)

WASI defines a portable, sandboxed API set (file I/O, networking, clocks, randomness, etc.) that allows Wasm modules to run outside browsers while preserving security. It is modular, starting from wasi‑core and extending with additional proposals.

6. Conclusion

The article has examined Wasm module loading, parsing, execution, linear memory layout, emerging garbage‑collection mechanisms, and the WASI system interface, highlighting that while Wasm 2.0 expands capabilities, many advanced features remain under active development.