Details
-
Type:
Bug
-
Status: Resolved
-
Priority:
P3
-
Resolution: Duplicate
-
Affects Version/s: 10
-
Fix Version/s: None
-
Component/s: hotspot
-
Labels:
-
Subcomponent:
Description
Attempting to transition to using SMR techniques ran into the following problem:
the _threads array inside my ThreadsListHandle stack local variable was destroyed / removed after removing the Threads_lock, which was covering the scope of using the ThreadsListHandle.
It seems that it is not enough to take a SMR ThreadsListHandle for thread list interaction, but you also need to be registered as a thread that SMR will inspect when doing updates to the threads list (which it does under the exclusive Threads_lock).
Currently, this “registration” is done using Threads::do(), which means this is a static registration of threads to scan for SMR, that is, it is not a dynamic one.
We should figure out some means of providing automatic (ideal) and/or dynamic (ok) SMR thread registration.
the _threads array inside my ThreadsListHandle stack local variable was destroyed / removed after removing the Threads_lock, which was covering the scope of using the ThreadsListHandle.
It seems that it is not enough to take a SMR ThreadsListHandle for thread list interaction, but you also need to be registered as a thread that SMR will inspect when doing updates to the threads list (which it does under the exclusive Threads_lock).
Currently, this “registration” is done using Threads::do(), which means this is a static registration of threads to scan for SMR, that is, it is not a dynamic one.
We should figure out some means of providing automatic (ideal) and/or dynamic (ok) SMR thread registration.
Attachments
Issue Links
- duplicates
-
JDK-8209976 Improve iteration over non-JavaThreads
-
- Resolved
-
- relates to
-
JDK-8191798 redo nested ThreadsListHandle to drop Threads_lock
-
- Resolved
-