runtime: GC can thrash on very small heaps

[aclements]

In applications with very small heaps and high allocation rates, the garbage collector can consume a large amount of CPU by running very frequently. This particularly affects microbenchmarks, which often have virtually no live heap, causing a full GC cycle every 4MB of allocation. We've seen this several times, and Cloudflare just blogged about this problem: https://blog.cloudflare.com/go-dont-collect-my-garbage/

We should consider rate-limiting the garbage collector, allowing the heap to grow beyond the goal if the GC is running too frequently or using too much CPU. We could potentially replace the (rather arbitrary) 4MB lower-bound on heap size with a more principled rate-limiting system.

One possible approach is to enforce an upper bound on GC utilization. This could be measured GC CPU overhead (e.g., MemStats.GCCPUFraction) or simply the ratio of GC active wall-clock time to total wall-clock time. The GC trigger would be delayed until this metric drops below the upper bound. This should prevent thrashing.

With this approach, we could also enforce a lower bound, which could be a more principled replacement for the current 2 minute forced GC. This should prevent starvation.

@RLH and I have talked about this several times, but apparently neither of us filed an issue to track it. I'm correcting that. :)

[aclements]

The actual problem here is that we fail to amortize the cost of GC on small heaps. I've detailed the problem in #23044 (comment).

[prattmic]

@mknyszek do we want to do more here?

[mknyszek]

I don't think so. While the pacer doesn't really model some GC fixed costs and things can still get weird when these fixed costs dominate, the Go 1.18 pacer also pushed this problem back enough that I'm comfortable not doing anything else here for now and calling it good.