Stop-the-world latency during Garbage Collection in G-M-P scheduler

The Go runtime employs a G-M-P model to manage concurrency, where the scheduler distributes goroutines (G) across logical processors (P) and OS threads (M). During Garbage Collection (GC), the runtime must initiate a stop-the-world (STW) phase to ensure memory consistency across all active threads.

In environments with a high number of OS threads (M) created due to frequent blocking syscalls, the time required to pause all threads can increase. This introduces uncertainty regarding how the scheduler handles the transition of goroutines from local run queues to the global queue when an M is forced into a pause state during a GC cycle.

• Does the scheduler prioritize flushing local run queues to the global queue before completing the STW pause?
• What is the impact on work-stealing efficiency when a P is detached from an M during a GC-induced pause?