Concurrent GC via `fork` (was: Opportunistic GC)

[Stefan Monnier]

> Just a random idea: What if we exploit the fact most people have more
> than one CPU core these days, garbage-collect in a separate fork()ed
> process, then do only the sweeping in the main process?

Sounds like a good idea.
A concurrent GC which relies on `fork` to take the snapshot.

I don't think we'll be able to always use it, so the synchronous code
path will have to stay, but I think it's definitely worth working on it.

It will probably require moving the markbits out of the objects in order
to work well (which would probably be beneficial in the synchronous GC
case as well), but other than that I'd expect it should be possible to
get pretty good performance out of it in the "normal" case:
- most pages should stay shared between the two processes (because the
  GC process should basically only modify its stack and its markbit
  pages, and the parent process should hopefully not have enough time to
  modify a large fraction of its working set).
- the "normal" case I envision is one where there's a fair bit of extra
  RAM left in the system and a few CPU cores waiting to help Emacs.

> Eli, would this qualify as a "small" GC change, and thus be vetoed?

I like the idea, but its inclusion can't be discussed without
a proof-of-concept patch.


        Stefan