A separate GC idea - multiple D GCs
ckatko at gmail.com
Fri Jan 21 13:56:09 UTC 2022
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
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!
More information about the Digitalmars-d