Re: Opportunistic GC

[Matt Armstrong <matt@rfc20.org>]

Pip Cet <pipcet@gmail.com> writes:

> 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.

Hi Pip,

Neat idea.

Are there examples of other GC implementations using this approach?
Perhaps this has been tried before, elsewhere, and we could learn a lot
from that.

I looked for myself and found
https://dlang.org/blog/2019/07/22/symmetry-autumn-of-code-experience-report-porting-a-fork-based-gc/
which talk about this idea in the context of the D run time.  This page
mentions a different idea: doing the mark pass with multiple threads.
This might be worth exploring; the two ideas are composable with
each other.

Matt