-
Bug
-
Resolution: Duplicate
-
P3
-
None
-
10
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.
- duplicates
-
JDK-8209976 Improve iteration over non-JavaThreads
- Resolved
- relates to
-
JDK-8191798 redo nested ThreadsListHandle to drop Threads_lock
- Resolved