A separate GC idea - multiple D GCs

Ola Fosheim Grøstad ola.fosheim.grostad at gmail.com
Sat Jan 22 12:39:44 UTC 2022

On Saturday, 22 January 2022 at 11:27:39 UTC, Ola Fosheim Grøstad 
> On Saturday, 22 January 2022 at 11:06:24 UTC, rikki cattermole 
> wrote:
>> We already have forking, and that is super useful for getting 
>> user threads to not stop.
> Well, but I would never use it. Forking is crazy expensive. 
> Messes with TLB and therefore caches IIRC.

Here are some downsides of a forking collector:

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

2. will hog extra threads, thus if your program is using all 
cores, you will see a penalty

3. requires a reduced activity in pointer mutation in the main 
program, so the forking collector has to saturate the databus in 
order to complete quickly, which is bad for the main process

4. requires carefulness in configuring OS resource handling

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

6. makes it more difficult to coordinate with real time threads 

7. not really portable, platform dependent

A forking collector is just not suitable for system level 
programming, it is very much a solution for a high level 
programming language running on hardware with lots of headroom.

If you are going high level, you might as well introduce write 
barriers for pointer mutation.

More information about the Digitalmars-d mailing list