Re: Opportunistic GC

[Pip Cet <pipcet@gmail.com>]

On Mon, Mar 8, 2021 at 3:37 AM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> I've been running with the code below recently to try and see if
> opportunistic GC can be worth the trouble.

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?

Immediate advantage: we'd never mark objects in the "real" Emacs
process, making debugging easier.

My implementation proposal would be to pipe(), fork(), run GC, then
send through the pipe the Lisp_Objects which can be collected by the
original Emacs.

For me, it was a bit difficult to see that this would indeed be safe,
but I'm now pretty convinced it would be: objects that are unreachable
in the child Emacs cannot become reachable in the parent Emacs (they
might show up on the stack, but that's a false positive).

We'd have to be careful not to run two "real" GC processes at the same
time. And, of course, we'd require fork() and pipe(), so I'm not sure
this would work on Windows. Furthermore, if we ever decide to fall
back to doing the real GC in the main process, we must not sweep
objects which were determined to be unreachable by a conflicting
henchman process.

And of course it would mean that we would increase memory usage for
GC, so in low-memory situations, we'd have to fall back to traditional
GC.

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

Pip