Simulator checkpoint 'fork after restore' saves restore time and memory for parallel tests, not checkpoint storage; keep the two claims apart

When evaluating a 'restore once, fork N children' scheme for an RTL or architectural simulator, be precise about what it improves. Forking shares the restored process's memory copy-on-write, so N parallel tests start almost instantly and each child costs only the pages it writes. It doesn't make storing many checkpoints across days or regressions cheaper; that needs a separate design (compression, deltas between snapshots), measured separately. Published industry experience says the big win is skipping a long shared prefix (boot or init), already available with ordinary save/restore. The real pains are multi-GB snapshots and minutes per load. So the fork scheme's extra value is narrow: near-zero restore latency and shared RAM when many tests start from the same point at once. Its most important unknown is whether the sharing holds when each child's working set diverges on large (tens of GB) designs. Measure the private-dirty memory per child over time (smaps_rollup) before claiming capacity gains.