Snapshotting in ERD-TSVM

Snapshotting in ERD-TSVM

A Faster Way To Start a Runtime

ERD-TSVM is built around a custom TypeScript-to-bytecode toolchain and a custom runtime/VM that runs across multiple targets. In that kind of system, startup work matters. Before a program can do useful work, the runtime may need to execute module top-level code, build objects, wire prototypes, resolve imports, and register internal state.

Snapshotting exists to avoid repeating that setup when the resulting state is stable and reusable.

In ERD-TSVM, a snapshot is a captured image of a pre-initialized runtime heap after top-level initialization has completed. That image is embedded into the ERD1 container as a dedicated `SNAPSHOT` section. On a later run, the runtime can restore that heap directly instead of executing `$bundled_init` again.

This is not just generic serialization. The snapshot system is designed specifically for runtime startup. The snapshot format stores runtime state without raw pointers, encodes runtime-owned references symbolically, and validates compatibility against the runtime and the bytecode before restoring. If a snapshot is unavailable or rejected, ERD-TSVM falls back to the normal initialization path.

How It Fits the Platform

Snapshotting is part of the architecture, not an afterthought. The bundler can build and embed a snapshot, the runtime loader can restore it, and the runtime API exposes `setMain()` so programs can separate one-time setup from per-run work.

That separation is important. Top-level code can build the state that should be captured once, while the function registered with `setMain()` still runs on every invocation. In practice, that makes snapshotting a good fit for workloads that spend real time constructing reusable runtime state before doing their actual job.

The current codebase already wires this into the self-hosted compiler flow, and the same model is used for tooling-oriented workloads where startup cost is visible to developers.

Why It Matters

Startup latency matters, especially in developer tooling.

Even when total execution time is acceptable, repeated initialization makes systems feel slower than they need to. Faster startup improves perceived speed, and perceived speed directly affects how responsive a tool feels in daily use.

That matters for CLI-oriented workflows, compile-and-run loops, and tooling that repeatedly creates fresh runtime instances. When reusable state can be restored instead of rebuilt, the platform spends less time redoing the same work and more time getting to the task the developer actually asked for.

Fast feedback loops improve productivity because they reduce waiting between intent and result.

A Practical Building Block

For ERD-TSVM, snapshotting is a practical runtime mechanism for reducing repeated startup cost while keeping execution semantics consistent. It helps turn expensive initialization into a build-time or one-time step, and it remains an important building block for future tooling and deployment flows across the platform.