JavaThread::get_thread_name() requires that the caller own the Threads_lock if not operating on the current thread, to ensure the safety of the access. But since ThreadSMR the use of the Threads_lock is not the primary mechanism for ensuring safe access to a JavaThread. The code should be updated to allow access when the target thread is on a ThreadsList held by the current thread.
Erik O. writes:
There currently is no "can_access_safely()" function. Implementing it is not impossible. The safety is ensured often with hazard pointers,
but in nested cases, there could be some reference counting going on. Fortunately, we have an abstraction called SafeThreadsListPtr, which
abstracts away those details, and importantly, also describe the current nesting in a walkable linked list.
The "top" SafeThreadsListPtr is reachable from Thread::current()->_threads_list_ptr. You can walk the nestings by following the _previous
pointers. By walking these things and checking of the target thread is in any of the ThreadsList instances they point at, you can provide
an accurate answer to "can_access_safely()", in the sane scenarios where it is Thread::current() that ensures the safety.
However, it is worth mentioning that we have some rare cases where the safety is provided through a surrogate thread, so it might look
like it is not safe, when it fact it is. This is very rare though, and unless the assert triggers on that (I hope not), then I think we
should ignore that.
---
Dan D. writes:
This is a way to see if the current thread an associated ThreadsList:
inline ThreadsList* Thread::get_threads_hazard_ptr() {
return (ThreadsList*)Atomic::load_acquire(&_threads_hazard_ptr);
}
Once you have the ThreadsList, you can use
ThreadsList::includes(const JavaThread * const p)
to see if your target is on _that_ ThreadsList. If there are nested
ThreadsLists, then more work is required.
Because you are asking the question of your own ThreadsList, I don't
think you need to go through the SafeThreadsListPtr layer and can
deal directly with your own ThreadsList (and probably its nested
ThreadsLists).
Or perhaps the right solution is to add a ThreadsListHandle to this
code and then query the ThreadsListHandle to see if it includes the
target thread (more about this below)... Although that will only
answer the question for the current snapshot and won't answer the
question for any nested ThreadsListHandles that the calling thread
might have...
---
It is noted that until JDK-8240588 is fixed access to the threadObj() would not be truly safe.