Re: Concurrent GC via `fork`

[Stefan Monnier]

> And I do want to mention weak hash tables: they're a problem, because
> they can resurrect unreachable objects.

Indeed, weak pointers require special attention to handle them correctly
with concurrent GCs.  But nothing insurmountable.

> Worse, while normal weak-key-strong-value hash tables only resurrect
> objects when you maphash, weak-value hash tables can do so for gethash
> as well, so that code path would become more expensive

I think it can be made "cheap enough".

> and more difficult to translate into native code.

I don't know what this has to do with native code.

>> but I think it's definitely worth working on it.
> I've got it working for conses, I think (as a proof of concept,
> synchronously, with an extra waitpid()).

I think a real proof of concept is one where the GC is never
run synchronously.

> Apart from hating threads and loving processes, I love nice levels,
> and I think this would be a good use case for them. For example, I
> hear there's a new CPU out there that has two separate sets of cores
> for "efficiency" and "performance", and it would be great if Emacs ran
> an "efficiency" garbage collection in the background rather than a
> "performance" garbage collection synchronously.

To the extent that the GC normally only uses less than 50% of the CPU
time, indeed we don't need it to run as fast the main thread.
More generally, the OS scheduling of the GC process should focus on
maximizing throughput rather than minimizing latency.


        Stefan