Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8241403

JavaThread::get_thread_name() should be ThreadSMR-aware



    • b12


      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

      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.


        Issue Links



              dcubed Daniel Daugherty
              dholmes David Holmes
              0 Vote for this issue
              4 Start watching this issue