I've just read in Unity's docs that
Unity’s garbage collection – which uses the Boehm GC algorithm – is non-generational and non-compacting. “Non-generational” means that the GC must sweep through the entire heap when performing a collection pass, and its performance therefore degrades as the heap expands. “Non-compacting” means that objects in memory are not relocated in order to close gaps between objects.
Does anyone of You knows or assumes why Unity aborts using standard .Net GC with generations and compacting? I made some tests and i'm really surprised that even objects from LOH are in generation 0 and probably GC's trying to collect them with small objects.
You paid attention to the details, so here comes a story of the details you deserve.
It was in early 2008 that Unity and Mono announced their collaboration, and at that time Unity licensed the Mono runtime (GPL covered for open source usage) so as to embed it. And the Boehm GC was the primary GC in Mono then.
Time passed and Mono 4.x/5.x by default uses SGen GC with generational/compacting features. However, Unity did not want to pay the licensing fees again. Thus, you see the documentation remains it was.
Microsoft acquired Xamarin in 2016, and hence gained control of Mono core assets. It re-published the code base under MIT, and solved the licensing issue for ever. Unity joined .NET Foundation and started to work with Microsoft/Xamarin to incorporate the latest Mono runtime into the game engine.
That effort is still undergoing and should soon reach maturity (currently an experimental feature).
BTW, Unity cannot use the standard .NET GC yet. Microsoft does not open source its GC in .NET Framework, but a version in .NET Core. That GC is different from Mono's, and would require more efforts to be embedded into Unity. I guess that's why Mono 5 was chosen to be integrated right now. Maybe in the future Unity would migrate to the .NET Core GC.
Some of the events can be found in the .NET timeline.