When GC is running behind the pace at which mutators are allocating memory, increase the number of GC worker threads that contribute to GC progress. Each phase of GC (marking, evacuating, updating) can have a different number of worker threads.

We can detect that GC is running slow by:
 1. The triggering heuristic can know that it has "triggered too late".
 2. If the previous phase of GC required throttling
 3. If the previous GC degenerated, we may not "understand" the workload's requirements because it is "spiking"

The plan is to allow surging of more than ConcGCThreads but no more than ParallelGCThreads. In a typical configuration, Parallel GCThreads is less than the total number of cores available on the host.

The benefit of surging is that this can sometimes avoid a transition to degenerated GC. The transition typically requires a minimum of 10 ms, and has been observed to require over 100 ms in some cases, as concurrent GC is not always instantly interruptible.

If we can avoid degenerated GC, this allows mutator threads to continue making some amount of (potentially degraded) progress during GC and avoids the long pauses and context-switch overheads associated with transitioning to STW gc.