runtime: goroutines may allocate beyond the hard heap goal #40460
Today, it's possible (though unlikely) that goroutines may allocate beyond the hard heap goal.
Consider the following scenario:
We've now exceeded the hard heap goal, which is currently 1.1 * the heap goal (so 110 MiB in this example).
The fundamental problem here is that there is nothing to push back on G1 while the GC is nearly done, or after we've exceeded the soft goal. The assist credit system is the sole mechanism through which a goroutine may be blocked and forced to assist. If it still has credit, it won't even bother. This credit mechanism is not necessarily wrong, since it's what allows us to keep the assist cost down by amortizing it, but once we're in this regime where the most important thing is to finish the GC or we're in danger of exceeding the hard goal, it stands to reason that the goroutine should not be allowed to allocate. Doing so directly may have significant negative consequences, so a real solution here needs more thought.
With larger heaps this is even less likely to happen (because allocating fast enough is hard to do), but still possible.
The text was updated successfully, but these errors were encountered: