A separate GC idea - multiple D GCs

[Ola Fosheim Grøstad]

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

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?