runtime.GC is called in the test and may spin up GOMAXPROCS
(proportional to the initial count) new threads. We need to be robust to
this, and it happens relatively frequently on some platforms.
We didn't notice this earlier since the heap is so miniscule that
runtime.GC essentially finished instantly without all the threads
getting spun up.
Fixes #76613.
Change-Id: I2af02cb090d5c1c952e4db53ad35895b6f23f638
Reviewed-on: https://go-review.googlesource.com/c/go/+/726642
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
// threads through frequent scheduling, like mayMoreStackPreempt.
// A slack of 5 is arbitrary but appears to be enough to cover
// the leftovers plus any inflation from scheduling-heavy build
- // modes.
- const threadsSlack = 5
+ // modes. We then also add initialGMP to this slack, since we're
+ // about to call runtime.GC, and in the worst case this will
+ // spin up GOMAXPROCS new threads to run those workers.
+ threadsSlack := 5 + uint64(initialGMP)
// Make sure GC isn't running, since GC workers interfere with
// expected counts.