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.)
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 (
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.)
- relates to
-
JDK-8209975 Some GCThreadLocalData not initialized
-
- Resolved
-
-
JDK-8214097 Rework thread initialization and teardown logic
-
- Resolved
-
-
-
- Closed
-