Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
runtime: delay mutator pacing until the end of lock block #18558
As I understand, currently goroutines may be switched to GC work on memory allocations. This work may take some time, thus pacing goroutines doing a lot of allocations. The problem is that the switch to GC work may happen inside highly contended lock block, so other goroutines become blocked at the beginning of the block. This may significantly increase tail request latencies for highly loaded http servers. This is quite common case. For instance, if a global map is updated under the lock with each incoming request.
The proposal is to postpone GC work till the end of lock block. Additionally, allocation limit may be set at the beginning of each lock block, so the goroutine is switched to GC work after reaching this limit inside the lock block.
I share @ianlancetaylor concerns.
If a lock is heavily contended and all the goroutines, except the one holding the lock, are blocked then the Ps will presumable be idle and the GC will enlist them and get ahead. If not it would be interesting to understand why the GC doesn't get ahead when all the blocked Ps are available to do GC work.
Is this in the wild and if so is there a reproducer?