Garbage Collection and gamedev - tl;dr Yes we want it, so let's solve it

Ola Fosheim Grostad ola.fosheim.grostad at gmail.com
Mon Nov 23 08:17:30 UTC 2020


On Monday, 23 November 2020 at 03:15:59 UTC, rikki cattermole 
wrote:
> On 23/11/2020 4:48 AM, Ola Fosheim Grostad wrote:
>> So that means there are only three options left: single 
>> threaded GC pool, non-language GC or ARC.
>
> Concurrent GC (aka fork) and concurrent DS GC with i.e. fork.
>
> We are only missing Windows support for a partially concurrent 
> GC atm.
>
> This is the direction I believe our default should be. It 
> covers pretty much all use cases with reasonable performance.

Fork is expensive in the sense that when the game modifies memory 
the process has to halt while the OS creates a copy of that 
memory page.

You have to be very careful when writing applications that call 
fork, you don't want two processes appending to the same file etc.

It a very special cased soltuion that basically won't work with 
existing c++ codebases without vetting...

More suitable for a high level language where the compiler can 
set up the application for fork.



More information about the Digitalmars-d mailing list