I couldn&#x27;t have said it better. This is almost word for word why I decided to build mmm: I maintain a few high-load RPC services in Go, each of which stores millions, if not tens of millions of items in their cache.<p>In this configuration, each incoming request means allocations inside Go&#x27;s RPC package [1], which in turn means that a GC pass will be triggered if GC_PERCENT [2] has been reached, which in turn means that the GC will have to scan all of those long lived pointers (Go&#x27;s GC is not generational), which in turn means a huge peak in response time.<p>This basically leaves me with three possible solutions:<p>- hack into Go&#x27;s RPC package to minimize allocations, which is a huge price to pay just to delay the inevitable<p>- build my caches in a language that offers manual memory management, then query those via RPC from my Go services; but I don&#x27;t want to add a new language into the mix<p>- provide a generic solution for manual memory management in Go, which is where we are now<p>[1] <a href="https:&#x2F;&#x2F;golang.org&#x2F;pkg&#x2F;net&#x2F;rpc&#x2F;" rel="nofollow">https:&#x2F;&#x2F;golang.org&#x2F;pkg&#x2F;net&#x2F;rpc&#x2F;</a><p>[2] <a href="https:&#x2F;&#x2F;golang.org&#x2F;pkg&#x2F;runtime&#x2F;debug&#x2F;#SetGCPercent" rel="nofollow">https:&#x2F;&#x2F;golang.org&#x2F;pkg&#x2F;runtime&#x2F;debug&#x2F;#SetGCPercent</a>