Seriously, I would *love* golang if I could have it as not-GC'ed.
Conversation
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.
1
4
This Tweet was deleted by the Tweet author. Learn more
Their approach makes sense when latency matters a lot and most of the code avoids heavy allocation. If you have a workload where throughput is all that matters, the design is a bad fit, especially if you need lots of dynamic allocation - not nearly as cheap as a mainstream GC.