JDK-8215097 : Do not create NonJavaThreads before BarrierSet
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 12
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2018-12-09
  • Updated: 2018-12-14
  • Resolved: 2018-12-11
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 12
12 b24Fixed
Related Reports
Relates :  
JDK-8209975 - Some GCThreadLocalData not initialized
Relates :  
JDK-8214097 - Rework thread initialization and teardown logic
Relates :  
JDK-8209974 - Eliminate shared PtrQueues
Description
There can be some NonJavaThreads threads created before the barrier set has been created. JDK-8209975 introduced some bootstrapping workarounds to deal with the barrier set not being available for some of the initialization of these threads (via on_thread_create).

It would be simpler if the barrier was created before any such threads were created.  There are also in-progress changes that may benefit from such reordering (JDK-8214097, JDK-8209974).

The only NonJavaThreads presently created too early are gang workers used by G1 or by CMS. All other threads used by those collectors are created after the barrier set. Parallel and ZGC create their barrier set before they create any threads. Other NJTs used by the VM are also created after the barrier set.

(Note that the main thread is the only JavaThread created before the barrier set.  Reordering those is a different problem.)