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

[rikki cattermole]

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.