JDK-6858051 : Create GC worker threads dynamically
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs16
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2009-07-07
  • Updated: 2023-11-06
  • Resolved: 2016-05-09
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b120Fixed
Related Reports
Duplicate :  
JDK-7189147 - GC threads should be created as needed not all at once
Relates :  
JDK-8131932 - Ergonomics oversize number of GC threads for small JVMs on large systems
Relates :  
JDK-8213224 - Move code related to GC threads calculation out of AdaptiveSizePolicy
Relates :  
JDK-8231669 - Remove WorkerManager abstraction to support multiple work gang implementations
Relates :  
JDK-7189147 - GC threads should be created as needed not all at once
Relates :  
JDK-6593758 - RFE: Enhance GC ergonomics to dynamically choose ParallelGCThreads
Description
See evaluation.
The VM currently creates all GC worker threads during initialization, and all workers participate in every GC.  There is work in progress to change the latter property (6593758), so that the number of active GC worker threads can vary from one collection to the next based on the amount of work.  Once that feature is enabled, GC worker threads should be created lazily (only when needed) and destroyed when not needed.  This would save memory and improve startup time (slightly) for applications which do not use GC heavily.
Comments
URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/54d0862c0773 User: lana Date: 2016-05-25 17:36:48 +0000
25-05-2016
URL: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/54d0862c0773 User: jmasa Date: 2016-05-09 00:37:49 +0000
09-05-2016
I'm changing this enhancement to dynamically create GC threads as needed but not to destroy them when not needed. The latter can be added back in another CR if desirable.
18-04-2016
EVALUATION Once the number of GC workers can be varied, creating and destroying them dynamically is the logical next step. Must make sure that failure to create a new worker thread is not a fatal error, and that any partially allocated state is cleaned up. A policy for destroying worker threads is also needed (e.g., if a thread has not been used in N successive collections).
07-07-2009