[silisili]

Well, I don't love that reported performance regressions are handwaved away as not the new gc, but doing something wrong or abnormal.

Will wait for more real world cases showing substantial improvements, but existing(and possibly bad) code exists and it shouldn't be blamed for regressions.

[zozbot234]

I didn't see anyone "handwaving away" performance regressions in the thread. The closest was a special case where a Golang program was auto-tuning caching decisions based on heap size metrics, and this led to an apparent regression due to the improved metrics w/ the new GC leading to excessive caching. That's hardly the common case!

(In general though, if you take the authors' concerns about the increased future impact of memory bandwidth and memory non-locality seriously, the obvious answer is "don't use GC in the first place, except when you really, really can't avoid it. And even then, try to keep your object graphs as small and compact as possible wrt. memory use; don't have a single "tracing" phase that ends up scanning all sorts of unrelated stuff together." Of course this is unhelpful if you need to work w/ existing codebases, but it's good to keep in mind for new greenfield projects!)