Garbage Collection and gamedev - tl;dr Yes we want it, so let's solve it
rikki at cattermole.co.nz
Mon Nov 23 12:05:14 UTC 2020
On 24/11/2020 12:50 AM, aberba wrote:
> 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.
>> This is the direction I believe our default should be. It covers
>> pretty much all use cases with reasonable performance.
> Can you expand on this?
There isn't much to say.
We already have POSIX support done, just need to implement Windows now.
The basic gist of it is, you want to move the scanning + collecting to a
separate concurrently executed thread. In a fork based model, that uses
another process to do it. On Windows you would use another thread with a
(non-changing) view of the memory of the process.
The reason I say it should be the default is: with multi-core systems
being the default now, adding a dedicated thread for scanning +
collecting isn't all that expensive and it allows to keep the main logic
of the program running without any interruptions to the end user unless
an OOM situation occurs.
But as Ola has said, there are down sides to this approach once you
start needing performance.
More information about the Digitalmars-d