[Mawr]

Holy buzzwords. There's no such thing as the GC design, just like there's no the car engine design that's suitable for every vehicle in existence. The right GC design is one that fits the language it's designed for.

Therefore, if you have reason to believe those qualities are a good fit for a Go GC, it'd be great if you could go into detail as to why instead of just throwing out buzzwords left and right.

I'm not a GC expert, but as far as I know, compaction isn't needed because due to various Go-isms, there's not much fragmentation happening. No reason to constrain a design for a feature that won't give much benefit.

[rurban]

I was wrong in my initial thoughts on the Go GC design. Apparently they improved it in the last years a bit. Still not state of art by far.

Esp. compaction is their latest "improvement", just implemented backwards, in the sweep phase. Now a moving collector is already compacting, no need to optimize for it to detect it in the sweep phase when the copying GC already puts them together.

No buzzwords, sorry. Simple technical concepts the Go people still don't get. Compaction is always needed, because that's the biggest run-time win in all environments. Cache misses.