Current Shenandoah code defers to shared GC policy to figure out how many workers to use in its concurrent and parallel phases. This sounds like a good idea on the surface, but actually is not, for several reasons:

 a) This ties up Shenandoah to the policy for other GCs. Meaning, the global changes in policy affect Shenandoah without us knowing. Also, the policy decisions there might not reflect the reality of fully-concurrent non-generational collector.

 b) The policy selects the number of workers depending on current number of application threads. Meaning, the GC behavior changes as application phase changes. This makes Shenandoah less predictable.

 c) The way current policy is implemented, user settings for ParallelGCThreads and ConcGCThreads take priority over dynamic policy. This makes the case of *setting* the ParallelGCThreads=4 and *defaulting* to ParallelGCThreads=4 quite different. In the latter case, policy can decide to run parallel phases with 1..4 threads, not with 4 threads always. This makes tuning Shenandoah harder.
 
 d) If we are in a very quick pause, and policy decides to create a new worker, we incur a stall during that pause. The performance for quick pauses depends on worker pools being ready to accept work without extra stalls.

Nominally, this means disabling UseDynamicNumberOfGCThreads when Shenandoah is enabled. Opting-out of UseDynamicNumberOfGCThreads allows further code simplifications, since we do not have to call into shared WorkerPolicy at all.