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

[Paulo Pinto]

On Sunday, 22 November 2020 at 20:20:50 UTC, Ola Fosheim Grostad 
wrote:
> On Sunday, 22 November 2020 at 19:54:14 UTC, Ethan wrote:
>> But yeah, this all comes down to the fact that the runtime 
>> really needs work these days. And to a degree, I imagine 
>> user-provided templates that dictate how code should be 
>> generated is an interesting compiler design paradigm that can 
>> help there.
>
> If you want to mix ARC and GC in the same executable, for high 
> efficiency, you need at least two types of pointers: owning and 
> nonowning, and to break cycles you also need weak pointers 
> (turns to null on destruction) which are useful for speculative 
> caching as well.
>
> The good news is that going from ARC to GC is free and that ARC 
> annotated pointers will collect faster with a precise tracing 
> GC than is the case today. So clearly a win for libraries, 
> either way.
>
> The bad news is that doing ARC in the LLVM IR is nontrivial so 
> you may need a new intermediary typed language specific IR. But 
> you need that to do @live well anyway... So, why not?

Other bad news is that if you don't want the runtime to look bad 
against tracing GC implementations,

https://github.com/ixy-languages/ixy-languages

You need to ship your own CPU with ARC specific improvments,

https://blog.metaobject.com/2020/11/m1-memory-and-performance.html