[bob1029]

> Unity is still stuck with the worst possible GC (Boehm) for the foreseeable future.

How are we measuring "worst possible" here?

Unity's GC is unique in that it has an incremental marking phase. The most important thing in a unity application is frame latency, not raw GC throughput. If you are generating so much garbage every frame that the incremental collector falls behind, that's probably on you.

[Rohansi]

> How are we measuring "worst possible" here?

The garbage collectors used by both .NET and Mono (since 2013) are precise, concurrent, and compacting. They know exactly what memory locations are GC references, scans them while the game is still running, and moves objects in memory to fix fragmentation. Pause times are kept short because heavy work is done on a background that.

Unity's GC is conservative and incremental. It does not know what addresses are GC references so it has to scan everything that could be a GC reference. It's incremental which is nice but means you're expected to trade a few milliseconds of your frame budget for the GC to run. Being conservative means a chunk of your budget is spent scanning memory locations that aren't GC references. By default it uses the time spent waiting for vsync to run but not everyone plays with vsync enabled and lower spec systems have less room there so they end up running worse.

[pjmlp]

A Jurassic GC introduced in Mono, that due to Unity not wanting to pay Xamarin for updates, meant it was mostly frozen in the days of Unity/Xamarin early collaboration.

Unity preferred to go down the route of HPC#, Burst compiler and IL2CPP, and is still maybe one to two years to fully migrate to modern .NET.

Meanwhile in Redmond, Mono is almost gone, with CoreCLR already in preview for mobile platforms,

https://devblogs.microsoft.com/dotnet/dotnet-maui-moves-to-c...

Capcom's RE engine also uses their own fork CoreCLR, customised for consoles, Devil May Cry for PS 5 uses it.

[Rohansi]

> Unity preferred to go down the route of HPC#, Burst compiler and IL2CPP, and is still maybe one to two years to fully migrate to modern .NET.

They're replacing Mono with CoreCLR in Unity 7 which is Q1 2027. Somehow they're also doing this with no breaking changes too - even though they previously announced breaking changes due to the obvious differences between the two runtimes.

Also, they have already said there are no plans to change the GC used by IL2CPP builds so it will keep using Boehm.

[pjmlp]

Yeah, but will they deliver this time?

Apparently the team has been affected multiple times during the various layoffs.

Unity has been both a blessing for .NET adoption on the games industry, and also pain, given that many equate .NET with their Unity experience.

[Rohansi]

I have my doubts! I work on Rust (the video game) and we're excited to see how much better performance will be on CoreCLR. However, we were confused by the switch from "Mono replaced with CoreCLR with these breaking changes Unity 6.8" [1] to "Mono replaced with CoreCLR with no breaking changes in Unity 7 [2], with Unity 6.8 off the roadmap [3]".

[1] https://discussions.unity.com/t/path-to-coreclr-2026-upgrade...

[2] https://unity.com/releases/unity-7

[3] https://unity.com/roadmap

[pjmlp]

I guess fingers crossed, then. :)

[needlesslygrim]

> Unity's GC is unique in that it has an incremental marking phase.

Does ZGC not also have an incremental marking phase?

[mibsl]

Also, the default collector, G1, introduced more than 15 years ago. Most JVM GCs are concurrent, too.