A separate GC idea - multiple D GCs (page 3) - D Programming Language Discussion Forum

On Friday, 21 January 2022 at 13:56:09 UTC, Chris Katko wrote:

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.

Instead of segregating GC by execution contexts like threads or fibers, I think it makes more sense to separate it by task instead.

When making the most of multiple cores you try to limit synchronizations to tasks boundaries anyway. So a task itself basically runs isolated. Any memory it burns through can basically be dropped when the task is done.

Of course the devil is in the details, but I think it is more promising than segregating by execution context.

On 23/01/2022 4:14 AM, Sebastiaan Koppe wrote: > Instead of segregating GC by execution contexts like threads or fibers, I think it makes more sense to separate it by task instead. For my proposal, I may call it a fiber, but in reality it can just as easily be a task. The only difference is one has a dedicated stack, the other does not.

On Saturday, 22 January 2022 at 12:39:44 UTC, Ola Fosheim Grøstad wrote: > Here are some downsides of a forking collector: > 1. messes with TLB, wipes all caches completely (AFAIK). Probably likely to evict some stuff, but I don't see why you would lose everything. > 2. will hog extra threads, thus if your program is using all cores, you will see a penalty It probably isn't using all threads, though. > 5. if you actually are out of memory, or close to it, then there is no way for you to fork, so it will fail and the process will instead be killed You can fall back to regular gc if fork fails (and I think the fork gc does this). > If you are going high level, you might as well introduce write barriers for pointer mutation. I agree with your other critiques, and I agree with this.

January 22, 2022

Re: A separate GC idea - multiple D GCs

Posted by Ola Fosheim Grøstad
in reply to Elronnd

Permalink

Ola Fosheim Grøstad

Posted in reply to Elronnd

Permalink

On Saturday, 22 January 2022 at 16:45:02 UTC, Elronnd wrote:

On Saturday, 22 January 2022 at 12:39:44 UTC, Ola Fosheim Grøstad wrote:

Here are some downsides of a forking collector:

messes with TLB, wipes all caches completely (AFAIK).

Probably likely to evict some stuff, but I don't see why you would lose everything.

If you change the TLB, then affected address ranges should in general be flushed although maybe this is too pessimistic in the case of a fork. I don't know the details of what different CPU/MMU hardware implementations require and how various OSes deal with this.

But both the fork and the COW page copying that will occur when the process writes to memory pages after the fork hurt.

You can fall back to regular gc if fork fails (and I think the fork gc does this).

Good point, but if you succeed with the fork in a low memory situation then you are in risk of being killed by Linux OOM Killer. Maybe only the GC collector will be killed since it is a child process, or how does this work?

So what happens then, will D detect this failure and switch to a cheaper GC collection process?

On Saturday, 22 January 2022 at 19:43:33 UTC, Ola Fosheim Grøstad wrote: > If you change the TLB, then affected address ranges should in general be flushed although maybe this is too pessimistic in the case of a fork. I assume you would only lose TLB, not cache.

Forums