Generational online_delete: measured write reduction

What changes

Today. SHAMapStoreImp::run() rotates by copying every live node of the state map into a brand-new backend file, then dropping the old one. The copy is O(total state) and it happens on every rotation, whether or not anything changed — a node that has been cold for a year is rewritten every interval.

With a generation ring. Writes always land in the newest generation; reads walk newest→oldest. When the ring exceeds its budget, the oldest generation is retired: only nodes that are still live and still served by that generation get copied forward, then the whole file is dropped. An evacuated node lands in the newest generation, so it then has to age across the entire ring before it can be touched again — a cold node is re-stored once per budget rotations instead of once per rotation.

Measured write volume

Full matrix

How it was measured

The bench drives the real DatabaseRotatingImp rotation path — advance(), beginRetire(), retireOldest() — against an in-process backend ring, with the production evacuation pattern: a cold working set written once, fresh churn every interval, and a fetch of every live node during each retire window (what visitNodes(copyNode) does). The reported volume is copyForwardCount(): nodes actually re-stored because the retiring generation was the one serving them.

cd build
./xrpld --unittest=xrpl.app.SHAMapStoreBench

• The “Today (full copy)” column is analytic — rotations × cold — because that is definitionally what copying every live node on every rotation costs. The ring columns are measured.
• Wall times come from a debug build on a laptop. They are useful as a relative shape across budgets, not as throughput numbers.
• Retirement count falls as the budget grows (15 → 13 → 9 → 1 over 16 rotations) because a bigger ring has to fill before it can retire anything. That is why a large budget trades disk footprint for writes.
• This is a rotation-path benchmark, not a full-node measurement. It isolates the write volume claim; it does not model NuDB behaviour under real ledger load.