3 ms·
sync.pools aka buffer pools. this puts lots of back pressure on GC trading bursts of speed for a more noticeable pause at a later time bc of the pause-the-worl
by pxue 11y ago
sync.pools aka buffer pools.
this puts lots of back pressure on GC trading bursts of speed for a more noticeable pause at a later time bc of the pause-the-world style GC. I'd love to see if this is still the case with the GC improvements in Go 1.5+. One solution is to manually load balance your web services to switch seamlessly between GC pauses (stagnated gc), without this it's almost unusable in real time applications.
- infogulch 11y agoYeah I thought sync.Pool might be involved. But I don't see how this would negatively impact the GC, since using a pool almost always reduces the amount of garbage.
- pxue 11y agoUnlike in C you can't tell the garbage collector to "ignore" a large chunk of the memory allocated in the buffer. what ends up happening is Go's GC spends lots of time traversing the heap and marking anyway and end up doing nothing. I know they've made optimizations like here https://github.com/golang/go/issues/9477 https://github.com/golang/go/issues/9477 but I haven't followed it up and gave it another look yet.