JDK-8201235 : Lazy allocation of compiler threads
  • Type: CSR
  • Component: hotspot
  • Sub-Component: compiler
  • Priority: P4
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 11
  • Submitted: 2018-04-06
  • Updated: 2018-04-23
  • Resolved: 2018-04-20
Related Reports
CSR :  
JDK-8198756 - Lazy allocation of compiler threads
Description
Summary
-------

Allocate and remove compiler threads on demand depending on the compile queue lengths and available memory. 

Problem
-------

The VM currently starts a large number of compiler threads on systems with many CPUs regardless of available memory and number of compilation requests. This leads to inefficient use of resources. They consume memory even if they are idle almost all of the time.

A similar issue regarding GC was addressed with the option UseDynamicNumberOfGCThreads which is now active by default.

Solution
--------

Change the implementation to start only one compiler thread of each type during startup and handle the start and shutdown of further threads dynamically controlled by a new command line flag:

-XX:+UseDynamicNumberOfCompilerThreads

This is the main flag which controls this feature. It is on by default.

Specification
-------

      product(bool, UseDynamicNumberOfCompilerThreads, true,                \
          "Dynamically choose the number of parallel compiler threads")     \
                                                                            \
http://cr.openjdk.java.net/~mdoerr/8198756_CompilerCount/webrev.05/
Comments
Moving to Approved.
20-04-2018
Minor edits and added myself as a reviewer. I don't object to one Product and one Diagnostic flag.
18-04-2018
I updated request based on discussion.
18-04-2018
I don't like numbered flags - I always forget what numbers mean. I can agree to make ReduceNumberOfCompilerThreads to diagnostic flag since performance testing shows no difference in our benchmarks. In such case only one flag will be product - UseDynamicNumberOfCompilerThreads.
17-04-2018
Copied from the main bug: UseDynamicNumberOfCompilerThreads / ReduceNumberOfCompilerThreads: do we really need multiple flags here? Would it not be better and more flexible in the future to define one flag that takes an int that represents a thread management policy: - 0: static thread creation at VM init (default) - 1: dynamic startup and terminate when idle - 2: dynamic startup but never terminate - 3: whatever you want to try next ...
08-04-2018
Please move this back to Draft Martin, although JBS allows you to do this you need to have a Reviewer before you can actually propose it, and you need to fill in a bunch of other things regarding capatability etc - edit the issue to see what needs to be done. Thanks.
06-04-2018