V8 Snapshot Trade-off: Embedded Code Objects vs. Lazy Recompilation for Cold-Start Latency

When building a V8 embedder that targets sub-50 ms cold-start on constrained devices, the snapshot strategy becomes a primary lever. Including compiled code objects in the heap snapshot eliminates JIT compilation pauses during the first few hundred milliseconds of execution, but inflates the serialized blob by roughly 30–50 percent and ties the artifact to a specific CPU microarchitecture. Excluding code keeps the snapshot small and portable, yet shifts the latency cost to the first invocation of each function, where lazy compilation can produce observable spikes that violate strict startup budgets.

The embedder controls this choice through v8::SnapshotCreator and the SetDefaultEmbeddedBlob flag, but the decision interacts with two hard constraints: the external reference table must be rebuilt identically at deserialization, and the snapshot version is locked to the V8 major release, forcing a full rebuild on every engine upgrade. Neither approach provides built-in integrity verification, so the embedder must add its own checksums or post-deserialization health checks.

Given a fixed startup-latency budget and a requirement to support heterogeneous CPU targets across OTA updates, which snapshot composition strategy minimizes the risk of exceeding the budget while keeping the update payload manageable?

1. Does embedding compiled code for only the hot builtins (via EmbeddedBlob) provide a measurable latency reduction without the full size penalty?
2. How do embedders typically validate snapshot integrity after deserialization in the absence of a V8-provided API?
3. Is there a supported pattern for shipping multiple microarchitecture-specific snapshots and selecting at runtime?