Yes, long-lived objects will go to Gen1 and 2, but by nature of being long-lived they are also allocated much less frequently. I think it's important to unders

Yes, long-lived objects will go to Gen1 and 2, but by nature of being long-lived they are also allocated much less frequently. I think it's important to understand the context of where the discourse on "GC in games" comes from - I mentioned in a sibling comment that a lot of perception, at least from Unity side, comes from the fact that in Unity the GC performs (or had performed in the past) really poorly. And, as another comment mentioned, games written in another popular GC language, Java, have little to no avenue in avoiding allocations where even integer operations can lead to data being heap allocated, and requiring the compiler to do a lot of heavy lifting to avoid doing so with escape analysis and packing integers into (compressed) pointer shadows. Actually, I don't think there is much widespread knowledge on how non-Unity C# performs on its own as a language for both the engine and the scripts, at least here on HN. There are Stride3D (rename from Xenko), Fna, MonoGame (which does not use Mono unlike the name suggests), and probably other I don't know about which use .NET 6/8. I'm not aware of GC related issues for any of these games beyond regular aspects of memory management in games that apply regardless of the platform. Something to look for is Unity's migration away from their custom Mono fork to CoreCLR .NET as it should eliminate most if not all remaining GC related issues. I find this interesting as .NET's GC implementations (both WKS, SRV and SRV+DATAS) have not been made with games in mind, and a more game-optimized and frame-pacing-aware GC implementation could be definitely provided, at the cost of complexity of doing such project.