6 ms·

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 other

by cafxx 9mo 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.

pjmlp 9mo ago
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.
- cafxx 9mo ago
  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).
  - pjmlp 9mo ago
    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.
    - cafxx 9mo ago
      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).
      - pjmlp 9mo ago
        GOGC was introduced in Go 1.5, and I thought the problem was solved. https://go.dev/blog/go15gc 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.
        cafxx 9mo ago
        > 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.
        pjmlp 9mo ago
        That would be since Go exists, literally.
        cafxx 9mo ago
        The point is that no-one is thinking to add knobs, or allow alternative GCs.
- Mawr 9mo ago
  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 https://go.dev/blog/greenteagc. It's not an optional alternative GC, but a successor.

by cafxx 9mo ago

pjmlp 9mo ago

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.

cafxx 9mo ago
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).
- pjmlp 9mo ago
  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.
  - cafxx 9mo ago
    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).
    - pjmlp 9mo ago
      GOGC was introduced in Go 1.5, and I thought the problem was solved. https://go.dev/blog/go15gc 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.
      - cafxx 9mo ago
        > 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.
        pjmlp 9mo ago
        That would be since Go exists, literally.
        cafxx 9mo ago
        The point is that no-one is thinking to add knobs, or allow alternative GCs.
Mawr 9mo ago
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 https://go.dev/blog/greenteagc. It's not an optional alternative GC, but a successor.