An undo feature built on full-state mementos is consuming too much memory in production. How do you diagnose and reduce the cost while keeping correctness?

## Why full-state mementos blow up memory A memento is, by definition, an **independent (usually deep) copy** of the state needed to restore the Originator. If you snapshot before every change and never discard old snapshots, memory grows as **(history length) × (per-snapshot size)**. For a large document or object graph, this is the classic 'undo eats all the RAM' problem. ## Step 1 — Diagnose Confirm the cause before changing anything: - Take a **heap dump** (e.g. `jmap`, or `-XX:+HeapDumpOnOutOfMemoryError`) and open it in a tool like **Eclipse MAT** or **VisualVM**. Look at the **dominator tree** and **retained size**: an undo stack holding many mementos will show up as the dominant retained set. - Check whether the problem is **too many** snapshots (history unbounded) or **too large** snapshots (each copy is huge), or both — the fix differs. - Watch for a subtle bug: a memento that **accidentally retains references** to live, growing objects (a shallow copy aliasing the Originator's mutable graph) can pin far more than intended — that's a memory leak, not just cost. ## Step 2 — Reduce, by strategy ### A. Bound the history (cap depth) Keep only the last N mementos in a fixed-size structure (ring buffer / bounded deque); evict the oldest when full. - **Pro:** simplest, hard memory ceiling. - **Con:** undo depth is limited to N. ### B. Store deltas instead of full snapshots Record only **what changed** per step (e.g. 'replaced chars 10–14 with "abc"') rather than the entire state. - **Pro:** tiny per step when edits are small. - **Con:** restoring an old state may require replaying/inverting deltas; more complex; this shades into the **Command** pattern. ### C. Immutability + structural sharing If the state is built from **immutable / persistent data structures**, two snapshots can **share** the parts that didn't change; each new memento only adds the modified sub-structure. (This is how persistent collections work — unchanged sub-trees are reused.) - **Pro:** snapshots become cheap and naturally safe (no defensive copies, no aliasing bugs). - **Con:** requires designing state around immutable structures up front. ### D. Spill cold history off-heap / to disk Keep only recent mementos on the heap; **serialize older ones** to off-heap memory or disk, reloading on demand. - **Pro:** large/long histories without heap pressure; serialized mementos persist across runs. - **Con:** serialization cost, I/O latency, and the usual serialization caveats (Serializable, versioning, security of untrusted bytes). ### E. Switch patterns for the right workload For **large state with small, invertible edits**, an **operation log (Command)** undo is fundamentally cheaper than snapshots — store the small operation, not the big state. Consider migrating rather than optimizing snapshots. ## Step 3 — Set policy and verify - Make the **history-size policy explicit** (max depth, max bytes, or time-based eviction) instead of letting it grow unbounded. - **Re-measure** after the change with the same heap-dump/profiler workflow to confirm retained heap dropped and undo still works. - Add a regression guard (e.g. a test asserting the history is bounded) so the fix doesn't regress. ## Cross-cutting correctness notes - Evicting old mementos must not break a memento still referenced by a redo stack — coordinate undo/redo lifetimes. - If you adopt deltas or structural sharing, ensure restore still yields a **byte-for-byte equivalent** state; add tests that save → mutate → restore → assert equality. - Beware the leak variant above: a *shallow* memento that aliases live mutable state both corrupts snapshots and inflates retained memory — fix with proper immutable snapshots.