4 ms·

So still an extremely slow mark & sweep with stop the world. No compaction, not moving. Mark & sweep is only really useful for external references, but golang

• zozbot234 1y ago
  Golang GC is mostly concurrent, not stop-the-world. There's a tiny STW pause at the end of the 'mark' phase that could in principle be avoided, but it's not a huge issue wrt. performance.
  • rurban 1y ago
    Thanks. Missed that
• Mawr 1y ago
  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 1y ago
    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.