Watching Go's new garbage collector move through the heap

Post by Rohansi » Tue, Jul 28, 2026, 3:10 PM UTC

pjmlp wrote: post #38

bob1029 wrote: post #28

Earlier quoted context omitted.

> 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.

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://devb…

Post by Rohansi » Tue, Jul 28, 2026, 4:03 PM UTC

bob1029 wrote: post #28

Rohansi wrote: post #21

Earlier quoted context omitted.

Can't say I totally agree with the claim that GC is a dealbreaker for games. There are trade-offs either way and games typically need to do things a bit differently to achieve high performance anyway. It is, however, a strong benefit of Godot over Unity because Unity is still stuck with the worst possible GC (Boehm) for the foreseeable future.

> 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.

Post by pjmlp » Tue, Jul 28, 2026, 5:43 PM UTC

Rohansi wrote: post #41

pjmlp wrote: post #38

Earlier quoted context omitted.

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://devb…

> 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 a…

Post by yvdriess » Wed, Jul 29, 2026, 7:19 AM UTC

evntdrvn wrote: post #42

matheusmoreira wrote: post #18

Earlier quoted context omitted.

> then changes one bit on every page in the entire virtual space Yeah that sucks. Naively implemented garbage collectors have the same problem: they put the live and mark bits in the object itself which spreads those bits all over the address space. This leads to the garbage collector touching every single page when it scans and writes all of those bits. The proper solution is to allocate separate bitmap pages. This…

I've always struggled a bit with the fact that "machines want SoA but readability/clarity/etc is easier with AoS". And wonder if it would be possible for a language to have the code representation be AoS but the implementation transparently be SoA.