fork() leaks (?) heap areas

[waddlesplash]

1. Compile attached test program.
2. Run it. Observe that system memory usage climbs +200MB before the fork, as expected.
3. Observe that system memory usage climbs +400MB after the second pair of memory sets.

Changing the SIZ constant shows that the second round of sets will always consume 2x as much memory as expected.

[waddlesplash]

I note that in ProcessController, both processes are supposedly using only 200MB each, but the kernel memory usage increases 200MB. (After the process exits, all memory returns to the way it was before.) Running listarea at each pause point and then diffing the results finds nothing of consequence in the kernel.

[waddlesplash]

Not only is this still a bug, I now notice that swap usage increases by 470MB in addition to main memory usage increasing by 600MB at peak.

[waddlesplash]

So here's what happens:

1. The original application creates a large heap area, it gets filled with pages on memset.
2. The fork occurs. The original heap area's cache becomes a source cache for two new caches, one for each of the child processes.
3. The child processes copy-on-write from the parent cache.
4. The source cache's pages are now fully shadowed by the child caches' pages, but the source cache is still referenced by the child caches so it isn't released.

When either of the processes exits, the caches will be merged and all the "duplicate" pages discarded, but as of now we don't do anything to detect when pages are not needed in this case. Fixing that will be quite tricky.