A separate GC idea - multiple D GCs

[Chris Katko]

So I was going to ask this related question in my other thread 
but I now see it's hit over 30 replies (!) and the discussion is 
interesting but a separate topic.

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.

Basically, you cordon off your memory use like you would with say 
a memory pool, so that when a GC freezes it only freezes that 
section. Smaller, independent sections means less freeze time and 
the rest of the threads keep running on multiple core CPUs.

There are obviously some issues:

  1 - Is the D GC designed to allow something like this? Can it be 
prevented from walking into areas it shouldn't? I know you can 
make malloc non-system memory it "shouldn't" touch if you never 
make pointers to it?

  2 - It will definitely be more complex, and D can be too complex 
and finnicky already. (SEGFAULT TIME.) So patterns to prevent 
that will be needed. "Am I reading in my thread, or thread 37?"

  3 - Any boundary where threads "touch" will be either a 
nightmare or at least need some sort of mechanism to cross and 
synchronize across said boundary. And a frozen thread, 
synchronized, will freeze any reads by non-frozen threads. 
[Though one might be able to schedule garbage collections only 
when massive reads/writes aren't currently needed.]

I think the simple, easiest way to try this would be to just 
spawn multiple processes [each having their own D GC collector] 
and somehow share memory between them. But I have no idea if it's 
easy to work around the inherent "multiple process = context 
switch" overhead making it actually slower.

As for the "why?". I'm not sure if there are huge benefits, mild 
benefits, benefits in only niche scenarios (like games, which is 
the kind I play with). But I'm just curious about the prospect.

Because while an "iterative GC" requires... an entire new GC. 
Splitting off multiple existing D garbage collectors into their 
own fields could maybe work. [And once again, without benchmarks 
a single D GC may be more than fast for my needs.] But I'm 
curious and like to know my options, suggestions, and people's 
general thoughts on it.

Thanks, have a great day!