> And it’s probably higher than you think.

Possibly, but the question is does it negate the need for a generational GC? Judging by Go's poor GC performance compared to Java -- it doesn't.

> This has nothing to do with on-stack structure, it has to do with Go not using C-compatible stacks

Sure, but any user-mode thread implementation will not be using C-compatible stacks (if it wants to be efficient). Java doesn't use C-compatible stacks yet it doesn't take the hit Go does.

> GC complexity impacts its cost and performances. Generational GCs have more overhead than non-generational ones.

But in this case (ZGC) it doesn't come at a cost.

> And that is what the go team observed on many workloads when they experimented with making Go’s GC generational.

Go's GC is several generations behind the GCs in Java. It is also isn't compacting. Java had such a GC -- CMS, which served the JDK well for many years -- until the next generation (G1) and the next-next generation (ZGC) were developed, at which point it made little sense to keep a non-moving collector.