[笔记] Unity的未来，是固守Mono，还是拥抱CoreCLR？

2010年9月，Mono2.8发布，带来了新的分代式GC：SGen；支持 C#4；支持 .NET 4.0。2013年7月，Mono3.2发布，SGen取代Boehm成为默认的GC。2015年4月，Mono4.0发布，开始集成 .NET Core；支持 C#6。2017年5月，Mono5.0发布，开启了concurrent SGen；使用Roslyn编译器；支持 C#7。2019年9月，Mono6.4发布，支持 .NET Standard 2.1；支持 .NET 4.8。

Unity has been and is still relying on the Boehm GC, which is a conservative (stack-root) GC. The link above doesn't go into some details like how managed objects on the stack are collected by the GC, but basically: a conservative GC will scan the entire stack of all managed threads to "pin" memory referenced by it. Because of this blind scan, it can bring false pin, because it can interpret an integer value, as a pointer to a region of the heap memory, while it was really an int in the first place. By doing so, a conservative GC can start to block some objects from being collected (or worse for a moving-generational GC, to relocate objects). Otoh, a precise GC is able to scan precisely stack-roots and report only pointers that actually point to heap memory. In order for a precise GC to work, the (JIT) codegen needs to be GC aware, which is the case for CoreCLR.

先尽量分配好所有对象的内存，然后关闭GC，等到合适的时机（如关卡结束），再开启GC；默认开启 incremental 模式分帧处理，注意如果在期间有大量引用关系的改写，分帧处理反而会有大量额外性能损耗（主要来自写屏障）

首先集成最新的Mono，因为其支持 .NET Core 的BCL；然后将自家的 IL2CPP 也更新（其依赖Mono的输出结果）；支持 .NET Standard 2.1（特别是Span，Range），虽然Unity此时依然基于 .NET Framework，但利用最新的Mono可以不依赖 .NET Framework实现；支持 C#8/9，基于前面的工作，这一步并不难；支持 .NET 6（跳过 .NET 5）。但有两大难题：

所有dll必须重新编译； 要修改 UnityEditor 中大量使用 AppDomain进行hot reload的部分（AppDomain在新版.NET中几乎被废弃，出处）；目前的替代类 AssemblyLoadContext 并不能提供之前 AppDomain Reload的所有功能。

In general Assembly Load Context is cooperative, and any remaining references (static fields, GC Handles, running threads, etc) will prevent the code from being unloaded.