freenode/#clim - IRC Chatlog
Search
16:52:28
nyef
Orthogonal persistence really is the wrong term, isn't it? The typical implementations, and explanations, are all VM-state persistence. It's "orthogonal" to user programs because the VM implementor does all the work. An "image-based environment" for a programming language does this without the automatic snapshots, and in many cases without actually preserving thread state (in some cases outright disallowing a state-save with more than
16:53:39
nyef
And doing this for a single address space out of an entire system means that you lose any IPC connections (including open files) across a save, and foreign code access is iffy at best.
16:55:19
nyef
So, the two points here are that you can't do VM-state persistence well without doing it across the entire system, and that as soon as you want data to survive the loss of your VM-state you need to consider persistence again.
17:06:12
nyef
This also puts VM-state persistence as being less necessary than other forms of persistence (because the other forms are still necessary, while VM-state persistence is "merely" nice-to-have). But there's also a potential interaction problem, in that you can be trying to restore a VM-state that's slightly older than the state of other persistence mechanisms.
17:07:09
nyef
And this also damages some of the utility claims for "orthogonal persistence": We're expecting that the VM-state might have to be erased every so often for various reasons, which is directly counter to the promises of orthogonal persistence.
17:53:39
beach
nyef: It is late here, and I'll be spending time with my (admittedly small) family, but I'll read and contemplate what you wrote tomorrow morning (UTC+2).