Use garbage collection, they said. Manual memory management is too hard, they said. Garbage collection means you don't need to think about memory, they said.
Now the code uses 14m of actual memory, but my OS needs to provide 400m for those 14m, and I am reading the runtime.
Conversation
Seriously, I would *love* golang if I could have it as not-GC'ed.
7
2
39
Replying to
I am not sure that’s Go fault. With TamaGo, which keeps the Go runtime almost identical but on ARM bare metal and therefore without the OS virtual memory, we don’t see much memory waste. And we have much less memory to spare. Are you sure it isn’t just Linux overcommitting?
1
Replying to
From golang's own accounting: Alloc: 31324248 Sys: 917090656 - 900 megs of system memory for 31 megs of live heap-allocated objects. But I am not sure yet, I am in the process of root-causing what is going on.
1
2
Replying to
Sys is the total bytes of memory obtained from the OS, I think Alloc is what matters. Isn't this just the OS over committing VM to the process?
1
Replying to
Let me root-cause this; we're both guessing into the dark. I suspect this is a combination of heap fragmentation & bad scavenging after short memory usage spikes.
1
Go doesn't use a moving (compacting) GC, so it isn't good at reclaiming memory from small objects.
They've chosen to value low pause times and minimal impact on the latency / throughput of pointer accesses above everything else.
It uses lots of memory and has bad throughput.
1
2
Allocation is far slower than a more mainstream modern GC and they don't compact the heap. In exchange, they avoid the cost of ever needing read barriers, largely avoid the cost of write barriers and still have quite low latency. Allocation of small objects resembles tcmalloc.
Things might have changed a little with recent versions, but otherwise these are two good links:
ardanlabs.com/blog/2018/12/g
blog.golang.org/ismmkeynote
1