When a GC starts, Ms are enlisted to run a dedicated or fractional GC worker via a call to findRunnableGCWorker early in schedule.
This is problematic for Ms blocked in findrunnable, which never calls findRunnableGCWorker, and thus cannot run dedicated or fractional GC workers. findrunnable can run idle-priority GC workers, and thus the GC work should get done regardless, but this is going to become particularly problematic if idle-priority GC is removed (#44163).
The typical flow should look something like:
- Normal goroutine calls
gcStart.
- During the process of starting GC,
startTheWorldWithSema calls wakep, waking an M stopped in findrunnable.
- The woken M runs a GC mark worker at idle-priority.
- The M from (1) eventually enters the scheduler and calls
findRunnableGCWorker, running a dedicated GC mark worker, and then calls wakep from schedule, waking another M stopped in findrunnable.
- The woken M runs a GC mark worker at idle-priority.
If the Ms at (3) and (5) are not spinning (which they won't be if it will be fully stopped), I don't believe there will be anymore wakep calls, thus limiting the total number of workers to a maximum of three.
FWIW, I don't think it should be fundamentally difficult to move a findRunnableGCWorker check into findrunnable.
This is somewhat related to #39004, another case of a source of work not reachable from findrunnable (though in that case there is no wakep at all).
cc @mknyszek @aclements
When a GC starts, Ms are enlisted to run a dedicated or fractional GC worker via a call to
findRunnableGCWorkerearly inschedule.This is problematic for Ms blocked in
findrunnable, which never callsfindRunnableGCWorker, and thus cannot run dedicated or fractional GC workers.findrunnablecan run idle-priority GC workers, and thus the GC work should get done regardless, but this is going to become particularly problematic if idle-priority GC is removed (#44163).The typical flow should look something like:
gcStart.startTheWorldWithSemacallswakep, waking an M stopped infindrunnable.findRunnableGCWorker, running a dedicated GC mark worker, and then callswakepfromschedule, waking another M stopped infindrunnable.If the Ms at (3) and (5) are not spinning (which they won't be if it will be fully stopped), I don't believe there will be anymore
wakepcalls, thus limiting the total number of workers to a maximum of three.FWIW, I don't think it should be fundamentally difficult to move a
findRunnableGCWorkercheck intofindrunnable.This is somewhat related to #39004, another case of a source of work not reachable from
findrunnable(though in that case there is nowakepat all).cc @mknyszek @aclements