Hacker News new | ask | show | jobs
by cafxx 183 days ago
There's a bunch of activity ongoing to make things better for memory allocation/collection in Go. GreenTeaGC is one that has already landed, but there are others like the RuntimeFree experiment that aims at progressively reduce the amount of garbage generated by enabling safe reuse of heap allocations, as well as other plans to move more allocations to the stack.

Somehow concluding that "By killing Memory Arenas, Go effectively capped its performance ceiling" seems quite misguided.

1 comments

That one is kind of interesting given the past criticism of Java and .NET having too many GCs and knobs.

With time Go is also getting knobs, and turns out various GC algorithms are actually useful.

Not sure what you are referring to. There are no knobs involved in the things I mentioned (aside from the one to enable the experiment, but that's just temporary until the experiment completes - one way or the other).
The knobs are the values that can be given to GOGC environment variable.

Also I kind of foresee they will discover there are reasons why multiple GC algorithms are desired, and used in other programming ecosystems, thus the older one might stay anyway.

Your previous message was referring to Go "getting" knobs, but GOGC has always been there.

The older GC algorithm won't stay, IIRC the plan is for it to be removed in 1.27 (it's kept for now just to give a fallback in case of bugs in the first release).

GOGC was introduced in Go 1.5, and I thought the problem was solved.

https://go.dev/blog/go15gc

> Go 1.5’s GC ushers in a future where stop-the-world pauses are no longer a barrier to moving to a safe and secure language. It is a future where applications scale effortlessly along with hardware and as hardware becomes more powerful the GC will not be an impediment to better, more scalable software. It’s a good place to be for the next decade and beyond.

> GOGC was introduced in Go 1.5

yes, that's quite literally what I meant by "GOGC has always been there". 1.5 was released 10 years ago, just 3 years after 1.0.

So to summarize: there is one knob (that has been there from basically the beginning), plus a second one (if you squint hard enough: GOMAXMEM), and absolutely no plans to add further ones, or to add alternative GCs.

That past criticism was and is correct, proven by the fact new Java GCs like ZGC were deliberately designed to offer few knobs.

Go isn't getting any new knobs, there are only two; that's nothing compared to 100's of options that old Java GCs had. Completely incomparable.

> and turns out various GC algorithms are actually useful.

I don't know what you're trying to say here, but I think I know why — you don't know either. Stop spitballing.

There are no "various GC algorithms" at play here at all. There is just a new algorithm that performs better. You can read all about it here: https://go.dev/blog/greenteagc. It's not an optional alternative GC, but a successor.