regions have generations. its the same concept just partitioned to make the working sets smaller.
there isn't anything fundamentally wrong with golangs GC. attempting to apply the solutions for the JVM to golang is fundamentally flawed and ignorant.
the languages have fundamentally different approaches to memory allocations. and the reasons behind the JVM implementations simply do not exist in golang.
> attempting to apply the solutions for the JVM to golang is fundamentally flawed and ignorant.
I'm not saying that Go should use GCs like Java's. I'm just saying that Go's GC does not work well enough for Go's needs, and that Java's GCs now deliver a better experience. Maybe Go needs something entirely different, but it does need something better than what it has now.
there isn't anything fundamentally wrong with golangs GC. attempting to apply the solutions for the JVM to golang is fundamentally flawed and ignorant.
the languages have fundamentally different approaches to memory allocations. and the reasons behind the JVM implementations simply do not exist in golang.
the new pacer is in the works to attempt addressing many of the edge cases. https://github.com/golang/proposal/blob/master/design/44167-...
you seem to lack fundamental understanding of what the actual issues in the golang runtime are with relation to its GC.