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.
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. > On Jan 23, 2020, at 6:13 AM, Kevin Chadwick <m8il1i...@gmail.com> wrote: > > On 2020-01-20 18:57, Robert Engels wrote: >> This is solved pretty easily in Java using soft references and a hard memory >> cap. >> >> Similar techniques may work here. > > One of the only things I dislike about GO compared to C is the arbitrary > memory > allocation but it has great benefits in coding time and I expect you can > handle > an array allocation panic etc. and keep track of your buffers. > > I know that OpenBSD sets limits by default which need to be raised for > chrome/firefox to prevent OOM death etc. which isn't the case on Linux without > default limits (last I heard). I believe Linux kills the hogging process > instead! > > I seem to remember OpenBSD devs saying the OS provides opportunity for Firefox > to manage it's own OOM condition with these limits in place. I took that to > mean > that Linux defaults have made it difficult to handle this properly in general, > but I may lack understanding of the general issue? > > -- > 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/97c30a53-1b99-6424-fd00-9a7ae10a77f6%40gmail.com. -- 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/8F45240D-E57E-4655-98BE-4E103A222405%40ix.netcom.com.
