Forked GC explained

Steven Schveighoffer schveiguy at
Sat Sep 3 14:31:31 UTC 2022

On 9/3/22 9:35 AM, frame wrote:
> I'm not sure I fully understand how it works. I know that the OS creates 
> read only memory pages for both and if a memory section is about to be 
> written, the OS will issue a copy of the pages so any write operation 
> will be done in it's own copy and cannot mess up things.
> But then is the question, how can memory be marked as free? The forked 
> process cannot since it writes into a copy - how it is synchronized then?
> Is the GC address root somehow shared between the processes? Or does the 
> forked process communicate the memory addresses back to the parent?

It definitely communicates back to the parent. I'm not sure the 
mechanism, either shared memory or a pipe.

The information communicated back is which blocks can be marked as 
unreferenced, then the sweep is done in the original process.

> Are freeing GC operations just locked while the forked process is running?

I'm not sure, but I would think it's possible not to. Only during the 
freeing of the blocks does it need to lock the GC.

> What happens if a manually `` is called while the forked 
> process marks the memory as free too but the GC immediately uses the 
> memory again and then gets the notification to free it from the forked 
> child? Can this happen?

No, because if you can free it, you should have had a reference to it 
when you forked, which should mean it's not garbage.

There's a talk on it from the 2013 dconf by the inventor:


More information about the Digitalmars-d-learn mailing list