On 2020-01-23 14:18, robert engels wrote: > There is nothing “special” about it - generally the Go process calls > “malloc()” and fails with OOM (unable to expand the process memory size), but > the OS can kill processes in a low system memory condition without them > calling malloc (OOM killer kills the hogs). If you process is dying due to > the OOM killer you have configuration problems. >
Because GO has it's own limit right? Whereas firefox/chrome didn't bother, likely because who are firefox/chrome to limit your systems memory use when it is the OS job. I guess GO limits it for panics or because Linux has a questionable default of unlimited or maybe because it supports so many platforms, otherwise it does not make any sense to me. The point is that if polling has race issues then I would investigate whether an OOM return/panic might be a timely indicator to the application/routine to clean house. > When malloc() fails in a GC system, it could be because the free space is > fragmented. In a compacting and moving GC, it will shift objects around to > make room (Go does not does this, most Java collectors do). Additionally, > what I was primarily pointing out, rather than failing the GC will free “soft > refs” to make room. Right, I believe tiny go does some compacting but you are better off without dynamic memory at all on a micro without an MMU. This compacting doesn't really solve the issue in a dynamic world with an MMU either, but just makes the system more predictable, doesn't it? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/7fea4901-16df-93e7-8a7c-9b95beb9a33e%40gmail.com.
