Garbage Collection and gamedev - tl;dr Yes we want it, so let's solve it
pjmlp at progtools.org
Mon Nov 23 11:54:24 UTC 2020
On Sunday, 22 November 2020 at 20:20:50 UTC, Ola Fosheim Grostad
> 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,
You need to ship your own CPU with ARC specific improvments,
More information about the Digitalmars-d