Understanding the Go Runtime: The System Monitor

In the previous articles we explored the scheduler — how goroutines get multiplexed onto OS threads through the GMP model — and the garbage collector — how Go tracks and reclaims memory using a concurrent, tri-color mark-and-sweep approach. Both of these systems are impressive, but they have real blind spots. The scheduler can’t reclaim a P that’s stuck in a syscall, because no Go code is running on that thread — there’s nobody to notice and hand the P off. The GC won’t fire if no allocations are happening, because it’s allocation pressure that triggers a collection cycle. These aren’t bugs, they’re inherent limits of systems that only run when Go code runs.