Summary
Determine the upper limit for the number of threads GC should use based on heap size by setting UseDynamicNumberOfGCThreads as default.
Problem
Garbage collectors currently size the number of threads to use to the number of available CPU resources.
This is a very bad fit for running smaller VMs (installers, ...) with tens or low hundreds of MB of heap sizes as even in this case tens of threads are being created at startup and later used during gc.
This leads to delayed startup, and inefficient use of thread resources - actually in many cases using less threads for GC work if there is little work to do improves pause times due to synchronization overhead.
Hotspot already has the command line option UseDynamicNumberOfGCThreads which limits the number of threads based on heap size. However this feature is currently turned off by default.
Solution
Set the default value of the existing flag "UseDynamicNumberOfGCThreads" to true.
Specification
diff -r 2a12ff1fff68 src/hotspot/share/runtime/globals.hpp
--- a/src/hotspot/share/runtime/globals.hpp Tue Mar 06 10:30:24 2018 +0100
+++ b/src/hotspot/share/runtime/globals.hpp Tue Mar 06 12:57:37 2018 +0100
@@ -1430,9 +1430,10 @@
"Use semaphore synchronization for the GC Threads, " \
"instead of synchronization based on mutexes") \
\
- product(bool, UseDynamicNumberOfGCThreads, false, \
- "Dynamically choose the number of parallel threads " \
- "parallel gc will use") \
+ product(bool, UseDynamicNumberOfGCThreads, true, \
+ "Dynamically choose the number of threads up to a maximum of " \
+ "ParallelGCThreads parallel collectors will use for garbage " \
+ "collection work") \
\
diagnostic(bool, InjectGCWorkerCreationFailure, false, \
"Inject thread creation failures for " \
- csr of
-
JDK-8198510 Enable UseDynamicNumberOfGCThreads by default
- Resolved
- relates to
-
JDK-8199513 Release Note: Garbage Collectors Adaptively Scale the Number of Threads by Default
- Closed