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
>> 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