Address Space Copy on Write -- Parent Termination

[pcmattman]

Hi all,

Just been working through address space copy on write in my mind for a few days and the only thing I'm currently really "stuck" on is the circumstance where the original address space owner (ie, the parent) terminates before the child.

In this case, the parent's address space will be cleaned up and the physical pages referring to the child's CoW mapping freed, leaving the system in an inconsistent state.

I keep coming back to the concept of a refcount for physical pages to solve this (ie, only free the physical page if no refcount is present, or if one is present and drops to zero, increment/create on clone). I'm curious to know if there are better alternatives to this, perhaps at a higher level.

Cheers!

[OSwhatever]

In this case, if the parent is terminated before the child then the child should still have that page. I can't see any good reason to remove the page right under the nose of the child process just because the parent dies. That can be solved as you mentioned with a reference count and this is a fully adequate method which is used in several known kernels.

Also, in my design code or data pages are not really associated with the parent process but the executable file. If a code or data page is not present in the physical memory, then it will be loaded from the file in the exception handler. So in this case it doesn't matter in which order and when the processes are terminated.

Are you implementing it "fork way", copying the entire parent address space when creating a new process?

[pcmattman]

Also, in my design code or data pages are not really associated with the parent process but the executable file.

Right, sorry - should have been more clear. This is mostly referring to the memory that is not code/data from an executable file (eg, stacks or heaps). Memory mapped files should already be managed in such a way that the parent terminating doesn't break children.

Right now, if you use say 100 MiB of heap space, and then fork() (for the sake of example, let's say the forked child does not run a process, let's say it's a worker process), you'll end up triggering a clone that does a page-by-page copy of that heap space. CoW would be ideal in that situation, and is more or less implemented aside from handling this particular issue I'm inquiring about. Obviously there's caveats with CoW in such a context that need to be considered, but the high-level concept is still nice.

[Combuster]

I'd also use reference counting mostly because it follows KISS.
CoW can then be implemented as just duplicating the entries to the child, marking both the parent and the child sets as read-only, and when the write actually happens you don't need to leave the address space for a fixup but just allocate a new page, copy, replace the original, decrement the reference count and free if it was the last original.

[sortie]

Perhaps this part of the FreeBSD documentation is of interest to you as it deals with exactly this: http://www.freebsd.org/doc/en/articles/ ... ticle.html