On Sunday, 1 August 2021 at 14:43:47 UTC, evilrat wrote:>
What this means in practice - it should be possible to go full OOP crap for game simulation using lightweight classes without any hiccups even with GC enabled, but all asset data should be handled differently and taken out of GC scannable heap to avoid long pauses.
I'm kind of skeptical towards tracing GC for games. Think of thousands of objects, usually of the same type. These objects are often full of references to other objects and they often points to each other as there might be some relation.
This is a lot of memory, that is also scattered around in the memory. Scanning these will take time. For this type of objects I would go for a pool that is outside GC. Also how the reference each other could be solved by reference counting in order to minimize memory leaks. Other suggestions is that object references each other using a hash table. This rolling identifier/hash lookup is often used in operating systems (file handles for example) as pointers cannot be used in order to distinguish a resource.
Often memory management in games kind of falls outside the convenience of GC as the demand is so special, not only because of performance but also when it comes to data structures.