Save a process' memory for later use?

Is it possible to pause a process, save the memory contents to a file, and then later reload the file so you can continue the program? Edit I've been reading about this: http://en.wikipedia.org/wiki/Setcontext Is it possible to dump the contents of the struct, and somehow force malloc to allocate the same memory regions?

9 Answers 9

Technically it is possible, but it would require saving all the system-allocated resources state too - like file descriptors for example and then restoring them. So it's a challenging task.

The easiest way to achieve what you want is to use a virtual machine like VMWare. When you pause it you actually save the whole machine state together with all programs running.

@GSerg, that link presupposes that resources outside the process will be released when it's hibernated. That doesn't have to be the case in a situation where the process is just stashed on a do-not-run queue and it's address space sent to disk without relinquishing exo-process resources.

I can envisage this as a simple extension to the UNIX SIGSTOP/SIGCONT - it doesn't relinquish those resources now and it could be changed to swap whole address space to disk. It wouldn't be possible to survive a machine restart but you could achieve the desired effect.

That effect being able to stop and start processes willy-nilly. Of course, you have the problem of a resource being locked while the process is stopped but you could have tools to tell you that (and you would then restart the process to release it).

This is usually called a persistent continuation. Some languages like SmallTalk and SBCL have first class support for persistent continuations. Most languages don't.

Continuations structure the control flow inside a program, they don't stop or start the programs execution.

@sth Some Smalltalk runtimes and SBCL support persistent continuations, rather than just the transient ones you're thinking of.

Depending on your requirements and OS you could try forcing a core dump

I have never tried actually loading a core dumped program back up other than in gdb. It seems like any files you have open or any other state that is not in your programs memory would be lost as sharptooth pointed out.

Another approach would be simply serializing the state you need to disk in your program. It sucks but it is probably the most reliable way unless you are content with suspending execution of the program. That could be done with your operating system's thread library. Or as one poster pointed out with your shell.

Well java has serialization and it comes somewhere near to it. Though you can't do it to the lowest level like CPU registers memory address etc since this will require os to be in same state that was when you 'paused' the process.

This can be a good project as a linux kernel module :-)

It's messy to the point of being impossible when dealing with native code, as sharptooth mentions.

However, some programs (iirc emacs, for instance) have used "dump my own memory" tricks to preserve configuration, instead of dealing with config files. This doesn't work on Windows, though, since executables are run in deny-write share mode. But it's a cute (albeit dangerous) trick on linux or DOS :)

Q. Can you please explain more on how this swap works so that process state will be saved in disk and reuse when required?"

A. It's very simple. The Page file is a special place on a disk where inactive processes are stored in highly optimized way. When such process resumes running, the system automagically reads it back to memory and it just continues from where it was. It is sort of how programs run on iPad :)

All this functionality is already built into Windows. While your process keeps running, the system ensures that it is either in the memory or in the page file (there are few exceptons though, which you can ignore).

In other words, Windows already has the ability to hibernate a process to the page file. @MSalters quote from Raymond Chen "explaining why its impossible" is simply wrong.

Note that the bookkeeping for a paged-out process still exists in RAM (kernel). Its window handles remain valid; you can send it messages which will cause it to page back in, etc. That's why this is generally not considered process hibernation.

Workflow Foundation in .NET 3.0 and higher allows for workflows to be stopped and restarted.

Raymond Chen explains why it's impossible. Obviously, not all Microsoft engineers read this, because the Visual Studio compiler does this when precompiling headers. Its dumps its own state after compiling the headers for the first time, and restores itself to continue.

Mr Chen is right and wrong. It's only impossible if the outside-process resources disappear. This doesn't have to happen. You can stop a process totally while preserving the out-of-process resources - obviously that won't survive a reboot but that's not necessarily what's needed here.

The ability to stop a process totally for an hour while you do some CPU-intensive work is still valuable. Then you just restart that process. SIGSTOP/SIGCONT already does this on UNIX et al.

Actually, for that it's sufficient to lower the priority to idle. No harm in using the last few % of the last core, many parallel algorithms can't sustain full parallelism over the entire operation - especially with trees.

Raymond Chen attempted to explain why it was impossible, however, Cooney refuted all of his arguments.