GC settings, Go now has 2, adopted ours, we should adopt theirs: "Go runtime: 4 years later"

A new knob

With Go 1.19 comes an long-requested feature that requires a little extra work to use, but carries a lot of potential: the Go runtime’s soft memory limit.

[Julia 1.9 has such]

For years, the Go GC has had only one tuning parameter: GOGC. GOGC lets the user adjust the trade-off between CPU overhead and memory overhead made by the Go GC. For years, this “knob” has served the Go community well, capturing a wide variety of use-cases.

The Go runtime team has been reluctant to add new knobs to the Go runtime, with good reason: every new knob represents a new dimension in the space of configurations that we need to test and maintain, potentially forever. The proliferation of knobs also places a burden on Go developers to understand and use them effectively, which becomes more difficult with more knobs. Hence, the Go runtime has always leaned into behaving reasonably with minimal configuration.

So why add a memory limit knob?

Memory is not as fungible as CPU time. With CPU time, there’s always more of it in the future, if you just wait a bit. But with memory, there’s a limit to what you have.

The memory limit solves two problems. […]

They allow setting from within the program (at least the setting we have), likely because they ship binaries (with the [GC] runtime), and users to not or wouldn’t know how to set. I do support users being able to set some different things, but should the program also have access, maybe within the limit from the CLI option?