Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8320969

Shenandoah: Enforce stable number of GC workers



    • gc
    • b27


      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.


        Issue Links



              shade Aleksey Shipilev
              shade Aleksey Shipilev
              0 Vote for this issue
              4 Start watching this issue