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