A separate GC idea - multiple D GCs

[rikki cattermole]

On 22/01/2022 2:56 AM, Chris Katko wrote:
> So a related question: Has anyone ever thought about "thread-local 
> garbage collection" or some sort of "multiple pool [same process/thread] 
> garbage collection"? The idea here is, each thread [or thread 
> collection] would have its own garbage collector, and, be the only 
> thread that pauses during a collection event.

Indeed we have thought about this.

What I want is a fiber aware GC and that implicitly means thread-local too.

But I'm not sure it would be any use with the existing GC to have the 
hooks, it would need to be properly designed to take advantage of it.

> Because while an "iterative GC" requires... an entire new GC.

The existing GC has absolutely horrible code.

I tried a while back to get it to support snapshotting (Windows specific 
concurrency for GC's) and I couldn't find where it even did the scanning 
for pointers... yeah.

https://github.com/dlang/druntime/blob/master/src/core/internal/gc/impl/conservative/gc.d

After a quick look it does look like it has been improved somewhat with 
more comments since then.



What we need is a full reimplementation of the GC that is easy to dig 
into. After that, forking, precise, generational should all be pretty 
straight forward to implement.