To recover in normal Smalltalk, you revert to a known good image, and then roll forward changes from the Changes file, ideally not executing that last bit that

To recover in normal Smalltalk, you revert to a known good image, and then roll forward changes from the Changes file, ideally not executing that last bit that killed it in the first place. I would think this would be challenging a world where you have a single, very large, persistent image (at least as naively presented as I have). You have no "known good" image to revert to. For this use case, there is no "file system". Just the living image -- and it's big, ostensibly larger than RAM. So, rather, you'd want something like the write-ahead log in databases, but one that you can roll back through a primitive restart process to a known good point. This is why I mentioned CouchDB which versions all of its page writes making recovery from catastrophe possible (at a not small cost of garbage collection). And, I appreciate the difficulty. Imagine simply having a thread tracking a real time clock. Every second a page gets persisted to the disk...tic tic tic. 86000 pages a day, just "sitting idle". Or does it? Maybe pages never get persisted to disk until snapshot or swapped out. (And since you have stupid amounts of memory, swapping is rare). Anyway, just musing.