Go 1.19 only had this in its notes for memory changes
"...includes support for a soft memory limit. This memory limit includes the Go heap and all other memory managed by the runtime, and excludes external memory sources such as mappings of the binary itself, memory managed in other languages, and memory held by the operating system on behalf of the Go program"
> ...includes support for a soft memory limit. This memory limit includes the Go heap and all other memory managed by the runtime, and excludes external memory sources such as mappings of the binary itself, memory managed in other languages, and memory held by the operating system on behalf of the Go program"
Of course it’s a runtime setting, it won’t affect other factors but you can’t say it didn’t solved anything “because there’s a GitHub issue open” Then Go runtime was unpredictable because of its ideology “CPU is unlimited but not Memory” and containers are kinda of a dynamic resource allocated but it did solve vast amount of problem dealing with kernel OOM and unpredictable GC cycles
I would be surprised if the Go team implemented it into the runtime, because some devs would love to have there own way of handling such settings so I don’t see it as an issue
We can’t just compare added features if don’t compare how backwards compatible the language is at that time I don’t know much about Java, but I wouldn’t say the same from upgrading from Go 1.9 to Go 1.19
lenkite|1 year ago
You still need to use a helper library like https://github.com/KimMachineGun/automemlimit or https://github.com/uber-go/automaxprocs.
Go 1.19 only had this in its notes for memory changes
"...includes support for a soft memory limit. This memory limit includes the Go heap and all other memory managed by the runtime, and excludes external memory sources such as mappings of the binary itself, memory managed in other languages, and memory held by the operating system on behalf of the Go program"
Forgot to add: The JVM does this for you since JDK 17 https://developers.redhat.com/articles/2022/04/19/java-17-wh...
demi56|1 year ago
Of course it’s a runtime setting, it won’t affect other factors but you can’t say it didn’t solved anything “because there’s a GitHub issue open” Then Go runtime was unpredictable because of its ideology “CPU is unlimited but not Memory” and containers are kinda of a dynamic resource allocated but it did solve vast amount of problem dealing with kernel OOM and unpredictable GC cycles
> You still need to use a helper library like https://github.com/KimMachineGun/automemlimit or https://github.com/uber-go/automaxprocs.
I would be surprised if the Go team implemented it into the runtime, because some devs would love to have there own way of handling such settings so I don’t see it as an issue
> Forgot to add: The JVM does this for you since JDK 17 https://developers.redhat.com/articles/2022/04/19/java-17-wh...
We can’t just compare added features if don’t compare how backwards compatible the language is at that time I don’t know much about Java, but I wouldn’t say the same from upgrading from Go 1.9 to Go 1.19
btreecat|1 year ago