[tbrock]

I am not a fan of new knobs like this. It reminds me of Java where you actually have to think about -xMx blah blah and setting it is a dark art. I would really prefer if we could somehow confer the memory limit from the container environment to go so this could be set intuitively at the container level without mucking about in the go GC internals.

[spullara]

You are actually suggesting what Java does in a container environment lol.

https://developers.redhat.com/articles/2022/04/19/java-17-wh...

[uup]

Maybe now, but in the past you'd have to worry about things like running out of PermGen space. There were definitely more knobs than a typical container environment.

[spullara]

PermGen was removed from Java in 2014, just a year after Docker was released. Please compare modern with modern rather than "the last time I used it".

[uup]

I did qualify my statement with "in the past." I was pointing out that Java did, in fact, have a lot of annoying knobs to turn. tbrock was advocating against having such knobs as they make deploying a language diffcult. The fact that Java removed one of the annoying knobs doesn't disprove the fact that having such knobs is annoying.

[kaba0]

And in the past it was interpreter only.

[mort96]

I'm sure the goal will always be to be as good as humanly possible out of the box. 99.999% of users will probably never have to think about it. But if your mission-critical application just happens to hit a case which the default behavior handles poorly, would you rather: 1) redesign your system and hope that a different design just happens to not hit the same bad case, or 2) tweak a knob until the GC fits your use case?

I think I'd prefer 2. But 1 will always remain an option I suppose.

[skybrian]

I agree that getting a suitable default from the container would be a good idea. It probably requires cooperation from the many different containers out there, though. There might sometimes be more than one process per container, too, which implies some kind of flexbox-like layout algorithm to allocate memory within the container.

And on the other hand, it's a simple flag. They added one memory flag in over a decade. I think they're holding the line on complexity pretty well?

[yencabulator]

Well, what you got is

1. runtime feature to limit memory use

2. a mechanism to configure it

What we just don't have yet is

3. standard way to read container memory limit

Once that comes to existence, the first two were gonna be needed anyway. And now you can experiment with #3 for the various container runtimes.