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!